ganbatte-os 0.2.27 → 0.2.29

package/.gos/agents/profiles/ganbatte-os-master.md

@@ -81,6 +81,8 @@ persona:
     - Follow Conventional Commits for all git operations
     - Treat Figma Make output as triage material, not production code
     - "Comprehension Gate: Before delegating to any agent, skill, or workflow, first understand what needs to be done — read relevant code, docs, and state; document findings; only then route"
+    - "Stack como contrato: toda decisão técnica respeita docs/stack.md; alterações de stack exigem ADR explícita e flag --allow-arch-change"
+    - "Paths via config: nada hardcoded — todos os caminhos do projeto-cliente vêm de .gos-local/plan-paths.json"
 
 # ─── COMPREHENSION GATE ──────────────────────────────────────
 # Applies before any delegation to agent, skill, or workflow.
@@ -90,6 +92,8 @@ comprehension_gate:
   trigger: "Before any delegation to agent, skill, or workflow"
   protocol:
     step_0_scan: "Read relevant files, docs, recent commits related to the request"
+    step_0_5_stack: "If routing to planning/implementation: load docs/stack.md (path from .gos-local/plan-paths.json). If absent, abort and dispatch stack-profiler refresh."
+    step_0_6_progress: "If progress.txt exists at the configured path: read it for active plan/task context (memória L1)."
     step_1_document: "State what exists (current state, patterns, constraints) in factual terms"
     step_2_assess: "Determine which agent/skill/workflow is appropriate based on evidence, not assumption"
     step_3_delegate: "Route with context summary so the target has full picture"
@@ -186,6 +190,22 @@ routing_matrix:
     triggers: [architecture, system design, technical design, ADR]
     target: agent:architect
 
+  stack_profile:
+    triggers: [stack, stack profile, refresh stack, stack drift, stack-of-record]
+    target: skill:stack-profiler
+    notes: Run on first setup or whenever stack changes (libs, framework, ORM, auth, hosting)
+
+  plan_creation:
+    triggers: [plan, plano, screen plan, tela, criar plano, blueprint, plano de tela]
+    target: skill:plan-blueprint
+    pre_action: Validate docs/stack.md exists; if not, dispatch stack-profiler first
+    notes: 1 tela = 1 plano. Subdivide automaticamente quando há múltiplas seções autônomas
+
+  progress_tracking:
+    triggers: [progress, status, progress.txt, memoria curta, l1]
+    target: skill:progress-tracker
+    notes: State machine pendente → em-andamento → validacao → concluido
+
   product_decisions:
     triggers: [PRD, requirements, product decision, scope, feature priority]
     target: agent:po
@@ -262,6 +282,17 @@ commands:
     args: "[plan|status|sync]"
     description: Sprint operations via ClickUp integration
 
+  # Plan pipeline (stack-aware)
+  - name: stack
+    args: "[refresh|show|drift]"
+    description: Mantém docs/stack.md (stack-of-record do projeto)
+  - name: plan
+    args: "<tela|figma-url|descricao> [--from-figma-mcp] [--allow-arch-change]"
+    description: Cria plano por tela (plan + tasks + context + progress.txt)
+  - name: progress
+    args: "[init|show|set <plan>|status <task> <novo-status>|compact|read]"
+    description: Gerencia progress.txt (memória L1) e state machine de status
+
   # Quality
   - name: check
     args: "[tsc|tests|all]"
@@ -297,7 +328,7 @@ available_squads:
   - name: git-operations
     purpose: SSH setup, quality gate, safe commit+push
 
-# ─── AVAILABLE SKILLS (15) ────────────────────────────────────
+# ─── AVAILABLE SKILLS (18) ────────────────────────────────────
 available_skills:
   - design-to-code
   - figma-implement-design
@@ -314,6 +345,9 @@ available_skills:
   - plan-to-tasks
   - agent-teams
   - git-ssh-setup
+  - stack-profiler
+  - plan-blueprint
+  - progress-tracker
 
 # ─── PLAYBOOKS ────────────────────────────────────────────────
 available_playbooks:
@@ -321,6 +355,7 @@ available_playbooks:
   - sprint-planner-playbook.md
   - squad-pipeline-runner.md
   - ssh-multi-account-setup.md
+  - plan-creation-playbook.md
 
 # ─── SCRIPTS & TOOLS ─────────────────────────────────────────
 scripts:
@@ -336,6 +371,15 @@ scripts:
     - name: clickup.js
       path: scripts/tools/clickup.js
       purpose: ClickUp API v2 CLI for sprint/task management
+    - name: plan-paths.js
+      path: scripts/tools/plan-paths.js
+      purpose: Resolve paths do projeto-cliente (.gos-local/plan-paths.json)
+    - name: plan-status.js
+      path: scripts/tools/plan-status.js
+      purpose: State machine de status (pendente → em-andamento → validacao → concluido)
+    - name: stack-scan.js
+      path: scripts/tools/stack-scan.js
+      purpose: Inferir stack do projeto-cliente (auxilia stack-profiler)
 
 # ─── SECURITY ─────────────────────────────────────────────────
 security:
@@ -402,6 +446,12 @@ security:
 - `*sprint status` - Check sprint progress
 - `*sprint sync` - Sync with ClickUp
 
+**Plan pipeline (stack-aware):**
+
+- `*stack [refresh|show|drift]` - Mantém docs/stack.md
+- `*plan <tela|figma-url|descrição>` - Cria plano por tela
+- `*progress [show|set|status|compact]` - Gerencia progress.txt (L1)
+
 **Framework:**
 
 - `*doctor` - Health check (gos-cli.js doctor)

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

