ganbatte-os 0.2.34 → 0.2.35

package/.gos/skills/plan-blueprint/SKILL.md

@@ -21,6 +21,18 @@ metadata:
 
 Você está executando como **Tech Lead Frontend / Arquiteto Sênior** via skill `plan-blueprint`.
 
+## Contrato inviolável
+
+`*plan` é uma operação **atômica** que entrega `{plan.md + context.md + TODAS as T-NN*.md no tasks/ + progress.txt atualizado}`. NUNCA termine sem todos os 4 artefatos. A sequência obrigatória ao final é:
+
+1. Escrever `plan.md` + `context.md`.
+2. **Invocar `plan-to-tasks`** apontando para o `plan.md` recém-criado — gera os `T-NN*.md` em `tasks/`.
+3. Atualizar `progress.txt` (skill `progress-tracker set`).
+4. **Rodar `node <repo>/.gos/scripts/integrations/check-plan.js <plan-dir>`** — gate determinístico.
+5. Exit 0 → devolver "plano criado" com resumo. Exit != 0 → regerar tasks 1x e re-rodar; se persistir, ABORTAR e devolver a saída do check-plan ao usuário.
+
+Plano sem tasks (tasks/ vazio ou ausente) é falha — não é "plano parcial". Skill que devolve "plano criado" sem ter rodado o check-plan está em estado inválido.
+
 ## Input
 
 $ARGUMENTS
@@ -28,10 +40,11 @@ $ARGUMENTS
 Campos obrigatórios no prompt:
 - `OBJETIVO` — `implantacao` | `correcao` | `refactor`
 - `FIGMA` — URL do frame principal (auto-ativa Figma MCP)
+- `INTERACOES` — lista estruturada de interações da tela (`<Elemento> — <trigger> → <ação> → <resultado>`). **Obrigatório quando a tela tem table com row clicável OU drawer/modal/popup OU botão que dispara ação assíncrona**. `gos-master` recusa o `*plan` se vazio nessas condições.
 
 Opcionais:
 - `FIGMA+` — lista de URLs de componentes
-- `NOTAS` — prosa livre (comportamento, edge cases, invioláveis)
+- `NOTAS` — prosa livre (invioláveis, edge cases, contexto adicional)
 - `ASSIGNEE` — override do user_id ClickUp para tasks de backend (default: 112010775)
 
 Auto-resolvido pelo `gos-master` (comprehension gate, NÃO pedir ao usuário):
@@ -84,13 +97,37 @@ Caso contrário: trabalhar pela descrição/screenshot fornecido.
 
 Produzir tabela:
 
-| Elemento (Figma/descrição) | Componente do DS | Story (path) | Variant | Props relevantes |
-|----------------------------|------------------|--------------|---------|-------------------|
+| Elemento (Figma/descrição) | Componente do DS | Story (path) | Variant | Props relevantes | Comportamento |
+|----------------------------|------------------|--------------|---------|-------------------|---------------|
 
 A coluna `Story (path)` aponta para `.stories.tsx` indexado no gate. Componente sem story correspondente NÃO entra na tabela — vai pra "Componentes ausentes" e gera task de criação.
 
+Coluna `Comportamento` é obrigatória quando o elemento é interativo. Refinamentos cosméticos (bg, border, padding) NÃO entram aqui — vão para `## Page-level overrides` (Fase 1.4 abaixo).
+
 Listar **componentes ausentes** separadamente — sinalizar como bloqueio ou candidato a criação (vai virar task própria).
 
+### 1.4 Comportamentos & Overrides
+
+Sub-fase nova que materializa intenção de uso e divergência Figma↔Storybook:
+
+1. **Interações & Estados** (`## Interações & Estados` no plano):
+   - Lê `INTERACOES` do input. Se ausente E a tela tem table/drawer/modal/popup detectado em Figma MCP (layer names contendo `Drawer|Modal|Dialog|Popup|Sheet`) ou em `dirs.app` (página equivalente já existente): **bloqueia** a geração e devolve `AskUserQuestion` estruturado pedindo as interações com 3 exemplos pré-preenchidos (clickable row, submit, filtro).
+   - Reconcilia `INTERACOES` com Figma MCP prototype connections quando disponíveis (`figma.connections` revela frame→frame transitions). Conflito → prefere `INTERACOES` do usuário (intenção declarada).
+   - Cada bullet vira identificável (slug curto: `row-click-drawer-view`, `submit-create`, `filter-periodo`) — esses slugs são referenciados por `interaction_target:` nas tasks.
+   - Mapa de estados visuais (skeleton/empty/error/loading) por componente é obrigatório quando a tabela "Componentes mapeados" inclui Tabela ou Form.
+
+2. **Page-level overrides** (`## Page-level overrides` no plano):
+   - Para cada componente da tabela "Componentes mapeados": confronta CSS aplicado no Figma da página (padding, border, bg, radius, shadow) contra props/classes da story canônica em `.stories.tsx`.
+   - Diff cosmético vira linha em `## Page-level overrides` com decisão sugerida pela heurística:
+     - Override aparece em ≥3 telas do projeto (grep em `dirs.app`): **(b) nova variant na story**.
+     - Override aparece só nesta tela: **(a) className na página**.
+     - Override é workaround conhecido / hack temporário: **(c) exceção documentada**.
+   - Slugs curtos (`StatCard:flat-variant`, `Drawer:no-outer-border`) são referenciados por `override_target:` nas tasks.
+
+Política Figma vs Storybook (ver Fase 2):
+
+> Story define API/anatomia do componente; refinamentos cosméticos da página são aceitos via override registrado em `## Page-level overrides`. **Em conflito visual, Figma da página vence**.
+
 ## Fase 2 — Aderência à Stack
 
 **Modo padrão (sem `--allow-arch-change`)**: SOMENTE referenciar a stack já registrada em `stack.md`. Para cada dado/ação da tela, listar:
