up-cc 0.16.1 → 2.0.1

package/up/workflows/build.md

@@ -1,19 +1,40 @@
 <purpose>
 Workflow `/up:build` — Execucao de projeto previamente planejado.
 
-Requer `.plano/PLAN-READY.md` (gerado por `/up:plan`).
+Requer `.plano/PLAN-READY.md` (gerado por `/up:plan`). Conduz Build (loop por fase) + Quality Gate
+global + Delivery. Pode executar projeto planejado em outro runtime — confia no PLAN-READY.md.
 
-Conduz Estagios 3 (Build) + 4 (Quality Gate) + 4.5 (Delivery Audit) + 5 (Delivery).
-
-Pode executar projeto planejado em outro runtime — confia no PLAN-READY.md.
+Este e o MOTOR UNICO de execucao do redesign v2. Absorveu executar-fase.md, executar-plano.md e a
+parte de execucao do modo-builder (builder.md, que foi deletado).
 </purpose>
 
+<migrado_de_builder>
+O antigo builder.md (3416 linhas) foi deletado. Capacidades reais migradas para ca (ou pro up.md/plan.md),
+SEM trazer governanca hierarquica/supervisores/CEO:
+
+- **Intake autonomo de projeto + pesquisa inline de stack:** migrado para `workflows/up.md` (Passo 2,
+  classify-task escala o brainstorm; greenfield spawna 4x up-pesquisador; modo light = mini-scan inline).
+  `/up:build` assume que isso ja rodou e que existe PLAN-READY.md.
+- **Crash recovery via LOCK.md:** preservado aqui (Estagio 0.3).
+- **Routing por tipo de plano (frontend/backend/database/misto):** preservado (Estagio 3.2), AGORA via
+  CONTEXTO no `up-executor` (carrega skill/ref de dominio sob demanda), sem agentes specialist separados.
+- **Pre-inline de contexto via `up-tools.cjs context`:** preservado (Estagio 3.3), economiza tokens por spawn.
+- **Verification ladder deterministica (verify-static antes do verificador-LLM):** preservada (Estagio 3.6).
+- **E2E + DCRV por fase:** delega a `@~/.claude/up/workflows/dcrv.md` (que absorveu builder-e2e.md).
+- **Modo light (pipeline enxuto):** o conceito de "feature pequena = menos cerimonia" agora e decidido
+  upstream pelo classify-task (em up.md). Aqui o pipeline e o mesmo; o cap de rework e 1 round.
+
+NAO migrado (morto de proposito): CEO/chiefs/supervisores, governanca hierarquica, re-plans com 2 niveis
+de aprovacao LLM, updates periodicos ao dono.
+</migrado_de_builder>
+
 <core_principle>
-Este workflow assume que o projeto foi completamente planejado por `/up:plan`.
+Pipeline final por fase (redesign v2):
 
-Diferenca do builder:
-- Builder: planeja + executa em sequencia, no mesmo runtime
-- Build: SO executa, le PLAN-READY.md gerado anteriormente (mesmo runtime ou outro)
+```
+[up-planejador (replan LOCAL, so se preciso)] -> up-executor (roteia por contexto) -> up-verificador
+  -> [GATE approvals.log] -> up-revisor -> marcar completa
+```
 
 **Model routing configuravel (v0.9.0+):**
 Antes de spawnar qualquer agente, resolver o modelo:
@@ -21,41 +42,41 @@ Antes de spawnar qualquer agente, resolver o modelo:
 MODEL=$(node "$HOME/.claude/up/bin/up-tools.cjs" config resolve-model {agent-name} --raw)
 ```
 Se `default`: nao passar `model=`. Se `opus/sonnet/haiku`: passar `model="{MODEL}"` no spawn.
-Isso permite que o usuario configure via `/up:configurar` quais agentes usam qual modelo.
-Sem configuracao, todos usam o modelo do runtime (comportamento v0.6.0).
 
 **Re-plan local permitido (max 2):**
-Se durante execucao o execution-supervisor detectar que um plano esta inviavel,
-ele pode pedir REQUEST_REPLAN. O planejador local refaz o plano daquela fase.
-NUNCA volta pro runtime que planejou originalmente.
-
-**REGRA ANTI-COLAPSO — SEPARACAO RIGIDA DE AGENTES:**
-
-O LLM tende a otimizar colapsando passos — dar ao mesmo agente tarefas de executar + verificar,
-ou pular supervisores por parecer "overhead". Isso e PROIBIDO.
-
-**Cada passo do Stage 3 DEVE ser um Agent() SEPARADO.**
-**NUNCA combinar dois passos em um unico spawn.**
-**NUNCA instruir um agente a fazer o trabalho de outro.**
-
-Exemplo do que NAO fazer:
-```
-# ERRADO — combina execucao + verificacao
-Agent(subagent_type="up-executor", prompt="Executar E verificar a fase...")
-
-# ERRADO — pula supervisor
-# (executar e marcar completa sem passar por execution-supervisor)
-```
-
-**Mecanismo de enforcement: GATES verificaveis.**
-Cada supervisor DEVE escrever no `.plano/governance/approvals.log`.
-Cada GATE verifica que o log tem a entry esperada.
-Se o gate falha, NAO avance — spawne o agente faltante.
-
-**Pipeline obrigatorio por fase:**
-```
-Specialist → [GATE A] → EXECUTION-SUPERVISOR → [GATE B] → Verificador → [GATE C] → VERIFICATION-SUPERVISOR → [GATE D] → E2E + DCRV → CHIEF-ENGINEER → [GATE E] → Marcar completa
-```
+Se durante a execucao ficar claro que um plano e inviavel, o orquestrador pode re-planejar a fase
+LOCALMENTE via `up-planejador` (self-check). NUNCA volta pro runtime que planejou originalmente.
+
+**SEPARACAO RIGIDA DE AGENTES:**
+O LLM tende a colapsar passos (mesmo agente executa + verifica). Isso e PROIBIDO. Cada passo do Stage 3
+e um `Agent()` SEPARADO. O enforcement e o GATE deterministico do `approvals.log`
+(ver `@~/.claude/up/workflows/governance.md`), nao uma piramide de supervisores.
+
+**GitHub-nativo e o DEFAULT (v2):**
+- **PADRAO (sem flag):** cada fase abre uma worktree + branch `up/fase-NN-slug` e (se houver `gh` + remote)
+  uma issue do GitHub; no fim da fase, se a fase tem UI, **sobe o dev server e PEDE aprovacao visual antes de
+  mergear** (3.8.0), depois fecha (merge local / PR / deixa / descarta). Isto e o caminho quente.
+  Controlado por `config.github_native=true` (default).
+- `--solo`: ESCAPE HATCH sem cerimonia. Forca `github_native=false` SO nesta execucao. Commit atomico na
+  branch ATUAL. Zero worktree, zero issue, zero PR, zero rede. (Mesmo comportamento de `/up:rapido`.)
+- **Teste visual antes do merge (`require_visual_test`, default true):** fase de UI sobe dev server e exige
+  o dono aprovar na tela ANTES do merge (3.8.0). Projeto em PRODUCAO: deixe ligado (nada sobe sem voce ver).
+- `--auto`: pula o MENU de fechamento. Apos o GATE aprovar, `finish-phase --mode auto` (PR -> merge squash ->
+  cleanup). MAS o teste visual (3.8.0) ainda roda se `require_visual_test=true` (so `false` deixa o --auto
+  mergear UI sem aprovacao). So faz sentido com github_native ligado.
+- `--board`: espelha status no Multica (espelho de board OPT-IN, BATCHED no fim da onda/fase). NAO ha
+  stream ao vivo no fluxo local: o board mostra so o status (`todo -> in_progress -> in_review -> done /
+  blocked`), nunca cada tool_use. Chamadas via `up-tools.cjs multica {init|sync|board}` (que usa
+  `multica.cjs`, deteccao `uname -s` Mac->`ssh server-ecoup`, FAIL-OPEN: se `multica` indisponivel, avisa
+  e segue sem board, nunca crasha). So roda quando `--board` ligado.
+
+**FAIL-OPEN universal:** `start-phase`/`finish-phase` detectam `gh` + remote. Faltando qualquer um, degradam
+para git local (worktree local + merge local; issue/PR = null) com aviso, NUNCA crasham. `git worktree` e
+sempre local e funciona offline. Com `--solo` nao ha nem worktree (commit direto na branch atual).
+
+**Onde o estado vive:** `git-map.json` e canonico no working dir PRINCIPAL (`.plano/git-map.json`). O `.plano/`
+de cada fase viaja na branch da fase (worktree) e volta pra main no merge. STATE.md permanece a fonte humana
+de "onde estou"; git-map.json e o indice maquina de "onde esta cada fase no GitHub".
 </core_principle>
 
 <process>
@@ -66,21 +87,19 @@ Specialist → [GATE A] → EXECUTION-SUPERVISOR → [GATE B] → Verificador
 
 ```bash
 if [ ! -f ~/.claude/up/owner-profile.md ]; then
-  echo "Owner profile nao existe NESTE runtime. Rodando /up:onboard..."
-  # Delegar pro workflow onboarding.md
+  echo "Owner profile nao existe NESTE runtime. Rodando onboarding..."
+  # Delegar pro workflow @~/.claude/up/workflows/onboarding.md
 fi
 ```
 
-**IMPORTANTE:** O profile e do RUNTIME ATUAL, nao do runtime que planejou. Cada runtime tem seu profile.
+O profile e do RUNTIME ATUAL, nao do runtime que planejou.
 
 ### 0.2 PLAN-READY.md Existe?
 
 ```bash
 if [ ! -f .plano/PLAN-READY.md ]; then
   echo "ERRO: Este projeto nao foi planejado."
