ganbatte-os 0.2.38 → 0.2.42

package/.gos/skills/sprint-planner/SKILL.md

@@ -1,434 +0,0 @@
----
-name: sprint-planner
-description: >
-  Orquestra planejamento completo de sprint a partir de qualquer input (caminhos de projeto,
-  designs Figma, transcricoes, documentos). Gera PRD, ADR, roadmap, schema DBML e backlog
-  executavel com tasks decompostas. Trabalha em loops interativos de descoberta.
-argument-hint: "[caminho do projeto, arquivo de design, transcricao, ou descricao livre]"
-allowedTools: [Read, Glob, Grep, Bash, Write, Edit, Agent, AskUserQuestion]
-sourceDocs:
-  - playbooks/sprint-planner-playbook.md
-  - templates/adr-tmpl.yaml
-  - playbooks/story-creation-playbook.md
-  - playbooks/gsd-agent-decomposition-playbook.md
-use-when:
-  - transformar ideia ou projeto em sprint completa
-  - planejar sprint de projeto novo ou existente (greenfield ou brownfield)
-  - gerar PRD + ADR + roadmap + tasks a partir de qualquer input
-  - receber designs Figma, transcricoes ou documentacao e montar backlog
-  - preparar ambiente completo (contas, credenciais, infra, DBML)
-do-not-use-for:
-  - execucao de tasks ja planejadas — use /sdd ou /compose
-  - refinamento de backlog existente — use @sm ou @po
-  - hotfix ou ajuste pontual sem necessidade de planejamento formal
-  - analise de um unico link — use /link-insight
-metadata:
-  category: workflow-automation
----
-
-# sprint-planner
-
-Voce esta executando a skill `sprint-planner`.
-
-## Conceito
-
-O Sprint Planner e um orquestrador que transforma qualquer input em uma sprint completa
-e executavel. Diferente do SDD (que assume requisitos claros), o Sprint Planner comeca
-com descoberta interativa e constroi o entendimento progressivamente.
-
-**Nao executa codigo** — para apos produzir o pacote completo da sprint.
-Para executar, use `/sdd <PRD.md>` ou `/compose <TASK-NNN>`.
-
-## Task
-
-$ARGUMENTS
-
-Se nenhum input foi fornecido, solicite ao usuario imediatamente.
-
-## Leitura Obrigatoria
-
-Antes de iniciar, leia:
-- `playbooks/sprint-planner-playbook.md` — workflow detalhado com checklists
-- `templates/adr-tmpl.yaml` — template de ADR para fase 3
-- `rules/spec-as-contract.md` — principios do contrato de especificacao
-
-## Phase 0 — Triage & Input Normalization
-
-**Objetivo:** Classificar o input e preparar material para descoberta.
-
-1. Classificar tipo de input recebido:
-
-| Tipo | Deteccao | Acao |
-|------|----------|------|
-| `project-path` | Caminho para codebase | Executar `/project-brief <path>` |
-| `design` | Screenshot, Figma frame, export Figma Make | Analise visual — extrair telas, fluxos, componentes |
-| `transcription` | Texto de reuniao, audio transcrito | Extrair requisitos, fluxos, restricoes, decisoes |
-| `document` | PRD, spec, briefing existente | Ler, sumarizar, identificar gaps |
-| `free-text` | Descricao livre do usuario | Iniciar discovery loop diretamente |
-| `mixed` | Combinacao de tipos acima | Processar cada tipo, consolidar |
-
-2. Gerar `input-analysis.md` com:
-   - Tipo(s) de input detectado(s)
-   - Resumo do material (10-15 linhas)
-   - Gaps identificados (o que falta para planejar)
-   - Prerequisitos para discovery
-
-**Gate:** Input normalizado. Apresentar resumo ao usuario antes de continuar.
-
-## Phase 1 — Discovery (Loops Interativos)
-
-**Objetivo:** Coletar requisitos via loops de 2-3 perguntas por vez.
-
-### Motor de Tecnicas
-
-Em cada loop, selecionar 2-4 tecnicas conforme o estagio e tipo de incerteza:
-
-| Tecnica | Quando usar |
-|---------|-------------|
-| SCQA | Enquadrar contexto rapidamente (Situacao → Complicacao → Questao → Acao) |
-| Analise de Premissas | Quando houver "nao sei", lacunas, ambiguidades ou suposicoes |
-| ReAct | Quando faltar conhecimento de dominio — pesquisar, trazer fontes, confirmar |
-| Task-Oriented Thought | Para decompor entendimento em backlog |
-| Tree of Thoughts | Para gerar opcoes de caminho quando ha multiplas abordagens |
-| Brainstorming Estruturado | Para alternativas e decisoes de escopo |
-| Verificacao de Consistencia | Para checar lacunas entre requisitos e criterios de aceite |
-| Feynman | Para explicar de forma simples a quem nao e tecnico |
-
-### Checklist de Coleta
-
-1. **Contexto**: Qual produto/modulo/tela? Qual problema e por que agora?
-2. **Objetivo**: Qual resultado esperado (metrica/impacto)?
-3. **Usuarios**: Perfis, permissoes e stakeholders
-4. **Escopo**: O que entra e o que NAO entra nesta Sprint
-5. **Fluxos**: Passo a passo do usuario e telas envolvidas
-6. **Regras de negocio**: Validacoes, estados, permissoes
-7. **Dados**: Campos, integracoes, origem/destino, relatorios
-8. **Restricoes**: Prazo, LGPD/compliance, performance, padroes
-9. **Criterios de aceite**: Sucesso/erro/excecao
-10. **Time/capacidade**: Papeis (FE/BE/QA/UX), duracao da Sprint, prioridades
-
-### Formato de Cada Loop
-
-```
-### Tecnicas escolhidas
-- [Tecnica] — (1 frase do porque)
-- [Tecnica] — (1 frase do porque)
-
-### Resultado parcial
-- (5-10 linhas com entendimento e pendencias)
-- Confirmado: [lista]
-- A confirmar: [lista]
-- Pesquisa necessaria: [lista]
-
-### Perguntas
-1. ...
-2. ...
-3. ...
-```
-
-### Diferenciar Fontes
-
-- Confirmado pelo usuario
-- Assumido como padrao de mercado (a confirmar)
-- Baseado em pesquisa (com referencia)
-
-**Gate:** Clarity >= 70% no checklist. Se < 70% apos 4 loops, consolidar o que tem e sinalizar gaps explicitamente no PRD.
-
-## Phase 2 — Requirements Crystallization (PRD)
-
-**Objetivo:** Consolidar descobertas em PRD formal.
-
-1. Gerar `sprint-planner/<slug>/PRD.md` contendo:
-   - Visao geral e objetivo
-   - Problema que resolve
-   - Escopo: IN e OUT (explicito)
-   - Usuarios e perfis
-   - Requisitos funcionais (numerados)
-   - Requisitos nao-funcionais
-   - Criterios de aceite (Given/When/Then)
-   - Dependencias externas
-   - Riscos e assuncoes
-   - **Decisoes Menores (Embedded ADR)**: decisoes que nao justificam arquivo separado, cada uma com contexto, opcoes, escolha e justificativa
-
-2. Reuso: patterns do agente `@pm` (Morgan) e template `prd-for-ralph.template.md`
-
-**Gate:** Usuario aprova PRD antes de avancar. Se houver rejeicao, voltar a Phase 1 para refinar.
-
-## Phase 3 — Architecture & Schema
-
-**Objetivo:** Definir arquitetura, decisoes estruturais e schema de dados.
-
-### ADR (Architecture Decision Records)
-
-Para cada decisao arquitetural significativa (3+ opcoes com trade-offs):
-1. Gerar `sprint-planner/<slug>/ADR-NNN.md` usando template de `templates/adr-tmpl.yaml`
-2. Decisoes tipicas: stack tecnologico, banco de dados, autenticacao, hospedagem, arquitetura de API
-
-Decisoes menores (escolha obvia, < 3 opcoes) ficam embedded no PRD (Phase 2).
-
-### Schema DBML
-
-Se o projeto envolve banco de dados:
-1. Gerar `sprint-planner/<slug>/schema.dbml` em formato DBML
-2. Incluir: tabelas, campos com tipos, relacoes (1:1, 1:N, N:N), indexes, enums
-3. Anotar RLS policies quando aplicavel (Supabase/Postgres)
-4. Exemplo de formato:
-
-```dbml
-Table users {
-  id uuid [pk, default: `gen_random_uuid()`]
-  email varchar [unique, not null]
-  created_at timestamp [default: `now()`]
-}
-
-Table projects {
-  id uuid [pk]
-  owner_id uuid [ref: > users.id]
-  name varchar [not null]
-  status project_status [default: 'draft']
-}
-
-Enum project_status {
-  draft
-  active
-  archived
-}
-```
-
-### APIs
-
-Se o projeto envolve APIs:
-- Listar endpoints: metodo, path, request/response schema, autenticacao
-
-**Gate:** ADR(s) e schema revisados e aprovados pelo usuario.
-
-## Phase 4 — Roadmap Generation
-
-**Objetivo:** Gerar roadmap com fases e prazos realistas.
-
-1. Aplicar logica de `proposals/gerar-roadmap-por-fases-com-prazos`:
-
-| Complexidade | Fases | Duracao tipica |
-|-------------|-------|----------------|
-| Simples | 2-3 | Ate 15 dias |
-| Medio | 4-5 | 15-45 dias |
-| Complexo | 5-6 | 45+ dias |
-
-2. Fases recomendadas por complexidade:
-
-**Simples (2-3 fases):**
-1. Setup & Core
-2. Testes & Deploy
-
-**Medio (4-5 fases):**
-1. Descoberta & Briefing (3-5 dias)
-2. Arquitetura & Setup (5-8 dias)
-3. Desenvolvimento Core (10-15 dias)
-4. Testes, QA & Deploy (5-10 dias)
-
-**Complexo (5-6 fases):**
-1. Descoberta & Briefing (3-5 dias)
-2. Design UX/UI — Figma (5-7 dias, apenas se ha interface)
-3. Arquitetura & Setup (5-10 dias)
-4. Desenvolvimento Core (10-20 dias)
-5. Observabilidade & Integracoes (5-10 dias)
-6. Testes, QA & Go-Live (5-10 dias)
-
-3. Gerar `sprint-planner/<slug>/ROADMAP.md` com fases, duracoes, entregaveis e condicoes de inicio
-
-**Validacao:**
-- Soma das duracoes <= total + 20% margem
-- Cada fase tem pelo menos 1 entregavel concreto
-- Nenhuma fase com menos de 2 dias
-
-**Gate:** Roadmap com fases e prazos validados pelo usuario.
-
-## Phase 5 — Task Decomposition
-
-**Objetivo:** Decompor roadmap em tasks executaveis e detalhadas o suficiente para que qualquer pessoa (tecnica ou nao) entenda o que deve ser feito.
-
-1. Executar `/plan-to-tasks sprint-planner/<slug>/PRD.md`
-2. Cada task segue formato padrao:
-   - ID: `TASK-YYYYMM-NNN`
-   - Titulo imperativo
-   - Area: FE / BE / QA / UX / DevOps / General
-   - Prioridade: P0 (bloqueante) / P1 (importante) / P2 (nice-to-have)
-   - Estimativa: max 1 dia por task
-   - DoD mensuravel
-3. User stories em Given/When/Then (padrao `story-creation-playbook.md`)
-4. Ordenar por dependencias — tasks sem dependencia primeiro
-5. Scoring de complexidade (1-25) conforme playbook de story creation
-
-### Regras de Enriquecimento Obrigatorio
-
-Cada task DEVE conter os seguintes campos com nivel de detalhe minimo:
-
-| Campo | Regra | Exemplo |
-|-------|-------|---------|
-| `description` | Min 2 sentencas: O QUE fazer + POR QUE fazer | "Inicializar o projeto Next.js com App Router. Necessario para estabelecer a base de codigo do projeto." |
-| `context` | Motivacao para leitor nao-tecnico. Por que esta task existe no contexto do projeto | "Primeiro passo do projeto. Todas as demais tasks dependem desta estrutura estar funcional." |
-| `acceptanceCriteria` | Formato DADO/QUANDO/ENTAO. Min 2 criterios verificaveis | "DADO que o repo foi clonado QUANDO rodar pnpm dev ENTAO o servidor sobe sem erros" |
-| `steps` | Passo a passo de implementacao (3-7 steps acionaveis) | "1. Rodar pnpm create next-app 2. Configurar Prettier 3. Criar estrutura de pastas" |
-| `points` | Story points obrigatorio (1, 2, 3, 5, 8, 13) | 3 |
-| `files` | Paths especificos, NAO diretorios genericos | `app/layout.tsx` em vez de `app/` |
-| `dependencies` | Array de T-IDs que bloqueiam esta task (vazio se nenhum) | `["T-005"]` ou `[]` |
-| `dod` | Definition of Done resumido em 1 linha | "Projeto roda localmente, estrutura match spec, preview Vercel OK" |
-| `subtasks` | Obrigatorio para tasks >5 pontos | Array de sub-items |
-| `businessRules` | IDs de regras de negocio (vazio se nenhuma) | `["BR-001"]` ou `[]` |
-
-### Exemplo de Task Enriquecida
-
-```json
-{
-  "id": "T-006",
-  "title": "Scaffold Next.js App Router",
-  "description": "Inicializar o projeto Next.js com App Router, TypeScript, Tailwind v4, ESLint e Prettier. Configurar a estrutura de pastas conforme a especificacao arquitetural (secao 2.1 do ADR) para garantir consistencia e escalabilidade do codebase.",
-  "context": "Este e o primeiro passo do projeto Fractus. Todos os demais tasks (backend e frontend) dependem desta estrutura base estar correta e funcional. A estrutura de pastas define convencoes que serao seguidas por toda a equipe.",
-  "priority": "P0",
-  "area": "backend",
-  "points": 3,
-  "assignee": "Douglas Oliveira",
-  "steps": [
-    "Rodar pnpm create next-app@latest com App Router, TypeScript, Tailwind, ESLint",
-    "Configurar Prettier com regras do projeto (.prettierrc)",
-    "Criar estrutura de pastas: app/, components/ui/, lib/, hooks/, types/, services/",
-    "Configurar path aliases no tsconfig.json (@/ para src/)",
-    "Adicionar scripts no package.json (dev, build, lint, format)",
-    "Validar que pnpm dev sobe sem erros",
-    "Fazer deploy preview no Vercel e confirmar que a pagina padrao renderiza"
-  ],
-  "acceptanceCriteria": [
-    "DADO que o repo foi clonado QUANDO rodar pnpm install && pnpm dev ENTAO o servidor sobe em localhost:3000 sem erros",
-    "DADO a estrutura de pastas QUANDO comparar com secao 2.1 do ADR ENTAO todos os diretorios listados existem",
-    "DADO o projeto deployado QUANDO acessar a preview URL no Vercel ENTAO a pagina renderiza com status 200"
-  ],
-  "files": [
-    "package.json", "tsconfig.json", "next.config.ts", "tailwind.config.ts",
-    ".prettierrc", ".eslintrc.json", "app/layout.tsx", "app/page.tsx"
-  ],
-  "dependencies": [],
-  "businessRules": [],
-  "dod": "Projeto roda localmente, estrutura match spec, preview Vercel funcional"
-}
-```
-
-### Validacao Pre-Import
-
-O CLI `clickup.js sprint import` agora valida cada task automaticamente (score 0-100). Tasks com score < 30 bloqueiam o import. Use `--skip-validation` para bypass.
-
-**Gate:** Tasks acionaveis, detalhadas e sem interpretacao subjetiva.
-
-## Phase 6 — Environment & Setup Tasks
-
-**Objetivo:** Gerar tasks de preparacao de ambiente que precedem o desenvolvimento.
-
-1. Detectar necessidades de setup a partir do PRD e ADRs:
-
-| Categoria | Exemplos |
-|-----------|----------|
-| Contas de servicos | Supabase, Vercel, Cloudflare, APIs externas |
-| Credenciais | API keys, secrets, env vars, OAuth apps |
-| Repositorio | Criar repo, configurar branches, CI/CD |
-| Backend | Migrations iniciais, seeds, RLS policies |
-| Frontend | Scaffold, design tokens, tema base |
-| DBML | Gerar schema.dbml, validar com dbdiagram.io |
-| Infraestrutura | DNS, dominios, certificados, storage |
-
-2. Gerar tasks com area `devops` ou `general`, prioridade P0
-3. Marcar como pre-requisitos das tasks de desenvolvimento
-4. Incluir instrucoes passo-a-passo (criar conta → obter credenciais → configurar .env)
-
-**Gate:** Nenhuma task de dev depende de setup nao planejado.
-
-## Phase 7 — Sprint Assembly & Summary
-
-**Objetivo:** Consolidar todos os artefatos em visao geral da sprint.
-
-1. Gerar `sprint-planner/<slug>/SPRINT-OVERVIEW.md` com:
-   - Nome e objetivo da sprint
-   - Entregaveis (com links para artefatos gerados)
-   - Fora de escopo (explicito)
-   - Assuncoes e riscos
-   - Dependencias externas
-   - Resumo do backlog (tabela com todas as tasks, area, prioridade, estimativa)
-   - Ordem de execucao sugerida
-   - Proximos passos (qual skill usar para executar)
-
-2. Registrar decisoes em `.G-OS/memory/decision-log.json`
-
-### ClickUp-Ready Output (Opcional)
-
-Se o projeto usa ClickUp para gestao, gerar tambem o JSON de import:
-
-1. Gerar `sprint-planner/<slug>/sprint-import.json` no formato do schema `data/schemas/sprint-clickup.schema.json`
-2. Cada task com TODOS os campos de enriquecimento obrigatorio (ver Phase 5):
-   - `id`, `title`, `description`, `context`, `priority`, `area`, `points`
-   - `assignee`, `steps`, `acceptanceCriteria` (DADO/QUANDO/ENTAO)
-   - `files` (paths especificos), `dependencies`, `businessRules`, `dod`
-   - `subtasks` (obrigatorio para tasks >5 pontos)
-   - `estimatedHours` (0.5-16), `technicalNotes` (quando aplicavel)
-3. Criterios de aceite viram checklist "Acceptance Criteria" no ClickUp automaticamente
-4. Steps viram checklist "Implementation Steps" no ClickUp automaticamente
-5. Campo `assignee` com nome do responsavel (resolvido pelo CLI via `--team-id`)
-6. Textos passam por sanitizacao automatica (correcao de acentos + deteccao de padroes de IA)
-7. Importar via: `node scripts/tools/clickup.js sprint import --folder-id <id> --file sprint-import.json --team-id <id>`
-8. Para enriquecer tasks ja importadas: `node scripts/tools/clickup.js task enrich --file enriched.json`
-
-### Artefatos Finais
-
-```
-.G-OS/sprint-planner/<slug>/
-  input-analysis.md
-  PRD.md
-  ADR-001.md (... ADR-NNN.md)
-  schema.dbml (se aplicavel)
-  ROADMAP.md
-  SPRINT-OVERVIEW.md
-  sprint-import.json (se ClickUp habilitado)
-
-.G-OS/tasks/
-  TASK-YYYYMM-001.md
-  TASK-YYYYMM-002.md
-  ...
-```
-
-### Continuacao apos Sprint Planner
-
-| Objetivo | Comando |
-|----------|---------|
-| Executar spec-driven | `/sdd sprint-planner/<slug>/PRD.md` (pula fases 1-3 do SDD) |
-| Orquestrar execucao | `/compose TASK-YYYYMM-001` |
-| Refinar backlog | `@sm` ou `@po` revisam stories |
-| Implementar frontend | `/fe` com tasks geradas |
-| Implementar backend | `/be` com tasks geradas |
-
-## Regras Criticas
-
-1. **Nao executar codigo** — Sprint Planner para apos produzir o pacote da sprint.
-2. **Nao assumir requisitos** — se faltar informacao, perguntar no loop de discovery.
-3. **Nao pular gates** — cada fase precisa de aprovacao antes de avancar.
-4. **Internalizar tudo** — nenhuma referencia a caminhos externos no output final.
-5. **Priorizar setup** — tasks de ambiente sempre precedem desenvolvimento.
-6. **DBML quando houver banco** — sempre gerar schema mesmo para projetos simples.
-7. **ADR para decisoes grandes** — 3+ opcoes com trade-offs = ADR separado.
-
-## Model Guidance
-
-| Escopo | Modelo recomendado |
-|--------|-------------------|
-| Projeto simples (escopo claro, 3-5 tasks) | `sonnet` |
-| Projeto medio (ambiguidade moderada, 5-15 tasks) | `opus` |
-| Projeto complexo (multi-dominio, 15+ tasks, Figma + backend) | `opus` (obrigatorio) |
-| Discovery apenas (fases 0-1) | `sonnet` |
-| Full pipeline (fases 0-7) | `opus` (recomendado) |
-
-## When to Use
-- Use according to the triggers described in the description/use-when list.
-
-## Do not use
-- Fora do escopo descrito; prefira a skill apropriada.
-
-## Instructions
-1) Siga o passo-a-passo principal da skill.
-2) Valide saa com checklists desta skill ou do workflow.
-3) Registre decises relevantes se aplic5vel.

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

