@daniellins/power-claude 0.16.3

package/template/.claude/skills/pc-review-story/references/false-positive-detection.md

@@ -0,0 +1,50 @@
+# False Positive Detection — checklist anti-viés de confirmação
+
+> Protocolo aprofundado do `pc-review-story` (e do `pc-apply-qa-fixes` ao julgar findings). Origem destilada: task `qa-false-positive-detection.md`. Use SEMPRE que a story é bug fix, ou ao decidir se um finding aponta problema real. Transforma checklist qualitativo em decisão quantitativa.
+
+## Os 5 falsos positivos clássicos
+
+1. **Placebo Fix** — parece corrigir mas não trata a causa-raiz (ex.: try-catch em volta do erro; o erro continua).
+2. **Timing Coincidence** — o bug sumiu por mudança/timing não relacionado (ex.: race condition que parou por causa de um log adicionado).
+3. **Environment Dependency** — funciona em dev, falha em prod (ex.: URL localhost hardcoded).
+4. **Incomplete Fix** — cobre um caso, não todas as bordas (ex.: null check adicionado, mas `undefined` ainda quebra).
+5. **Self-Healing Bug** — resolve sozinho de forma intermitente (ex.: bug de cache que some após restart).
+
+## Teste de causação (o mais importante)
+
+- **remove-test:** reverta o fix (stash/branch) → reproduza o bug → reaplique o fix → confirme que sumiu. PASS: o bug **volta** sem o fix e **some** com o fix. FAIL: comportamento não muda com o fix.
+- **old-code-fails:** há evidência concreta de que o código ANTIGO falha? (não presumir).
+- **new-code-succeeds:** há evidência concreta de que o código NOVO passa? (não presumir).
+- **not-self-healing:** espere / reinicie serviço / limpe cache → o bug segue corrigido?
+
+## Checks de viés
+
+- **negative-cases:** cenários onde o código DEVE falhar/rejeitar foram testados? (não só o happy path).
+- **independent-verification:** os passos de reprodução bastam para outra pessoa verificar sem o ambiente do autor?
+- **mechanism-explained:** dá para explicar POR QUE o fix funciona (causa-raiz → como o change a trata → por que não regride), não só QUE funciona?
+
+## Confidence score (pesos determinísticos)
+
+```
+assumptions_verified   0.20
+remove_test_passed     0.25   ← maior peso
+old_code_fails         0.15
+new_code_succeeds      0.15
+not_self_healing       0.10
+negative_cases_tested  0.10
+mechanism_explained    0.05
+                       ----
+total                  1.00
+```
+
+Cada fator entra como 0..1 (fração satisfeita) × peso.
+
+## Limiares → ação
+
+- **≥ 0.85** (alta) — aprovar com confiança; sem impacto na decisão do gate.
+- **≥ 0.65** (média) — aprovar com nota no gate.
+- **< 0.65** (baixa) — exigir evidência adicional ou **forte consideração para FAIL/REJECT**.
+
+## Red flags (qualquer um puxa o veredito para baixo)
+
+Fix só testado no happy path · bug original não reproduzível · funciona mas mecanismo obscuro · depende de timing/ambiente · sem teste de regressão adicionado · código similar em outro lugar não conferido · premissas não documentadas · uma única explicação considerada.

package/template/.claude/skills/pc-review-story/references/nfr-assess.md

