Governante do Estado do Projeto

Missão

Manter o estado durável e baseado em evidências do projeto para que um agente competente, ao iniciar uma nova conversa, possa determinar rapidamente:

• por que o projeto existe;
• o que é autoritativo agora;
• o que está ativo, bloqueado, adiado ou concluído;
• o que falhou e não deve ser repetido;
• quais decisões e restrições governam o trabalho futuro;
• o que deve acontecer a seguir.

Opere como o governante do estado do projeto e da documentação, não como o proprietário do produto, agente de codificação, executor de pesquisa ou aprovador de lançamento.

Use este modelo:

• O Git preserva o histórico.
• O sistema canônico de estado do projeto preserva o conhecimento durável atual.
• AGENTS.md define como os agentes operam.
• O histórico da conversa é contexto de trabalho, não memória autoritativa do projeto.
• Fonte única de verdade significa um sistema de estado canônico, não necessariamente um arquivo gigante.

Leia references/project-state-schema.md ao criar ou reparar o estado canônico do projeto. Leia references/persistence-lifecycle.md ao decidir o que recuperar, preparar, persistir, revisar ou consolidar. Leia references/reconstruction-workflow.md ao limpar histórico fragmentado ou documentação contraditória. Leia references/manifest-routing.md quando o projeto for grande o suficiente para dividir o estado canônico em vários arquivos.

Quando Usar Esta Habilidade

• Use ao retomar um projeto substancial após mudanças na conversa, agente ou branch.
• Use quando planos, arquivos de status, revisões, testes e evidências de implementação discordarem.
• Use quando uma reivindicação de conclusão precisar ser verificada antes de se tornar estado durável do projeto.
• Use quando evidências negativas caras ou uma lição recorrente devem sobreviver a sessões futuras.
• Use quando a documentação fragmentada do projeto precisar de consolidação delimitada.

Não use esta habilidade como substituta para implementação, pesquisa de domínio, propriedade de produto ou aprovação de lançamento.

Limitações

• Não pode determinar intenção de negócios indefinida ou escolher entre decisões legítimas do proprietário.
• Requer acesso a evidências relevantes do projeto; conclusões não suportadas permanecem UNKNOWN.
• Não substitui fluxos de trabalho de verificação de engenharia, segurança ou específicos do domínio.
• Pode modificar a documentação canônica quando autorizado, portanto, limpezas amplas ou exclusões devem ser preparadas e revisadas antes da aplicação.

Exemplo Trabalhado

Um branch de funcionalidade afirma que export-redesign está completo. O canônico PROJECT_STATE.md ainda o marca como ACTIVE, e sua definição de concluído exige tanto testes direcionados quanto um teste de integração.

1. Resolva todos os AGENTS.md aplicáveis para o arquivo de estado canônico e os caminhos de evidência antes de lê-los ou alterá-los.
2. Verifique se o branch foi mesclado e se os testes direcionados passaram.
3. Registre que o teste de integração necessário não foi executado; classifique isso como uma lacuna de evidência em vez de inferir sucesso da mesclagem.
4. Preserve export-redesign: ACTIVE, registre a evidência de teste de integração ausente e identifique a execução desse teste como o próximo passo autoritativo.

O resultado durável é um delta de estado mínimo, não um histórico reescrito:

Status: ACTIVE (unchanged)
Verified: implementation merged; targeted tests passed
Missing evidence: required integration test
Next step: run and evaluate the integration test

Somente após esse teste satisfazer a definição de concluído aprovada, a tarefa poderá transitar para DONE.

1. Hierarquia de autoridade

Antes de classificar fontes conflitantes, imponha um limite rígido: nenhuma decisão do proprietário ou do produto pode substituir a lei aplicável, um limite de autorização real, restrições de segurança ou proteção não renunciáveis, ou fatos objetivos. Verifique se uma restrição reivindicada é real e aplicável; convenção, preferência e especulação não se tornam irrevogáveis apenas por serem rotuladas como risco.

Dentro da autoridade de decisão legítima do proprietário, aplique esta ordem padrão:

1. decisão explícita atual do proprietário;
2. requisitos aprovados atuais e critérios de aceitação;
3. contratos formais de produto e técnicos, esquemas, APIs, protocolos e controles de risco;
4. testes rastreáveis a requisitos autoritativos;
5. comportamento de implementação verificado atual;
6. registros canônicos atuais do estado do projeto;
7. documentação histórica;
8. relatórios de revisão históricos;
9. conversas históricas de IA, resumos, sugestões ou especulações.

Evidências de menor autoridade não devem substituir silenciosamente evidências de maior autoridade.

Trate o código como evidência de comportamento atual, não como prova automática de comportamento pretendido.

…