up-cc 0.16.1 → 2.0.1

package/up/references/tdd-evidence-types.md

@@ -0,0 +1,81 @@
+# TDD por Tipo: Evidência Exigida pelo Gate
+
+Referência operacional carregada sob demanda pelo `up-verificador` e citada pelas skills
+`up-tdd` e `up-verificar-antes-de-concluir`. Define os 3 tipos de evidência, a prova
+exigida de cada um e o formato do campo `evidence=` no `approvals.log`.
+
+A Lei de Ferro do UP nao é "TDD-unit sempre". É "evidência fresca do TIPO CERTO antes de
+afirmar pronto". TDD-unit red-green é UMA das três provas. O tipo de código decide qual prova
+o gate de fase aceita. Sem a evidência do tipo certo, o veredito do revisor NAO pode ser APPROVE.
+
+---
+
+## Os 3 tipos e a prova de cada
+
+| Tipo | Natureza do código | Prova exigida (evidência) | `evidence=` |
+|------|--------------------|---------------------------|-------------|
+| **logic** | lógica pura, parser, cálculo, algoritmo, API própria, bugfix | teste red-green VISTO falhar antes de passar | `evidence=logic:test_pass` |
+| **ui** | componente visual, CSS, layout, estilo, página | captura visual ANTES e DEPOIS (Playwright / `up-tester`) | `evidence=ui:visual` |
+| **glue** | integração externa (Asaas, uazapi, Supabase, Shopify, webhook, OAuth, payment) | smoke-test: UMA chamada real (ou sandbox) com resposta esperada | `evidence=glue:smoke` |
+
+### logic -> teste red-green visto falhar
+A prova NAO é "tem teste". É ter visto o teste FALHAR antes do código existir e PASSAR depois.
+Teste que passa de primeira nao prova nada (pode estar testando o nada). Para bugfix: o teste
+reproduz o bug (falha antes do fix), passa depois, e ao reverter o fix volta a falhar (regressão).
+Resultado aceito: saída do runner com 0 falhas no comportamento-alvo, depois de tê-lo visto vermelho.
+
+### ui -> captura visual antes/depois
+NAO é red-green com mock. "O CSS parece certo" nao prova nada. A prova é o par de screenshots
+(antes e depois) da mudança, via Playwright ou `up-tester`. Sem o par antes/depois, o gate nao passa.
+Resultado aceito: existem as duas capturas e a diferença bate com a mudança pretendida.
+
+### glue -> smoke-test
+Nao dá pra red-green de verdade contra dependência externa. "O endpoint existe" nao prova integração.
+A prova é UMA chamada real (ou contra sandbox/staging) confirmando a resposta esperada.
+Resultado aceito: a chamada retornou o status/payload esperado nesta sessão.
+
+---
+
+## Como determinar o tipo (heurística)
+
+O tipo sai do `classify-task` (`frontmatter_type` + `reasons`) do `up-tools.cjs`, com fallback
+pela natureza da mudança quando nao há plano formal:
+
+1. **glue** se: `frontmatter_type=integration`, ou `reasons` contém `external_integration` /
+   `payment`, ou o código toca Asaas / uazapi / Supabase / Shopify / webhook / OAuth / API de terceiro.
+2. **ui** se (e nao for glue): `frontmatter_type=frontend`, ou a mudança toca componente /
+   `.css` / `.tsx` de view / layout / estilo, sem lógica de negócio testável isolada.
+3. **logic** caso contrário (default): `frontmatter_type` backend / database / refactor / docs-com-código,
+   ou parser / cálculo / algoritmo / API-própria / bugfix. Lógica pura sempre cai aqui.
+
+Uma fase pode misturar tipos (ex: filtro de data = lógica do filtro `logic` + render `ui`).
+Nesse caso exija a evidência de CADA tipo presente e registre uma linha `evidence=` por tipo.
+
+---
+
+## Formato no approvals.log (formato estendido, Fase 3)
+
+O gate de fase só APROVA com uma entrada `up-revisor` que carregue o campo `evidence=` do tipo certo.
+Formato da linha (uma por veredito; o `evidence=` vai na MESMA linha):
+
+```
+<timestamp ISO> | phase-N | up-revisor | <DECISAO> | <motivo> | evidence=<tipo>:<resultado>
+```
+
+- `<tipo>` ∈ `{logic, ui, glue}`
+- `<resultado>` ∈ `{test_pass, visual, smoke}` (test_pass casa com logic, visual com ui, smoke com glue)
+- `<DECISAO>` ∈ `{APPROVE, REQUEST_CHANGES, BLOCK}`
+
+Múltiplos tipos na mesma fase -> várias linhas, uma por tipo:
+
+```
+2026-05-30T14:00:00Z | phase-3 | up-revisor | APPROVE | filtro ok | evidence=logic:test_pass
+2026-05-30T14:00:01Z | phase-3 | up-revisor | APPROVE | render ok | evidence=ui:visual
+```
+
+Regra dura do gate: existe entrada `phase-N` do `up-revisor` COM `evidence=` preenchido e o
+`<resultado>` corresponde ao `<tipo>`. Sem isso (campo ausente ou tipo errado), trate como
+evidência faltando e NAO aprove a fase: volte e produza a prova do tipo certo.
+
+Exceções (só com permissão explícita do dono): protótipo descartável, código gerado, arquivo de config.
+Nesses casos registre `evidence=<tipo>:exempted` com o motivo no `<motivo>`.

