@daniellins/power-claude 0.16.3

package/template/.claude/commands/power/forge.md

@@ -0,0 +1,224 @@
+---
+description: "Conduz `*new` do pod squad-forge PELO MOTOR determinístico (pc-run-pod.cjs): cria agente/pod/skill novo com entrevista de escopo, veto de discovery, checkpoint de red-team e checkpoint de registro, e memória curada. Use para: criar agente, pod ou skill novo a partir de um pedido de negócio."
+---
+
+Você conduz `*new` do pod `squad-forge` **pelo motor** `scripts/pc-run-pod.cjs`.
+Não existe caminho "leia `forge-chief.md` e siga o pedido": todo passo é despachado, verificado
+em disco e liberado pelo motor — é assim que o veto da etapa `discovery` (escopo registrado, os 3
+campos canônicos preenchidos) e os 2 checkpoints bloqueantes (`red-team`, `register`) deixam de
+depender de o agente seguir a prosa direito. `squad-forge` fabrica os outros pods do framework — é
+por isso que ele próprio passa a nascer sob o mesmo padrão que impõe aos demais.
+
+Pedido do usuário: $ARGUMENTS
+
+---
+
+## Passo 0 — a entrevista de escopo (G1) + ECO, self-contida
+
+**Aviso de persistência, ANTES de qualquer pergunta:** tudo que o dono responder abaixo viaja
+**verbatim** para o `--task-ref` e fica **gravado permanentemente** no `state.json` da run, em
+disco — inclusive as respostas do item 6 (forma de clone) e do item 7 (degrau de voz do PRÓPRIO
+dono, se o pod for de conteúdo), que podem carregar material de voz/persona. Calibre o que responde
+sabendo disso agora — o ECO ao final é confirmação, não a sua primeira chance de decidir o que
+revelar.
+
+Pergunte, na ordem, os **7 itens do G1** (`pods/squad-forge/tasks/pipeline.md`, réplica self-contida
+— não é preciso ler o arquivo para conduzir esta entrevista):
+
+1. **Job-to-be-done** em uma frase, sem "e também".
+2. **Comandos necessários** — nome de cada um e o que entrega.
+3. **Conhecimento consumido** por comando — já existe em `knowledge/`? precisa de DNA? precisa ser
+   criado?
+4. **Onde vive** — aplicando a árvore comando × agente × pod (`pods/squad-forge/README.md`).
+5. **Tier** — classificação SIMPLE / STANDARD/COMPLEX pelo gate de proporcionalidade
+   (`node scripts/forge-assess-tier.cjs <spec.json>`), com os gatilhos registrados.
+6. **Forma do clone**, se clona um especialista — persona completa (voice DNA, custo maior por
+   ativação, trade-off informado) ou só metodologias (otimizado, default) — ou "não é clone"
+   explícito.
+7. **Degrau de voz do DONO**, se o pod é de CONTEÚDO (produz peça assinada por alguém) — eixo
+   SEPARADO do item 6 (`ADR-013`/`ADR-027`: voz de QUEM assina, não de quem se clona): sem voz
+   (nenhuma checagem) / guia de estilo (bloco `voz:` em `knowledge/dono.yaml` + veto léxico) / DNA
+   completo do dono (`mind-extractor`, custo informado) — ou "não é pod de conteúdo" explícito.
+
+Mais os **3 campos canônicos** que o veto da etapa `discovery` do `wf-forge.yaml` já verifica — para
+o **POD SENDO CRIADO**, não para o `squad-forge` — cada um **DECLARADO com conteúdo OU RECUSADO com
+razão**, nunca deixado de fora:
+
+8. **Ritmo** — algum checkpoint do pod novo pode ser pulado em modo autônomo, ou nenhum é pulável?
+   `{ step, skip_modes }` — ou `nao_se_aplica` explícito, com razão.
+9. **Contrato de entrada** — a etapa inicial do pod novo recebe mais de uma forma de entrada válida,
+   ou só uma? `{ step, valores }` (≥2 valores) — ou `nao_se_aplica` explícito, com razão.
+10. **Entregável** — alguma etapa do pod novo produz artefato binário/arquivo que precisa existir em
+    disco, ou todas produzem só texto? `{ step }` — ou `nao_se_aplica` explícito, com razão.
+
+**ECO OBRIGATÓRIO em qualquer ritmo:** depois de colher os 10 itens, mostre o `--task-ref` inteiro
+que você vai usar (a entrevista completa, formatada) e só inicie após o "ok" do dono. Nada começa
+sem ele ter visto o valor exato — e sem já ter sido avisado, no início, do que acontece com o que ele
+disse.
+
+## Passo 1 — `start` (linha literal)
+
+```bash
+node scripts/pc-run-pod.cjs start squad-forge forge \
+  --workflow-file pods/squad-forge/workflows/wf-forge.yaml \
+  --mode <interactive|yolo> \
+  --task-ref "<entrevista completa do G1 + 3 campos canônicos, já ecoada e confirmada>"
+```
+
+Sempre pela **flag** `--task-ref`, nunca posicional. Rode a partir da raiz do repo
+(`second-brain`); o `--pod-root` não é necessário — o motor deriva a raiz do pod pelo path do `wf`.
+
+O `start` imprime `[start] run <run-id> → <caminho do state.json>` e já emite o `[dispatch]` da
+etapa `discovery`, com o bloco `--- BRIEF ---` (o `next` NÃO é necessário para ver o brief — ele só
+avança a máquina depois que o subagente escrever o artefato). **Guarde o caminho do `state.json`**:
+todos os comandos seguintes usam `--state <caminho>`. O `--mode` é gravado no `state.json` como
+**rótulo** — o motor não ramifica por ele; o ritmo é responsabilidade deste comando.
+
+## Passo 2 — o laço (uma transição por chamada)
+
+```bash
+node scripts/pc-run-pod.cjs next    --state <state.json> --workflow-file pods/squad-forge/workflows/wf-forge.yaml
+node scripts/pc-run-pod.cjs status  --state <state.json> --workflow-file pods/squad-forge/workflows/wf-forge.yaml
+node scripts/pc-run-pod.cjs approve --state <state.json> --workflow-file pods/squad-forge/workflows/wf-forge.yaml
+node scripts/pc-run-pod.cjs revise  --state <state.json> --workflow-file pods/squad-forge/workflows/wf-forge.yaml
+node scripts/pc-run-pod.cjs abort   --state <state.json> --workflow-file pods/squad-forge/workflows/wf-forge.yaml
+```
+
+Uma sexta chamada, **fora** da máquina de estados — registra o comentário do dono no checkpoint como
+aprendizado do pod (SF11.5). Ela **não** transiciona nada; é chamada ANTES do `approve`/`revise`, e
+só quando o dono comentou (ver "Passo obrigatório do comando: pedir o comentário" abaixo):
+
+```bash
+node scripts/pod-memory-note.cjs --state <state.json> --workflow-file pods/squad-forge/workflows/wf-forge.yaml \
+  --step red-team|register --verdict approve|revise --file <arquivo com o comentário, escrito pela ferramenta Write>
+```
+
+O que fazer com cada saída:
+
+| Saída do motor | Significado | Sua ação |
+|---|---|---|
+| `[dispatch] etapa=<id>` + bloco `--- BRIEF ---` | o motor abriu a etapa e emitiu o brief | despache um **subagente FRESCO** (um por etapa, nunca reaproveitado) com o brief **VERBATIM**; quando ele voltar, chame `next` |
+| `[blocked] etapa=<id> motivo=verification_failed` + lista de falhas | o artefato em disco reprovou (forma ou veto) | a etapa continua `running` e a seguinte NÃO roda. Re-despache a MESMA etapa anexando as `failures` ao brief |
+| `[awaiting_approval] etapa=<id>` | verificação passou e a etapa tem checkpoint bloqueante | **PARE.** Só o dono destrava (`approve`/`revise`) — acontece em `red-team` e em `register` |
+| `[complete]` | todas as etapas `done` | reporte o pod registrado e encerre |
+| `[erro] …` (exit 1) | uso/estado inválido | reporte ao dono; nunca "conserte" editando o `state.json` |
+
+**Despacho do subagente (cada etapa): cole o brief inteiro, sem resumir.** O brief abre com a seção
+**"Leitura obrigatória ANTES de agir"**, que lista o arquivo do agente e o(s) `knowledge:` que o `wf`
+declara para a etapa — por path absoluto, na ordem declarada, com a existência já verificada em
+disco pelo motor. O brief também traz a linha `Tarefa:` com o `task-ref`, o path exato do artefato,
+o template, as `veto.assertions` que serão verificadas e o limite de autoridade. Não acrescente
+instrução que contradiga o brief.
+
+**Acréscimo obrigatório, só no despacho da etapa `discovery` — NÃO REENTREVISTE.** As respostas dos
+10 itens do Passo 0 já estão na linha `Tarefa:` do brief (colada verbatim, junto com o resto do
+brief). O trabalho do subagente despachado para `discovery` é **transcrever** o que já foi ecoado e
+confirmado para `templates/discovery-tmpl.md` — não colher a entrevista de novo. Esta instrução é um
+**acréscimo do comando, escrito DEPOIS de colar o brief verbatim**, rotulada como instrução do
+comando (nunca embutida no próprio brief — ele é gerado pelo motor, não editável — nem em
+`agents/forge-chief.md`, que esta story não toca).
+
+**Bloqueio (`blocked`):** o motor já nomeia a assertion e a causa. Chamar `next` sem mudar nada só
+reavalia e rebloqueia. Nunca edite o `state.json` para "passar", nunca relaxe o veto no `wf` no meio
+de uma rodada.
+
+## Ritmo — `interactive` (default) e `yolo`
+
+`wf-forge.yaml` tem **2 checkpoints bloqueantes** (`red-team`, `register`) — os dois **param nos
+MESMOS pontos**, nos dois ritmos (`pod-spec.json → ritmo: nao_se_aplica`; sem `skip_modes` no `wf` —
+tornar qualquer um pulável violaria o invariante do gate humano, `ADR-024 DF-SF11.10-3`).
+
+| | `interactive` | `yolo` |
+|---|---|---|
+| Entre etapas | reporta ao dono e espera ele mandar seguir | encadeia despacho → subagente → `next` sem perguntar |
+| Retry em `blocked` | zero automático (o dono decide) | **no máximo 1** re-despacho da mesma etapa, **sempre reportado**; segundo bloqueio PARA e chama o dono |
+| Checkpoint de `red-team` | **bloqueia** | **bloqueia** (sem `skip_modes` — mesmo gate nos dois ritmos) |
+| Checkpoint de `register` | **bloqueia** | **bloqueia** (sem `skip_modes` — mesmo gate nos dois ritmos) |
+| Onde para | em `red-team`/`register`, e em `blocked` | só em `awaiting_approval` de `red-team`/`register`, `blocked` (após o retry) ou `complete` |
+| `approve` | só o dono | **NUNCA** — ver abaixo |
+
+**Proibição inegociável: o modo autônomo (`yolo`) JAMAIS executa `approve`.** Não existe "aprovar se
+estiver bom" — a aprovação final é sempre humana: o autônomo entrega todo o trabalho pronto e as duas
+decisões que exigem olho humano (veredito do red-team, registro) esperam por ele.
+
+## Checkpoint de `red-team` — só o dono
+
+Ao chegar em `[awaiting_approval] etapa=red-team`, apresente o `checkpoint.criteria` do `wf` e o
+artefato produzido, e peça a decisão: **"Veredito APROVADO explícito por escrito do pod-critic
+(verificação independente: valida-pod-workflow + smoke rodados por ele mesmo, G6 estendido).
+REPROVADO → volta à Fase 3 com a lista de correções. JULGAMENTO HUMANO — NUNCA veto de máquina
+(fronteira `ADR-002`; a máquina não decide 'aprovado')."** `REPROVADO` → `revise` devolve a
+`generation` com a lista de correções.
+
+## Checkpoint de `register` — só o dono
+
+Ao chegar em `[awaiting_approval] etapa=register`, apresente o `checkpoint.criteria` do `wf` e o
+artefato produzido, e peça a decisão: **"Registro conferido: stub em disco (≤15 linhas, aponta o
+entry point), linha em `pods/README.md`, `validate-budgets` reexecutado verde. Fase 5 termina em
+DECISÃO DO USUÁRIO (sem commit automático) — checkpoint bloqueante, não veto."**
+
+### Passo obrigatório do comando: pedir o comentário (SF11.5) — nos 2 checkpoints
+
+Depois que o dono decidir (`approve` **ou** `revise`) em **`red-team`** ou em **`register`**, e
+**antes** de chamar o motor, **pergunte a ele, sempre, uma vez**: *"quer registrar um comentário
+desta decisão? (ele vira aprendizado do pod; pode pular)"*. Isto **não é opcional para você** — o
+dono é quem escolhe comentar ou não; você é obrigado a perguntar, nos dois checkpoints.
+
+Se o dono comentar:
+
+1. **Escreva o texto dele num arquivo temporário com a ferramenta Write**
+   (`.power-claude/pod-runs/squad-forge/<run-id>/checkpoint-note.txt` serve). **NUNCA** por
+   `heredoc`, `echo`, `cat <<EOF` ou qualquer forma de shell: o comentário tem aspas, acentos e
+   quebras de linha, e o shell corrompe algum caractere justamente na rodada que importa.
+2. Invoque o registrador **com `--file`** — a mensagem **nunca** entra na linha de comando:
+
+```bash
+node scripts/pod-memory-note.cjs --state <state.json> \
+  --workflow-file pods/squad-forge/workflows/wf-forge.yaml \
+  --step red-team|register --verdict approve|revise --file <arquivo escrito no passo 1>
+```
+
+3. Só então chame `pc-run-pod.cjs approve`/`revise`. Nessa ordem: se a gravação da memória falhar, o
+   dono vê o erro **antes** de a etapa avançar.
+
+Regras que não se negociam neste passo:
+
+- **Comentário vazio ⇒ não invoque o registrador.** Silêncio não vira learning.
+- **Nunca escreva o comentário em nome do dono** — é o texto dele, verbatim. O modo autônomo continua
+  **proibido** de `approve`/`revise`, e portanto nunca chega a este passo.
+- **`--tier critical` só quando o dono disser, com essas palavras, que aquilo é regra permanente.**
+  Comentário de rodada é `normal` (default).
+
+## Só `*new` está no motor por este comando
+
+`squad-forge` tem `discovery` → `generation` → `red-team` → `register`, o **único** fluxo que
+`wf-forge.yaml` modela, e é o que este comando conduz pelo motor. **`*upgrade-pod {pod}`**,
+**`*migrate-squad {squad}`**, e a invocação **standalone** de `*discovery`/`*gates`/`*register`/
+`*ingest-memory` (fora do `wf-forge.yaml` inteiro) **continuam fora do motor por este comando** —
+decisão já registrada em `pods/squad-forge/pod-spec.json`
+(`_sources.wf_upgrade_migrate_nao_formalizados`): são sequências de chamada de script determinístico
+(`forge-upgrade-pod.cjs` / `migration-manifest.cjs`) orquestradas por UM agente via CLI, não handoffs
+artefato-a-artefato — formalizá-los como `wf` seria um 2º mecanismo de orquestração para o mesmo
+comportamento.
+
+**Capacidade não regride:** `forge-chief *upgrade-pod {pod}` / `*migrate-squad {squad}` /
+`*discovery` / `*gates` / `*register` / `*ingest-memory` continuam disponíveis exatamente como hoje,
+por invocação direta do `forge-chief` — só o roteamento livre de PROSA do `*new` some, que era o
+defeito que este comando existe para consertar.
+
+## Run pendurada
+
+`status` mostra o estado de cada etapa. Etapa em `running` sem trabalho por trás = run abandonada (o
+motor não tem timeout: ele espera para sempre). Confirme com o dono e então: `abort` (encerra, marca
+as etapas não-`done` como `failed`) ou `resume <run-id>` se a rodada for legítima e valer continuar.
+Nunca `approve`/`next` sobre uma etapa cujo artefato nunca foi realmente produzido — isso "resgata"
+lixo de teste como se fosse trabalho.
+
+## Fronteiras
+
+- Nunca `git push` / `gh pr create` / merge (exclusivo devops).
+- Nunca editar `state.json` para pular etapa ou fabricar verificação; nunca afrouxar o `wf` para
+  destravar uma rodada.
+- Nunca aprovar checkpoint em nome do dono.
+- Cada etapa é um subagente FRESCO; o brief é a única fonte de contexto dele.
+- Referência do protocolo do motor: skill `pc-run-pod` (`.claude/skills/pc-run-pod/SKILL.md`).

