@luanpdd/kit-mcp 1.33.0 → 1.34.0

package/kit/commands/discutir-fase.md

@@ -1,131 +1,131 @@
----
-name: discutir-fase
-description: Reúne contexto da fase por questionamento adaptativo antes do planejamento. Use --auto para pular perguntas interativas (Claude escolhe os padrões recomendados).
-argument-hint: "<phase> [--auto] [--batch] [--analyze] [--text]"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - Glob
-  - Grep
-  - AskUserQuestion
-  - Task
-  - mcp__context7__resolve-library-id
-  - mcp__context7__query-docs
----
-
-<objective>
-Extrair decisões de implementação que os agentes subsequentes precisam — o pesquisador e o planejador usarão o CONTEXT.md para saber o que investigar e quais escolhas estão travadas.
-
-**Como funciona:**
-1. Carregar contexto anterior (PROJECT.md, REQUIREMENTS.md, STATE.md, arquivos CONTEXT.md anteriores)
-2. Explorar base de código em busca de recursos e padrões reutilizáveis
-3. Analisar a fase — pular áreas cinzentas já decididas em fases anteriores
-4. Apresentar áreas cinzentas restantes — usuário seleciona quais discutir
-5. Aprofundar cada área selecionada até satisfação
-6. Criar CONTEXT.md com decisões que guiam pesquisa e planejamento
-
-**Saída:** `{phase_num}-CONTEXT.md` — decisões claras o suficiente para que agentes subsequentes possam agir sem perguntar ao usuário novamente
-</objective>
-
-<execution_context>
-@./.claude/framework/workflows/discuss-phase.md
-@./.claude/framework/workflows/discuss-phase-assumptions.md
-@./.claude/framework/templates/context.md
-</execution_context>
-
-<context>
-Número da fase: $ARGUMENTS (obrigatório)
-
-Arquivos de contexto são resolvidos no workflow usando `init phase-op` e chamadas de ferramentas de roadmap/estado.
-</context>
-
-<process>
-**Roteamento de modo:**
-```bash
-DISCUSS_MODE=$(node "./.claude/framework/bin/tools.cjs" config-get workflow.discuss_mode 2>/dev/null || echo "discuss")
-```
-
-Se `DISCUSS_MODE` for `"assumptions"`: Ler e executar @./.claude/framework/workflows/discuss-phase-assumptions.md do início ao fim.
-
-Se `DISCUSS_MODE` for `"discuss"` (ou não definido, ou qualquer outro valor): Ler e executar @./.claude/framework/workflows/discuss-phase.md do início ao fim.
-
-**OBRIGATÓRIO:** Os arquivos execution_context listados acima SÃO as instruções. Ler o arquivo de workflow ANTES de tomar qualquer ação. As seções de objective e success_criteria neste arquivo de comando são resumos — o arquivo de workflow contém o processo completo passo a passo com todos os comportamentos obrigatórios, verificações de configuração e padrões de interação. Não improvisar a partir do resumo.
-</process>
-
-<success_criteria>
-- Contexto anterior carregado e aplicado (sem re-perguntar questões já decididas)
-- Áreas cinzentas identificadas através de análise inteligente
-- Usuário escolheu quais áreas discutir
-- Cada área selecionada explorada até satisfação
-- Expansão de escopo redirecionada para ideias adiadas
-- CONTEXT.md captura decisões, não visão vaga
-- Usuário conhece os próximos passos
-</success_criteria>
-
-<observability_integration>
-**Integração com Observability-Driven Development (v1.9):**
-
-Quando o workflow.observability_phase_questions = true (default), o workflow inclui pergunta canônica de ODD na sessão de discussão:
-
-> "Quais SLIs essa fase impacta? O que precisa ser instrumentado para responder às 4 perguntas pré-PR?"
-
-A pergunta é resolvida consultando a skill [`observability-driven-development`](../skills/observability-driven-development/SKILL.md) e o resultado é registrado na seção `<observability>` do CONTEXT.md gerado:
-
-```markdown
-<observability>
-## SLIs impactados
-- [SLI ou "nenhum — fase puramente interna"]
-
-## Instrumentação necessária
-- Spans novos: [lista]
-- Atributos canônicos: [user.id, tenant_id, ...]
-- error.type enum esperado: [validation, timeout, ...]
-</observability>
-```
-
-O `plan-checker` invocado pelo `/planejar-fase` (Phase 33 — INT-FW-02) lê esta seção e bloqueia o plano se ODD ausente para fases voltadas ao usuário (skip silenciosamente para fases de infraestrutura — ver detecção em `discuss-phase.md`).
-
-**REQ:** INT-FW-01.
-</observability_integration>
-
-<legacy_refactor_integration>
-**Integração com Suíte Legacy Code (Feathers):**
-
-Quando o workflow detecta intent de **refactor** (palavras-chave em descrição da fase: "refator", "refactor", "extrair", "limpar", "reorganizar", "split", "quebrar classe/módulo"), inclui pergunta canônica:
-
-> "Esta fase envolve refactor de arquivo existente? Se sim, qual é o arquivo alvo?"
-
-Para cada arquivo identificado:
-1. Coleta line count + checa se path matches contrato externo (supabase/functions, src/api, webhooks, pages/api)
-2. Invoca [`refactor-safety-auditor`](../agents/refactor-safety-auditor.md) **em modo dry-run** para coletar evidências sem bloquear
-3. Resultado registrado em CONTEXT.md em seção `<refactor_safety>`:
-
-```markdown
-<refactor_safety>
-## Arquivos alvo de refactor
-
-| Arquivo | Linhas | Contrato externo | Cobertura | Char tests | Veredito do gate |
-|---|---|---|---|---|---|
-| src/orders/handler.ts | 724 | true | 12% | absent | BLOCK |
-| src/orders/utils.ts | 89 | false | 78% | absent | GO |
-
-## Recomendação
-
-Para `src/orders/handler.ts`:
-  - Caminho preferido: /caracterizar antes de refactor (custo: 8-16h)
-  - Alternativa: /refactor-seguro --mode=sprout (se mudança ADICIONA, não modifica)
-  - Para safe-extract: assinar checklist canônico de safe extraction
-  - Override possível com ticket + reason
-
-Para `src/orders/utils.ts`:
-  - Refactor pode prosseguir; cobertura adequada existe.
-</refactor_safety>
-```
-
-`plan-checker` consume essa seção. Se gate retorna BLOCK e mode=blocking, plano não é aprovado até user escolher caminho explícito.
-
-**Skill canônica:** [`pre-refactor-characterization`](../skills/pre-refactor-characterization/SKILL.md)
-
-**Quando skip:** fase puramente de infraestrutura (markdown, config, tooling), fase greenfield (sem arquivos existentes a modificar), OR `workflow.legacy_refactor_questions=false` em config.
-</legacy_refactor_integration>
+---
+name: discutir-fase
+description: Reúne contexto da fase por questionamento adaptativo antes do planejamento. Use --auto para pular perguntas interativas (Claude escolhe os padrões recomendados).
+argument-hint: "<phase> [--auto] [--batch] [--analyze] [--text]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - Task
+  - mcp__context7__resolve-library-id
+  - mcp__context7__query-docs
+---
+
+<objective>
+Extrair decisões de implementação que os agentes subsequentes precisam — o pesquisador e o planejador usarão o CONTEXT.md para saber o que investigar e quais escolhas estão travadas.
+
+**Como funciona:**
+1. Carregar contexto anterior (PROJECT.md, REQUIREMENTS.md, STATE.md, arquivos CONTEXT.md anteriores)
+2. Explorar base de código em busca de recursos e padrões reutilizáveis
+3. Analisar a fase — pular áreas cinzentas já decididas em fases anteriores
+4. Apresentar áreas cinzentas restantes — usuário seleciona quais discutir
+5. Aprofundar cada área selecionada até satisfação
+6. Criar CONTEXT.md com decisões que guiam pesquisa e planejamento
+
+**Saída:** `{phase_num}-CONTEXT.md` — decisões claras o suficiente para que agentes subsequentes possam agir sem perguntar ao usuário novamente
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/discuss-phase.md
+@./.claude/framework/workflows/discuss-phase-assumptions.md
+@./.claude/framework/templates/context.md
+</execution_context>
+
+<context>
+Número da fase: $ARGUMENTS (obrigatório)
+
+Arquivos de contexto são resolvidos no workflow usando `init phase-op` e chamadas de ferramentas de roadmap/estado.
+</context>
+
+<process>
+**Roteamento de modo:**
+```bash
+DISCUSS_MODE=$(node "./.claude/framework/bin/tools.cjs" config-get workflow.discuss_mode 2>/dev/null || echo "discuss")
+```
+
+Se `DISCUSS_MODE` for `"assumptions"`: Ler e executar @./.claude/framework/workflows/discuss-phase-assumptions.md do início ao fim.
+
+Se `DISCUSS_MODE` for `"discuss"` (ou não definido, ou qualquer outro valor): Ler e executar @./.claude/framework/workflows/discuss-phase.md do início ao fim.
+
+**OBRIGATÓRIO:** Os arquivos execution_context listados acima SÃO as instruções. Ler o arquivo de workflow ANTES de tomar qualquer ação. As seções de objective e success_criteria neste arquivo de comando são resumos — o arquivo de workflow contém o processo completo passo a passo com todos os comportamentos obrigatórios, verificações de configuração e padrões de interação. Não improvisar a partir do resumo.
+</process>
+
+<success_criteria>
+- Contexto anterior carregado e aplicado (sem re-perguntar questões já decididas)
+- Áreas cinzentas identificadas através de análise inteligente
+- Usuário escolheu quais áreas discutir
+- Cada área selecionada explorada até satisfação
+- Expansão de escopo redirecionada para ideias adiadas
+- CONTEXT.md captura decisões, não visão vaga
+- Usuário conhece os próximos passos
+</success_criteria>
+
+<observability_integration>
+**Integração com Observability-Driven Development (v1.9):**
+
+Quando o workflow.observability_phase_questions = true (default), o workflow inclui pergunta canônica de ODD na sessão de discussão:
+
+> "Quais SLIs essa fase impacta? O que precisa ser instrumentado para responder às 4 perguntas pré-PR?"
+
+A pergunta é resolvida consultando a skill [`observability-driven-development`](../skills/observability-driven-development/SKILL.md) e o resultado é registrado na seção `<observability>` do CONTEXT.md gerado:
+
+```markdown
+<observability>
+## SLIs impactados
+- [SLI ou "nenhum — fase puramente interna"]
+
+## Instrumentação necessária
+- Spans novos: [lista]
+- Atributos canônicos: [user.id, tenant_id, ...]
+- error.type enum esperado: [validation, timeout, ...]
+</observability>
+```
+
+O `plan-checker` invocado pelo `/planejar-fase` (Phase 33 — INT-FW-02) lê esta seção e bloqueia o plano se ODD ausente para fases voltadas ao usuário (skip silenciosamente para fases de infraestrutura — ver detecção em `discuss-phase.md`).
+
+**REQ:** INT-FW-01.
+</observability_integration>
+
+<legacy_refactor_integration>
+**Integração com Suíte Legacy Code (Feathers):**
+
+Quando o workflow detecta intent de **refactor** (palavras-chave em descrição da fase: "refator", "refactor", "extrair", "limpar", "reorganizar", "split", "quebrar classe/módulo"), inclui pergunta canônica:
+
+> "Esta fase envolve refactor de arquivo existente? Se sim, qual é o arquivo alvo?"
+
+Para cada arquivo identificado:
+1. Coleta line count + checa se path matches contrato externo (supabase/functions, src/api, webhooks, pages/api)
+2. Invoca [`refactor-safety-auditor`](../agents/refactor-safety-auditor.md) **em modo dry-run** para coletar evidências sem bloquear
+3. Resultado registrado em CONTEXT.md em seção `<refactor_safety>`:
+
+```markdown
+<refactor_safety>
+## Arquivos alvo de refactor
+
+| Arquivo | Linhas | Contrato externo | Cobertura | Char tests | Veredito do gate |
+|---|---|---|---|---|---|
+| src/orders/handler.ts | 724 | true | 12% | absent | BLOCK |
+| src/orders/utils.ts | 89 | false | 78% | absent | GO |
+
+## Recomendação
+
+Para `src/orders/handler.ts`:
+  - Caminho preferido: /caracterizar antes de refactor (custo: 8-16h)
+  - Alternativa: /refactor-seguro --mode=sprout (se mudança ADICIONA, não modifica)
+  - Para safe-extract: assinar checklist canônico de safe extraction
+  - Override possível com ticket + reason
+
+Para `src/orders/utils.ts`:
+  - Refactor pode prosseguir; cobertura adequada existe.
+</refactor_safety>
+```
+
+`plan-checker` consume essa seção. Se gate retorna BLOCK e mode=blocking, plano não é aprovado até user escolher caminho explícito.
+
+**Skill canônica:** [`pre-refactor-characterization`](../skills/pre-refactor-characterization/SKILL.md)
+
+**Quando skip:** fase puramente de infraestrutura (markdown, config, tooling), fase greenfield (sem arquivos existentes a modificar), OR `workflow.legacy_refactor_questions=false` em config.
+</legacy_refactor_integration>

