Registro de mandatos transversais (CM-1–CM-28)

Registro canônico dos mandatos transversais. Este documento carrega o corpo completo do registro de CM-N; as enumerações substantivas ficam aqui e são operacionalizadas pelos arquivos de regras em src/apothem/rules/. Toda sessão que precisa do corpo detalhado de CM-N carrega este documento sob demanda.

Isenção de autorreferência do registroCopy Anchor Link

Este documento É o registro canônico de CM-N — é a fonte em que os tokens CM-1 a CM-28 são definidos. Repetir esses tokens dentro do próprio corpo do registro é canônico, e não um vazamento de terminologia interna aos planos. O invariante de isolamento da base de código continua a valer com força total para todos os demais artefatos que não são documentação publicada (regras, auxiliares, comandos, hooks, schemas, scripts, ferramentas, testes, README, CONTRIBUTING, changelogs, assuntos/corpos de commits, nomes de branches, títulos/descrições de PR): nenhum token CM-N / TM-N / CP-N, apenas linguagem natural do domínio.

As páginas de documentação publicada em site/content/docs/ podem citar um mandato pelo seu id CM-N, porque este registro e a página de referência de regras definem esses ids para os leitores. Uma página que cita um id DEVERIA nomear o mandato em palavras simples ao lado dele, e NÃO DEVE citar números de seção internos ao plano de um mandato. Os tokens TM-N e CP-N ficam fora da documentação publicada, assim como os demais termos proibidos no bloco de CM-7 abaixo.

NamespacesCopy Anchor Link

