up-cc 0.5.2 → 0.7.0

package/package.json

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

package/references/engineering-principles-compressed.md

@@ -0,0 +1,26 @@
+# Engineering Principles (compressed)
+
+> Versao compactada para injecao inline em prompts. ~400 tokens vs 2.5k da versao completa.
+> Versao completa em `engineering-principles.md` — Read sob demanda se precisar de exemplos detalhados.
+
+## 6 Principios
+
+1. **Implementacao real, nao simulacao** — Zero `onClick={() => {}}`, zero placeholder, zero API que retorna `{ok: true}` estatico, zero `useState([])` sem setter, zero imports nao usados. Se nao pode implementar agora: declare explicitamente como debito tecnico.
+
+2. **Correto, nao rapido** — Tipagem explicita (sem `any`). Validacao com lib (zod/yup). Queries parametrizadas. `===` nao `==`. `crypto.randomUUID()` nao `Math.random()`. `structuredClone` nao `Object.assign` raso.
+
+3. **Conectado de ponta a ponta** — Componente → rota navegavel. API → frontend chama + trata response. Schema → migration rodada. Validacao → form aplica + feedback visivel. "Arquivo existe" ≠ "funciona". Usuario consegue usar no browser.
+
+4. **Consistencia sobre criatividade** — Antes de implementar: `grep` por pattern similar no codebase. Se React Query existe, use `useQuery`. Se Button component existe, use `<Button>`. Se Tailwind, use classes. Nao invente patterns paralelos.
+
+5. **Dados reais desde o primeiro momento** — Banco real com seed > API real > mock temporario removido > hardcoded (PROIBIDO). Se banco existe, conecte desde o primeiro componente. Mock so em testes automatizados.
+
+6. **Cada decisao tem custo futuro** — Sem tipagem = bugs silenciosos. Sem pagination = trava com 10k items. Sem error handling = crash cego. Sem indices = queries lentas. Custo de fazer certo e linear, refatorar e exponencial.
+
+## Aplicacao
+
+- Antes de cada tarefa: reler mentalmente os 6
+- Durante: checar cada decisao contra a lista
+- Antes de commit: self-review rapido
+- No SUMMARY: documentar violacoes como debito tecnico
+- Para exemplos detalhados: `Read references/engineering-principles.md`

package/references/governance-rules-compressed.md

@@ -0,0 +1,31 @@
+# Governance Rules (compressed)
+
+> Versao compactada para injecao inline. ~250 tokens vs 1.9k da versao completa.
+> Versao completa em `governance-rules.md` — Read sob demanda para hierarquia detalhada.
+
+## Hierarquia
+DONO → CEO → 5 Chiefs → 8 Supervisores → 36 Operacionais
+
+## Decisoes do Supervisor (apos cada operacional)
+- **APPROVE** — criterios atendidos, sem issues criticas, evidencia clara
+- **REQUEST_CHANGES** — 1+ criterio falhou, feedback especifico e acionavel
+- **ESCALATE** — fora do escopo, decisao arquitetural ou conflito → chief
+
+## Decisoes do Chief (apos area completa)
+- APPROVE | REQUEST_CHANGES (volta pro supervisor) | ESCALATE pro CEO
+
+## Decisoes do CEO (antes de delivery)
+- APPROVE_DELIVERY | ALERTA_DONO | REWORK (volta pro chief)
+
+## Anti-patterns (NUNCA aprovar se)
+- Trabalho nao foi de fato verificado ("parece ok")
+- Evidencia faltando ou ambigua
+- SUMMARY claim sem backing no codigo
+- Rework cycle no max sem melhoria
+- Stub/placeholder em vez de implementacao real
+- Falta de wiring (componente criado mas nao conectado)
+
+## Logging obrigatorio
+Toda decisao em `.plano/governance/approvals.log | reworks.log | escalations.log`.
+
+Para detalhes de poderes especificos por nivel: `Read references/governance-rules.md`

package/references/production-requirements-compressed.md

