ganbatte-os 0.2.38 → 0.2.42

package/.gos/libraries/lazy-dev-policy.md

@@ -0,0 +1,38 @@
+# Lazy Dev Policy (G-OS)
+
+Escrever só o que a tarefa precisa. O melhor código é o que nunca foi escrito. Absorvido do padrão "ponytail" (senior dev preguiçoso = eficiente, não desleixado).
+
+## A escada (parar no primeiro degrau que resolve)
+
+Depois de entender o problema (nunca antes):
+
+1. **Precisa existir?** Necessidade especulativa → pular, dizer em 1 linha. (YAGNI)
+2. **Já existe neste codebase?** Helper, util, tipo, componente que já vive aqui → reutilizar, não reescrever. Olhar antes de escrever é a regra que mais evita retrabalho.
+3. **Stdlib resolve?** Usar.
+4. **Feature nativa da plataforma?** `<input type="date">` > lib de datepicker; CSS > JS; constraint de DB > código de app.
+5. **Dependência já instalada resolve?** Usar. Nunca adicionar dep nova pro que poucas linhas fazem.
+6. **Cabe em uma linha?** Uma linha.
+7. **Só então**: o mínimo de código que funciona.
+
+Dois degraus resolvem → pegar o mais alto e seguir.
+
+## Regras
+
+- Sem abstração não pedida: nada de interface com uma implementação, factory pra um produto, config pra valor que não muda.
+- Sem boilerplate/scaffolding "pra depois". Depois se scaffolda sozinho.
+- Deleção > adição. Chato > esperto (esperto é o que alguém decodifica às 3h da manhã).
+- Menor diff que funciona vence — mas só depois de entender o problema. Menor mudança no lugar errado é um segundo bug.
+- Bug fix = causa-raiz, não sintoma. Grep todos os callers antes de editar; corrigir uma vez, onde todos passam.
+- Marcar simplificação deliberada com comentário `// ponytail:` nomeando o teto e o upgrade path (ex.: `// ponytail: lock global; por-conta se throughput exigir`).
+
+## Quando NÃO ser preguiçoso (inegociável)
+
+Nunca simplificar fora: **validação em trust boundary, tratamento de erro que evita perda de dado, segurança, acessibilidade básica, qualquer coisa pedida explicitamente.** Um smoke test / `assert` mínimo em lógica não-trivial é o mínimo ponytail, não bloat.
+
+Nunca preguiçoso em **entender o problema**. A escada encurta a solução, nunca a leitura. Ler o fluxo inteiro, depois ser preguiçoso.
+
+## Aplicação no G-OS
+
+- Regra sempre-ativa referenciada pelo `gos-master` e pelo `dev`.
+- Skill `simplify-review` faz review por deleção (o que cortar).
+- Composição com `perf-review` (otimização) e `security-review` (nunca cortar segurança).

package/.gos/libraries/lucide-icons-policy.md

@@ -160,7 +160,7 @@ import { AlertTriangle, RotateCw } from "lucide-react";
 
 - Output em terminal/Bash que sera lido por humano (ex: `npm run doctor`).
 - Documentacao README.md (estilo).
-- Slack messages, ClickUp comments (texto plano fora de codigo de UI).
+- Mensagens de chat e comentarios em tickets (texto plano fora de codigo de UI).
 - Mensagens em chat enquanto agente conversa com usuario (regra global do agente — nao em codigo gerado).
 - Usuario pede explicitamente: "use emoji aqui".
 

package/.gos/libraries/performance-audit-playbook.md

