Governança

O manifesto perde valor se ficar restrito a uma apresentação inicial. Ele deve aparecer nos momentos em que o time toma decisões: definição, design, geração, revisão e aprendizado posterior ao lançamento.

Responsabilidades

Responsável	Obrigação principal
Produto	Estabelece a definição autorizada, o escopo, os resultados, as regras, os não objetivos e a evidência de sucesso; valida Jobs to Be Done e Job Stories quando são utilizados.
Design	Traduz o fundamento de produto em percursos coerentes com o modelo mental da pessoa e protege sua atenção; usa Job Stories quando permitem concretizar a situação.
Engenharia	Absorve complexidade e garante estados, desempenho, acessibilidade e recuperação.
Agente de IA	Planeja e implementa dentro do fundamento e do contrato; declara suposições, mantém cobertura e não reduz nem amplia escopo por iniciativa própria.
Revisão humana	Avalia causalidade, sentido, risco, experiência completa e evidência; não se limita a revisar código.

Pontos de controle

Momento	Decisão requerida
Antes de projetar	Fontes, autoridade, escopo, resultados, evidência, suposições e não objetivos estão claros; as Job Stories são compreendidas quando existem.
Antes de gerar código	O plano cobre a definição completa e estabelece dependências, resposta escolhida, rotas, estados, regras críticas, riscos e aceitação.
Durante a construção	A decomposição organiza o trabalho sem alterar o escopo; bloqueios, pendências e exceções permanecem visíveis.
Antes de integrar	Cada mudança conserva rastreabilidade com seu fundamento, respeita o escopo, cobre estados e passa nos testes técnicos.
Antes de liberar	A implementação completa demonstra resultados, cobertura, compreensão, controle e qualidade de experiência.
Depois de liberar	Observam-se resultado, atrito, abandono e erros; revisam-se o fundamento, as histórias e suas suposições quando couber.

Os princípios devem ser estáveis; as regras e os testes podem evoluir com novas evidências. Toda mudança deveria registrar o problema observado, a decisão modificada e a razão. A estrutura não deve crescer por acumulação: uma regra nova só é incorporada se resolver uma lacuna que as existentes não cobrem.

Controle de mudanças das versões 2.0 e 2.1

A versão 1.0 permanece como formulação fundacional. A versão 2.0 conserva sua tese e seus dez princípios, mas substitui referências operacionais genéricas a Jobs to Be Done por uma cadeia mais concreta e verificável.

Área	Ajuste da versão 2.0	Conteúdo que permanece
Unidade de design	A Job Story concretiza o progresso no contexto de Jobs to Be Done.	O progresso da pessoa continua sendo a medida principal.
Arquitetura	Incorpora-se um nível entre princípio e regra.	Princípios, regras e testes conservam sua função.
Fluxo e artefatos	Exigem-se circunstância, motivação, resultado e evidência antes de projetar.	Mantém-se a documentação mínima que muda decisões.
Desenvolvimento com IA	O agente deve reformular e respeitar a Job Story.	Continuam os limites, o determinismo e a revisão humana.
Aceitação	O resultado é testado sob a circunstância descrita.	Acessibilidade, desempenho, estados e controle seguem obrigatórios.
Exemplo e governança	Acrescentam-se rastreabilidade causal e validação de histórias.	O tutor de cálculo e os pontos de controle conservam seu propósito.

A versão 2.1 preserva a tese, os dez princípios, a doutrina para IA, as Job Stories e o exemplo aplicado. Amplia o núcleo para admitir definições de produto de forma, extensão e profundidade distintas, sem impor uma estrutura a montante nem supor uma estratégia incremental.

Área	Ajuste da versão 2.1	Conteúdo que permanece
Fundamento	Define-se uma base autorizada, rastreável e verificável, que pode assumir formas distintas.	O progresso humano continua como medida principal.
Job Stories	Declaram-se forma de referência, e não estrutura universal obrigatória.	Conservam-se sua forma canônica, evidência, testes e exemplos.
Escopo	Exige-se cobertura completa e proíbem-se omissões ou adiamentos não autorizados.	Produto segue definindo escopo e não objetivos.
Planejamento	Separam-se decomposição, sequência e paralelismo de qualquer decisão de escopo.	Continuam a clareza prévia, as regras, os riscos e a aceitação.
Estratégia de entrega	A incrementalidade deixa de ser uma suposição do núcleo.	Cada projeto pode adotar fases ou releases quando couber.
Implementação SDD	Reserva-se para anexos e adaptadores independentes.	O núcleo conserva princípios e garantias que toda implementação deve respeitar.

Um desenvolvimento está completo quando todos os elementos obrigatórios da definição de produto têm uma implementação e uma evidência verificável, ou uma exceção explícita e aprovada; quando as pessoas alcançam os resultados previstos sob as condições definidas; e quando o comportamento do sistema e a qualidade da experiência foram verificados com rigor proporcional ao risco.

Quando o fundamento inclui Job Stories, a verificação deve demonstrar o resultado em suas circunstâncias. A completude inclui código correto, mas não termina aí. Exige cobertura do escopo, integração entre suas partes, estados críticos confiáveis, uma experiência que não obrigue a aprender a arquitetura do produto, IA dentro de limites explícitos e clareza sobre o que deve ser observado depois do lançamento.