@@ -0,0 +1,122 @@
+# Playbook — Criação de planos por tela
+
+Pipeline determinístico do G-OS para transformar uma tela (Figma, descrição, screenshot) em `{plano + tasks + contexto + entrada-progress}` respeitando a stack-of-record do projeto.
+
+## Quando usar
+
+- Toda nova tela em projeto que consome o G-OS
+- Reescrita ou refatoração de tela existente
+- Cada tela = 1 plano (subdividido em filhos quando complexa)
+
+## Pré-requisitos do workspace
+
+1. `.gos-local/plan-paths.json` configurado (paths do projeto + `knowledge_sources`)
+2. `docs/stack.md` válido e sem drift (gerado por `stack-profiler`)
+3. `progress.txt` na raiz (criado automaticamente no primeiro `*plan`)
+
+## Fluxo end-to-end
+
+### 0. Bootstrap (uma vez por workspace)
+
+```
+*stack refresh
+```
+
+Lê configs do projeto + `knowledge_sources` (Postman, regras-de-negocio, ADRs, design system) e grava `docs/stack.md` + `.gos-local/stack.lock.json`.
+
+Se `plan-paths.json` ausente, a skill cria interativamente.
+
+### 1. Verificar drift antes de planejar
+
+```
+*stack drift
+```
+
+Se houver drift, decidir entre:
+- `*stack refresh` (atualizar stack.md, planos antigos ficam com stack_ref antigo — ok)
+- ignorar e prosseguir (apenas se a mudança não afeta a tela)
+
+### 2. Criar plano
+
+```
+*plan <tela|figma-url|descrição>
+```
+
+`plan-blueprint` executa:
+1. Fase 1 — Mapeamento Visual & Componentização
+2. Fase 2 — Aderência à Stack (sem redefinir arquitetura)
+3. Fase 3 — Plano de Execução
+
+Saídas:
+- `<dirs.planos>/PLAN-NNN-<slug>/plan.md`
+- `<dirs.planos>/PLAN-NNN-<slug>/context.md`
+- `<dirs.planos>/PLAN-NNN-<slug>/tasks/T-NNN-NN-*.md`
+- `progress.txt` atualizado com plano ativo
+
+### 3. Revisar e aceitar
+
+Humano revisa:
+- componentes mapeados x ausentes
+- aderência à stack (especialmente endpoints/regras)
+- checklist de aceite
+
+Se aprovado, prosseguir. Caso contrário: ajustar manualmente ou rerodar `*plan` com refinamento.
+
+### 4. Executar tasks
+
+Para cada task, dev (humano ou LLM):
+
+```
+*progress status T-NNN-NN em-andamento
+```
+
+Implementa, commita localmente (sem push), atualiza:
+
+```
+*progress status T-NNN-NN validacao
+```
+
+### 5. Validação
+
+Quando todas as tasks do plano estiverem `validacao` e o checklist do plano estiver completo:
+
+```
+*progress status PLAN-NNN-<slug> validacao
+```
+
+Validação humana + QA. Se aprovado:
+
+```
+*progress status PLAN-NNN-<slug> concluido
+```
+
+(Status `concluido` SOMENTE após validação. Antes disso, qualquer task/plano fica em `validacao`.)
+
+### 6. Commit & resumo
+
+`devops` skill prepara commit (não pusha). Resumo do que foi feito é gerado a partir das tasks `concluido` desde o último commit.
+
+## Regras invioláveis
+
+1. **Stack como contrato** — toda decisão respeita `stack.md`. Mudança de stack exige ADR e flag `--allow-arch-change`.
+2. **Read-only respeitado** — se `stack.md` declara backend read-only, plano nunca propõe migration.
+3. **State machine dura** — `concluido` só após validação humana.
+4. **Paths via config** — nada hardcoded; tudo de `plan-paths.json`.
+5. **`progress.txt` é L1** — denso, otimizado para LLM, sempre atualizado.
+
+## Troubleshooting
+
+| Sintoma | Causa provável | Ação |
+|---------|----------------|------|
+| `*plan` aborta com "stack.md ausente" | Bootstrap não rodou | `*stack refresh` |
+| Drift detectado constantemente | `package.json` muda muito | Aceitar drift e rerunar refresh por sprint |
+| Task `concluido` sem passar por `validacao` | Tentativa de bypass | State machine bloqueia — usar `--rollback` se for engano |
+| Plano referencia endpoint que não existe | Postman desatualizado | Atualizar coleção, `*stack refresh`, replanejar |
+
+## Skills relacionadas
+
+- `stack-profiler` — produz/mantém `stack.md`
+- `plan-blueprint` — cria plano por tela
+- `plan-to-tasks` — decompõe plano em tasks (chamada automaticamente)
+- `progress-tracker` — gerencia `progress.txt`
+- `clickup` — sync opcional para tracking externo (não obrigatório)

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

@@ -0,0 +1,144 @@
+---
+name: plan-blueprint
+description: Cria um plano padronizado para uma tela (1 plano = 1 tela) seguindo a stack-of-record do projeto. Produz {plano, tasks, contexto, entrada-progress.txt} em três fases (Mapeamento → Aderência à stack → Execução). Pré-requisito duro: docs/stack.md existir. Subdivide automaticamente telas com seções autônomas múltiplas.
+argument-hint: "<tela|figma-url|descrição> [--from-figma-mcp] [--allow-arch-change]"
+allowedTools: [Read, Glob, Grep, Bash, Write, Edit, Agent, AskUserQuestion]
+sourceDocs:
+  - templates/planTemplate.md
+  - templates/contextTemplate.md
+  - playbooks/plan-creation-playbook.md
+use-when:
+  - criar plano de implementação para uma tela específica
+  - input começa com URL Figma (auto-detectado)
+  - planejar feature de UI com componentes do design system
+do-not-use-for:
+  - planejamento de sprint inteira (use sprint-planner)
+  - decomposição de plano pronto em tasks (use plan-to-tasks)
+  - alterações que mudam stack (gerar ADR primeiro, depois rodar com --allow-arch-change)
+metadata:
+  category: planning
+---
+
+Você está executando como **Tech Lead Frontend / Arquiteto Sênior** via skill `plan-blueprint`.
+
+## Input
+
+$ARGUMENTS
+
+Auto-detecção de input:
+- URL `https://www.figma.com/...` → ativa modo Figma MCP
+- caminho de arquivo `.md`/`.png`/`.jpg` → modo descrição com referência visual
+- texto livre → modo descrição
+
+Flags:
+- `--from-figma-mcp` — força leitura via Figma MCP
+- `--allow-arch-change` — libera Fase 2 propositiva (gera ADR)
+
+## Pré-requisitos (gate)
+
+1. Resolver paths via `.gos-local/plan-paths.json` (criar se ausente).
+2. **Verificar `docs/stack.md` (caminho de `dirs.stack`)**:
+   - Se ausente: ABORTAR. Despachar `stack-profiler refresh` e instruir o usuário a re-executar.
+   - Se presente: ler integralmente. Verificar drift via `*stack drift` antes de prosseguir.
+3. Ler `progress.txt` se existir (memória L1).
+
+## Fase 1 — Mapeamento Visual & Componentização
+
+### 1.1 Carregar referências do design system
+
+Ler (paths via `plan-paths.json`):
+- `dirs.design_system_doc`
+- `dirs.components/` (inspecionar nomes e props)
+- `dirs.stories/` (entender padrões de uso)
+
+### 1.2 Analisar a tela
+
+Se Figma MCP ativo: invocar Figma MCP para extrair árvore de nodes.
+Caso contrário: trabalhar pela descrição/screenshot fornecido.
+
+### 1.3 Mapear componentes
+
+Produzir tabela:
+
+| Elemento (Figma/descrição) | Componente do DS | Variant | Props relevantes |
+|----------------------------|------------------|---------|-------------------|
+
+Listar **componentes ausentes** separadamente — sinalizar como bloqueio ou candidato a criação (vai virar task própria).
+
+## 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:
+
+- Endpoint/tabela/serviço já existente (consultando `knowledge_sources` — Postman, regras-de-negócio, schema)
+- Padrão de fetching a usar (do `stack.md`)
+- Server vs Client component (do `stack.md`)
+
+Saída desta fase é uma seção **"Aderência à Stack"** no plano — não redefine arquitetura.
+
+**Modo `--allow-arch-change`**: pode propor alteração. Gerar ADR em `dirs.adr` (template `templates/adr-tmpl.yaml`) ANTES de prosseguir. Plano referencia o ADR e marca `arch_change: true` no frontmatter.
+
+## Fase 3 — Plano de Execução
+
+Para cada elemento mapeado:
+
+1. Estrutura de pastas/rotas (seguindo convenções de `stack.md`)
+2. Lógica de fetching (onde o data source é chamado)
+3. Montagem da view (composição dos componentes do DS)
+4. Estado e interatividade (client components estritamente onde necessário)
+
+## 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:
+
+- Plano pai: `PLAN-NNN-<slug>` (visão geral + checklist consolidado)
+- Filhos: `PLAN-NNN.1-<slug>`, `PLAN-NNN.2-<slug>` (cada um com suas tasks)
+
+Frontmatter linka via `parent_plan` / `children_plans`.
+
+## Saída
+
+Para cada plano (incluindo filhos):
+
+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).
+4. Disparar `progress-tracker set-current` apontando o plano novo → atualiza `progress.txt`.
+
+Resumo final:
+
+```
+## Plano criado: PLAN-042-checkout
+
+- plan.md:    docs/plans/PLAN-042-checkout/plan.md
+- context.md: docs/plans/PLAN-042-checkout/context.md
+- tasks/:     docs/plans/PLAN-042-checkout/tasks/ (5 tasks)
+- progress:   atualizado (status=pendente)
+- stack_ref:  docs/stack.md@a1b2c3d
+
+Próximos passos:
+1. Revisar plan.md e checklist de aceite
+2. *progress status T-042-01 em-andamento
+3. Executar
+```
+
+## Regras críticas
+
+- **Reuso estrito**: priorizar componentes existentes. Componente novo só com justificativa no plano.
+- **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.
+
+## Model guidance
+
+| Escopo | Modelo |
+|--------|--------|
+| Tela simples (1 form, 1 listagem) | `sonnet` |
+| Tela complexa, subdivisão necessária | `opus` |
+| Replanejamento incremental | `sonnet` |
+
+## Instructions
+
+1. NUNCA prosseguir sem `stack.md` válido.
+2. Resolver TODOS os paths via `plan-paths.json`.
+3. Status inicial do plano e tasks: `pendente`.
+4. Não pushar nada — apenas escrever arquivos locais.

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