package/template/.claude/commands/power/hormozi.md

@@ -0,0 +1,221 @@
+---
+description: "Conduz uma rodada de Grand Slam Offer do pod hormozi-method PELO MOTOR determinístico (pc-run-pod.cjs): diagnóstico, oferta, money model/pricing e copy de vendas, com checkpoint humano e memória curada. Use para: diagnosticar e desenhar uma oferta, precificar e montar money model, escrever a copy de vendas final, iniciar/retomar/acompanhar uma rodada."
+---
+
+Você conduz uma rodada de `grand-slam-offer` do pod `hormozi-method` **pelo motor** `scripts/pc-run-pod.cjs`.
+Não existe caminho "leia o README e escolha o agente pelo pedido": todo passo é despachado, verificado
+em disco e liberado pelo motor — é assim que o veto de `offer-engineer` (Value Stack ≥5 componentes) e o checkpoint
+bloqueante de `conversion-copywriter` deixam de depender de o agente seguir a prosa direito.
+
+Pedido do usuário: $ARGUMENTS
+
+---
+
+## Passo 0 — montar a ENTRADA e ECOAR antes de iniciar
+
+A entrada viaja no `--task-ref` como **descrição livre do negócio/oferta** — não há gramática
+`entrada=`/`fonte=` aqui (isso é de `hn-carousel`; `grand-slam-offer` não tem 2º modo de entrada, ver
+"Ritmo" abaixo e a recusa de `contrato_entrada` no `pod-spec.json`). Peça ao dono, em texto livre: que
+negócio/produto é, para quem, e o que ele já sabe sobre a oferta atual (se houver).
+
+```
+<descrição livre do negócio/produto/oferta, tudo que o dono já trouxer>
+```
+
+**Aviso de segurança, uma frase, sempre:** a linha que você montar fica **gravada permanentemente** no
+`state.json` da run — não inclua nada que o dono não queira persistido em disco.
+
+**ECO OBRIGATÓRIO em qualquer ritmo:** mostre o `--task-ref` inteiro que você vai usar e só inicie após
+o "ok" do dono. Nada começa sem ele ter visto o valor exato.
+
+## Passo 1 — `start` (linha literal)
+
+```bash
+node scripts/pc-run-pod.cjs start hormozi-method wf-grand-slam-offer \
+  --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml \
+  --mode <interactive|yolo> \
+  --task-ref "<descrição livre do negócio/oferta>"
+```
+
+Sempre pela **flag** `--task-ref`, nunca posicional. Rode a partir da raiz do repo (`second-brain`); o
+`--pod-root` não é necessário — o motor deriva a raiz do pod pelo path do `wf`.
+
+O `start` imprime `[start] run <run-id> → <caminho do state.json>`. **Guarde esse caminho**: todos os
+comandos seguintes usam `--state <caminho>`. O `--mode` é gravado no `state.json` como **rótulo** — o
+motor não ramifica por ele; o ritmo é responsabilidade deste comando.
+
+## Passo 2 — o laço (uma transição por chamada)
+
+```bash
+node scripts/pc-run-pod.cjs next    --state <state.json> --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml
+node scripts/pc-run-pod.cjs status  --state <state.json> --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml
+node scripts/pc-run-pod.cjs approve --state <state.json> --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml
+node scripts/pc-run-pod.cjs revise  --state <state.json> --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml
+node scripts/pc-run-pod.cjs abort   --state <state.json> --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml
+```
+
+Uma sexta chamada, **fora** da máquina de estados — registra o comentário do dono no checkpoint como
+aprendizado do pod (SF11.5). Ela **não** transiciona nada; é chamada ANTES do `approve`/`revise`, e só
+quando o dono comentou (ver "Passo obrigatório do comando: pedir o comentário" abaixo):
+
+```bash
+node scripts/pod-memory-note.cjs --state <state.json> --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml \
+  --step conversion-copywriter --verdict approve|revise --file <arquivo com o comentário, escrito pela ferramenta Write>
+```
+
+O que fazer com cada saída:
+
+| Saída do motor | Significado | Sua ação |
+|---|---|---|
+| `[dispatch] etapa=<id>` + bloco `--- BRIEF ---` | o motor abriu a etapa e emitiu o brief | despache um **subagente FRESCO** (um por etapa, nunca reaproveitado) com o brief **VERBATIM**; quando ele voltar, chame `next` |
+| `[blocked] etapa=<id> motivo=verification_failed` + lista de falhas | o artefato em disco reprovou (forma ou veto) | a etapa continua `running` e a seguinte NÃO roda. Re-despache a MESMA etapa anexando as `failures` ao brief |
+| `[awaiting_approval] etapa=<id>` | verificação passou e a etapa tem checkpoint bloqueante | **PARE.** Só o dono destrava (`approve`/`revise`) — só acontece em `conversion-copywriter`, a etapa final |
+| `[complete]` | todas as etapas `done` | reporte o pacote final e encerre |
+| `[erro] …` (exit 1) | uso/estado inválido | reporte ao dono; nunca "conserte" editando o `state.json` |
+
+**Despacho do subagente (cada etapa):** **cole o brief inteiro, sem resumir.** O brief abre com a seção
+**"Leitura obrigatória ANTES de agir"**, que lista o arquivo do agente e o(s) `knowledge:` que o `wf`
+declara para a etapa — por path absoluto, na ordem declarada, com a existência já verificada em disco
+pelo motor. O brief também traz a linha `Tarefa:` com o `task-ref`, o path exato do artefato, o
+template, as `veto.assertions` que serão verificadas e o limite de autoridade. Não acrescente instrução
+que contradiga o brief.
+
+**Bloqueio (`blocked`):** o motor já nomeia a assertion e a causa. Chamar `next` sem mudar nada só
+reavalia e rebloqueia. Nunca edite o `state.json` para "passar", nunca relaxe o veto no `wf` no meio de
+uma rodada.
+
+## Ritmo — `interactive` (default) e `yolo`
+
+Diferente de `hn-carousel`, os dois ritmos **param no MESMO ponto** — `wf-grand-slam-offer` tem **1
+único** checkpoint bloqueante, em `conversion-copywriter` (a etapa final). `skip_modes` foi **recusado**
+nesta forma do `wf` (`pod-spec.json → ritmo`, `nao_se_aplica`): com um único gate, torná-lo pulável em
+qualquer modo deixaria aquele modo sem nenhum checkpoint não-pulável, e o validador reprova o invariante
+do gate humano (`ADR-024 DF-SF11.10-3`).
+
+| | `interactive` | `yolo` |
+|---|---|---|
+| Entre etapas | reporta ao dono e espera ele mandar seguir | encadeia despacho → subagente → `next` sem perguntar |
+| Retry em `blocked` | zero automático (o dono decide) | **no máximo 1** re-despacho da mesma etapa, **sempre reportado**; segundo bloqueio PARA e chama o dono |
+| Checkpoint de `conversion-copywriter` | **bloqueia** | **bloqueia** (sem `skip_modes` — mesmo gate nos dois ritmos) |
+| Onde para | em `conversion-copywriter`, e em `blocked` | só em `awaiting_approval` de `conversion-copywriter`, `blocked` (após o retry) ou `complete` |
+| `approve` | só o dono | **NUNCA** — ver abaixo |
+
+**Proibição inegociável: o modo autônomo JAMAIS executa `approve`.** Não existe "aprovar se estiver
+bom" — a aprovação final é sempre humana: o autônomo entrega todo o trabalho pronto e a decisão que
+exige olho humano espera por ele.
+
+**Dito honestamente, antes de o dono escolher (`DEBT-SF12.5a-A`):** o único gate humano deste `wf` vem
+**depois** de `offer-engineer` **e** `monetization-architect` já terem rodado — o dono aprova a *copy*
+sem nunca ter aprovado a *oferta* (value stack, garantia, âncora de preço) sobre a qual a copy foi
+construída. É a assimetria inversa de `hn-carousel` (lá, o `digest` existe para o dono julgar cedo). Se
+um gate intermediário for adicionado no futuro, `ritmo` volta a ter pergunta real — não é o caso hoje.
+
+## Checkpoint bloqueante de `conversion-copywriter` — só o dono
+
+Ao chegar em `[awaiting_approval] etapa=conversion-copywriter`, apresente o `checkpoint.criteria` do
+`wf` e o artefato produzido, e peça a decisão. O que o dono aprova: a copy final — nome da oferta
+(MAGICO), headline, copy do value stack, copy da garantia — **rastreável** ao que `offer-engineer` e
+`monetization-architect` produziram a montante (nenhum número, promessa ou componente que não veio de
+lá). Este é o **único** gate da rodada, e ele vem depois de toda a oferta já decidida (ver "Ritmo"
+acima) — não invente cláusula de conteúdo que o `wf` não tem; o `criteria` em si não muda nesta story.
+
+### Passo obrigatório do comando: pedir o comentário (SF11.5)
+
+Depois que o dono decidir (`approve` **ou** `revise`) e **antes** de chamar o motor, **pergunte a ele,
+sempre, uma vez**: *"quer registrar um comentário desta decisão? (ele vira aprendizado do pod; pode
+pular)"*. Isto **não é opcional para você** — o dono é quem escolhe comentar ou não; você é obrigado a
+perguntar.
+
+Se o dono comentar:
+
+1. **Escreva o texto dele num arquivo temporário com a ferramenta Write** (`.power-claude/pod-runs/<pod>/<run-id>/checkpoint-note.txt` serve). **NUNCA** por `heredoc`, `echo`, `cat <<EOF` ou qualquer forma de shell: o comentário tem aspas, acentos e quebras de linha, e o shell corrompe algum caractere justamente na rodada que importa.
+2. Invoque o registrador **com `--file`** — a mensagem **nunca** entra na linha de comando:
+
+```bash
+node scripts/pod-memory-note.cjs --state <state.json> \
+  --workflow-file pods/hormozi-method/workflows/wf-grand-slam-offer.yaml \
+  --step conversion-copywriter --verdict approve|revise --file <arquivo escrito no passo 1>
+```
+
+3. Só então chame `pc-run-pod.cjs approve`/`revise`. Nessa ordem: se a gravação da memória falhar, o
+   dono vê o erro **antes** de a etapa avançar.
+
+Regras que não se negociam neste passo:
+
+- **Comentário vazio ⇒ não invoque o registrador.** Silêncio não vira learning.
+- **Nunca escreva o comentário em nome do dono** — é o texto dele, verbatim. O modo autônomo continua
+  **proibido** de `approve`/`revise`, e portanto nunca chega a este passo.
+- **`--tier critical` só quando o dono disser, com essas palavras, que aquilo é regra permanente.**
+  Comentário de rodada é `normal` (default).
+
+## Só `grand-slam-offer` está no motor por este comando
+
+`hormozi-method` tem **6 workflows**; este comando conduz **apenas** `wf-grand-slam-offer`
+(`*diagnose` → `*offer`/`*guarantee`/`*bonus`/`*scarcity` → `*money-model`/`*price` → `*name`/`*sales-page`)
+pelo motor, com loop completo (`start`/`next`/`status`/`approve`/`revise`/`abort` + checkpoint +
+`pod-memory-note.cjs`). Os outros **5** ficam de fora do loop deste comando, por decisão de escopo — os
+6/6 já têm `knowledge:`/`contrato_entrada`/`entregavel` governados pelo motor (`SF12.5b`), mas só
+disponíveis por CLI direto (sem `approve`/`revise` pelo comando — `ritmo` fica deferido nos 5, Bloco B):
+
+- `wf-money-model-design`
+- `wf-full-launch-sequence`
+- `wf-lead-magnet-pipeline`
+- `wf-paid-ads-campaign`
+- `wf-scaling-diagnostic`
+
+**`acquisition-strategist` fica sem porta neste comando** — ele não participa de `wf-grand-slam-offer`.
+As famílias de pedido que ele cobre (leads/hooks/ads: `*core-four`, `*lead-magnet`, `*hooks`, `*ads`)
+não têm caminho aqui. Se o dono pedir uma delas, rode o `wf` que a cobre por CLI direto (mesmo padrão do
+Passo 1, trocando `workflowId`/`--workflow-file`/`--task-ref`):
+
+```bash
+# money model / pricing (*money-model, *upsell, *downsell, *continuity)
+node scripts/pc-run-pod.cjs start hormozi-method wf-money-model-design \
+  --workflow-file pods/hormozi-method/workflows/wf-money-model-design.yaml \
+  --mode <interactive|yolo> --task-ref "<descrição livre>"
+
+# lançamento completo (*launch, *nurture, *retention)
+node scripts/pc-run-pod.cjs start hormozi-method wf-full-launch-sequence \
+  --workflow-file pods/hormozi-method/workflows/wf-full-launch-sequence.yaml \
+  --mode <interactive|yolo> --task-ref "<descrição livre>"
+
+# leads / lead magnet (*lead-magnet, *core-four)
+node scripts/pc-run-pod.cjs start hormozi-method wf-lead-magnet-pipeline \
+  --workflow-file pods/hormozi-method/workflows/wf-lead-magnet-pipeline.yaml \
+  --mode <interactive|yolo> --task-ref "<descrição livre>"
+
+# hooks / ads pagos (*hooks, *ads)
+node scripts/pc-run-pod.cjs start hormozi-method wf-paid-ads-campaign \
+  --workflow-file pods/hormozi-method/workflows/wf-paid-ads-campaign.yaml \
+  --mode <interactive|yolo> --task-ref "<descrição livre>"
+
+# diagnóstico e roadmap de escala (*scale-check, *growth-decision)
+node scripts/pc-run-pod.cjs start hormozi-method wf-scaling-diagnostic \
+  --workflow-file pods/hormozi-method/workflows/wf-scaling-diagnostic.yaml \
+  --mode <interactive|yolo> --task-ref "<descrição livre>"
+```
+
+**Capacidade não regride:** `node scripts/pc-run-pod.cjs start hormozi-method <qualquer um dos 6 wf>, ...`
+continua disponível por CLI direto, exatamente como hoje — só o roteamento livre de PROSA some, que era
+o defeito que este comando existe para consertar. Levar o loop completo (`approve`/`revise`/checkpoint
+pelo comando) aos 5 workflows restantes depende de `ritmo` decidido (Bloco B/`_ritmo_deferido`,
+`DEBT-SF12.5b-A`/`-C` fechadas sem essa implementação) — fora do escopo de `SF12.5b`, gatilho de retorno
+nomeado, não promessa solta.
+
+## Run pendurada
+
+`status` mostra o estado de cada etapa. Etapa em `running` sem trabalho por trás = run abandonada (o
+motor não tem timeout: ele espera para sempre). Confirme com o dono e então: `abort` (encerra, marca as
+etapas não-`done` como `failed`) ou `resume <run-id>` se a rodada for legítima e valer continuar. Nunca
+`approve`/`next` sobre uma etapa cujo artefato nunca foi realmente produzido — isso "resgata" lixo de
+teste como se fosse trabalho.
+
+## Fronteiras
+
+- Nunca `git push` / `gh pr create` / merge (exclusivo devops).
+- Nunca editar `state.json` para pular etapa ou fabricar verificação; nunca afrouxar o `wf` para
+  destravar uma rodada.
+- Nunca aprovar checkpoint em nome do dono.
+- Cada etapa é um subagente FRESCO; o brief é a única fonte de contexto dele.
+- Metodologia SEMPRE com fonte citada ("$100M Playbooks, Alex Hormozi"); nunca encarnar a pessoa.
+- Referência do protocolo do motor: skill `pc-run-pod` (`.claude/skills/pc-run-pod/SKILL.md`).

