@orchestrator-claude/definitions 3.37.3 → 3.39.0

package/skills/arquitetura-lane-dispatch/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: arquitetura-lane-dispatch
+description: Use BEFORE dispatching a lane 3 round (Arquitetura Mediada) — the arquitetos de substrato em leque, sem contato, a partir do mesmo Ciclo aprovado, e depois o architecture-mediator. Triggers on "rodar a lane 3", "despachar os arquitetos", "leque-e-mediação", "primeira mesa", "mediar os pareceres", "ADR a partir do Ciclo", "Arquitetura Mediada". Carries the orchestrator side of the lane: pré-voo (o Ciclo está aprovado? a Q3 dá sim? quais eixos a task convoca? os agentes estão despacháveis?), o prompt simétrico do leque e o do mediador, o gate que o gate-guardian não vê, e — o essencial — como julgar o que volta re-medindo em vez de acreditar, inclusive a medição da rodada (V9). Do NOT use to PRODUCE architecture (that is each architect's charter plus arquitetura-mediada-arquiteto, which they carry and you do not hand them), nor for the adversarial review gate (adversarial-reviewer), nor for the consensus fan-out of the orchestrator skill — here nobody votes.
+---
+
+# Arquitetura Lane Dispatch — o lado do orquestrador da lane 3
+
+Os arquitetos carregam o **executável**: o charter de cada um e a skill comum
+`arquitetura-mediada-arquiteto`. O `architecture-mediator` carrega a disciplina de desempate. Esta skill
+carrega o que **não** cabe em nenhum deles: o que checar antes de despachar, como despachar o leque
+sem que um contamine o outro, e o que fazer com o que volta. A separação é por leitor (D-101, V3 = iii):
+o arquiteto não lê esta skill, porque ela traz o gabarito de quem o julga.
+
+O construto é o **leque-e-mediação** (`VOCABULARIO-LANE3-ARQUITETURA-MEDIADA-S528.md` §4): os arquitetos
+que a Q3 e o escopo convocam produzem **em paralelo e sem contato**, cada um sobre o seu substrato, a
+partir do **mesmo Ciclo aprovado** da lane 2; o mediador isola as divergências e desempata cada uma por
+medição. **Não é fase e não é gate.** Não é o *fan-out → gate de consenso* da skill `orchestrator`: lá
+se agrega, aqui um terceiro decide e pode dar razão a um contra seis.
+
+## Quando usar
+
+- Existe um **Ciclo aprovado** (lane 2A ou 2B) e a próxima pergunta é estrutural: *que decisão tomada
+  agora constrange a próxima entrega?*
+- Uma dívida técnica medida ou uma RFC decomposta pede decisão de mais de um substrato.
+
+**Não use** quando a pergunta é de um substrato só e ninguém discorda: despache o arquiteto do eixo
+direto, sem mesa e sem mediador. O leque existe para quando a divergência é provável; montar sete
+cadeiras para uma pergunta de uma é o custo sem o valor.
+
+---
+
+## 1 · Pré-voo — cinco checagens, todas antes de escrever o prompt
+
+### 1.1 O Ciclo está aprovado, e a aprovação está num arquivo
+
+O insumo canônico é o Ciclo aprovado da lane 2, com proveniência. Localize **o arquivo** e **o registro
+da aprovação** (corte, PR, `DECISOES-DO-PM.md`) e anote o sha256 do Ciclo: ele vai no prompt de todos,
+e é o que prova depois que todos leram o **mesmo** Ciclo. Ciclo sem aprovação registrada = **não
+despache**. Insumo vazio não falha limpo: sete arquitetos preenchem sete lacunas de sete jeitos, e o
+mediador passa a rodada desempatando invenção.
+
+Se o insumo é uma dívida medida ou uma RFC, e não um Ciclo, o prompt diz qual, com o mesmo rigor de
+sha e de registro.
+
+### 1.2 A Q3 dá sim
+
+*Aponte uma decisão que, tomada agora, constranja a próxima entrega que ainda não foi pedida.* Se você
+não consegue apontar, **a lane 3 não se aplica**: um estudo, um pipeline que reprocessa do zero todo
+ano, uma entrega que não deixa estrutura. Diga isso ao PM no gate e não despache. Escreva a decisão que
+constrange, **em uma frase**: ela vai no prompt como a pergunta aberta da mesa.
+
+### 1.3 Quem senta — a primeira mesa (V8)
+
+`[U]` **D-133**, que corrige a D-119: na **primeira mesa** sentam **os 6 arquitetos de substrato** —
+`backend-architect`, `frontend-architect`, `contract-architect`, `datamodel-architect`,
+`infra-architect`, `agentic-architect` — **mais o mediador**. Pares possíveis = **C(6,2) = 15**. O
+`harness-architect` **só senta quando a task toca o harness**; aí são 7 que produzem mapa e **C(7,2) =
+21**. O mediador **não conta** nos pares: ele não produz mapa.
+
+O PM escolheu a mesa cheia **contra a mitigação** da `PROPOSTA-EQUIPAMENTO-LANE3-S527.md` §4.10 (rodar só
+o subconjunto que a Q3 convoca). O risco é o salto de **2 para 6 ou 7 sem dado intermediário**, e é por
+isso que a primeira rodada é instrumentada (§2.3). **Da segunda mesa em diante**, a escolha de quem
+senta volta a ser do escopo e da Q3; escreva quais eixos a decisão constrange e **por que** cada um
+senta.
+
+Declare, **antes de despachar**, a conta de pares possíveis da mesa. Ela vai para o prompt do mediador
+e para o registro. Zero pares divergentes só é dado se você tinha o número esperado antes.
+
+### 1.4 Os agentes estão despacháveis — e com o charter certo
+
+Leia a lista de agentes do harness e confira **pelo nome exato** que cada arquiteto da mesa e o
+`architecture-mediator` estão lá, com o prefixo que a topologia exige (`orchestrator:backend-architect`
+sob plugin). **Um charter que existe no repo não é um agente despachável**: definição nova só fica viva
+depois de release, update do plugin e reload. `[M]` Na S530 nenhum dos arquitetos da lane 3 estava na
+lista (plugin 3.37.3, com as definições do `main`), e o gate do V5 foi feito com um `general-purpose` que
+**adotou o charter** lido da branch. O PM aceitou isso como **substituição declarada** (D-131).
+
+Se faltar algum, as opções são duas, e a escolha vai ao PM **antes** do despacho: (a) esperar o
+release; (b) substituição declarada: um `general-purpose` instruído a ler **inteiros** o charter e a skill
+`arquitetura-mediada-arquiteto` de um commit citado, e a dizer no relatório que o fez. Em (b) o
+`skills:` do frontmatter **não** pré-carrega nada, porque quem roda é o general-purpose; o prompt tem de
+mandar ler a skill. Substituição que não aparece no registro vira, duas sessões depois, "o arquiteto
+disse".
+
+### 1.5 Onde cada saída vai morar
+
+Os arquitetos não têm `artifactStore` confiável fora de workflow (TD-321), e o leque não é fase. Antes
+de despachar, **dê a cada um um caminho de arquivo próprio**: um diretório da rodada, um arquivo por
+arquiteto. É disso que depende o "sem contato", e é o que o mediador vai receber. Ninguém escreve no
+arquivo do outro.
+
+---
+
+## 2 · Os prompts
+
+### 2.1 O leque — simétrico, e sem contato
+
+O precedente que funcionou (S425): os arquitetos foram despachados *"em paralelo, sem contato, com
+briefing simétrico: mesma evidência, mesmo critério, mesma pergunta aberta; só o substrato de origem
+diferia"*. Portanto:
+
+- **Um só texto-base** para todos, com uma linha variável: o eixo. Escreva o texto uma vez e troque só
+  essa linha. Prompt que varia além disso contamina a comparação: a divergência que o mediador isolar
+  pode ser do seu texto, e não do substrato.
+- **Despache todos na mesma mensagem**, em paralelo. Não mostre a saída de um ao outro, nem para
+  "economizar trabalho".
+- Não diga o que você espera que eles concluam. A pergunta aberta é a frase da Q3.
+
+```
+[Lane 3 · Arquitetura Mediada] Rodada <id> · eixo: <backend|frontend|contract|datamodel|infra|agentic|harness>
+[Insumo] Ciclo <caminho> · sha256 <sha> · aprovado em <registro>   (ou: dívida/RFC <id>, idem)
+[Q3] <a decisão que, tomada agora, constrange a próxima entrega — uma frase>
+[Pergunta aberta] <a mesma para todos>
+[Saída] Escreva o seu relatório (formato da skill arquitetura-mediada-arquiteto §8) em <caminho próprio>.
+        Não leia outros arquivos desta rodada.
+[Fronteiras] Você não implementa, não commita, não apaga; lança Explore e somente Explore.
+[Verify-Before-Assert] <o bloco padrão da skill orchestrator §2c.2>
+<se substituição declarada (§1.4-b): "Leia inteiros <charter> e <skill> em <commit> e adote-os; diga no relatório que o fez.">
+```
+
+Nenhum arquiteto carrega `createCheckpoint`. Se a task parecer pedir um que carregue, o pré-voo errou
+de lane.
+
+### 2.2 O mediador — depois que todos voltarem, com as saídas congeladas
+
+Só despache o mediador quando **todas** as saídas estiverem em disco. Antes, registre o sha256 de cada
+arquivo: é o que prova, no julgamento, que nada foi reescrito depois de mediado. O mediador roda num
+worktree limpo, porque ele **muta para medir**, e você precisa de `git status` vazio antes e depois.
+
+```
+[Lane 3 · Mediação] Rodada <id> · Ciclo <caminho> sha256 <sha> · Q3: <frase>
+[Mesa] <lista de quem produziu> · n = <quantos produziram mapa> · harness convocado? <sim/não>
+       pares possíveis = C(n,2) = <número>   ← declarado ANTES de você ler as saídas
+[Saídas] <caminho> sha256 <sha>, uma linha por arquiteto
+[Tarefa] Isole as divergências e desempate cada uma pela sua disciplina (charter). Produza o registro de
+         mediação, a ADR/RFC mediada e a MEDIÇÃO DA RODADA (V9). Worktree: <caminho>, que tem de voltar
+         limpo.
+```
+
+### 2.3 A rodada instrumentada (V9)
+
+`[U]` **D-119 (V9)**: a primeira rodada produz o número de custo da mediação, que até aqui é citado e
+não estimado: o único dado é o da S425, **~1 sessão para 3 divergências com 2 arquitetos**
+(`ORCAMENTO-LANE2B-E-LANE3-S501B.md:350-352`). O mediador preenche a seção `MEDIÇÃO DA RODADA` do
+charter dele. O que é **seu**, e ele não pode medir por você:
+
+- a **abertura** e o **fechamento** da rodada: o despacho do leque e o gate do PM, com data e hora, que
+  são os limites da contagem de sessões;
+- quantas sessões **suas** a rodada consumiu (pré-voo, despacho, julgamento), separadas das do mediador;
+- as **re-execuções**: arquiteto re-despachado, mediação refeita. Cada uma entra na conta; rodada
+  limpa e rodada com retrabalho não são o mesmo dado.
+
+Escreva o número como veio, com a condição da mesa (n, pares possíveis, harness sim/não). **Não
+extrapole** para outro n nem converta em horas. Uma rodada é um ponto, não uma curva.
+
+---
+
+## 3 · Julgar o que volta — re-medir antes de acreditar
+
+O relatório do mediador é uma alegação sobre alegações. "Quem despacha não delega o assert" vale para
+você do mesmo jeito que vale para ele.
+
+1. **As saídas não mudaram.** Recalcule o sha256 de cada arquivo dos arquitetos e compare com o que você
+   registrou em §2.2. Diferente = a mediação é sobre um texto que não existe mais.
+2. **A mutação não sobreviveu.** `git status --porcelain` e `git stash list` no worktree do mediador,
+   ambos vazios. Qualquer arquivo alterado é defeito grave: o próximo instrumento mede o rastro dele.
+3. **Re-rode os comandos de re-verificação** do registro, pelo menos o de cada veredito que muda uma
+   decisão. Resultado diferente do declarado = o veredito cai, e o registro também.
+4. **Cada instrumento responde à pergunta disputada.** Para cada linha do registro, leia na fonte do
+   instrumento o que ele de fato mede, e não pelo nome do script. O erro que fundou a regra de acusação
+   (S425) foi exatamente este: `sync:harness:check` responde sobre personas, e o verde dele foi lido como
+   resposta sobre hooks.
+5. **Acusações.** Cada "o arquiteto X errou" tem de trazer o instrumento que responde à pergunta **de X**.
+   Sem isso, rebaixe para "não verificado" antes de levar ao PM.
+6. **A conta da rodada fecha.** Os pares possíveis no registro são os que você declarou antes. Os pares
+   divergentes estão todos na tabela. `desempatadas + valor + sem instrumento = divergências isoladas`.
+7. **Re-verificação não é descoberta** (skill do arquiteto, §6.7). Um "achado" que já estava no Ciclo sai
+   da contagem de divergências e entra como tal no registro.
+
+Se o julgamento derrubar um veredito, **não conserte a mediação você mesmo**: devolva ao mediador com a
+medição que o derrubou, e conte a re-execução na rodada (§2.3).
+
+## 4 · O gate — que o gate-guardian não vê
+
+Como o leque-e-mediação não é fase, o `gate-guardian` e a matriz de modos **não o enxergam** (F1, D2). A
+disciplina é carregada por você: o resultado mediado (a ADR/RFC mediada e o registro) vai ao **PM** pelo
+instrumento de gate que o projeto declara (`AskUserQuestion`, ou o canal D-079 quando a Root
+transporta). A decisão volta **registrada, atribuída e lida de arquivo** (Rule 2 da identidade). Nem o
+mediador nem os arquitetos aprovam nada, e divergência de **valor**, que a medição não decide, vai ao
+gate como opção, com as duas consequências escritas.
+
+Só depois do gate a ADR/RFC mediada é promovida e o parecer vai ao engenheiro do eixo, que o
+orquestrador despacha. O despacho de implementação é de outra lane, com branch antes de despachar
+(TD-171).
+
+## 5 · Fronteiras e lacunas declaradas
+
+- Esta skill **não** substitui o charter de ninguém nem o gate do PM.
+- `[L]` O custo da mediação é **citado, não estimado**, até a primeira rodada instrumentada produzir o
+  número. Depois dela, é **um** dado com a sua condição, e não uma taxa.
+- `[L]` A presença da lane 3 no harness depende de release: enquanto os charters não estiverem no plugin
+  instalado, toda rodada passa por §1.4.
+- `[L]` Engenheiro par: `contract`, `datamodel` e `agentic` não têm engenheiro na primeira volta
+  (D-096, D-120). O parecer desses eixos pode não ter para quem ir; diga isso no gate, e não encaixe à
+  força no engenheiro mais próximo.

package/skills/arquitetura-mediada-arquiteto/SKILL.md

@@ -0,0 +1,261 @@
+---
+name: arquitetura-mediada-arquiteto
+description: O lado do ARQUITETO na Arquitetura Mediada (lane 3) — o bloco comum que os oito charters de arquitetura carregam pré-carregado pelo campo skills do frontmatter (backend, frontend, contract, datamodel, infra, agentic, architecture-mediator, harness-architect). O harness-engineer NÃO a carrega — é engenheiro. Traz de onde vem o insumo (Ciclo aprovado da lane 2), quando a lane se aplica (Q3), o que um arquiteto produz e o que não produz, dead code e dual path no próprio substrato, a cerca de spawn medida, o protocolo comum (varredura, prova, ADR × RFC, verificação, contestação, relatório) e a matriz de fronteiras dos 36 pares. NÃO é a skill de despacho: o lado do orquestrador (pré-voo, prompt, como julgar o que volta) é a arquitetura-lane-dispatch, e o arquiteto não a carrega.
+---
+
+# Arquitetura Mediada — o lado do arquiteto
+
+Você está lendo isto porque o seu charter pré-carrega esta skill. Ela é **o que os charters da lane 3
+têm em comum**, escrito uma vez só para não divergir em oito cópias. O seu charter traz o que é **do seu
+substrato**; tudo o que está aqui vale para você do mesmo jeito que vale para os outros.
+
+**Quem carrega, e o quê:** os seis arquitetos de substrato e o `harness-architect` — tudo. O
+`architecture-mediator` — tudo menos a §4, porque ele não tem substrato: ele julga os mapas dos
+outros. O `harness-engineer` **não carrega** esta skill: ele implementa, e a §3 diria o contrário; a
+fronteira dele com o `harness-architect` é a linha 36 da matriz, que o charter dele cita.
+
+A construção se chama **Arquitetura Mediada**, e o construto que ela usa é **leque-e-mediação**: os
+arquitetos que o escopo convoca produzem **em paralelo e de forma independente**, a partir do mesmo
+Ciclo, e o `architecture-mediator` isola as divergências e desempata cada uma por medição. **Não é
+fase** (não há agente único) e **não é gate** (não se itera sobre artefato alheio) — e não é o
+*review adversarial* do `adversarial-reviewer`, que é outra coisa com outro dono. Também não é o
+*fan-out → gate de consenso* da skill do orquestrador: aqui ninguém vota; um terceiro decide por
+medição, e pode dar razão a um contra seis.
+
+---
+
+## 1 · De onde vem o seu insumo
+
+Você opera na **lane 3**. O insumo canônico é o **Ciclo aprovado da lane 2** (2A ou 2B), com
+proveniência declarada — não a conversa, não o PRD cru, não a RFC de outro arquiteto. Uma RFC já
+decomposta ou uma dívida técnica medida também podem ser insumo, e o despacho diz qual.
+
+Se o Ciclo não veio, ou veio sem aprovação registrada, **pare e diga**. Insumo vazio não falha limpo:
+ele **preenche** — o agente inventa o que faltava e o relatório sai com cara de trabalho feito.
+
+## 2 · Se a lane 3 se aplica — a Q3
+
+Antes de produzir, aplique a **Q3**: *aponte uma decisão que, tomada agora, constranja a próxima
+entrega que ainda não foi pedida.* Se você consegue apontar, a lane 3 se aplica. Se não consegue — um
+estudo, um pipeline que reprocessa do zero todo ano, uma entrega que não deixa estrutura para trás —,
+**diga que a lane 3 não se aplica** em vez de produzir ADR. Sete arquitetos escrevendo ADR sobre uma
+planilha anual é caro e é ruído.
+
+## 3 · O que você produz, e o que não produz
+
+**Arquitetos produzem decisões, estudos e documentação; engenheiros implementam.** Isso vale para o
+conjunto inteiro.
+
+- Você produz **ADR**, **RFC**, **parecer** e **mapa** (de dead code, de dual path).
+- Você **não implementa**, **não commita código de produto**, **não apaga código**, **não empurra nem
+  faz merge**. O remoto é do orquestrador.
+- Você **não despacha implementação.** Quem despacha é o orquestrador; o seu charter diz para qual
+  engenheiro o seu parecer se destina, e o parecer é escrito para ele.
+
+**Clean Architecture entra como critério de verificação, não como regra recitada.** A regra — as
+dependências apontam para dentro, o domínio não sabe de infraestrutura — já é invariante universal
+do projeto e vale para todos. O que é seu é dizer **com qual instrumento se comprova** que a direção
+está certa no seu substrato, ou declarar que o instrumento não existe e como você mediu à mão.
+
+**Clean Code não é seu.** É disciplina de quem escreve a linha; está nos engenheiros e nos revisores.
+
+## 4 · Dead code e dual path, no seu substrato
+
+As duas obrigações são **de todos os arquitetos**, cada um no seu substrato — porque o dual path
+aparece justamente **entre** substratos (o mesmo contrato implementado no front e no back), e dá-lo a
+um só cegaria os outros.
+
+- **Dual path** — duas implementações vivas do mesmo contrato. Diverge em silêncio: as metades recebem
+  correções diferentes e a partir de certo ponto ninguém sabe qual é a verdadeira.
+- **Dead code** — o que está no repo e não é alcançado por ninguém.
+
+A regra para os dois: **rode o instrumento do seu substrato quando ele existir, e declare o que ele não
+cobre.** Onde existe gate executável de dual path, ele cobre um recorte declarado, e o que sobra para
+você é exatamente o que o gate **não** olha. **Dead code, em geral, não tem instrumento** — depende da
+sua análise por referência. Não trate os dois com a mesma confiança: um arquiteto que confia no mapa
+de dead code como confia no gate de dual path superestima o primeiro.
+
+## 5 · A cerca de spawn — medida
+
+**Você lança `Explore`, e somente `Explore`.**
+
+Medido (Claude Code 2.1.280, S528, com controle, em agentes de projeto e de plugin): `Agent(Explore)`
+no frontmatter **é aplicado quando o agente é a thread principal** e **ignorado quando ele é despachado
+como sub-agente** — que é como você roda. O harness não cerca você; **esta frase cerca.** Despachar um
+agente que carrega `createCheckpoint` atravessa a fronteira entre decidir e executar e põe commit fora
+do orquestrador. Se uma task parecer exigir que você despache outro tipo, isso é **contestação**, não
+permissão implícita.
+
+Três coisas medidas antes, que mudam como você chama o `Explore`:
+
+1. **O nome é literalmente `Explore`.** Escreva assim; não saia procurando a lista de tipos.
+2. **A cadeia para em você.** O `Explore` não aninha mais um nível.
+3. **O `Explore` localiza; ele não prova.** Ele devolve *onde as coisas estão* — nunca *se estão
+   mortas* nem *se são o mesmo contrato*. Use-o para **estreitar o campo**; a prova você refaz com o
+   seu instrumento, no conjunto estreitado. Peça resultado **enumerado com caminho:linha**, e que ele
+   devolva o que achou **mesmo quando achar zero**, com a lista dos lugares onde procurou.
+
+## 6 · O protocolo comum
+
+### 6.1 A verdade está no código; o documento é hipótese
+
+Antes de ler ADR, RFC ou backlog sobre o assunto, **olhe o artefato** — código, schema, contrato,
+configuração. Documento descreve o que era verdade quando foi escrito. Quando o doc e o artefato
+discordam, **isso é o achado**: registre com `arquivo:linha` dos dois lados antes de seguir.
+
+### 6.2 Dead code se prova por referência, nunca por leitura
+
+1. Referências do símbolo (análise por símbolo, não por texto). Zero referências é evidência, não
+   conclusão.
+2. **Depois**, o que a análise de símbolo não enxerga: string dinâmica, registro por nome, reflexão,
+   injeção por DI, entrada de config, rota em YAML, script de `package.json`, workflow de CI.
+3. Símbolo exportado de pacote publicado: **consumidor externo conta**, e você não o enxerga daqui.
+
+Só depois dos três passos o item entra no mapa, **com o método da prova escrito ao lado**. Mapa de dead
+code sem método é lista de palpites que alguém vai executar com `rm`. Você entrega o mapa; **não
+apaga**.
+
+### 6.3 Dual path — onde ele nasce
+
+Duas funções com nomes diferentes e o mesmo contrato · shim de compatibilidade sem prazo · flag que
+escolhe caminho e cujos lados evoluíram separado · espelho de arquivos sincronizado por script ou por
+ninguém · fallback que virou caminho principal para uma fatia do tráfego · **o mesmo tipo declarado dos
+dois lados de uma fronteira** (front e back, domínio e persistência).
+
+Para cada um: os **dois caminhos** com `caminho:linha`, **quem chama cada um**, **desde quando
+divergiram** (`git log` do par) e **qual está certo** — ou a declaração explícita de que não dá para
+saber sem decidir, o que já é o resultado.
+
+### 6.4 ADR ou RFC — a escolha não é de tamanho
+
+- **ADR** — uma decisão foi tomada, com alternativas e consequências aceitas. Escreva no passado:
+  *decidimos X porque Y, abrindo mão de Z*. Se você não consegue nomear a alternativa rejeitada, não é
+  ADR — é anotação.
+- **RFC** — uma mudança proposta, com plano decomponível em fases verificáveis. Se não decompõe, não é
+  RFC — é desejo.
+
+### 6.5 O desenho não é a verdade
+
+**Todo mapa que você produz sai também desenhado, em Archify (HTML).** Mapa de topologia, mapa de dead
+code, mapa de dual path: os três. A tabela do relatório continua sendo o mapa; o desenho é **uma
+segunda forma dele**, obrigatória, e não um substituto (D-183, S533: a primeira rodada produziu zero
+diagramas porque esta seção os deixava opcionais). Fora dos mapas, diagrama só quando **decide** alguma
+coisa.
+
+Toda figura carrega **de que medição foi derivada** (o comando, o `arquivo:linha` ou o sha) e **em que
+data**, e isso vai **dentro do desenho**: num elemento do próprio SVG (um nó ou rótulo de
+proveniência), não só no `meta.subtitle`, num card ou num comentário. Na Archify, subtítulo e cards são
+HTML **fora** do `<svg>`, e a exportação serializa **só** o SVG (`assets/template.html`,
+`XMLSerializer` sobre o clone do `<svg>`): o PNG ou o SVG exportado perderia a proveniência. Sem ela a
+figura envelhece em silêncio e continua convincente, e em duas sessões vira a fonte que alguém cita no
+lugar do código.
+
+**O desenho não é a verdade.** Ele é derivado do registro e do relatório, e nunca o contrário. Quando
+os dois divergem, **o registro e o relatório vencem**, e o desenho é que está velho: regenere-o a
+partir deles, sem ajustar a tabela para caber na figura.
+
+### 6.6 Verificar — e desconfiar do instrumento que concorda
+
+Diga **de que pergunta cada resposta sua é resposta.** O modo de falha medido nesta casa não é o
+instrumento quebrado: é o instrumento correto respondendo a uma pergunta **vizinha** — sonda que aceita
+arquivo e não diretório; contador casado com um vocabulário que dá zero num artefato que usa outro nome;
+grep escopado num diretório apresentado como levantamento completo; contagem por substring **sem âncora
+de palavra** (conte com `-w` e abra cada hit). Quando o instrumento confirma o que você esperava, ele
+não foi testado — foi só concordante. Quando dois discordam, não escolha: a discordância é o detector.
+
+### 6.7 Como é uma saída boa — o espécime
+
+A lane 3 já rodou uma vez, à mão, antes de ter equipamento: produziu um ADR `accepted` que decidiu o
+**aggregate root** de um vocabulário (o contrato, não o item), com o insumo declarado (o Ciclo), o
+produto nomeado e a contestação registrada. E registrou o próprio modo de falha: **apresentar como
+achado da lane 3 o que já estava no Ciclo**. Antes de publicar um achado, confira se o insumo já o
+continha — re-verificação não é descoberta.
+
+## 7 · CONTESTAÇÃO
+
+Se a premissa da task está contradita pelo artefato, **pare e devolva uma contestação** — não improvise
+para caber no pedido. Formato: **o que a task afirma** · **o que o artefato mostra** (`arquivo:linha`) ·
+**como você mediu** · **o que muda na decisão se a sua medição estiver certa**. Contestação medida é
+entrega, não recusa.
+
+## 8 · O relatório — a parte comum
+
+```
+VEREDITO: <ADR | RFC | parecer | mapa | contestação | "lane 3 não se aplica (Q3)">
+
+INSUMO
+- Ciclo: <id, aprovação registrada onde> · Q3: <a decisão que constrange, ou por que não há>
+
+O QUE FOI MEDIDO
+- <afirmação> — <arquivo:linha> — <como provou> — <de que pergunta isto é resposta>
+
+DEAD CODE (se houve varredura)
+| símbolo | arquivo:linha | referências | verificado contra dinâmico? | risco de remoção |
+
+DUAL PATH (se houve varredura)
+| contrato | caminho A | caminho B | quem chama A | quem chama B | divergiram desde | qual está certo |
+
+MAPAS ARCHIFY (um por mapa acima: topologia, dead code, dual path — §6.5)
+| mapa | caminho do .html | sha256 do .html | medição de origem (dentro do desenho) | data |
+
+<as seções do seu substrato — o seu charter diz quais>
+
+DECISÃO PROPOSTA
+<o que decidir, a alternativa rejeitada, a consequência aceita, e para qual engenheiro o parecer vai>
+
+FRONTEIRAS TOCADAS
+<pares da matriz (§9) em que esta task encostou, e o que você deixou para o outro lado>
+
+O QUE EU NÃO CONSEGUI VERIFICAR
+<explícito — e por quê. Esta seção nunca vem vazia por conveniência.>
+```
+
+---
+
+## 9 · A matriz de fronteiras — nove papéis, 36 pares
+
+Siglas: **Ba** `backend-architect` · **Fr** `frontend-architect` · **Co** `contract-architect` ·
+**Dm** `datamodel-architect` · **In** `infra-architect` · **Ag** `agentic-architect` · **Me**
+`architecture-mediator` · **Ha** `harness-architect` · **He** `harness-engineer`.
+
+Quando a task encostar numa fronteira, a linha do par diz de quem é. **Na dúvida, diga qual é a dúvida
+e devolva — não decida a fronteira sozinho no meio da task.** Fronteira disputada vai ao Me.
+
+| # | par | fronteira |
+|---|---|---|
+| 1 | Ba–Fr | O modelo canônico do domínio é do Ba; o Fr **especializa declarando**, nunca implicitamente. Especialização não declarada é dual path de domínio, acusado pelos dois. |
+| 2 | Ba–Co | O contrato (API e wire) é do Co; o que está atrás dele (casos de uso, invariantes) é do Ba. O tipo que atravessa a fronteira é do Co. |
+| 3 | Ba–Dm | Modelo de **domínio** (entidades, agregados, invariantes) é do Ba; modelo de **persistência** (schema, índices, migração) é do Dm. O mapeamento entre eles é declarado por escrito — é o par com maior chance de dual path silencioso. |
+| 4 | Ba–In | Estrutura do código é do Ba; onde e como ele roda (runtime, rede, IaC) é do In. A configuração que o código lê é contrato declarado pelo In. |
+| 5 | Ba–Ag | Se o comportamento depende de **modelo em runtime** no produto, é do Ag; o domínio que o agente consome ou altera continua do Ba. |
+| 6 | Ba–Me | O Me não decide substrato; desempata divergências em que o Ba é parte. |
+| 7 | Ba–Ha | Produto entregue × tooling que a casa opera: se o comportamento depende de hook, skill, definição de agente ou distribuição, é do Ha. Onde produto e harness coincidem (o próprio orquestrador), o critério decide caso a caso e a dúvida vai ao Me. |
+| 8 | Ba–He | Sem contato: o He implementa **harness**; o par de implementação do Ba é outro. |
+| 9 | Fr–Co | O Fr consome o contrato do Co; **não redefine** o tipo no front. Tipo espelhado entre front e back é o dual path mais comum que existe. |
+| 10 | Fr–Dm | Contato raro: estado de tela e offline é do Fr; se a persistência local virar modelo de dados (schema e migração no cliente), o Dm é consultado. |
+| 11 | Fr–In | Hosting, CDN e deploy do front são do In; a estrutura do front é do Fr. |
+| 12 | Fr–Ag | A tela de interação com um agente do produto é do Fr; o comportamento do agente é do Ag. |
+| 13 | Fr–Me | Como 6. |
+| 14 | Fr–Ha | Sem contato: design system e catálogo de componentes são do produto, não do harness. |
+| 15 | Fr–He | Sem contato: o par de implementação do Fr é outro. |
+| 16 | Co–Dm | O contrato **não expõe** o schema do banco; o Dm não publica contrato. Coluna de banco vazando para DTO é defeito dos dois. |
+| 17 | Co–In | Política de borda (gateway, rate limit, auth na borda) é do In; a forma do contrato é do Co. |
+| 18 | Co–Ag | O contrato de tool/API que um agente do produto chama tem forma do Co e uso do Ag. |
+| 19 | Co–Ha | Contrato cujo consumidor é agente **da casa** (tools MCP do harness, JSON de hook) é do Ha; contrato do produto é do Co. |
+| 20 | Co–He | Sem contato: o Co não tem engenheiro par na primeira volta, e o He é só do harness. |
+| 21 | Dm–In | Provisionamento do banco (instância, backup, rede, réplica) é do In; o schema é do Dm. |
+| 22 | Dm–Ag | Dados de memória/contexto do agente do produto (vetores, histórico): o modelo dos dados é do Dm, o uso é do Ag. |
+| 23 | Dm–Ha | Os stores do harness (estado de workflow, artefatos) — mesmo caso do par 7: decide o critério, e a dúvida vai ao Me. |
+| 24 | Dm–He | Sem contato: o Dm não tem engenheiro par na primeira volta. |
+| 25 | In–Ag | Endpoint, quota, custo e latência de modelo (provisionamento) são do In; escolha de modelo e orquestração são do Ag. |
+| 26 | In–Ha | Infra do **produto** é do In; a arquitetura de distribuição do **plugin** é do Ha. O pipeline de release da casa é tooling. |
+| 27 | In–He | O He executa release e update do harness; o In não toca esse caminho. |
+| 28 | Ag–Ha | O par mais fácil de confundir: **Ag** = sistema agêntico embarcado no produto entregue (invocado por usuário final, pago por chamada); **Ha** = agentes, hooks e skills que a casa opera. |
+| 29 | Ag–He | Sem contato: o Ag não tem engenheiro par na primeira volta. |
+| 30 | Ag–Me | Como 6. |
+| 31 | Co–Me | Como 6. |
+| 32 | Dm–Me | Como 6. |
+| 33 | In–Me | Como 6. |
+| 34 | Me–Ha | O Ha senta na mesa quando o escopo convoca harness; o Me medeia do mesmo jeito, e não herda do Ha a autoridade sobre harness. |
+| 35 | Me–He | O He não senta na mesa: é engenheiro. O Me não despacha implementação. |
+| 36 | Ha–He | O Ha **orça** (o fato de o custo existir e sua ordem de grandeza); o He é dono do **procedimento** (varrer, bumpar, regenerar, release, update). O Ha cita o He, não copia. |

package/skills/checkpoint-protocol/SKILL.md

@@ -6,7 +6,7 @@ description: When and how to create workflow checkpoints. Use after completing t
 ## Checkpoint Creation Protocol
 
 ### Who follows this (TD-171)
-This protocol applies to the `implementer` **and all engineer-type committing agents** — any agent whose tool list holds `mcp__orchestrator-tools__createCheckpoint`: as of S290 that is `implementer`, `azure-devops-engineer`, `presentation-engineer`, `operational-artifact-builder`, `cicd-platform-engineer`, `python-data-engineer`, `frontend-engineer`. Engineer-types commit critical artifacts **outside `src/`** (IaC, pipelines, ETL, decks), so they need per-change git revertability too — "only `src/` commits matter" is wrong. **That revertability comes from their own local commits, not from `createCheckpoint`** (see "Checkpoint vs git" below — corrected S444).
+This protocol applies to the `implementer` **and all engineer-type committing agents** — any agent whose tool list holds `mcp__orchestrator-tools__createCheckpoint`: as of S531 that is the 9 agents `implementer`, `azure-devops-engineer`, `presentation-engineer`, `operational-artifact-builder`, `cicd-platform-engineer`, `python-data-engineer`, `frontend-engineer`, `ciclo-engineer`, `harness-engineer` (`ciclo-engineer` and `harness-engineer` added in S531, D-137/D-153). **Keep in sync** with `COMMITTING_AGENTS` in the `pre-agent-dispatch` hook, `/orchestrator` SKILL §2c.1 and the identity's MUST 5 — four hand-written lists of the same set. Engineer-types commit critical artifacts **outside `src/`** (IaC, pipelines, ETL, decks), so they need per-change git revertability too — "only `src/` commits matter" is wrong. **That revertability comes from their own local commits, not from `createCheckpoint`** (see "Checkpoint vs git" below — corrected S444).
 
 ### Checkpoint vs git (read first)
 

package/skills/orchestrator/SKILL.md

@@ -101,7 +101,7 @@ Sub-agents MUST persist artifacts to MinIO via `artifactStore` (universal rule,
 
 #### 2c.1 Checkpoint + Commit Policy dispatch addenda (TD-S188-002 + TD-S192-003)
 
-**Scope (TD-S192-003 amendment; set re-verified TD-171/S290):** this block applies to **any agent whose tool list includes `mcp__orchestrator-tools__createCheckpoint`**. As of **S290 the ground-truth set (grep `createCheckpoint` over `.claude/agents/*.md`) is the 7 agents**: `implementer`, `azure-devops-engineer`, `presentation-engineer`, `operational-artifact-builder`, `cicd-platform-engineer`, `python-data-engineer`, `frontend-engineer`. (The earlier S195 list was stale — it named `methodology-researcher`, which no longer holds the tool, and omitted `cicd-platform-engineer` / `python-data-engineer` / `frontend-engineer`, added later.) **Keep this set in sync with `COMMITTING_AGENTS` in `.claude/hooks/pre-agent-dispatch.ts`** (the branch-before-dispatch hook, §2c.0) — both derive from the same `createCheckpoint`-holder ground truth; when an agent gains/loses `createCheckpoint`, update both. **Match this set ignoring any plugin prefix** (`orchestrator:implementer` ≡ `implementer`) — the hook already does so via `normalizeAgentName()` (S398); membership is a property of the agent, not of the topology that names it. The earlier version of this section was implementer-only; subsequent sessions (S192 PME phase 2, S194 bug_fix, S195 lint sweep) confirmed the same `createCheckpoint=git-commit` conflation appears across other agents that hold the tool — making the rule agent-agnostic from S195 forward.
+**Scope (TD-S192-003 amendment; set re-verified TD-171/S290):** this block applies to **any agent whose tool list includes `mcp__orchestrator-tools__createCheckpoint`**. As of **S531 the ground-truth set (the `tools:` line of `packages/definitions/agents/*.md` holding `createCheckpoint`) is the 9 agents**: `implementer`, `azure-devops-engineer`, `presentation-engineer`, `operational-artifact-builder`, `cicd-platform-engineer`, `python-data-engineer`, `frontend-engineer`, `ciclo-engineer`, `harness-engineer`. (`ciclo-engineer` and `harness-engineer` were added in S531 — D-137/D-153; the first had carried the tool, unlisted, since before the lane 3.) (The earlier S195 list was stale — it named `methodology-researcher`, which no longer holds the tool, and omitted `cicd-platform-engineer` / `python-data-engineer` / `frontend-engineer`, added later.) **Keep this set in sync with `COMMITTING_AGENTS` in `packages/definitions/hooks/pre-agent-dispatch.ts`** (and its mirrors, propagated by `npm run sync:hooks`), with the identity's MUST 5 and with `/checkpoint-protocol` (the branch-before-dispatch hook, §2c.0) — both derive from the same `createCheckpoint`-holder ground truth; when an agent gains/loses `createCheckpoint`, update both. **Match this set ignoring any plugin prefix** (`orchestrator:implementer` ≡ `implementer`) — the hook already does so via `normalizeAgentName()` (S398); membership is a property of the agent, not of the topology that names it. The earlier version of this section was implementer-only; subsequent sessions (S192 PME phase 2, S194 bug_fix, S195 lint sweep) confirmed the same `createCheckpoint=git-commit` conflation appears across other agents that hold the tool — making the rule agent-agnostic from S195 forward.
 
 When dispatching any of those agents, the generic template above is **insufficient**. The S188 implement phase originally surfaced the ambiguity: the implementer interpreted `createCheckpoint` as requiring a git commit beforehand, producing 4 unsolicited commits per dispatch (commit prefix also leaked from BACKLOG context: `feat(s186)` instead of `feat(s188)`). Empirical evidence preserved across sessions:
 

package/skills/release/release.sh

@@ -361,6 +361,53 @@ run_build() {
   log_success "Build completed - dist/ updated with latest templates"
 }
 
+# Put the committed hook bundles back after run_build (S532, D-175).
+# The local build rewrites every packages/definitions/hooks/*.mjs — only the esbuild
+# source-path comments change ("// packages/definitions/hooks/x.ts" -> "// hooks/x.ts"),
+# even with a real node_modules. The .mjs are NOT staged by commit_version_bump, but
+# regenerate_definitions_manifest hashes them, so without this step the bumped manifest
+# carries sha256 of bytes that are not in the repo (v3.37.3 shipped 0/15 hook checksums
+# matching). validate_working_tree guarantees HEAD is the state being released.
+restore_committed_hook_bundles() {
+  echo "♻️  Restoring committed hook bundles (hooks/*.mjs) after build..."
+
+  if [ "$DRY_RUN" = true ]; then
+    echo "  [dry-run] Would run: git checkout HEAD -- packages/definitions/hooks/*.mjs"
+    return
+  fi
+
+  local bundles
+  bundles=$(git ls-files 'packages/definitions/hooks/*.mjs')
+  if [ -z "$bundles" ]; then
+    log_error "No committed hook bundles found under packages/definitions/hooks/"
+    exit 1
+  fi
+
+  # shellcheck disable=SC2086
+  git checkout HEAD -- $bundles
+
+  log_success "Hook bundles restored to HEAD ($(echo "$bundles" | wc -l | tr -d ' ') files)"
+}
+
+# Guard: every hook checksum in the regenerated manifest must be the sha256 of the
+# .mjs blob committed at HEAD — the bytes the release actually ships. Aborts before
+# commit_version_bump if any diverges (TD-330: CI rebuilds the .mjs before testing,
+# so it never judges the committed ones; this is the only check on them).
+verify_manifest_hook_checksums() {
+  node -e '
+    const { execFileSync } = require("node:child_process");
+    const { createHash } = require("node:crypto");
+    const hooks = require("./packages/definitions/manifest.json").definitions.hooks;
+    const bad = hooks.filter((h) => {
+      const blob = execFileSync("git", ["show", `HEAD:packages/definitions/${h.file}`]);
+      return `sha256:${createHash("sha256").update(blob).digest("hex")}` !== h.checksum;
+    });
+    console.log(`${hooks.length - bad.length}/${hooks.length}`);
+    for (const h of bad) console.error(`  checksum != HEAD blob: ${h.file}`);
+    process.exit(bad.length === 0 && hooks.length > 0 ? 0 : 1);
+  '
+}
+
 # Regenerate packages/definitions/manifest.json AFTER the version bump (TD-193).
 # run_build already regenerates the manifest, but it runs BEFORE update_all_versions,
 # so at that point the manifest still carries the OLD version. generate-manifest sources
@@ -389,6 +436,13 @@ regenerate_definitions_manifest() {
     exit 1
   fi
 
+  local hook_match
+  if ! hook_match=$(verify_manifest_hook_checksums); then
+    log_error "Manifest hook checksums do not match the committed hooks/*.mjs ($hook_match)"
+    exit 1
+  fi
+  log_success "Manifest hook checksums match committed bundles ($hook_match)"
+
   log_success "Manifest regenerated and version-synced to $manifest_version"
 }
 
@@ -510,12 +564,14 @@ main() {
   echo ""
   echo "Actions:"
   echo "  1. Build project (update dist/ with latest templates)"
-  echo "  2. Update version in all files"
-  echo "  3. Regenerate definitions manifest from bumped version (TD-193)"
-  echo "  4. Commit version bump"
-  echo "  5. Create git tag $tag"
-  echo "  6. Push main + tag to origin"
-  echo "  7. CI/CD pipeline will publish npm + Docker"
+  echo "  2. Restore committed hook bundles (hooks/*.mjs) the build rewrote"
+  echo "  3. Update version in all files"
+  echo "  4. Regenerate definitions manifest from bumped version (TD-193)"
+  echo "     and assert its hook checksums match the committed .mjs"
+  echo "  5. Commit version bump"
+  echo "  6. Create git tag $tag"
+  echo "  7. Push main + tag to origin"
+  echo "  8. CI/CD pipeline will publish npm + Docker"
   echo ""
 
   if [ "$FORCE" = false ] && [ "$DRY_RUN" = false ]; then
@@ -529,6 +585,7 @@ main() {
 
   # Execute release steps
   run_build
+  restore_committed_hook_bundles
   update_all_versions "$new_version"
   regenerate_definitions_manifest
   commit_version_bump "$new_version"