@@ -128,6 +165,12 @@ Para cada elemento mapeado:
 3. Montagem da view (composição dos componentes do DS)
 4. Estado e interatividade (client components estritamente onde necessário)
 
+Regras de geração de tasks (cobertura de comportamento + overrides):
+
+- Toda interação em `## Interações & Estados` deve gerar **ao menos 1 task** com `interaction_target:` apontando pra ela. Se uma task cobre múltiplas interações, listar todos os slugs.
+- Toda linha de `## Page-level overrides` com decisão **(b)** gera task de variant na story (`area: ui-ux`, `agent:ux-design-expert`); decisões **(a)** e **(c)** geram tasks na página (`area: frontend`, `agent:dev`). Em ambos os casos, frontmatter da task declara `override_target:` apontando pro slug.
+- Tasks de seed data (quando aplicável — Tabela ou Form com fields no Figma) declaram fields obrigatórios e referenciam o checklist "Seed popula TODOS os campos exibidos".
+
 ## Subdivisão automática
 
 Se a análise identificar mais de 3 seções autônomas (modais, drawers, sub-rotas com fetching próprio), gerar **planos filhos** numerados:
@@ -139,13 +182,34 @@ Frontmatter linka via `parent_plan` / `children_plans`.
 
 ## Saída
 
-Para cada plano (incluindo filhos):
+Para cada plano (incluindo filhos), os 4 passos abaixo são **obrigatórios e atômicos** — `*plan` NÃO termina sem todos. Falhar qualquer um aborta com erro explícito (não retornar plano-sem-tasks ao usuário; foi exatamente isso que motivou o bug do PLAN-006).
 
 1. `<dirs.planos>/PLAN-NNN-<slug>/plan.md` — gerado a partir de `templates/planTemplate.md`. Frontmatter inclui `stack_ref: <dirs.stack>@<sha-curto>` para travar a versão da stack.
 2. `<dirs.planos>/PLAN-NNN-<slug>/context.md` — gerado a partir de `templates/contextTemplate.md`. Denso, indexado.
-3. Disparar `plan-to-tasks` automaticamente apontando para o `plan.md` recém-criado → produz tasks em `<dirs.tasks>` (resolvido com `{plan}` substituído).
+3. **Disparar `plan-to-tasks`** apontando para o `plan.md` recém-criado → produz tasks em `<dirs.tasks>` (resolvido com `{plan}` substituído). Esta chamada é **vinculante** — `*plan` é uma operação `{plano + tasks + context + progress}`, nunca só plano. Se `plan-to-tasks` falhar (gate de Phase 3.5), abortar `*plan` inteiro (não deixar plano órfão).
 4. Disparar `progress-tracker set-current` apontando o plano novo → atualiza `progress.txt`.
 