package/up/skills/up-brainstorm/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: up-brainstorm
+description: "Use antes de QUALQUER trabalho criativo: criar feature, montar componente, adicionar funcionalidade, mudar comportamento, iniciar projeto ou tarefa. Explora intencao, requisitos e design antes de implementar. Aplica a todo projeto, por mais simples que pareca."
+---
+
+# UP Brainstorm
+
+<HARD-GATE>
+NAO invoque skill de implementacao, NAO escreva codigo, NAO faca scaffold, NAO tome acao de implementacao ate ter apresentado um design e o usuario ter aprovado. Vale para TODO projeto, independente da simplicidade percebida. O design pode ser curto, mas TEM que ser apresentado e aprovado.
+</HARD-GATE>
+
+Anti-padrao combatido: "isso e simples demais pra precisar de design". Mesmo um todo list ou mudanca de config passa pelo processo. O design escala, o gate nao.
+
+## Red flags (racionalizacoes proibidas)
+
+Se voce se pegar pensando uma dessas, PARE. E o sinal de que esta prestes a furar o gate.
+
+| Voce pensa | Realidade |
+|------------|-----------|
+| "Isso e simples demais pra brainstorm" | O gate nao e opcional. Tier Trivial ja e a saida leve (0 perguntas). Anuncie e siga, mas pelo gate. |
+| "Vou so escrever o codigo, depois explico" | Implementar antes de apresentar o design fura o HARD-GATE. Apresente primeiro. |
+| "Preciso de mais contexto antes de decidir o tier" | Classifique com `classify-task` AGORA. O tier sai dos sinais (nº arquivos, arquitetura, schema/API/auth), nao do seu humor. |
+| "Marco como Trivial pra ir mais rapido" | Se toca schema/API/auth ou >1 subsistema, NAO e Trivial. Rebaixar o tier e furar o gate disfarcado. |
+| "O usuario tem pressa, pulo a aprovacao" | Pressa muda a PROFUNDIDADE (tier), nunca remove a aprovacao. Ate Trivial anuncia antes de agir. |
+| "Ja sei o que ele quer" | Suposicao nao e aprovacao. Em Pequena+, pergunte a decisao-chave. |
+
+A unica forma legitima de ir rapido e o tier Trivial, nao furar o gate.
+
+## Profundidade escalada por tamanho
+
+Classifique a tarefa com o `classify-task` do `up-tools.cjs` (tiers: `simple` / `standard` / `complex`). Heuristica equivalente quando ainda nao ha plano: nº de arquivos provaveis, palavra de arquitetura, toca schema/API/auth.
+
+| Tier | Profundidade |
+|------|--------------|
+| **Trivial** (1 arquivo, sem decisao de arquitetura) | 0 perguntas. Anuncia em 1 linha o que vai fazer e onde. Executa. |
+| **Pequena** (1 subsistema, 1 escolha de design) | 1 pergunta via AskUserQuestion (a decisao-chave) + design em 3 frases. Aprova e segue. |
+| **Media / Grande** (multi-subsistema, toca schema/API/auth) | Brainstorm full. |
+
+## Brainstorm full (media/grande)
+
+1. **Explore o contexto** (arquivos, docs, commits recentes).
+2. **Companion visual:** se o topico tem questao visual (mockup, layout, comparacao), ofereca em mensagem isolada, sozinha. Jonathan e visual: ofereca por default em UI. Metodo de quando/como oferecer e produzir: ver `visual-companion.md` (mesma pasta).
+3. **Perguntas uma por vez.** Multipla escolha preferida. Foco: proposito, restricoes, criterio de sucesso. Se o escopo for multiplos subsistemas independentes, sinalize JA e ajude a decompor em sub-projetos.
+4. **Proponha 2-3 abordagens** com trade-offs e sua recomendacao.
+5. **Apresente o design por SECAO** (arquitetura / componentes / dados / erros / testes), cada secao escalada a complexidade, aprovacao do usuario apos CADA secao.
+6. **Escreva BRIEFING.md** e commite (`docs(brief): <topico>`).
+7. **Self-review do briefing** (inline, sem re-review): caca placeholders (TBD/TODO), contradicoes, escopo amplo demais, ambiguidade. Corrige.
+8. **Gate de revisao humana:** peca ao usuario revisar o BRIEFING.md antes de prosseguir. Espera resposta.
+
+Principios: uma pergunta por vez, multipla escolha, YAGNI sem piedade, sempre alternativas, validacao incremental.
+
+## Estado terminal
+
+Aprovado o design, transicione para o planejamento (`/up:plan`). Nao invoque skill de implementacao direto a partir daqui.