-  echo ""
-  echo "Use /up:plan primeiro pra planejar o projeto."
-  echo "Ou /up:modo-builder pra planejar e executar de uma vez."
+  echo "Use /up:plan primeiro. Ou /up \"descricao\" -> /up:plan -> /up:build."
   exit 1
 fi
 ```
@@ -91,7 +110,8 @@ fi
 ls .plano/LOCK.md 2>/dev/null
 ```
 
-Se LOCK.md existe e `stage: build`: retomar.
+Se LOCK.md existe e `stage: build`: retomar do passo/fase correto (pular o que ja tem SUMMARY/VERIFICATION).
+Se `status: completed`: deletar LOCK.md e iniciar normalmente.
 
 ## Estagio V: VALIDACAO LIGHT
 
@@ -100,7 +120,6 @@ Se LOCK.md existe e `stage: build`: retomar.
 ### V.1 Parsear PLAN-READY.md
 
 ```bash
-# Extrair frontmatter
 PLANNED_RUNTIME=$(grep "runtime:" .plano/PLAN-READY.md | head -1 | awk '{print $2}')
 INTENDED_RUNTIME=$(grep -A1 "intended_execution:" .plano/PLAN-READY.md | tail -1 | awk '{print $2}')
 TOTAL_PHASES=$(grep "total_phases:" .plano/PLAN-READY.md | awk '{print $2}')
@@ -110,15 +129,13 @@ CONFIDENCE=$(grep "planning_confidence:" .plano/PLAN-READY.md | awk '{print $2}'
 ### V.2 Validacao de Compatibilidade
 
 ```bash
-CURRENT_RUNTIME="claude-code"  # detectar
+CURRENT_RUNTIME="claude-code"
 [ -d ~/.config/opencode ] && CURRENT_RUNTIME="opencode"
 [ -d ~/.gemini ] && CURRENT_RUNTIME="gemini-cli"
 
-# Se intended_execution especifica um runtime e nao e o atual, alertar
 if [ "$INTENDED_RUNTIME" != "same" ] && [ "$INTENDED_RUNTIME" != "any" ] && [ "$INTENDED_RUNTIME" != "$CURRENT_RUNTIME" ]; then
-  echo "AVISO: Plano gerado pra $INTENDED_RUNTIME, voce esta em $CURRENT_RUNTIME"
-  echo "Pode haver incompatibilidades. Continuar mesmo assim?"
-  # AskUserQuestion sim/nao
+  echo "AVISO: Plano gerado pra $INTENDED_RUNTIME, voce esta em $CURRENT_RUNTIME. Continuar?"
+  # AskUserQuestion sim/nao (output direto, sem CEO)
 fi
 ```
 
@@ -133,141 +150,229 @@ fi
 
 ### V.4 Validar Planos Listados
 
-Pra cada plano listado em PLAN-READY.md, checar se arquivo existe:
-
 ```bash
-# Extrair lista de planos do PLAN-READY.md
 PLANS=$(grep -oE "fases/[0-9]+-[a-z-]+/[0-9]+-[0-9]+-PLAN.md" .plano/PLAN-READY.md)
-
 for plan in $PLANS; do
-  if [ ! -f ".plano/$plan" ]; then
-    echo "FALTANDO: $plan"
-    FAIL=1
-  fi
+  [ ! -f ".plano/$plan" ] && echo "FALTANDO: $plan" && FAIL=1
 done
 ```
 
 ### V.5 Decidir
 
-**Se todos arquivos OK:** prosseguir.
+**Tudo OK:** prosseguir. **Falta algo:** alertar o dono (AskUserQuestion), oferecer re-planejar
+localmente (`/up:plan`) ou abortar.
 
-**Se algo falta:** 
-- Alertar usuario
-- Oferecer: "Posso planejar localmente?" (re-roda /up:plan)
-- Ou abortar
+## Estagio C: CONFIRMACAO DO DONO (orquestrador, sem CEO)
 
-## Estagio C: CEO CONFIRMA
+Output direto do orquestrador (le owner-profile pra tom):
 
-Spawnar CEO local:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ UP > BUILD
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-```python
-Agent(
-  subagent_type="up-project-ceo",
-  prompt="""
-    Confirmar execucao de projeto previamente planejado.
-    
-    <files_to_read>
-    - ~/.claude/up/owner-profile.md (perfil LOCAL deste runtime)
-    - .plano/BRIEFING.md (briefing original)
-    - .plano/PLAN-READY.md (resumo do planejamento)
-    - .plano/AUDIT-PLAN.md (audit do planejamento)
-    - .plano/PENDING.md
-    </files_to_read>
-    
-    Apresentar ao dono:
-    - "Detectei projeto planejado em {runtime} por {ceo_name_anterior}"
-    - Resumo: N fases, M planos
-    - Planning confidence: X/100
-    - Pendencias conhecidas
-    - "Iniciar execucao? (enter pra continuar)"
-    
-    Se dono confirmar: prosseguir.
-    Se recusar: abortar.
-  """
-)
+Projeto planejado em {runtime}.
+Resumo: {N} fases, {M} planos. Planning confidence: {X}/100.
+Pendencias conhecidas: {de PENDING.md}.
+
+Modo git: {GITHUB_MODE}   (GitHub-nativo e o default; --solo desliga; --auto pula o menu)
+```
+
+Resolver `GITHUB_MODE` antes do banner:
+
+```bash
+# --solo forca github_native=false SO nesta execucao
+if [ "$SOLO" = "true" ]; then
+  GITHUB_NATIVE=false
+else
+  GITHUB_NATIVE=$(node "$HOME/.claude/up/bin/up-tools.cjs" config get github_native --raw 2>/dev/null)
+  [ -z "$GITHUB_NATIVE" ] && GITHUB_NATIVE=true   # default TRUE
+fi
+
+if [ "$GITHUB_NATIVE" = "true" ]; then
+  GITHUB_MODE="GitHub-nativo (worktree + issue + PR/menu por fase)"
+  [ "$AUTO" = "true" ] && GITHUB_MODE="GitHub-nativo --auto (PR + merge squash automatico)"
+else
+  GITHUB_MODE="--solo (commit atomico na branch atual, sem worktree/issue/PR)"
+fi
+
+# --board liga o espelho Multica (OPT-IN). So tem efeito se passado explicitamente.
+BOARD=false
+[ "$BOARD_FLAG" = "true" ] && BOARD=true
+[ "$BOARD" = "true" ] && GITHUB_MODE="$GITHUB_MODE + Multica board (espelho de status, batched, fail-open)"
 ```
 
-## Estagio 3: BUILD (loop por fase — com GATES verificaveis)
+Confirmar via AskUserQuestion ("Iniciar execucao?"). Se recusar: abortar.
+
+## Estagio 3: BUILD (loop por fase — com GATE deterministico)
 
-**Inicializar governance:**
+**Inicializar governance** (ver `@~/.claude/up/workflows/governance.md`):
 ```bash
 mkdir -p .plano/governance
 touch .plano/governance/approvals.log