+**Pós-condições obrigatórias** (verificar antes de devolver controle ao usuário):
+
+- `<dirs.planos>/PLAN-NNN-<slug>/tasks/` existe e contém ≥1 `T-NN*.md`.
+- Para CADA `T-NN*.md`: `head -1` = `---` E grep `^status: pendente$` retorna match. Use o gate da Phase 3.5 do `plan-to-tasks`. Falha → regerar tasks; se persistir, abortar com erro explícito ao usuário citando os arquivos malformados.
+- `progress.txt` aponta para o plano novo.
+
+### Gate determinístico — ÚLTIMA ação obrigatória do `*plan`
+
+Após escrever todos os arquivos e atualizar `progress.txt`, **executar via Bash**:
+
+```bash
+node <repo-do-framework>/.gos/scripts/integrations/check-plan.js <dirs.planos>/PLAN-NNN-<slug>
+```
+
+(No projeto-cliente o caminho do script é `.gos/scripts/integrations/check-plan.js`. Em workspaces que rodam o G-OS canônico, é `.G-OS/.gos/scripts/integrations/check-plan.js`.)
+
+- **Exit code 0** → plano válido, usável por `*execute-plan` / `*validate-plan`. SÓ ENTÃO devolver "plano criado" ao usuário com o resumo final.
+- **Exit code != 0** → NÃO devolver "plano criado". A saída do script aponta exatamente o que está errado (task sem frontmatter, status divergente, secao `## Status` no body, etc.). Tentar regerar via `plan-to-tasks` UMA vez; se persistir, abortar com a saída do `check-plan` literal e instruir o usuário a rodar `migrate-task-status.js`.
+
+Esse gate é **determinístico** — não depende do LLM verificar individualmente cada task. É a barreira que evita o bug PLAN-006 voltar.
+
 Resumo final:
 
 ```
@@ -169,7 +233,8 @@ Próximos passos:
 - **Backend read-only respeitado**: se `stack.md` declara backend read-only, plano NUNCA propõe schema novo.
 - **Next.js App Router**: decisão server vs client é explícita por elemento.
 - **Sem prosa decorativa**: plano deve ser executável, denso, com critérios mensuráveis.
-- **Storybook como contrato**: cada componente do DS na tabela DEVE apontar `.stories.tsx` existente em `dirs.storybook`. Sem story → componente vai pra "Componentes ausentes" e gera task de criação. Sem essa disciplina, o visual gate do `*execute-plan` quebra.
+- **Storybook como contrato base; Figma da página como contrato final**: cada componente do DS na tabela DEVE apontar `.stories.tsx` existente em `dirs.storybook`. Sem story → componente vai pra "Componentes ausentes" e gera task de criação. **Em conflito visual entre story e Figma da página, Figma vence** — divergência cosmética é registrada em `## Page-level overrides` com decisão a/b/c (não vira retrabalho no fim).
+- **Comportamento mapeado é obrigatório**: tela com table-clicável/drawer/modal/popup sem `INTERACOES` no input bloqueia plan generation (`AskUserQuestion`). Sem essa disciplina, o caso PLAN-005 (54 deltas em 26 rodadas de feedback) repete.
 
 ## Model guidance
 

package/.gos/skills/plan-to-tasks/SKILL.md

@@ -49,40 +49,24 @@ For each task, create a file following o caminho resolvido em `plan-paths.json`:
 
 Naming: usar `naming.task_prefix` e `naming.seq_padding` do `plan-paths.json` (defaults: `T`, padding 3 → `T-042-001`).
 
-Use this template (from `templates/taskTemplate.md`):
+**Template — CONTRATO DURO**: a estrutura canônica vive em `templates/taskTemplate.md`. Esta skill **DEVE ler esse arquivo na Phase 1** e usar **exatamente** os campos do frontmatter de lá — sem omitir, renomear ou reordenar. NÃO reproduza template inline aqui (já causou bug onde tasks geradas não tinham `status:` no frontmatter — rastreável a planos com tasks travadas em `pendente` mesmo após execução).
 
-```markdown
----
-id: TASK-<YYYYMM>-<seq>
-title: <imperative action verb + what>
-area: <security|backend|ui-ux|routers|migrations|tests|general>
-labels: [agent:<slug>, type:<refactor|bug|feature|chore>]
-priority: <P0|P1|P2>
-estimate: "<2h|4h|1d>"
-assignees: []
-due: null
-links: []
----
-
-## Contexto
-<why this task exists — link to the source plan/ADR/PRD>
+Campos obrigatórios do frontmatter (do `taskTemplate.md`, presentes em CADA T-NN.md gerado):
+- `id`, `plan_id`, `seq`, `title`, `area`, `labels`, `priority`, `estimate`
+- **`status: pendente`** — invariante. Sem isso o `progress-tracker` não consegue transicionar e o `*execute-plan`/`*validate-plan` quebram.
+- `valida_em`, `depends_on_backend: []`, `interaction_target: []`, `override_target: []`, `assignees: []`, `links: []`
 
-## Objetivo
-<expected result in 1-2 sentences>
+Body: copiar as seções do `taskTemplate.md` (`## Contexto`, `## Objetivo`, `## Plano de execução`, `## Critérios de aceitação (DoD)`, `## Riscos & Rollback`) — **NÃO** adicionar seção `## Status` no body. Status vive APENAS no frontmatter.
 
-## Plano de execução
-- [ ] Step 1
-- [ ] Step 2
-- [ ] Step 3
+### Phase 3.5 — Verificação pós-geração (gate)
 
-## Critérios de aceitação (DoD)
-- [ ] Tests/CI green
-- [ ] No regressions
-- [ ] <measurable metric: e.g., coverage ≥70% | endpoint returns <200ms | UI renders correctly on mobile>
+Para cada `T-NN*.md` gerado: confirmar que `head -1` retorna `---` E o frontmatter contém literalmente `status: pendente`. Se qualquer task falhar, regerar (não prosseguir com tasks malformadas — silenciar aqui é o bug original).
 
-## Riscos & Rollback
-- <risk>
-- Rollback plan: <git tag/migration revert command>
+```bash
+for f in <dirs.tasks>/T-*.md; do
+  head -1 "$f" | grep -q '^---$' || { echo "FALHA frontmatter: $f"; exit 1; }
+  grep -q '^status: pendente$' "$f" || { echo "FALHA status: $f"; exit 1; }
+done
 ```
 
 ### Phase 4 — Output a summary