package/kit/commands/encontrar-seams.md

@@ -1,136 +1,136 @@
----
-name: encontrar-seams
-description: Invoca seam-finder — analisa código para identificar seams (object/link/preprocessing) e recomenda técnica do cap 25 Feathers para quebrar dependências bloqueantes.
-argument-hint: "<target_file> [--symbol <name>] [--prefer object|link|preprocessing] [--output PATH]"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - Grep
-  - Glob
-  - Task
----
-
-<objective>
-Analisar código alvo para identificar **seams** (lugares onde se pode alterar comportamento sem editar lá) e recomendar **técnica do catálogo cap 25 Feathers** para quebrar dependências bloqueantes (DB real, HTTP, framework objects, singletons, clocks). Invoca o agente [`seam-finder`](../agents/seam-finder.md) que aplica a skill [`legacy-seams-and-test-harness`](../skills/legacy-seams-and-test-harness/SKILL.md) — decision tree por linguagem, prioridade pelo MENOR custo + MAIOR reversibilidade.
-
-**Cria/Atualiza:**
-- `.planning/SEAM-ANALYSIS.md` — relatório com deps bloqueantes, técnicas recomendadas, sequência canônica de commits
-
-**Após:** o user tem plano mecânico para tornar código testável antes de invocar `/caracterizar`. Tipicamente 5-30 minutos por dep bloqueante; sequência de pequenos commits revertíveis.
-</objective>
-
-<context>
-**Argumentos:**
-- `<target_file>` — caminho do arquivo a analisar (relativo ao project root) — OBRIGATÓRIO
-- `--symbol <name>` — analisar apenas símbolo específico (default: arquivo inteiro)
-- `--prefer object|link|preprocessing` — preferência de tipo de seam (default: object)
-- `--output PATH` — caminho do output (default: `.planning/SEAM-ANALYSIS.md`)
-
-**Exemplos:**
-```
-/encontrar-seams src/orders/OrderService.ts                        # análise completa
-/encontrar-seams src/orders/OrderService.ts --symbol charge        # método específico
-/encontrar-seams src/legacy/Client.cpp --prefer link               # forçar link seam (C++ legado)
-```
-
-**Quando este comando é o caminho certo:**
-- `/caracterizar` falhou porque deps externas impedem isolamento
-- Construtor faz I/O direto (cria conexão DB no constructor)
-- Usar singleton/global hardcoded no método a testar
-- Framework type complexo (HttpServletRequest, Express.Request) bloqueando teste
-- Código procedural (C, COBOL, Go) onde polimorfismo não está disponível
-
-**Quando NÃO é o caminho:**
-- Código já é testável (deps injetadas via DI) → usar `/caracterizar` direto
-- Código é puro (sem I/O) → não precisa break-dep
-- Mudança é safe-extraction (rename, IDE-extract) → usar `/refactor-seguro --mode=safe-extract`
-</context>
-
-<process>
-
-## 1. Parsear argumentos
-
-```bash
-TARGET_FILE=$(echo "$ARGUMENTS" | awk '{print $1}')
-SYMBOL=$(echo "$ARGUMENTS" | grep -oE -- '--symbol [^ ]+' | awk '{print $2}')
-PREFER=$(echo "$ARGUMENTS" | grep -oE -- '--prefer [^ ]+' | awk '{print $2}')
-OUTPUT_PATH=$(echo "$ARGUMENTS" | grep -oE -- '--output [^ ]+' | awk '{print $2}')
-
-[ -z "$OUTPUT_PATH" ] && OUTPUT_PATH=".planning/SEAM-ANALYSIS.md"
-[ -z "$PREFER" ]      && PREFER="object"
-
-if [ -z "$TARGET_FILE" ]; then
-  echo "ERROR: target_file é obrigatório."
-  echo "Uso: /encontrar-seams <target_file> [opções]"
-  exit 1
-fi
-
-if [ ! -f "$TARGET_FILE" ]; then
-  echo "ERROR: arquivo não encontrado: $TARGET_FILE"
-  exit 1
-fi
-
-mkdir -p "$(dirname "$OUTPUT_PATH")"
-```
-
-## 2. Dispatch para `seam-finder`
-
-```text
-Task(
-  subagent_type="seam-finder",
-  prompt="
-target_file: ${TARGET_FILE}
-${SYMBOL:+target_symbol: ${SYMBOL}}
-output_path: ${OUTPUT_PATH}
-prefer_technique: ${PREFER}
-
-Aplicar skill legacy-seams-and-test-harness. Etapas:
-1. Detectar linguagem + paradigma (OO vs procedural)
-2. Mapear deps externas (network/DB/FS/clock/random/UUID/global/framework-type/construtor-caro)
-3. Identificar tipos de seam disponíveis (object/link/preprocessing)
-4. Aplicar decision tree do cap 25 escolhendo técnica de menor custo + maior reversibilidade
-5. Gerar SEAM-ANALYSIS.md com:
-   - tabela de deps bloqueantes
-   - técnica recomendada por dep com custo + reversibilidade
-   - exemplo ANTES/DEPOIS por técnica
-   - sequência canônica de commits (mais seguro → mais arriscado)
-6. Output curto para caller: lista de N deps + custo total estimado
-"
-)
-```
-
-## 3. Pós-output: integração com fluxo
-
-```
-═══════════════════════════════════════════════════════════
- framework ► ENCONTRAR-SEAMS ▸ ${OUTPUT_PATH}
-═══════════════════════════════════════════════════════════
-
-[output do seam-finder]
-
-## Próximos passos
-
-1. **Aplicar técnicas** — seguir sequência canônica em ${OUTPUT_PATH}
-   Cada commit é single-goal, mecânico, revertível
-2. **Rodar suite após cada commit** — compilação verde + tests verdes
-3. **/caracterizar <file>** — após break-deps complete, characterization fica viável
-4. **/auditar-refactor <file>** — gate deve retornar GO ou WARN agora (não mais BLOCK)
-
-## Cross-suite
-
-- Em projetos Supabase com Edge Functions: `supabase-edge-fn-writer` (v1.8) já segue patterns testáveis
-- Para skills de SOLID/DI: ver também `supabase-architect` (v1.8) — schema design considera testabilidade similarmente
-- Para mudança em código que afeta SLOs: `/instrumentar-fase` (v1.9) durante refactor preserva visibility
-```
-
-</process>
-
-<success_criteria>
-- [ ] $ARGUMENTS parseados (target_file obrigatório)
-- [ ] `seam-finder` invocado via `Task(subagent_type=...)` com prompt completo (6 etapas)
-- [ ] `.planning/SEAM-ANALYSIS.md` criado pelo agent com deps + técnicas + sequência de commits
-- [ ] Output forwarded transparentemente do agent
-- [ ] Próximos passos sugeridos: aplicar técnicas, rodar suite, /caracterizar, /auditar-refactor
-- [ ] Cross-references com Suíte Supabase (v1.8) e Observabilidade (v1.9) onde aplicável
-</success_criteria>
+---
+name: encontrar-seams
+description: Invoca seam-finder — analisa código para identificar seams (object/link/preprocessing) e recomenda técnica do cap 25 Feathers para quebrar dependências bloqueantes.
+argument-hint: "<target_file> [--symbol <name>] [--prefer object|link|preprocessing] [--output PATH]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+  - Task
+---
+
+<objective>
+Analisar código alvo para identificar **seams** (lugares onde se pode alterar comportamento sem editar lá) e recomendar **técnica do catálogo cap 25 Feathers** para quebrar dependências bloqueantes (DB real, HTTP, framework objects, singletons, clocks). Invoca o agente [`seam-finder`](../agents/seam-finder.md) que aplica a skill [`legacy-seams-and-test-harness`](../skills/legacy-seams-and-test-harness/SKILL.md) — decision tree por linguagem, prioridade pelo MENOR custo + MAIOR reversibilidade.
+
+**Cria/Atualiza:**
+- `.planning/SEAM-ANALYSIS.md` — relatório com deps bloqueantes, técnicas recomendadas, sequência canônica de commits
+
+**Após:** o user tem plano mecânico para tornar código testável antes de invocar `/caracterizar`. Tipicamente 5-30 minutos por dep bloqueante; sequência de pequenos commits revertíveis.
+</objective>
+
+<context>
+**Argumentos:**
+- `<target_file>` — caminho do arquivo a analisar (relativo ao project root) — OBRIGATÓRIO
+- `--symbol <name>` — analisar apenas símbolo específico (default: arquivo inteiro)
+- `--prefer object|link|preprocessing` — preferência de tipo de seam (default: object)
+- `--output PATH` — caminho do output (default: `.planning/SEAM-ANALYSIS.md`)
+
+**Exemplos:**
+```
+/encontrar-seams src/orders/OrderService.ts                        # análise completa
+/encontrar-seams src/orders/OrderService.ts --symbol charge        # método específico
+/encontrar-seams src/legacy/Client.cpp --prefer link               # forçar link seam (C++ legado)
+```
+
+**Quando este comando é o caminho certo:**
+- `/caracterizar` falhou porque deps externas impedem isolamento
+- Construtor faz I/O direto (cria conexão DB no constructor)
+- Usar singleton/global hardcoded no método a testar
+- Framework type complexo (HttpServletRequest, Express.Request) bloqueando teste
+- Código procedural (C, COBOL, Go) onde polimorfismo não está disponível
+
+**Quando NÃO é o caminho:**
+- Código já é testável (deps injetadas via DI) → usar `/caracterizar` direto
+- Código é puro (sem I/O) → não precisa break-dep
+- Mudança é safe-extraction (rename, IDE-extract) → usar `/refactor-seguro --mode=safe-extract`
+</context>
+
+<process>
+
+## 1. Parsear argumentos
+
+```bash
+TARGET_FILE=$(echo "$ARGUMENTS" | awk '{print $1}')
+SYMBOL=$(echo "$ARGUMENTS" | grep -oE -- '--symbol [^ ]+' | awk '{print $2}')
+PREFER=$(echo "$ARGUMENTS" | grep -oE -- '--prefer [^ ]+' | awk '{print $2}')
+OUTPUT_PATH=$(echo "$ARGUMENTS" | grep -oE -- '--output [^ ]+' | awk '{print $2}')
+
+[ -z "$OUTPUT_PATH" ] && OUTPUT_PATH=".planning/SEAM-ANALYSIS.md"
+[ -z "$PREFER" ]      && PREFER="object"
+
+if [ -z "$TARGET_FILE" ]; then
+  echo "ERROR: target_file é obrigatório."
+  echo "Uso: /encontrar-seams <target_file> [opções]"
+  exit 1
+fi
+
+if [ ! -f "$TARGET_FILE" ]; then
+  echo "ERROR: arquivo não encontrado: $TARGET_FILE"
+  exit 1
+fi
+
+mkdir -p "$(dirname "$OUTPUT_PATH")"
+```
+
+## 2. Dispatch para `seam-finder`
+
+```text
+Task(
+  subagent_type="seam-finder",
+  prompt="
+target_file: ${TARGET_FILE}
+${SYMBOL:+target_symbol: ${SYMBOL}}
+output_path: ${OUTPUT_PATH}
+prefer_technique: ${PREFER}
+
+Aplicar skill legacy-seams-and-test-harness. Etapas:
+1. Detectar linguagem + paradigma (OO vs procedural)
+2. Mapear deps externas (network/DB/FS/clock/random/UUID/global/framework-type/construtor-caro)
+3. Identificar tipos de seam disponíveis (object/link/preprocessing)
+4. Aplicar decision tree do cap 25 escolhendo técnica de menor custo + maior reversibilidade
+5. Gerar SEAM-ANALYSIS.md com:
+   - tabela de deps bloqueantes
+   - técnica recomendada por dep com custo + reversibilidade
+   - exemplo ANTES/DEPOIS por técnica
+   - sequência canônica de commits (mais seguro → mais arriscado)
+6. Output curto para caller: lista de N deps + custo total estimado
+"
+)
+```
+
+## 3. Pós-output: integração com fluxo
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► ENCONTRAR-SEAMS ▸ ${OUTPUT_PATH}
+═══════════════════════════════════════════════════════════
+
+[output do seam-finder]
+
+## Próximos passos
+
+1. **Aplicar técnicas** — seguir sequência canônica em ${OUTPUT_PATH}
+   Cada commit é single-goal, mecânico, revertível
+2. **Rodar suite após cada commit** — compilação verde + tests verdes
+3. **/caracterizar <file>** — após break-deps complete, characterization fica viável
+4. **/auditar-refactor <file>** — gate deve retornar GO ou WARN agora (não mais BLOCK)
+
+## Cross-suite
+
+- Em projetos Supabase com Edge Functions: `supabase-edge-fn-writer` (v1.8) já segue patterns testáveis
+- Para skills de SOLID/DI: ver também `supabase-architect` (v1.8) — schema design considera testabilidade similarmente
+- Para mudança em código que afeta SLOs: `/instrumentar-fase` (v1.9) durante refactor preserva visibility
+```
+
+</process>
+
+<success_criteria>
+- [ ] $ARGUMENTS parseados (target_file obrigatório)
+- [ ] `seam-finder` invocado via `Task(subagent_type=...)` com prompt completo (6 etapas)
+- [ ] `.planning/SEAM-ANALYSIS.md` criado pelo agent com deps + técnicas + sequência de commits
+- [ ] Output forwarded transparentemente do agent
+- [ ] Próximos passos sugeridos: aplicar técnicas, rodar suite, /caracterizar, /auditar-refactor
+- [ ] Cross-references com Suíte Supabase (v1.8) e Observabilidade (v1.9) onde aplicável
+</success_criteria>

package/kit/commands/entrar-discord.md

@@ -1,18 +1,18 @@
----
-name: entrar-discord
-description: Entrar na comunidade framework no Discord
----
-
-<objective>
-Exibir o link de convite para o servidor da comunidade framework no Discord.
-</objective>
-
-<output>
-# Entre no Discord do framework
-
-Conecte-se com outros usuários do framework, obtenha ajuda, compartilhe o que está criando e fique atualizado.
-
-**Link de convite:** https://discord.gg/framework
-
-Clique no link ou cole-o no seu navegador para entrar.
+---
+name: entrar-discord
+description: Entrar na comunidade framework no Discord
+---
+
+<objective>
+Exibir o link de convite para o servidor da comunidade framework no Discord.
+</objective>
+
+<output>
+# Entre no Discord do framework
+
+Conecte-se com outros usuários do framework, obtenha ajuda, compartilhe o que está criando e fique atualizado.
+
+**Link de convite:** https://discord.gg/framework
+
+Clique no link ou cole-o no seu navegador para entrar.
 </output>

package/kit/commands/estatisticas.md

@@ -1,18 +1,18 @@
----
-name: estatisticas
-description: Exibe estatísticas do projeto — fases, planos, requisitos, métricas git e linha do tempo
-allowed-tools:
-  - Read
-  - Bash
----
-<objective>
-Exibe estatísticas abrangentes do projeto incluindo progresso de fases, métricas de execução de planos, conclusão de requisitos, estatísticas de histórico git e linha do tempo do projeto.
-</objective>
-
-<execution_context>
-@./.claude/framework/workflows/stats.md
-</execution_context>
-
-<process>
-Execute o workflow stats de @./.claude/framework/workflows/stats.md do início ao fim.
-</process>
+---
+name: estatisticas
+description: Exibe estatísticas do projeto — fases, planos, requisitos, métricas git e linha do tempo
+allowed-tools:
+  - Read
+  - Bash
+---
+<objective>
+Exibe estatísticas abrangentes do projeto incluindo progresso de fases, métricas de execução de planos, conclusão de requisitos, estatísticas de histórico git e linha do tempo do projeto.
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/stats.md
+</execution_context>
+
+<process>
+Execute o workflow stats de @./.claude/framework/workflows/stats.md do início ao fim.
+</process>