@@ -0,0 +1,54 @@
+# Performance Audit Playbook (G-OS)
+
+Catálogo de otimizações para código de desenvolvimento (React/Next.js frontend + backend Supabase / Cloudflare D1/Workers). Usado por `perf-review` e pelo fechamento de `validate-plan`. Foco em ganhos algorítmicos e arquiteturais, não micro-otimização.
+
+## Regras de manejo
+
+- Finding só com evidência (`file:line`) + impacto concreto ("cada render da lista dispara 1+N queries") + correção. "Provavelmente lento" não é finding.
+- Índice/materialização "por suspeita" precisa de evidência de schema/query antes de afirmar.
+- Findings viram tasks de correção e entram no loop do pipeline.
+
+## Categorias
+
+### 1. N+1 e complexidade
+- Query/fetch por item dentro de loop ou por linha de lista renderizada → batch / `in (...)` / dataloader.
+- Varreduras aninhadas na mesma coleção; `find`/`filter` repetido em hot loop onde cabe `Map`.
+
+### 2. Cache estratégico
+- Computações/fetches caros idênticos repetidos por request/render → memoização no boundary certo.
+- Sem cache HTTP / data-layer em dado estável. **Cloudflare**: Cache API / KV para dado quente; `cache-control` correto. **Supabase**: cache no edge / revalidação.
+- **Next.js**: `revalidate`, `cache: 'force-cache'`, React Query/SWR staleTime para dado estável; evitar refetch desnecessário.
+
+### 3. Trabalho fora do caminho crítico (item 4)
+- Serviço/função que NÃO precisa ser realtime rodando síncrono no request → mover para **fila** (Cloudflare Queues / Supabase pg-boss/pgmq) e processar em background.
+- Tarefas periódicas → **cron** (Cloudflare Cron Triggers / Supabase `pg_cron`).
+- Envio de email, geração de relatório, webhooks, agregações pesadas: background, não no caminho do usuário.
+
+### 4. Banco de dados (Supabase Postgres / Cloudflare D1)
+- **Índices**: padrões de query (filtro por coluna, join, order by) sem índice de suporte → flag com evidência do schema.
+- **Views / materialized views**: agregação cara repetida → materialized view + refresh agendado (cron). View para encapsular join complexo recorrente.
+- **Paginação obrigatória**: lista sem limite → `limit`/`offset` ou keyset pagination. Consumo **mediante filtro/search** (não trazer tudo e filtrar no client).
+- **Over-fetch**: `select *` / objeto inteiro onde IDs bastam; colunas não usadas; JSON grande enviado ao client.
+- Query pesada em request quente → materializar / cachear / paginar.
+- **D1**: batch de statements; evitar round-trips múltiplos; usar prepared statements reusados.
+
+### 5. Frontend (React/Next.js)
+- Bundle: dependência pesada para uso trivial; falta de code-splitting em rota rara; imagens/fontes não otimizadas.
+- Render waterfalls; fetch no client para dado disponível no render (mover para server component / server-side).
+- Memoização ausente em boundary claro; re-render em cascata.
+- Deferir para as guidelines do projeto (react-best-practices) quando houver.
+
+### 6. Build/CI
+- CI lento por falta de cache; passos redundantes; suíte que poderia paralelizar.
+
+## Formato do finding
+
+```markdown
+### [PERF-NN] Título imperativo curto
+- **Evidência**: `path/file.ts:142` — o padrão concreto.
+- **Impacto**: custo pago ("cada listagem: 1+N queries", "500KB de JSON por request").
+- **Esforço**: S | M | L (para a correção).
+- **Correção**: técnica específica (batch, cache, fila, índice, view, paginação).
+```
+
+Ordenar por leverage (impacto ÷ esforço). Findings de alto impacto viram task antes de fechar o plano.

package/.gos/libraries/security-audit-playbook.md