package/.gos/skills/progress-tracker/SKILL.md

@@ -37,15 +37,23 @@ Formato denso, sem prosa, otimizado para tokens. Inspirado em `caveman-main` e `
 
 ```
 pendente → em-andamento → validacao → concluido
+              ↓               ↑
+        bloqueada-backend ────┘
+        (ClickUp aberto)
 ```
 
+Estado lateral `bloqueada-backend` é introduzido pelo `*execute-plan` quando a task tem `depends_on_backend:` que aponta para `## Backend pendings` ainda em aberto no ClickUp. Mantém memória do bloqueio sem regredir para `pendente`.
+
 Transições válidas:
 - `pendente → em-andamento`: livre
+- `pendente → bloqueada-backend`: livre (gate detectou no pré-flight do execute-plan)
+- `em-andamento → bloqueada-backend`: livre (executor detectou gap em runtime)
+- `bloqueada-backend → em-andamento`: requer ClickUp `concluido`/`closed` (skill checa via `mcp__clickup__clickup_get_task`)
 - `em-andamento → validacao`: requer commit preparado (não pushado)
-- `validacao → concluido`: requer aprovação humana
+- `validacao → concluido`: marcado automaticamente por `*validate-plan` quando passa em checklist + visual gate curto + diff. Manual via `*progress status T-NNN-NN concluido` aceito também.
 - `* → pendente`: rollback (libera a transição via flag `--rollback`)
 
-Transições inválidas falham com mensagem do helper `scripts/tools/plan-status.js`.
+Transições inválidas falham com mensagem da skill (state machine textual; sem helper externo).
 
 ## Subcomandos
 
@@ -67,7 +75,19 @@ Fixa o plano ativo. Ex.: `*progress set PLAN-042-checkout`. Atualiza:
 
 ### `status <task-id> <novo-status>`
 
-Muda status de uma task. Valida via state machine. Atualiza `progress.txt` (`last_done`, `next`) e o frontmatter do task file. Se a task fechar o checklist do plano, sugere `*progress status <plan-id> validacao`.
+Muda status de uma task. Valida via state machine. Atualiza:
+
+1. **Frontmatter do task file** (campo `status:` no YAML do topo). Esta e a fonte de verdade — `execute-plan`/`validate-plan` leem dali. **NAO** atualizar/criar secao `## Status` no body.
+2. `progress.txt` (`last_done`, `next`).
+
+Pre-condicao: o task file DEVE ter frontmatter YAML valido com campo `status:`. Se ausente:
+- Detectar via `head -1` != `---` OU grep `^status:` vazio.
+- Se task tem secao `## Status` no body (formato legado bugado): abortar com mensagem `task-malformada: T-NNN-NN usa formato body-status — rodar scripts/integrations/migrate-task-status.js antes de continuar`.
+- Se nao tem nem frontmatter nem `## Status`: abortar com `task-sem-status: regenerar via plan-to-tasks`.
+
+Falha de pre-condicao NAO e silenciada — se silenciar, executor segue achando que transicionou e tasks travam em `pendente` (bug original que motivou esse contrato).
+
+Se a task fechar o checklist do plano, sugere `*progress status <plan-id> validacao`.
 
 ### `compact`
 

package/.gos/skills/registry.json

@@ -23,6 +23,7 @@
     { "slug": "stack-profiler", "path": "skills/stack-profiler/SKILL.md" },
     { "slug": "plan-blueprint", "path": "skills/plan-blueprint/SKILL.md" },
     { "slug": "progress-tracker", "path": "skills/progress-tracker/SKILL.md" },
-    { "slug": "execute-plan", "path": "skills/execute-plan/SKILL.md" }
+    { "slug": "execute-plan", "path": "skills/execute-plan/SKILL.md" },
+    { "slug": "validate-plan", "path": "skills/validate-plan/SKILL.md" }
   ]
 }