@@ -23,9 +23,9 @@ $ARGUMENTS
 
 ### Phase 1 — Read & understand the input
 1. If `$ARGUMENTS` is a file path, read that file. If it's a description, work from the description.
-2. Read `./.G-OS/agents/tasks-writer.system.md` to internalize the DoD for tasks.
-3. Read `./.G-OS/templates/taskTemplate.md` to get the exact format.
-4. Read `./.G-OS/tasks/README.md` (if it exists) to understand the current task naming convention.
+2. Resolver paths via `.gos-local/plan-paths.json` (helper: `scripts/tools/plan-paths.js`). Se ausente, criar com defaults.
+3. Read `templates/taskTemplate.md` (canonical do framework) para o formato exato — superseda qualquer template legado em `.G-OS/templates/`.
+4. Se o input for um plano gerado por `plan-blueprint`, herdar `plan_id` do frontmatter para encadear `T-NNN-NN` corretamente.
 
 ### Phase 2 — Decompose into tasks
 Analyze the plan and extract:
@@ -41,15 +41,15 @@ Rules:
 
 ### Phase 3 — Generate task files
 
-For each task, create a file following the project docs convention:
+For each task, create a file following o caminho resolvido em `plan-paths.json`:
 
-**Primary location (per-project):** `docs/tasks/NN-name/TASK-NN-desc.md`
-Where `NN` matches the plan prefix and tasks use zero-padded sequence (01, 02, ...).
+**Primary location:** `<dirs.tasks>` com `{plan}` substituído pelo `plan_id` do plano (ex.: `docs/plans/PLAN-042-checkout/tasks/T-042-01-<slug>.md`).
 
-**Fallback (framework tasks):** `./.G-OS/tasks/TASK-<YYYYMM>-<seq>.md`
-Use only if `docs/tasks/` does not exist or for framework-internal tasks.
+**Fallback** (apenas se rodando sem `plan-paths.json` ou para tasks internas do framework): `./.gos/data/tasks/T-<YYYYMM>-<seq>.md`.
 
-Use this template (from `./.G-OS/templates/taskTemplate.md`):
+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`):
 
 ```markdown
 ---

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

