O DOCOD Runtime é a implementação open source de referência do método DOCOD.
Ele deriva o estado de engenharia diretamente dos arquivos do projeto, verifica relações, hashes, aprovações e evidências, e impede que um gate continue verde quando aquilo que o sustentava mudou.
The files are the state.
Open source · zero-install (Node ≥18, YAML vendorizado) · model-neutral
Define · Orchestrate · Confirm · Observe · [re]Define
O método organiza como intenção vira decisão, como o trabalho é coordenado, como resultados são confirmados, como o sistema é observado e como aprendizado volta para o próximo ciclo.
Seu papel é tornar verificável aquilo que não deveria depender da memória, da interpretação ou da palavra de um agente.
É o SDLC, o Software Development Life Cycle.
A disciplina que engenharia de software usa há décadas para transformar intenção em sistemas que podem ser construídos, testados, operados e evoluídos.
O DOCOD não substitui esse ciclo.
Ele o reorganiza para um ambiente em que agentes participam cada vez mais da execução.
| SDLC clássico | Movimento DOCOD | Artefatos que você já conhece |
|---|---|---|
| Planejamento e viabilidade | Define | business case |
| Requisitos e análise | Define | PRD, FRD, user stories |
| Design e arquitetura | Orchestrate | system design, data design, security design, API contract, ADR |
| Implementação | Orchestrate | tasks, code, evidence |
| Testes e verificação | Confirm | test plan, QA, design review, code review |
| Deploy e operação | Observe | SLOs, runbooks, playbooks, release notes |
| Manutenção e evolução | [re]Define | postmortem, impact analysis, novo ciclo |
A tabela mostra onde cada artefato costuma nascer.
ADRs, RFCs, trade-offs e impact analysis são transversais. Eles aparecem quando uma decisão exige, não porque existe uma fase fixa reservada para eles.
Um desenvolvedor humano preenche uma lacuna com experiência, contexto informal, conversa de corredor ou julgamento acumulado.
Um agente não recebe nada disso por padrão. Ele recebe contexto.
Quando esse contexto está incompleto, ele não para necessariamente. Ele infere. E uma inferência plausível ainda pode produzir software errado.
Quanto mais execução você delega, mais explícita precisa ser a engenharia que orienta essa execução.
Agentes também ajudam a entrevistar, estruturar requisitos, comparar documentos, encontrar inconsistências, manter artefatos e propagar mudanças.
O que antes parecia apenas documentação sobre o sistema passa a participar da própria execução dele.
A especificação deixa de ser papelada sobre o trabalho. Ela passa a programar o contexto dentro do qual o trabalho acontece.
Ele não apenas registra que algo foi aprovado.
Ele verifica se a aprovação ainda corresponde ao conteúdo atual.
Não apenas registra que um artefato depende de outro.
Ele detecta quando o input vivo mudou.
Não apenas pede que um agente cite evidência.
Ele verifica mecanicamente aquilo que pode verificar.
E quando a capacidade necessária não existe:
ele não fabrica um pass.
DOCOD não substitui o SDLC. Ele torna o SDLC operacional para engenharia de software com agentes.
Toda vez que o runtime roda, ele lê o projeto novamente.
Ele é derivado dos arquivos que existem agora.
Nada precisa lembrar que o evento aconteceu. O estado atual emerge do que está no disco.
Um sistema legado não precisa ser convertido inteiro antes que o runtime ajude. O modo diagnóstico aponta para o repositório e devolve o mapa com proveniência: o que foi observado, o que foi inferido, o que veio de alguém de fora. Sem criar pins, sem criar gates, sem congelar baseline.
Pre-read, not pre-approved.
A disciplina neutra. O ciclo e os princípios que independem de modelo, linguagem ou ferramenta.
Agentes, regras, skills e contratos que definem responsabilidades, entradas, saídas e condições.
A camada que materializa o método dentro de um harness. Slash commands, subagents e integrações pertencem aqui.
O projeto real. Sua configuração, seus artefatos, suas decisões e seu estado.
Files → Derive → Gate → Human decision
E depois lê os arquivos novamente.
O que muda entre harnesses é o adapter. O método, os contratos e o estado derivado dos arquivos não mudam. Um harness passa a ser suportado ganhando um adapter, não reescrevendo a disciplina.
A lista de papéis não está codificada no runtime: agentes, skills e artefatos são DECLARADOS em registros. Um projeto pode acrescentar os seus escrevendo o contrato e registrando-o, do mesmo jeito que os que vêm na caixa. O que o método fixa é a forma do contrato, não quem está nele.
São essas peças que dão corpo à governança. Sem elas, o que sobra é ethos.
Ele coloca contratos, estado derivado, evidência e gates ao redor da execução.
Porque a pergunta importante não é apenas:
O agente consegue fazer isso?
É também:
Como sabemos o que ele deveria fazer, o que realmente fez, e se ainda podemos confiar nesse resultado depois que o projeto mudou?
Quando uma pessoa aprova um artefato, o runtime grava quem aprovou, quando, e o hash do conteúdo aprovado.
Se o arquivo for alterado depois, o hash deixa de corresponder. A aprovação anterior não continua verde por conveniência: ela se torna inválida, e aquilo que depende dela é reavaliado.
Artefatos registram os inputs dos quais dependem. Quando um input vivo muda, o runtime detecta mecanicamente que a relação ficou stale.
Entender como aquela mudança deve ser propagada continua exigindo análise. Detectar que a premissa antiga não é mais a mesma, não: o input reaparece como stale e o downstream é re-bloqueado.
O runtime verifica mecanicamente aquilo que consegue provar: se o frontmatter realmente parseia, se o status é permitido pelo método, se o hash da aprovação ainda bate com o conteúdo, e se os hashes dos inputs ainda batem com as fontes vivas. A lista completa de checks e warnings vive no manual.
Algumas condições falham o gate. Outras aparecem como warnings. E um pass também declara seus limites: pass silencioso não ensina.
Se uma capacidade necessária para verificar alguma coisa não existe no ambiente, o runtime não trata ausência de evidência como sucesso.
Missing capability is not permission to improvise.
Ele automatiza trabalho.
Não responsabilidade.
O projeto continua precisando saber:
É para isso que o runtime existe.
Open source · zero-install (Node ≥18, YAML vendorizado) · model-neutral