@@ -0,0 +1,63 @@
+# Security Audit Playbook (G-OS)
+
+Catálogo de vulnerabilidades conhecidas para auditar código de desenvolvimento (React, Next.js, TypeScript, Node, Deno, Supabase, Cloudflare D1/Workers). Usado por `security-review` e pelo fechamento de `validate-plan`.
+
+## Regras de manejo
+
+- Uma vulnerabilidade só é finding **com evidência**: `file:line` + descrição do padrão + impacto em produção + remediação. "Provavelmente tem XSS em algum lugar" não é finding.
+- **NUNCA reproduzir valor de secret.** Referenciar só `file:line` + tipo da credencial; a correção sempre inclui rotação (secret commitado está queimado mesmo após remoção).
+- Comportamento by-design (convenção de plataforma, decisão registrada em ADR) não é finding — salvo se a implementação adiciona risco além da convenção. ADR desatualizada vs código É finding (drift).
+- Findings viram tasks de correção e entram no loop do `execute-plan` / correção do `validate-plan`.
+
+## Categorias
+
+### 1. Credenciais e secrets
+- Chaves/tokens/senhas hardcoded no código ou em `.env` commitado.
+- **Supabase**: `service_role` key usada no client (deve ser só server/edge). `anon` key com RLS desligado = acesso total.
+- Secrets logados ou persistidos em stores de evento/histórico.
+- **Cloudflare**: secrets via `wrangler secret` (não em `wrangler.toml` versionado nem `vars`).
+- Remediação: remover, **rotacionar**, mover para secret manager / env server-side.
+
+### 2. Dados cruzando para interpretadores
+- **SQL injection**: query montada com string de request (Postgres/D1). Usar parâmetros/prepared statements.
+- **Command injection**: shell montado com input.
+- **XSS**: `dangerouslySetInnerHTML`, `eval`, `innerHTML` com conteúdo controlado pelo usuário. Sanitizar / usar APIs seguras.
+- **Path traversal**: path de arquivo derivado de request.
+- **SSRF**: fetch para URL controlada pelo usuário sem allowlist.
+
+### 3. Controle de acesso (o eixo mais crítico em Supabase)
+- **RLS**: tabela com dado sensível e RLS **desligado** ou sem policy → qualquer `anon`/`authenticated` lê tudo. Toda tabela exposta via PostgREST precisa de RLS ligado + policy explícita por operação (select/insert/update/delete).
+- **Policies frouxas**: `using (true)` em tabela sensível; policy que não checa `auth.uid()` / tenant / ownership (IDOR).
+- **Edge Functions (Supabase)**: função sem verificação de JWT/authz server-side; confiar em header do client; `verify_jwt` desligado sem motivo.
+- **Next.js**: route handler / server action sem checagem de identidade server-side; autorização só no client; middleware que não cobre a rota.
+- **Cloudflare Workers**: endpoint mutável sem auth; falta de checagem de origem.
+- **CSRF**: rota que muda estado sem checagem de autenticidade.
+
+### 4. Contratos de entrada
+- Boundary de API que confia no body sem validação de schema (usar **Zod** front + back — validação no client não substitui a do server).
+- Upload de arquivo sem restrição de tipo/tamanho/armazenamento.
+- Mass assignment: atribuição ampla de objeto do request para modelo de persistência.
+
+### 5. Configuração de produção
+- CORS amplo (`*`) com credenciais permitidas.
+- Headers de segurança ausentes (CSP) em superfícies sensíveis; cookies sem `HttpOnly`/`Secure`/`SameSite`.
+- Debug/verbose habilitado em produção; stack trace vazando para o client.
+- **Supabase**: bucket de Storage público quando deveria ser privado; policy de Storage ausente.
+
+### 6. Dependências
+- Rodar o audit do ecossistema em modo read-only: `npm audit` / `pnpm audit` / `deno info`. Reportar só advisories critical/high que afetam código runtime alcançável.
+
+### 7. Minimização de dados
+- PII / dado operacional sensível em logs, em respostas de erro, ou exposto via API.
+
+## Formato do finding
+
+```markdown
+### [SEC-NN] Título imperativo curto
+- **Evidência**: `path/file.ts:123` — o que está lá (sem reproduzir secret).
+- **Impacto**: o que um atacante consegue / o que vaza.
+- **Severidade**: CRITICAL | HIGH | MEDIUM | LOW.
+- **Remediação**: mudança de código/config + rotação quando aplicável.
+```
+
+Ordenar por severidade; CRITICAL/HIGH viram task de correção obrigatória antes de fechar o plano.

package/.gos/manifests/g-os-runtime-manifest.json