@@ -0,0 +1,47 @@
+# NFR Assessment — os quatro NFRs centrais
+
+> Protocolo aprofundado do eixo de NFR do `pc-review-story`. Origem destilada: task `qa-nfr-assess.md`. Avaliação rápida e gate-ready, não análise profunda. Carregue quando a story tiver requisito não-funcional relevante.
+
+Foco default nos **quatro centrais**: segurança, performance, confiabilidade, manutenibilidade. (Estendidos sob demanda: usabilidade, compatibilidade, portabilidade, adequação funcional.)
+
+## Procedimento
+
+1. **Achar thresholds** nos ACs, em `docs/architecture/*.md`, em preferências técnicas. Target ausente e não fornecido → status **CONCERNS** com nota "Target unknown" (nunca chutar).
+2. Para cada NFR: há evidência de implementação? dá para validar? há gap óbvio?
+3. Emitir bloco de gate só para os NFRs realmente avaliados (sem placeholders).
+
+## Regras determinísticas de status
+
+- **FAIL** — qualquer NFR selecionado com gap crítico ou target claramente não atingido.
+- **CONCERNS** — sem FAILs, mas algum NFR desconhecido/parcial/sem evidência.
+- **PASS** — todos os NFRs selecionados atingem o target com evidência.
+
+## Quality score
+
+```
+quality_score = 100
+- 20 por atributo FAIL
+- 10 por atributo CONCERNS
+Piso 0, teto 100.
+```
+
+## Critérios por NFR
+
+**Segurança** — PASS: auth implementada, authz aplicada, input validado, sem segredo hardcoded. CONCERNS: sem rate limiting, cripto fraca, authz incompleta. FAIL: sem auth, credencial hardcoded, SQL injection.
+
+**Performance** — PASS: dentro do target de tempo, sem gargalo óbvio, uso razoável de recurso. CONCERNS: perto do limite, sem índice, sem cache. FAIL: excede o limite, memory leak, query não otimizada.
+
+**Confiabilidade** — PASS: tratamento de erro, degradação graciosa, retry onde necessário. CONCERNS: alguns erros não tratados, sem circuit breaker, sem health check. FAIL: sem tratamento de erro, quebra no erro, sem recuperação.
+
+**Manutenibilidade** — PASS: cobertura no target, código bem estruturado, documentação presente. CONCERNS: cobertura abaixo do target, alguma duplicação, doc faltando. FAIL: sem testes, alto acoplamento, sem documentação.
+
+## Bloco para o gate file
+
+```yaml
+nfr_validation:
+  _assessed: [security, performance, reliability, maintainability]
+  security:        { status: CONCERNS, notes: "sem rate limiting em auth" }
+  performance:     { status: PASS,     notes: "respostas < 200ms verificado" }
+  reliability:     { status: PASS,     notes: "erro tratado + retry" }
+  maintainability: { status: CONCERNS, notes: "cobertura 65%, target 80%" }
+```

package/template/.claude/skills/pc-review-story/references/risk-profile.md

@@ -0,0 +1,75 @@
+# Risk Profile — matriz de risco probabilidade × impacto
+
+> Protocolo aprofundado do eixo de risco do `pc-review-story`. Origem destilada: task `qa-risk-profile.md` (framework anterior). Carregue sob demanda quando a story tiver superfície de risco material (auth, dados, dinheiro, integração nova).
+
+## Categorias (prefixo do ID)
+
+- **TECH** — arquitetura, integração, dívida técnica, escalabilidade, dependências.
+- **SEC** — auth/authz, exposição de dados, injeção, sessão, cripto.
+- **PERF** — tempo de resposta, throughput, exaustão de recurso, query, cache.
+- **DATA** — perda, corrupção, privacidade, compliance, backup/recovery.
+- **BUS** — não atende a necessidade, receita, reputação, regulatório, timing.
+- **OPS** — deploy, monitoração, resposta a incidente, documentação, transferência de conhecimento.
+
+## Score = Probabilidade × Impacto
+
+**Probabilidade:** Alta (3, >70%) · Média (2, 30-70%) · Baixa (1, <30%).
+**Impacto:** Alto (3: breach/queda/perda financeira) · Médio (2: degradação/dado menor) · Baixo (1: cosmético).
+
+| Score | Nível |
+|---|---|
+| 9 | Crítico |
+| 6 | Alto |
+| 4 | Médio |
+| 2-3 | Baixo |
+| 1 | Mínimo |
+
+## Mapeamento determinístico score → gate
+
+- Qualquer risco com **score ≥ 9 → FAIL** (salvo WAIVED explícito).
+- Senão, qualquer **score ≥ 6 → CONCERNS**.
+- Senão → **PASS**.
+- Riscos não mitigados: documentar no gate file.
+
+## Quality score da story (opcional, para tendência)
+
+```
+Base = 100
+- 20 por risco Crítico (9)
+- 10 por risco Alto (6)
+-  5 por risco Médio (4)
+-  2 por risco Baixo (2-3)
+Piso 0, teto 100.
+```
+
+## Registro de risco (formato)
+
+```yaml
+risk:
+  id: SEC-001
+  category: security
+  title: "Validação de input insuficiente em formulários"
+  probability: 3   # 1|2|3
+  impact: 3        # 1|2|3
+  score: 9
+  affected_components: [UserRegistrationForm]
+  mitigation:
+    strategy: preventive   # preventive|detective|corrective
+    actions: ["input validation lib", "CSP headers", "sanitizar entradas"]
+    testing: ["security testing", "unit de validação"]
+    residual_risk: "Baixo"
+    owner: dev
+```
+
+## Bloco para o gate file
+
+```yaml
+risk_summary:
+  totals: { critical: X, high: Y, medium: Z, low: W }
+  highest: { id: SEC-001, score: 9, title: "..." }
+  recommendations:
+    must_fix: ["..."]
+    monitor: ["..."]
+```
+
+Regras de saída: só emitir riscos avaliados (sem placeholders); ordenar por score desc; sem riscos → totais zerados e recomendações vazias.

