up-cc 0.4.3 → 0.4.5

package/agents/up-planejador.md

@@ -21,6 +21,61 @@ Se o prompt contem um bloco `<files_to_read>`, voce DEVE usar a ferramenta `Read
 - Lidar com planejamento padrao e modo de fechamento de gaps
 - **Research inline:** Se o dominio for desconhecido, pesquisar usando WebFetch/Context7 DENTRO do processo de planejamento
 - **Self-check interno:** Apos criar PLAN.md, rodar checklist interno (tarefas especificas? dependencias identificadas? ondas atribuidas? must_haves derivados?)
+
+**MODO SONNET-READY (quando `<sonnet_execution>true</sonnet_execution>` no prompt):**
+
+O executor sera um modelo Sonnet (mais rapido, mais barato, mas segue instrucoes LITERALMENTE).
+Sonnet NAO infere, NAO decide, NAO improvisa. Ele faz EXATAMENTE o que o plano diz.
+Se o plano e vago, Sonnet entrega vago. Se o plano e preciso, Sonnet entrega preciso.
+
+**Regras Sonnet-ready — CADA tarefa DEVE ter:**
+
+1. **Imports exatos** — nao dizer "importar biblioteca de validacao", dizer "import { z } from 'zod'"
+2. **Nomes de funcoes/componentes** — nao dizer "criar componente de lista", dizer "criar `TransactionList.tsx` com props `{ transactions: Transaction[], onDelete: (id: string) => void }`"
+3. **Schema/tipos definidos** — nao dizer "criar tipo do usuario", dizer:
+   ```typescript
+   interface User {
+     id: string;
+     email: string;
+     name: string;
+     role: 'admin' | 'user';
+     created_at: string;
+   }
+   ```
+4. **Endpoints com assinatura completa** — nao dizer "criar endpoint de login", dizer:
+   ```
+   POST /api/auth/login
+   Body: { email: string, password: string }
+   Response 200: { user: User, token: string }
+   Response 401: { error: "Invalid credentials" }
+   Validacao: zod schema z.object({ email: z.string().email(), password: z.string().min(8) })
+   ```
+5. **SQL/migrations literais** — nao dizer "criar tabela de transacoes", dizer:
+   ```sql
+   CREATE TABLE transactions (
+     id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
+     user_id UUID REFERENCES users(id) ON DELETE CASCADE,
+     amount DECIMAL(12,2) NOT NULL CHECK (amount >= 0),
+     description TEXT NOT NULL,
+     category TEXT NOT NULL,
+     date DATE NOT NULL DEFAULT CURRENT_DATE,
+     created_at TIMESTAMPTZ DEFAULT NOW()
+   );
+   CREATE INDEX idx_transactions_user_id ON transactions(user_id);
+   CREATE INDEX idx_transactions_date ON transactions(date);
+   ```
+6. **Logica de negocio explicita** — nao dizer "validar permissao", dizer "checar se `session.user.role === 'admin'`, se nao, retornar 403"
+7. **Conexoes explicitas** — nao dizer "conectar com o backend", dizer "o componente `TransactionList` deve chamar `fetch('/api/transactions', { headers: { Authorization: 'Bearer ' + token } })` no useEffect, tratar loading/error/empty states"
+
+**Self-check Sonnet-ready (apos cada tarefa do plano):**
+- [ ] A tarefa tem imports explicitados?
+- [ ] A tarefa tem nomes de arquivos, funcoes, componentes, tipos?
+- [ ] A tarefa tem schemas/tipos com campos e tipos definidos?
+- [ ] A tarefa tem endpoints com request/response shapes?
+- [ ] A tarefa tem logica de negocio descrita passo a passo?
+- [ ] Um executor que NAO conhece o projeto consegue implementar SEM pensar?
+
+Se qualquer check falha: reescrever a tarefa com mais detalhe antes de finalizar o plano.
 </role>
 
 <project_context>

package/commands/modo-builder.md

@@ -78,11 +78,14 @@ Em brownfield, convencoes do codebase existente tem prioridade sobre defaults.
 <process>
 **Parsear flags primeiro:** Extrair `--light` dos $ARGUMENTS se presente. O restante e o briefing.
 
-**Se `--light`:**
-Execute o builder workflow em modo light (ver secao `<light_mode>` no workflow).
-Estagios: 1 (Intake simplificado) → 2 (Mini-scan + estrutura inline) → 3 (Build + E2E) → Fim.
+**GUARD: Light mode SOMENTE se `--light` esta presente LITERALMENTE nos argumentos.**
+NAO inferir light baseado no tamanho do briefing. Briefing curto = FULL com poucas fases.
 
-**Se modo full (padrao):**
+**Se `--light` PRESENTE nos argumentos:**
+Execute o builder workflow em modo light (ver secao `<light_process>` no workflow).
+Light ainda verifica (up-verificador), testa (E2E + DCRV 1 ciclo), mas sem polish/delivery.
+
+**Se `--light` AUSENTE (default = FULL):**
 Execute the builder workflow from @~/.claude/up/workflows/builder.md end-to-end.
 
 **CRITICO:** A partir do Estagio 2, ZERO interacao com usuario. NAO use AskUserQuestion apos coletar o briefing e respostas criticas. Toda decisao e tomada autonomamente.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "up-cc",
-  "version": "0.4.3",
+  "version": "0.4.5",
   "description": "Simplified spec-driven development for Claude Code, Gemini and OpenCode.",
   "bin": {
     "up-cc": "bin/install.js"

package/templates/builder-defaults.md

@@ -35,6 +35,27 @@ O usuario customiza uma vez e vale para todos os projetos criados com `/up:modo-
 - Linter: ESLint + Prettier
 - Git: branch main, commits diretos
 