@@ -0,0 +1,23 @@
+# Production Requirements (compressed)
+
+> Versao compactada para injecao inline. ~300 tokens vs 1.3k da versao completa.
+> Versao completa em `production-requirements.md` — Read sob demanda para checklist completo (60+ itens).
+
+## Categorias e contagem (cada item tem ID)
+- **UIST** (8) — UI States: loading/error/empty/success, disabled, optimistic, confirm destrutivo
+- **ERR** (8) — Error handling: boundaries, try/catch, sessao expirada, 404, offline, server-side validation
+- **PERF** (9) — Performance: lazy loading, code split, debounce, pagination, cache, memo, prefetch
+- **FORM** (8) — Forms: inline validation, mensagens especificas, autofocus, tab order, defaults, mascaras
+- **RESP** (7) — Responsividade: 375px funcional, touch 44x44, hamburger mobile, modais fullscreen
+- **META** (7) — Meta/SEO: title unico, og tags, favicon, manifest, canonical, robots
+- **A11Y** (9) — Acessibilidade: alt, labels, focus visible, keyboard, aria, contraste 4.5:1, landmarks
+- **SEC** (8) — Seguranca: rotas protegidas, CSRF, XSS, rate limit, headers, UUID, env vars, RLS
+- **POLISH** (7) — Visual: hover, transicoes 150-300ms, escala espacamento, design tokens, dark mode
+
+## Total: 71 requisitos de producao em 9 categorias
+
+Quando precisar de IDs especificos ou descricao detalhada de um item:
+`Read references/production-requirements.md` e procure pela categoria.
+
+Arquiteto/system-designer injetam estes requisitos automaticamente no REQUIREMENTS.md.
+Supervisores validam contra eles antes de approval.

package/references/rework-limits-compressed.md

@@ -0,0 +1,22 @@
+# Rework Limits (compressed)
+
+> Versao compactada para injecao inline. ~150 tokens vs 2k da versao completa.
+> Versao completa em `rework-limits.md` — Read sob demanda para fluxos detalhados.
+
+## Limites por nivel
+| Nivel | Max Ciclos | Apos limite |
+|---|---|---|
+| Operacional ← Supervisor | **3** | Forca approval, marca como debito tecnico |
+| Supervisor ← Chief | **2** | Escalacao pro CEO |
+| Chief ← CEO | **1** | CEO decide: aceitar ou alertar dono |
+
+## Quando forcar aprovacao (apos max ciclos)
+- Melhoria entre ciclos < 10% (diminishing returns)
+- Issue nao pode ser resolvida sem info externa
+- Acao: registrar em `governance/technical-debt.log`, marcar item como `completed_with_debt`
+
+## Rework rate saudavel: 15-30%
+- < 5% = supervisor mal calibrado, aprovando sem criterio
+- > 40% = prompt vago ou criterios muito rigidos
+
+Para fluxos completos por ciclo: `Read references/rework-limits.md`

package/templates/audit-plan.md