@@ -0,0 +1,125 @@
+---
+name: progress-tracker
+description: Gerencia progress.txt como memória L1 (curta, otimizada para LLM) na raiz do projeto-cliente. Suporta init, set-current, update-status (state machine), compact e read. Sempre consultado quando há dúvida sobre plano/task ativo.
+argument-hint: "[init|show|set <plan>|status <task> <novo-status>|compact|read]"
+allowedTools: [Read, Write, Edit, Bash]
+sourceDocs:
+  - templates/progressTemplate.txt
+  - playbooks/plan-creation-playbook.md
+use-when:
+  - inicializar progress.txt no workspace
+  - definir qual plano está ativo
+  - transicionar status de plano/task
+  - LLM com dúvida sobre o que está sendo feito
+  - compactar progress.txt removendo tasks concluídas antigas
+do-not-use-for:
+  - planejamento (plan-blueprint)
+  - decomposição (plan-to-tasks)
+  - leitura de stack (stack-profiler)
+metadata:
+  category: project-context
+---
+
+Você está executando a skill `progress-tracker`. Mantém a memória L1 do projeto.
+
+## Conceito
+
+`progress.txt` é a **memória de curta duração** que toda LLM consulta quando precisa saber:
+- qual plano está ativo
+- qual task está em execução
+- o que foi feito por último
+- o que vem a segur
+- bloqueios atuais
+
+Formato denso, sem prosa, otimizado para tokens. Inspirado em `caveman-main` e `sandeco-token`. Localização default: raiz do projeto-cliente (path resolvido em `dirs.progress` do `plan-paths.json`).
+
+## State machine
+
+```
+pendente → em-andamento → validacao → concluido
+```
+
+Transições válidas:
+- `pendente → em-andamento`: livre
+- `em-andamento → validacao`: requer commit preparado (não pushado)
+- `validacao → concluido`: requer aprovação humana
+- `* → pendente`: rollback (libera a transição via flag `--rollback`)
+
+Transições inválidas falham com mensagem do helper `scripts/tools/plan-status.js`.
+
+## Subcomandos
+
+### `init`
+
+Cria `progress.txt` se ausente, usando `templates/progressTemplate.txt`. Não sobrescreve se já existir.
+
+### `show` (default)
+
+Imprime `progress.txt`.
+
+### `set <plan-id>`
+
+Fixa o plano ativo. Ex.: `*progress set PLAN-042-checkout`. Atualiza:
+- `plan_active=<dirs.planos>/<plan-id>/plan.md`
+- `tasks_dir=<dirs.planos>/<plan-id>/tasks/`
+- `context=<dirs.planos>/<plan-id>/context.md`
+- `status=pendente` (se for primeira ativação)
+
+### `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`.
+
+### `compact`
+
+Reescreve `progress.txt` removendo tasks `concluido` antigas (manter < 4kB). Mantém apenas:
+- plano ativo
+- últimas 3 tasks `concluido`
+- todas tasks `em-andamento`/`validacao`/`pendente` do plano ativo
+- bloqueios e notas curtas
+
+### `read`
+
+Mesmo que `show`. Disponível como verbo explícito para integração com `comprehension_gate` do gos-master.
+
+## Formato `progress.txt`
+
+```
+# progress.l1
+ts=2026-05-01T18:22:00-03:00
+project=<nome>
+plan_active=docs/plans/PLAN-042-checkout/plan.md
+tasks_dir=docs/plans/PLAN-042-checkout/tasks/
+context=docs/plans/PLAN-042-checkout/context.md
+stack_ref=docs/stack.md@a1b2c3d
+status=em-andamento
+
+last_done=T-042-03 montar-form-pagamento
+current=T-042-04 integrar-supabase-orders
+next=T-042-05 estado-erro-checkout
+
+blockers=
+notes=fetch usa server component em app/checkout/page.tsx
+```
+
+## Regras
+
+- Sempre resolver `dirs.progress` via `plan-paths.json` antes de ler/escrever.
+- Nunca remover bloqueios sem confirmação.
+- `compact` só remove `concluido` antigas — nunca toca `em-andamento`.
+- Toda alteração registra `ts` em ISO 8601.
+
+## Saída
+
+Após qualquer alteração, mostrar diff curto:
+
+```
+[progress] PLAN-042-checkout / T-042-03 → concluido
+last_done=T-042-03 montar-form-pagamento
+current=T-042-04 integrar-supabase-orders
+```
+
+## Instructions
+
+1. Skill silenciosa — não tagarela, devolve estado.
+2. State machine é dura — bloquear transições inválidas.
+3. Nunca apagar `progress.txt` sem `compact` explícito.

package/.gos/skills/registry.json

@@ -19,6 +19,9 @@
     { "slug": "git-ssh-setup", "path": "skills/git-ssh-setup/SKILL.md" },
     { "slug": "humanizer", "path": "skills/humanizer/SKILL.md" },
     { "slug": "weekly-update", "path": "skills/weekly-update/SKILL.md" },
-    { "slug": "slack-review", "path": "skills/slack-review/SKILL.md" }
+    { "slug": "slack-review", "path": "skills/slack-review/SKILL.md" },
+    { "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" }
   ]
 }

package/.gos/skills/stack-profiler/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: stack-profiler
+description: Produz e mantém docs/stack.md como fonte canônica da stack-of-record do projeto. Lê arquivos de configuração, design system, Postman, regras de negócio e ADRs (paths resolvidos via .gos-local/plan-paths.json). Usar antes de criar planos ou quando a stack do projeto mudou.
+argument-hint: "[refresh|show|drift]"
+allowedTools: [Read, Glob, Grep, Bash, Write, Edit, AskUserQuestion]
+sourceDocs:
+  - templates/stackTemplate.md
+  - playbooks/plan-creation-playbook.md
+use-when:
+  - primeiro setup do projeto no fluxo de planos do G-OS
+  - stack mudou (libs, framework, ORM, auth, hosting)
+  - drift detectado entre stack.md e arquivos-fonte
+  - antes de qualquer execução de plan-blueprint sem stack.md presente
+do-not-use-for:
+  - decisões pontuais de tela (use plan-blueprint)
+  - alteração de stack (gera ADR, não rerruna profiler cego)
+metadata:
+  category: project-context
+---
+
+Você está executando a skill `stack-profiler`. Ela define o contrato técnico do projeto que todas as demais skills do pipeline de planos respeitam.
+
+## Input
+
+$ARGUMENTS
+
+Subcomandos:
+- `refresh` (default) — varre fontes e (re)escreve `docs/stack.md`
+- `show` — imprime o `stack.md` atual
+- `drift` — compara hashes em `.gos-local/stack.lock.json` com arquivos-fonte; alerta se mudaram
+
+## Pré-requisitos
+
+1. Resolver paths via `.gos-local/plan-paths.json`. Se não existir, criar com defaults e perguntar apenas o que não puder inferir.
+2. Carregar template `templates/stackTemplate.md`.
+
+## Procedimento — `refresh`
+
+### Fase 1 — Ler fontes canônicas
+
+Ler (quando existirem, todos relativos à raiz do projeto-cliente):
+- `package.json`, `tsconfig*.json`
+- `next.config.*`, `vite.config.*`, `tailwind.config.*`, `postcss.config.*`
+- `prisma/schema.prisma`, `drizzle.config.*`, `supabase/`
+- `README.md`, `CLAUDE.md`
+- Cada `knowledge_sources[].path` declarado em `plan-paths.json`:
+  - `design-system` — extrair tokens, componentes-chave
+  - `postman` — listar coleções e endpoints expostos (extrair `name`, `request.method`, `request.url.raw`)
+  - `business-rules` — listar arquivos com títulos/escopos
+  - `adr` — listar ADRs ativas
+
+### Fase 2 — Inferir e perguntar
+
+Inferir automaticamente:
+- Framework principal e versão (`dependencies` em package.json)
+- Runtime (Node, Bun, Edge)
+- ORM efetivo (Prisma, Drizzle, Supabase client)
+- UI lib + design system
+- Hosting (vercel.json, netlify.toml, Dockerfile)
+
+Perguntar ao usuário (apenas o que não conseguir inferir, em uma única rodada):
+- Auth provider efetivo
+- Padrão preferido de fetching (server component, server action, client + SWR, etc.)
+- Backend é read-only para a aplicação (sem criar schema novo)?
+- Restrições explícitas (ex.: "não introduzir novas libs sem ADR")
+
+### Fase 3 — Gravar `stack.md`
+
+Caminho: o que estiver em `dirs.stack` do `plan-paths.json` (default `docs/stack.md`).
+
+Seções obrigatórias (ver `templates/stackTemplate.md`):
+1. Framework & runtime
+2. UI / Design System (com link para o doc canônico)
+3. Estado & dados
+4. Auth
+5. Backend / DB (incluir flag `read_only: true|false`)
+6. Padrões de fetching
+7. Convenções de pastas e rotas
+8. Fontes de conhecimento do projeto (lista cada `knowledge_source` com path resolvido + resumo)
+9. Restrições
+10. Links internos (docs, ADRs ativas)
+
+### Fase 4 — Atualizar lock
+
+Gravar `.gos-local/stack.lock.json`:
+
+```json
+{
+  "schema": "gos.stack-lock.v1",
+  "generated_at": "<iso>",
+  "stack_path": "<dirs.stack>",
+  "sources": [
+    { "path": "package.json", "sha256": "..." },
+    { "path": "docs/postman/Fractus.postman_collection.json", "sha256": "..." }
+  ]
+}
+```
+
+## Procedimento — `drift`
+
+1. Ler `.gos-local/stack.lock.json`.
+2. Recalcular sha256 de cada `sources[].path`.
+3. Listar mudanças. Se houver, sugerir `*stack refresh` e listar planos com `stack_ref` divergente (escanear `dirs.planos`).
+
+## Procedimento — `show`
+
+Imprimir o conteúdo de `dirs.stack`. Se ausente, instruir `*stack refresh`.
+
+## Saída
+
+Após `refresh`:
+
+```
+## Stack profilada — <projeto>
+
+- Framework: Next.js 15 (App Router)
+- DB: Supabase (read-only)
+- Design System: .referencia-storybook
+- Knowledge sources: 3 (postman, business-rules, adr)
+
+stack.md: docs/stack.md
+lock: .gos-local/stack.lock.json
+hashes: 12 arquivos
+```
+
+## Model guidance
+
+| Escopo | Modelo |
+|--------|--------|
+| Refresh em projeto pequeno/médio | `sonnet` |
+| Projeto grande com muita ambiguidade | `opus` |
+| `show` / `drift` | `haiku` |
+
+## Instructions
+
+1. Sempre resolver paths via `plan-paths.json` antes de tocar filesystem do projeto.
+2. Não inventar tecnologia — se não conseguir inferir, perguntar.
+3. Nunca propor mudança de stack neste skill — só registrar o que existe.