@@ -1,7 +1,7 @@
 {
-  "runtime": "ganbatte-os-design-delivery",
+  "runtime": "ganbatte-os-development",
   "version": "0.1.0",
-  "description": "Runtime curado do ganbatte-os para design-to-code, sprint planning e ClickUp delivery.",
+  "description": "Runtime curado do ganbatte-os para desenvolvimento: prototipacao, design-to-code, implementacao, otimizacao e seguranca.",
   "modules": {
     "agents": [
       "ganbatte-os-master",
@@ -10,8 +10,11 @@
       "dev",
       "sm",
       "po",
+      "qa",
       "devops",
-      "squad-creator"
+      "squad-creator",
+      "security-auditor",
+      "perf-optimizer"
     ],
     "skills": [
       "design-to-code",
@@ -21,21 +24,39 @@
       "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",
       "humanizer",
-      "weekly-update"
+      "stack-profiler",
+      "plan-blueprint",
+      "progress-tracker",
+      "execute-plan",
+      "validate-plan",
+      "audit-screenshots",
+      "idea-intake",
+      "prd-from-intake",
+      "adr-tech-decisions",
+      "prototype-orchestrator",
+      "gos-caveman",
+      "gos-compress",
+      "figma-print-diff",
+      "ui-guardrails",
+      "cloudflare-pages-setup",
+      "typeform-form-pattern",
+      "timer-component-pattern",
+      "security-review",
+      "perf-review",
+      "simplify-review"
     ],
     "squads": [
       "design-delivery",
       "design-squad",
-      "sprint-planning",
-      "git-operations"
+      "git-operations",
+      "code-quality"
     ]
   }
 }

package/.gos/playbooks/audit-streaming-playbook.md

@@ -0,0 +1,86 @@
+# Playbook — Auditoria visual streaming (audit-screenshots)
+
+Guia de uso do fluxo de correção visual **plano-primeiro, task-por-insumo**. Confronta o app implementado
+contra o Figma e gera UM plano de correção com tasks escritas na hora — cada divergência passa pelo gate
+de reuso de componente (reuse / create / merge). Substitui o modelo antigo de fila (acumular prints →
+materializar no `close`).
+
+## Quando usar
+
+- Você tem N telas com divergências visuais (cola prints, ou aponta rotas) e quer UM plano de fix.
+- Quer auditar sistematicamente um tipo de tela contra o Figma (`validate`).
+- NÃO use para planejar tela nova (use `*plan` / plan-blueprint) nem para executar (use `*execute-plan`).
+
+## Pré-requisitos do workspace
+
+1. `.gos-local/plan-paths.json` configurado (campo `figma_screen_map`; default `docs/figma-screen-map.md`).
+2. `docs/figma-screen-map.md` — mapa canônico `Rota app ↔ node-id` (contrato tela↔Figma do projeto).
+3. **Figma MCP** ativo (expected) e **Playwright** disponível (actual, captura do app vivo).
+4. `progress.txt` na raiz (criado no primeiro `*plan`/`open`).
+
+## Fluxo end-to-end
+
+### 1. Abrir o plano (uma vez por auditoria)
+
+```
+*audit-screenshots open [SLUG]
+```
+
+Cria `docs/plans/PLAN-NNN-fix-<SLUG>/` com `plan.md` em **`status: aberto`** (draft) + `context.md` +
+`tasks/` vazio + `audit-evidence/`. **Não** roda check-plan (o plano ainda é rascunho).
+
+### 2. Adicionar insumos (quantos quiser, a qualquer momento)
+
+```
+# Cole o print + contexto, OU aponte a rota para o Playwright capturar:
+*audit-screenshots add   "a aba negocios esta sem a coluna Area"   # + imagem colada
+*audit-screenshots add   /dashboard/projetos/123?tab=negocios       # captura via Playwright
+```
+
+Cada insumo, NA HORA: resolve tela no mapa → captura actual (print ou Playwright) → pull Figma (MCP) →
+confronta via `figma-print-diff` (single-pass, lenses 1-6) → **gate de reuso** por divergência estrutural
+→ escreve `tasks/T-NN-*.md` (`status: pendente`) com evidência anexada. Sem fila, sem `close` no fim.
+
+### 3. (Opcional) Sweep de validação por tipo de tela
+
+```
+*audit-screenshots validate listagem      # todas as telas tipo "listagem" no mapa
+*audit-screenshots validate --all          # varre o mapa inteiro
+```
+
+Itera o `figma-screen-map.md`, captura Playwright + pull Figma, confronta e escreve tasks — mesmo fluxo do `add`.
+
+### 4. Revisar e finalizar
+
+```
+*audit-screenshots list        # tasks escritas ate agora + decisoes de componente
+*audit-screenshots finalize    # flip status: pendente -> roda check-plan.js -> pronto p/ execute-plan
+```
+
+`finalize` valida que cada task é self-contained, vira o plano para `status: pendente`, dispara
+`ui-guardrails` e roda `check-plan.js` (gate determinístico). Exit 0 → o plano é input de `*execute-plan`.
+
+```
+*execute-plan PLAN-NNN-fix-<SLUG>
+```
+
+`*audit-screenshots discard` aborta o plano aberto a qualquer momento.
+
+## Gate de reuso de componente (design-to-code)
+
+Cada divergência em estrutura reusável (table, card, form, list…) NÃO vira patch one-off. O fluxo mapeia o
+elemento → checa a biblioteca (`component-dedup`) → decide **reuse | create | merge** (ver
+`libraries/component-reuse-gate.md`). A task grava `component_decision` + `component_target`.
+
+**Exemplo (Fractus):** divergência numa tabela → a primitiva `DataTable` (TanStack) já existe →
+decisão **reuse**. A correção é nas `columns`/dados daquela tela OU na própria primitiva (se o defeito é
+compartilhado) — nunca um `<table>` novo. `negocios-table`, `funders-table` etc. = 1 primitiva, N usos.
+
+## Por que mudou (vs modelo de fila)
+
+| Antes (fila) | Agora (streaming) |
+|--------------|-------------------|
+| `add` acumula em `audit-session.json` | `open` cria plano draft; o diretório É o estado |
+| Tasks só nascem no `close` (perda de contexto) | Task escrita NA HORA, por insumo, com evidência |
+| Correção = patch da tela | Correção passa pelo gate de reuso (reuse/create/merge) |
+| check-plan no `close` | check-plan só no `finalize` (plano `aberto` é estado válido) |

