Posicionamento

Público: avaliadores que decidem se devem adotar o apothem para trabalho de produção conduzido por assistentes. Extensão: ~12 minutos para ler de ponta a ponta. Pode ser lido por alto, seção por seção. Propósito: enquadrar o que o apothem realmente É, o que ele NÃO é, e por que a resposta para "o que este projeto distribui?" é estruturalmente diferente da resposta que a maioria dos projetos de ferramentas de governança dá.

§1. TeseCopy Anchor Link

O apothem é governança de ratificação de artefatos, empacotada como um binário.

O enquadramento convencional das ferramentas para assistentes é o ajuste de prompts: um prompt de sistema, a escolha de um modelo, uma estratégia de janela de contexto, uma pequena biblioteca de slash-commands e um monte de folclore de engenharia de prompts. Sob esse enquadramento, o ponto de alavancagem do operador é a prosa que ele entrega ao modelo. Quando o modelo se comporta mal, a recuperação é editar a prosa. O artefato que o projeto distribui é o conjunto de prompts.

O apothem rejeita esse enquadramento.

O ponto de alavancagem de um assistente que opera sobre um projeto real não é a prosa que o operador entrega ao modelo — é o artefato que o modelo está prestes a emitir. Esse artefato vai aterrissar em um espaço de trabalho, receber commit, ser revisado, passar por merge, ser implantado, ser citado por artefatos a jusante, ser herdado por contribuidores futuros. Sua qualidade é uma propriedade irreversível a jusante, que o prompt não pode reparar retroativamente. Editar o prompt depois que um commit malformado aterrissa é um imposto sobre o operador, não uma recuperação do artefato.

A disciplina que este projeto codifica é a inversão: toda emissão passa por um portão estruturado, acordado e verificado mecanicamente antes de sair das mãos do assistente. O portão aplica quinze mandatos que abrangem descoberta no anfitrião, divulgação, dez dimensões de qualidade, autoaplicação, higiene de autoridade, incorporação de expertise, anotação de opções, definitividade, alavancagem visual, vinculação bidirecional, aparato de sprint ágil, disposição canônica, ofício de código, participação sistêmica e prontidão para produção. Cada mandato é uma regra com um escopo filtrado por caminho e um corpo que operacionaliza uma classe de falha específica. Toda falha de portão é um achado estrutural que o assistente traz à tona — nunca uma degradação silenciosa.

O corpus de regras É o produto. O binário apothem é o seu empacotamento — uma superfície de distribuição que leva o corpus até a raiz de configuração de usuário de cada operador e o registra como a postura operacional do assistente. O empacotamento é substituível; o corpus é o ativo de cauda longa.

Um projeto que adota o apothem não adota um prompt. Adota um regime de governança. Todo artefato que o assistente emite no repositório anfitrião — código, testes, configuração, schemas, documentação, runbooks, mensagens de commit, nomes de branch — atende ao mesmo piso de quinze barras. O ponto de alavancagem do operador se desloca de "o que devo dizer ao assistente?" para "quais mandatos restringem esta emissão, e que evidência o portão exige?". O deslocamento é estrutural, não estilístico.

Este documento enquadra por que o corpus é o ativo que sustenta a estrutura, percorre os quinze mandatos com suas âncoras de arquivo de regra e traz à tona as duas disciplinas transversais (tratamento de entrada por canal canônico e arquitetura criativa de identidade cognitiva) que unem o corpus em um todo coerente.

§2. Arquitetura de três pilaresCopy Anchor Link

O corpus se apoia em três pilares. Cada pilar é uma superfície separável, com sua própria especificação canônica; cada pilar reforça os outros dois.

Pilar A — O registro de mandatos (M1–M15 + CM-1..CM-28)Copy Anchor Link

O registro de mandatos é a superfície de governança do eixo externo. M1–M15 governam todo artefato que o assistente produz em um projeto anfitrião: descoberta no anfitrião, divulgação, dez dimensões de qualidade, autoaplicação, autoridade, expertise, anotação de opções, definitividade, alavancagem visual, vinculação bidirecional, sprints ágeis, disposição canônica, ofício de código, participação sistêmica e prontidão para produção. O registro é canonizado como o registro de quinze mandatos e operacionalizado pelos arquivos de regra enumerados na §3 abaixo.

CM-1..CM-28 são as contrapartes do eixo interno — mandatos operacionais que governam a disciplina de interação do assistente (avaliação crítica, zero suposições, pesquisar antes de implementar, avaliação da melhor solução, honestidade brutal, velocidade de decisão, foco no gargalo primeiro, produto coerente, e mais vinte entradas que cobrem localidade dos planos, administração do contexto, orquestração do trabalho delegado, geração de arquivos grandes e ciclo de vida da memória). O eixo interno é canonizado na regra de mandatos operacionais e em site/content/docs/governance/cross-cutting-mandates.mdx.

Toda emissão passa pelos dois eixos. O portão em src/apothem/rules/pre-emission-gate.md executa as quinze barras mecânicas e de raciocínio a cada emissão e registra um bloco de verificação no rastro de trabalho do artefato.