@@ -0,0 +1,139 @@
+# AUDIT-PLAN.md Template
+
+Template para `.plano/AUDIT-PLAN.md` — relatorio do up-planning-auditor.
+Gerado ao final do planejamento, antes do PLAN-READY.md.
+
+Diferente do AUDIT-REPORT.md (do delivery-auditor) que audita execucao,
+este audita SOMENTE o planejamento.
+
+<template>
+
+```markdown
+---
+audited_at: ""
+auditor: up-planning-auditor
+planning_confidence: 0  # 0-100
+recommendation: PENDING | READY_FOR_BUILD | NEEDS_REWORK | BLOCKED
+---
+
+# Planning Audit Report
+
+**Planning Confidence Score:** {N}/100
+
+**Recomendacao:** {status}
+
+---
+
+## Completude por Estagio
+
+| Estagio | Items | Completed | Missing | Score |
+|---------|-------|-----------|---------|-------|
+| Intake (E1) | 5 | {N} | {N} | {%} |
+| Arquitetura (E2) | 7 | {N} | {N} | {%} |
+| Planejamento (E2.5) | {6 × phases} | {N} | {N} | {%} |
+| **TOTAL** | **{N}** | **{N}** | **{N}** | **{%}** |
+
+---
+
+## Validacao de Completude
+
+### Artefatos Arquiteturais
+
+- [ ] BRIEFING.md existe
+- [ ] OWNER.md existe
+- [ ] PROJECT.md existe e completo
+- [ ] ROADMAP.md existe e tem fases
+- [ ] REQUIREMENTS.md existe
+- [ ] SYSTEM-DESIGN.md existe e completo
+- [ ] DESIGN-TOKENS.md existe (se projeto com UI)
+- [ ] PENDING.md existe (mesmo se vazio)
+
+### Planos por Fase
+
+Para cada fase em ROADMAP.md:
+- [ ] Existe pasta `.plano/fases/XX-nome/`
+- [ ] Existe pelo menos 1 PLAN.md
+- [ ] Cada PLAN.md tem frontmatter valido
+- [ ] Cada PLAN.md tem 5-8 tarefas
+- [ ] Cada PLAN.md tem must_haves
+- [ ] Cada PLAN.md passou no planning-supervisor (PLAN-REVIEW.md existe)
+
+### Cobertura de Requisitos
+
+| REQ-ID | Mapeado a fase? | Coberto por plano? | Status |
+|--------|----------------|-------------------|--------|
+| AUTH-01 | Sim (Fase 1) | Sim (01-01-PLAN) | OK |
+| ... | | | |
+
+**Cobertura:** {covered}/{total} ({%})
+
+### Sonnet-readiness
+
+Para cada PLAN.md, checar nivel de detalhe:
+
+| Plan | Imports | Tipos | Endpoints | SQL | Score |
+|------|---------|-------|-----------|-----|-------|
+| 01-01-PLAN.md | ✓ | ✓ | ✓ | N/A | 100% |
+| 01-02-PLAN.md | ✓ | ✓ | ✓ | ✓ | 100% |
+
+**Score medio Sonnet-ready:** {%}
+
+### Dependency Graph
+
+- [ ] Todas dependencias entre planos resolvidas
+- [ ] Sem ciclos detectados
+- [ ] Waves atribuidas (0, 1, 2, 3)
+- [ ] Paralelismo maximizado onde possivel
+
+---
+
+## Aprovacoes Faltantes
+
+| Item | Esperado | Atual |
+|------|----------|-------|
+| [item] | [supervisor] APPROVE | pending/missing |
+
+---
+
+## Inconsistencias Detectadas
+
+### INC-001: [Titulo]
+**Tipo:** [conflito | gap | duplicacao]
+**Descricao:** [...]
+**Acao sugerida:** [...]
+
+---
+
+## Pendencias Conhecidas
+
+Da PENDING.md:
+- {N} blockers
+- {N} non-blockers
+
+Estas pendencias NAO bloqueiam o planejamento, mas serao revistas no delivery.
+
+---
+
+## Veredito
+
+**{READY_FOR_BUILD | NEEDS_REWORK | BLOCKED}**
+
+[Justificativa em 1-2 paragrafos]
+
+### Rework Plan (se NEEDS_REWORK)
+
+1. [acao 1]
+2. [acao 2]
+3. [acao 3]
+
+Apos rework, re-rodar auditor.
+
+### Pronto pra Build (se READY_FOR_BUILD)
+
+Proximos passos:
+1. Gerar PLAN-READY.md
+2. Apresentar ao dono via CEO
+3. Aguardar `/up:build` (mesmo runtime ou outro)
+```
+
+</template>

package/templates/builder-defaults.md

@@ -35,26 +35,15 @@ 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).
+## Modelos
+
+**v0.6.0+: Removido.** O runtime que voce usa decide o modelo.
+
+- Em Claude Code: usa o modelo selecionado via /model (default Opus 4.6)
+- Em OpenCode: usa o modelo do opencode.json
+- Em Gemini CLI: usa o modelo do runtime
+
+Planos sao sempre gerados em nivel detalhado (Sonnet-ready) independente do modelo executor.
 
 ## Nao usar
 - (liste aqui tecnologias que voce NAO quer em nenhum projeto)

package/templates/plan-ready.md