package/.gos/playbooks/plan-creation-playbook.md

@@ -46,7 +46,6 @@ FIGMA      = <url-frame>
 FIGMA+     = [<url-comp>, ...]                   # opcional
 INTERACOES = """<lista estruturada — obrigatório quando tela tem table-clicável/drawer/modal/popup>"""
 NOTAS      = """<prosa livre>"""                 # opcional
-ASSIGNEE   = <user-id>                           # opcional, default 112010775 (Douglas)
 ```
 
 `gos-master` resolve no comprehension gate (não pedir ao usuário):
@@ -59,7 +58,7 @@ ASSIGNEE   = <user-id>                           # opcional, default 112010775 (
 1. Fase 1 — Mapeamento Visual & Componentização
    1.4 Comportamentos & Overrides — `## Interações & Estados` + `## Page-level overrides` no plano
 2. Fase 2 — Aderência à Stack (sem redefinir arquitetura)
-2.5 Fase 2.5 — Backend gaps → criar tasks ClickUp pro Douglas (`--skip-clickup` desliga)
+2.5 Fase 2.5 — Backend gaps → registro local em `## Backend pendings` + plano-irmão `PLAN-NNN-backend-<slug>` quando grande (`--skip-backend-tracking` desliga)
 3. Fase 3 — Plano de Execução (gera tasks com `interaction_target` e `override_target` para cobrir comportamentos e overrides)
 
 Saídas:
@@ -117,7 +116,7 @@ NOTAS = """<opcional — desvios conhecidos, contexto de QA>"""
 
 Skill `validate-plan` (Opus, revisor):
 - Para cada task em `validacao`: re-roda visual gate curto (anatomia + tokens + comportamentos), confronta `git diff --staged` vs Componentes mapeados, confere checklist da task e `interaction_target`/`override_target`. Tudo bate → auto-marca `concluido`. Falha → mantém `validacao` com nota.
-- Para o plano: cobertura de comportamento (`## Interações & Estados`) + cobertura de overrides (`## Page-level overrides`) + checklist do plano + backend pendings ClickUp todos `concluido` → marca `validated_at:` no plan.md + `*progress status PLAN-NNN-<slug> concluido`. Senão → mantém em `validacao`.
+- Para o plano: cobertura de comportamento (`## Interações & Estados`) + cobertura de overrides (`## Page-level overrides`) + checklist do plano + backend pendings locais todos `concluido` → marca `validated_at:` no plan.md + `*progress status PLAN-NNN-<slug> concluido`. Senão → mantém em `validacao`.
 - Tasks `bloqueada-backend` ficam intocadas — backend tem que fechar primeiro.
 
 ### 5. Push manual e fechamento