package/template/.claude/commands/power/modo.md

@@ -0,0 +1,57 @@
+---
+description: Alterna entre modo econômico e modo desempenho na matriz de modelos dos papéis (economico | desempenho | status)
+---
+
+# /power:modo — alternar matriz de modelos dos papéis
+
+Argumento recebido: `$ARGUMENTS`
+
+O estado do modo é a **existência do arquivo** `$CLAUDE_PROJECT_DIR/.claude/rules/economy-mode.md`:
+- Arquivo EXISTE → modo econômico ativo (carrega como regra em toda sessão enquanto existir)
+- Arquivo NÃO existe → modo desempenho (matriz padrão em `.claude/rules/model-matrix.md`)
+
+## Ações por argumento
+
+### `economico` (ou `eco`)
+1. Escreva (Write, sobrescrevendo se existir) o arquivo `$CLAUDE_PROJECT_DIR/.claude/rules/economy-mode.md` com o conteúdo canônico abaixo — **SEM frontmatter** (o arquivo deve carregar sempre, enquanto existir).
+2. Aplique a matriz econômica IMEDIATAMENTE nesta sessão (não só nas próximas).
+3. Confirme ao usuário: "Modo econômico ativado" + resumo da matriz em 3 linhas.
+
+### `desempenho` (ou `perf`, `padrao`)
+1. Delete o arquivo `$CLAUDE_PROJECT_DIR/.claude/rules/economy-mode.md` (via Bash `rm`; se não existir, apenas informe que já estava em desempenho).
+2. Volte a aplicar a matriz padrão IMEDIATAMENTE nesta sessão (`.claude/rules/model-matrix.md`: coordenadora e architect no modelo de topo, qa e dev em opus, devops/planner/analyst/po em sonnet, escalada um degrau acima por gatilho).
+3. Confirme ao usuário: "Modo desempenho restaurado".
+
+### `status` (ou vazio)
+Verifique se o arquivo existe e informe o modo ativo + a matriz vigente em tabela curta. Não altere nada.
+
+## Conteúdo canônico do arquivo economy-mode.md
+
+```markdown
+# MODO ECONÔMICO ATIVO — alternável via /power:modo
+
+> Ativado pelo usuário via `/power:modo economico`. Para desativar: `/power:modo desempenho` (remove este arquivo).
+> **NÃO altera a matriz padrão** (`.claude/rules/model-matrix.md`) — apenas a suspende parcialmente enquanto este arquivo existir. A coordenadora aplica via override `model:` nas chamadas do Agent tool.
+
+## Matriz econômica
+
+| Papel | Padrão | Econômico |
+|---|---|---|
+| qa (gate adversarial) | opus | **opus — INTOCADO** |
+| architect | modelo de topo | opus |
+| dev | opus | sonnet |
+| devops / planner / analyst / po | sonnet | sonnet |
+| Etapas mecânicas | effort low | haiku + effort low |
+
+## Gatilhos de escalada (um degrau abaixo do normal)
+
+Story que toca segurança/auth · migration de dados · dinheiro/cobrança · compliance/dados pessoais · desempate entre especialistas → executores sobem para **opus** (não para o modelo de topo). O modelo de topo fica reservado para desempate crítico de segurança.
+
+## O que NÃO muda (âncoras de qualidade)
+
+1. Gate adversarial do qa em opus, com todos os checks.
+2. Validação do po e verificação pós-fase em disco do pc-full-cycle.
+3. As 3 regras de eficiência de tokens (agente fresco por story, relatórios ≤15 linhas, effort low mecânico).
+
+Racional: os executores podem errar mais barato porque o funil de detecção permanece na potência integral.
+```