package/.gos/skills/validate-plan/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: validate-plan
+description: Valida implementacao pos-execute. Para cada task em validacao, re-roda visual gate curto (anatomia + tokens), confronta diff staged contra Componentes mapeados, confere checklist do plano. Auto-marca concluido o que passa. Fecha plano quando todas as tasks fecham E backend pendings ClickUp estao concluidas.
+argument-hint: "<PLAN-NNN-slug> [NOTAS=...]"
+allowedTools: [Read, Glob, Grep, Bash, Edit, Agent, AskUserQuestion]
+sourceDocs:
+  - templates/planTemplate.md
+  - templates/taskTemplate.md
+  - playbooks/plan-creation-playbook.md
+  - skills/execute-plan/SKILL.md
+  - skills/progress-tracker/SKILL.md
+use-when:
+  - validar plano apos *execute-plan ter rodado
+  - fechar tasks em validacao -> concluido apos checklist + visual gate curto
+  - confirmar que diff staged bate com Componentes mapeados do plano
+do-not-use-for:
+  - executar tasks (use execute-plan)
+  - criar plano novo (use plan-blueprint)
+  - decompor plano em tasks (use plan-to-tasks)
+metadata:
+  category: validation
+---
+
+Voce esta executando como **Revisor de Planos** via skill `validate-plan`. Fecha o ciclo `*plan -> *execute-plan -> *validate-plan`. Ambiente recomendado: Opus 4.7 (revisor); funciona em qualquer IDE.
+
+## Input
+
+$ARGUMENTS
+
+Formato esperado:
+- `<PLAN-NNN-slug>` — id do plano (ex.: `PLAN-001-pagina-projetos-inicial`)
+- `NOTAS="..."` — opcional, contexto de QA / desvios conhecidos
+
+## Pre-requisitos (gate)
+
+1. Resolver paths via `.gos-local/plan-paths.json`. Ausente -> abortar.
+2. Localizar `<dirs.planos>/<PLAN-NNN-slug>/plan.md`. Ausente -> abortar.
+3. Ler `plan.md` por completo: frontmatter + Componentes mapeados + Plano de execucao + Checklist de aceite + Backend pendings.
+4. Listar arquivos staged: `git diff --staged --name-only`. Vazio -> warning visivel ("nenhuma alteracao staged; *execute-plan rodou?") mas NAO aborta — pode validar plano que ja foi commitado, comparando com `git log` desde `validated_at` ou `created_at`.
+5. Ler `<dirs.progress>` (progress.txt). Confirmar que `plan_active` casa com o argumento; se outro plano estiver ativo, perguntar antes de prosseguir.
+
+## Loop por task
+
+**Gate de formato (pre-loop)**: para cada `T-NN*.md` em `<dirs.planos>/<PLAN-NNN-slug>/tasks/`, confirmar `head -1 == "---"` E `grep -q '^status:'` no frontmatter. Tasks malformadas (sem frontmatter ou usando `## Status` no body) sao registradas como erro de plano: validate-plan ABORTA com mensagem `tasks-malformadas: <lista> — rodar scripts/integrations/migrate-task-status.js OU regerar via plan-to-tasks`. Isso evita o falso negativo onde tasks com codigo pronto aparecem `pendente` por bug de gerador (caso PLAN-006).
+
+Iterar tasks cujo frontmatter `status:` seja `validacao`. Tasks em outros estados (pendente, em-andamento, bloqueada-backend, concluido) sao puladas com log curto.
+
+**Diagnostico do bug PLAN-006**: se TODAS as tasks estao em `pendente` E `git diff --staged` ou `git log --since=<plan.created_at>` mostra alteracoes nos arquivos esperados, e provavel que `*execute-plan` rodou sem transicionar (bug do executor). Reportar como `executor-skipped-progress` e instruir humano: rodar `migrate-task-status.js --infer-from-diff` OU re-rodar `*execute-plan PLAN-NNN-<slug>` (que agora tem pos-condicao obrigatoria).
+
+Para cada `T-NNN-NN-*.md` em `validacao`:
+
+1. **Visual gate curto**: para cada componente do plano que a task tocou:
+   a) Localizar `<Componente>.stories.tsx` em `<dirs.storybook>`.
+   b) Comparar implementacao vs story canonica em 3 dimensoes (curto, sem refazer Figma MCP completo):
+      - **Anatomia**: ordem de slots/elementos.
+      - **Tokens**: classes Tailwind/variaveis CSS batem com DS — divergencia registrada em `## Page-level overrides` do plano NAO falha (gate confirma aplicacao do override).
+      - **Comportamentos**: para cada `interaction_target:` da task, grep do handler/estado no diff. Para cada `override_target:` da task, grep das classes/props da decisao.
+   c) Output: append em `tasks/T-NNN-NN.notes.md` na secao `## Validate run <iso>`.
+2. **Confronto diff x mapeamento**: arquivos alterados pela task estao listados em "Componentes mapeados" do plano? Arquivos fora do mapeamento -> warning (nao falha por padrao).
+3. **Checklist da task (DoD)**: ler `## Criterios de aceitacao` da task. Itens nao marcados (`[ ]`) = falha automatica.
+4. **Resultado**:
+   - **Tudo bate** -> `*progress status T-NNN-NN concluido` (auto-marca; rollback humano via `*progress status T-NNN-NN pendente --rollback` se necessario).
+   - **Falha** -> mantem `validacao`, registra divergencia em `T-NNN-NN.notes.md` secao `## Validate run <iso>`, devolve `current=` no progress apontando pra essa task.
+
+## Fechamento do plano
+
+Apos o loop:
+
+1. **Cobertura de comportamento**: ler `## Interações & Estados` em `plan.md`. Para cada bullet (slug): existe AO MENOS 1 task com `interaction_target:` apontando pra ele E status `concluido`? Bullet sem cobertura -> plano permanece em `validacao` (registrar em `T-NNN-NN.notes.md` da task mais proxima do dominio).
+2. **Cobertura de overrides**: ler `## Page-level overrides`. Cada linha com decisao (a/b/c) tem task `concluido` cobrindo? grep do `override_target:` correspondente nos frontmatter de tasks. Override sem cobertura -> plano permanece em `validacao`.
+3. **Checklist do plano**: ler `## Checklist de aceite` em `plan.md`. Itens nao marcados -> plano permanece em `validacao` mesmo se todas as tasks fecharam.
+4. **Backend pendings**: ler `## Backend pendings`. Para cada linha com `ClickUp ID`:
+   - Consultar `mcp__clickup__clickup_get_task <ID>`.
+   - Se status != `concluido`/`closed` -> bloqueio ainda ativo.
+   - Atualizar coluna `Status` da tabela com o estado atual do ClickUp.
+5. **Decisao**:
+   - Todas tasks `concluido` + cobertura de comportamento + cobertura de overrides + checklist do plano marcado + backend pendings todos `concluido` no ClickUp -> marcar `plan.md` frontmatter `validated_at: <iso>` + `*progress status PLAN-NNN-<slug> concluido`.
+   - Caso contrario -> manter `validacao`, listar bloqueios.
+6. **Push**: NAO. Commit ja foi preparado por `*execute-plan`. Push e ato consciente humano (`git push`).
+
+## Saida final ao usuario
+
+Resumo em 4 blocos:
+
+```
+[validate-plan] PLAN-NNN-<slug>
+
+tasks concluidas:   <N>  (T-..., T-...)
+tasks pendentes:    <M>  (T-..., T-...)
+bloqueada-backend:  <K>  (T-...:CU-..., ...)
+backend pendings:   <X>  abertas no ClickUp / <Y> concluidas
+
+plano: <concluido | validacao>
+proximo passo: <git push | resolver bloqueios | re-rodar visual gate em T-...>
+```
+
+## Diferenca x execute-plan (anti-overlap)
+
+- `execute-plan`: visual gate completo (5 dimensoes + Figma MCP arvore), pre-flight smoke (screenshot vs frame), executa codigo via Agent tool, opera estado `em-andamento`.
+- `validate-plan`: visual gate curto (3 dimensoes — anatomia, tokens, comportamentos — sem Figma MCP completo), nao executa codigo, opera estado `validacao -> concluido`, valida cobertura de `interaction_target` e `override_target` no plano. Reaproveita `notes.md` em secao separada `## Validate run <iso>`.
+
+Se `validate-plan` detectar que uma task em `validacao` claramente NAO foi implementada (diff staged nao toca os arquivos esperados), nao reabre execucao — devolve falha clara e instrui usuario a rodar `*execute-plan PLAN-NNN-<slug> --task T-NNN-NN`.
+
+## Regras criticas
+
+- **Auto-conclusao e default**: tudo que passa em checklist + visual gate curto + diff vira `concluido` automaticamente. Rollback humano sempre disponivel.
+- **Sem push automatico**: commit ja preparado pelo `*execute-plan`, push e manual.
+- **State machine respeitada**: tasks `bloqueada-backend` ficam intocadas — backend tem que fechar primeiro.
+- **Backend pendings via ClickUp MCP**: se MCP indisponivel, registra warning e mantem plano em `validacao` ate humano confirmar manualmente.
+
+## Model guidance
+
+| Escopo | Modelo |
+|--------|--------|
+| Validacao curta de plano com poucas tasks | `sonnet` |
+| Plano grande (10+ tasks, varios componentes) | `opus` |
+| Visual gate curto (2 dimensoes, sem Figma MCP) | inherit |
+
+## Instructions
+
+1. NUNCA pular checklist do plano — itens nao marcados bloqueiam fechamento.
+2. NUNCA marcar `concluido` sem visual gate curto rodado e gravado em `T-NNN-NN.notes.md`.
+3. Backend pendings via ClickUp MCP sao vinculantes — plano so fecha quando todos `concluido`.
+4. Resolver TODOS os paths via `plan-paths.json`.
+5. Output final: 4-block summary + comando exato de proximo passo (push manual, ou comandos para resolver bloqueios).

