Governança universal de projetos

Missão: 2026-09-27-governanca-projetos

Versão: 1.2 · Estado: APROVADA pelo Pai em voz em 2026-09-27, pela ordem expressa de usar esta SPEC e prosseguir com a missão

Fontes: instruções do Pai nesta sessão; IDEATION.md; RESEARCH.md; cânone existente consultado.

1. Problema

A governança atual contém bons controles gerais, mas permite que uma tarefa longa avance do pedido diretamente para plano/protótipo sem ideação registrada, pesquisa explícita, SPEC aprovada, gates de autoridade e critérios de evidência apropriados. Isso permitiu iniciar implementação antes de transformar a intenção e as referências em contrato verificável. Também não existe mecanismo estabelecido de segunda revisão independente com Claude.

2. Resultado pretendido

Um protocolo universal, simplificado e modular, aplicável a projetos de qualquer domínio, no qual cada unidade de trabalho tem contrato documental antes de execução, autoridade do Pai é explícita, a execução ocorre por fases/sprints/subsprints e a conclusão só é declarada após validação real e conferência contra o escopo autorizado.

3. Requisitos normativos desta ordem

R1 — Classificação sem adivinhação

Se não estiver claro se a solicitação constitui projeto, o agente pergunta ao Pai antes de classificá-la ou iniciar fluxo de projeto. Dúvidas de intenção, gosto, escopo, prioridade, trade-off ou autonomia também são perguntas bloqueantes quando mudam resultado.

R2 — Autoridade explícita

O Pai conserva decisão de produto, intenção, gosto, prioridades, escopo e aceitação. O agente pode executar apenas ações necessárias e reversíveis dentro de escopo e autonomia declarados. A permissão para pesquisar não implica permissão para instalar; permissão para planejar não implica permissão para implementar; implementação não implica publicação, envio externo ou conclusão aceita. Nenhuma aprovação pode ser inferida do silêncio.

R3 — Ciclo mínimo obrigatório

Todo projeto, mesmo pequeno, percorre os registros mínimos: Ideação → Pesquisa/Exploração → SPEC → Plano da fase/sprint → Execução com estado → Validação → Fechamento e memória. Documentação é contrato antes, registro durante e evidência depois. A quantidade/profundidade interna pode ser proporcional; nenhuma etapa pode ser omitida sem ordem expressa do Pai.

R4 — Especificação antes de cada unidade executável

Antes de produzir o plano de uma fase/sprint, existe SPEC dessa unidade com objetivo, contexto/fontes, escopo incluído/excluído, requisitos, critérios de aceitação, autoridade/autonomia, dependências, riscos, validação e perguntas abertas. Pergunta que afeta interpretação bloqueia a unidade até resposta. Plano não pode ampliar SPEC.

R5 — Pesquisa após ideação

Pesquisar precedentes internos primeiro e fontes externas depois; explorar tecnologias e meios relevantes ao domínio, incluindo bibliotecas, dependências, linguagens, engines, soluções, plugins, MCPs e skills. Registrar fontes, atualidade, achados, alternativas, custos/limites, incertezas e o que não foi testado. Recomendações são opções para decisão do Pai quando alteram direção ou compromisso.

R6 — Decomposição modular

Decompor em fases e sprints; cada sprint pode conter subsprints ou tarefas quando risco/tamanho justificar. Cada unidade tem SPEC, plano, escopo autorizado, entregável, critérios pass/fail, evidências, rollback, checkpoint e estado. Nenhuma etapa subsequente começa com gate bloqueado.

R7 — Gates e evidências

Gates são bloqueios reais, tipados como: (a) decisão/aprovação do Pai; (b) verificação objetiva; (c) demonstração/revisão do Pai. O registro declara dono, entrada exigida, condição de saída, prova e estado. Alegação de worker/agente, checklist marcado ou descrição não substitui artefato/evidência. Gate não executado permanece aberto.

R8 — Teste de realidade

Validação verifica a implementação real em ambiente identificável. Os níveis e verificações exigidos são definidos na SPEC aprovada; não se omite nível por decisão do agente. Qualquer dispensa/N/A exige autorização explícita do Pai. Hipóteses podem ser exploradas na ideação, mas não contam como validação de entrega. Registrar comandos/ambiente, resultado, evidência e limitações.

R9 — Validação visual e aceitação