package/template/.claude/skills/pc-review-story/references/security-checklist.md

@@ -0,0 +1,69 @@
+# Security Checklist — 8 checks com regex prontos
+
+> Protocolo aprofundado de scan de segurança do `pc-review-story`. Origem destilada: task `qa-security-checklist.md`. Scan de anti-padrões via Grep sobre os arquivos do diff. Rode em toda story que toca auth, dados sensíveis ou superfície externa; obrigatório se a story mudou input do usuário ou query.
+
+**Alvo:** arquivos do `git diff` com extensão `.js .ts .jsx .tsx .py .mjs .cjs`. Excluir testes (`*.test.*`, `*.spec.*`, `__tests__/*`) só na primeira passada — padrões perigosos em teste podem ser intencionais (ver falso-positivo).
+
+## Os 8 checks
+
+### 1. eval / execução dinâmica de código — CRITICAL (RCE)
+```
+JS:  eval\(   |   new Function\(   |   setTimeout\(['"`][^'"]+['"`]   |   setInterval\(['"`][^'"]+['"`]
+PY:  eval\(   |   exec\(   |   compile\(
+```
+Fix: `JSON.parse()` para dados; nunca código dinâmico.
+
+### 2. innerHTML / DOM XSS — CRITICAL (XSS)
+```
+\.innerHTML\s*=   |   \.outerHTML\s*=   |   document\.write\(   |   document\.writeln\(
+```
+Fix: `textContent`, `createElement`, ou biblioteca de sanitização.
+
+### 3. dangerouslySetInnerHTML (React) — CRITICAL (XSS)
+```
+dangerouslySetInnerHTML
+```
+Fix: DOMPurify ou evitar. Exceção: só se sanitizado com `DOMPurify.sanitize()`.
+
+### 4. shell=True / comando de shell (Python) — CRITICAL (Command Injection)
+```
+subprocess\..*shell\s*=\s*True   |   os\.system\(   |   os\.popen\(
+```
+Fix: `subprocess` com `shell=False` e argumentos em lista.
+
+### 5. Segredos hardcoded — CRITICAL (Credential Exposure)
+```
+api[_-]?key\s*[=:]\s*['"][^'"]{10,}['"]     |   apikey\s*[=:]\s*['"][^'"]{10,}['"]
+password\s*[=:]\s*['"][^'"]+['"]            |   passwd\s*[=:]\s*['"][^'"]+['"]   |   pwd\s*[=:]\s*['"][^'"]+['"]
+token\s*[=:]\s*['"][^'"]{10,}['"]          |   secret\s*[=:]\s*['"][^'"]{10,}['"]   |   bearer\s+[a-zA-Z0-9_-]{20,}
+AKIA[0-9A-Z]{16}                            |   aws[_-]?secret[_-]?access[_-]?key
+-----BEGIN (RSA |DSA |EC |OPENSSH )?PRIVATE KEY-----
+```
+Fix: variável de ambiente, secrets manager ou `.env`.
+
+### 6. SQL Injection — CRITICAL
+```
+JS:  query\s*\(\s*['"`].*\$\{   |   query\s*\(.*\+.*\)   |   execute\s*\(\s*['"`].*\$\{
+PY:  execute\s*\(\s*['"].*%s   |   execute\s*\(.*\.format\(   |   execute\s*\(.*f['"]
+```
+Fix: query parametrizada / ORM / prepared statement.
+
+### 7. Validação de input ausente — HIGH
+```
+req\.body\.[a-zA-Z]+[^?]   |   req\.query\.[a-zA-Z]+[^?]   |   req\.params\.[a-zA-Z]+[^?]
+```
+(acesso direto sem optional chaining). Fix: Zod, Joi, express-validator. Exceção: se há middleware de validação.
+
+### 8. CORS inseguro — HIGH
+```
+origin:\s*['"]\*['"]   |   Access-Control-Allow-Origin.*\*   |   cors\(\)
+```
+Fix: especificar origens permitidas explicitamente.
+
+## Severidade / bloqueio
+
+Checks 1-6 = CRITICAL (bloqueiam merge). Checks 7-8 = HIGH (recomendado). Qualquer CRITICAL → o gate não passa sem fix ou WAIVED explícito.
+
+## Falso-positivo (filtrar antes de reportar)
+
+Para cada match, checar: está em **comentário**? em **arquivo de teste**? há **sanitização** próxima (ex.: `DOMPurify.sanitize()` antes do `innerHTML`)? é **match espúrio** do padrão? Supressão por linha reconhecida: `// security-ignore: <id> - <motivo>`. Match que sobrevive a esse filtro = finding com evidência (arquivo:linha + trecho).

package/template/.claude/skills/pc-review-story/references/test-design.md

@@ -0,0 +1,37 @@
+# Test Design — nível de teste e prioridade
+
+> Protocolo aprofundado de estratégia de teste do `pc-review-story` (útil também para o `pc-develop-story` ao planejar a suíte). Origem destilada: task `qa-test-design.md`. Define O QUE testar, em QUE nível e POR QUÊ — cobertura eficiente sem redundância.
+
+## Nível de teste (onde cada cenário vive)
+
+- **Unit** — lógica pura, algoritmos, cálculos, validação.
+- **Integration** — interação entre componentes, operações de banco, multi-componente.
+- **E2E** — jornadas críticas do usuário, compliance, caminho ponta a ponta.
+
+**Shift left:** prefira unit sobre integration, integration sobre E2E. Não teste a mesma coisa em dois níveis (sem redundância).
+
+## Prioridade (por risco de negócio)
+
+- **P0** — crítico de receita, segurança, compliance.
+- **P1** — jornadas centrais do usuário, uso frequente.
+- **P2** — features secundárias, funções de admin.
+- **P3** — nice-to-have, uso raro.
+
+## Matriz de cenários
+
+```
+| ID           | Level       | Priority | Test                      | Justificativa          |
+| 1.3-UNIT-001 | Unit        | P0       | Valida formato de input   | Lógica de validação    |
+| 1.3-INT-001  | Integration | P0       | Serviço processa request  | Fluxo multi-componente |
+| 1.3-E2E-001  | E2E         | P1       | Usuário completa jornada  | Caminho crítico        |
+```
+
+Convenção de ID: `{epic}.{story}-{LEVEL}-{NNN}`.
+
+## Ordem de execução recomendada
+
+1. P0 Unit (falha rápido) → 2. P0 Integration → 3. P0 E2E → 4. P1 na ordem → 5. P2+ conforme tempo.
+
+## Uso no gate
+
+Cada AD/AC crítico deve ter pelo menos um cenário P0/P1 mapeado. Distribuição saudável tende à pirâmide (mais unit, menos E2E); E2E-pesado com unit escasso é sinal de custo de manutenção e lentidão — registrar como CONCERNS se a story introduz isso sem justificativa.

package/template/.claude/skills/pc-review-story/references/trace-requirements.md

@@ -0,0 +1,46 @@
+# Requirements Traceability — matriz AC → teste
+
+> Protocolo aprofundado de rastreabilidade do `pc-review-story`. Origem destilada: task `qa-trace-requirements.md`. Documenta a COBERTURA de cada AC por teste — não é para escrever código de teste.
+
+**Given-When-Then é usado só para DOCUMENTAR o que o teste valida, não como sintaxe do código de teste** (nada de BDD no código; siga o padrão de teste do projeto).
+
+## Para cada AC / requisito
+
+Mapeie o(s) teste(s) que o validam:
+
+```yaml
+requirement: "AC1 — login com credencial válida"
+tests:
+  - test_case: "should login with valid email and password"
+    given: "usuário registrado com credencial válida"
+    when: "submete o formulário de login"
+    then: "é redirecionado ao dashboard e a sessão é criada"
+    coverage: full        # full | partial | none | integration | unit
+```
+
+## Níveis de cobertura
+
+- **full** — requisito completamente testado.
+- **partial** — alguns aspectos testados, há gaps (registrar o gap).
+- **none** — nenhuma cobertura encontrada → finding.
+
+## Análise de gaps
+
+```yaml
+coverage_gaps:
+  - requirement: "AC3 — bloqueio após 5 tentativas"
+    coverage: none
+    gap: "nenhum teste exercita o contador de tentativas"
+    severity: bloqueante   # AC sem cobertura é finding do gate
+```
+
+## Resumo (para o gate)
+
+```
+Total de requisitos: X
+Fully covered: Y (Z%)
+Partially covered: A (B%)
+None: W  ← cada um vira finding
+```
+
+Conexão com o gate: AC com `coverage: none` = AC sem teste rastreável = FAIL desse AC (mesma régra do eixo de rastreabilidade do SKILL.md). `partial` sem justificativa material → CONCERNS.

package/template/.claude/skills/pc-run-pod/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: pc-run-pod
+description: "Executa um workflow de pod (wf-*.yaml) POR ETAPA com enforcement determinístico: lê o próximo passo não-done na ordem topológica do DAG, despacha o agente como subagente FRESCO, verifica o artefato EM DISCO (existe + casa com o template + todas as veto.assertions passam) antes de marcar done, e só então libera o próximo passo. State durável e retomável. Use para: rodar um pod, seguir um workflow de pod, retomar uma run de pod, executar wf-*.yaml."
+---
+
+# pc-run-pod — Runner Determinístico de Workflows de Pod
+
+Skill irmã de `pc-full-cycle`. Lá a **story é dado** e a skill é o motor; aqui o **pod é dado** (`workflows/wf-*.yaml` + templates + contratos de handoff) e este runner é o motor, na granularidade "passo do DAG". A conformidade ao processo é **forçada por código**, nunca por confiança no relato do subagente ("do not fake green").
+
+O enforcement vive em código testável: **`scripts/pc-run-pod.cjs`** (motor determinístico, com suíte própria em `scripts/__tests__/pc-run-pod.test.cjs` — DoD 1b). Esta skill é o protocolo de operação; a máquina de estados, a verificação em disco e o veto são do motor, não desta prosa.
+
+## Invocação
+
+```
+/pc-run-pod start  {pod} {workflow} [task-ref]   # inicia uma run
+/pc-run-pod resume {run-id}                       # retoma do 1o passo não-done
+/pc-run-pod next                                  # avança um passo
+/pc-run-pod status                                # resume o estado da run
+/pc-run-pod approve                               # libera um checkpoint.blocking
+/pc-run-pod revise                                # devolve a etapa (honra fix_cycle)
+/pc-run-pod abort                                 # encerra a run
+```
+
+Sob o capô, cada comando chama `node scripts/pc-run-pod.cjs <cmd> …` (ver `--help` no motor para as flags: `--workflow-file`, `--pod-root`, `--state`, `--runs-root`, `--run-id`, `--step`).
+
+## Estado durável (retomável)
+
+Arquivo: `.power-claude/pod-runs/{pod}/{workflow}/{run-id}/state.json`. `run-id` = timestamp ISO-8601 sanitizado (ex.: `2026-07-24T18-00-00Z`). Schema exato (SPEC §B1):
+
+```json
+{
+  "pod": "hormozi-method",
+  "workflow": "wf-build-offer",
+  "run_id": "2026-07-24T18-00-00Z",
+  "mode": "interactive",
+  "task_ref": "…",
+  "steps": {
+    "discovery": { "status": "done", "agent": "offer-architect", "artifact": "artifacts/discovery.md", "template": "templates/discovery-tmpl.md", "checkpoint": null, "started_at": "…", "verified_at": "…" },
+    "build":     { "status": "running", "agent": "offer-architect", "artifact": "artifacts/build.md", "template": "templates/offer-tmpl.md", "checkpoint": null, "started_at": "…", "verified_at": null },
+    "red_team":  { "status": "pending", "agent": "pod-critic", "artifact": null, "template": "templates/critique-tmpl.md", "checkpoint": "blocking", "started_at": null, "verified_at": null }
+  },
+  "updated_at": "ISO-8601"
+}
+```
+
+**Status de etapa:** `pending → running → done` (SPEC). Extensões documentadas do runner: `awaiting_approval` (checkpoint.blocking verificado, aguardando gate) e `failed` (aborto / fix_cycle esgotado). O agente **nunca** escreve o `state.json` — quem decide a transição é o motor.
+
+**Retomada:** ao ser invocada, a skill SEMPRE lê o `state.json` primeiro (via `resume {run-id}` ou `--state`), valida o schema (Risco 4: state corrompido → HALT explícito, nunca "conserto" silencioso) e continua do primeiro passo não-`done` na ordem topológica. Sem edição manual para "pular" etapa — mesma disciplina do Sequence Lock do `pc-full-cycle`.
+
+## Loop de execução (o que o motor faz por `advance`)
+
+```
+0. Ler/criar state.json (retomada; valida schema antes de decidir)
+1. Se há passo running:
+     verifica EM DISCO (artefato existe + template conforme + TODAS as veto.assertions)
+       falhou → BLOCKED: não avança, próxima etapa NÃO roda (o passo fica running)
+       passou → verified_at gravado; se checkpoint.blocking → awaiting_approval (para)
+                senão → done; segue
+2. Se há passo awaiting_approval → só `approve`/`revise` destravam
+3. Próximo passo pending na ordem topológica com depends_on satisfeitos:
+     status→running, started_at, artifact atribuído, brief emitido (subagente FRESCO)
+4. Sem pendências → complete
+```
+
+**Subagente FRESCO por etapa (AC3):** cada passo é despachado como agente novo — nunca reaproveitado entre etapas do mesmo run. O único reaproveitamento é o fluxo de `revise` (reexecução da mesma etapa). O brief inclui: paths exatos (artefato + template), o veto que será verificado, limites de autoridade (não marca done; sem push) e a instrução de **retorno ≤15 linhas** — verificável por inspeção de `buildBrief` no motor.
+
+## Verificação pós-etapa (independente, EM DISCO)
+
+O relato do subagente **não é evidência**. Antes de `done`, o motor confere o disco (`verifyStep`):
+
+| Verificação | Como |
+|-------------|------|
+| Artefato existe | arquivo em `state.steps[id].artifact` presente em disco; ausente → BLOCKED |
+| Template conforme | toda SEÇÃO (heading nível 2+) do template consta no artefato (`checkTemplateConformance`) |
+| Veto passa | TODAS as `veto.assertions` avaliadas por máquina (`section_exists`, `field_matches`, `file_referenced_exists`, `count_gte`, `json_schema_valid`) — resultado binário e determinístico; qualquer uma falsa → BLOCKED |
+
+Nenhuma verde é fabricada: uma etapa bloqueia a seguinte porque o motor **recusa avançar** enquanto a verificação da corrente não passar. Estático (SF1.1) prova FORMA do contrato; este runner prova que o artefato produzido casa com o contrato.
+
+## Checkpoint bloqueante (`approve` / `revise`)
+
+Passos com `checkpoint.blocking: true` param o runner após a verificação passar, aguardando decisão humana. `approve` marca `done` e libera o próximo. `revise` devolve a etapa a `pending` para reexecução; se a etapa declara `fix_cycle: {to, max_iterations}`, o intervalo `[fix_cycle.to .. etapa]` volta a `pending` (a ÚNICA aresta para trás permitida — SPEC §B2a), sob o teto `max_iterations` (excedido → HALT, etapa `failed`).
+
+## Sequence Lock (inegociável)
+
+1. Passos **em ordem topológica**. Nenhum passo N+1 antes da verificação em disco de N passar.
+2. O agente **não** escreve o `state.json`; a transição é decidida por código.
+3. `resume` sempre lê o state primeiro; nunca aceita edição manual para "pular".
+4. `checkpoint.blocking` só é destravado por `approve`/`revise` — nunca por relato.
+5. Este runner garante **PROCESSO e FORMA**; qualidade de conteúdo subjetiva é do `checkpoint.blocking` (pod-critic), nunca do veto determinístico.
+
+## Modos
+
+| Modo | Comportamento |
+|------|---------------|
+| `interactive` | Reporta entre etapas; pausa em BLOCKED, checkpoint e decisões |
+| `yolo` | Autônomo entre etapas; para só em HALT (verificação falha, checkpoint, fix_cycle esgotado) |
+
+## Fronteiras
+
+- Nunca `git push` / `gh pr create` / merge — exclusivo do papel devops.
+- Nunca edita o `state.json` para "pular" etapa ou fabricar verificação.
+- Nunca aceita veto em prosa avaliada por LLM (proibido por ADR-002; anula a garantia-por-código).
+- Não gera `wf-*.yaml` (isso é o forge / SF1.4); aqui o workflow é dado de entrada.
+
+## Memória do pod (lifecycle SF2.2 — G1/ADR-003)
+
+O runner APRENDE com a própria execução, consumindo o motor `pod-memory.cjs` (SF2.1):
+
+- **Appenda ao log cru** `<pod>/memory/learnings.jsonl` (append-only) no fechamento de cada etapa/run, com entrada estruturada `tier: normal`:
+  - `verification_failed` (etapa bloqueada) → **candidato**: `trigger`/`recommendation`/`evidence` montados DETERMINISTICAMENTE dos `failures` (etapa + veto violado + causa), nunca por julgamento de LLM.
+  - fechamento limpo (`complete`) → **padrão-ok**: registra que a sequência completou sem bloqueio.
+  - O runner **nunca** marca `tier: critical` por conta própria (exige `attributed_by` humano/regra — trava anti-inflação do ADR-003).
+- **Consolida** (`podMemory.consolidate`) sempre no fechamento de run e/ou a cada K=20 appends acumulados — o que ocorrer primeiro. A lógica de dedup/conflito/poda/CRITICAL vive inteiramente na SF2.1; o runner só decide a cadência.
+- **Injeta no brief SOMENTE** `<pod>/memory/learnings.consolidated.md` (curado, top-N, ≤~1.500 tokens), e apenas quando tem conteúdo real — scaffold vazio é omitido (sem placeholder). **NUNCA lê nem menciona o log cru** `learnings.jsonl`: nenhum caminho do brief referencia o `.jsonl` (garantia testada — teste negativo). É o contrato inegociável do ADR-003: o agente lê só o consolidado.
+
+**Comentário do dono no checkpoint (SF11.5 / ADR-020 §Revisão 3).** O runner **não** grava julgamento humano: `approve`/`revise` decidem transição e só isso. Quem captura o comentário é o COMANDO do pod, chamando `scripts/pod-memory-note.cjs` — invocador fino sobre a mesma API de memória:
+
+```bash
+node scripts/pod-memory-note.cjs --state <state.json> --workflow-file <wf.yaml> \
+     --step <id> --verdict approve|revise --file <arquivo com o comentário>
+```
+
+A mensagem viaja por **arquivo ou stdin, nunca por argv** (aspas/acentos/quebras de linha do dono quebram no shell, e argv é visível em `ps`); o arquivo temporário é escrito pela ferramenta de escrita do agente, **nunca por heredoc/echo**. Comentário vazio ⇒ **nada é gravado** (silêncio não vira learning). Detalhe: `docs/mecanismos/memoria-evolutiva.md`.

package/template/.claude/skills/pc-validate-story/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: pc-validate-story
+description: "Valida um draft de story com checklist de 10 pontos e emite veredito GO/NO-GO (Draft → Ready). Use para: validar story antes de codar, checar prontidão de um draft, decidir GO/NO-GO, transicionar story para Ready."
+---
+
+# pc-validate-story — Validação de Story (papel PO)
+
+Protocolo completo e autocontido. Nenhuma engine externa é necessária.
+
+## Quando usar
+
+Story em Status **Draft** que precisa de veredito antes de qualquer implementação. Nenhuma story entra em `pc-develop-story` sem GO registrado aqui.
+
+## Pré-condições
+
+1. Arquivo da story existe em `docs/stories/{epic}.{n}.story.md`.
+2. Status atual é `Draft` (se já for `Ready` ou posterior, pare e informe — não revalide silenciosamente).
+3. A SPEC ou epic de origem está acessível (necessária para rastrear ACs).
+
+## Protocolo
+
+### Passo 1 — Ler tudo antes de julgar
+
+Leia a story completa, a SPEC/epic de origem e, se citados, os arquivos de arquitetura relevantes. Não emita veredito parcial com leitura parcial.
+
+### Passo 2 — Checklist de 10 pontos
+
+Avalie cada item como **PASS**, **PARTIAL** ou **FAIL**, com evidência (citação ou ausência concreta):
+
+| # | Item | Critério de PASS |
+|---|---|---|
+| 1 | Título claro | Identifica o entregável sem ambiguidade; formato `{epic}.{n}: {resumo}` |
+| 2 | Descrição do problema | Explica POR QUE a story existe, não só o quê |
+| 3 | ACs testáveis e rastreáveis | Cada AC é verificável objetivamente E rastreia a um item da SPEC/epic (sem AC inventado). Quando a story tiver AC com bloco ` ```oraculo `, rode `node scripts/validate-story-acs.cjs <story>` (validador comportamental de ACs, `docs/mecanismos/validador-de-acs-do-ciclo.md`) antes de julgar este item — não confie só na prosa. |
+| 4 | Escopo IN/OUT | Lista explícita do que está dentro E do que está fora |
+| 5 | Dependências | Stories, serviços ou decisões prévias identificadas (ou "nenhuma" explícito) |
+| 6 | Estimativa de complexidade | Presente e coerente com o escopo (P/M/G ou pontos) |
+| 7 | Valor de negócio | Uma frase ligando a story ao objetivo do epic |
+| 8 | Riscos | Riscos técnicos/de produto nomeados, com mitigação quando material |
+| 9 | Critério de Done | Definição objetiva além dos ACs (gates verdes, docs, gate file) |
+| 10 | Alinhamento com epic | Não contradiz nem duplica outras stories do epic |
+
+> **AC de investigação (forma válida):** um AC pode ter a forma "investigar X → aplicar o fix **OU** documentar como não-aplicável com evidência". É testável (o entregável é a conclusão evidenciada) e evita tanto invenção quanto scope creep. Sem a cláusula de evidência, falha o item 3.
+
+### Passo 3 — Veredito
+
+- **GO** ⇔ score **≥ 7 PASS** E **nenhum FAIL nos itens 3 (ACs) e 4 (escopo)**.
+- **NO-GO** caso contrário. Liste cada correção necessária, numerada, acionável e apontando o item do checklist que falhou.
+
+PARTIAL conta como não-PASS para o score. Não arredonde para cima.
+
+### Passo 4 — Ações por veredito
+
+**GO:**
+1. Atualize `Status: Draft` → `Status: Ready` na story.
+2. Registre na story uma seção `## Validação (PO)` com: data, score (X/10), tabela resumida do checklist e veredito.
+3. Informe a próxima ação: `pc-develop-story`.
+
+**NO-GO:**
+1. Status permanece `Draft`.
+2. Registre a mesma seção `## Validação (PO)` com veredito NO-GO e a lista de correções.
+3. Devolva ao autor da story (humano ou papel SM). Não corrija escopo você mesmo.
+
+## Limites de autonomia
+
+**PODE corrigir diretamente (lacunas mecânicas):**
+- Typos, formatação, numeração de ACs, links quebrados para arquivos existentes.
+- Preencher campo "Dependências: nenhuma" quando a análise confirma ausência.
+- Completar o critério de Done com os gates padrão do ambiente (lint/typecheck/test + gate file), se omitido.
+
+**NÃO PODE (mudança material — sempre NO-GO ou pergunta ao humano):**
+- Adicionar, remover ou reescrever ACs em substância.
+- Mover itens entre IN e OUT do escopo.
+- Alterar estimativa, prioridade ou valor de negócio.
+- Inventar requisitos que não rastreiam à SPEC/epic.
+
+**Toda correção autônoma vira registro:** adicione à story uma linha `[AUTO-DECISION] {o que foi corrigido e por quê}` na seção de Validação. Sem registro, a correção não aconteceu.
+
+## Anti-padrões
+
+- Emitir GO "por confiança" sem preencher o checklist item a item.
+- Validar a própria story que você acabou de escrever (anti-self-review — ver `.claude/rules/authority.md`).
+- Rebaixar item 3 ou 4 para PARTIAL para viabilizar um GO que seria NO-GO.
+- Iniciar implementação "enquanto isso" — validação e implementação são papéis distintos.
+
+## Template da seção de Validação (copiar para a story)
+
+```markdown
+## Validação (PO)
+- Data: {YYYY-MM-DD}
+- Veredito: GO | NO-GO
+- Score: {X}/10
+
+| # | Item | Resultado | Evidência |
+|---|---|---|---|
+| 1 | Título claro | PASS | ... |
+| ... | ... | ... | ... |
+
+Correções necessárias (se NO-GO):
+1. {correção acionável, apontando o item do checklist}
+
+[AUTO-DECISION] {correções mecânicas aplicadas, se houver}
+```
+
+## Casos de borda
+
+- **Story sem SPEC/epic de origem:** item 3 não é verificável → FAIL automático no item 3 → NO-GO. Peça ao humano a fonte antes de revalidar.
+- **Re-validação após NO-GO:** rode o checklist COMPLETO de novo, não só os itens que falharam — correções podem ter quebrado outros itens.
+- **Story trivial (bug fix curto):** o checklist vale igual, mas itens 6-8 podem passar com uma linha cada. Rigor não é burocracia; é proporcionalidade com evidência.
+- **Conflito com outra story do epic (item 10):** NO-GO e sinalize as duas stories — nunca resolva o conflito editando a outra story.
+
+## Saída esperada
+
+Resposta final contém: veredito (GO/NO-GO), score X/10, tabela do checklist, lista de correções (se NO-GO), lista de `[AUTO-DECISION]` (se houver) e o novo Status da story.