package/template/.claude/hooks/README.md

@@ -0,0 +1,114 @@
+# Hooks — POWER CLAUDE
+
+Enforcement determinístico dos não-negociáveis do ambiente. O que é inegociável vira hook, não prosa.
+
+## enforce-git-push-authority.cjs
+
+Hook `PreToolUse` para o tool `Bash`. Intercepta operações remotas de git/GitHub antes da execução e decide, com **3 níveis de autoridade** (D4, story SF12.3):
+
+| Comando | `agent_type === "pc-devops"` | Qualquer outro |
+|---|---|---|
+| `git push --force` / `-f` / `--force-with-lease` | **deny** — incondicional | **deny** — incondicional |
+| `git push`, `gh pr create` | **allow** (passa direto) | **ask** — exige aprovação humana |
+| `gh pr merge` | **ask** — sempre, mesmo para devops | **ask** — exige aprovação humana |
+
+Merge em `main` espera aprovação humana explícita como regra permanente do dono — isso não muda com este hook, nem para o papel devops. Força-push é a única operação sempre negada, para qualquer agente.
+
+**Fronteira real (D6/D7, fix rounds F3/F5 — não prometer mais do que o instrumento entrega):** este hook é **guard-rail contra erro, não barreira contra evasão deliberada**. O que ele PEGA: `git`/`gh` em qualquer sintaxe de flags (curtas combinadas, longas, opções globais antes do subcomando), comandos encadeados (`;`/`&&`/`||`/`|`), e **alias em AMBOS os branches** — `git` (`git config --get alias.<nome>`) e `gh` (`gh alias list`, alias NATIVO da ferramenta, ex. `gh alias set qm 'pr merge --auto'`) — inclusive um alias já configurado, sem nenhuma pista no texto do comando; se a consulta falhar (git/gh ausente, timeout, config corrompida), o resultado vira `ask`, nunca silêncio. **Até o fix round F5 só o `git` tinha essa resolução** — o `gh` casava `pr create`/`pr merge` de forma literal, uma assimetria que abria bypass via alias nativo do `gh` mesmo com força-push do `git` já fechada; os 2 branches agora usam a mesma disciplina (lógica de expansão/recursão compartilhada). O que ele **NÃO pega, por desenho**: indireção via `sh -c`/`bash -c`/`eval`/`npm run`/`node -e`/scripts externos (`./deploy.sh`) que por sua vez rodem git/gh — qualquer uma dessas contorna o hook. Perseguir essas variantes de evasão deliberada foi avaliado e rejeitado (não converge, e não é o problema que este guard-rail resolve).
+
+**Identidade do agente:** lida exclusivamente de `input.agent_type` (payload do `PreToolUse` — o `subagent_type` literal do despacho, ex. `"pc-devops"`). **SEM fallback a variáveis de ambiente**: `PC_ACTIVE_AGENT`/`CLAUDE_AGENT_NAME`/`CLAUDE_CODE_AGENT` não existem no produto (medido: 0 ocorrências no binário da plataforma), e `.claude/settings.json` tem chave `env` que alcança subprocessos — manter o fallback reabriria a autoproclamação que este hook existe para fechar. Um prefixo inline no comando (ex.: `PC_ACTIVE_AGENT=devops git push`) e uma env var no processo do hook NÃO funcionam — nenhum dos dois é fonte de identidade.
+
+**Fail-closed proporcional:** se o input JSON do hook vier malformado, só bloqueia comandos cujo texto bruto aparente ser uma operação remota; o restante do Bash segue normal.
+
+Teste manual:
+
+```bash
+echo '{"agent_id":"s","agent_type":"pc-devops","tool_input":{"command":"git push origin main"}}' \
+  | node .claude/hooks/enforce-git-push-authority.cjs
+```
+
+## enforce-cycle-authority.cjs
+
+Hook `PreToolUse` para os tools `Edit`/`Write`. Mecaniza as 2 garantias de autoridade do ciclo que não podem depender só de disciplina (`DF-SF12.3-2`): só QA marca `Status: Done` / escreve `docs/qa/gates/*.yaml`; Dev não edita código enquanto a story associada (derivada da branch) está `Draft`.
+
+| Predicado | Alvo | Papel exigido | Decisão quando errado |
+|---|---|---|---|
+| 1 — Done | `*.story.md`, seção `## Status` transiciona para Done | `pc-qa` | `deny` (papel conhecido e errado) / `ask` (ambíguo) |
+| 2 — gate file | `docs/qa/gates/*.yaml`, qualquer Edit/Write | `pc-qa` | `deny` (papel conhecido e errado) / `ask` (ambíguo) |
+| 3 — Dev × Draft | qualquer arquivo (exceto `*.story.md` e sob `docs/`) | qualquer papel ≠ `pc-dev` | `ask` (nunca `deny` — ver `docs/mecanismos/hooks-de-autoridade-do-ciclo.md`) |
+
+**Alcance declarado:** tool calls `Edit`/`Write` apenas — `Bash` (`sed -i`, heredoc, `python -c`) e `MultiEdit` estão fora. Documentação completa (matriz allow/deny/ask, canal de identidade, destravamento): `docs/mecanismos/hooks-de-autoridade-do-ciclo.md`.
+
+Teste manual:
+
+```bash
+echo '{"agent_id":"s","agent_type":"pc-dev","tool_name":"Edit","tool_input":{"file_path":"docs/qa/gates/1.1.yaml","old_string":"a","new_string":"b"}}' \
+  | node .claude/hooks/enforce-cycle-authority.cjs
+```
+
+## context-budget.cjs
+
+Hook `PostToolUse` para o tool `Read`. Sentinela de orçamento de contexto: após cada leitura de arquivo, verifica o tamanho de `tool_input.file_path`.
+
+| Situação | Comportamento |
+|---|---|
+| Arquivo lido > 32KB (~8k tokens) | Emite `additionalContext` avisando o excesso e sugerindo ler por `offset`/`limit` ou extrair o essencial para `knowledge/` |
+| Arquivo pequeno / inexistente / input malformado | Silêncio total (sem output, exit 0) |
+
+**Advisory-only:** nunca bloqueia nada. Qualquer erro interno → exit 0 silencioso; timeout interno curto (~2,5s) impede travamento. Node puro, sem dependências.
+
+Teste manual:
+
+```bash
+echo '{"tool_name":"Read","tool_input":{"file_path":"/caminho/arquivo-grande.md"}}' \
+  | node .claude/hooks/context-budget.cjs
+```
+
+## Como registrar
+
+Já registrados em `.claude/settings.json`:
+
+```json
+"hooks": {
+  "PreToolUse": [
+    {
+      "matcher": "Bash",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/enforce-git-push-authority.cjs\"",
+          "timeout": 10
+        }
+      ]
+    },
+    {
+      "matcher": "Edit|Write",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/enforce-cycle-authority.cjs\"",
+          "timeout": 10
+        }
+      ]
+    }
+  ],
+  "PostToolUse": [
+    {
+      "matcher": "Read",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/context-budget.cjs\"",
+          "timeout": 10
+        }
+      ]
+    }
+  ]
+}
+```
+
+Requer Node.js 18+ no PATH. Sem dependências externas. Para testar manualmente:
+
+```bash
+echo '{"tool_input":{"command":"git push --force"}}' | node .claude/hooks/enforce-git-push-authority.cjs
+```