@@ -128,7 +127,7 @@ Skill `validate-plan` (Opus, revisor):
 git push
 ```
 
-Push é ato consciente do humano. Tasks `bloqueada-backend` aguardam ClickUp fechar — quando isso acontece, rodar `*progress status T-NNN-NN em-andamento` (state machine valida ClickUp via MCP) e voltar pra etapa 4.
+Push é ato consciente do humano. Tasks `bloqueada-backend` aguardam o pending local de backend fechar — quando isso acontece, rodar `*progress status T-NNN-NN em-andamento` (state machine valida o status local) e voltar pra etapa 4.
 
 ### 6. Commit & resumo
 
@@ -159,4 +158,3 @@ Push é ato consciente do humano. Tasks `bloqueada-backend` aguardam ClickUp fec
 - `execute-plan` — executa plano com visual gate, non-blocking em backend gaps (Codex IDE, execução)
 - `validate-plan` — valida plano pós-execute, auto-marca concluido (Opus, revisor)
 - `progress-tracker` — gerencia `progress.txt` + state machine (incluindo `bloqueada-backend`)
-- `clickup` — sync opcional para tracking externo (não obrigatório)

package/.gos/prompts/01-search.md

@@ -14,5 +14,5 @@ Use este prompt quando a tarefa for descobrir contexto antes de construir.
 - Screenshot ou referencia visual: `design-to-code`
 - Figma Make bruto: `figma-make-analyzer`
 - Codigo do Stitch ou outro gerador: `make-code-triage`
-- Planejamento de entrega: `sprint-planner`
-- Sincronizacao operacional: `clickup`
+- Planejamento por tela: `plan-blueprint`
+- Auditoria de seguranca/performance: `security-review`, `perf-review`

package/.gos/prompts/03-tasks.md

@@ -5,11 +5,11 @@ Quebre a especificacao em tarefas pequenas e ordenadas.
 ## Regras
 
 - cada task deve caber em menos de um dia
-- separar FE, UX, QA, DevOps e operacao ClickUp quando fizer sentido
-- incluir criterios de aceite objetivos
+- separar backend, frontend, UX e QA quando fizer sentido (backend-first quando houver dependencia)
+- incluir criterios de aceite objetivos e verificaveis
 - explicitar dependencias
 
 ## Saida esperada
 
-- backlog pronto para `sprint-planner`
-- ou JSON/markdown que possa virar importacao no ClickUp
+- backlog pronto para `plan-to-tasks`
+- tasks em markdown com frontmatter e criterios de aceite

package/.gos/prompts/05-reviews.md

@@ -8,4 +8,4 @@ Revise a entrega com foco em regressao, fidelidade ao design e prontidao para sp
 - aderencia ao design/tokens
 - acessibilidade
 - riscos de dados mockados ou codigo Make misturado com UI final
-- importacao/sincronizacao correta para ClickUp quando fizer parte do fluxo
+- seguranca (RLS, authz, secrets) e performance (N+1, cache, paginacao) quando fizer parte do fluxo

package/.gos/scripts/cli/gos-cli.js

@@ -315,6 +315,22 @@ function cmdInit(root, args) {
   const gitignoreUpdated = mergeGitignore(root, manifest.gitignoreEntries || []);
   if (gitignoreUpdated) ok('.gitignore atualizado com entradas do manifest.');
 
+  // 8b. Config de modelo por etapa (Junior executa, Senior audita)
+  try {
+    const { writeLocalDefaults, resolveAll } = require(path.join(root, '.gos', 'scripts', 'tools', 'model-router.js'));
+    const res = writeLocalDefaults(root);
+    const map = resolveAll(root);
+    if (res.created) {
+      ok('Config de modelos por etapa criada em .gos-local/models.json');
+    } else {
+      info('Config de modelos por etapa ja existe (.gos-local/models.json).');
+    }
+    info(`  plan=${map.plan.model} | execute=${map.execute.model} | validate=${map.validate.model}`);
+    info('  Edite .gos-local/models.json para trocar modelo/provider por etapa.');
+  } catch (err) {
+    warn(`Nao foi possivel configurar models por etapa: ${err.message}`);
+  }
+
   // 9. Salvar install log
   writeJson(installLog, {
     version: VERSION,

package/.gos/scripts/hooks/claude-stop-summary.js

@@ -122,22 +122,6 @@ function main() {
   const summary = [];
   const syncMatcher = /^(\.gos|\.claude|data|README\.md|CLAUDE\.md|AGENTS\.md|GEMINI\.md)/;
 
-  // Trigger post-commit notification if git commit was made
-  if (state.gitCommit) {
-    try {
-      execFileSync('node', [path.join(ROOT, '.gos', 'scripts', 'hooks', 'post-commit-notify.js')], {
-        cwd: ROOT,
-        encoding: 'utf8',
-        stdio: ['pipe', 'pipe', 'pipe'],
-        timeout: 30000,
-      })
-      summary.push('post-commit-notify OK')
-    } catch (error) {
-      const message = error.stderr || error.stdout || error.message || 'falha no post-commit'
-      summary.push(`post-commit-notify falhou (${String(message).split(/\r?\n/)[0]})`)
-    }
-  }
-
   if (anyPathMatches(touchedFiles, syncMatcher)) {
     try {
       runNpm(["run", "sync:ides"], { timeout: 180000 });

package/.gos/scripts/integrations/check-plan.js

@@ -13,10 +13,11 @@
  * Verificacoes:
  * 1. plan.md existe e tem frontmatter YAML.
  * 2. context.md existe.
- * 3. tasks/ existe e contem >= 1 T-NN*.md.
- * 4. Cada T-NN*.md: head -1 == "---" E frontmatter contem `status: pendente`
- *    E `id:`, `plan_id:`, `seq:`, `title:`.
- * 5. Nenhum T-NN*.md tem secao `## Status` no body (formato bugado legado).
+ * 3. spec.md existe (spec completa de desenvolvimento).
+ * 4. tasks/ existe e contem >= 1 T-NN*.md.
+ * 5. Cada T-NN*.md: head -1 == "---" E frontmatter contem `status: pendente`
+ *    E `id:`, `plan_id:`, `seq:`, `title:`, E body tem `## Critérios de aceite`.
+ * 6. Nenhum T-NN*.md tem secao `## Status` no body (formato bugado legado).
  *
  * Exit code:
  *   0 = plano valido, usavel pelo pipeline