package/up/skills/up-brainstorm/visual-companion.md

@@ -0,0 +1,33 @@
+# Companion visual (brainstorm)
+
+Carregue isto quando o brainstorm tocar em algo visual (UI, layout, fluxo de telas, comparacao de opcoes). O Jonathan e visual: em tarefa de UI, ofereca por DEFAULT.
+
+## Quando oferecer
+
+Ofereca o companion visual se o topico envolve QUALQUER um:
+- aparencia de tela, componente, layout, tema, design system
+- comparar 2-3 opcoes de design lado a lado
+- fluxo de navegacao (onde o usuario clica, pra onde vai)
+- antes/depois de uma mudanca visual
+
+NAO ofereca em: logica pura, schema de banco, API sem UI, script, automacao, glue.
+
+## Como oferecer (regra dura)
+
+O convite vai em UMA mensagem SOZINHA, sem nenhum outro conteudo junto (nem pergunta, nem design, nem codigo). O usuario precisa decidir sobre o visual sem ruido. Exemplo:
+
+> Quer que eu gere um mockup rapido das opcoes de layout antes de a gente decidir? Posso montar 2-3 variacoes pra voce comparar na tela.
+
+Espere a resposta. So depois siga com as perguntas do brainstorm.
+
+## Como produzir o companion
+
+Conforme o caso, do mais leve ao mais pesado:
+1. **ASCII / wireframe em texto** dentro da propria conversa: rapido, zero dependencia, bom pra estrutura e hierarquia.
+2. **Mockup HTML/CSS renderizado** via skill `image-creator` ou `gemini` (quando ja instaladas): bom pra cor, tipografia, sensacao real.
+3. **Referencias da web** via skill `image-fetcher`: quando o usuario quer "algo no estilo de X".
+4. **Comparacao A/B/C:** monte as variacoes lado a lado e peca o usuario escolher por numero (mesma logica de "multipla escolha preferida").
+
+## Depois do visual
+
+A escolha visual do usuario vira uma decisao travada no BRIEFING.md (secao de design/componentes). Os DESIGN-TOKENS extraidos (cores, espacamento, tipografia) alimentam o `up-arquiteto` e, na execucao, o `up-executor` (dominio frontend) e o `up-tester` (passe visual, baseline de consistencia).