-echo "# Build governance initialized at $(date -u +%Y-%m-%dT%H:%M:%SZ)" >> .plano/governance/approvals.log
+[ -s .plano/governance/approvals.log ] || \
+  echo "# Build governance initialized at $(date -u +%Y-%m-%dT%H:%M:%SZ)" >> .plano/governance/approvals.log
+```
+
+**Inicializar board no Multica (so se `--board`, UMA vez no inicio do projeto):**
+`multica init` garante o `project` no Multica + a issue-pai (e as issues-filhas por fase, se `/up:plan`
+ja as criou) e grava `metadata up_project=<repo>`. FAIL-OPEN: se `multica` indisponivel ou der erro,
+avisa e segue sem board (nunca crasha o build). Deteccao `uname -s` fica dentro de `multica.cjs`.
+
+```bash
+if [ "$BOARD" = "true" ]; then
+  # init = ensureProject + issue-pai (idempotente; reconcilia via metadata up_project).
+  MULTICA_INIT=$(node "$HOME/.claude/up/bin/up-tools.cjs" multica init --raw 2>/dev/null) \
+    || echo "AVISO: Multica indisponivel (init). Seguindo sem board."
+fi
 ```
 
 Para cada fase em ROADMAP.md (em ordem):
 
-### 3.1 Carregar Plano da Fase
+### 3.0 Abrir a fase (GitHub-nativo - DEFAULT)
+
+A menos que `--solo` (ou `github_native=false`), abrir worktree + branch + issue ANTES de executar a fase.
+
+```bash
+PHASE_SLUG=$(node "$HOME/.claude/up/bin/up-tools.cjs" slug "{phase_name}" --raw)
+
+if [ "$GITHUB_NATIVE" = "true" ]; then
+  # Cria worktree + branch up/fase-NN-slug; se gh+remote, cria issue. Escreve .plano/git-map.json.
+  # Fail-open: sem gh/remote -> worktree local, issue=null, aviso (nunca crasha).
+  START=$(node "$HOME/.claude/up/bin/up-tools.cjs" github start-phase \
+    --phase {phase_number} --slug "$PHASE_SLUG" --raw)
+  if [[ "$START" == @file:* ]]; then START=$(cat "${START#@file:}"); fi
+  WORKTREE=$(echo "$START" | grep -oE '"worktree"[^,}]*' | sed 's/.*: *"//;s/"//')
+  BRANCH=$(echo "$START"   | grep -oE '"branch"[^,}]*'   | sed 's/.*: *"//;s/"//')
+  ISSUE=$(echo "$START"    | grep -oE '"issue"[^,}]*'    | sed 's/.*: *//')
+  echo "Fase {phase_number}: branch=$BRANCH worktree=$WORKTREE issue=${ISSUE:-null}"
+else
+  # --solo: sem worktree/issue. Trabalho acontece na branch atual.
+  WORKTREE="$(pwd)"; BRANCH="$(git rev-parse --abbrev-ref HEAD 2>/dev/null)"; ISSUE=""
+fi
+```
+
+**Entrar na worktree (so se github_native):** o trabalho da fase (executor, commits) acontece
+DENTRO de `$WORKTREE`. Preferir a tool nativa do harness **EnterWorktree** apontando para `$WORKTREE`; se
+indisponivel, a worktree ja foi criada por `start-phase` (basta usar `--cwd "$WORKTREE"` nos comandos
+`up-tools.cjs` e `cd "$WORKTREE"` antes de `git add/commit`). O `.plano/` da fase viaja na branch da fase;
+`git-map.json` permanece canonico no working dir principal. Ao terminar a fase usar **ExitWorktree** (ou
+voltar `cd` para o repo principal) antes de atualizar `git-map.json` na main.
+
+> Em `--solo`, IGNORAR EnterWorktree/ExitWorktree: tudo na branch atual.
+
+**Multica: marcar a fase em execucao (so se `--board`, 1 chamada na ENTRADA da fase).**
+Uma transicao por fase (nao por microtransicao): status `in_progress` + metadata `gh_issue`/`branch`.
+FAIL-OPEN: erro ou `multica` indisponivel -> avisa e segue.
+
+```bash
+if [ "$BOARD" = "true" ]; then
+  node "$HOME/.claude/up/bin/up-tools.cjs" multica sync \
+    --phase {phase_number} --status in_progress \
+    --gh-issue "${ISSUE:-}" --branch "${BRANCH:-}" --raw 2>/dev/null \
+    || echo "AVISO: Multica indisponivel (sync in_progress fase {phase_number}). Seguindo."
+fi
+```
+
+### 3.1 Descobrir planos + waves da fase (MULTI-PLANO)
+
+Uma fase tem N planos agrupados em WAVES. O motor de waves vive em `up-tools.cjs`; aqui so o consumimos.
+NAO existe mais "1 plano por fase" (era a regressao do `head -1`): descobrimos TODOS os planos e o
+agrupamento por wave do disco.
+
+Os planos vivem DENTRO de `$WORKTREE` (a `.plano/` da fase viaja na branch da fase). Por isso TODA chamada
+de descoberta usa `--cwd "$WORKTREE"` (em `--solo`, `$WORKTREE` = repo principal, entao funciona igual).
 
 ```bash
-PHASE_DIR=$(ls -d .plano/fases/{phase_number}-* 2>/dev/null)
-PLAN=$(ls "$PHASE_DIR"/*-PLAN.md | head -1)
+# (a) Metadados da fase + flag de paralelizacao (config). Trata @file: (saida > 50KB).
+INIT=$(node "$HOME/.claude/up/bin/up-tools.cjs" init executar-fase {phase_number} --cwd "$WORKTREE" --raw)
+if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
+# init executar-fase retorna: phase_found, phase_dir, phase_number, phase_name, phase_slug,
+# plans[] (nomes de arquivo), incomplete_plans[], plan_count, incomplete_count, paralelizacao, commit_docs.
+PHASE_DIR="$WORKTREE/$(echo "$INIT" | grep -oE '"phase_dir"[^,}]*' | sed 's/.*: *"//;s/"//')"
+PARALLELIZATION=$(echo "$INIT" | grep -oE '"paralelizacao"[^,}]*' | grep -oE '(true|false)')
+PLAN_COUNT=$(echo "$INIT" | grep -oE '"plan_count"[^,}]*' | grep -oE '[0-9]+')
+[ -z "$PARALLELIZATION" ] && PARALLELIZATION=true
+[ "$PLAN_COUNT" = "0" ] && echo "GATE A FALHOU: sem planos na Fase {phase_number}." && exit 1
+
+# (b) Inventario com agrupamento por WAVE (este e o motor de waves real).
+PLAN_INDEX=$(node "$HOME/.claude/up/bin/up-tools.cjs" phase-plan-index {phase_number} --cwd "$WORKTREE" --raw)
+if [[ "$PLAN_INDEX" == @file:* ]]; then PLAN_INDEX=$(cat "${PLAN_INDEX#@file:}"); fi
+# phase-plan-index retorna: phase, plans[] (cada: id, wave [int], autonomous [bool], objective,
+# files_modified[], task_count, has_summary [bool]), waves (map wave->[ids]), incomplete[], has_checkpoints.
 ```
 
-### 3.2 Detectar Tipo de Plano (Specialist Routing)
+Parsear de `$PLAN_INDEX`: a lista `plans[]` e o mapa `waves` (chave = numero da wave, valor = ids dos
+planos daquela wave). Ordenar as waves por numero CRESCENTE. Para resolver o arquivo de um plano a partir
+do id: `PLAN="$PHASE_DIR/${id}-PLAN.md"` (fallback `"$PHASE_DIR/PLAN.md"` se id vazio).
+
+> Por que paralelizar dentro da wave e SEGURO: o agrupamento por wave ja garante que os planos da MESMA
+> wave sao INDEPENDENTES entre si (arquivos disjuntos, sem dependencia mutua). Qualquer plano que dependa
+> de outro cai numa wave POSTERIOR. Entao rodar todos os planos de uma wave em paralelo nunca causa
+> conflito de escrita. Waves rodam SEMPRE em ordem (a wave N+1 so comeca quando a wave N inteira termina).
+
+### 3.2 + 3.3 LOOP DE WAVES: detectar tipo (por plano) + spawnar executor(es)
 
-Ler o frontmatter do plano pra determinar qual specialist usar:
-- Frontend tasks → up-frontend-specialist
-- Backend tasks → up-backend-specialist
-- Database tasks → up-database-specialist
-- Misto → up-executor
+Iterar as waves em ordem crescente. Para CADA wave:
 
-### 3.3 Spawnar Specialist (PASSO 1 — Agent SEPARADO)
+1. **Selecionar os planos da wave que ainda NAO tem SUMMARY** (resume): pular todo plano com
+   `has_summary: true` no `$PLAN_INDEX` (idempotencia/retomada). Se a wave inteira ja esta concluida,
+   anuncia e pula pra proxima wave.
 
-**Wave 2 (v0.11+) — pre-inline context:**
-ANTES do spawn, montar contexto via `up-tools.cjs context`. Isso injeta
-PLAN, STATE, config, governance comprimida, engineering principles,
-requirements-slice direto no prompt. O agente NAO refaz Read desses
-arquivos. Economiza ~30k tokens por spawn.
+2. **Para CADA plano selecionado da wave, montar contexto e detectar tipo (PRE-spawn, por plano):**
 
 ```bash
-SPECIALIST_AGENT="up-executor"  # ou specialist baseado em type do plano
+# Roda UMA VEZ por plano da wave (PLAN = $PHASE_DIR/<id>-PLAN.md).
+EXECUTOR_AGENT="up-executor"   # SEMPRE up-executor (Onda 2: sem specialists separados)
 
-# Wave 6+ — manifest filtra refs por papel
+# 3.2 (por plano): tipo apenas informa o executor qual dominio carregar; o agente nao muda.
+PLAN_TYPE=$(grep -oE '^type:[[:space:]]*[a-z-]+' "$PLAN" | head -1 | sed 's/type:[[:space:]]*//')
+EXECUTOR_DOMAIN="$PLAN_TYPE"   # frontend|backend|database|misto (vazio = misto)
+
+# Pre-inline de contexto (economiza ~30k tokens/spawn), por plano:
 CTX=$(node "$HOME/.claude/up/bin/up-tools.cjs" context \
   --plan "${PLAN}" \
   --state \
   --config \
   --requirements "${PHASE_NUMBER}" \
-  --manifest "${SPECIALIST_AGENT}" \
-  --raw)
+  --manifest "${EXECUTOR_AGENT}" \
+  --cwd "$WORKTREE" --raw)
 