@@ -43,6 +44,7 @@ const warnings = [];
 
 const planFile = path.join(planDir, 'plan.md');
 const contextFile = path.join(planDir, 'context.md');
+const specFile = path.join(planDir, 'spec.md');
 const tasksDir = path.join(planDir, 'tasks');
 
 if (!fs.existsSync(planFile)) {
@@ -58,6 +60,10 @@ if (!fs.existsSync(contextFile)) {
   warnings.push(`context.md ausente — recomendado, nao bloqueia`);
 }
 
+if (!fs.existsSync(specFile)) {
+  errors.push(`spec.md ausente em ${planDir} — *plan deve emitir spec.md (templates/specTemplate.md)`);
+}
+
 if (!fs.existsSync(tasksDir)) {
   errors.push(`tasks/ ausente em ${planDir} — *plan deve invocar plan-to-tasks`);
 } else {
@@ -100,6 +106,10 @@ if (!fs.existsSync(tasksDir)) {
     if (/^## Status\s*$/m.test(body)) {
       errors.push(`${rel}: contem secao "## Status" no body (formato legado bugado) — rodar migrate-task-status.js`);
     }
+
+    if (!/^## Crit[eé]rios de aceite/m.test(body)) {
+      errors.push(`${rel}: sem secao "## Critérios de aceite" no body — task precisa de criterios verificaveis`);
+    }
   }
 }
 
@@ -116,5 +126,5 @@ if (errors.length) {
 
 const taskCount = fs.readdirSync(tasksDir)
   .filter((f) => /^T-\d+.*\.md$/.test(f)).length;
-console.log(`[check-plan] OK — ${planDir}: plan.md + context.md + ${taskCount} tasks (todas com frontmatter status: pendente).`);
+console.log(`[check-plan] OK — ${planDir}: plan.md + context.md + spec.md + ${taskCount} tasks (frontmatter status: pendente + criterios de aceite).`);
 process.exit(0);