package/up/skills/up-tdd/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: up-tdd
+description: "Use ao implementar qualquer feature, ajuste ou bugfix, antes de escrever o codigo de implementacao. A prova exigida varia por tipo de codigo: teste red-green para logica, captura visual para UI, smoke-test para integracao."
+---
+
+# UP TDD por Tipo
+
+A Lei de Ferro real e "evidencia fresca antes de afirmar pronto" (ver `up-verificar-antes-de-concluir`). TDD-unit nao e universal: e UMA forma de prova. O tipo de codigo decide qual prova o gate exige.
+
+Leia o tipo via `classify-task` (`frontmatter_type`, reasons) do `up-tools.cjs`, ou classifique pela natureza da mudanca. Os 3 tipos, a prova de cada e o formato do campo `evidence=<tipo>:<resultado>` estao na ref `tdd-evidence-types` (carregada pelo `up-verificador`). O gate `approvals.log` so passa com a linha do `up-revisor` carregando `evidence=` do tipo certo (`logic:test_pass` | `ui:visual` | `glue:smoke`).
+
+## Logica / parser / calculo / API-propria / bugfix -> red-green-refactor de verdade
+
+**Lei:** NENHUM CODIGO DE PRODUCAO SEM UM TESTE FALHANDO ANTES. Escreveu codigo antes do teste? Delete. Recomece dos testes.
+
+- **RED:** escreva UM teste minimal de um comportamento, codigo real (sem mock salvo inevitavel).
+- **Verifique RED (obrigatorio, nunca pule):** rode o teste. Confirme que FALHA (nao da erro), que a mensagem e a esperada, que falha porque a feature falta. Se voce nao viu o teste falhar, nao sabe se ele testa a coisa certa.
+- **GREEN:** codigo minimo pra passar. Nada de `options?` extra, nada de "melhorar alem do teste". YAGNI.
+- **Verifique GREEN (obrigatorio):** rode, confirme que passa, que os outros testes seguem verdes, saida limpa (zero warnings).
+- **REFACTOR:** so depois do verde. Remove duplicacao, melhora nomes, mantem verde, nao adiciona comportamento.
+- **Bugfix:** escreva o teste que reproduz o bug antes do fix. Regressao: escreve -> roda (passa) -> reverte o fix -> roda (DEVE falhar) -> restaura -> roda (passa).
+
+## UI / CSS -> prova visual obrigatoria
+
+NAO e red-green com mock. A prova e a captura. Tire screenshot ANTES e DEPOIS via Playwright (ou `up-tester`) e compare. "O CSS parece certo" nao prova nada. Sem o antes/depois, o gate nao passa.
+
+## Glue / integracao (Asaas, uazapi, Supabase, Shopify, webhooks) -> smoke-test obrigatorio
+
+Nao da pra red-green de verdade contra dependencia externa. A prova e o smoke-test: rode UMA chamada real (ou contra sandbox) e confirme a resposta esperada. "O endpoint existe" nao prova integracao.
+
+## Common rationalizations (matam o atalho)
+
+- "Testo depois." -> Teste que passa de primeira nao prova nada.
+- "Deletar X horas de codigo e desperdicio." -> Falacia do custo afundado. Codigo nao verificado e divida tecnica.
+- "TDD e dogmatico, estou sendo pragmatico." -> TDD E pragmatico.
+- "Pulo o TDD so dessa vez." -> Isso e racionalizacao. Pare.
+- "Violar a letra da regra e violar o espirito da regra."
+
+Excecoes (so com permissao explicita): prototipo descartavel, codigo gerado, arquivo de config.