@@ -0,0 +1,137 @@
+# PLAN-READY.md Template
+
+Template para `.plano/PLAN-READY.md` — arquivo-flag que indica que o projeto foi
+completamente planejado e esta pronto para execucao.
+
+Gerado por `/up:plan` ao final do planejamento.
+Lido por `/up:build` como gate de entrada.
+
+<template>
+
+```yaml
+---
+version: "0.6.0"
+planned_at: ""
+planned_by:
+  runtime: ""           # claude-code | opencode | gemini-cli
+  ceo_name: ""
+  user_preferred_name: ""
+intended_execution:
+  runtime: ""           # same | claude-code | opencode | gemini-cli | any
+project_name: ""
+mode: ""                # greenfield | brownfield
+total_phases: 0
+total_plans: 0
+total_requirements: 0
+estimated_tasks: 0
+status: ready_for_execution
+planning_confidence: 0  # 0-100, do AUDIT-PLAN.md
+---
+
+# Projeto Pronto Para Execucao
+
+Este projeto foi completamente planejado. Todos os artefatos arquiteturais
+foram gerados, todas as fases foram planejadas em detalhe maximo (Sonnet-ready),
+e todas as aprovacoes de supervisores/chiefs foram obtidas.
+
+## Como executar
+
+```
+/up:build
+```
+
+Pode ser executado neste mesmo runtime ou em outro. O estado esta completamente
+salvo em `.plano/`.
+
+## Resumo do Projeto
+
+**Briefing:** [resumo em 1-2 frases do BRIEFING.md]
+
+**Stack:** [stack escolhida]
+
+**Mode:** [greenfield | brownfield]
+
+## Fases Planejadas
+
+| # | Fase | Planos | Tarefas | Wave | Status |
+|---|------|--------|---------|------|--------|
+| 1 | [nome] | [N] | [M] | 0 | planejada |
+| 2 | [nome] | [N] | [M] | 1 | planejada |
+| 3 | [nome] | [N] | [M] | 1 | planejada |
+
+## Aprovacoes Obtidas
+
+Todas estas aprovacoes foram registradas em governance/approvals.log:
+
+- [x] CEO: Briefing aprovado, intake completo
+- [x] Chief-architect: Arquitetura aprovada
+- [x] Chief-product: Fit com briefing confirmado
+- [x] Architecture-supervisor: PROJECT, ROADMAP, SYSTEM-DESIGN, REQUIREMENTS aprovados
+- [x] Planning-supervisor: Todos planos aprovados
+- [x] Chief-engineer: Planejamento consistente cross-fase
+- [x] Planning-auditor: Confidence score [N]/100
+
+## Artefatos Disponiveis
+
+```
+.plano/
+├── BRIEFING.md
+├── OWNER.md
+├── PENDING.md
+├── DESIGN-TOKENS.md
+├── PRODUCT-ANALYSIS.md
+├── SYSTEM-DESIGN.md
+├── PROJECT.md
+├── ROADMAP.md
+├── REQUIREMENTS.md
+├── AUDIT-PLAN.md           ← relatorio do planning auditor
+├── CHECKLIST.md
+├── PLAN-READY.md           ← este arquivo
+└── fases/
+    ├── 01-[nome]/
+    │   ├── 01-01-PLAN.md
+    │   ├── 01-01-PLAN-REVIEW.md
+    │   └── 01-02-PLAN.md
+    ├── 02-[nome]/
+    └── ...
+```
+
+## Credenciais
+
+- [x] [credencial 1]
+- [ ] [credencial pendente] (mock ativo)
+- [ ] [credencial pendente] (mock ativo)
+
+Ver `.plano/PENDING.md` para detalhes.
+
+## Listagem Completa de Planos
+
+[lista de todos os PLANs com seus paths, para o /up:build validar que existem]
+
+| ID | Path | Wave | Tasks |
+|----|------|------|-------|
+| 01-01 | fases/01-auth/01-01-PLAN.md | 0 | 8 |
+| 01-02 | fases/01-auth/01-02-PLAN.md | 1 | 7 |
+...
+```
+
+</template>
+
+<guidelines>
+
+## Como o /up:build usa este arquivo
+
+1. Gate de entrada: arquivo deve existir
+2. Parse YAML frontmatter
+3. Para cada plano listado, verificar se arquivo existe no disco
+4. Se algum plano falta: alertar e oferecer planejamento local
+5. Se tudo OK: prosseguir com execucao
+
+## Quando este arquivo e atualizado
+
+- Criado: ao final de `/up:plan`
+- Lido: no inicio de `/up:build`
+- Atualizado: nunca (e snapshot do planejamento)
+- Deletado: ao final do `/up:build` (vira PROJECT-COMPLETE.md)
+
+</guidelines>