Skip to content
Apothem
Governança

Registro de conformidade externa — Ao operar sobre projetos anfitriões

Registro de quinze mandatos (M1–M15) que especifica os requisitos de conformidade para todos os artefatos gerados em projetos anfitriões, com mapeamento cruzado para os mandatos internos do ecossistema.

Registro canônico dos quinze mandatos de produção. Este documento carrega o registro completo de quinze mandatos (M1–M15), a ratificação do limiar trivial versus não trivial, a política de mapeamento cruzado M↔CM e o protocolo de introdução de mandatos; as enumerações substantivas vivem aqui, operacionalizadas pelos arquivos de regra de cada mandato.

Quando este ecossistema gera, edita, retrabalha, adapta, estende ou remove qualquer artefato em um projeto anfitrião (o alvo de invocação do usuário — repositório git, árvore de documentação, corpus de pesquisa, manifesto de infraestrutura, bloco de notas), cada artefato produzido atende ao padrão de quinze mandatos (M1–M15) declarado abaixo. Isto é inegociável e se aplica a toda superfície do ecossistema (auxiliar, assistente, comando, hook, resposta, diff, mensagem). A aplicação é o portão de pré-emissão (veja site/content/docs/governance/pre-emission-gate-registry.mdx); a aplicação da fração mecânica vive em src/apothem/conformity/*-grep.py, orquestrada por src/apothem/conformity/gate.py.

Os quinze mandatos operam ao lado dos mandatos CM-N segundo a política de vocabulário paralelo (veja site/content/docs/governance/cross-cutting-mandates.mdx); M e CM são dimensões de governança ortogonais (M é o eixo externo — artefatos de projetos anfitriões; CM é o eixo interno — artefatos internos do ecossistema). Cada regra listada abaixo é o lar canônico do seu mandato; este registro é o índice.

IDMandatoResumo em uma linhaRegra canônica
M1Agnosticismo quanto ao projeto anfitriãoDescubra a pilha / formatador / linter / disposição / idiomas do anfitrião; honre-os; traga o silêncio à tona como consulta segundo M5 com anotação M7src/apothem/rules/host-discovery.md
M2Disciplina editorialRevele cada emenda / extensão / refinamento com justificativa; sem cumprimento excessivo silencioso, sem extrapolação silenciosasrc/apothem/rules/disclosure-ledger.md
M3Dez dimensões de qualidadeCada artefato passa na verificação de dez pontos (rigor, coerência, configurabilidade, legibilidade, orfandade, estruturalidade, arquitetura, nomenclatura, referenciamento acadêmico, exemplos/testes/documentação)src/apothem/rules/ten-dimension-check.md
M4AutoaplicaçãoExecute o portão de pré-emissão de quinze pontos antes de cada emissão de escopo significativo; registre a prova de publicaçãosrc/apothem/rules/pre-emission-gate.md
M5Princípio de autoridadePergunte, não invente; dados de identidade / escopo / preferência / segurança / nomenclatura / infraestrutura / fixação de versão nunca são fabricadossrc/apothem/rules/authority-inquiry.md
M6Incorporação de expertiseLeia a intenção, emende proativamente, estenda sobre lacunas adjacentes, refine com justificativa citada, antecipe consequências de segunda ordemsrc/apothem/rules/expertise-posture.md
M7Anotação de opçõesToda escolha de múltiplas opções carrega um marcador de recomendação mais uma justificativa vinculada a princípios; escolhas silenciosas são proibidas em território autoritativosrc/apothem/rules/option-annotation.md
M8Definitividade e hermeticidadeSem hesitação onde uma prescrição vinculante for possível; sem "depende" sem ramos enumerados; cada contrato tem condições prévias / posteriores / de falhasrc/apothem/rules/definitiveness.md
M9Alavancagem visualO tema estrutural carrega um diagrama de realidade atual (Mermaid por padrão) com proveniência + data de verificaçãosrc/apothem/rules/visual-leverage.md
M10Vinculação bidirecionalElementos estruturais substantivos declaram vínculos recíprocos (Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔)src/apothem/rules/bidirectional-binding.md
M11Sprints ágeisTrabalho não trivial de múltiplas etapas é executado como sprints disciplinados (Objetivo / Backlog / DoR / DoD / Revisão / Retrospectiva)src/apothem/rules/agile-sprints.md
M12Relatórios de fase e disposição canônicaTrabalho de múltiplas fases emite relatórios por subfase + um resumo no nível de fase; saídas na disposição canônicasrc/apothem/rules/canonical-layout.md
M13Ofício de códigoComentários de por-quê-não-o-quê; nomes reveladores de intenção com unidades; tratamento de exceções tipado; constantes nomeadas; honre o linter / formatador / verificador de tipos do anfitriãosrc/apothem/rules/code-craft-{python,shell,markdown,conventions}.md (por linguagem)
M14Sistemicidade do ecossistemaNovos componentes declaram ascendentes / descendentes / pares / aplicadores; indexados nos registros do anfitrião; sem silos nem órfãos introduzidossrc/apothem/rules/systemic-participation.md
M15Forma pronta para produçãoMudanças de código são entregues com testes + documentação + entrada no CHANGELOG + mensagem de commit conforme + CI em verde no mesmo conjunto de mudançassrc/apothem/rules/production-ready-prs.md

1. Limiar trivial versus não trivial (resolvido)

O limiar que separa o trabalho trivial do não trivial — trabalho não trivial aciona o aparato M11 + M12 — é um híbrido de contagem de linhas + escopo: uma mudança é trivial quando é uma edição de arquivo único de ≤ 5 linhas E não introduz nenhuma mudança na superfície da API pública E nenhuma mudança de comportamento. Qualquer outra coisa é não trivial. Resolvido uma única vez segundo a disciplina de resolver-uma-vez de M5; o limiar vive aqui no escopo de usuário e é sobrescrito apenas por uma declaração explícita de escopo de projeto que honre a descoberta do anfitrião de M1 (p. ex. um <project>/.claude/CLAUDE.md para Claude Code, ou a superfície por projeto equivalente para outro harness).

2. Mapeamento cruzado M↔CM

Cada corpo de regra numerada M declara seu mapeamento cruzado CM-N em linha (em seu vínculo Cross-bound with ↔) usando a política de vocabulário paralelo: onde um mandato M tem seu análogo CM-N mais próximo, ambas as regras se aplicam onde ambas se aplicarem (sem substituição). Os mapeamentos são intrínsecos aos corpos das regras; este registro resume a política de eixo sem duplicar a tabela de mapeamento.

3. Protocolo de introdução de mandatos

Adicionar um novo mandato numerado M (p. ex., um futuro M16) é uma mudança empacotada. O pacote alcança o registro apenas quando cada componente abaixo está presente no mesmo conjunto de mudanças. Adições silenciosas — uma nova linha M na tabela do registro sem o pacote de apoio — produzem deriva do eixo de mandatos e são não conformes segundo a participação sistêmica M14.

Componente exigidoPropósitoOnde aterrissa
Linha do mandato na tabela do registroNomeia o mandato, seu resumo em uma linha, sua regra canônicaA tabela deste registro acima
Célula de mapeamento cruzado CM-NDeclara o análogo CM-N mais próximo (ou marca (no direct CM-N analog) como eixo novo) segundo a política de vocabulário paralelo de §2A linha Cross-bound with ↔ da nova regra
Corpo da regra canônicaA especificação substantiva do mandato (Condições prévias / Comportamento exigido / Superfície de divulgação / Indícios de falha / Vínculos de cinco direções)src/apothem/rules/<mandate-name>.md
Linha do portão de pré-emissãoNomeia o tipo de verificação da barra (mecânica / racional / mista) e seu Failure → actionA tabela do registro do portão de pré-emissão (site/content/docs/governance/pre-emission-gate-registry.mdx)
Superfície de aplicaçãoSeja um grep mecânico em src/apothem/conformity/<name>-grep.py orquestrado por gate.py, OU uma declaração explícita de barra racional com a âncora de autoverificação do operadorsrc/apothem/conformity/ (mecânica) ou a linha do portão marcada como reasoned (autoverificação do operador)
Fixture de conformidadeUm fixture sob tests/conformity-scenarios/fixtures/F-<N>-<name>/ que exercita os modos de falha do mandato; a lista de mandatos do verificador é atualizada para incluir a nova barratests/conformity-scenarios/
Atualização do esquema de prova de publicaçãoO bloco bars: da prova de publicação ganha a nova linha; os blocos de prova de publicação de artefatos existentes tratam a nova linha como n/a (with reason: pre-mandate-N artifact) até serem reauditadossite/content/docs/governance/pre-emission-gate-registry.mdx §1 esquema
Entrada no livro-razão de divulgaçãoRegistra a introdução do mandato com uma justificativa fundamentada em um impulsionador concreto (recorrência de padrão observada; lacuna de segurança exposta; capacidade que os quinze existentes não cobrem)O corpo do commit do conjunto de mudanças ou a descrição do PR segundo src/apothem/rules/disclosure-ledger.md

Disciplina de aplicação. Uma proposta de mandato que chega sem o pacote é rejeitada na revisão; o proponente ou completa o pacote ou rebaixa a proposta a uma extensão de um mandato existente. Os quinze mandatos existentes foram adotados juntos como o eixo externo da especificação; adições futuras honram a mesma cadência de adoção de todos-os-componentes-ou-nenhum-componente em vez de aterrissar por partes.

Protocolo de rebaixamento / aposentadoria. Quando um M-N estabelecido é descoberto como redundante com um CM-N existente ou com outro M-N (o mapa de cobertura de mapeamento cruzado no corpo da regra materializadora mostra adjacência direct em ambas as direções), o rebaixamento é o inverso simétrico: a linha do registro é aposentada, a linha do portão é aposentada, a regra canônica é aposentada (com o conteúdo dobrado na regra absorvente segundo src/apothem/rules/clean-room-generation.md §3 Protocolo de reescrita), o fixture de conformidade é aposentado, o bloco bars: do esquema de prova de publicação descarta a linha, e o conjunto de mudanças é registrado no livro-razão de divulgação com a citação da regra absorvente. O rebaixamento preserva o mesmo invariante de todos-os-componentes-ou-nenhum-componente.

On this page