CM-N = mandato de configuração (definido aqui, ou em src/apothem/rules/*.md conforme a tabela de regras em site/content/docs/reference/rules.mdx); TM-N = mandato de template (definido em src/apothem/skills/plan-suite/master-template.md §4 "General Mandates", TM-1–28); CP-N = princípio central (definido no mesmo template, §6 "Core Principles", CP-1–27). O template da suíte de planejamento é o registro canônico de TM/CP — os comandos /plan resolvem as referências cruzadas por meio desse arquivo. Os artefatos auxiliares (regras, auxiliares, comandos, hooks) citam este registro por referência.

AtivaçãoCopy Anchor Link

CM-1–10 + a identidade cognitiva regem todas as interações. CM-11, CM-13 (subregras A a C), CM-15, CM-16, CM-20 se aplicam somente dentro do pipeline /plan. A subregra D de CM-13 se aplica a toda escrita no git, e a subregra E aos destinos de git mv / git rm e aos caminhos no corpo de commits, dentro ou fora desse pipeline. CM-12, CM-14, CM-17–19, CM-21–22, CM-24–26 se aplicam universalmente. CM-23, CM-27, CM-28 se aplicam universalmente dentro do escopo de filtro de caminhos que declaram. Nível de seriedade padrão ad hoc: PERSONAL_USE. Um mandato rege independentemente de sua regra ser carregada na inicialização: quatro regras são carregadas em toda sessão (agnostic-posture, authority-inquiry, session-closure, context-management), e as demais são carregadas em um caminho correspondente, por meio do índice de regras ou por meio de uma regra, skill ou comando que as cite.

CM-1–10 (Operacionais)Copy Anchor Link

(1) Avaliação crítica (→TM-10), (2) Zero suposições (→TM-1), (3) Orientado por configuração (→TM-2), (4) Pesquisar antes de implementar (→TM-4), (5) Melhor solução (→TM-7), (6) Autoaperfeiçoamento (→CP-20), (7) Produto coerente (→TM-11), (8) Foco no gargalo primeiro, (9) Velocidade de decisão, (10) Honestidade brutal. Definições completas com indicadores de violação: src/apothem/rules/operational-mandates.md.

CM-7 (Isolamento do que é interno ao plano)Copy Anchor Link

Esta é a faceta de CM-7 voltada à base de código; a faceta de completude do produto está documentada como Produto coerente (→TM-11) em src/apothem/rules/operational-mandates.md §CM-7. Os dois rótulos se referem ao mesmo mandato.

Os artefatos da base de código NUNCA devem conter referências internas aos planos. Termos proibidos (bloco canônico — os consumidores irmãos fazem referência cruzada a esta enumeração): TM-N, CM-N, CP-N, "Resumption Contract", "Phase Output Registry", "convention anchors", nomes de pastas de fase, nomes de arquivos da suíte de planejamento (PROGRESS.md, PLAN-NOTES.md, PREAMBLE, MASTER-PLAN), nomes de níveis de seriedade (EXPLORING, PERSONAL_USE, SHARED, PUBLIC_LAUNCH). Artefatos protegidos: código-fonte, testes, configurações, schemas, scripts de build, dados, assets, mensagens de commit, nomes de branches, títulos/descrições de PR, README, CONTRIBUTING, documentação de API, changelogs — qualquer artefato visível fora da árvore de código-fonte do Apothem (os destinos de instalação por harness, como ~/.claude/ para o Claude Code). Apenas linguagem natural do domínio. A única exceção é a documentação publicada em site/content/docs/, que pode citar ids CM-N conforme descrito na isenção de autorreferência do registro acima. Consumidores irmãos (cada um cita este bloco por referência em vez de enumerá-lo de novo): src/apothem/hooks/messages/pretooluse-bash.md, src/apothem/hooks/messages/pretooluse-write.md, src/apothem/hooks/messages/pretooluse-edit.md, src/apothem/hooks/messages/pretooluse-notebookedit.md, src/apothem/rules/operational-mandates.md §CM-7 indicadores de violação.

CM-11 (Integridade do plano)Copy Anchor Link

A — Fidelidade à prosa: Todo requisito é rastreável prosa↔plano. Scorecard: PASS ≥90% STRONG/0 ABSENT. B — Consistência interna: Coerência entre os documentos da suíte de planejamento. Scorecard: PASS 100%. C — Portões: FAIL bloqueia a execução em SHARED+ (a anulação pelo Product Owner é permitida em SHARED, com justificativa registrada; bloqueio rígido em PUBLIC_LAUNCH). Consultivo em PERSONAL_USE.

CM-12 (Administração do contexto)Copy Anchor Link

Gestão enxuta do contexto o tempo todo — consulte a regra CM-24. Quatro subníveis estão enumerados na seção Convenção de subreferências, abaixo. A disciplina de compactação (CM-19) rege o ato de compactar; CM-12 rege a disciplina em regime permanente.

CM-13 (Commits)Copy Anchor Link

• A — Cadência por tarefa: Por tarefa em SHARED+. Por fase em PERSONAL_USE. Opcional em EXPLORING.
• B — Commits de qualidade/remediação: As correções de portões de qualidade e as mudanças de remediação recebem commit imediatamente, separadas do trabalho de funcionalidades.
• C — Portão de fim de fase: Nenhuma mudança sem commit atravessa os limites de fase. O isolamento de CM-7 se aplica a todos os artefatos git. Em PUBLIC_LAUNCH: commits assinados com GPG (git commit -S) são obrigatórios.
• D — Autoria exclusivamente humana: Toda superfície de autoria em todo artefato git (assunto do commit, corpo do commit, Author:, trailer Co-Authored-By:, trailer Signed-off-by:, nome de branch, nome de tag, anotação de tag, nome de stash, corpo de git-notes, título de PR, descrição de PR) nomeia somente contribuidores humanos. O assistente nunca se atribui, nem atribui o modelo de linguagem subjacente, o runtime / harness / IDE / extensão / fornecedor ou qualquer outra ferramenta automatizada, a nenhuma dessas superfícies. Os padrões proibidos são enumerados e aplicados mecanicamente em src/apothem/rules/production-ready-prs.md §6 (Commit-Message Discipline → Human-only authorship), com o matcher em src/apothem/hooks/messages/pretooluse-bash.md Scan 3 disparando a cada invocação Bash que escreve no git.
• E — Disciplina de prefixo numérico nos destinos de git-mv / git-rm: Os prefixos numéricos (NN-) em caminhos do sistema de arquivos transmitem ordenação e se aplicam somente onde a ordenação é intrínseca — sequências de pastas de fase, sequências de subfases, esquemas de nomenclatura ordinal descobertos pelo host. Singletons de nível raiz que não têm sequência irmã não levam prefixo numérico; adicionar um é decoração sem sentido que sinaliza erroneamente uma relação de ordenação que não existe. Especificação completa em src/apothem/rules/canonical-layout.md §2.1. Aplicada mecanicamente em src/apothem/hooks/messages/pretooluse-bash.md Scan 2 sobre git mv / git rm e sobre as referências a caminhos no corpo do commit.

CM-14 (Protocolos de sessão)Copy Anchor Link

Início: Executar o Blind Bootstrap (CM-24 §6). Fim: Executar o Phase Exit (CM-24 §2.5) + avaliação de memória (CM-26) + evolução de artefatos (CM-22 §2+§4).

CM-15–21 (Pipeline)Copy Anchor Link

CM-15 e CM-16 são definidos em linha aqui (sem regra separada); CM-17–21 são delegados a regras conforme a tabela de regras em site/content/docs/reference/rules.mdx. O título agrupa esses mandatos por tema; o escopo deles segue o parágrafo Ativação: CM-15, CM-16 e CM-20 se aplicam somente dentro do pipeline /plan, e CM-17–19 e CM-21 se aplicam universalmente.

• CM-15 Coerência coletiva: Verificar se os artefatos do plano permanecem coerentes após uma modificação.
• CM-16 Execução autônoma: Em SHARED+, nunca parar entre fases. Compactação obrigatória nas transições de fase (PERSONAL_USE+).
• CM-17 Equipes de trabalhadores: Implantar equipes de trabalhadores delegados para trabalho paralelizável — consulte a regra CM-25.
• CM-18 Recuperação de erros: Seis classes gerais (CM-24 §8); as classes de execução de planos estão em TM-18. Escalar após 3 falhas.
• CM-19 Disciplina de compactação: Gatilhos de compactação proativa — consulte CM-24 §3.
• CM-20 Orquestração do pipeline: prose→[approval]→generate→[approval]→review→[approval]→execute(01→NN). Técnicas de revisão: src/apothem/rules/planning-techniques.md.
• CM-21 Qualidade criativa: Os filtros cognitivos são portões de qualidade, não decoração. Escalonamento conforme a regra de identidade cognitiva, §2.

CM-22–28 (Delegados a regras)Copy Anchor Link

Âncoras de uma linha para os mandatos delegados a regras (as especificações completas ficam nos arquivos citados):

• CM-22 Vigilância de convenções — convenções do ecossistema e evolução proativa de artefatos. Consulte src/apothem/rules/persistent-conventions-vigilance.md.
• CM-23 Geração de arquivos grandes — protocolo de anexação incremental para arquivos acima do limiar de escrita única. Consulte src/apothem/rules/large-file-generation.md.
• CM-24 Protocolo de administração do contexto — externalização, compactação, blind bootstrap e disciplina de orçamento. Consulte src/apothem/rules/context-management.md.
• CM-25 Orquestração de trabalhadores — padrões de implantação, contratos de retorno, isolamento de contexto. Especificação completa na regra de orquestração de trabalhadores.
• CM-26 Ciclo de vida da memória automática — disciplina de memória, organização de arquivos por tópico, avaliação de fim de sessão. Consulte src/apothem/rules/auto-memory.md.
• CM-27 Camadas de arquitetura limpa — separação Domain / Application / Infrastructure / Presentation. Consulte src/apothem/rules/clean-architecture-layers.md.
• CM-28 Arquiteto sênior de Python — salvaguardas de SOLID, estilo, testes e segurança para artefatos Python. Consulte src/apothem/rules/code-craft-python.md.

Mandatos delegados a regras vs. definidos em linhaCopy Anchor Link

• Delegados a regras (especificação completa em src/apothem/rules/): consulte a coluna "Implements" da tabela de regras em site/content/docs/reference/rules.mdx. Abrange CM-1–10, CM-12, CM-14, CM-17–28.
• Definidos em linha (especificação completa aqui, sem regra separada): CM-11 (Integridade do plano), CM-13 (Commits; as subregras D e E citam arquivos de regras para sua especificação detalhada), CM-15 (Coerência coletiva), CM-16 (Execução autônoma).

Convenção de subreferênciasCopy Anchor Link

Os comandos usam sufixos de letra para referenciar subseções específicas dentro dos mandatos. Padrão: CM-N + letra de sufixo = seção da regra. Convenção de maiúsculas e minúsculas: Os sufixos maiúsculos denotam subseções estruturais dentro de um mandato; os sufixos minúsculos denotam diretivas mais granulares dentro de um nível de administração. A tabela canônica de mapeamento de chaves de subreferência (definições internas ao registro) está no bloco delimitado abaixo:

CM-11A = Prose Fidelity
CM-11B = Internal Consistency
CM-11C = Gates

CM-12a = lean ingestion / demand loading (context-management §7.2)
CM-12b = budget awareness (§7.1)
CM-12c = budget pressure response (§7.3)
CM-12d = per-task effort calibration (context-management §7.4 — D3 stratified taxonomy; PHASE.md frontmatter is the per-phase override surface)

CM-13A = per-task commits
CM-13B = quality / remediation commits
CM-13C = end-of-phase commit gate
CM-13D = human-only authorship
CM-13E = numeric-prefix discipline on git mv / git rm targets

CM-23A = pre-generation size assessment (§1)
CM-23B = incremental generation protocol (§2)

CM-24B = proactive externalization (§2)

CM-25A = worker-team patterns (§1)
CM-25C = return-contract enforcement (§4)
CM-25E = isolation / non-duplication (§5)