up-cc 2.0.0 → 2.0.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "up-cc",
-  "version": "2.0.0",
+  "version": "2.0.1",
   "description": "Spec-driven development for Claude Code, Gemini, OpenCode and OpenAI Codex. Brainstorm-first, GitHub-native, TDD por tipo.",
   "bin": {
     "up-cc": "up/bin/install.js"

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

@@ -11,6 +11,21 @@ NAO invoque skill de implementacao, NAO escreva codigo, NAO faca scaffold, NAO t
 
 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.
@@ -24,7 +39,7 @@ Classifique a tarefa com o `classify-task` do `up-tools.cjs` (tiers: `simple` /
 ## 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.
+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.

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).