package/.gos/skills/weekly-update/CHANGELOG.md

@@ -1,5 +1,33 @@
 # weekly-update — Changelog
 
+## 2026-04-20 — v1.2.1 (refinamento do modo simple após envio validado)
+
+Após o primeiro envio real em modo `simple` (mesma data), Douglas ajustou manualmente a versão gerada antes de enviar. Ajustes virando regras permanentes:
+
+### Mudanças nas regras do modo simple
+
+1. **Bullet markers opcionais**: removida obrigatoriedade de `•`. Quebra de linha entre itens é suficiente e preferível — Slack renderiza limpo.
+2. **Tom casual/neutro misturado**: `pra/tá/tô` não são mais mandatórios. Mistura natural com `para/está/estou` é validada e soa melhor.
+3. **Termos contextualmente aceitos** (nova categoria, entre banidos e permitidos):
+   - `PRD` — PO/PM usam, mantém.
+   - `front`/`backend` — aceitáveis quando linguagem corrente do time.
+   - `Storybook` — aceitável se nome de produto; senão trocar por "catálogo de componentes".
+4. **Voz ativa primeira pessoa obrigatória**: "Criei e enviei" > "Entreguei" > "Foi entregue". Evitar passiva.
+5. **Tamanho alvo ajustado**: 200-350 palavras (antes 150-250). Completude vale mais que concisão extrema — cobrir todas as entregas e pendências.
+
+### Exemplo canônico arquivado
+
+`.gos/weekly-updates/2026-04-20.md` — versão final enviada por Douglas com ajustes. Frontmatter documenta os ajustes aplicados. SKILL.md passa a referenciar esse arquivo como exemplo autoritativo (substitui o rascunho anterior curto).
+
+### Diff vs v1.2.0
+
+- Regras 3/4/5 do modo simple reescritas.
+- Nova regra 3 (termos contextualmente aceitos) intercalada.
+- Alvo subiu de 150-250 para 200-350 palavras.
+- Exemplo canônico agora é o envio real, não um rascunho.
+
+---
+
 ## 2026-04-20 — v1.2.0 (modos `simple` e `detailed`, controlados por env)
 
 Motivação: na thread "Conversa semanal" de 2026-04-17, PO (U07M07M6R42) e PM (U0ADE3FT9HB) pediram explicitamente resumo em linguagem não-técnica. Citações literais:

package/.gos/skills/weekly-update/SKILL.md

@@ -10,7 +10,7 @@ description_pt-BR: >
   com aprovacao antes de postar na Conversa semanal do Slack. Modo simple ou detailed.
 argument-hint: "[--mode simple|detailed] [link da mensagem 'Conversa semanal' no Slack]"
 type: prompt
-version: "1.2.0"
+version: "1.2.1"
 env:
   - WEEKLY_UPDATE
   - WEEKLY_UPDATE_MODE
@@ -190,41 +190,46 @@ Audiência: PO/PM sem background técnico, clientes, time de negócio.
 Regras **obrigatórias** (violar qualquer uma implica reescrever):
 
 1. **Zero IDs de task.** Nunca mencionar "T-084", "T-110", "task X". Só o que foi entregue, em linguagem de valor.
-2. **Zero jargão técnico.** Banidos: API, endpoint, FK, foreign key, hook, webhook, migration, deploy, pipeline, CI/CD, TypeScript, Zod, Storybook (a menos que seja nome conhecido do produto), backend, frontend, regex, SPA routing, commit, branch, merge, PR, rebase, drift, build. Traduzir cada um:
+2. **Zero jargão técnico de baixo nível.** Banidos sempre: API, endpoint, FK, foreign key, hook, webhook, migration, pipeline, CI/CD, TypeScript, Zod, regex, SPA routing, commit, branch, merge, PR, rebase, drift, build, deploy. Traduzir cada um:
    - "API de diagnóstico" → "formulário de diagnóstico" ou "ferramenta pra coletar dados do diagnóstico"
-   - "Deploy no Vercel" → "publicar a página online"
+   - "Deploy no Vercel" → "publicar a página online" ou "colocar online"
    - "Corrigi o SPA routing" → "arrumei a navegação entre telas que estava quebrada"
