A especificação orienta.
O processo verifica.
O Kit SDD conecta especificações a stories, contratos e verificações executáveis. Ajuda suas equipes e agentes de código a seguir o que foi acordado e registrar evidências de cada entrega.
KIT .SDD/ A PARTIR DE LAUDOS COMPATÍVEIS OU DO CRIAR SPEC
Referência do Kit SDD 3.1.0. Papéis e dimensões conferidos no código. Resultados de mutação, aplicação das regras e calibração documentados em 13/08/2026.
Por que agora
Três forças convergiram entre 2025 e 2026 — e transformaram a especificação governada de boa prática em requisito.
Gerar código ficou barato. Gerar o código certo, não.
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.
Agentes precisam de memória de processo.
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.
Auditabilidade virou requisito de negócio.
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.
Um processo que sua equipe pode executar
O kit inclui ferramentas Python baseadas na biblioteca padrão para verificar o processo dentro do repositório.
Verificações de integridade do próprio .sdd: seções obrigatórias, limites de contrato e rastreabilidade de afirmações que ainda precisam de validação.
Nos ambientes com suporte aos hooks, eles restringem que quem implementou aprove o próprio trabalho ou preencha suas evidências de QA. Os papéis e seus limites ficam explícitos.
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.
Como avaliar uma abordagem SDD
Além de escrever a especificação, vale perguntar como cada ferramenta conecta contexto, execução e verificação. Estes são os critérios que orientam o Kit SDD do ArchGenerator.
| O que avaliar | Como funciona no ArchGenerator |
|---|---|
| Especificação antes do código | Especificações, critérios de aceite e plano de execução antes da implementação. |
| Papéis multi-agente | Papéis separados para planejar, implementar, revisar e aprovar. |
| Autoridade imposta por mecanismo (hooks) | Hooks limitam ações de acordo com o papel responsável. |
| Contratos de implementação assinados | Cada story tem escopo, artefatos e verificações acordados no contrato. |
| Sensores executáveis com registry em dados | sensors.yaml registra comandos, critérios e condições de bloqueio. |
| Evidência graduada por afirmação [A]/[P]/[Q] | Cada afirmação distingue evidência, hipótese ou questão em aberto. |
| Processo que verifica a si mesmo (mutantes) | Testes de mutação verificam se os sensores identificam falhas introduzidas. |
| Cânone versionado com hash | canon.lock fixa a versão e os hashes das referências de qualidade. |
| Especificação nascida de diagnóstico do código real | O diagnóstico do repositório alimenta histórias, evidências e verificações. |
| Interoperabilidade bidirecional entre formatos | Importação e exportação para Spec Kit, OpenSpec e Kiro, com perdas documentadas. |
| Open-source / comunidade | O registro sdd-canon é público; a plataforma ArchGenerator é um produto comercial. |
O ecossistema evolui. Compare os recursos disponíveis na versão que sua equipe usa e escolha os mecanismos adequados ao seu contexto.
Explore também as documentações oficiais de outras abordagens:
O kit nasce de prova, não de prompt
O kit também pode partir do diagnóstico de um repositório real. Este exemplo documentado conecta achados de segurança a stories e verificações de correção.
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.
Três situações reais
"Herdei um sistema legado com dezenas de vulnerabilidades e um time júnior."
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.
"A auditoria perguntou como governamos código gerado por IA."
Contratos por story, evidências consultáveis, sensores executáveis e revisão independente: um registro do processo que ajuda a responder à auditoria.
"O consultor entregou o diagnóstico e foi embora — e agora?"
O laudo pode se tornar um kit de implementação com prioridades, evidências e critérios de aceite. Suas equipes recebem um ponto de partida para executar as recomendações.
O Kit SDD conecta a especificação e as evidências do código a um processo verificável, preservando a interoperabilidade com as ferramentas da sua equipe.
O cânone é público
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 de qualidade baseadas em referências públicas (WCAG, CWE Top 25, OWASP, Well-Architected), com um conjunto versionado de regras SAST de fontes com licenças 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.
Veja o kit nascer do seu próprio código.
Nos laudos compatíveis e com o recurso habilitado, as recomendações do seu repositório podem dar origem a um kit executável, com stories, critérios e verificações apoiados nas evidências do sistema.