package/.gos/templates/planTemplate.md

@@ -21,9 +21,41 @@ validated_at: null
 
 ## Componentes mapeados
 
-| Elemento | Componente do DS | Story (path) | Variant | Props |
-|----------|------------------|--------------|---------|-------|
-|          |                  |              |         |       |
+| Elemento | Componente do DS | Story (path) | Variant | Props | Comportamento |
+|----------|------------------|--------------|---------|-------|---------------|
+|          |                  |              |         |       |               |
+
+> Coluna `Comportamento` é **obrigatória** quando o elemento é interativo (row clicável, botão, input, drawer/modal/popup trigger). Refinamentos cosméticos da página (bg, border, padding) NÃO entram aqui — vão para `## Page-level overrides`.
+
+## Interações & Estados
+
+> Cobre o `INTERACOES` do prompt. Cada bullet = um caminho do usuário (trigger → ação → resultado/estado). `validate-plan` cruza essa lista contra tasks com `interaction_target:` no frontmatter.
+
+Fluxos por trigger:
+
+1. <ex: Lista → Row click → Drawer abre `mode=view` com record.id → fechar (X ou backdrop) → volta lista>
+2. <ex: Lista → "Novo X" → Drawer abre `mode=create` vazio → Salvar → POST /x → fecha + refetch + toast>
+3. <ex: Toolbar → mudar filtro Período → debounce 300ms → refetch query>
+
+Estados visuais por componente (skeleton / empty / error / loading):
+
+- <ex: Tabela: skeleton 5 rows enquanto fetch; empty state com ilustração + CTA "Criar primeiro X">
+- <ex: Drawer Salvar: estado loading com spinner + disabled durante POST>
+- <ex: Toolbar refresh: ícone gira durante refetch>
+
+## Page-level overrides
+
+> Refinamentos do Figma da página que divergem da story canônica. **Política**: Figma da página vence a story em conflitos cosméticos (bg, border, padding, radius). Cada override é uma decisão (a/b/c).
+
+| Componente | Override observado | Decisão | Ação |
+|------------|--------------------|---------|------|
+|            |                    |         |      |
+
+Decisões possíveis:
+
+- **(a) className na página** — override cosmético e isolado; mantém story padrão e aplica via classe na composição da página.
+- **(b) Nova variant na story** — override aparece em ≥3 telas do projeto; vira variant reusável (ex.: `flat`, `seamless`).
+- **(c) Exceção documentada** — override específico desta tela e não merece variant; documentado aqui sem propagar pra story.
 
 ## Componentes ausentes
 