Interfaces e produtos visuais renderizáveis devem ser abertos e inspecionados no browser in-app do Codex no estado real, usando jornadas/interações previstas e capturas relevantes. Artefatos não renderizáveis nessa superfície devem ser exibidos em outra superfície apropriada do Codex, com dimensões e estado registrados. A revisão deve ser apresentada visivelmente ao Pai. Revisão do agente/Claude e captura técnica são evidência, não aprovação de produto. Se nenhuma superfície apropriada estiver disponível, o gate visual fica bloqueado; mostrar não significa aprovação.

R10 — Claude como verificador obrigatório

Claude revisa a saída de ideação, pesquisa, SPEC, plano, execução, validação e fechamento, incluindo cada sprint/subsprint, depois de reunidas as evidências daquela unidade e antes de avançar ou encerrá-la; começa por esta governança e pelo Tower Defense como primeira aplicação após ratificação explícita do Pai. É uma invocação separada do executor, com ferramentas desativadas, sem shell, subagentes ou persistência e com pacote mínimo. O parecer cita achados com localização/evidência, separa observação de inferência e pode abster-se. Se o executor também for Claude, ou se qualquer contexto adicional impedir isolamento, a chamada é segunda leitura, não revisão independente. A unidade fica bloqueada até isolamento ser provado ou o Pai aceitar explicitamente o risco daquela unidade; isso não transforma o rótulo em independente. Instalação/configuração, mudança de conta/privacidade, uso extra pago e conteúdo sensível não ficam autorizados por esta regra. Parecer de Claude não substitui teste real nem aprovação do Pai.

R11 — Honestidade de estado

Usar CONFIRMADO, PROVÁVEL, HIPÓTESE e NÃO IDENTIFICADO. Diferenciar concluído, em curso, bloqueado e aguarda-Pai. Não declarar “pronto”, “jogável”, “validado” ou “alinhado” sem critérios/evidências correspondentes.

R12 — Fechamento documental

Conferir cada requisito e gate contra escopo aprovado; atualizar STATE, diário e STATUS/MEMORY segundo os gatilhos existentes; registrar lições sem autoelogio; arquivar artefato rejeitado com lápide; executar o rito de Blog/sessão/sincronização vigente sem expor dados privados. Não apagar nem sobrescrever trabalho existente sem regra/autorização aplicável.

R13 — Revisão externa, dados e custo

A autorização de Claude como verificador é aplicada por missão: a SPEC daquela missão identifica o material que pode ser enviado para revisão, e a aprovação do Pai cobre somente o pacote mínimo descrito nela. Esta missão autoriza os documentos normativos necessários à auditoria, não histórico bruto, arquivos pessoais, credenciais, identificadores privados ou conteúdo confidencial. Sanitização exige checklist: (1) escopo/arquivos listados; (2) cópias congeladas fora do corpus; (3) secrets e identificadores varridos e removidos; (4) manifesto/SHA-256 conferidos localmente; (5) dados transmitidos e rota registrados. Conteúdo ambíguo fica fora e é apresentado ao Pai antes de envio.

O executor não habilita uso extra pago, troca conta, configura preferências de privacidade nem instala integração por inferência. O provedor processa o conteúdo remotamente; retenção/uso dependem do produto e da preferência da conta. Antes de cada chamada, registrar evidência disponível de autenticação/rota first-party e de que créditos API/extra usage não estão habilitados; após a chamada, registrar o estado/uso que a interface disponibilizar. A autorização do Pai para Claude cobre o uso incluído da conexão existente, não gasto adicional. Teto imposto pelo agente limita tecnicamente a chamada, mas não autoriza gasto. Se a rota incluída ou ausência de gasto extra não puder ser verificada previamente, bloquear chamada e seguir com as demais etapas independentes. Registrar custo medido ou, se houver apenas preço de lista, identificá-lo como estimativa, nunca como cobrança.

4. Fluxo normativo de adoção nesta casa

Para cada unidade: IDEAÇÃO/REFINO → G-CLAUDE → PESQUISA → G-CLAUDE → SPEC → G-CLAUDE → APROVAÇÃO DA SPEC PELO PAI → PLANO → G-CLAUDE → APROVAÇÃO DO PLANO/AUTORIZAÇÃO PELO PAI → EXECUÇÃO ↔ CHECKPOINTS/G-CLAUDE → VALIDAÇÃO REAL → G-CLAUDE → REVISÃO VISUAL DO PAI (produto visual) → ACEITAÇÃO DO PAI se exigida na SPEC → FECHAMENTO/G-CLAUDE.

