Planejar antes de programar virou padrão de mercado. O que nenhuma ferramenta entrega é o que vem depois do plano: verificação mecânica de que o processo foi seguido — contratos assinados por story, sensores executáveis e evidência em cada afirmação.
ENTREGUE COMO KIT .SDD/ DENTRO DOS DOIS PRODUTOS — LAUDO E CRIAR SPEC
Três forças convergiram entre 2025 e 2026 — e transformaram a especificação governada de boa prática em requisito.
Quando uma funcionalidade custa minutos de agente, o gargalo migra do teclado para a intenção. Descrever vagamente e aceitar o que vier produz código plausível que se afasta da intenção e envelhece mal.
Um agente que abre um repositório precisa saber o que já foi decidido, o que é proibido e como se prova que algo está pronto. Sem isso, cada sessão reinventa o projeto.
Código escrito por IA em produção exige trilha: de onde veio cada mudança, qual evidência a sustentava, quem aprovou. O SDD é a infraestrutura dessa trilha.
Dentro do kit viaja código Python (stdlib pura — roda em qualquer máquina com python3) que transforma governança de recomendação em mecanismo.
18 regras de integridade sobre o próprio .sdd — story sem seção obrigatória, contrato estourado, afirmação presumida sem rastreio de validação. Kit novo abre 100% verde.
O hook BLOQUEIA quem implementou de marcar como pronto ou preencher a própria evidência de QA. Não é "o agente deveria" — é "o agente não consegue".
O registry de sensores é dado executável: cada um com comando, critério e flag bloqueante. QA não aprova story sem exit 0.
O estado do projeto é GERADO dos frontmatters das stories — e a verificação acusa edição manual.
O cânone de qualidade chega pinado por versão e hash, com verificação de cadeia completa. Atualizar exige confirmação humana.
40 sabotadores, um por regra de sensor — prova mecânica de que cada sensor olha de verdade, não passa por vacuidade.
O único juiz não-determinístico (deriva spec×código) é cercado: rubrica explícita, calibração cega — sem calibração válida, sem veredito.
Conversores bidirecionais Spec Kit / OpenSpec / Kiro, com perda documentada em cada arquivo convertido. Entrada e saída sem aprisionamento.
+ Constitution de 25+1 artigos com enforcement mapeado em 24/26 — cada artigo aponta o mecanismo que o impõe; os 2 sem mecanismo estão marcados como decisão registrada, não esquecimento.
Nas duas primeiras linhas o mercado empatou — todo mundo escreve especificação. Da linha grossa para baixo, estamos sozinhos.
| Capacidade | Spec Kit | Kiro | OpenSpec | BMAD | Tessl | ArchGenerator |
|---|---|---|---|---|---|---|
| Especificação antes do código | ● | ● | ● | ● | ● | ● |
| Papéis multi-agente | ◐ | — | — | ● | ◐ | ● 27 |
| Autoridade imposta por mecanismo (hooks) | — | — | — | — | — | ● |
| Contratos de implementação assinados | — | — | — | — | — | ● |
| Sensores executáveis com registry em dados | — | — | — | — | — | ● |
| Evidência graduada por afirmação [A]/[P]/[Q] | — | — | — | — | — | ● |
| Processo que verifica a si mesmo (mutantes) | — | — | — | — | — | ● 40 |
| Cânone versionado com hash | — | — | — | — | ◐ | ● 17 |
| Especificação nascida de diagnóstico do código real | — | — | — | — | — | ● |
| Interoperabilidade bidirecional entre formatos | — | — | — | — | — | ● |
| Open-source / comunidade | ● | ◐ | ● | ● | ◐ | — |
● SIM · ◐ PARCIAL · — NÃO
A última linha é fraqueza honesta: eles têm distribuição e comunidade; nós temos profundidade — e conversamos com as ferramentas deles nas duas direções.
Todo concorrente parte de descrição em linguagem natural. O nosso kit nasce de um diagnóstico do repositório real — validado em produção num repositório público.
stories executáveis — críticos com cláusula de hotfix e o guardrail que impede o agente de refatorar junto
detalhes de achado com a evidência do laudo transcrita, advisory por advisory
sensor de dependências EXECUTÁVEL de fábrica — gerado dos lockfiles reais do repositório
achados de evidência presumida viram perguntas: validar antes de corrigir
O time do cliente — ou o agente de código do cliente — abre o kit, roda o bootstrap e tem ordem de ataque, evidência e critério de pronto. Sem uma reunião de planejamento.
Laudo → kit de remediação: stories priorizadas com hotfix primeiro, evidência transcrita, gate de dependências pronto — e a cláusula que impede o júnior (ou o agente) de refatorar junto.
Trilha completa por construção: contrato assinado → evidência citável → sensor verde → aprovação independente imposta por hook. Nenhuma outra ferramenta produz essa trilha.
O laudo aponta, o kit executa: a distância entre o PDF e o backlog executável é um clique. Categoria que não existe nos concorrentes — nenhum tem motor de diagnóstico para partir dele.
Enquanto o mercado disputa quem escreve a melhor especificação antes do código, o ArchGenerator entrega a única que chega carregada de evidência do código real, com um processo que se verifica sozinho — e que ainda conversa com as ferramentas dos concorrentes nas duas direções.
A doutrina de qualidade que o kit carrega não é caixa-preta: o registry sdd-canon é público, versionado, com hash por arquivo e licença declarada em cada regra.
17 dimensões ancoradas em padrões públicos (WCAG, CWE Top 25, OWASP, Well-Architected) + rulepack SAST de 291 regras de 8 fontes permissivas.
Quem já usa Spec Kit, OpenSpec ou Kiro entra e sai com perda declarada — sem aprisionamento.
Atualizar o cânone no kit exige confirmação humana — um agente nunca passa sozinho.
Um laudo do seu repositório vira um kit executável — com as stories, os sensores e a evidência do seu sistema, não de um exemplo.