package/up/skills/up-verificar-antes-de-concluir/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: up-verificar-antes-de-concluir
+description: "Use quando estiver prestes a afirmar que um trabalho esta completo, corrigido, funcionando ou passando. Exige rodar o comando de prova e confirmar a saida ANTES de qualquer afirmacao de sucesso. Evidencia antes de afirmacao, sempre."
+---
+
+# UP Verificar Antes de Concluir
+
+**Lei de Ferro:** NENHUMA AFIRMACAO DE CONCLUSAO SEM EVIDENCIA FRESCA NESTA MENSAGEM.
+
+Se voce nao rodou o comando de prova NESTA mensagem, voce nao pode afirmar que passa. Afirmar conclusao sem verificar e desonestidade, nao eficiencia.
+
+## A funcao de gate
+
+Antes de afirmar qualquer status ou expressar satisfacao:
+
+1. **IDENTIFIQUE:** qual comando prova essa afirmacao?
+2. **RODE:** execute o comando COMPLETO (fresco, inteiro).
+3. **LEIA:** saida inteira, exit code, conte as falhas.
+4. **VERIFIQUE:** a saida confirma a afirmacao?
+5. **SO ENTAO:** faca a afirmacao.
+
+Pulou um passo = mentir, nao verificar.
+
+## Afirmacao -> exige -> nao basta
+
+| Afirmacao | Exige | NAO basta |
+|-----------|-------|-----------|
+| "Testes passam" | Saida do comando: 0 falhas | "rodou antes" / "deveria passar" |
+| "Bug corrigido" | Repro falha antes, passa depois | "mudei a linha certa" |
+| "UI ajustada" | Captura visual depois (Playwright) | "o CSS parece certo" |
+| "Integracao funciona" | Smoke-test com resposta real | "o endpoint existe" |
+| "Subagente concluiu" | Diff do VCS mostra as mudancas | "o agente relatou sucesso" |
+| "Pronto" | Todas as provas acima do tipo certo | satisfacao |
+
+Confie no diff do VCS, nao no relatorio. Subagente terminou rapido demais? Inspecione o codigo de verdade.
+
+A prova exigida por tipo (logic=teste red-green / ui=captura / glue=smoke) e o campo `evidence=<tipo>:<resultado>` que o gate de fase le no `approvals.log` estao na ref `tdd-evidence-types`. O `up-revisor` so APROVA com a `evidence=` do tipo certo logada.
+
+## Red flags (racionalizacoes que matam o atalho)
+
+- "Isso e obviamente certo, nao preciso rodar." -> Rode.
+- "Ja rodei algo parecido antes." -> Saida antiga nao prova esta mudanca.
+- "Vou expressar satisfacao" ("Otimo!", "Perfeito!", "Pronto!") antes de verificar. -> PARE. Verifique primeiro.
+- "E so um ajuste pequeno." -> Pequeno tambem quebra. Prove.
+- "Violar a letra da regra e violar o espirito da regra." Nao ha "estou seguindo o espirito".
+
+## Cultura anti-bajulacao
+
+Honestidade e valor central. Proibido bajular ("voce tem toda razao", "otimo ponto") ou agradecer feedback antes de verifica-lo contra o codebase. Acao fala: declare a correcao, nao o agradecimento. Se um review aponta erro, cheque se e tecnicamente correto PARA ESTE codebase antes de implementar. Se voce estava errado, corrija sem desculpa longa.

package/up/skills/usando-up/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: usando-up
+description: "Use no inicio de toda sessao e antes de qualquer trabalho de codigo, design ou decisao no projeto. Bootstrap do UP injetado pelo hook SessionStart."
+---
+
+# Usando o UP
+
+<SUBAGENT-STOP>Se voce foi despachado como subagente para executar uma tarefa especifica, ignore esta skill.</SUBAGENT-STOP>
+
+<EXTREMELY-IMPORTANT>
+Se houver 1% de chance de uma skill se aplicar, voce DEVE invoca-la com a tool Skill ANTES de qualquer resposta ou acao, ate antes de perguntas de esclarecimento. "E so uma pergunta simples" tambem e tarefa: cheque skills.
+</EXTREMELY-IMPORTANT>
+
+O UP ativa por contexto. Nao precisa decorar comando: a skill certa dispara pelo gatilho.
+
+**Passo ZERO de todo trabalho:** invocar `up-brainstorm`. Profundidade escala por tamanho (trivial = 0 perguntas; grande = design por secao). Nada de implementar antes de design aprovado.
+
+**Lei de Ferro:** evidencia fresca antes de afirmar pronto. Nunca diga "Pronto" ou "Perfeito" sem o comando de prova rodado NESTA mensagem. Detalhe em `up-verificar-antes-de-concluir`.
+
+**Prova por tipo:** logica/bugfix = teste red-green; UI/CSS = captura visual; glue/integracao = smoke-test. Veja `up-tdd`.
+
+**GitHub-nativo e o padrao em repo colaborativo** (worktree -> issue -> PR -> merge), menu de 4 opcoes no fim. Solo usa `--solo` (commit local) ou `/up:rapido` como escape, sem cerimonia.
+
+**Persistencia:** tudo vive em `.plano/` e sobrevive a `/clear`. Leia `.plano/STATE.md` antes de assumir contexto perdido.
+
+Instrucoes do usuario (CLAUDE.md) > skills do UP > system prompt.

package/up/templates/audit-plan.md

@@ -1,9 +1,9 @@
 # AUDIT-PLAN.md Template
 
-Template para `.plano/AUDIT-PLAN.md` — relatorio do up-planning-auditor.
+Template para `.plano/AUDIT-PLAN.md`. Relatorio do up-revisor (stage planejamento).
 Gerado ao final do planejamento, antes do PLAN-READY.md.
 