-# Wave 5+ — complexity-aware model routing per plan
 MODEL=$(node "$HOME/.claude/up/bin/up-tools.cjs" resolve-model-for-plan \
-  "${PLAN}" "${SPECIALIST_AGENT}" --raw)
-CLASSIFY=$(node "$HOME/.claude/up/bin/up-tools.cjs" classify-task "${PLAN}" --raw)
-COMPLEXITY=$(echo "$CLASSIFY" | grep -oE '"complexity"[^,]+' | grep -oE '"(simple|standard|complex)"' | tr -d '"')
-SCORE=$(echo "$CLASSIFY" | grep -oE '"score"\s*:\s*[0-9]+' | grep -oE '[0-9]+')
-
-# Wave 6+ — Iron rule: validar plan
-VALIDATE=$(node "$HOME/.claude/up/bin/up-tools.cjs" validate-plan "${PLAN}" --raw)
-VALIDATE_PASS=$(echo "$VALIDATE" | grep -oE '"pass"\s*:\s*(true|false)' | grep -oE '(true|false)')
-if [ "$VALIDATE_PASS" = "false" ]; then
-  echo "IRON RULE FALHOU: Plan ${PLAN} excede limites. Voltando pro planejador."
-  echo "$VALIDATE" | grep -A 20 'suggestions'
-  exit 1
-fi
-
-node "$HOME/.claude/up/bin/up-tools.cjs" routing-log \
-  --plan "${PLAN}" --agent "${SPECIALIST_AGENT}" --model "${MODEL}" \
-  --complexity "${COMPLEXITY}" --score "${SCORE}" --outcome pending
+  "${PLAN}" "${EXECUTOR_AGENT}" --cwd "$WORKTREE" --raw)
 ```
 
+3. **Spawnar o(s) executor(es) da wave:**
+   - **Se `PARALLELIZATION=true`:** spawnar TODOS os executores da wave EM PARALELO (multiplos `Agent()`
+     numa UNICA mensagem do orquestrador, um por plano selecionado da wave).
+   - **Se `PARALLELIZATION=false`:** spawnar os executores da wave um por vez (sequencial), esperando cada
+     um antes do proximo.
+
+   O prompt de cada `Agent` e o bloco abaixo, parametrizado POR PLANO (`{PLAN}`, `{EXECUTOR_DOMAIN}`,
+   `{CTX}` daquele plano). Um executor = um plano.
+
 ```python
 Agent(
-  subagent_type="{up-specialist}",
+  subagent_type="up-executor",
   prompt=f"""
-    Executar Plano da Fase {phase_number}.
-    
+    Executar o Plano {PLAN} (Fase {phase_number}, wave {wave}).
+
+    Tipo do plano (dominio a carregar por contexto): {EXECUTOR_DOMAIN}
+    Roteie POR CONTEXTO conforme o tipo: frontend -> carregar skill/ref de UI/CSS e DESIGN-TOKENS;
+    backend -> ref de API/server; database -> ref de schema/migrations; misto -> conforme cada tarefa.
+    NAO existem agentes specialist separados: voce e o unico executor e adapta ao dominio.
+
+    Escopo: SOMENTE este plano. Outros planos da mesma wave rodam em paralelo em arquivos disjuntos;
+    NAO toque em arquivos fora dos <files> das tarefas DESTE plano.
+
     <prompt_context>
     {CTX}
     </prompt_context>
-    
+
     <production_requirements_compressed>
-    Categorias a respeitar (71 requisitos no total):
-    - UIST (UI States): loading/error/empty/success em TODA operacao async
-    - ERR (Error handling): boundaries, try/catch, sessao expirada, 404
+    Categorias a respeitar (71 requisitos):
+    - UIST: loading/error/empty/success em TODA operacao async
+    - ERR: boundaries, try/catch, sessao expirada, 404
     - PERF: lazy loading, code split, debounce, pagination > 20 items, cache
     - FORM: validacao inline, mensagens especificas, autofocus, mascaras
     - RESP: 375px funcional, touch 44x44, hamburger mobile
@@ -275,175 +380,102 @@ Agent(
     - SEC: rotas protegidas, CSRF, XSS, rate limit, env vars, RLS
     - POLISH: hover, transicoes 150-300ms, design tokens
     </production_requirements_compressed>
-    
+
     <files_to_read>
-    O contexto principal ja esta no <prompt_context> acima. Ler do disco APENAS:
+    O contexto principal ja esta no <prompt_context>. Ler do disco APENAS:
     - ./CLAUDE.md (se existir)
-    - .plano/fases/{phase_number}/PHASE.md (se existir, complemento curto)
+    - .plano/fases/{phase_number}/PHASE.md (se existir)
     - .plano/DESIGN-TOKENS.md (so se frontend e existir)
-    - Arquivos referenciados em <files> das tarefas (codigo a editar)
-    
-    TIER 3 — Sob demanda apenas:
-    - .plano/PROJECT.md (so se precisar visao geral)
-    - .plano/SYSTEM-DESIGN.md (so se decisao de arquitetura aparecer)
-    - .plano/REQUIREMENTS.md (so se a slice nao tiver info suficiente)
-    
-    NAO refazer Read em PLAN, STATE.md, config.json, REQUIREMENTS-SLICE.md,
-    engineering-principles — ja estao inline em <prompt_context>.
+    - Arquivos referenciados em <files> das tarefas DESTE plano (codigo a editar)
+
+    Sob demanda apenas: .plano/PROJECT.md, .plano/SYSTEM-DESIGN.md, .plano/REQUIREMENTS.md
+    NAO refazer Read em PLAN/STATE/config/REQUIREMENTS-SLICE/engineering-principles (ja inline).
     </files_to_read>
-    
-    Implementar todas as tarefas. Commitar atomicamente.
-    Gerar SUMMARY.md.
+
+    Implementar todas as tarefas DESTE plano. Se o plano pedir, gerar tambem artefatos de
+    prod/docs/testes inline (papeis de devops/technical-writer/qa absorvidos pelo executor).
+    Commitar atomicamente. Gerar o SUMMARY.md DESTE plano.
   """
 )
 ```
 
-### --- GATE A: Verificar que execucao produziu artefatos ---
-
-```bash
-echo "=== GATE A: Verificando artefatos da execucao (Fase ${PHASE_NUMBER}) ==="
-SUMMARY_COUNT=$(ls ${PHASE_DIR}/*-SUMMARY.md 2>/dev/null | wc -l)
-[ "$SUMMARY_COUNT" -eq 0 ] && echo "GATE A FALHOU: Nenhum SUMMARY.md. Re-executar specialist." && exit 1
-echo "GATE A OK: ${SUMMARY_COUNT} SUMMARY(s)"
-```
+4. **Esperar TODOS os executores da wave terminarem** antes de iniciar a proxima wave (`Agent`/`Task`
+   bloqueia ate retornar; a barreira da wave e o ponto onde se espera todos).
 
-### --- Patch routing outcome (Wave 5+) ---
+5. **--- GATE A (por wave): todos os planos da wave com SUMMARY ---**
 
 ```bash
-if [ "$SUMMARY_COUNT" -gt 0 ]; then
-  OUTCOME=success
-elif echo "$SPAWN_RETURN" | grep -q "^ABORTED:"; then
-  OUTCOME=abort
-else
-  OUTCOME=rework
-fi
-
-node "$HOME/.claude/up/bin/up-tools.cjs" routing-log --update \
-  --plan "${PLAN}" --agent "${SPECIALIST_AGENT}" --model "${MODEL}" \
-  --complexity "${COMPLEXITY}" --score "${SCORE}" \
-  --outcome "${OUTCOME}" --rework-cycles "${REWORK_COUNT:-0}"
+echo "=== GATE A: artefatos da wave ${wave} (Fase ${PHASE_NUMBER}) ==="
+# Espera-se 1 SUMMARY por plano nao-pulado da wave. Conferir cada id da wave:
+WAVE_MISSING=0
+for PLAN_ID in $WAVE_PLAN_IDS; do   # WAVE_PLAN_IDS = ids dos planos selecionados desta wave
+  [ -f "${PHASE_DIR}/${PLAN_ID}-SUMMARY.md" ] || { echo "GATE A: SUMMARY faltando para plano ${PLAN_ID}"; WAVE_MISSING=$((WAVE_MISSING+1)); }
+done
+[ "$WAVE_MISSING" -gt 0 ] && echo "GATE A FALHOU na wave ${wave}: ${WAVE_MISSING} SUMMARY(s) ausente(s). Re-executar o(s) plano(s) faltante(s)." && exit 1
+echo "GATE A OK (wave ${wave})"
 ```
 
-### 3.4 Execution Supervisor Revisa (PASSO 2 — Agent SEPARADO)
+   - Se algum SUMMARY da wave faltar: re-spawnar SO o(s) executor(es) do(s) plano(s) faltante(s) (mesmo
+     bloco `Agent`), depois reavaliar o GATE A da wave. Falha real e sistemica (toda a wave falhou) ->
+     parar e alertar o dono (AskUserQuestion).
 
-```python
-Agent(
-  subagent_type="up-execution-supervisor",
-  prompt=f"""
-    Revisar execucao da Fase {phase_number}.
-    
-    <governance_compressed>
-    DECISOES: APPROVE | REQUEST_CHANGES | REQUEST_REPLAN | ESCALATE
-    REWORK: max 3 ciclos antes de forcar approval com debito
-    NUNCA APROVAR: trabalho nao verificado, evidencia ambigua, claim sem backing,
-                   stub/placeholder, falta de wiring
-    </governance_compressed>
-    
-    <engineering_principles_compressed>
-    1. Implementacao real (zero placeholder)
-    2. Correto, nao rapido
-    3. Conectado ponta a ponta
-    4. Consistencia (seguir patterns existentes)
-    5. Dados reais
-    6. Custo futuro
-    </engineering_principles_compressed>
-    
-    <files_to_read>
-    - {PLAN}
-    - {PHASE_DIR}/*-SUMMARY.md
-    - git diff (use Bash)
-    - .plano/fases/{phase_number}/REQUIREMENTS-SLICE.md (se existir)
-    
-    Sob demanda apenas:
-    - $HOME/.claude/up/references/engineering-principles-compressed.md (exemplos)
-    - $HOME/.claude/up/references/governance-rules-compressed.md (hierarquia)
-    - $HOME/.claude/up/references/rework-limits-compressed.md (fluxos)
-    - $HOME/.claude/up/references/production-requirements-compressed.md (IDs especificos)
-    </files_to_read>
-    
-    Decisao: APPROVE | REQUEST_CHANGES | REQUEST_REPLAN | ESCALATE
-    
-    REQUEST_REPLAN: Se descobrir que o plano e fundamentalmente errado/inviavel.
-                    Max 2 re-plans por projeto.
-    
-    **OUTPUT OBRIGATORIO (fazer ANTES de retornar):**
-    ```bash
-    echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | phase-{phase_number} | execution-supervisor | {{DECISAO}} | {{motivo}}" >> .plano/governance/approvals.log
-    ```
-    Sem este log, o GATE B vai bloquear o avanço.
-  """
-)
-```
+6. **Prosseguir para a proxima wave.** Repetir 1-5 ate a ultima wave.
 
-### --- GATE B: Verificar que execution-supervisor logou ---
+**Fim do loop de waves:** ao sair do loop, TODOS os planos da fase tem SUMMARY. GATE A consolidado:
 
 ```bash
-echo "=== GATE B: Verificando governance da execucao (Fase ${PHASE_NUMBER}) ==="
-EXEC_ENTRY=$(grep "phase-${PHASE_NUMBER}.*execution-supervisor" .plano/governance/approvals.log 2>/dev/null | tail -1)
-[ -z "$EXEC_ENTRY" ] && echo "GATE B FALHOU: execution-supervisor NAO logou. Spawnar agora." && exit 1
-echo "GATE B OK: $EXEC_ENTRY"
+echo "=== GATE A consolidado (Fase ${PHASE_NUMBER}) ==="
+SUMMARY_COUNT=$(ls ${PHASE_DIR}/*-SUMMARY.md 2>/dev/null | wc -l)
+[ "$SUMMARY_COUNT" -lt "$PLAN_COUNT" ] && echo "GATE A FALHOU: ${SUMMARY_COUNT}/${PLAN_COUNT} SUMMARY(s). Re-executar plano(s) faltante(s)." && exit 1
+echo "GATE A OK: ${SUMMARY_COUNT}/${PLAN_COUNT} SUMMARY(s) (todas as waves)"
 ```
 
-### 3.5 Processar Decisao do Supervisor
-
-**Se APPROVE:** prosseguir para verificacao.
+> A partir daqui (3.4-3.9) o escopo e a FASE INTEIRA (todos os planos / todos os SUMMARYs), nao mais
+> "o plano". Roda UMA VEZ por fase, depois de TODAS as waves.
 
-**Se REQUEST_CHANGES:** re-spawn specialist com feedback (max 3 ciclos).
+### 3.4 Re-plan local (so se um plano especifico se revelar inviavel)
 
-**Se REQUEST_REPLAN:**
+Por-plano: se durante a execucao de UM plano especifico ficar evidente que ele e fundamentalmente
+errado/inviavel, o orquestrador re-planeja SO aquele plano, LOCALMENTE (max 2 por projeto). Sem
+supervisor: o `up-planejador` faz self-check. `{PLAN}` aqui = o plano inviavel especifico (nao a fase).
 
 ```bash
 REPLAN_COUNT=$(cat .plano/governance/replans.log 2>/dev/null | wc -l)
 if [ "$REPLAN_COUNT" -ge 2 ]; then
-  echo "Max re-plans atingido. Escalando pro CEO."
-  # ESCALATE
+  echo "Max re-plans atingido. Alertar o dono (AskUserQuestion)."
 else
-  # Re-planejar fase localmente
-  echo "REQUEST_REPLAN aprovado. Re-planejando fase {phase_number} localmente..."
-  
-  # Spawnar planejador LOCAL (Agent SEPARADO)
-  Agent(
-    subagent_type="up-planejador",
-    prompt=f"""
-      RE-PLAN da Fase {phase_number}.
-      
-      Plano original: {PLAN}
-      Razao do re-plan: {execution_supervisor_reason}
-      
-      Refaca o plano corrigindo o problema descoberto.
-    """
-  )
-  
-  # Salvar como -PLAN-v2.md
-  mv "$PLAN" "${PLAN%-PLAN.md}-PLAN-v1.md"
-  
-  # Registrar
-  echo "$(date -u) | phase-{phase_number} | execution-supervisor | REPLAN | reason: {reason}" >> .plano/governance/replans.log
-  
-  # Planning-supervisor revisa novo plano (Agent SEPARADO)
-  Agent(subagent_type="up-planning-supervisor", prompt="""
-    Revisar re-plan da fase {phase_number}.
-    **OUTPUT OBRIGATORIO:** logar em .plano/governance/approvals.log
-  """)
-  
-  # Voltar pro 3.3 (re-spawn specialist)
+  echo "REQUEST_REPLAN. Re-planejando fase {phase_number} localmente..."
 fi
 ```
 
-**Se ESCALATE:** chief-engineer entra.
+```python
+# Re-plan LOCAL — Agent SEPARADO (so up-planejador, sem camada de revisao intermediaria)
+Agent(subagent_type="up-planejador", prompt=f"""
+  RE-PLAN da Fase {phase_number}.
+  Plano original: {PLAN}
+  Razao: {motivo descoberto na execucao}
+  Refaca o plano corrigindo o problema. Self-check: confirme viabilidade e completude antes de retornar.
+""")
+```
+
+```bash
+mv "$PLAN" "${PLAN%-PLAN.md}-PLAN-v1.md"
+echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | phase-{phase_number} | up-planejador | REPLAN | {motivo}" >> .plano/governance/replans.log
+# Voltar pro LOOP DE WAVES (3.2+3.3): re-spawnar o executor SO desse plano, na wave dele, com o plano novo.
+```
 
-### 3.6 Verificacao (PASSO 3 — Agent SEPARADO)
+### 3.5 Verificacao da FASE (PASSO 2 - Agent SEPARADO)
 
-**Wave 4 (v0.13+) — Verification Ladder Determinística**
+Roda UMA VEZ por fase, depois de TODAS as waves. O verificador valida a FASE INTEIRA (todos os planos /
+todos os SUMMARYs juntos), nao 1 plano isolado. Um unico VERIFICATION.md cobre a fase.
 
-ANTES do verificador-LLM, rodar checks deterministicos:
+**Verification ladder deterministica primeiro:**
 
 ```bash
 STATIC=$(node "$HOME/.claude/up/bin/up-tools.cjs" verify-static --raw)
 STATIC_OVERALL=$(echo "$STATIC" | grep -oE 'overall.{1,20}' | head -1 | grep -oE '"(pass|fail|skip)"' | tr -d '"')
 
 if [ "$STATIC_OVERALL" = "pass" ]; then
-  # Pular verificador-LLM, criar VERIFICATION.md sintetico
   cat > "${PHASE_DIR}/VERIFICATION.md" <<EOF
 ---
 status: passed
@@ -457,194 +489,376 @@ EOF
 fi
 ```
 
-Se STATIC=fail ou skip: spawnar verificador-LLM com static logs como contexto:
+Se STATIC=fail ou skip: spawnar `up-verificador` com os logs estaticos como contexto:
 
 ```python
 Agent(subagent_type="up-verificador", prompt=f"""
-  Verificar fase {phase_number}.
-  
+  Verificar a FASE {phase_number} INTEIRA (todos os planos / todos os SUMMARYs juntos, nao 1 plano).
+  Conferir o objetivo da fase contra o codebase real e cruzar os REQUIREMENTS desta fase com o que
+  TODOS os SUMMARYs ({PHASE_DIR}/*-SUMMARY.md) entregaram.
   <static_check_results overall="{STATIC_OVERALL}">
   Logs em .plano/runtime/verify-static-*.log
   </static_check_results>
-  
-  FOCAR no que falhou nos checks. Nao reexecutar tudo.
+  FOCAR no que falhou. Exigir evidencia fresca por tipo de codigo. Gerar UM VERIFICATION.md da fase.
 """)
 ```
 
-### --- GATE C: Verificar que verificacao produziu artefatos ---
+### --- GATE B: artefatos da verificacao ---
 
 ```bash
-echo "=== GATE C: Verificando artefatos da verificacao (Fase ${PHASE_NUMBER}) ==="
+echo "=== GATE B: artefatos da verificacao (Fase ${PHASE_NUMBER}) ==="
 VERIF_COUNT=$(ls ${PHASE_DIR}/*-VERIFICATION.md 2>/dev/null | wc -l)
-[ "$VERIF_COUNT" -eq 0 ] && echo "GATE C FALHOU: Sem VERIFICATION.md. Spawnar verificador." && exit 1
-echo "GATE C OK: ${VERIF_COUNT} VERIFICATION(s)"
+[ "$VERIF_COUNT" -eq 0 ] && echo "GATE B FALHOU: sem VERIFICATION.md. Spawnar verificador." && exit 1
+echo "GATE B OK: ${VERIF_COUNT} VERIFICATION(s)"
 ```
 
-### 3.6.1 Verification Supervisor (PASSO 4 — Agent SEPARADO)
+### 3.6 E2E + DCRV (PASSO 3)
 
-```python
-Agent(subagent_type="up-verification-supervisor", prompt=f"""
-  Revisar verificacao da Fase {phase_number}.
-  Decisao: APPROVE | REQUEST_CHANGES | ESCALATE
-  
-  **OUTPUT OBRIGATORIO (fazer ANTES de retornar):**
-  ```bash
-  echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | phase-{phase_number} | verification-supervisor | {{DECISAO}} | {{motivo}}" >> .plano/governance/approvals.log
-  ```
-""")
+Delegar ao loop DCRV (que absorveu builder-e2e). Ver `@~/.claude/up/workflows/dcrv.md`.
+
+```
+SCOPE=phase, PHASE_DIR={PHASE_DIR}, PHASE_NUMBER={phase_number}, AUTO_FIX=true, MAX_CYCLES=3
 ```
 
-### --- GATE D: Verificar que AMBOS supervisores logaram ---
+Pular se a fase nao tem UI nem API (infra/schema).
+
+### 3.7 Revisao da FASE (PASSO 4 - Agent SEPARADO)
+
+Roda UMA VEZ por fase, depois de TODAS as waves. O revisor revisa a FASE consolidada (todos os planos /
+todos os SUMMARYs juntos).
+
+**Derivar o tipo de evidencia esperado (Fase 3 - TDD por tipo).** A fase pode ter VARIOS planos de tipos
+diferentes; agregamos o `type` do frontmatter de TODOS os planos da fase e exigimos a evidencia mais forte
+aplicavel (UI > glue > logic): se QUALQUER plano da fase e UI -> exige `ui:visual`; senao se qualquer plano
+e integracao -> `glue:smoke`; senao `logic:test_pass`. O GATE so aprova com `evidence=<tipo>:<resultado>`
+do tipo certo:
 
 ```bash
-echo "=== GATE D: Verificando governance completa (Fase ${PHASE_NUMBER}) ==="
-EXEC_OK=$(grep -c "phase-${PHASE_NUMBER}.*execution-supervisor" .plano/governance/approvals.log 2>/dev/null)
-VERIF_OK=$(grep -c "phase-${PHASE_NUMBER}.*verification-supervisor" .plano/governance/approvals.log 2>/dev/null)
-[ "$EXEC_OK" -eq 0 ] || [ "$VERIF_OK" -eq 0 ] && echo "GATE D FALHOU: supervisor faltante" && exit 1
-echo "GATE D OK: ambos supervisores logaram"
+# Agrega os tipos de TODOS os planos da fase (nao mais 1 plano via head -1).
+PHASE_TYPES=$(grep -hoE '^type:[[:space:]]*[a-z-]+' ${PHASE_DIR}/*-PLAN.md 2>/dev/null | sed 's/type:[[:space:]]*//')
+if echo "$PHASE_TYPES" | grep -qE '^(frontend|ui|css)$'; then
+  EVIDENCE_TYPE="ui";   EVIDENCE_RESULT="visual"      # UI/CSS -> captura visual antes/depois (Playwright)
+elif echo "$PHASE_TYPES" | grep -qE '^(integration|glue|webhook)$'; then
+  EVIDENCE_TYPE="glue"; EVIDENCE_RESULT="smoke"       # integracao (Asaas/uazapi/etc) -> smoke-test
+else
+  EVIDENCE_TYPE="logic"; EVIDENCE_RESULT="test_pass"  # parser/calculo/API-propria/bugfix -> teste red-green
+fi
+echo "Fase {phase_number}: evidence esperada (agregada da fase) = ${EVIDENCE_TYPE}:${EVIDENCE_RESULT}"
 ```
 
-### 3.7 E2E + DCRV (PASSO 5)
-
-Ver builder.md secao 3.1.5 (E2E) e 3.1.5.1 (DCRV).
+A evidencia ja foi PRODUZIDA upstream: `logic:test_pass` pelo verificador (red-green); `ui:visual` pela
+captura visual antes/depois do `up-tester` no DCRV (3.6); `glue:smoke` pelo smoke do DCRV (3.6). O revisor
+apenas CONFIRMA que ela existe e a carimba no approvals.log. Ver `@~/.claude/up/workflows/dcrv.md`.
 
-### 3.8 Chief-engineer Aprova Fase (PASSO 6 — Agent SEPARADO)
+Spawnar `up-revisor` (UNICO, two-stage). Substitui supervisores, chiefs e auditores gold.
 
 ```python
 Agent(
-  subagent_type="up-chief-engineer",
+  subagent_type="up-revisor",
   prompt=f"""
-    Revisar Fase {phase_number} consolidada.
-    Validar coerencia plano vs execucao vs verificacao.
-    Decidir: APPROVE | REQUEST_CHANGES | ESCALATE_CEO
-    
-    **OUTPUT OBRIGATORIO (fazer ANTES de retornar):**
+    Revisar a Fase {phase_number} consolidada (two-stage).
+
+    STAGE 1 — spec-compliance cetico: assuma que "terminou rapido demais". Valide o comportamento
+    contra os REQUIREMENTS desta fase navegando/inspecionando o resultado real (nao confie no codigo
+    nem no SUMMARY). Emita um Confidence Score (0-100) de delivery.
+    STAGE 2 — code-quality: padroes, edge cases, OWASP/security, wiring ponta a ponta.
+
+    <files_to_read>
+    - {PHASE_DIR}/*-PLAN.md (TODOS os planos da fase)
+    - {PHASE_DIR}/*-SUMMARY.md (TODOS os SUMMARYs da fase)
+    - {PHASE_DIR}/*-VERIFICATION.md
+    - {PHASE_DIR}/dcrv/DCRV-REPORT.md (se existir)
+    - git diff (use Bash)
+    - .plano/fases/{phase_number}/REQUIREMENTS-SLICE.md (se existir)
+    Sob demanda: $HOME/.claude/up/references/engineering-principles-compressed.md,
+                 $HOME/.claude/up/references/production-requirements-compressed.md
+    </files_to_read>
+
+    Veredito unico: APPROVE | REQUEST_CHANGES | BLOCK.
+
+    **EVIDENCIA OBRIGATORIA (Fase 3 - TDD por tipo):** so APPROVE se houver evidencia fresca do tipo
+    `{EVIDENCE_TYPE}` desta fase:
+    - logic (parser/calculo/API-propria/bugfix): teste red-green passando -> evidence=logic:test_pass
+    - ui (UI/CSS): captura visual antes/depois (Playwright, do up-tester) -> evidence=ui:visual
+    - glue (integracao Asaas/uazapi/etc): smoke-test passando -> evidence=glue:smoke
+    Se a evidencia do tipo certo NAO existe, o veredito NAO pode ser APPROVE (use REQUEST_CHANGES para
+    forcar a producao da evidencia).
+
+    **OUTPUT OBRIGATORIO (ANTES de retornar) - formato estendido com campo evidence:**
     ```bash
-    echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | phase-{phase_number} | chief-engineer | {{DECISAO}} | {{motivo}}" >> .plano/governance/approvals.log
+    echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | phase-{phase_number} | up-revisor | {{DECISAO}} | {{motivo}} | evidence={EVIDENCE_TYPE}:{EVIDENCE_RESULT}" >> .plano/governance/approvals.log
     ```
+    Sem este log COM o campo evidence preenchido do tipo certo, o GATE de fase bloqueia o avanco.
   """
 )
 ```
 
-### --- GATE E: Verificar TODA governanca antes de marcar completa ---
+### --- GATE de fase: veredito do revisor (deterministico) ---
+
+Aplicar o gate de `@~/.claude/up/workflows/governance.md`:
 
 ```bash
-echo "=== GATE E: Verificacao FINAL (Fase ${PHASE_NUMBER}) ==="
+echo "=== GATE: Fase ${PHASE_NUMBER} ==="
 SUMMARY_OK=$(ls ${PHASE_DIR}/*-SUMMARY.md 2>/dev/null | wc -l)
-VERIF_FILE_OK=$(ls ${PHASE_DIR}/*-VERIFICATION.md 2>/dev/null | wc -l)
-EXEC_OK=$(grep -c "phase-${PHASE_NUMBER}.*execution-supervisor" .plano/governance/approvals.log 2>/dev/null)
-VERIF_OK=$(grep -c "phase-${PHASE_NUMBER}.*verification-supervisor" .plano/governance/approvals.log 2>/dev/null)
-CHIEF_OK=$(grep -c "phase-${PHASE_NUMBER}.*chief-engineer" .plano/governance/approvals.log 2>/dev/null)
+VERIF_OK=$(ls ${PHASE_DIR}/*-VERIFICATION.md 2>/dev/null | wc -l)
+REVISOR_ENTRY=$(grep "phase-${PHASE_NUMBER}.*up-revisor" .plano/governance/approvals.log 2>/dev/null | tail -1)
 
 PASS=true
-[ "$SUMMARY_OK" -eq 0 ] && echo "FALHA: Sem SUMMARY.md" && PASS=false
-[ "$VERIF_FILE_OK" -eq 0 ] && echo "FALHA: Sem VERIFICATION.md" && PASS=false
-[ "$EXEC_OK" -eq 0 ] && echo "FALHA: execution-supervisor NAO rodou" && PASS=false
-[ "$VERIF_OK" -eq 0 ] && echo "FALHA: verification-supervisor NAO rodou" && PASS=false
-[ "$CHIEF_OK" -eq 0 ] && echo "FALHA: chief-engineer NAO rodou" && PASS=false
+[ "$SUMMARY_OK" -eq 0 ] && echo "FALHA: sem SUMMARY.md" && PASS=false
+[ "$VERIF_OK" -eq 0 ] && echo "FALHA: sem VERIFICATION.md" && PASS=false
+[ -z "$REVISOR_ENTRY" ] && echo "FALHA: up-revisor NAO logou" && PASS=false
+
+# Fase 3 - TDD: a entry do revisor PRECISA ter o campo evidence=<tipo>:<resultado> do tipo certo.
+EVIDENCE_FIELD=$(echo "$REVISOR_ENTRY" | grep -oE 'evidence=(logic|ui|glue):(test_pass|visual|smoke)')
+if [ -z "$EVIDENCE_FIELD" ]; then
+  echo "FALHA: up-revisor logou sem campo evidence=<tipo>:<resultado>. Re-rodar revisor com prova fresca." && PASS=false
+elif [ -n "$EVIDENCE_TYPE" ] && ! echo "$EVIDENCE_FIELD" | grep -q "evidence=${EVIDENCE_TYPE}:"; then
+  echo "FALHA: evidence de tipo errado ($EVIDENCE_FIELD; esperado ${EVIDENCE_TYPE}). Re-rodar com prova certa." && PASS=false
+fi
+
+DECISION=$(echo "$REVISOR_ENTRY" | awk -F'|' '{gsub(/ /,"",$4); print $4}')
 
 if [ "$PASS" = false ]; then
-  echo "GATE E FALHOU: Voltar e executar passos faltantes."
+  echo "GATE FALHOU: spawnar o agente faltante e re-rodar."
   exit 1
-else
-  echo "GATE E OK: Todos 5 checks passaram."
 fi
 ```
 
-### 3.9 Marcar Completa e Avancar
+**Processar o veredito:**
+- `APPROVE`: prosseguir para 3.8.
+- `REQUEST_CHANGES`: cap de rework 1 round (ver governance.md passo 4). Round 0 -> re-spawn do(s)
+  executor(es) do(s) plano(s) apontado(s) no review (mesmo bloco Agent de 3.2+3.3, parametrizado por
+  plano); round >= 1 -> forced approval com debito tecnico. Depois re-rodar verificador da fase + revisor.
+- `BLOCK`: interromper e alertar o dono (AskUserQuestion).
+
+### 3.8 Fechar a fase: teste visual (pre-merge) + merge
+
+So apos o GATE aprovar (APPROVE ou forced approval registrado).
+
+**Caso `--solo` (github_native=false):** nada a fazer aqui. Tudo ja foi committado atomicamente na branch
+atual. Seguir direto para 3.9. (Sem worktree, sem teste-visual-gate, sem merge.)
+
+#### 3.8.0 Checkpoint de teste visual (PRE-MERGE) - so GitHub-nativo
+
+Roda ANTES de qualquer merge. Garante que NADA sobe sem o dono ver na tela. Resolver:
+
+```bash
+REQUIRE_VISUAL=$(node "$HOME/.claude/up/bin/up-tools.cjs" config get require_visual_test --raw 2>/dev/null)
+[ -z "$REQUIRE_VISUAL" ] && REQUIRE_VISUAL=true
+# HAS_UI: a fase tocou em UI? (tipo do plano frontend/ui/css OU package.json com script dev/start/serve)
+HAS_DEV=$(node -e "try{const s=require('./package.json').scripts||{};process.stdout.write((s.dev||s.start||s.serve)?'1':'')}catch(e){}" 2>/dev/null)
+```
+
+**Aplica o gate quando:** (HAS_UI ou HAS_DEV) E NAO (`--auto` E REQUIRE_VISUAL=false).
+Ou seja: por padrao SEMPRE pede aprovacao visual antes do merge em fase de UI. Para PULAR (CI/yolo):
+`--auto` + setar `require_visual_test=false` no config. Para projeto em PRODUCAO: deixe o default (true).
+
+Se aplica:
+
+1. **Subir o dev server DENTRO da worktree** (o codigo da fase vive na worktree - voce testa o codigo REAL
+   da fase, nao a main). Ainda DENTRO da worktree, antes de sair dela:
+
+```bash
+PORT=${PORT:-3000}
+if ! curl -s "http://localhost:${PORT}" >/dev/null 2>&1; then
+  ( npm run dev > /tmp/up-build-dev-${phase_number}.log 2>&1 & ) \
+    || ( npm start > /tmp/up-build-dev-${phase_number}.log 2>&1 & )
+  for i in $(seq 1 40); do curl -s "http://localhost:${PORT}" >/dev/null 2>&1 && break; sleep 1; done
+fi
+echo "Dev server da Fase {phase_number} no ar: http://localhost:${PORT}"
+```
+
+2. **Perguntar (AskUserQuestion):**
+
+```
+header: "Fase {phase_number}: testar antes de mergear?"
+question: "Subi o dev server em http://localhost:{PORT} com o codigo desta fase. Testar primeiro ou pode mergear?"
+options:
+  - "Testar primeiro (deixo o server no ar)"
+  - "Pode mergear"
+  - "Deixa a branch (nao mergeia agora)"
+  - "Descarta a fase"
+```
+
+3. **Se "Testar primeiro":** MANTEM o dev server no ar, repete a URL, e ESPERA o dono testar. Quando ele
+   voltar, perguntar de novo:
+
+```
+header: "Testou a Fase {phase_number}?"
+question: "E ai, pode fechar?"
+options:
+  - "Aprovado, pode mergear"
+  - "Achei problema, quero ajustar"
+```
+
+   - **"Achei problema, quero ajustar":** pedir a descricao do problema, re-spawnar `up-executor` pra corrigir
+     NA WORKTREE (mesma branch da fase), re-rodar `up-verificador` + GATE (3.6/3.7), e VOLTAR pro 3.8.0
+     (re-testa com o dev server). Loop ate o dono aprovar. (E o "quando eu disser nao, ajusta; quando eu
+     disser sim, merge".)
+   - **"Aprovado, pode mergear":** segue como "Pode mergear".
+
+4. **Matar o dev server** antes de sair da worktree e mergear:
+
+```bash
+pkill -f "npm run dev" 2>/dev/null || true; pkill -f "npm start" 2>/dev/null || true
+```
+
+A escolha do checkpoint define a acao de fechamento (3.8.1): "Pode mergear"/"Aprovado" -> MERGE;
+"Deixa a branch" -> nao mergeia; "Descarta" -> remove sem merge.
+
+**Fase SEM UI** (infra/schema/backend puro) ou `--auto` com `require_visual_test=false`: pula 3.8.0.
+Nesse caso, GitHub-nativo interativo ainda apresenta o mesmo AskUserQuestion de 4 opcoes (sem o passo do
+dev server) pra o dono decidir merge/PR/deixa/descarta. `--auto` com fase sem UI fecha direto (sem perguntar).
+
+#### 3.8.1 Merge e avancar
+
+Sair da worktree (**ExitWorktree** ou `cd` de volta ao repo principal) para que `finish-phase` opere e
+atualize `git-map.json` na main. Mapear a escolha de 3.8.0 para `finish-phase`
+(`--mode menu|auto|solo`):
+
+```bash
+case "$ESCOLHA" in
+  # Pode mergear / Aprovado: finish-phase --mode auto faz gh pr create (Closes #N) -> merge squash -> cleanup.
+  # FAIL-OPEN: sem gh/remote, --mode auto degrada para merge LOCAL da branch na base + cleanup (issue/PR=null).
+  mergear|aprovado) node "$HOME/.claude/up/bin/up-tools.cjs" github finish-phase --phase {phase_number} --mode auto --strategy squash ;;
+  # Deixa a branch: nao mergeia; worktree+branch vivos. menu so atualiza git-map.json (status=in_review).
+  deixa)            node "$HOME/.claude/up/bin/up-tools.cjs" github finish-phase --phase {phase_number} --mode menu ;;
+  # Descarta: orquestrador remove worktree + branch (sem merge); reflete em git-map.json via status=cancelled.
+  descarta)         echo "Descartando fase {phase_number}: remover worktree + branch (sem merge)." ;;
+esac
+```
+
+`finish-phase --mode auto` faz: gh pr create (body com `Closes #<issue>` quando ha issue) -> merge (squash
+default, ou `--strategy merge|rebase`) -> cleanup worktree+branch, e atualiza `git-map.json`. FAIL-OPEN: sem
+gh/remote, faz merge LOCAL da branch da fase na base e remove a worktree (issue/PR = null). `--mode solo` nao
+faz nada (usado quando ja esta tudo committado na branch atual); em `--solo` o fluxo nem chega aqui.
+
+**Multica: sync BATCHED no FIM da fase/onda (so se `--board`).**
+Uma unica chamada que reflete TODAS as transicoes acumuladas da fase de uma vez (nao por microtransicao):
+status final + metadata `gh_issue`/`branch`/`pr`. Mapeamento de status UP -> Multica:
+`done->done`, `in_review->in_review`, `blocked->blocked` (descarte/opcao 4 -> `cancelled`). Status final:
+opcoes 1/2 (merge/PR) -> `done`; opcao 3 (deixa branch) -> `in_review`; opcao 4 (descarta) -> `cancelled`.
+A KEY do Multica ja vai no body do PR (`Closes MUL-X`) via `finish-phase`, entao o merge auto-avanca a
+issue pra `done` no proprio Multica; este `sync done` e idempotente. FAIL-OPEN: erro -> avisa e segue.
+
+```bash
+if [ "$BOARD" = "true" ]; then
+  case "$ESCOLHA" in
+    1|2) MB_STATUS=done ;;
+    3)   MB_STATUS=in_review ;;
+    4)   MB_STATUS=cancelled ;;
+    *)   MB_STATUS=done ;;   # --auto sem menu = fechou = done
+  esac
+  # Ler pr_number do git-map.json da fase (escrito por finish-phase), se houver.
+  MB_PR=$(node "$HOME/.claude/up/bin/up-tools.cjs" github status --phase {phase_number} --raw 2>/dev/null \
+    | grep -oE '"pr"[^,}]*' | sed 's/.*: *//;s/"//g')
+  node "$HOME/.claude/up/bin/up-tools.cjs" multica sync \
+    --phase {phase_number} --status "$MB_STATUS" \
+    --gh-issue "${ISSUE:-}" --branch "${BRANCH:-}" --pr "${MB_PR:-}" --raw 2>/dev/null \
+    || echo "AVISO: Multica indisponivel (sync $MB_STATUS fase {phase_number}). Seguindo."
+fi
+```
+
+> Em `--solo` o fluxo nem chega aqui (sem `--board`): nenhuma chamada Multica.
+
+### 3.9 Reassessment de roadmap (pos-fase, inline, ~30s)
+
+Apos o GATE aprovar e ANTES de planejar/executar a proxima fase, o orquestrador re-avalia o ROADMAP inline (sem agente separado). Migrado do builder.md 3.1.7 (caira por omissao no corte; recolocado).
+
+Ler ROADMAP.md (fases futuras) + os SUMMARY da fase recem-completa e checar 3 coisas:
+- **(a) Fase futura virou redundante?** A fase atual pode ter coberto algo que uma fase futura faria (ex: auth da Fase 3 ja entregou o RBAC que a Fase 6 planejava). Se sim: marcar a fase futura como `Removida (coberta pela Fase {X})` no ROADMAP.
+- **(b) Fase futura precisa de ajuste?** Decisao arquitetural desta fase muda o escopo de fases futuras (ex: escolheu tRPC, fases de API mudam). Se sim: atualizar objetivo/criterios da fase futura.
+- **(c) Surgiu necessidade nova critica?** Ler `.plano/captures/` (se existir). Insight que bloqueia fases futuras vira fase nova; melhoria so vai pro Polish.
+
+Se houve mudanca no roadmap:
+
+```bash
+node "$HOME/.claude/up/bin/up-tools.cjs" commit "docs: reassessment apos fase {X}" --files .plano/ROADMAP.md
+```
 
-**So apos GATE E passar.**
+Log de 1 linha: `Reassessment: [sem mudancas | X ajustadas | Y removidas | Z adicionadas]`. Sem mudanca: seguir silenciosamente. Diferente do re-plan LOCAL do Estagio 3.4 (que so corrige a fase corrente): aqui poda/ajusta o roadmap FUTURO a luz do que ja foi construido.
 
 ## Estagio 4: QUALITY GATE GLOBAL
 
-Mesmo processo do builder.md secao Estagio 4. Sem model routing.
+Rodar DCRV em escopo global apos todas as fases:
+
+```
+SCOPE=global, AUTO_FIX=true, MAX_CYCLES=5
+```
+
+Ver `@~/.claude/up/workflows/dcrv.md`. Carryover de issues por fase ja foi acumulado em
+`.plano/issues-carryover/`.
 
-## Estagio 4.5: DELIVERY AUDIT
+## Estagio 4.5: REVISAO DE DELIVERY (consolidada)
+
+Spawnar `up-revisor` em escopo global (Confidence Score de delivery do projeto inteiro). Substitui a
+antiga auditoria de delivery dedicada.
 
 ```python
-Agent(subagent_type="up-delivery-auditor", ...)
+Agent(subagent_type="up-revisor", prompt="""
+  Revisao final de delivery (escopo: projeto). Stage 1 valida comportamento vs REQUIREMENTS globais;
+  Stage 2 confere qualidade/seguranca cross-fase. Emitir Confidence Score (0-100) e veredito.
+  Logar em .plano/governance/approvals.log com escopo 'delivery'.
+""")
 ```
 
 ## Estagio 5: DELIVERY
 
-Mesmo processo. CEO local apresenta resultado.
+Apresentacao = output direto do orquestrador (sem CEO). Le owner-profile pra tom.
 
 ### 5.X Marcar Projeto Completo
 
 ```bash
-# PLAN-READY.md → PROJECT-COMPLETE.md
 mv .plano/PLAN-READY.md .plano/PROJECT-COMPLETE.md
 ```
 
+**Multica: fechar o board (so se `--board`).** Sync batched final marca a issue-pai como `done` (idempotente).
+FAIL-OPEN. Imprimir a URL do board pro dono ver o resultado.
+
+```bash
+if [ "$BOARD" = "true" ]; then
+  node "$HOME/.claude/up/bin/up-tools.cjs" multica sync --status done --raw 2>/dev/null \
+    || echo "AVISO: Multica indisponivel (sync final). Seguindo."
+  node "$HOME/.claude/up/bin/up-tools.cjs" multica board --raw 2>/dev/null   # imprime a URL do board
+fi
+```
+
 Adicionar ao frontmatter:
 ```yaml
 status: complete
 completed_at: [timestamp]
 completed_by:
   runtime: [current]
-  ceo_name: [local]
-final_confidence: [from audit]
+final_confidence: [do up-revisor de delivery]
 ```
 
 </process>
 
-<replans>
-
-## Re-plans Locais (max 2)
-
-Quando: execution-supervisor descobre que o plano original esta inviavel.
-
-Como funciona:
-
-```
-Execution falha
-  ↓
-execution-supervisor analisa
-  ↓
-Decide: REQUEST_REPLAN
-  ↓
-Verifica replans.log < 2?
-  ├─ Sim: prosseguir
-  └─ Nao: ESCALATE pro CEO
-  ↓
-Spawnar planejador LOCAL no runtime atual
-  ↓
-Refaz plano daquela fase
-  ↓
-Salva como PLAN-v2.md (preserva v1 pra historico)
-  ↓
-Planning-supervisor LOCAL revisa
-  ↓
-Se APPROVE: voltar pro executor com novo plano
-Se REJECT: ESCALATE pro chief-engineer
-```
-
-Registro em `.plano/governance/replans.log`:
-```
-2026-04-11T15:30:00Z | phase-3 | execution-supervisor | REPLAN | cycle 1/2
-  reason: Library X discontinued, need to use Y instead
-  original_plan: 03-01-PLAN-v1.md
-  new_plan: 03-01-PLAN.md (was v2)
-```
-
-</replans>
-
 <success_criteria>
 - [ ] Owner profile LOCAL validado
 - [ ] PLAN-READY.md existe e parseado
 - [ ] Validacao light passou (artefatos + planos existem)
-- [ ] CEO confirmou execucao
+- [ ] Dono confirmou execucao (orquestrador, sem CEO)
 - [ ] Governance inicializada (.plano/governance/approvals.log)
-- [ ] Todas fases executadas com SUMMARY.md (GATE A por fase)
-- [ ] Execution-supervisor revisou CADA fase (GATE B — logou em approvals.log)
-- [ ] Verificador produziu VERIFICATION.md por fase (GATE C)
-- [ ] Verification-supervisor revisou CADA verificacao (GATE D — logou em approvals.log)
-- [ ] Chief-engineer aprovou CADA fase (GATE E — logou em approvals.log)
-- [ ] GATE E passou para CADA fase (todos 5 checks OK)
-- [ ] Re-plans registrados (se houve)
-- [ ] Quality Gate global passou
-- [ ] Delivery audit aprovou
-- [ ] CEO apresentou resultado
-- [ ] PLAN-READY.md → PROJECT-COMPLETE.md
-- [ ] .plano/governance/approvals.log tem entries de TODOS supervisores e chiefs
+- [ ] Todas as fases executadas com SUMMARY.md (GATE A)
+- [ ] Verificador produziu VERIFICATION.md por fase (GATE B); ladder estatica usada quando possivel
+- [ ] E2E + DCRV rodaram por fase (delegado a dcrv.md)
+- [ ] up-revisor emitiu veredito por fase e LOGOU em approvals.log COM campo evidence=<tipo>:<resultado>
+- [ ] GATE de fase deterministico passou (APPROVE + evidence do tipo certo, ou forced approval com debito)
+- [ ] GitHub-nativo (default): worktree+branch+issue por fase via `github start-phase`; menu 4 opcoes /
+      `github finish-phase` no fim. `--solo` degrada para commit na branch atual (sem worktree/issue/PR)
+- [ ] Execucao sempre via up-executor (roteia por contexto: frontend/backend/database/misto); SEM agentes
+      specialist separados (Onda 2 do corte)
+- [ ] `--board`: Multica init no inicio (project+pai), sync `in_progress` na entrada da fase, sync BATCHED
+      no fim da fase/onda (status+metadata gh_issue/branch/pr), sync done + board URL no delivery. Tudo
+      fail-open (nunca crasha) e batched (nao por microtransicao). Sem `--board`: zero chamada Multica
+- [ ] Cap de rework de 1 round respeitado
+- [ ] Re-plans locais registrados (se houve, max 2)
+- [ ] Quality Gate global rodou
+- [ ] up-revisor fez revisao de delivery consolidada
+- [ ] PLAN-READY.md -> PROJECT-COMPLETE.md
+- [ ] Nenhuma referencia a CEO, chiefs, camadas de revisao intermediaria, auditores gold ou builder-e2e
+- [ ] Nenhuma referencia aos 3 specialists de dominio nem aos 3 detectores DCRV antigos (6 agentes
+      deletados na Onda 2; tudo via up-executor e up-tester)
 </success_criteria>
+</output>