Cada estado tem artefato mínimo e condição de entrada/saída. G-Claude ocorre no fim de cada etapa enumerada, não somente após a validação, e em cada sprint/subsprint, antes de avançar ou fechar; o parecer fica consultivo. Se isolamento não for comprovado, apenas o Pai pode aceitar, explicitamente para a unidade nomeada, o avanço baseado naquela segunda leitura não independente. A exigência de aceitação final do Pai é declarada por ele ao aprovar a SPEC. Resposta nova do Pai pode alterar escopo; mudança gera nova versão/registro da SPEC, nunca edição silenciosa de uma aprovação anterior.

5. Artefatos desta implementação

Artefatos da implementação: AGENTS.md; GOVERNANCE.md; docs/ops/runbooks/RUNBOOK-PROJETOS.md; templates IDEATION.md, RESEARCH.md, SPEC.md, EXECUTION-PLAN.md, SPRINT-PLAN.md, STATE.md; docs/ops/INDEX.md; missão e pareceres em docs/ops/missions/2026-09-27-governanca-projetos/; apresentação navegável SPEC.html. A revisão Claude 07 foi não independente, de cobertura parcial e não aprovou o pacote recebido. As correções verificáveis foram incorporadas e registradas, mas não receberam revisão Claude posterior. O uso exato da franquia segue NÃO IDENTIFICADO.

6. Dependências, riscos, validação, rollback e checkpoints

Dependências

• A governança existente (AGENTS.md, GOVERNANCE.md, RQP, Blog Governance) continua sendo fonte normativa, lida em conjunto com esta revisão aprovada.
• A revisão Claude usa pacote mínimo e sanitizado. O revisor declarou contexto extra nesta chamada; portanto, o parecer atual é NÃO INDEPENDENTE.
• Blog e corpus principal são repositórios distintos e exigem validação e sincronização próprias.

Riscos e respostas

Validação

1. Revisão Claude read-only; classificar independência conforme contexto declarado e flags observáveis.
2. Verificação local de consistência, encoding, links e diffs.
3. Executar o gate estrutural do Blog e inspecionar post e SPEC no browser in-app em 375 px e 1440 px.
4. Verificar a URL publicada e o commit remoto depois da sincronização.

Rollback e recuperação

• Toda alteração fica identificada em commits próprios e pode ser revertida por git revert <commit> no repositório correspondente, preservando histórico.
• Antes de publicação, descartar somente alterações desta missão usando os paths exatos; nunca resetar o workspace nem tocar na missão Hermes.
• Correção publicada vira novo commit; nunca reescrever histórico remoto.

Checkpoints e gates

Perguntas abertas

• Não há pergunta de intenção pendente para executar a formalização autorizada. Limitações observáveis de Claude, custo/uso ou superfície visual devem ser registradas como gates, sem inventar aprovação.

7. Não objetivos

• Não pesquisar/implementar o produto Tower Defense nesta missão; iniciar a missão própria após o fechamento dos gates desta governança aprovada.
• Não instalar ferramenta, plugin, dependência, skill, MCP ou CLI; usar o Claude CLI já disponível somente no modo read-only autorizado para revisar esta governança.
• Não reconfigurar Claude/Codex, permissões, autenticação, conta, billing ou rede.
• Não delegar ao Claude ou a outro agente as decisões que o Pai reservou para si.
• Não transformar BMAD integral em requisito; adaptar somente o que for aprovado e necessário.

8. Critérios de aceitação — em execução

Proveniência da ordem: sessão Codex Desktop voz, 2026-09-27. A ordem inicial estabeleceu a reestruturação documental, Claude como verificador e Tower Defense como primeira aplicação. Nesta retomada, o Pai aprovou explicitamente esta revisão v1.2 e autorizou sua execução. O ledger mede a sessão, mas o transcript não fornece timestamps individuais. Esta aprovação identifica a revisão v1.2; não aprova retrospectivamente evidências ou gates anteriores. Instalação/configuração, mudança de conta/privacidade e decisões de produto do jogo seguem fora do escopo.

Histórico da SPEC: v1.1 foi a primeira versão de execução e recebeu achados Claude; v1.2 incorpora requisitos de cadência, isolamento, autorização limitada de transmissão, retenção e custo. A v1.1 permanece no histórico Git; nenhum gate anterior é considerado aprovado retroativamente.