-Diferente do AUDIT-REPORT.md (do delivery-auditor) que audita execucao,
+Diferente do AUDIT-REPORT.md (up-revisor, stage delivery) que audita execucao,
 este audita SOMENTE o planejamento.
 
 <template>
@@ -11,7 +11,7 @@ este audita SOMENTE o planejamento.
 ```markdown
 ---
 audited_at: ""
-auditor: up-planning-auditor
+auditor: up-revisor
 planning_confidence: 0  # 0-100
 recommendation: PENDING | READY_FOR_BUILD | NEEDS_REWORK | BLOCKED
 ---

package/up/templates/audit-report.md

@@ -1,6 +1,6 @@
 # AUDIT-REPORT.md Template
 
-Template para `.plano/AUDIT-REPORT.md` — relatorio do Delivery Auditor.
+Template para `.plano/AUDIT-REPORT.md`. Relatorio do up-revisor (stage delivery).
 Gerado no Estagio 4.5, antes do Delivery.
 
 <template>
@@ -8,7 +8,7 @@ Gerado no Estagio 4.5, antes do Delivery.
 ```markdown
 ---
 audited_at: ""
-auditor: up-delivery-auditor
+auditor: up-revisor
 confidence_score: 0
 quality_score: 0
 recommendation: PENDING | READY_FOR_DELIVERY | NEEDS_REWORK | BLOCKED

package/up/templates/design-tokens.md

@@ -1,7 +1,7 @@
 # Design Tokens — {PROJECT_NAME}
 
-Referencia visual do projeto. Gerado pelo up-system-designer durante o Estagio 2 (Arquitetura).
-Usado pelo up-visual-critic como baseline para avaliar consistencia visual.
+Referencia visual do projeto. Gerado pelo up-arquiteto durante a fase de arquitetura.
+Usado pelo up-tester (passe visual) como baseline para avaliar consistencia visual.
 
 ---
 

package/up/workflows/auditar.md