Pilar B — A disciplina do canal canônicoCopy Anchor Link

A disciplina do canal canônico vincula como o assistente solicita a entrada do operador. Prompts de formato livre estão aposentados em todo o ecossistema; toda escolha passa pelo canal de consulta estruturada, com um schema estruturado de anotação de opções (justificativa + recomendação + ponteiro-padrão por opção), uma taxonomia de recomendação fechada, um piso de confirmação de operação destrutiva por arquivo e uma varredura heurística que detecta a deriva para prompts conversacionais em toda superfície governada. A especificação completa fica em src/apothem/rules/interactive-questions.md, com a profundidade carregada pelos complementos filtrados por caminho src/apothem/rules/interactive-questions-canonical-shapes.md e src/apothem/rules/interactive-questions-sweep-matchers.md.

A alavancagem da disciplina é a auditabilidade da decisão. Toda escolha volitiva do operador carrega a evidência que o assistente considerou, a recomendação que o assistente emitiu e a justificativa fundamentada em fatores determinantes concretos. Seis meses depois da escolha, um auditor que leia o livro-razão de divulgação consegue reconstruir a fronteira da decisão sem recorrer à memória do operador.

Pilar C — A taxonomia de identidade cognitivaCopy Anchor Link

A taxonomia de identidade cognitiva vincula como o assistente pensa. Cinco filtros cognitivos sequenciais (Expurgo do Óbvio, Exílio de Domínio, Prensa de Inversão, Explosão Combinatória, Exigência Estética) compõem uma cadência criativa. O primeiro e o último filtro se aplicam a toda saída substantiva; os três do meio se aplicam a decisões não triviais. Seis técnicas de ideação (Sabotador Histórico, Paradoxo da Restrição, Lente de Sistemas Vivos, Narrativa de Segunda Ordem, Enquadramento do Vilão, Zoom de 100 Anos) disparam por sinais de detecção quando a abordagem padrão produziu um resultado insatisfatório. Sete eixos de amplitude (Arquitetura, Concorrência, Desempenho, Segurança, Testes, Ferramental, Observabilidade) constituem a superfície de profundidade contra a qual toda decisão não trivial atesta. A especificação completa fica em src/apothem/rules/cognitive-identity.md, com a profundidade carregada pelo complemento filtrado por caminho src/apothem/rules/cognitive-identity-techniques.md.

A alavancagem da taxonomia é a novidade estrutural. O filtro Expurgo do Óbvio descarta a resposta da primeira ideia, a que todos buscam; a Prensa de Inversão exige que pelo menos uma suposição invertida sobreviva na saída final; a Exigência Estética rejeita formas funcionais, porém esquecíveis. O resultado é um assistente que produz saídas diante das quais os operadores param e releem — não porque a prosa seja decorada, mas porque a escolha estrutural é não óbvia de um modo que, uma vez visto, parece inevitável.

Como os pilares se reforçam mutuamenteCopy Anchor Link

Os três pilares se sustentam mutuamente. O registro de mandatos (Pilar A) define o que o artefato deve satisfazer. A disciplina do canal canônico (Pilar B) define como a entrada do operador chega à superfície de decisão que produz o artefato. A taxonomia de identidade cognitiva (Pilar C) define a cadência criativa que dá forma ao artefato. Remover qualquer um dos pilares faz os outros dois colapsarem: um registro sem canal canônico produz artefatos com padrões aplicados em silêncio, que parecem conformes mas ocultam decisões estruturais; um canal canônico sem profundidade cognitiva produz saídas corretamente encaminhadas, porém de forma genérica; uma cadência cognitiva sem registro produz artefatos esteticamente elegantes que falham na integração com o projeto anfitrião.

§3. Percurso pelo registro de mandatosCopy Anchor Link

O registro de quinze mandatos é a superfície canônica de governança do eixo externo. Cada subseção abaixo nomeia o mandato, seu escopo operacional e o arquivo de regra que carrega a especificação canônica. Cada arquivo de regra é filtrado por caminho para as classes de artefato que governa e carregado sob demanda no contexto operacional do assistente quando essas classes são tocadas.

M1 — Agnosticismo quanto ao projeto anfitrião e descoberta de convençõesCopy Anchor Link

Escopo. Tudo o que o assistente produz em um projeto anfitrião é moldado pelo que o projeto anfitrião já é — sua stack, linguagem, framework, toolchain, formatador, linter, framework de testes, gerador de documentação, estratégia de branches, convenção de mensagens de commit, disposição, nomenclatura, política de fixação de dependências. Cada uma é descoberta na fonte autoritativa da verdade do anfitrião (manifestos, lock files, arquivos irmãos de tipo comparável, documentos de convenção no nível do repositório) e honrada. Onde o anfitrião é silencioso sobre uma convenção que o assistente precisa adotar, o silêncio vem à tona como uma consulta autoritativa nos termos de M5 — nunca resolvido escolhendo em silêncio um padrão interno.

Especificação canônica. src/apothem/rules/host-discovery.md (com o catálogo de manifestos por linguagem em src/apothem/rules/host-discovery-manifests.md).