-   - "Hook de pre-commit" → "trava automática que impede erros de passar"
-   - "Migration" → "ajuste no banco de dados" (se precisar) ou omitir
+   - "Hook de pre-commit" → "trava automática que impede erros de passar adiante"
+   - "Migration" → "ajuste no banco de dados" (quando inevitável) ou omitir
    - "Regras de negócio em doc próprio" → "organizei as regras do produto num documento pra validar com o time"
-3. **Bullets curtos**, não parágrafos densos. Cada bullet com 1 linha, no máximo 2. Inspirado no tom do PM do time:
-   > • Sigo trabalhando nas telas do figma.
-   > • Nessa semana liberei PRD Novo e novo padrão no Figma.
-   > • Agora to trabalhando nuns ajustes que o Adri pediu.
-4. **Foco no valor entregue**, não em como foi feito. Em vez de "configurei X e corrigi Y", usar "agora Z funciona / está disponível / está mais rápido".
-5. **Tom de reunião casual.** Primeira pessoa (eu/a gente), contrações permitidas ("pra", "to", "tá"), sem formalismo corporativo.
-6. Tamanho alvo: 150-250 palavras.
+3. **Termos contextualmente aceitos** (use com moderação — só quando a audiência já conhece do produto):
+   - `PRD` — PO/PM usam o termo.
+   - `front`/`backend` — aceitáveis quando já é linguagem corrente do time (ver exemplo do envio 2026-04-20).
+   - `Storybook` — aceitável se é nome de produto/catálogo conhecido; caso contrário, traduzir pra "catálogo de componentes".
+   - Se na dúvida, traduzir. Regra: PO/PM deve entender sem parar pra perguntar.
+4. **Linhas curtas, sem bullet markers obrigatórios.** Cada linha com 1 frase, no máximo 2. Slack renderiza quebras de linha limpas sem `•` — preferível ao marcador visual. O PM do time usa `•` em algumas mensagens e não em outras; siga o padrão do autor do envio (default: sem marcador, só quebra de linha).
+5. **Voz ativa primeira pessoa.** Preferir "Criei e enviei pra X" sobre "Foi entregue pra X". Preferir "Arrumei" sobre "Foram feitos ajustes".
+6. **Foco no valor entregue**, não em como foi feito. Em vez de "configurei X e corrigi Y", usar "agora Z funciona / está disponível / está mais rápido".
+7. **Tom reunião casual, mas não forçado.** Primeira pessoa (eu/a gente). Contrações permitidas (`pra`, `tá`, `tô`) mas não obrigatórias — mistura com forma neutra (`para`, `está`, `estou`) é natural e foi validado no envio 2026-04-20. Evitar formalismo corporativo ("foi realizada a entrega de...").
+8. Tamanho alvo: 200-350 palavras. Preferência por completude (cobrir todas as entregas e pendências) sobre concisão extrema.
 
 Teste de validação (aplicar mentalmente antes de aprovar):
 - Se minha mãe lesse esse texto, ela entenderia o que eu fiz essa semana? Se não, reescrever.
 - Se o PO leu e vai perguntar "o que é X?" — termo X é jargão, trocar.
+- Dupla checagem: se PO/PM usam o termo em mensagens próprias na thread, pode manter (ex: PRD).
+
+Exemplo canônico — envio validado 2026-04-20 (ver `.gos/weekly-updates/2026-04-20.md` para versão completa):
 
-Exemplo de tom (re-escrita do envio 2026-04-17 em modo simple):
 > *O que foi feito*
 >
-> • Coloquei o catálogo de componentes do Fractus online, com a cara nova (logo e cores).
-> • Organizei as regras do produto num documento próprio pra gente revisar junto na reunião de terça.
-> • Arrumei umas travas automáticas que impedem erros de passar adiante — ficou mais seguro pra todo mundo mexer no código.
-> • Entreguei pro Adriano Morais a ferramenta que extrai contatos de grupo do WhatsApp.
->
-> *Pendências*
->
-> Cinco coisas dependem de decisão da PO/PM pra destravar:
-> 1. Templates/Formulários — aguardando validação do Adriano Morais.
-> 2. Impacto — precisa definir quais métricas entram no MVP.
-> 3. Faturamento — regra de consolidação ainda em aberto.
-> 4. Acesso do Financiador — permissões não definidas.
-> 5. Toggle Ativo — comportamento ao desativar ainda não documentado.
+> Coloquei online o catálogo de componentes do Fractus com a cara nova — logo, cores e a home personalizada. Já plugado nos medidores de desempenho pra gente acompanhar se a página tá rápida.
+> A branch desse catálogo tava bagunçada, arrumei e montei uma trava automática pra não deixar entrar mistura errada de novo.
+> Liguei travas antes de subir código pra evitar que erro passe adiante — quem tentar subir coisa quebrada é avisado na hora.
+> Organizei as regras do produto num documento, usando para validarmos as regras no desenvolvimento do front/backend.
+> Criei e enviei para Adriano Morais uma ferramenta que extrai contatos de grupo do WhatsApp.
+> No nosso framework interno, parei de mandar notificação duplicada no Slack e arrumei a conexão com o ClickUp na IDE nova que eu estou testando.
+
+Padrões a notar nesse envio:
+- Sem marcadores `•`, só quebra de linha entre itens.
+- Mistura `pra/tá` com `para/está` naturalmente.
+- `front/backend` aceito porque é linguagem já corrente do time.
+- Voz ativa primeira pessoa em todos os itens (`Coloquei`, `Arrumei`, `Liguei`, `Criei e enviei`).
+- Comprimento total ~310 palavras (acima do mínimo ajustado de 200-350).
 
 ## Phase 3 — Humanizar
 

package/.gos/templates/contextTemplate.md

@@ -0,0 +1,35 @@
+---
+plan_id: PLAN-<NNN>-<slug>
+generated_at: <iso>
+---
+
+# Contexto — <tela>
+
+> Documento denso para a LLM — não é prosa para humanos. Indexa arquivos, decisões e riscos relevantes para executar o plano sem perder contexto.
+
+## Arquivos relevantes
+
+| Path | Função |
+|------|--------|
+| `<path>` | <função> |
+
+## Componentes do DS já em uso (próximos)
+
+- `<componente>` — usado em `<onde>`
+
+## Endpoints / regras-de-negócio referenciados
+
+- `<endpoint>` — Postman: `<ref>` — método: `<METHOD>`
+- `<regra>` — path: `<ref>`
+
+## Decisões tomadas durante o planejamento
+
+- <decisão> (motivo: <ref>)
+
+## Riscos abertos
+
+- <risco>
+
+## Notas curtas (livre)
+
+- <nota>

package/.gos/templates/planTemplate.md