+## Modelos por Papel
+
+Configurar qual modelo de IA usar para cada tipo de trabalho.
+Modelos disponiveis: opus, sonnet, haiku
+
+| Papel | Modelo | Agentes |
+|-------|--------|---------|
+| planning | opus | arquiteto, product-analyst, system-designer, planejador, roteirista |
+| execution | sonnet | executor, frontend-specialist, backend-specialist, database-specialist |
+| verification | opus | verificador, code-reviewer, blind-validator, requirements-validator |
+| detection | sonnet | visual-critic, exhaustive-tester, api-tester |
+| research | sonnet | pesquisador-projeto, pesquisador-mercado, mapeador-codigo |
+| quality | opus | qa-agent, security-reviewer, auditor-ux, auditor-performance |
+
+Notas:
+- Opus: raciocinio profundo, decisoes arquiteturais, verificacao critica. Mais lento, mais caro.
+- Sonnet: execucao rapida, seguir instrucoes, volume de codigo. Mais rapido, mais barato.
+- Haiku: tarefas simples. NAO recomendado para codigo de producao.
+- Opus e Sonnet ambos suportam 1M de contexto.
+- Se execution=sonnet, planos serao gerados com nivel extra de detalhe (Sonnet-ready).
+
 ## Nao usar
 - (liste aqui tecnologias que voce NAO quer em nenhum projeto)
 ```

package/workflows/builder.md

@@ -11,8 +11,25 @@ Modo Builder: construir projeto completo de forma autonoma. Funciona em dois mod
 A partir do Estagio 2, ZERO interacao com usuario. Todas as decisoes sao tomadas autonomamente.
 
 **IMPORTANTE: Verificar flag `--light` no $ARGUMENTS antes de iniciar.**
-Se `--light` presente: pular direto para `<light_process>` no final deste workflow.
+Se `--light` presente LITERALMENTE nos argumentos: pular direto para `<light_process>`.
 Se ausente: seguir o `<process>` normal (full).
+
+**GUARD CONTRA ATIVACAO ACIDENTAL DO LIGHT:**
+- O modo light so e ativado se o usuario escreveu `--light` explicitamente.
+- NAO inferir light baseado no tamanho do briefing ou complexidade.
+- NAO ativar light porque "parece uma feature simples".
+- Briefing curto = modo FULL com poucas fases, NAO modo light.
+- Se em duvida: FULL. Sempre FULL como default.
+
+**LOG OBRIGATORIO no inicio (EXECUTAR SEMPRE):**
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ UP > MODO BUILDER — {FULL | LIGHT}
+ Versao: $(cat $HOME/.claude/up/VERSION 2>/dev/null || echo "dev")
+ Argumentos: $ARGUMENTS
+ Flag --light: {SIM | NAO}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
 </purpose>
 
 <core_principle>
@@ -38,6 +55,38 @@ Neste modo, TODOS os agentes devem:
 7. **Quality Gate:** Incluir clone-verifier como dimensao "Fidelidade" (20% do score).
 </core_principle>
 
+<model_routing>
+## Roteamento de Modelos por Papel
+
+**REGRA OBRIGATORIA:** Ao spawnar QUALQUER agente via Task() ou Agent(), incluir o parametro `model` baseado nesta tabela. Usar os valores de $MODEL_* extraidos do builder-defaults.md (Estagio 1.1).
+
+| Papel | Variavel | Agentes | Default |
+|-------|----------|---------|---------|
+| **Planning** | $MODEL_PLANNING | up-arquiteto, up-product-analyst, up-system-designer, up-planejador, up-roteirista | opus |
+| **Execution** | $MODEL_EXECUTION | up-executor, up-frontend-specialist, up-backend-specialist, up-database-specialist | sonnet |
+| **Verification** | $MODEL_VERIFICATION | up-verificador, up-code-reviewer, up-blind-validator, up-requirements-validator | opus |
+| **Detection** | $MODEL_DETECTION | up-visual-critic, up-exhaustive-tester, up-api-tester | sonnet |
+| **Research** | $MODEL_RESEARCH | up-pesquisador-projeto, up-pesquisador-mercado, up-mapeador-codigo, up-sintetizador | sonnet |
+| **Quality** | $MODEL_QUALITY | up-qa-agent, up-security-reviewer, up-auditor-ux, up-auditor-performance, up-auditor-modernidade, up-sintetizador-melhorias, up-consolidador-ideias, up-devops-agent, up-technical-writer | opus |
+
+**Exemplo de aplicacao:**
+```python
+# ANTES (sem model routing):
+Task(subagent_type="up-executor", prompt="...")
+
+# DEPOIS (com model routing):
+Task(subagent_type="up-executor", model="$MODEL_EXECUTION", prompt="...")
+
+# Equivale a (com defaults):
+Task(subagent_type="up-executor", model="sonnet", prompt="...")
+```
+
+**Ao spawnar qualquer agente, SEMPRE:**
+1. Identificar o papel do agente na tabela acima
+2. Usar a variavel $MODEL_* correspondente como parametro model
+3. Se a variavel nao foi definida (sem builder-defaults), usar o default da tabela
+</model_routing>
+
 <process>
 
 ## Estagio 1: INTAKE (Interativo)
@@ -100,6 +149,24 @@ DEFAULTS_PATH="$HOME/.claude/up/builder-defaults.md"
 
 Ler `$DEFAULTS_PATH` se existir. Se nao existir, informar: "Sem builder-defaults.md. Usando inferencia inteligente para decisoes nao especificadas. Crie ~/.claude/up/builder-defaults.md para personalizar."
 
+**Extrair configuracao de modelos:**
+
+Se builder-defaults.md existe, procurar secao "## Modelos por Papel" e extrair mapeamento:
+```
+$MODEL_PLANNING = modelo para planning (default: opus)
+$MODEL_EXECUTION = modelo para execution (default: sonnet)
+$MODEL_VERIFICATION = modelo para verification (default: opus)
+$MODEL_DETECTION = modelo para detection (default: sonnet)
+$MODEL_RESEARCH = modelo para research (default: sonnet)
+$MODEL_QUALITY = modelo para quality (default: opus)
+```
+
+Se secao nao existe: usar defaults acima (opus planeja, sonnet executa, opus verifica).
+
+**IMPORTANTE — Sonnet-ready planning:**
+Se `$MODEL_EXECUTION = sonnet`, setar flag `$SONNET_EXECUTION = true`.
+Isso ativa nivel extra de detalhe nos planos (ver planejador Sonnet-ready mode).
+
 **Detectar modo automaticamente:**
 
 ```bash
