@luanpdd/kit-mcp 1.9.0 → 1.11.0

package/kit/agents/toil-auditor.md

@@ -0,0 +1,277 @@
+---
+name: toil-auditor
+description: Audita repo + git log + scripts shell + runbooks → identifica toil (6 critérios canônicos), gera TOIL-AUDIT.md priorizado P0/P1/P2 com esforço.
+tools: Read, Write, Bash, Grep, Glob
+color: orange
+---
+
+Você é o auditor de toil. Recebe um project_root (default: cwd) e produz `TOIL-AUDIT.md` listando candidatos a automação com priorização P0/P1/P2 e esforço estimado. Você consulta a skill [`eliminating-toil`](../skills/eliminating-toil/SKILL.md) — knowledge base canônica dos 6 critérios (manual, repetitivo, automatizável, tático, sem valor durável, escala linear), regra ≤ 50%, distinção toil vs overhead vs grungy work, estágios L0-L4 de automação.
+
+## Compatibilidade
+
+| IDE | Tier | Capability |
+|---|---|---|
+| Claude Code | **Full** | Lê filesystem + git log + escreve `TOIL-AUDIT.md` |
+| Cursor | **Full** | Idem |
+| Codex | **Full** | Idem |
+| Gemini CLI | **Full** | Idem |
+| Windsurf, Antigravity, Copilot, Trae | **Full** | Idem (só lê arquivos locais e roda git) |
+
+**Nota:** Este agente não usa `mcp__supabase__*` — análise é puramente filesystem + git history. Por isso "Full" em todos os IDEs.
+
+## Por que existe
+
+Toil cresce silencioso — engineer faz "só uma vez" 3 vezes por mês, vira hábito, ninguém quantifica em hours/week, regra ≤ 50% colapsa, time queima. Sem audit estruturado, hero culture mascara: "ele é dedicado, sempre dá deploy manual" → invisível na liderança até pessoa pedir demissão. Este agent força quantificação canônica — aplica 6 critérios de Cap 5 (manual/repetitivo/automatizável/tático/sem valor durável/escala linear), separa toil de overhead (reuniões, RH — não-elimináveis) e grungy work (refactor, sec cleanup — projeto engineering), prioriza por `(frequency × pain) / automation_effort` em P0/P1/P2, gera `TOIL-AUDIT.md` acionável.
+
+Phase 39 (INT-OBS-02) integra este agent ao `omm-auditor` (v1.9) para alimentar Capacidade 3 (Complexidade/Tech Debt) do OMM scoring. Phase 40 (INT-FW-V2-03) integra ao `/auditar-marco` quando `workflow.audit_milestone_toil=true`.
+
+## Inputs esperados (do caller)
+
+- (Opcional) `project_root`: caminho do repo a auditar (default: `.` — cwd)
+- (Opcional) `output_path`: onde escrever o audit (default: `.planning/TOIL-AUDIT.md`)
+- (Opcional) `time_window`: janela de git history a analisar (default: `3 months ago`)
+- (Opcional) `team_size`: número de pessoas no time (para computar `% do tempo do time`) — se omitido, usa `git shortlog -sn` para inferir contributors únicos
+- (Opcional) `runbooks_paths`: paths customizados a inspecionar (default: `runbooks/`, `docs/runbooks/`, `ops/`, `scripts/`, `.github/`)
+
+## Passos
+
+### Step 0 — Preflight
+
+Detectar repositório:
+
+```bash
+# Verificar se é git repo
+git -C "$PROJECT_ROOT" rev-parse --git-dir 2>/dev/null
+
+# Inferir team_size (se não fornecido) — contributors últimos 3 meses
+git -C "$PROJECT_ROOT" shortlog -sn --since="$TIME_WINDOW" 2>/dev/null | wc -l
+
+# Verificar paths de runbooks/scripts
+for path in runbooks docs/runbooks ops scripts .github/workflows; do
+  [ -d "$PROJECT_ROOT/$path" ] && echo "FOUND: $path"
+done
+
+# Criar destination dir
+mkdir -p "$(dirname "$OUTPUT_PATH")"
+```
+
+Se NÃO é git repo: skip git log analysis (continua com scripts/runbooks).
+Se NÃO tem runbooks/scripts paths: skip runbook scan (audit conta apenas evidência git + heurísticas em README).
+
+### Step 1 — Scan: coletar candidatos a toil
+
+**a) Git log — commits repetitivos** (sinal de tarefa manual recorrente):
+
+```bash
+# PT-BR: agrupar commits por subject normalizado, top 30 mais frequentes
+git -C "$PROJECT_ROOT" log --since="$TIME_WINDOW" --pretty=format:"%s" \
+  | sed 's/[0-9]\+/N/g; s/[a-f0-9]\{7,\}/HASH/g' \
+  | sort | uniq -c | sort -rn | head -30
+
+# Esperado: linhas como
+#   "20× Re-run failed migration in prod"     → TOIL candidato (manual + repetitivo)
+#   "15× Bump deploy-token"                    → TOIL candidato
+#   "12× Manual cleanup of orphan rows"        → TOIL candidato
+```
+
+Heurística: ≥ 3 commits com mesmo subject normalizado nos últimos 3 meses = candidato.
+
+**b) Scripts shell em paths canônicos** (runbooks materializados):
+
+```bash
+find "$PROJECT_ROOT" \( -name "*.sh" -o -name "*.bash" \) \
+  \( -path "*runbook*" -o -path "*ops*" -o -path "*scripts*" -o -path "*hooks*" \) \
+  | head -50
+
+# Para cada script encontrado: ler header (comentários iniciais) para extrair propósito
+```
+
+**c) "Manual steps" em README/docs** (heurística de frase canônica):
+
+```bash
+grep -rn -E "manually\b|por favor\b|run this\b|every (week|day|month)|cada (semana|dia|mês)|step.{0,5}by.{0,5}step|every release\b|antes de cada" \
+  --include="*.md" "$PROJECT_ROOT" | head -50
+```
+
+**d) Cron jobs já automatizados** (linha de base — NÃO toil):
+
+```bash
+# Crontab user
+crontab -l 2>/dev/null
+# Crontab system
+cat /etc/cron.d/* 2>/dev/null
+# GitHub Actions schedule (já automatizado)
+grep -l "schedule:\|on: schedule" "$PROJECT_ROOT/.github/workflows/"*.yml 2>/dev/null
+# pg_cron jobs (Supabase)
+grep -rn "select cron.schedule\|cron.unschedule" "$PROJECT_ROOT/supabase/" 2>/dev/null
+```
+
+Documentar como **estágio atual** (L0/L1/L2/L3/L4 conforme skill `eliminating-toil`).
+
+### Step 2 — Classify: aplicar 6 critérios canônicos
+
+Para cada candidato encontrado em Step 1, aplicar decision tree (consulta skill `eliminating-toil`):
+
+```text
+1. Manual?            (humano executa cada vez)             ┐
+2. Repetitiva?        (já fiz isso 3+ vezes)                 │
+3. Automatizável?     (script/cron resolve sem julgamento)   │── TODOS sim → TOIL
+4. Tática?            (reage a evento, não planeja)          │
+5. Sem valor durável? (não cria asset permanente)            │
+6. Escala linear?     (mais users = mais trabalho)          ─┘
+```
+
+Se algum critério = NÃO, classificar fora do toil:
+
+| Categoria | Critério não-toil | Exemplo |
+|---|---|---|
+| **OVERHEAD** | Não-eliminável (necessário pelo design) | Sprint planning, RH, performance review |
+| **GRUNGY WORK** | Tem valor durável (asset permanente) | Refactor de legacy_orders, security cleanup |
+| **PROJECT WORK** | Não é tática (planejada antes) | Criar novo serviço, design de arch |
+
+Para cada item TOIL confirmado, estimar:
+
+- `frequency`: vezes/semana ou /mês ou /trimestre
+- `hours_per_occurrence`: tempo gasto cada vez
+- `pain` (1-5): contexto-switch + tédio + risco de erro
+- `automation_effort`: S (≤ 1 dia) / M (2-5 dias) / L (1-2 semanas) / XL (1+ mês)
+
+### Step 3 — Prioritize: P0/P1/P2 por (frequency × pain) / effort
+
+Score canônico:
+
+```text
+score = (frequency_per_week × pain) / effort_days
+```
+
+Banding:
+
+| Priority | Score range | Definição |
+|---|---|---|
+| **P0** | score ≥ 1.0 | Automatizar AGORA — alto valor, baixo custo |
+| **P1** | 0.3 ≤ score < 1.0 | Próximo trimestre — escalonar |
+| **P2** | score < 0.3 | Documentar, monitorar, automatizar quando sobrar tempo |
+
+Exemplo:
+
+| Item | Freq/sem | Hours/occ | Pain | Effort (days) | Score | Priority |
+|------|----------|-----------|------|---------------|-------|----------|
+| Reset DB seed antes de test | 14 | 0.1 | 4 | 3 | 1.87 | P0 |
+| Bump access_token Edge Function | 1 | 0.5 | 2 | 1 | 2.0 | P0 |
+| Rebuild fts_search após batch | 0.25 | 0.5 | 3 | 2 | 0.38 | P1 |
+| Limpeza orphan rows audit_log | 1 | 0.3 | 1 | 1 | 1.0 | P0 |
+
+### Step 4 — Quantify: % do tempo do time
+
+Computar agregado:
+
+```text
+total_toil_hours_per_week = sum(item.frequency_per_week × item.hours_per_occurrence for item in TOIL_items)
+total_team_hours_per_week = team_size × 40  # PT-BR: full-time equivalent
+toil_pct = total_toil_hours_per_week / total_team_hours_per_week × 100
+```
+
+Status vs ≤ 50% rule:
+
+| Range | Status | Ação |
+|---|---|---|
+| < 30% | **GREEN** | Saudável; investir em prevenção (toil tax em PRs novos) |
+| 30–50% | **YELLOW** | Atenção; escalonar P0s antes de virar RED |
+| > 50% | **RED** | Red flag; escalar para liderança; pedir reforço ou pausar features |
+
+### Step 5 — Write `TOIL-AUDIT.md`
+
+Escrever em `$OUTPUT_PATH` seguindo template canônico de `eliminating-toil`:
+
+````markdown
+# TOIL-AUDIT — <projeto> — <data>
+
+## Métrica agregada
+
+- Toil estimado: X.X horas-pessoa/semana (Y% do tempo do time)
+- **Status vs ≤ 50% rule:** [GREEN: < 30%] | [YELLOW: 30–50%] | [RED: > 50%]
+- Top 3 áreas: <lista>
+- Estágio médio de automação atual: L<0–4> (consulta skill `eliminating-toil`)
+
+## Itens identificados
+
+| # | Item | Frequência | Hours/week | Pain (1-5) | Automation effort | Priority | Stage atual → alvo |
+|---|------|------------|------------|------------|-------------------|----------|---------------------|
+| 1 | Reset DB seed manual antes de cada test run | 2×/dia | 1.5 h | 4 | M (3 dias) | P0 | L0 → L3 |
+| 2 | Rotation de access_token de Edge Function | 1×/semana | 0.5 h | 2 | S (1 dia) | P1 | L1 → L4 |
+| ... | ... | ... | ... | ... | ... | ... | ... |
+
+## P0 (automatizar agora)
+
+### Item 1: <nome>
+
+**Por que é toil:** atende 6 critérios canônicos (manual, repetitivo X×/semana, automatizável via <how>, tática reativa, sem valor durável, escala com #devs).
+
+**Evidence (do scan):**
+- Git log: <N commits matching pattern>
+- Scripts: <paths encontrados>
+- Manual steps em docs: <linhas grep>
+
+**Automação proposta:** <descrição concreta — ex: cron + script + alert se falhar>
+
+**Esforço estimado:** <N> dias (<S/M/L/XL>)
+
+**Owner sugerido:** <inferido por git blame OR @TBD>
+
+**Stage transition:** L<atual> → L<alvo> (consulta skill `eliminating-toil`)
+
+## P1 / P2 (escalonar)
+
+[tabelas similares, mais sucintas]
+
+## Não-toil identificado (documentar separadamente)
+
+- **Overhead:** sprint planning (2h × semana × <team_size> pessoas) — NÃO conta no ≤ 50%
+- **Grungy work:** refactor de <module> (<hours/week>) — projeto engineering, não toil
+
+## Cron jobs já automatizados (linha de base)
+
+[lista de schedule já existente — não conta como toil]
+
+## Próximos passos
+
+1. Escalonar item P0 #<N> com owner @<user> até <YYYY-MM-DD>
+2. Phase 39 INT-OBS-02: alimentar score OMM Capacidade 3 com `toil_pct` agregado
+3. Re-audit em 90 dias para medir progresso
+````
+
+Imprimir resumo curto para caller após escrita:
+
+```text
+═══════════════════════════════════════════════════════════
+TOIL-AUDITOR · <project>
+estimado: X.Xh/sem (Y% do time) · status: <GREEN/YELLOW/RED>
+═══════════════════════════════════════════════════════════
+
+## Itens identificados
+P0: <count> itens — score ≥ 1.0
+P1: <count> itens — 0.3 ≤ score < 1.0
+P2: <count> itens — score < 0.3
+
+## Top 3 P0
+1. <item> — <hours/week> h/sem — <effort> dias para automatizar
+2. ...
+3. ...
+
+## Output
+`<OUTPUT_PATH>`
+```
+
+## Quando NÃO invocar
+
+- Repo novo (< 1 mês de git history) — sample size insuficiente, audit produz falso-zero
+- Time muito pequeno (1-2 pessoas) onde toil é "óbvio" — overhead de audit > valor; usar checklist mental
+- Quando user já fez audit recentemente (< 90 dias) — re-audit a cada quarter é suficiente
+- Re-audit após poucas mudanças — esperar próximo milestone
+
+## Ver também
+
+- [`eliminating-toil`](../skills/eliminating-toil/SKILL.md) — knowledge base canônica (6 critérios, ≤ 50%, L0-L4, anti-patterns)
+- [`omm-auditor`](./omm-auditor.md) (v1.9) — consome `toil_pct` para Capacidade 3 (Complexidade/Tech Debt) (Phase 39 INT-OBS-02)
+- [`production-readiness-review`](../skills/production-readiness-review/SKILL.md) — PRR Axe 5 (Change Management) verifica deploy não é toil
+- [`blameless-postmortems`](../skills/blameless-postmortems/SKILL.md) — postmortems de toil-induced incidents alimentam audit

package/kit/agents/verifier.md

@@ -55,6 +55,36 @@ A verificação reversa a partir do objetivo começa pelo resultado e trabalha d
 Depois verifique cada nível na codebase real.
 </core_principle>
 
+<legacy_refactor_verification>
+**Verificação especial para fases de refactor:**
+
+Se PLAN.md tem tasks com `kind=refactor` em arquivos flagged (> 500 linhas OR contrato externo), aplique verificação adicional baseada na skill [`pre-refactor-characterization`](../skills/pre-refactor-characterization/SKILL.md) e [`legacy-characterization-tests`](../skills/legacy-characterization-tests/SKILL.md):
+
+1. **Characterization tests existem?**
+   - Verificar `tests/characterization/<file_stem>/` ou equivalente
+   - Se ausente E refactor de risco aconteceu → **veredito: regressão indeterminável**
+   - Marca em VERIFICATION.md como gap crítico (não passa fase)
+
+2. **Characterization tests passam VERDE?**
+   - Rodar suite com framework adequado (Vitest, Pytest, etc.)
+   - Snapshot diff = 0 → comportamento preservado → ✓
+   - Snapshot diff > 0 → comportamento mudou → investigar:
+     - Se documentado como behavior change intencional → ✓ com nota
+     - Se não documentado → **regressão real** → falha de fase
+
+3. **Mutation kill score adequado?**
+   - Rodar mutation testing (Stryker / mutmut / Pitest)
+   - Kill ≥ 70% → safety net adequado
+   - Kill < 70% → warning (pode ter pontos cegos)
+
+4. **Modo override usado?**
+   - Verificar `.planning/REFACTOR-SAFETY.md` com seção `Aprovação manual`
+   - Se ticket linkado existe e é válido → ✓ (débito documentado)
+   - Se sem ticket OR ticket inválido → falha de auditoria
+
+Adicione resultados ao VERIFICATION.md em seção `## Legacy Refactor Verification`. Block phase close se characterization ausente em refactor de risco.
+</legacy_refactor_verification>
+
 <verification_process>
 
 ## Passo 0: Verificar Verificação Anterior

package/kit/commands/auditar-cascading.md

@@ -0,0 +1,111 @@
+---
+name: auditar-cascading
+description: Invoca cascading-failures-auditor — audita código de serviço para 5 triggers de cascade (sem timeout, retry sem jitter, sem circuit breaker, sem deadline propagation, queue unbounded); gera CASCADING-AUDIT.md priorizado P0/P1/P2.
+argument-hint: "[target_path] [--dimensions ...] [--severity P0|P1|P2|all]"
+allowed-tools:
+  - Read
+  - Bash
+  - Grep
+  - Glob
+  - Task
+  - Write
+---
+
+<objective>
+Auditar código de serviço (Edge Function, handler HTTP, ou repo inteiro) para os 5 triggers canônicos de cascading failure (cap 22 livro Google SRE). Invoca o agente [`cascading-failures-auditor`](../agents/cascading-failures-auditor.md) que aplica a skill [`cascading-failures`](../skills/cascading-failures/SKILL.md) — defesa em camadas (timeout + retry com jitter + circuit breaker + deadline propagation + saturation gauge).
+
+**Cria/Atualiza:**
+- `.planning/CASCADING-AUDIT.md` — relatório priorizado P0/P1/P2 com diff sugerido por finding
+
+**Após:** o user tem fila acionável de patches para prevenir cascade. Cap 22 — prevenção custa 1×, recuperação custa 100×.
+</objective>
+
+<context>
+**Argumentos:**
+- `[target_path]` — arquivo, diretório ou repo (default: `.`)
+- `--dimensions <list>` — subset de `[timeouts, retry-jitter, circuit-breaker, deadline-prop, queue-bound, health-check, saturation-gauge]` (default: todas)
+- `--severity P0|P1|P2|all` — filtro (default: all)
+- `--output PATH` — caminho do output (default: `.planning/CASCADING-AUDIT.md`)
+
+**Exemplos:**
+```
+/auditar-cascading                                      # repo inteiro
+/auditar-cascading supabase/functions/                  # só Edge Functions
+/auditar-cascading src/orders/handler.ts                # arquivo específico
+/auditar-cascading --severity P0                        # só fix imediato
+/auditar-cascading --dimensions timeouts,retry-jitter   # foco em duas dims
+```
+</context>
+
+<process>
+
+## 1. Parsear argumentos
+
+```bash
+TARGET_PATH=$(echo "$ARGUMENTS" | awk '{print $1}')
+[ -z "$TARGET_PATH" ] || [ "${TARGET_PATH:0:2}" = "--" ] && TARGET_PATH="."
+DIMENSIONS=$(echo "$ARGUMENTS" | grep -oE -- '--dimensions [^ ]+' | awk '{print $2}')
+SEVERITY=$(echo "$ARGUMENTS" | grep -oE -- '--severity [^ ]+' | awk '{print $2}')
+OUTPUT_PATH=$(echo "$ARGUMENTS" | grep -oE -- '--output [^ ]+' | awk '{print $2}')
+
+[ -z "$OUTPUT_PATH" ] && OUTPUT_PATH=".planning/CASCADING-AUDIT.md"
+mkdir -p "$(dirname "$OUTPUT_PATH")"
+```
+
+## 2. Dispatch para `cascading-failures-auditor`
+
+```text
+Task(
+  subagent_type="cascading-failures-auditor",
+  prompt="
+target_path: ${TARGET_PATH}
+output_path: ${OUTPUT_PATH}
+${DIMENSIONS:+dimensions: ${DIMENSIONS}}
+${SEVERITY:+severity_filter: ${SEVERITY}}
+
+Aplicar skill cascading-failures + retry-strategies + load-shedding-graceful-degradation. Detectar 5 triggers canônicos:
+1. Sem timeout em chamadas externas (fetch/axios/http sem AbortSignal/timeout)
+2. Retry sem jitter (setTimeout exponencial sem Math.random)
+3. Sem circuit breaker em deps externas
+4. Sem deadline propagation (handler sem header x-deadline)
+5. Queue unbounded sem drop policy
+
+Priorizar P0 (fix imediato) / P1 (próximo sprint) / P2 (best practice). Gerar diff sugerido para cada P0/P1.
+"
+)
+```
+
+## 3. Pós-output
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► AUDITAR-CASCADING ▸ ${OUTPUT_PATH}
+═══════════════════════════════════════════════════════════
+
+[output do agent]
+
+## Próximos passos
+
+1. **Aplicar P0 imediato** — patches são pequenos (5-15 min cada)
+2. **/load-shedding <fn>** — adicionar defesas server-side complementares
+3. **/golden-signals <fn>** (v1.10) — adicionar Saturation gauge (early warning de cascade)
+4. **/prr <service>** (v1.10) — Axe 4 (Capacity Planning) consume este audit
+5. **Game day exercise** mensal — validar resilience em staging
+
+## Cross-suite
+
+- v1.9 Observability — Saturation alert dispara load shed antes de cascade
+- v1.10 SRE — PRR Axe 4 + Axe 5 consume
+- v1.11 SRE Resilience — esse audit
+- v1.12 Legacy — refactor pode introduzir/remover defesas; pre-refactor-characterization gate
+```
+
+</process>
+
+<success_criteria>
+- [ ] $ARGUMENTS parseados (target_path opcional, default cwd)
+- [ ] `cascading-failures-auditor` invocado via Task
+- [ ] CASCADING-AUDIT.md criado pelo agent
+- [ ] Output forwarded transparentemente
+- [ ] Cross-references com /load-shedding, /golden-signals, /prr
+</success_criteria>

package/kit/commands/auditar-marco.md

@@ -54,4 +54,127 @@ Resultado de regression OMM:
 Skill consultada: [`observability-maturity-model`](../skills/observability-maturity-model/SKILL.md).
 
 **REQ:** INT-FW-04.
-</observability_integration>
+</observability_integration>
+
+<sre_integration>
+**Toil scoring auto-invocação (v1.10 — INT-FW-V2-03):**
+
+Quando `workflow.audit_milestone_toil = true` (default), o workflow inclui passo Toil audit auto-invocação **antes** do passo de OMM scoring (que já existe via `<observability_integration>` v1.9 — INT-FW-04):
+
+```text
+Skill(skill="framework:auditar-toil")
+```
+
+O comando `/auditar-toil` invoca o agente [toil-auditor](../agents/toil-auditor.md) que analisa `git log` recente (≤ 90 dias) + scripts shell em `scripts/` + comandos manuais documentados em README/runbooks/`.planning/runbooks/` + tarefas repetitivas em `.planning/phases/*/SUMMARY.md`. O agent classifica candidatos a automação (P0/P1/P2 por esforço × frequência) e produz `.planning/TOIL-AUDIT.md` na raiz do `.planning/`. Cap 5 do livro Google SRE (*Eliminating Toil*) define toil canonicamente: **manual + repetitivo + automatizável + tático + sem valor durável + escala linear com tráfego/team**.
+
+**Loop fechado canônico:**
+
+```text
+/auditar-marco
+  ↓
+Step A: invoca /auditar-toil   ← gera .planning/TOIL-AUDIT.md (este patch — INT-FW-V2-03)
+  ↓
+Step B: invoca /auditar-observabilidade   ← OMM scoring v1.9 (INT-FW-04)
+  ↓
+omm-auditor consulta .planning/TOIL-AUDIT.md   ← Capacidade 3 — Complexidade / Tech Debt (Phase 39 INT-OBS-02)
+  ↓
+OMM-REPORT.md inclui Capacidade 3 score derivado de % toil pelo time
+  ↓
+MILESTONE-AUDIT.md inclui OMM-REPORT.md + TOIL-AUDIT.md como anexos
+```
+
+**Por que rodar `/auditar-toil` ANTES de `/auditar-observabilidade`:**
+
+O agent `omm-auditor` (Capacidade 3 patcheada em Phase 39 / INT-OBS-02) tem regra absoluta:
+
+> "score Capacidade 3 > 3 exige TOIL-AUDIT.md fresco ≤ 30 dias com `% toil < 30%`"
+
+Se TOIL-AUDIT.md ausente ou stale (> 30d), `omm-auditor` delega geração via `Task(subagent_type=toil-auditor)` ad-hoc — duplicação. Auto-invocar `/auditar-toil` em `/auditar-marco` evita essa duplicação ao garantir que `omm-auditor` encontre TOIL-AUDIT.md fresco.
+
+**Tabela de score Capacidade 3 (consumida por omm-auditor):**
+
+| % toil pelo time | OMM Capacidade 3 score | Implicação |
+|---|---|---|
+| < 15% | 5 | Excelente — automação madura |
+| 15-30% | 4 | Bom — abaixo regra ≤ 50% cap 5 com folga |
+| 30-50% | 3 | Aceitável — no limite (regra ≤ 50%) |
+| 50-60% | 2 | Risco — acima limite cap 5; team queimando ciclos em toil |
+| > 60% | 1 | Crítico — toil-driven team; scaling linear vai quebrar |
+
+Cross-ref ativo: tabela acima é replicada em [omm-auditor](../agents/omm-auditor.md) (Step 1 — patcheado em Phase 39 / INT-OBS-02).
+
+**Output esperado:**
+
+`.planning/TOIL-AUDIT.md` contém:
+
+1. % toil pelo time (estimado a partir de git log + scripts shell + runbooks manuais documentados)
+2. Lista de candidatos a automação P0/P1/P2 com:
+   - Comando/processo manual identificado
+   - Frequência (× por sprint/mês)
+   - Esforço estimado de automação (S/M/L)
+   - ROI = Frequência × Tempo Manual / Esforço Automação
+3. Sugestões de automação concretas (pg_cron job, hook PostToolUse, kit-mcp command, GitHub Action)
+4. Anti-toil-by-design: action items para `/discutir-fase` capturar toil prevenção upfront em fases futuras
+
+**Quando desligar gate:**
+
+- Solo developer side project (toil = você mesmo, audit é overhead)
+- Projeto ≤ 30 dias (sem volume git suficiente para detectar padrões repetitivos)
+- Repo somente bibliotecário sem ops (kit-mcp content-only sem deploy)
+
+Para esses casos: `workflow.audit_milestone_toil = false`. Para projetos team-based com ops/deploy, **manter `true`**.
+
+**Skill consultada:** [eliminating-toil](../skills/eliminating-toil/SKILL.md) (cap 5 livro Google SRE — *Eliminating Toil* — define toil canonicamente, regra ≤ 50%, padrões de automação, distinção toil vs overhead vs grungy work).
+
+**Anti-patterns prevenidos:**
+
+- "Skipar audit toil porque está OK há tempo" → trabalho cresce, toil cresce com ele; audit obrigatório por milestone
+- "TOIL-AUDIT.md gerado mas ignorado" → omm-auditor Capacidade 3 consome o arquivo; ignorar o relatório = score Cap 3 deteriora visivelmente
+- "Toil = features pequenas" → toil é manual + repetitivo + automatizável (ortogonal a tamanho); 5min × 50× por sprint = 4h por sprint
+- "Toil ≠ overhead" → overhead inclui meetings, planning, code review (necessário, não automatizável); toil é só o automatizable
+
+**REQ:** INT-FW-V2-03.
+</sre_integration>
+
+<legacy_refactor_integration>
+**Legacy refactor safety audit (opt-in):**
+
+Quando `workflow.audit_milestone_legacy_refactor = true` (default: false em projetos < 50% OMM maturity, true acima), o workflow inclui passo de auditoria de refactor safety:
+
+```text
+Para cada arquivo modificado por tasks com kind=refactor no milestone:
+  Task(
+    subagent_type="refactor-safety-auditor",
+    prompt="
+target_file: <file>
+change_kind: refactor
+mode: blocking
+output_path: .planning/REFACTOR-SAFETY-<file_stem>.md
+
+Aplicar skill pre-refactor-characterization. Validar retroativamente que safety net foi aplicado.
+"
+  )
+```
+
+**Critérios de aprovação:**
+- Cada refactor de risco no milestone tem characterization tests linkados E pass verde
+- Cada `--mode=override` tem ticket linkado válido (ainda aberto OR resolvido com follow-up)
+- Mutation kill score ≥ 70% nos arquivos refatorados (warning se line cov OK mas mutation baixo)
+
+**Resultado de regression:**
+- 0 refactors sem char → audit aprovado
+- 1+ refactors sem char e sem override → audit fail; bloqueia close de milestone até resolução
+- 1+ overrides com tickets ainda abertos > 90 dias → warning explícito (débito técnico envelhecido)
+
+Skill canônica: [`pre-refactor-characterization`](../skills/pre-refactor-characterization/SKILL.md)
+Cross-ref ativo: `omm-auditor` Capacidade 1 (Resilience) score consulta REFACTOR-SAFETY summaries para fator "% refactors com safety net"; baixa adequação reduz score.
+
+**Quando desligar gate:**
+- Projeto greenfield com < 3 meses de idade (legacy code não existe ainda)
+- Solo dev side project sem stakes de produção (audit é overhead)
+- Toda codebase é < 50% código não-trivial (a maior parte é config/markdown/tests)
+
+Para esses casos: `workflow.audit_milestone_legacy_refactor = false`. Para projetos com stakes de produção e equipe ≥ 2 pessoas, **manter `true`**.
+
+**REQ:** INT-LEGACY-FW-01.
+</legacy_refactor_integration>