@@ -0,0 +1,255 @@
+<purpose>
+Workflow `/up:auditar` — Auditoria priorizada de produto num passe unico.
+
+Funde melhorias.md + ideias.md. Spawna `up-auditor` (1x, passe unico de UX + performance + modernidade)
+e `up-sintetizador` (consolida, dedup, prioriza). Com `--features`, tambem spawna `up-pesquisador`
+modo mercado pra sugerir features novas (analise de gaps + concorrentes/tendencias).
+
+Standalone: nao requer projeto UP inicializado.
+</purpose>
+
+<core_principle>
+Antes eram 3 auditores (ux/perf/modernidade) + 1 sintetizador-melhorias para `/up:melhorias`, e
+analista-codigo + pesquisador-mercado + consolidador-ideias para `/up:ideias`. Agora:
+- `up-auditor` faz o passe unico das 3 dimensoes (carrega as refs audit-ux/audit-performance/audit-modernidade
+  sob demanda) e, com `--features`, tambem analisa gaps funcionais.
+- `up-pesquisador` (modo mercado) so entra com `--features` pra trazer evidencia de mercado.
+- `up-sintetizador` consolida tudo: dedup cross-dimensao, matriz esforco x impacto (melhorias),
+  ICE scoring + anti-features (features), sumario opinativo.
+
+Relatorio e informativo. NAO commitar automaticamente. NAO mexer em STATE.md (auditoria e standalone).
+</core_principle>
+
+<process>
+
+## Passo 1: Inicializar e carregar contexto
+
+```bash
+INIT=$(node "$HOME/.claude/up/bin/up-tools.cjs" init auditar)
+if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
+```
+
+Parse JSON: `planning_exists`, `has_claude_md`, `has_package_json`, `date`, `timestamp`,
+`commit_docs`, `stack_hints`.
+
+**Detectar flag `--features`** no $ARGUMENTS (ativa o modo de ideacao de features).
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ UP > AUDITORIA DE PRODUTO
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Passo 2: Setup standalone
+
+```bash
+mkdir -p .plano/auditar
+```
+
+Se `.plano/auditar/RELATORIO.md` ja existe: perguntar via AskUserQuestion se sobrescreve ou cancela.
+Se cancelar: sair mantendo o relatorio anterior.
+
+Reportar a stack detectada (de `stack_hints`): framework frontend, meta-framework, CSS, ORM, TypeScript.
+Se `has_package_json` = false: avisar que o auditor vai detectar a stack por outros sinais.
+
+## Passo 3: Spawn do auditor (passe unico)
+
+Spawnar `up-auditor` 1x. Ele cobre UX + performance + modernidade num passe (e gaps funcionais se `--features`).
+
+```
+Task(
+  subagent_type="up-auditor",
+  description="Auditoria de produto (passe unico)",
+  prompt="
+<objective>
+Auditar o produto num passe unico nas dimensoes UX, performance e modernidade. Mapa de cobertura
+obrigatorio. Salvar resultado por dimensao.
+{Se --features: tambem mapear gaps funcionais e oportunidades de features novas no codebase.}
+</objective>
+
+<files_to_read>
+- ./CLAUDE.md (se existir)
+</files_to_read>
+
+<constraints>
+- Carregar sob demanda: $HOME/.claude/up/references/audit-ux.md,
+  $HOME/.claude/up/references/audit-performance.md, $HOME/.claude/up/references/audit-modernidade.md
+- Carregar template: $HOME/.claude/up/templates/suggestion.md
+- Detectar a stack (primeiro passo)
+- Produzir sugestoes UX-NNN, PERF-NNN, MOD-NNN no formato do template, com mapa de cobertura
+- {Se --features: produzir IDEA-NNN para gaps funcionais com Dimensao=Ideias}
+- Salvar em:
+  - .plano/auditar/ux-sugestoes.md
+  - .plano/auditar/performance-sugestoes.md
+  - .plano/auditar/modernidade-sugestoes.md
+  {Se --features: .plano/auditar/gaps-sugestoes.md}
+- Retornar resumo no formato: ## AUDITORIA COMPLETA (com contagem por dimensao e cobertura)
+</constraints>
+"
+)
+```
+
+## Passo 3b: Pesquisa de mercado (SO com --features)
+
+Se `--features` estiver presente, spawnar `up-pesquisador` modo mercado EM PARALELO com nada
+(ja que o auditor ja rodou; pode rodar logo apos, ou junto se preferir 1 mensagem com os dois Task).
+
+```
+Task(
+  subagent_type="up-pesquisador",
+  description="Pesquisa de mercado para features",
+  prompt="
+<modo>mercado</modo>
+<objective>
+Pesquisar concorrentes e tendencias de mercado pra sugerir features novas para este projeto.
+Salvar em .plano/auditar/mercado-sugestoes.md
+</objective>
+
+<files_to_read>
+- ./CLAUDE.md, ./README.md, ./package.json (se existirem -- dominio e dependencias)
+</files_to_read>
+
+<constraints>
+- Carregar template: $HOME/.claude/up/templates/suggestion.md
+- Entender o dominio, pesquisar concorrentes e tendencias via WebSearch
+- Cada sugestao IDEA-NNN com evidencia de mercado (concorrente ou tendencia)
+- Sinalizar LOW confidence quando baseado so em dados de treinamento
+- Limitar a 10-15 sugestoes
+- Retornar resumo no formato: ## PESQUISA DE MERCADO COMPLETA
+</constraints>
+"
+)
+```
+
+## Passo 4: Verificar resultados
+
+Confirmar que os arquivos de sugestoes foram criados (ux/performance/modernidade sempre;
+gaps + mercado so com `--features`). Se algum faltar, reportar qual passo falhou e seguir com os
+disponiveis (o sintetizador aceita subconjunto).
+
+```
+## Resultados
+
+| Dimensao | Sugestoes | Cobertura | Status |
+|----------|-----------|-----------|--------|
+| UX | N | X/Y (Z%) | Completo |
+| Performance | N | X/Y (Z%) | Completo |
+| Modernidade | N | X/Y (Z%) | Completo |
+[se --features] | Gaps/Features | N | - | Completo |
+```
+
+## Passo 5: Spawn do sintetizador (consolida)
+
+Spawnar `up-sintetizador` SEQUENCIALMENTE (apos confirmar os arquivos).
+
+```
+Task(
+  subagent_type="up-sintetizador",
+  description="Consolidar auditoria",
+  prompt="
+<modo>auditoria</modo>
+<objective>
+Consolidar as sugestoes em relatorio unico. Deduplicar cross-dimensao, detectar conflitos,
+classificar melhorias na matriz esforco x impacto (4 quadrantes).
+{Se --features: aplicar ICE scoring as features e gerar anti-features (ceil(positivas/3)).}
+Salvar em .plano/auditar/RELATORIO.md
+</objective>
+
+<files_to_read>
+- .plano/auditar/ux-sugestoes.md
+- .plano/auditar/performance-sugestoes.md
+- .plano/auditar/modernidade-sugestoes.md
+{Se --features:}
+- .plano/auditar/gaps-sugestoes.md
+- .plano/auditar/mercado-sugestoes.md
+- ./CLAUDE.md (se existir)
+</files_to_read>
+
+<constraints>
+- Carregar templates: $HOME/.claude/up/templates/report.md e $HOME/.claude/up/templates/suggestion.md
+- Dedup cross-dimensao (mesmo arquivo, linhas sobrepostas, problema similar)
+- Melhorias: renumerar para MELH-NNN, classificar nos 4 quadrantes
+- {Features: ICE scoring por feature, anti-features, ranking por ICE decrescente, IDs IDEA-NNN}
+- Sumario executivo OPINATIVO (por onde comecar; top features se --features)
+- Salvar em .plano/auditar/RELATORIO.md
+- Retornar resumo no formato: ## SINTESE COMPLETA
+</constraints>
+"
+)
+```
+
+Confirmar que `.plano/auditar/RELATORIO.md` existe. Se nao, erro: "Sintetizador falhou ao criar RELATORIO.md".
+
+## Passo 6: Apresentar relatorio
+
+Ler `.plano/auditar/RELATORIO.md` e exibir:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ UP > AUDITORIA COMPLETA
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+[Sumario Executivo -- 2-3 paragrafos opinativos]
+
+## Visao Geral
+[Tabela de visao geral do relatorio]
+
+## Distribuicao (melhorias)
+| Quadrante | Total |
+|-----------|-------|
+| Quick Wins | N |
+| Projetos Estrategicos | N |
+| Preenchimentos | N |
+| Evitar | N |
+
+[Se --features:]
+## Top Features por ICE Score
+| # | Feature | ICE | Categoria |
+|---|---------|-----|-----------|
+| 1 | IDEA-NNN: [titulo] | NNN | must-have/performance/delighter |
+
+## Anti-Features
+[Total] features que NAO devem ser implementadas
+
+## Proximos Passos
+[Secao do relatorio]
+
+───────────────────────────────────────────────────────────────
+Relatorio: .plano/auditar/RELATORIO.md
+───────────────────────────────────────────────────────────────
+```
+
+**NAO commitar automaticamente. NAO atualizar STATE.md.**
+
+## Passo 7: Integracao com roadmap (opcional)
+
+Perguntar via AskUserQuestion se quer converter sugestoes/features aprovadas em fases no ROADMAP.md.
+
+Se sim:
+1. Extrair os IDs do RELATORIO.md (`### (MELH-\d+):` para melhorias; `### (IDEA-\d+):` para features,
+   excluindo a secao "## Anti-Features").
+2. Apresentar para selecao multipla (Quick Wins / maior ICE primeiro; nunca incluir quadrante "Evitar"
+   nem anti-features).
+3. Se nao houver `.plano/ROADMAP.md`, perguntar se cria um minimo.
+4. Gerar fases:
+
+```bash
+echo '{"source":"auditar","report_path":".plano/auditar/RELATORIO.md","approved_ids":["MELH-001","IDEA-003"],"grouping":"auto"}' | node "$HOME/.claude/up/bin/up-tools.cjs" phase generate-from-report
+```
+
+Substituir `approved_ids` pela selecao real. Apresentar resumo das fases criadas e os proximos passos
+(`/up:plan {N}` para planejar, `/up:build` para executar).
+
+</process>
+
+<success_criteria>
+- [ ] Init auditar retornou JSON valido; flag --features detectada
+- [ ] Diretorio .plano/auditar/ criado (standalone)
+- [ ] up-auditor rodou o passe unico (UX + performance + modernidade; + gaps se --features)
+- [ ] Com --features: up-pesquisador modo mercado rodou
+- [ ] Pelo menos 1 arquivo de sugestoes gerado
+- [ ] up-sintetizador gerou RELATORIO.md (matriz; + ICE/anti-features se --features)
+- [ ] Relatorio apresentado; NAO commitado; STATE.md intocado
+- [ ] Integracao com roadmap oferecida (opcional)
+</success_criteria>
+</output>