metacognition-framework

Ativar ao fim de entrega aprovada pelo qa-critic, antes de fechar o bloco. Nenhum bloco fecha sem documentação proporcional. Dispara compaction/note-taking. Genérico.

Núcleo SSoT do método metacognitivo reutilizável. Carregar quando precisar decompor um problema, validar antes de entregar, aplicar a cláusula anti-loop, resolver precedência de instruções, ou registrar checkpoint/transferência. O roteador (framework v2.3) decide QUANDO; este arquivo guarda o COMO. NÃO carregar para bate-papo casual.

Ativar ANTES de planejar/implementar quando o pedido é novo, vago, ou a spec pode estar rasa/limitada ao que o usuário já conhece. Faz elicitação PROFUNDA (várias perguntas, não uma) para extrair uma spec de nível sênior em QUALQUER domínio — dev, BI, BA, web, dados, regulado, ou o que for. Em v1.6.0 ganha sub-modo "mapeamento de processo" para processo de negócio (fluxo cross-funcional com gatilhos, donos, RACI, regras, handoffs, exceções). Entrega requirements.md sênior que alimenta o architect. NÃO implementa, NÃO decide arquitetura, NÃO audita código (isso é explorer). Genérico e agnóstico de domínio.

Aplicação SW/dados (ADR-023). Ativar quando o produto entregue precisa de validação SISTEMÁTICA — gold-set, métricas pass/fail, teste de regressão, reprodutibilidade (notebook de dados, modelo/ML, pipeline, produto que vai a produção). Distinto do qa-critic (adversarial, 1 turno): aqui é sistemático e reexecutável. NÃO ativar para script descartável, protótipo sem critério formal, ou no lugar do qa-critic adversarial. Ativado pelo product_type do mission-gate (ADR-022).

Aplicação SW/dados (ADR-023). Ativar quando o produto entregue tem INTERFACE humana (gui-app, CLI interativo, dashboard, notebook com visualização). Especifica a UX (ux-spec: fluxos, componentes, estados, critérios de aceite de UX) — é AUTOR de spec, NÃO constrói a GUI (isso é developer). A GUI é do PRODUTO, não do framework. NÃO ativar para pipeline headless, biblioteca sem UI, script sem interface. Ativado pelo product_type do mission-gate (ADR-022).

Ativar SEMPRE após o developer, antes de qualquer aprovação. Validação adversarial — hipótese default é que existe bug. Idealmente modelo diferente do developer. Genérico.

Ativar quando a tarefa é escrever/alterar código, fórmula, script, query ou transformação. Saída sempre passa por qa-critic. Genérico — a sintaxe específica vem da aplicação.

Núcleo SSoT da segurança de ações por EFEITO (allowlist + default-deny). Carregar antes de executar ou instruir QUALQUER ação que mude estado fora da leitura: shell, escrita, rede, git push/merge, exclusão, operação financeira/legal, mudança de permissão. Classifica por efeito (E1–E6), mapeia a tier (T1/T2/T3) e exige gate humano para T3 (irreversível + alto impacto). NÃO carregar para leitura pura ou bate-papo.

Ativar quando a decisão técnica afeta >1 arquivo, introduz dependência, muda contrato/modelo, ou há escolha de arquitetura. Decide e documenta (ADR) — NÃO implementa. Genérico.

"Ativar para trabalho de leitura longo, ruidoso ou paralelizável: varrer muitos arquivos, mapear código/dados existentes, auditar em lote, pesquisar fontes. READ-ONLY — nunca escreve nem corrige. Mesmo que a frase peça "explorar e corrigir", o explorer só REPORTA os achados; a correção é do developer. Retorna só o destilado ao orquestrador. NÃO usar para implementar, corrigir ou decidir arquitetura."

Ponto de entrada padrão. Ativar quando o usuário traz pedido novo, retoma projeto, pede status ou planejamento, ou há ambiguidade. Orquestra e delega — NUNCA escreve código de produção. Genérico, agnóstico de domínio.

NÃO ATIVAR — molde para criar uma APLICAÇÃO do framework (um domínio/contexto específico). Clonar, renomear, preencher description (gatilhos + exclusões), as skills de _shared a carregar, e o domínio. É assim que o framework genérico vira aplicável a qualquer contexto.