@@ -0,0 +1,77 @@
+---
+id: PLAN-<NNN>-<slug>
+tela: <nome da tela>
+figma_url: <url ou null>
+status: pendente
+parent_plan: <PLAN-NNN ou null>
+children_plans: []
+stack_ref: docs/stack.md@<sha-curto>
+arch_change: false
+created_at: <iso>
+validated_at: null
+---
+
+# <Título da tela>
+
+## Contexto
+
+<Por que esta tela existe — referência ao PRD, ticket, decisão de produto.>
+
+## Componentes mapeados
+
+| Elemento | Componente do DS | Variant | Props |
+|----------|------------------|---------|-------|
+|          |                  |         |       |
+
+## Componentes ausentes
+
+> Listar componentes não cobertos pelo DS. Cada um vira task de criação separada (priorizar reuso/extensão antes de propor novo).
+
+- <ausente 1 — sugestão: estender X | criar novo>
+
+## Aderência à Stack
+
+> Sem redefinir arquitetura. Apenas referenciar o que já existe em `stack.md`.
+
+- **Dados consumidos**: <endpoint Postman | tabela | regra-de-negocio> — path: <ref>
+- **Padrão de fetching**: <server component | server action | client+cache>
+- **Auth requerida**: <sim/não> — provider: <ref `stack.md`>
+- **Restrições aplicáveis**: <listar do `stack.md`>
+
+> Se `arch_change: true`: ADR de referência: `docs/adr/ADR-XXXX-<slug>.md`
+
+## Fluxo de navegação
+
+- Rota: `<src/app/.../page.tsx>`
+- Entrada: <de onde vem>
+- Saída: <para onde vai>
+
+## Fluxo de dados
+
+```
+<diagrama textual: tela → fetch → componente → render>
+```
+
+## Plano de execução
+
+1. **Estrutura de pastas/rotas** — criar `<path>`
+2. **Fetching** — `<server-component em page.tsx | server-action>` consumindo `<endpoint/tabela>`
+3. **Montagem da view** — compor `<componentes>`
+4. **Estado e interatividade** — `<descrever>`
+
+## Checklist de aceite
+
+- [ ] Tela renderiza com dados reais
+- [ ] Estados de loading e erro tratados
+- [ ] Acessibilidade básica (keyboard nav, aria)
+- [ ] Responsivo (mobile + desktop)
+- [ ] Sem console errors/warnings
+- [ ] TypeScript válido (`tsc --noEmit`)
+- [ ] Reutilização ≥ X% de componentes do DS
+- [ ] <critério específico da tela 1>
+- [ ] <critério específico da tela 2>
+
+## Riscos & Rollback
+
+- <risco>
+- Rollback: <git tag/branch>

package/.gos/templates/progressTemplate.txt

@@ -0,0 +1,15 @@
+# progress.l1
+ts=<iso>
+project=<nome>
+plan_active=<path/plan.md>
+tasks_dir=<path/tasks/>
+context=<path/context.md>
+stack_ref=docs/stack.md@<sha>
+status=pendente
+
+last_done=
+current=
+next=
+
+blockers=
+notes=

package/.gos/templates/stackTemplate.md

@@ -0,0 +1,72 @@
+---
+schema: gos.stack.v1
+project: <nome>
+generated_at: <iso>
+read_only_backend: <true|false>
+---
+
+# Stack-of-record — <projeto>
+
+> Este arquivo é a fonte canônica da stack. Todo plano (`plan-blueprint`) referencia este documento via `stack_ref`. Alterações aqui exigem ADR.
+
+## 1. Framework & runtime
+- Framework: <Next.js 15 / Vite / etc>
+- Runtime: <Node 20 / Bun / Edge>
+- Linguagem: <TypeScript / JavaScript>
+- Build: <turbopack / webpack / vite>
+
+## 2. UI / Design System
+- Lib UI base: <shadcn / radix / mui>
+- Design system path: <path>
+- Tokens: <path ou descrição>
+- Convenção de variants: <tailwind-variants / cva / cn>
+
+## 3. Estado & dados
+- Estado client: <zustand / jotai / context>
+- Cache/data: <swr / react-query / server cache>
+- Forms: <react-hook-form / formik>
+- Validação: <zod / yup>
+
+## 4. Auth
+- Provider: <supabase-auth / clerk / next-auth>
+- Estratégia: <session cookies / jwt>
+- Middleware: <path>
+
+## 5. Backend / DB
+- DB: <supabase / postgres / mongo>
+- ORM: <prisma / drizzle / supabase-js>
+- Read-only?: <sim|não>
+- Migrations: <permitidas|proibidas>
+
+## 6. Padrões de fetching
+- Server components: <quando usar>
+- Server actions: <quando usar>
+- Client + cache: <quando usar>
+- Convenção de erro/loading: <descrever>
+
+## 7. Convenções de pastas e rotas
+- Rotas: <src/app/...>
+- Componentes: <src/components/...>
+- Hooks: <src/hooks/...>
+- Helpers: <src/lib/...>
+
+## 8. Fontes de conhecimento do projeto
+
+> Listadas a partir de `knowledge_sources` em `.gos-local/plan-paths.json`.
+
+| Tipo | Path | Resumo |
+|------|------|--------|
+| design-system | <path> | <resumo> |
+| postman | <path> | <N coleções, M endpoints> |
+| business-rules | <path> | <N módulos> |
+| adr | <path> | <N ADRs ativas> |
+
+## 9. Restrições
+- <ex.: não introduzir nova lib sem ADR>
+- <ex.: não alterar schema sem migration aprovada>
+- <ex.: i18n é obrigatório em toda string visível>
+
+## 10. Links internos
+- README: <path>
+- CLAUDE.md: <path>
+- ADRs ativas: <lista>

package/.gos/templates/taskTemplate.md

@@ -0,0 +1,40 @@
+---
+id: T-<NNN>-<NN>
+plan_id: PLAN-<NNN>-<slug>
+seq: <NN>
+title: <verbo imperativo + objeto>
+area: <ui-ux|frontend|fetching|state|tests|infra>
+labels: [agent:<slug>, type:<feature|refactor|bug|chore>]
+priority: <P0|P1|P2>
+estimate: "<2h|4h|1d>"
+status: pendente
+valida_em: <referência ao critério no checklist do plano>
+assignees: []
+links: []
+---
+
+## Contexto
+
+<Por que esta task existe — referência direta ao plano pai e ao critério de aceite.>
+
+## Objetivo
+
+<Resultado esperado em 1-2 frases.>
+
+## Plano de execução
+
+- [ ] Passo 1
+- [ ] Passo 2
+- [ ] Passo 3
+
+## Critérios de aceitação (DoD)
+
+- [ ] Implementação atende `valida_em` do plano
+- [ ] Tests/CI verdes
+- [ ] Sem regressões
+- [ ] <métrica específica>
+
+## Riscos & Rollback
+
+- <risco>
+- Rollback: <comando>