@@ -73,6 +105,12 @@ validated_at: null
 - [ ] **Visual gate**: cada componente mapeado tem story em `dirs.stories/`
 - [ ] **Visual gate**: anatomia, tokens e densidade batem com a story canônica (≤ 1 desvio menor documentado em `T-NNN-NN.notes.md`)
 - [ ] **Visual gate**: árvore JSX da tela espelha hierarquia do Figma (mesmas seções, mesma ordem)
+- [ ] **Comportamentos**: cada linha de "Interações & Estados" tem implementação testável (handler conectado, refetch disparando, estado visual renderizado)
+- [ ] **Overrides**: cada linha de "Page-level overrides" foi resolvida pela decisão registrada (a/b/c)
+- [ ] **Variants**: story canônica reflete novas variants criadas (decisões `b`)
+- [ ] **States**: skeleton/empty/error/loading implementados conforme matriz acima
+- [ ] **Refetch**: dispara após mutações (POST/PATCH/DELETE)
+- [ ] **Seed**: popula TODOS os campos exibidos no Figma (sem `-` em colunas mapeadas)
 - [ ] <critério específico da tela 1>
 - [ ] <critério específico da tela 2>
 
@@ -80,9 +118,15 @@ validated_at: null
 
 > Gaps detectados confrontando Postman/regras-de-negocio com a necessidade da tela. Cada item vira task ClickUp atribuída ao Douglas (default) ou ao `ASSIGNEE` informado. Vazio = backend completo para esta tela.
 
-| Gap | Endpoint/Coleção esperada | ClickUp ID | Status |
-|-----|---------------------------|------------|--------|
-|     |                           |            |        |
+> Coluna `Bloqueia tasks` lista os T-IDs frontend cujo frontmatter declara `depends_on_backend:` apontando para a `gap-key` desta linha (ex.: `migration-20260501150000`).
+
+| gap-key | Gap | Endpoint/Coleção esperada | ClickUp ID | Status | Bloqueia tasks |
+|---------|-----|---------------------------|------------|--------|----------------|
+|         |     |                           |            |        |                |
+
+## Mock strategy
+
+> Opcional. Quando o frontend opta por mock enquanto o backend não atende, descreva aqui (ex.: fixture em `src/__mocks__/projetos.json`, MSW handler, etc.). Tasks que usam mock NÃO declaram `depends_on_backend:` — apenas referenciam esta seção.
 
 ## Knowledge mapped
 

package/.gos/templates/taskTemplate.md

@@ -9,6 +9,9 @@ priority: <P0|P1|P2>
 estimate: "<2h|4h|1d>"
 status: pendente
 valida_em: <referência ao critério no checklist do plano>
+depends_on_backend: []   # opcional — gap-keys da tabela ## Backend pendings do plano pai
+interaction_target: []   # opcional — bullets de "## Interações & Estados" do plano pai que esta task implementa/preserva (ex.: ["row-click-drawer-view", "submit-create"])
+override_target: []      # opcional — linhas de "## Page-level overrides" do plano pai que esta task resolve (ex.: ["StatCard:flat-variant"])
 assignees: []
 links: []
 ---
@@ -30,7 +33,9 @@ links: []
 ## Critérios de aceitação (DoD)
 
 - [ ] Implementação atende `valida_em` do plano
