up-cc 2.0.0 → 2.0.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "up-cc",
-  "version": "2.0.0",
+  "version": "2.0.2",
   "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,23 @@ 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. |
+| "Design aprovado, agora vou codar/criar a fundacao" | NAO. Projeto/feature: o estado terminal e `/up:plan`, nunca implementacao direta. Registre BRIEFING/PROJECT, entregue o handoff e PARE. |
+| "Vou so deixar o scaffold pronto enquanto isso" | Scaffold E implementacao. Sem `.plano/PLAN-READY.md`, nada de codigo/estrutura. |
+
+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 +41,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.
@@ -34,6 +51,8 @@ Classifique a tarefa com o `classify-task` do `up-tools.cjs` (tiers: `simple` /
 
 Principios: uma pergunta por vez, multipla escolha, YAGNI sem piedade, sempre alternativas, validacao incremental.
 
-## Estado terminal
+## Estado terminal (regra dura)
+
+Aprovado o design de um PROJETO ou FEATURE, o estado terminal e `/up:plan` (gera `.plano/PLAN-READY.md`). Voce NAO escreve codigo, NAO cria fundacao, NAO faz scaffold a partir daqui: registra os artefatos (BRIEFING/PROJECT), entrega o handoff e PARA. Quem implementa e o `/up:build`, e so depois que existe `PLAN-READY.md`.
 
-Aprovado o design, transicione para o planejamento (`/up:plan`). Nao invoque skill de implementacao direto a partir daqui.
+Excecao unica: tarefa Trivial pontual declarada via `/up:rapido` pode ir direto, sem plan. Projeto/feature nao-trivial, nunca.

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/usando-up/SKILL.md

@@ -15,6 +15,8 @@ O UP ativa por contexto. Nao precisa decorar comando: a skill certa dispara pelo
 
 **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.
 
+**Fluxo obrigatorio para PROJETO ou FEATURE (nao-trivial):** brainstorm -> `/up:plan` (gera `.plano/PLAN-READY.md`) -> `/up:build` (executa). Depois do design aprovado voce NAO comeca a codar nem a criar fundacao/scaffold direto: registra os artefatos (BRIEFING/PROJECT) e PARA, entregando o handoff para `/up:plan`. Planejar e um passo separado e obrigatorio, nao opcional. Pular o plan so e permitido em tarefa pontual declarada via `/up:rapido`. Se nao tem `.plano/PLAN-READY.md`, voce ainda nao pode buildar.
+
 **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`.