package/AGENTS.md

@@ -37,6 +37,21 @@ Este repo existe para acelerar design-to-code e entrega de sprint.
 | **plan-to-tasks** | `/gos:skills:plan-to-tasks` | Converte plano em tasks acionaveis |
 | **agent-teams** | `/gos:skills:agent-teams` | Coordena multiplos agentes em time |
 | **git-ssh-setup** | `/gos:skills:git-ssh-setup` | Configura identidade SSH para o workspace |
+| **stack-profiler** | `/gos:skills:stack-profiler` | Mantem `docs/stack.md` (stack-of-record canonica) |
+| **plan-blueprint** | `/gos:skills:plan-blueprint` | Cria plano por tela (1 tela = 1 plano) |
+| **progress-tracker** | `/gos:skills:progress-tracker` | Memoria L1 (`progress.txt`) + state machine |
+
+## Plan Pipeline
+
+Pipeline padronizado para criacao de planos por tela. Stack-of-record (`docs/stack.md`) e contrato — alteracoes exigem ADR.
+
+| Comando | Skill | Funcao |
+|---------|-------|--------|
+| `*stack [refresh\|show\|drift]` | `stack-profiler` | Mantem `docs/stack.md` |
+| `*plan <tela>` | `plan-blueprint` | Cria plano + tasks + context + atualiza `progress.txt` |
+| `*progress [show\|set\|status]` | `progress-tracker` | State machine `pendente -> em-andamento -> validacao -> concluido` |
+
+Paths do projeto-cliente sao resolvidos via `.gos-local/plan-paths.json` (incluindo `knowledge_sources` como Postman, regras-de-negocio, ADRs). Playbook: `.gos/playbooks/plan-creation-playbook.md`.
 
 ## Plan Mode Protocol
 

package/CLAUDE.md

@@ -48,4 +48,20 @@ 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
+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
+
+## Plan Pipeline (stack-aware)
+
+Pipeline padronizado para criacao de planos por tela. Toda tela = 1 plano. Stack-of-record (`docs/stack.md`) e contrato — alteracoes de stack exigem ADR.
+
+| Comando | Skill | Funcao |
+|---------|-------|--------|
+| `*stack [refresh|show|drift]` | `stack-profiler` | Mantem `docs/stack.md` (canonico do projeto) |
+| `*plan <tela>` | `plan-blueprint` | Cria plano + tasks + context + atualiza `progress.txt` |
+| `*progress [show|set|status]` | `progress-tracker` | Memoria L1 + state machine de status |
+
+State machine: `pendente -> em-andamento -> validacao -> concluido` (concluido somente apos validacao humana).
+
+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.
+
+Playbook completo: `.gos/playbooks/plan-creation-playbook.md`

package/README.md

@@ -130,6 +130,62 @@ O `ganbatte-os` utiliza uma estrutura **encapsulada** para manter seu projeto li
 | **git-ssh-setup** | `/gos:skills:git-ssh-setup` | Configura identidade SSH para o workspace |
 | **humanizer** | `/gos:skills:humanizer` | Remove padroes de IA do texto (two-pass audit + soul injection) |
 | **weekly-update** | `/gos:skills:weekly-update` | Resumo semanal de tasks ClickUp → humaniza → posta no Slack (requer aprovacao) |
+| **stack-profiler** | `/gos:skills:stack-profiler` | Mantem `docs/stack.md` como stack-of-record canonica do projeto |
+| **plan-blueprint** | `/gos:skills:plan-blueprint` | Cria plano por tela (1 tela = 1 plano) seguindo a stack |
+| **progress-tracker** | `/gos:skills:progress-tracker` | Memoria L1 (`progress.txt`) + state machine de status |
+
+## Plan Pipeline (stack-aware)
+
+Pipeline padronizado para criacao de planos por tela. Toda tela vira um plano + tasks + contexto, com status auditavel e contrato de stack.
+
+### Fluxo
+
+```
+*stack refresh   →   docs/stack.md (uma vez por workspace, ou quando stack mudar)
+*plan <tela>     →   docs/plans/PLAN-NNN-<slug>/{plan.md, tasks/, context.md} + progress.txt
+*progress ...    →   transicoes pendente → em-andamento → validacao → concluido
+```
+
+| Comando | Skill | Funcao |
+|---------|-------|--------|
+| `*stack [refresh\|show\|drift]` | `stack-profiler` | Mantem `docs/stack.md` (canonico) e `.gos-local/stack.lock.json` |
+| `*plan <tela\|figma-url>` | `plan-blueprint` | Cria plano + dispara `plan-to-tasks` + atualiza `progress.txt` |
+| `*progress [show\|set\|status]` | `progress-tracker` | Memoria L1 e state machine |
+
+### Regras invioiaveis
+
+- **Stack como contrato** — toda decisao tecnica respeita `docs/stack.md`. Mudanca de stack exige ADR e flag `--allow-arch-change`.
+- **Paths via config** — nada hardcoded. Tudo resolvido via `.gos-local/plan-paths.json` (incluindo `knowledge_sources` como Postman, regras-de-negocio, ADRs).
+- **State machine dura** — `concluido` somente apos validacao humana.
+- **`progress.txt` e L1** — denso, otimizado para LLM, atualizado em todo passo.
+
+### Configuracao por workspace
+
+`.gos-local/plan-paths.json` define onde cada projeto guarda seus artefatos. Cada projeto/dev pode organizar diferente:
+
+```json
+{
+  "schema": "gos.plan-paths.v1",
+  "dirs": {
+    "planos": "docs/plans/",
+    "tasks": "docs/plans/{plan}/tasks/",
+    "contexto": "docs/plans/{plan}/context.md",
+    "progress": "progress.txt",
+    "stack": "docs/stack.md",
+    "postman": "docs/postman/",
+    "regras_negocio": "docs/regras-de-negocio/"
+  },
+  "knowledge_sources": [
+    { "kind": "postman",        "path": "docs/postman/",            "required": false },
+    { "kind": "business-rules", "path": "docs/regras-de-negocio/",  "required": false },
+    { "kind": "design-system",  "path": ".referencia-storybook/docs/DESIGN_SYSTEM_REFERENCE.md", "required": true }
+  ]
+}
+```
+
+Helpers: `scripts/tools/plan-paths.js`, `scripts/tools/plan-status.js`, `scripts/tools/stack-scan.js`.
+
+Playbook completo: [`.gos/playbooks/plan-creation-playbook.md`](./.gos/playbooks/plan-creation-playbook.md).
 
 ## Documentacao
 

package/package.json

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