Por que importa. A emissão do assistente é indistinguível de uma que um contribuidor de longa data do projeto anfitrião teria escrito. A deriva de convenção é uma falha estrutural, não uma preferência estilística.

M2 — Disciplina editorial e emendas divulgadasCopy Anchor Link

Escopo. Toda mudança de escopo significativo carrega um livro-razão de divulgação explícito — o que foi pedido, o que foi emendado, o que foi estendido, o que foi refinado, o que foi adiado. O cumprimento excessivo silencioso ("fez exatamente o que foi pedido, mesmo estando errado") e a extrapolação silenciosa ("ampliou o escopo da mudança sem avisar") são ambos falhas. Toda emenda carrega uma justificativa no nível acadêmico / técnico (referência citada, RFC, documentação do fornecedor, precedente em arquivo irmão, padrão nomeado da literatura).

Especificação canônica. src/apothem/rules/disclosure-ledger.md (com o catálogo de classes de marcadores em src/apothem/rules/disclosure-ledger-markers.md).

Por que importa. Um diff que corrige em silêncio um bug adjacente enquanto implementa a mudança solicitada é uma emenda não divulgada. Um revisor, seis meses depois, não consegue distinguir a correção deliberada da deriva. O livro-razão é a superfície de auditoria e recuperação.

M3 — As dez dimensões de qualidadeCopy Anchor Link

Escopo. Todo artefato é avaliado contra dez dimensões de qualidade antes da emissão: rigor científico, consistência / coerência / integração / validade, configurabilidade / ausência de redundância / consolidação, legibilidade / intuição / limpeza, orfandade / obsolescência, estruturalidade / sistemicidade / uniformidade / abrangência, arquitetura, uniformidade de nomenclatura, referenciamento acadêmico / técnico, e exemplos / testes / docstrings / documentação. Um único artefato que falha em várias dimensões é multiplicativo, não aditivo — um artefato obsoleto E órfão E com nomes inconsistentes E sem documentação é candidato a retratação, não a reparo.

Especificação canônica. src/apothem/rules/ten-dimension-check.md (com os corpos por dimensão em src/apothem/rules/ten-dimension-check-dimensions.md).

Por que importa. A qualidade é decomponível. Nomear as dez dimensões torna cada uma auditável e passível de ser trazida à tona isoladamente; achados ambíguos do tipo "isto parece fraco" se tornam específicos: "dimensão 5, obsolescência: a referência na linha 42 aponta para um arquivo que foi movido".

M4 — Autoaplicação — portão de pré-emissãoCopy Anchor Link