@@ -1,165 +0,0 @@
-# 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:
-
-- PM: "consegue trazer um resumo em linguem nao técnica pra mim ahaha, por favor?"
-- PO: "Pensa que está em uma reunião com a gente, o que você compartilharia?"
-
-### Novo argumento e env var
-
-- `$ARGUMENTS --mode simple|detailed` sobrescreve via linha de comando.
-- `WEEKLY_UPDATE_MODE=simple|detailed` no `.env` define o padrão do projeto.
-- Se ambos ausentes, fallback para `detailed` (comportamento anterior).
-- Skill não pergunta mais — resolve via env/arg e informa o modo no início da Phase 2.
-
-### Modo `simple` (novo)
-
-Audiência não-técnica (PO/PM/clientes). Regras obrigatórias:
-
-1. Zero IDs de task (nada de T-084, T-110).
-2. Zero jargão técnico. Lista banida: API, endpoint, FK, hook, webhook, migration, deploy, pipeline, CI/CD, TypeScript, Zod, backend, frontend, SPA routing, commit, branch, merge, PR, rebase, drift, build, pre-commit.
-3. Bullets curtos em vez de parágrafos densos.
-4. Foco no valor entregue, não em como foi feito.
-5. Tom de reunião casual (primeira pessoa, contrações como "pra", "to", "tá").
-6. Alvo: 150-250 palavras.
-
-Calibração humanizer: conversacional (intensidade alta), contra os 30 pontos de padrões AI.
-
-### Modo `detailed` (comportamento anterior, preservado)
-
-Audiência técnica (tech lead, outros devs). Permite IDs de task, jargão apropriado, narrativa em parágrafos, dependências explícitas. Alvo: 300-500 palavras.
-
-### Checklist de aprovação expandido
-
-Novos itens na Phase 4:
-- Modo confirmado antes do envio.
-- Em `simple`: nenhum termo banido aparece no texto final.
-- Em `simple`: nenhum ID de task (T-XXX) aparece no texto final.
-
-### Arquivos afetados
-
-- `.gos/skills/weekly-update/SKILL.md` — Gate 3 novo, Phase 2 refatorada com templates por modo, Phase 3 com calibração por modo, Phase 4 checklist expandido.
-- `.env-example` — nova var `WEEKLY_UPDATE_MODE=simple`.
-- `.env` local Ganbatte — adicionado `WEEKLY_UPDATE_MODE=simple`.
-
-### Companion: `slack-notify.js` ganhou `fetch-thread` e `find-thread`
-
-Comandos Web API via `SLACK_BOT_TOKEN` (scope `groups:history` para canais privados). Usado pela skill e disponível para auditoria de threads passadas. Allow-rules adicionadas em `~/.claude/settings.json`:
-
-- `Bash(node .gos/scripts/tools/slack-notify.js fetch-thread:*)`
-- `Bash(node .gos/scripts/tools/slack-notify.js find-thread:*)`
-
----
-
-## 2026-04-17 — v2.0 (Web API, thread obrigatória, auto-descoberta)
-
-Mudanças estruturais motivadas por incidente em produção: o envio via incoming webhook caiu fora da thread "Conversa semanal" e gerou mensagem isolada no canal #cnpq-tech.
-
-### Incidente
-
-- **O quê:** weekly-update postou como mensagem nova no canal em vez de dentro da thread.
-- **Causa raiz:** incoming webhook do Slack não suporta `thread_ts`. O skill (v1.x) tentava passar `--thread-ts` para `slack-notify.js send`, mas o script ignorava (webhook path).
-- **Impacto:** poluição do canal + confusão visual; mensagem correta teve que ser reenviada e a errada deletada manualmente (API rejeitou `chat.delete` com `cant_delete_message` porque webhook é identidade separada mesmo dentro do mesmo app).
-
-### Migração obrigatória: Web API (chat.postMessage)
-
-- Weekly-update **não usa mais webhook**. Passa a usar `chat.postMessage` via Web API com bot token.
-- Env vars novas (ambas obrigatórias):
-  - `SLACK_BOT_TOKEN=xoxb-...` — Bot User OAuth Token.
-  - `SLACK_CHANNEL_ID_WEEKLY=C0ADYLL6W0K` — ID do canal #cnpq-tech.
-- Env var antiga `SLACK_WEBHOOK_CSPO_TECH` **não é mais usada pelo weekly-update** (continua viva para hooks de commit/task, sem impacto).
-
-### Scopes necessários no bot (app Slack)
-
-- `chat:write` — postar mensagens.
-- `chat:write.public` — postar em canais públicos sem invite (opcional).
-- `groups:history` — ler histórico de canais privados (necessário para auto-descoberta de thread).
-- Após adicionar qualquer scope: **Reinstall to Ganbatte** no painel OAuth (sem reinstall o token não ganha o scope).
-- Bot precisa ser convidado no canal privado: `/invite @autocommit` em `#cnpq-tech`.
-
-### Thread obrigatória
-
-- Skill cancela o envio se não conseguir resolver `thread_ts`. Nunca mais cai em "mensagem nova no canal".
-- Ordem de resolução do `thread_ts` (Phase 5):
-  1. Link do Slack em `$ARGUMENTS` → extrai ts.
-  2. **Auto-descoberta** via `slack-notify.js find-thread` (novo) — busca mensagem mais recente que bata com o regex.
-  3. Fallback: `AskUserQuestion` pedindo o link.
-
-### Auto-descoberta de thread
-
-Novo comando no CLI:
-
-```bash
-node .gos/scripts/tools/slack-notify.js find-thread \
-  --channel-id "$SLACK_CHANNEL_ID_WEEKLY" \
-  --pattern "CHECK-POINT ASSÍNCRONO|Conversa semanal"
-```
-
-Retorno:
-```json
-{ "found": true, "ts": "1776445206.005489", "text_preview": "..." }
-```
-
-Resolve o `thread_ts` da última mensagem que bate com o pattern — dispensa cole manual de link a cada semana.
-
-### Anti-sobreposição entre updates (Phase 1)
-
-Dois mecanismos cumulativos:
-
-1. **Arquivo de estado** `.gos/.weekly-update-last-run.json` — armazena `last_run_date` (YYYY-MM-DD). Skill usa como piso do filtro ClickUp (`date_done_from`). Gravado apenas após `sent: true`.
-2. **Arquivo do update anterior** `.gos/weekly-updates/YYYY-MM-DD.md` — texto íntegro do último envio. Skill lê o mais recente em Phase 1 e cruza contra o draft em Phase 2/4, descartando menções duplicadas (cobre casos em que uma task foi reportada proativamente e só fechou no ClickUp na janela seguinte).
-
-### Janela de busca default
-
-- Era 10 dias. Agora 7 (fallback quando não há `last_run_date`). Alinha com cadência semanal.
-
-### Template — quebra visual entre título e corpo
-
-- Todas as seções (`*O que foi feito*`, `*Desafios encontrados*`, etc.) agora têm linha em branco entre título e primeiro parágrafo. Slack renderia colado antes.
-
-### Novos comandos no `slack-notify.js`
-
-| Comando | Uso | Scope necessário |
-|---|---|---|
-| `send --channel-id C... --thread-ts TS` | Post via Web API em thread | `chat:write` |
-| `delete --channel-id C... --ts TS` | Apagar mensagem do próprio bot | `chat:write` (do app autor) |
-| `find-thread --channel-id C... --pattern REGEX` | Achar ts mais recente que bata com regex | `groups:history` (privado) |
-
-### Limitações conhecidas
-
-- `chat.delete` só funciona para mensagens postadas pelo **mesmo token**. Webhook conta como identidade separada — mensagens antigas postadas via webhook não podem ser deletadas via API mesmo que o app seja o mesmo. Delete manual no Slack UI é o único caminho nesse caso.
-
-### Coexistência com hooks de commit
-
-- Hooks pós-commit (`task-done`, `task-update`, `sprint-summary`) continuam em `SLACK_WEBHOOK_URL` via `sendWebhook`. Zero impacto.
-- Weekly-update é o único fluxo que migrou para Web API.