-- [ ] **Visual gate aprovado** (relatório em `T-NNN-NN.notes.md` com 4 seções: anatomia, tokens, variants, densidade)
+- [ ] **Visual gate aprovado** (relatório em `T-NNN-NN.notes.md` com 5 seções: anatomia, tokens, variants, densidade, comportamentos)
+- [ ] **Comportamentos**: cada `interaction_target` declarado tem handler/estado implementado e observável no diff
+- [ ] **Overrides**: cada `override_target` declarado foi aplicado conforme decisão (a/b/c) registrada em `## Page-level overrides`
 - [ ] Tests/CI verdes
 - [ ] Sem regressões
 - [ ] <métrica específica>

package/CLAUDE.md

@@ -48,7 +48,7 @@ Todo texto gerado deve passar por correcao ortografica e remocao de padroes de I
 gos-master | architect | dev | devops | po | qa | sm | squad-creator | ux-design-expert
 
 ### Skills (invoke via /gos:skills:{slug})
-design-to-code | figma-implement-design | figma-make-analyzer | make-code-triage | make-version-diff | component-dedup | frontend-dev | interface-design | react-best-practices | react-doctor | sprint-planner | clickup | plan-to-tasks | agent-teams | git-ssh-setup | stack-profiler | plan-blueprint | progress-tracker | execute-plan
+design-to-code | figma-implement-design | figma-make-analyzer | make-code-triage | make-version-diff | component-dedup | frontend-dev | interface-design | react-best-practices | react-doctor | sprint-planner | clickup | plan-to-tasks | agent-teams | git-ssh-setup | stack-profiler | plan-blueprint | progress-tracker | execute-plan | validate-plan
 
 ### IDEs suportadas (npm run sync:ides gera adapters)
 Claude Code | Cursor | Gemini CLI | Qwen Code | Antigravity | Opencode | Kilo Code | **Codex IDE Extension** (ambiente de execucao, comando primario `*execute-plan`)
@@ -60,11 +60,14 @@ Pipeline padronizado para criacao de planos por tela. Toda tela = 1 plano. Stack
 | Comando | Skill | IDE / Modelo | Funcao |
 |---------|-------|--------------|--------|
 | `*stack [refresh|show|drift]` | `stack-profiler` | qualquer | Mantem `docs/stack.md` (canonico do projeto) |
-| `*plan <tela>` | `plan-blueprint` | Opus 4.7 (planejador) | Cria plano + tasks + context + atualiza `progress.txt` |
-| `*execute-plan <PLAN-NNN>` | `execute-plan` | **Codex IDE Extension** (executor) | Executa task-a-task com visual gate vs Storybook canonico |
+| `*plan <tela>` | `plan-blueprint` | Opus 4.7 (planejador) | Cria plano + tasks + context + atualiza `progress.txt`. Captura comportamentos (`## Interacoes & Estados`) e page-level overrides (`## Page-level overrides`). INTERACOES obrigatorio quando tela tem table-clicavel/drawer/modal/popup. |
+| `*execute-plan <PLAN-NNN>` | `execute-plan` | **Codex IDE Extension** (executor) | Executa task-a-task com visual gate (5 dim: anatomia, tokens, variants, densidade, comportamentos) vs Storybook canonico. Pre-flight smoke compara screenshot da pagina vs Figma frame antes da T-01. Non-blocking em backend gaps. |
+| `*validate-plan <PLAN-NNN>` | `validate-plan` | Opus 4.7 (revisor) | Valida pos-execute; auto-marca concluido tasks que passam em checklist + visual gate curto + diff |
 | `*progress [show|set|status]` | `progress-tracker` | qualquer | Memoria L1 + state machine de status |
 
-State machine: `pendente -> em-andamento -> validacao -> concluido` (concluido somente apos validacao humana).
+State machine: `pendente -> em-andamento -> validacao -> concluido`. Estado lateral `bloqueada-backend` (introduzido pelo `*execute-plan` quando task tem `depends_on_backend:` em aberto no ClickUp; libera quando ClickUp fecha). `concluido` marcado automaticamente pelo `*validate-plan` quando passa em checklist + visual gate curto + diff + cobertura de `interaction_target`/`override_target`.
+
+**Politica Figma vs Storybook**: story define API/anatomia do componente; em conflito visual cosmetico (bg, border, padding, radius), Figma da pagina vence — divergencia e registrada em `## Page-level overrides` do plano com decisao a/b/c (a=className, b=variant nova, c=excecao documentada). Sem essa disciplina, refinamentos da pagina viram retrabalho no fim (caso PLAN-005: 54 deltas em 26 rodadas).
 
 Paths do projeto-cliente sao resolvidos via `.gos-local/plan-paths.json` — nada hardcoded. Nesse arquivo declara-se onde estao `docs/plans/`, `docs/postman/`, `docs/regras-de-negocio/`, design system, etc. Cada projeto/dev pode organizar diferente.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ganbatte-os",
-  "version": "0.2.34",
+  "version": "0.2.35",
   "description": "Framework operacional para design-to-code, squads de entrega e sprint sync com ClickUp.",
   "bin": {
     "gos": ".gos/scripts/cli/gos-cli.js"