@@ -504,7 +571,7 @@ Escrever .plano/PRODUCT-ANALYSIS.md
 Commit apos escrever.
 Retornar: ## PRODUCT ANALYSIS COMPLETE
 </output>
-", subagent_type="up-product-analyst", description="Analisar produto e mercado")
+", subagent_type="up-product-analyst", model="$MODEL_PLANNING", description="Analisar produto e mercado")
 ```
 
 Verificar retorno `## PRODUCT ANALYSIS COMPLETE`. Se falhou: registrar e continuar (System Designer usara blueprints como fallback).
@@ -553,7 +620,7 @@ Escrever .plano/SYSTEM-DESIGN.md
 Commit apos escrever.
 Retornar: ## SYSTEM DESIGN COMPLETE
 </output>
-", subagent_type="up-system-designer", description="Projetar sistema completo")
+", subagent_type="up-system-designer", model="$MODEL_PLANNING", description="Projetar sistema completo")
 ```
 
 ```
@@ -616,7 +683,7 @@ Se brownfield:
 - parallelization=true
 - Commit todos arquivos ao final
 </constraints>
-", subagent_type="up-arquiteto", description="Estruturar projeto executavel")
+", subagent_type="up-arquiteto", model="$MODEL_PLANNING", description="Estruturar projeto executavel")
 ```
 
 ### 2.7 Validar Requisitos (Quality Gate de Planejamento)
@@ -630,6 +697,7 @@ Validando requisitos (13 checks)...
 ```
 Task(
   subagent_type="up-requirements-validator",
+  model="$MODEL_VERIFICATION",
   prompt="
     <objective>
     Validar REQUIREMENTS.md com 13 checks automaticos.
@@ -814,13 +882,14 @@ Para cada fase no ROADMAP (da primeira a ultima):
 
 #### 3.1.1 Planejar Fase
 
-Spawnar up-planejador com flag de modo builder:
+Spawnar up-planejador com flag de modo builder e modelo de planning:
 
 ```
 Task(prompt="
 <planning_context>
 **Fase:** {phase_number}
 **Modo:** builder (autonomo -- NAO use AskUserQuestion)
+<sonnet_execution>{$SONNET_EXECUTION}</sonnet_execution>
 
 <files_to_read>
 - .plano/STATE.md (Estado do Projeto)
@@ -862,15 +931,35 @@ Se algo falhar, corrija antes de retornar.
 Escrever PLAN.md em: .plano/fases/{phase_dir}/
 Retornar: ## PLANNING COMPLETE com resumo dos planos
 </output>
-", subagent_type="up-planejador", description="Planejar Fase {phase_number}")
+", subagent_type="up-planejador", model="$MODEL_PLANNING", description="Planejar Fase {phase_number}")
 ```
 
 Verificar retorno:
-- `## PLANNING COMPLETE` → prosseguir para execucao
+- `## PLANNING COMPLETE` → prosseguir para quality gate do plano
 - `## PLANNING INCONCLUSIVE` → tentar novamente com mais contexto (max 2 tentativas)
 
+**Quality Gate do Plano (se $SONNET_EXECUTION = true):**
+
+Antes de passar pro executor, verificar qualidade do plano rapidamente:
+```bash
+# Contar tarefas com detalhamento insuficiente
+for plan in .plano/fases/{phase_dir}/*-PLAN.md; do
+  # Checar se tem imports/schemas/endpoints explicitados
+  DETAIL_SCORE=0
+  grep -c "import \|from '" "$plan" > /dev/null && DETAIL_SCORE=$((DETAIL_SCORE+1))
+  grep -c "interface \|type \|schema\|z\.\|zod" "$plan" > /dev/null && DETAIL_SCORE=$((DETAIL_SCORE+1))
+  grep -c "POST \|GET \|PUT \|DELETE \|endpoint\|route" "$plan" > /dev/null && DETAIL_SCORE=$((DETAIL_SCORE+1))
+  grep -c "CREATE TABLE\|migration\|ALTER" "$plan" > /dev/null && DETAIL_SCORE=$((DETAIL_SCORE+1))
+  echo "$plan: detail_score=$DETAIL_SCORE"
+done
+```
+
+Se algum plano tem detail_score < 2 e a fase tem mais de 3 tarefas:
+- Re-spawnar planejador com instrucao extra: "Plano insuficientemente detalhado para executor Sonnet. Reescrever com imports, tipos, schemas e endpoints explicitos. Ver self-check Sonnet-ready."
+- Max 1 re-tentativa de enriquecimento
+
 ```
-Fase {X}: Planejada — {N} planos em {M} waves
+Fase {X}: Planejada — {N} planos em {M} waves [Sonnet-ready: {score}]
 ```
 
 #### 3.1.2 Executar Fase (com Specialist Routing)
@@ -914,6 +1003,7 @@ Para cada wave, spawnar agentes especializados em paralelo (se parallelization=t
 ```
 Task(
   subagent_type="{up-frontend-specialist | up-backend-specialist | up-database-specialist | up-executor}",
+  model="$MODEL_EXECUTION",
   prompt="
     <objective>
     Executar plano {plan_number} da fase {phase_number}-{phase_name}.
@@ -976,6 +1066,7 @@ Spawnar code reviewer:
 ```
 Task(
   subagent_type="up-code-reviewer",
+  model="$MODEL_VERIFICATION",
   prompt="
     <objective>
     Revisar codigo da fase {phase_number} contra production-requirements e padroes de qualidade.
@@ -1031,7 +1122,8 @@ Modo builder. NAO use AskUserQuestion.
 - Criar VERIFICATION.md
 </builder_mode>
 ",
-  subagent_type="up-verificador"
+  subagent_type="up-verificador",
+  model="$MODEL_VERIFICATION"
 )
 ```
 
@@ -1527,6 +1619,7 @@ Relatorio em .plano/ideias/RELATORIO.md
 ```
 Task(
   subagent_type="up-blind-validator",
+  model="$MODEL_VERIFICATION",
   prompt="
     <objective>
     Validar requisitos SEM ler codigo. Apenas navegar o app via Playwright e curl.
@@ -1678,6 +1771,7 @@ Spawnar devops agent:
 ```
 Task(
   subagent_type="up-devops-agent",
+  model="$MODEL_QUALITY",
   prompt="
     <objective>
     Gerar artefatos de producao para o projeto: Dockerfile, docker-compose, CI/CD, .env.example, seed data, scripts.
@@ -1716,6 +1810,7 @@ Spawnar technical writer:
 ```
 Task(
   subagent_type="up-technical-writer",
+  model="$MODEL_QUALITY",
   prompt="
     <objective>
     Gerar documentacao completa: README.md, API docs, CHANGELOG.md, setup guide.
@@ -1757,6 +1852,7 @@ Spawnar security reviewer:
 ```
 Task(
   subagent_type="up-security-reviewer",
+  model="$MODEL_QUALITY",
   prompt="
     <objective>
     Auditar codigo para vulnerabilidades de seguranca (OWASP Top 10, auth, injection, data exposure).
@@ -1794,6 +1890,7 @@ Spawnar QA agent:
 ```
 Task(
   subagent_type="up-qa-agent",
+  model="$MODEL_QUALITY",
   prompt="
     <objective>
     Identificar gaps de cobertura de testes, escrever testes que faltam, executar todos.
@@ -2214,31 +2311,58 @@ Retornar: ## PLANNING COMPLETE
 
 Mesmo processo do full — spawnar up-executor por wave.
 
-#### L3.3 Verificar Fase (Quick Check)
+#### L3.3 Verificar Fase
 
-**NAO spawnar up-verificador.** Verificacao inline rapida:
+Spawnar up-verificador (mesmo do full — verificacao real, nao shortcut):
 
-1. Checar que SUMMARYs existem para todos os planos
-2. Checar que commits existem: `git log --oneline --grep="fase-{X}"`
-3. Se ha testes automatizados no projeto: rodar
-```bash
-# Detectar e rodar testes
-npm test 2>/dev/null || pnpm test 2>/dev/null || echo "sem testes"
 ```
-4. Se tudo OK: marcar fase completa
+Task(
+  subagent_type="up-verificador",
+  model="$MODEL_VERIFICATION",
+  prompt="Verificar fase {phase_number}. Diretorio: {phase_dir}. Objetivo: {goal}."
+)
+```
 
-Se falha: tentar gap closure (1 ciclo max), mesmo do full.
+| Status | Acao |
+|--------|------|
+| `passed` | → L3.4 |
+| `gaps_found` | Tentar gap closure (1 ciclo max) |
+| `human_needed` | Registrar, avancar |
 
 #### L3.4 Teste E2E (Playwright)
 
-**Mesmo processo do full** (referencia: builder-e2e.md Passo 3).
-Executar APENAS se a fase tem UI.
+**Referencia:** `@~/.claude/up/workflows/builder-e2e.md` — Passo 3 (Teste por Fase)
+
+**EXECUTAR OBRIGATORIAMENTE se a fase tem UI.** Nao pular.
+
+1. Subir dev server (se nao esta rodando)
+2. Traduzir must_haves em testes E2E
+3. Navegar, interagir, verificar, screenshot
+4. Bugs: corrigir (max 5 tentativas por bug)
+5. Criar E2E-RESULTS.md
+
+**Se dev server falha:** Registrar e continuar (nao bloqueia).
+
+#### L3.4.1 DCRV Light (1 ciclo)
+
+**Apos E2E**, rodar DCRV em modo light (1 ciclo, sem loop):
 
-- Subir dev server (se nao esta rodando)
-- Traduzir must_haves em testes E2E
-- Navegar, interagir, verificar, screenshot
-- Bugs: corrigir (max 5 tentativas por bug)
-- Criar E2E-RESULTS.md
+**Referencia:** `@~/.claude/up/workflows/dcrv.md`
+
+```
+SCOPE=light
+PHASE_DIR={phase_dir}
+PHASE_NUMBER={phase_number}
+MAX_CYCLES=1
+MAX_ISSUES_PER_CYCLE=10
+AUTO_FIX=true
+```
+
+Isso roda os 3 detectores (visual, API, exhaustive), corrige o que puder em 1 ciclo, e segue.
+
+```
+Fase {X} (light): DCRV — {resolved}/{total} issues corrigidas
+```
 
 #### L3.5 Marcar Fase Completa
 
@@ -2293,7 +2417,15 @@ Quer mais? /up:modo-builder "proxima feature"
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-**NAO gerar DELIVERY.md. NAO rodar polish. NAO rodar ideias.**
+**NAO gerar DELIVERY.md. NAO rodar polish completo. NAO rodar ideias.**
+
+**Light mode success criteria:**
+- [ ] .plano/ criado com PROJECT.md, ROADMAP.md, REQUIREMENTS.md
+- [ ] Todas fases executadas com commits atomicos
+- [ ] Verificador rodou em cada fase (NAO quick check)
+- [ ] E2E Playwright rodou em fases com UI
+- [ ] DCRV light (1 ciclo) rodou em cada fase com UI/API
+- [ ] Resumo final exibido com metricas
 
 </light_process>