Ecossistema DEV

O problema apareceu na prática.

Trabalhar em vários projetos assistidos por IA introduziu riscos que não existiam quando havia um único sistema em foco. Os exemplos abaixo foram observados durante o trabalho e motivaram a organização atual.

• Misturar contexto de projetos diferentes.
• Aplicar a regra de um sistema em outro por semelhança.
• Trabalhar no diretório ou repositório errado.
• Transformar a ferramenta atual em regra permanente.
• Perder decisões quando uma conversa termina.
• Utilizar estrutura antiga como se ainda fosse vigente.
• Automatizar antes de compreender o problema.
• Espalhar documentação contraditória.

Separar método de domínio.

O DevTOLAS concentra aquilo que pode ser compartilhado entre projetos: método, governança e templates. Cada projeto preserva o que é seu.

Continuam pertencendo a cada projeto

• Objetivo
• Regras de negócio
• Arquitetura
• Stack
• Código
• Banco de dados
• Infraestrutura
• Identidade visual
• Credenciais
• Decisões específicas do domínio

Padronizar a forma de trabalhar não significa padronizar indiscriminadamente a solução.

O que pode ser compartilhado.

O DevTOLAS é a fonte metodológica comum atual do ecossistema. Ele organiza princípios e critérios para iniciar, analisar, planejar, implementar, testar, auditar, documentar, preservar contexto, tratar risco, organizar continuidade e avaliar reutilização.

Ele não é framework, biblioteca, runtime, arquitetura obrigatória nem stack comum. Nenhum projeto o importa ou o executa.

Isso é orientação de trabalho, não pipeline rígido. A profundidade aplicada depende da natureza e do risco da mudança.

A IA trouxe um problema novo.

Quando o trabalho passou a ser assistido por agentes, o contexto deixou de ser implícito e precisou ser tratado explicitamente. O padrão atual é um workspace por projeto.

O objetivo é reduzir ruído, mistura de informações, utilização acidental de código e transporte indevido de regras entre projetos.

Workspace não é controle de acesso. Ele reduz exposição e mistura de contexto no trabalho cotidiano, mas não constitui uma barreira formal de segurança do sistema operacional.

AGENTS.md — o que não depende da conversa.

Esse arquivo pode manter orientação persistente sobre identidade do projeto, caminhos, fontes documentais, limites, regras de Git, cuidados com informações sensíveis, relacionamento com o DevTOLAS e validações esperadas.

A consequência é menos dependência de repetir instruções a cada nova sessão.

Instruções persistentes também envelhecem e precisam ser revisadas. O próprio ecossistema já precisou corrigir caminhos e referências metodológicas antigas.

Controle proporcional ao risco.

Esse ciclo não é um workflow burocrático aplicado igualmente a toda alteração. Uma correção pequena não exige o mesmo nível de controle de uma reorganização de diretórios, de uma publicação, da remoção de arquivos, de mudança de infraestrutura, de uma operação destrutiva ou de uma alteração com grande impacto.

Quanto maior o impacto, maior deve ser o controle.

Os fundamentos prevalecem sobre as ferramentas.

O ecossistema utiliza hoje VS Code, Codex, Git, GitHub, Lovable e skills específicas. Essas ferramentas atendem ao cenário atual. Elas não são o método.

Uma mudança de ferramenta pode exigir adaptação em integrações, skills, automações e procedimentos específicos. Isso não exige necessariamente abandonar os princípios que organizam o trabalho.

Princípio estável ≠ implementação operacional permanente.

Não existe aqui promessa de independência técnica absoluta nem afirmação de ausência comprovada de lock-in. O que se procura demonstrar é que a definição do método não se apoia na ferramenta utilizada hoje.

Duas independências.

Um problema concreto virou automação.

Essa combinação criou uma necessidade concreta: sincronizar alterações sem sobrescrever trabalho, reescrever histórico ou resolver conflitos silenciosamente.

Diante de uma divergência que exige julgamento humano, a automação deve parar.

O que não é utilizado como solução

• Force push automático
• Descarte silencioso
• Reset destrutivo
• Resolução arbitrária de conflitos
• Sobrescrita apenas para completar o fluxo

Git2Local e Local2Git existem porque resolvem uma necessidade da topologia atual — Lovable ↔ Git/GitHub ↔ ambiente local. Se as ferramentas ou a topologia mudarem, essas skills podem precisar de adaptação, podem ser substituídas ou podem deixar de ser necessárias. A automação atende ao problema atual; o fundamento não depende da permanência da automação.

Nem toda dor vira ferramenta.

Algumas atividades possuem automação ou assistência. Outras continuam manuais, de forma intencional.

Automatizar quando existe uma dor recorrente suficientemente clara para justificar uma ferramenta.

A ausência de automação não deve ser lida automaticamente como deficiência.

Criar um projeto sem escolher a solução antes do problema.

A estrutura mínima atualmente prevista para um novo projeto é deliberadamente neutra.

Esse início não precisa escolher antecipadamente linguagem, framework, banco de dados ou infraestrutura.

A tecnologia deve responder ao problema. O template não deve decidir o problema pela tecnologia.

A criação ainda é parcialmente assistida por instruções e templates. Não existe uma plataforma completa de scaffold automatizado.

Sem depender da conversa.

Uma sessão de IA não deve ser a única memória do projeto. Quando necessário, o registro local guarda alterações, validações, decisões, riscos, pendências e próxima ação.

Git e documentação vigente permanecem fontes mais importantes do que a memória de uma conversa.

Isso não significa gerar documentação burocrática a cada interação. A continuidade deve ser proporcional à necessidade.

O ambiente também precisou ser corrigido.

O Ecossistema DEV não nasceu pronto. Passou por reorganizações, correções de caminhos, separação de material antigo, consolidação do DevTOLAS, revisão de workspaces e criação de novas ferramentas para problemas observados.

Vigente não é a mesma coisa que histórico.

Quando existe valor histórico, arquivar pode ser preferível a simplesmente apagar.

Não existem duas metodologias ativas em paralelo.

Padronizar sem homogeneizar.

Método comum ≠ arquitetura comum obrigatória.

O que já existe e o que ainda está em consolidação.

Essas lacunas fazem parte do estado atual e permanecem visíveis por escolha.

O que o Ecossistema DEV não é.

• Uma stack obrigatória
• Um framework comum
• Uma biblioteca de runtime
• Um pipeline universal de CI/CD
• Uma plataforma integrada
• Uma Fábrica de Software concluída
• Um conjunto obrigatório de ferramentas
• Um sistema que elimina julgamento humano

É o estado atual de uma forma de organizar e governar o desenvolvimento, ainda em evolução.

Como os projetos alimentam o ecossistema.

O Ecossistema DEV não nasceu antes dos projetos. Ele está surgindo a partir deles.

Problemas encontrados durante o desenvolvimento geram decisões. Algumas permanecem específicas do sistema. Outras, depois de avaliadas, podem transformar-se em conhecimento reutilizável. É assim que experiências isoladas começam a formar uma maneira organizada de produzir software.

Ver as evidências

• PDF Livre →
• Find2Go →
• SmartTrade →
• Sia2Fa →