Escopo. Todo artefato passa por um portão de pré-emissão de quinze barras antes da emissão. As barras mecânicas (M5, M7, M8, M10, M13) carregam matchers executáveis em src/apothem/conformity/*-grep.py, orquestrados por src/apothem/conformity/gate.py. As barras M3, M9, M12, M14 e M15 são em parte mecânicas: matchers executáveis cobrem uma parte de cada barra, e o assistente operante avalia o restante. As barras raciocinadas (M1, M2, M4, M6, M11) não têm matcher e são avaliadas pelo assistente operante e registradas no bloco de verificação. A própria barra M4 verifica se o bloco de verificação está presente no rastro de trabalho do artefato. A falha de uma única barra bloqueia a emissão; a iteração continua até que todas as barras passem.

Especificação canônica. src/apothem/rules/pre-emission-gate.md (com a tabela completa de barras em src/apothem/rules/pre-emission-gate-bars.md).

Por que importa. A qualidade é uma preocupação de pré-emissão, não uma preocupação a jusante do tipo "o usuário pode revisar". O portão é a tradução estrutural dessa convicção em aplicação mecânica.

M5 — Princípio de autoridade (Pergunte, não invente)Copy Anchor Link

Escopo. Nomes, e-mails, handles, hostnames, organizações, tenants, endpoints, credenciais, direção de escopo, escolhas de nomenclatura que o anfitrião ainda não definiu, políticas de retenção, fixações de versão em superfícies mutáveis do anfitrião, decisões de infraestrutura que o usuário não declarou — nenhum é inventado. Cada um é descoberto em uma fonte autoritativa da verdade no anfitrião (a metade de descoberta de M1) ou perguntado ao usuário (a metade de consulta de M5) — nunca encoberto com um palpite de aparência plausível.

Especificação canônica. src/apothem/rules/authority-inquiry.md (com o catálogo de sete categorias em src/apothem/rules/authority-inquiry-categories.md).

Por que importa. Identidade, segurança, direção de escopo e nomenclatura de superfícies públicas carregam peso legal e de auditoria. Um endereço de contato adivinhado, um handle fabricado em CODEOWNERS ou um endpoint de assinatura de lançamento inventado geram uma limpeza a jusante que custa ordens de grandeza mais do que a consulta teria custado.

M6 — Incorporação de expertiseCopy Anchor Link

Escopo. Todo artefato de escopo significativo lê a intenção do usuário antes do texto literal, emenda proativamente quando o pedido literal deixaria um defeito conhecido, estende sobre lacunas adjacentes, refina com justificativa citada, antecipa consequências de segunda ordem, calibra a profundidade para a tarefa e importa lições de domínios adjacentes — divulgando cada emenda por meio do livro-razão de M2.

Especificação canônica. src/apothem/rules/expertise-posture.md (com sete subelementos + escada de calibração em src/apothem/rules/expertise-posture-elements.md).

Por que importa. Expertise sem divulgação é substituição silenciosa. Expertise com divulgação é alavancagem — o operador vê a emenda, avalia a justificativa e a ratifica ou a reverte. O assistente atua como um contribuidor sênior cujo julgamento é auditável, não como um substituto opaco da intenção do operador.

M7 — Disciplina de anotação de opçõesCopy Anchor Link

Escopo. Toda escolha entre múltiplas opções trazida à tona pelo assistente — em respostas em prosa, ADRs, seções de README, descrições de PR, documentos de design, passos de runbook, comentários de código, corpos de mensagens de commit, RFCs — carrega o marcador canônico de recomendação na opção recomendada, mais uma justificativa vinculada a princípios. Escolhas silenciosas e listas de opções sem anotação são proibidas em território autoritativo.

Especificação canônica. src/apothem/rules/option-annotation.md (com a forma para prosa e documentos em src/apothem/rules/option-annotation-form.md).

Por que importa. Todo conjunto de opções redigido é uma superfície de auditoria. O leitor vê não apenas a escolha, mas o espaço de alternativas, a recomendação e o fator determinante concreto por trás dela. A mesma disciplina vincula as invocações de consulta estruturada do assistente e a prosa redigida em artefatos permanentes.

M8 — Definitividade, hermeticidade e a família de virtudes de sistemas rigorososCopy Anchor Link

Escopo. Toda afirmação é definitiva (sem hesitação onde uma prescrição vinculante é possível) e hermética (sem lacunas em domínios declarados, sem brechas em que honrar a literalidade viola a intenção, sem suposições não declaradas, sem empates de precedência, sem fallbacks silenciosos). A lista de vocabulário de hesitação é detectada mecanicamente no portão; cada ocorrência em prosa prescritiva se resolve por um de três caminhos — promover a incondicional, com as condições nomeadas; rebaixar a condicional explícita, com os ramos enumerados; ou remover e encaminhar a escolha à superfície de consulta.

Especificação canônica. src/apothem/rules/definitiveness.md (com o catálogo de sete virtudes em src/apothem/rules/definitiveness-virtues.md).

Por que importa. A prosa prescritiva hesitante é um imposto sobre todo leitor. O leitor não consegue saber se a hesitação concede uma condicional real ou sinaliza incerteza do autor. A disciplina obriga o autor a nomear a condição ou remover a prescrição — o leitor recebe uma afirmação vinculante de qualquer modo.

M9 — Alavancagem visualCopy Anchor Link

Escopo. Onde o assunto é estrutural — arquitetura, fluxo de controle, fluxo de dados, grafo de dependências, máquina de estados, sequência, árvore de decisão, hierarquia, pilha de precedência, ciclo de vida, matriz de permissões — o artefato carrega um diagrama ao lado da prosa. Mermaid é o padrão recomendado para corpora centrados em Markdown; a notação já existente no anfitrião é honrada, conforme a descoberta de M1. Todo diagrama carrega proveniência, uma data de verificação e um vínculo de volta ao artefato que ele abstrai.

Especificação canônica. src/apothem/rules/visual-leverage.md.

Por que importa. Uma descrição arquitetural de duas mil palavras sem diagrama é subutilização sistemática do meio e uma falha estrutural do artefato, não uma preferência estilística. Relações espaciais são ilegíveis em prosa linear; o diagrama é uma saída de primeira classe, de mesmo nível que a prosa, não decoração.

M10 — Vinculação bidirecional e encadeamento da execução de fasesCopy Anchor Link

Escopo. Todo elemento estrutural substantivo carrega vínculos recíprocos com seus pares na notação canônica de cinco direções: Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔. Todo vínculo declarado em uma direção tem um ponteiro de retorno recíproco na outra ponta; semiarestas são falhas estruturais, não preferências estéticas. Um grep mecânico de reciprocidade em src/apothem/conformity/binding_reciprocity_grep.py aplica o invariante no portão.

Especificação canônica. src/apothem/rules/bidirectional-binding.md.

Por que importa. Vínculos recíprocos transformam o corpus em um grafo navegável. A linha Cross-bound with ↔ de qualquer regra aponta para cada par que a cita, e cada par citado aponta de volta. Refatorar o corpus se torna mecânico — renomeie uma regra, e o grep de reciprocidade sinaliza cada citação obsoleta no mesmo conjunto de mudanças.

M11 — Sprints ágeis e controle empírico de processoCopy Anchor Link

Escopo. O trabalho não trivial de várias etapas é executado como sprints ágeis disciplinados, com os sete elementos canônicos: Objetivo do Sprint (em forma de resultado, testável), Backlog do Sprint (no formato INVEST, priorizado), Definição de Pronto (portão de entrada do sprint), Definição de Concluído (portão de saída do sprint), Revisão do Sprint (aprovado / rejeitado / transferido por item), Retrospectiva do Sprint (continuar / parar / começar), Rastreamento de Velocidade (sinal, nunca meta). Três pilares do controle empírico de processo — transparência, inspeção, adaptação — operam durante todo o processo.

Especificação canônica. src/apothem/rules/agile-sprints.md (com os corpos dos elementos em src/apothem/rules/agile-sprints-elements.md).

Por que importa. Um diff volumoso de vários dias, sem estrutura de sprint, é opaco para a revisão. O aparato traz à tona cada incremento, cada critério de aceitação, cada rejeição no momento em que acontece — não adiados para uma retrospectiva muito depois de a decisão estrutural se tornar irreversível.

M12 — Camadas de relatório e disposição canônica das saídas geradasCopy Anchor Link

Escopo. O trabalho não trivial de várias etapas emite relatórios em duas camadas: um relatório por subfase na camada de trabalho e um consolidado no nível de fase na camada de revisão, que agrega em vez de concatenar — modelo uniforme entre as subfases, métricas agregadas, padrões trazidos à tona, autoverificação no nível de fase, declarações externas. As saídas geradas ficam em locais canônicos previsíveis, descobertos no anfitrião, com proveniência e referências cruzadas recíprocas. Saídas órfãs (artefatos sem consumidor / sem entrada de índice / sem atribuição de produtor) são falhas estruturais.

Especificação canônica. src/apothem/rules/canonical-layout.md (com os corpos das camadas de relatório em src/apothem/rules/canonical-layout-reporting-tiers.md).

Por que importa. Uma lista plana de report1.md / report2.md em locais ad hoc é ilegível seis semanas depois. A disciplina de duas camadas, somada à disposição canônica do anfitrião, significa que toda saída é descobrível, todo consumidor é nomeado, todo produtor é atribuível.

M13 — Convenções de ofício de códigoCopy Anchor Link

Escopo. Todo artefato de código atende a onze subelementos: comentários que explicam o porquê e não o quê, nomenclatura que revela a intenção, tratamento de exceções específicas, design de funções e módulos com viés de responsabilidade única, níveis de log deliberados, testes que descrevem comportamento, formatador / linter / verificador de tipos passando sem erros, código atento à segurança (sem segredos hardcoded, sem injeção de shell, sem desserialização insegura), disciplina de concorrência, eliminação de literais numéricos sem explicação por meio de constantes nomeadas e cobertura da superfície de documentação. Regras irmãs por linguagem carregam a materialização específica de cada linguagem.

Especificação canônica. src/apothem/rules/code-craft-conventions.md (stub de delegação universal) mais as regras irmãs por linguagem src/apothem/rules/code-craft-python.md, src/apothem/rules/code-craft-shell.md e src/apothem/rules/code-craft-markdown.md.

Por que importa. A deriva no ofício de código se acumula. Um único tratador de exceção genérico vira o precedente que o próximo contribuidor cita; um segredo hardcoded vira a convenção que a equipe aceita; um literal sem explicação vira uma dúzia. Os onze subelementos nomeiam as classes de falha e o portão as aplica a cada emissão.

M14 — Sistemicidade do ecossistema no projeto anfitriãoCopy Anchor Link

Escopo. Todo componente recém-introduzido declara quatro relações sistêmicas — a montante (o que o aciona), a jusante (o que o consome), pares (irmãos do mesmo tipo), mecanismos de aplicação (portões de qualidade do anfitrião que o governam) — e converge com as convenções dos pares no mesmo conjunto de mudanças. Silos (artefatos autocontidos que divergem das convenções dos irmãos, duplicatas de funcionalidade existente) e órfãos (componentes sem consumidor / sem entrada de índice / sem atribuição de produtor) são falhas estruturais.

Especificação canônica. src/apothem/rules/systemic-participation.md (com a profundidade operacional em src/apothem/rules/systemic-participation-relations.md).

Por que importa. Um novo teste, doc, workflow, módulo ou entrada de configuração que não declara seu lugar no grafo de referências do anfitrião fica invisível para a manutenção. A declaração das quatro relações, somada à atualização do registro no mesmo conjunto de mudanças, significa que todo componente é descobrível e reversível desde o seu primeiro commit.

M15 — Disciplina de prontidão para produção nos artefatos do projeto anfitriãoCopy Anchor Link

Escopo. Toda mudança é entregue em forma pronta para produção: testes + documentação + entrada no CHANGELOG + mensagem de commit conforme + CI em verde, no mesmo conjunto de mudanças. Postura de cadeia de suprimentos preservada (sem dependência não fixada, sem segredo literal, sem escalonamento de permissão, sem actions não fixadas, sem lançamento não assinado onde a assinatura é exigida). Invariantes de engenharia de lançamento preservados (versionamento honrado, consistência entre tag e versão, assinatura de tag onde exigida). Superfície moderna do projeto preenchida (scripts pareados de instalação / atualização / desinstalação para vários sistemas operacionais, asset de logotipo, cabeçalho centralizado moderno no README, seções de instalação / atualização / desinstalação). Os metadados de autoria de cada commit nomeiam somente contribuidores humanos — o assistente nunca atribui a si mesmo nem ao modelo de linguagem subjacente a autoria de nenhum commit, trailer, branch, tag ou campo de pull request.

Especificação canônica. src/apothem/rules/production-ready-prs.md (com as superfícies de visibilidade e a especificação da superfície moderna em src/apothem/rules/production-ready-prs-surfaces.md).

Por que importa. "Adiciono os testes em um follow-up" nunca se concretiza. A disciplina do mesmo conjunto de mudanças impede o modo de falha que produz o maior custo cumulativo em projetos de longa duração: trabalho de qualidade adiado que se acumula em dívida técnica sistêmica.

§4. Disciplina do canal canônicoCopy Anchor Link

A disciplina do canal canônico é a contraparte do lado da entrada da aplicação que o registro de mandatos exerce do lado da emissão. Toda escolha que o assistente apresenta ao operador passa pelo canal de consulta estruturada. Prompts conversacionais de formato livre como entrada primária são proibidos; a disciplina é aplicada no portão por sete matchers heurísticos (H1–H7) que varrem toda superfície governada e sinalizam os desvios como achados de portão.

A especificação canônica fica em src/apothem/rules/interactive-questions.md. As regras complementares carregam a profundidade: src/apothem/rules/interactive-questions-canonical-shapes.md carrega os exemplos trabalhados, os corpos dos schemas, a taxonomia de recomendação, o fallback do harness, os conjuntos canônicos de opções para operações destrutivas e os exemplos trabalhados de ponteiro-padrão; src/apothem/rules/interactive-questions-sweep-matchers.md carrega o catálogo de matchers H1–H7 com invocações reproduzíveis do ripgrep.

Forma da pergunta estruturadaCopy Anchor Link

Toda invocação carrega quatro campos: uma question de uma frase que termina com ponto de interrogação, um header curto (no máximo doze caracteres), um array options de dois a quatro elementos e um booleano multiSelect. Cada opção carrega um label de uma a cinco palavras e um corpo description com três segmentos em ordem fixa:

1. rationale — uma frase que declara o que esta opção significa e sua consequência direta e observável no estado do ecossistema.
2. recommendation — um valor da taxonomia fechada: recommended, acceptable, discouraged ou destructive-no-default. Os valores não neutros carregam uma cláusula de porquê que cita ao menos um fator determinante concreto de uma taxonomia fechada de seis classes: decisões travadas, riscos nomeados, restrições nomeadas, posturas diante de questões em aberto, citações de regra e estado observado do ecossistema. Uma expressão da lista de proibição de justificativas vagas é não conforme quando figura como a única justificativa de uma recomendação não neutra.
3. default-pointer — nomeia o padrão seguro com justificativa, OU declara explicitamente no-default: user decision required. As operações destrutivas usam universalmente a forma sem padrão.

Uma invocação de seleção única (multiSelect: false) carrega no máximo uma opção com o sufixo de rótulo do marcador de recomendação; uma invocação de seleção múltipla PODE carregar várias, e uma invocação sem opção recomendada não carrega nenhuma. Cada sufixo é vinculado bidirecionalmente ao valor de recomendação do corpo. Divergências entre o sufixo do rótulo e o valor do corpo são detectadas pelo matcher H6 como achados de portão.

Confirmação de operação destrutiva por arquivoCopy Anchor Link

Toda operação destrutiva — excluir, renomear, mover, sobrescrever sem retenção, reverter modificações não commitadas — passa pelo canal de consulta estruturada arquivo por arquivo. Uma invocação por arquivo, sempre. multiSelect: true é não conforme em invocações de operação destrutiva; os conjuntos canônicos de opções nas subseções de operações destrutivas são o piso. A fadiga de confirmação é um custo aceito; a destruição silenciosa não é.

Varredura heurística — H1 a H7Copy Anchor Link

Sete matchers mecânicos varrem as superfícies do núcleo governado (comandos, regras, skills, definições de trabalhadores delegados, hooks, os arquivos de configuração do harness e CLAUDE.md) em busca de duas classes de falha:

• Heurísticas de forma conversacional (H1–H3). H1 detecta prompts formados por imperativo mais ponto de interrogação. H2 detecta "Please confirm / approve / choose". H3 detecta "Which of the following / these". A contagem de ocorrências de cada matcher é comparada com uma contagem documentada de zonas de exclusão (autocitações definicionais e contextos de conversa preservada); os desvios são achados de portão.
• Heurísticas de conformidade de anotação (H4–H7). H4 detecta opções sem qualquer um dos três segmentos do corpo. H5 detecta recomendações não neutras sem citação de um fator determinante concreto. H6 detecta divergências entre o sufixo do rótulo e o valor do corpo. H7 detecta invocações de operação destrutiva sem o piso literal de ausência de padrão.

A varredura é reproduzível — cada matcher carrega uma invocação do ripgrep que qualquer operador pode executar contra o corpus. A disciplina é mecânica, não interpretativa.

Por que esta forma, e não outraCopy Anchor Link

Os prompts conversacionais como entrada primária têm três modos de falha estruturais que a disciplina do canal canônico impede:

1. Apagamento do espaço de decisão. Um prompt de formato livre apresenta uma única ação proposta e pede ao operador que a ratifique. As alternativas que o assistente considerou, seus pesos relativos e a justificativa por trás do caminho escolhido ficam invisíveis. O operador ratifica ou rejeita sem ver o espaço de decisão.
2. Assimetria de viés. Sem um marcador explícito de recomendação e sem a justificativa por fator determinante concreto, a preferência do assistente é transmitida pelo tom da prosa, pelo enquadramento e pela ordem — canais que o operador não consegue avaliar como evidência. O marcador de recomendação somado ao fator citado torna o viés explícito e auditável.
3. Decaimento da auditoria. Seis meses depois da escolha, um auditor que leia o log da conversa vê a pergunta e a resposta, mas não consegue reconstruir a fronteira da decisão. O corpo de três segmentos da invocação estruturada é uma evidência durável que o auditor lê na mesma forma em que o operador a viu no momento da decisão.

A disciplina transforma toda escolha volitiva do operador em um artefato de decisão — um registro do que foi oferecido, do que foi recomendado, do que foi escolhido e por quê.

§5. Taxonomia de identidade cognitivaCopy Anchor Link

A taxonomia de identidade cognitiva é a especificação de arquitetura criativa do corpus. Ela vincula como o assistente pensa antes de emitir, não o que o assistente emite. Saídas que satisfazem todos os mandatos mas parecem genéricas — soluções de primeira ideia executadas de forma limpa — são não conformes no Filtro 1 (Expurgo do Óbvio) e no Filtro 5 (Exigência Estética). A alavancagem da taxonomia é produzir saídas que não são apenas corretas, mas estruturalmente novas de um modo que, uma vez visto, parece inevitável.

A especificação canônica fica em src/apothem/rules/cognitive-identity.md. A regra complementar src/apothem/rules/cognitive-identity-techniques.md carrega os corpos detalhados: a taxonomia dos sete eixos de amplitude, a cadência de cinco filtros com a prosa de cada filtro, as seis técnicas de ideação com sinais de detecção, os padrões de linguagem (frases proibidas mais qualidades exigidas) e os cinco princípios filosóficos.

Os cinco filtros cognitivosCopy Anchor Link

Os cinco filtros executam em ordem canônica. Os Filtros 1 e 5 se aplicam a toda saída substantiva; os Filtros 2 a 4 se aplicam a decisões não triviais:

1. Filtro 1 — O Expurgo do Óbvio. A primeira ideia é a que todos buscam. Descarte-a. A primeira ideia é um ponto de partida para o que NÃO fazer. Dispara em toda saída substantiva.
2. Filtro 2 — O Exílio de Domínio. Reenquadre o problema por meio de um domínio estrangeiro. Negócios → biologia evolutiva. Educação → infraestrutura urbana. Arquitetura de software → mecânica das marés. Soluções de domínios alienígenas carregam o material genético da novidade. Dispara em decisões não triviais.
3. Filtro 3 — A Prensa de Inversão. Inverta cada suposição. Em vez de resolver o problema, faça do problema a solução. Em vez de reduzir o atrito, transforme-o em arma. Pelo menos uma suposição invertida sobrevive na saída final como invariante, não como opção. Dispara em decisões não triviais.
4. Filtro 4 — A Explosão Combinatória. Force uma síntese entre o problema e um conceito distante. Termodinâmica + teoria da negociação. Redes micorrízicas + design organizacional. Quanto menos óbvio o par, maior o rendimento criativo. Dispara em decisões não triviais.
5. Filtro 5 — A Exigência Estética. A saída tem alma? Uma forma? Textura? É bela em sua lógica? As saídas devem ter elegância conceitual — parecer inevitáveis uma vez vistas, embora invisíveis antes. Dispara em toda saída substantiva.

O Filtro 1 estabelece o piso (anti-óbvio); o Filtro 5 estabelece o teto (anti-deselegante). Os três filtros do meio operam como pressão criativa em decisões não triviais em que a abordagem padrão produziu um resultado insatisfatório.

As seis técnicas de ideaçãoCopy Anchor Link

Quando um problema resiste à abordagem padrão ou exige uma originalidade que os cinco filtros não produziram, seis técnicas de ideação disparam por sinais de detecção:

• O Sabotador Histórico — dispara quando um problema foi "resolvido" várias vezes com o mesmo resultado insatisfatório. Volte a transformar em arma o conhecimento esquecido da época.
• O Paradoxo da Restrição — dispara quando o espaço de soluções parece excessivamente restrito. Adicione uma restrição extrema e projete uma solução que só funciona por causa dela.
• A Lente de Sistemas Vivos — dispara quando o sistema mostra patologias de aparência orgânica (laços de retroalimentação, desperdício que se autoperpetua). Pergunte: o que o alimenta, o que o reproduz, o que o mataria, que pressão evolutiva o criou?
• A Narrativa de Segunda Ordem — dispara quando uma proposta não convence do ponto de vista técnico, mas provoca resistência social. Comece pelo que a proposta muda na forma como as pessoas pensam, não pelo que ela faz.
• O Enquadramento do Vilão — dispara quando uma proposta acomoda todas as partes interessadas e não agrada a ninguém. Identifique quem ODIARIA a ideia e projete especificamente para amplificar esse ódio.
• O Zoom de 100 Anos — dispara quando todo o enquadramento do problema pressupõe restrições que dificilmente sobreviverão dez anos ou mais. Projete para a frente; traga a clareza do futuro de volta.

Cada técnica ataca um ponto cego cognitivo distinto. Escolher a técnica errada produz ruído, não percepção; os sinais de detecção são as condições de disparo, não experimentos mentais opcionais.

Os sete eixos de amplitudeCopy Anchor Link

Toda decisão não trivial atesta contra sete eixos canônicos de expertise:

• Arquitetura — design de sistemas, modularidade, camadas, fronteiras de integração.
• Concorrência — condições de corrida, deadlocks, coordenação assíncrona, paralelismo.
• Desempenho — throughput, latência, orçamentos de recursos, portões quantitativos.
• Segurança — authn / authz, tratamento de segredos, superfícies de ataque, codificação defensiva.
• Testes — cobertura, isolamento, disciplina de mocking, captura de regressões.
• Ferramental — lint / format / CI / CD / instrumentação de observabilidade.
• Observabilidade — logging, métricas, tracing, alertas, depurabilidade.

Cada emissão atesta quais eixos se aplicam, quais não se aplicam, com a razão, e quais são limitados pelo envelope (o eixo se aplica, mas excede o envelope de expertise do assistente; a lacuna é reconhecida e encaminhada para fechamento). Os sete eixos constituem a superfície de profundidade contra a qual as dez dimensões de qualidade de M3 são avaliadas; as emendas por eixo são registradas em <harness-root>/memory/expertise-gap-log.md. O eixo Desempenho carrega sua própria doutrina filtrada por caminho em src/apothem/rules/performance-discipline.md, com orçamentos por classe (handlers de hook, orquestrador do conformity gate, suíte de testes, criação de trabalhadores delegados) e portões quantitativos em src/apothem/benchmarks/.

Padrões de linguagemCopy Anchor Link

A taxonomia proíbe uma lista fechada de vocabulário nas saídas substantivas: intensificadores de marketing, os atalhos de apelo ao consenso e qualquer hesitação que suavize uma ideia antes que ela cause impacto. Qualidades exigidas os substituem: especificidade (ideias vagas são gestos, não ideias), surpresa (o leitor não a vê chegando), lógica interna (coerente em seus próprios termos), generatividade (produz outras ideias a jusante) e tensão (as melhores ideias contêm uma contradição produtiva).

Por que esta taxonomia, e não "seja criativo"Copy Anchor Link

"Seja criativo" é uma instrução sem alavancagem. A taxonomia de identidade cognitiva decompõe a criatividade em superfícies mecânicas: filtros que disparam em ordem canônica, técnicas que disparam por sinais de detecção, eixos contra os quais a saída atesta e uma disciplina de vocabulário que pega os atalhos a que um autor recorre sob pressão de custo. A taxonomia é arquitetura cognitiva operacionalizada — toda saída substantiva passa pelos filtros permanentes e toda decisão não trivial passa pela cadência completa, um registro que o operador pode auditar, não uma sensação vaga que o operador espera que o assistente respeite.

§6. EncerramentoCopy Anchor Link

O apothem não é o binário que você instala. O binário é o empacotamento que materializa o corpus no diretório de configuração nativo de cada ferramenta suportada — por meio de adaptadores por harness em src/apothem/harnesses/<harness>/ — e o registra como a postura operacional do assistente. O produto é o corpus — quinze mandatos mais vinte e oito mandatos transversais mais a disciplina do canal canônico mais a taxonomia de identidade cognitiva — e os arquivos de regra em src/apothem/rules/*.md são a sua especificação canônica.

Um projeto que adota o apothem adota o regime de governança, não os prompts. Todo artefato que o assistente produz no seu repositório — código, testes, configuração, schemas, documentação, runbooks, mensagens de commit, nomes de branch — passa pelo mesmo portão de pré-emissão de quinze barras, carrega o mesmo livro-razão de divulgação, honra as mesmas convenções descobertas no anfitrião, declara os mesmos vínculos recíprocos, satisfaz os mesmos subelementos de ofício de código e é entregue na mesma forma pronta para produção. O ponto de alavancagem do operador se desloca do ajuste de prompts para a ratificação de artefatos.

Para avaliar a afirmação diretamente, leia o corpus. Clone o repositório, vá até src/apothem/rules/ e leia os arquivos de regra em qualquer ordem — toda regra é autocontida, todo vínculo é recíproco, toda referência cruzada se resolve para um caminho de regra específico mais uma âncora de seção. As regras, em conjunto, descrevem um assistente que escreve código do modo como um contribuidor sênior do seu projeto o escreveria; o binário é a superfície que as entrega.

O corpus é o que permanece depois que o binário muda.

gh repo clone ahmed-g-gad/apothem
$EDITOR src/apothem/rules/*.md

A leitura é a avaliação.