@polymorphism-tech/morph-spec 4.9.0 → 4.10.1

package/framework/skills/level-0-meta/post-implementation/SKILL.md

@@ -1,362 +0,0 @@
----
-name: morph:post-implementation
-description: Orquestra o fluxo completo pós-implementação: detecção de stack,
-  scans automáticos (C#/Next.js), testes, validate-feature, smoke test via
-  Playwright (obrigatório se dev server ativo), checklist de code review por
-  stack, checkpoint e geração de recap. Use após concluir todas as tasks.
-argument-hint: "[feature-name]"
-user-invocable: true
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Task,
-  mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot,
-  mcp__playwright__browser_take_screenshot, mcp__playwright__browser_console_messages
----
-
-# Post-Implementation Review
-
-> Orquestrador pós-implementação: executa todos os checks em sequência lógica e bloqueia em caso de falha.
-> Use após completar todas as tasks de implementação, antes de criar o PR.
-
----
-
-## Pré-requisitos
-
-- Todas as tasks marcadas como done (`morph-spec task done`)
-- Build do projeto compilando sem erros
-
----
-
-## Step 1 — Detectar Stack
-
-```bash
-node .claude/skills/post-implementation/scripts/detect-stack.mjs
-```
-
-Output JSON: `{ stack: "DOTNET" | "NEXTJS" | "FULLSTACK" | "UNKNOWN", frontendPath, backendPath, startCommand }`
-
-Ordem de prioridade (mais confiável primeiro):
-1. `.morph/config/config.json` → `config.project.stack` + `frontendPath`/`backendPath`
-2. `.morph/context/README.md` → seção `## Tech Stack`
-3. Fallback: Glob por `*.csproj` e `package.json` com dep `"next"`
-
-Guarde o resultado — todos os passos seguintes dependem do `stack` detectado.
-
----
-
-## Step 2 — Automated Scans
-
-Execute os scans automáticos conforme o stack detectado.
-
-### Se DOTNET ou FULLSTACK:
-
-```bash
-node .claude/skills/morph:code-review/scripts/scan-csharp.mjs --diff
-```
-
-### Se NEXTJS ou FULLSTACK:
-
-```bash
-node .claude/skills/morph:code-review-nextjs/scripts/scan-nextjs.mjs --diff
-```
-
-**🚫 BLOCK se qualquer finding CRITICAL encontrado.**
-
-Corrija todos os CRITICALs antes de continuar. Para revisar a lista completa de checks:
-- .NET: `/morph:code-review`
-- Next.js: `/morph:code-review-nextjs`
-
----
-
-## Step 3 — Test Suite
-
-Execute os testes conforme o stack.
-
-### DOTNET:
-
-```bash
-dotnet test --verbosity minimal
-```
-
-### NEXTJS:
-
-```bash
-npm test -- --watchAll=false
-```
-
-### FULLSTACK:
-
-Execute ambos em paralelo (use Task tool com dois subagents independentes).
-
-**🚫 BLOCK se testes falharem.**
-
-Não prossiga enquanto houver testes falhando. Corrija as falhas e re-execute antes de continuar.
-
----
-
-## Step 4 — Framework Validation
-
-```bash
-npx morph-spec validate-feature $ARGUMENTS --phase implement
-```
-
-**🚫 BLOCK se falhar.**
-
-Leia o output de validação, corrija os issues reportados e re-execute até passar.
-
----
-
-## Step 5 — Smoke Test (Playwright MCP)
-
-### 5a. Detectar Dev Server
-
-```bash
-node .claude/skills/post-implementation/scripts/detect-dev-server.mjs "<startCommand>"
-```
-
-Passe o `startCommand` retornado pelo detect-stack no Step 1.
-
-O script:
-1. Varre portas `[3000, 3001, 4200, 5000, 5001, 7000, 8000, 8080]` com `fetch()` timeout 500ms
-2. Se encontrar um servidor ativo → retorna `{ found: true, url }`
-3. Se não encontrar e `startCommand` fornecido → tenta iniciar automaticamente e aguarda 30s
-4. Retorna exit code 0 (server disponível) ou 1 (não disponível após tentativa)
-
-### 5b. Se dev server disponível (exit 0):
-
-**O smoke test é OBRIGATÓRIO.**
-
-1. Leia `spec.md` da feature para identificar os happy paths críticos (máximo 3 flows, seção Functional Requirements)
-2. Execute o smoke test via Playwright MCP:
-
-```javascript
-// Navegar para a feature
-await mcp__playwright__browser_navigate({ url: '<url-detectada>' });
-
-// Capturar estado da página
-await mcp__playwright__browser_snapshot();
-
-// Verificar erros críticos de console
-await mcp__playwright__browser_console_messages({ level: 'error' });
-
-// Screenshot para documentação
-await mcp__playwright__browser_take_screenshot({
-  type: 'png',
-  filename: '.morph/features/$ARGUMENTS/4-implement/smoke-screenshots/smoke-<timestamp>.png'
-});
-```
-
-Para cada happy path crítico da spec:
-- Navegue até o flow
-- Verifique elementos-chave visíveis (`browser_snapshot`)
-- Confirme ausência de erros de console críticos
-- Capture screenshot do estado final
-
-**Verificações obrigatórias:**
-- [ ] Página carrega sem erro 404/500
-- [ ] Elementos principais da feature visíveis (conforme spec)
-- [ ] Console sem erros críticos (level: error)
-- [ ] Happy path principal funcional
-
-**🚫 BLOCK se qualquer verificação falhar.** Não crie PR com smoke test falhando.
-
-### 5c. Se dev server NÃO disponível (exit 1):
-
-**⚠️ ATENÇÃO: Dev server não encontrado após tentativa de iniciar.**
-
-Solicite confirmação explícita ao usuário antes de pular o smoke test:
-
-```
-Dev server não detectado na porta esperada. O smoke test via Playwright é obrigatório
-para garantir que o código funciona no browser antes de criar o PR.
-
-Opções:
-1. Inicie manualmente o servidor (`npm run dev` / `dotnet run`) e re-execute /post-implementation
-2. Confirme explicitamente que deseja pular o smoke test e por quê
-
-Não é possível prosseguir para criação de PR sem smoke test ou confirmação explícita.
-```
-
-**Aguarde resposta antes de continuar.**
-
----
-
-## Step 6 — Code Review Checklist (CRITICAL + HIGH)
-
-> Antes de revisar, leia: `.claude/skills/morph:code-review/references/review-guidelines.md` — aplique confidence ≥ 75, ignore violações pré-existentes, inclua file:line em cada finding.
-
-Revise os itens mais importantes por stack. Para review completo, use os skills dedicados.
-
-### Se FULLSTACK:
-
-Dispatch dois subagents em paralelo (Task tool):
-
-**Subagent 1 — Backend Review:**
-> Revisor .NET focado. Escopo: APENAS arquivos .cs alterados (git diff main...HEAD).
-> Run: `node .claude/skills/morph:code-review/scripts/scan-csharp.mjs --diff`
-> Depois revisar manualmente itens CRITICAL+HIGH do checklist .NET.
-> Aplicar review-guidelines.md: confidence ≥ 75, skip pré-existentes.
-> Output: findings com file:line, ou "✅ Sem CRITICAL/HIGH em backend alterado."
-
-**Subagent 2 — Frontend Review:**
-> Revisor Next.js focado. Escopo: APENAS arquivos .tsx/.ts alterados (git diff main...HEAD).
-> Run: `node .claude/skills/morph:code-review-nextjs/scripts/scan-nextjs.mjs --diff`
-> Depois revisar manualmente itens CRITICAL+HIGH do checklist Next.js.
-> Aplicar review-guidelines.md: confidence ≥ 75, skip pré-existentes.
-> Output: findings com file:line, ou "✅ Sem CRITICAL/HIGH em frontend alterado."
-
-Aguardar ambos. **🚫 BLOCK se algum retornar CRITICAL não resolvido.**
-
-### Se DOTNET:
-
-**Itens CRITICAL e HIGH — .NET:**
-
-```
-[ ] CancellationToken propagado em toda a chain async
-[ ] Sem .Result / .Wait() (deadlock risk)
-[ ] Domain tem zero refs para Infrastructure ou Web
-[ ] Sem circular dependencies
-[ ] Sem empty catch blocks
-[ ] Background ops usam IDbContextFactory + await using
-[ ] Métodos async têm sufixo Async
-[ ] Interfaces prefixadas com I
-[ ] Sem classes > 300 linhas
-[ ] DTOs com nomes descritivos + tipos corretos
-```
-
-> Para lista completa: `/morph:code-review`
-
-### Se NEXTJS:
-
-**Itens CRITICAL e HIGH — Next.js:**
-
-```
-[ ] node .claude/skills/morph:code-review-nextjs/scripts/scan-nextjs.mjs --diff → 0 CRITICAL
-[ ] File names em kebab-case (user-card.tsx, não UserCard.tsx)
-[ ] 'use client' apenas em componentes com hooks/event handlers
-[ ] Sem useEffect para data fetching → Server Component ou useQuery
-[ ] Zod schema definido primeiro, type derivado com z.infer<>
-[ ] zodResolver conectado ao useForm, useMutation para submit
-[ ] Query key factory usado (userKeys.lists(), não ['users'])
-[ ] Feature public API via features/{name}/index.ts
-[ ] components/ui/ intocados (shadcn CLI only)
-[ ] Sem any type annotation
-```
-
-> Para lista completa: `/morph:code-review-nextjs`
-
-**🚫 BLOCK se qualquer item CRITICAL não estiver resolvido.**
-
----
-
-## Step 7 — Checkpoint + Recap
-
-```bash
-# Salvar checkpoint pós-review
-npx morph-spec checkpoint-save $ARGUMENTS --note "post-implementation review"
-
-# Gerar recap final
-npx morph-spec generate recap $ARGUMENTS
-```
-
----
-
-## Step 8 — Finish Worktree
-
-Implementation is complete. If the feature was developed in a morph worktree, finalize it now.
-
-**Check if a worktree exists:**
-```bash
-git worktree list | grep morph/
-```
-
-**If a `morph/{feature}` worktree exists:**
-
-Invoke the finishing-a-development-branch skill:
-```
-Skill(superpowers:finishing-a-development-branch)
-```
-
-This skill will:
-1. Verify tests pass
-2. Present 4 options:
-   - **Merge locally** → merge into base branch + delete worktree
-   - **Push and create PR** → push branch + create GitHub PR (keeps worktree)
-   - **Keep as-is** → no action (worktree preserved for later)
-   - **Discard** → delete branch + worktree (requires typed confirmation)
-3. Clean up worktree for options 1 and 4
-
-**If NOT in a worktree** (legacy mode): skip this step and proceed to Step 9.
-
-> **Note:** If the `superpowers` plugin is not installed, create the PR manually:
-> `gh pr create --title "feat({feature}): <description>" --body "..."`
-
----
-
-## Step 9 — Pre-PR Compliance Checklist
-
-Antes de criar o PR, invoque o checklist de compliance:
-
-```
-Skill(morph:checklist)
-```
-
-Este skill verifica: segurança, SEO, performance, acessibilidade e conformidade LGPD.
-**🚫 BLOCK se qualquer item CRITICAL não estiver resolvido.**
-
----
-
-## Step 10 — PR Suggestion
-
-Quando todos os steps passarem, sugira o PR:
-
-```bash
-gh pr create \
-  --title "feat($ARGUMENTS): <descrição concisa da feature>" \
-  --body "$(cat <<'EOF'
-## Summary
-
-- <principais mudanças implementadas>
-- <tasks concluídas>
-
-## Test Results
-
-- Build: ✅ passou
-- Tests: ✅ X testes passando
-- Smoke Test: ✅ happy path verificado via Playwright
-
-## Screenshots
-
-<!-- Cole os paths dos screenshots salvos em smoke-screenshots/ -->
-
-## Checklist
-
-- [ ] Automated scans: 0 CRITICAL findings
-- [ ] All tests passing
-- [ ] Smoke test via Playwright: ✅
-- [ ] Code review checklist: CRITICAL + HIGH itens verificados
-- [ ] validate-feature: ✅ passou
-- [ ] Checkpoint salvo
-- [ ] recap.md gerado
-EOF
-)"
-```
-
----
-
-## Resumo dos BLOCKs
-
-| Step | Condição de BLOCK |
-|------|-------------------|
-| Step 2 | Qualquer finding CRITICAL nos scans automáticos |
-| Step 3 | Qualquer teste falhando |
-| Step 4 | `validate-feature` falhando |
-| Step 5 | Dev server ativo + smoke test com falha |
-| Step 5 | Dev server não detectado sem confirmação explícita do usuário |
-| Step 6 | Qualquer item CRITICAL não resolvido no checklist manual |
-| Step 8 | Tests failing in worktree before merge/PR |
-| Step 9 | Item CRITICAL no `morph:checklist` não resolvido |
-
-**Todos os BLOCKs devem ser resolvidos antes de criar o PR.**
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-0-meta/terminal-title/SKILL.md

@@ -1,61 +0,0 @@
----
-name: morph:terminal-title
-description: Manually set the terminal window title for the current task. Use when you need to override the automatic title set by the hook, or to set a specific descriptive title for the current work context.
-argument-hint: "[title]"
-user-invocable: true
-allowed-tools: Bash
----
-
-# Terminal Title
-
-## Overview
-
-Manually sets the terminal window title. The hook `set-terminal-title.js` sets titles automatically on every prompt — use this skill only for manual overrides.
-
-## When to Use
-
-- Override the automatic title with something more descriptive
-- Set a custom title at the start of a focused work session
-- Invoke explicitly: `/terminal-title`
-
-## Title Format
-
-```
-[Action]: [Specific Focus]
-```
-
-**Good titles (max 40 chars):**
-- `Fix: Auth Login Bug`
-- `Build: Dashboard UI`
-- `Refactor: Payment Module`
-- `DB Migration: Users Table`
-- `Test: Checkout Flow`
-
-The script (`set_title.sh`) prepends the current directory name automatically:
-```
-morph-spec-framework | Fix: Auth Login Bug
-```
-
-The hook (`set-terminal-title.js`) sets the task title directly, without a directory prefix:
-```
-Fix: Auth Login Bug
-```
-
-## Implementation
-
-Run the title script with the desired title:
-
-```bash
-bash .claude/skills/terminal-title/scripts/set_title.sh "Fix: Auth Login Bug"
-```
-
-No confirmation needed — executes silently in the background.
-
-## Optional Custom Prefix
-
-Set `CLAUDE_TITLE_PREFIX` in your environment to add a custom prefix:
-
-```bash
-export CLAUDE_TITLE_PREFIX="🤖"
-# Results in: 🤖 morph-spec-framework | Fix: Auth Login Bug
-```

package/framework/skills/level-0-meta/terminal-title/scripts/set_title.sh

@@ -1,65 +0,0 @@
-#!/bin/bash
-# Set terminal window title
-# Usage: ./set_title.sh "Your Title Here"
-#
-# The script automatically prefixes the title with the current directory name
-# (usually the repo/project name) for easy identification across multiple terminals.
-#
-# Optional: Set CLAUDE_TITLE_PREFIX environment variable for additional custom prefix
-# Example: export CLAUDE_TITLE_PREFIX="🤖"
-#          Results in: "🤖 my-project | Your Title"
-
-# Exit silently if no title provided (fail-safe behavior)
-if [ -z "$1" ]; then
-    exit 0
-fi
-
-# Validate and sanitize input
-# Remove control characters (0x00-0x1F) and limit length to 80 characters
-TITLE=$(echo "$1" | tr -d '\000-\037' | head -c 80)
-
-# Ensure title is not empty after sanitization
-if [ -z "$TITLE" ]; then
-    exit 0
-fi
-
-# Get the current directory name (usually the repo/project name)
-DIR_NAME=$(basename "$PWD")
-
-# Build the final title with directory prefix and optional custom prefix
-if [ -n "$CLAUDE_TITLE_PREFIX" ]; then
-    # Sanitize prefix as well
-    PREFIX=$(echo "$CLAUDE_TITLE_PREFIX" | tr -d '\000-\037' | head -c 20)
-    if [ -n "$PREFIX" ]; then
-        FINAL_TITLE="${PREFIX} ${DIR_NAME} | ${TITLE}"
-    else
-        FINAL_TITLE="${DIR_NAME} | ${TITLE}"
-    fi
-else
-    FINAL_TITLE="${DIR_NAME} | ${TITLE}"
-fi
-
-# Store the title in a file that shell hooks can read
-# This allows precmd hooks (like update_terminal_cwd) to preserve the title
-# Use atomic write to prevent race conditions
-TITLE_FILE="${HOME}/.claude/terminal_title"
-mkdir -p "${HOME}/.claude"
-
-# Atomic write using temp file + rename
-TEMP_FILE="${TITLE_FILE}.tmp.$$"
-echo "$FINAL_TITLE" > "$TEMP_FILE"
-mv "$TEMP_FILE" "$TITLE_FILE" 2>/dev/null || rm -f "$TEMP_FILE"
-
-# Set the terminal title using ANSI escape sequences
-# Detect terminal type and set title accordingly
-case "$TERM" in
-    xterm*|rxvt*|screen*|tmux*)
-        # Standard xterm-compatible terminals
-        printf '\033]0;%s\007' "$FINAL_TITLE"
-        ;;
-    *)
-        # Fallback: try anyway, suppress errors
-        # This works for iTerm2, Alacritty, and most modern terminals
-        printf '\033]0;%s\007' "$FINAL_TITLE" 2>/dev/null
-        ;;
-esac

package/framework/skills/level-1-workflows/phase-clarify/SKILL.md

@@ -1,216 +0,0 @@
----
-name: morph:phase-clarify
-description: MORPH-SPEC Phase 3 (Clarify). Reviews spec.md for ambiguities, generates 3-7 targeted clarification questions, waits for user answers, then updates spec with edge cases and clarification sections. Use after design approval to eliminate spec ambiguities before task breakdown begins.
-argument-hint: "[feature-name]"
-user-invocable: false
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.9.0"
----
-
-# MORPH Clarify - FASE 3
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Identifique ambiguidades na especificação e faça perguntas de clarificação para garantir que todos os edge cases estão cobertos.
-
-## Pré-requisitos
-
-- [ ] FASE 2 (Design) concluída
-- [ ] `spec.md` aprovado pelo usuário
-- [ ] `contracts.cs` definidos
-
-## Ferramentas Recomendadas
-
-> **Ref:** `framework/skills/level-0-meta/tool-usage-guide/SKILL.md` para guia completo.
-> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` para referência MCP.
-> **Example:** `references/clarifications-example.md` — filled-in clarifications.md showing expected Q&A format.
-
-| Ação | Ferramenta | Alternativa |
-|------|------------|-------------|
-| Ler spec.md completo | **Read** spec.md | — |
-| Ler contracts.cs | **Read** contracts.cs | — |
-| Ler schema-analysis.md | **Read** schema-analysis.md | — |
-| Verificar viabilidade de requisito | **Context7 MCP** `query_docs()` | **WebSearch** + **WebFetch** |
-| Verificar issues/limitações conhecidas | **GitHub MCP** `search_issues()` | **Bash** `gh issue list --search "..."` |
-| Pesquisar edge cases externos | **WebSearch** | — |
-| Verificar comportamento UI existente | **Playwright MCP** `browser_navigate()` + `browser_snapshot()` | **WebFetch** URL |
-| Atualizar spec com clarificações | **Edit** spec.md | — |
-| Criar clarifications.md | **Bash** `npx morph-spec template render docs/clarifications .morph/features/$ARGUMENTS/2-clarify/clarifications.md` | — |
-| Atualizar state | **Bash** `npx morph-spec state mark-output $ARGUMENTS clarifications` | — |
-
-**MCPs desta fase:** Context7 (validar viabilidade), GitHub (issues conhecidas), Playwright (verificar UI existente).
-
-**Anti-padrões:**
-- ❌ Task agent para ler spec (use Read direto)
-- ❌ Reescrever spec do zero (use Edit para atualizar seções)
-- ❌ Pular cross-reference com schema-analysis.md (crítico para precisão)
-
----
-
-## Workflow
-
-### Passo 1: Analisar Spec
-
-Leia `.morph/features/$ARGUMENTS/1-design/spec.md` em detalhes e identifique:
-
-#### 1.1. Ambiguidades
-- Requisitos vagos ou genéricos
-- Termos sem definição clara
-- Comportamentos não especificados
-
-#### 1.2. Edge Cases Não Documentados
-- O que acontece se...?
-- Como lidar com entradas inválidas?
-- Comportamento em caso de erro?
-- Estados intermediários (loading, empty)
-
-#### 1.3. Requisitos Conflitantes
-- Duas funcionalidades que parecem incompatíveis
-- Prioridades não claras (o que vem primeiro?)
-
-#### 1.4. Dados Faltantes
-- Validações de negócio não especificadas
-- Limites e constraints (tamanhos, quantidades)
-- Formatos de dados (datas, moedas, etc.)
-
-### Passo 2: Gerar Perguntas de Clarificação
-
-Com base na análise, gere **3-7 perguntas** focadas e específicas:
-
-**Formato de pergunta:**
-```markdown
-### Q{N}: {Categoria} - {Título}
-
-**Context:** {Por que esta pergunta é importante}
-
-**Question:** {Pergunta clara e objetiva}
-
-**Options (if applicable):**
-- A) {Opção 1}
-- B) {Opção 2}
-- C) {Deixar em aberto/usuário decidir}
-
-**Impact:** {Como a resposta afeta a implementação}
-```
-
-### Passo 3: Categorizar Perguntas
-
-Organize perguntas por categoria:
-
-| Categoria | Descrição | Exemplos |
-|-----------|-----------|----------|
-| **Validação** | Regras de negócio, constraints | Limites de tamanho, formatos aceitos |
-| **Comportamento** | O que acontece quando... | Error handling, estados vazios |
-| **Prioridade** | O que é must-have vs nice-to-have | MVP vs futuras iterações |
-| **Integração** | Como interage com sistemas externos | APIs, webhooks, formato de dados |
-| **Performance** | Requisitos de velocidade/volume | Quantos registros? Tempo de resposta? |
-| **UX** | Experiência do usuário | Feedback visual, mensagens de erro |
-
-### Passo 4: Apresentar Perguntas ao Usuário via AskUserQuestion
-
-Use o tool `AskUserQuestion` para coletar as respostas — **NUNCA liste perguntas como texto simples**.
-
-**Regras:**
-- `AskUserQuestion` aceita **1-4 perguntas por chamada**
-- Se houver 5-7 perguntas, faça **2 chamadas sequenciais** (ex: Q1-Q4 → Q5-Q7)
-- Cada pergunta deve ter `header` (≤12 chars), `question` clara e 2-4 `options`
-- Se a pergunta for aberta sem opções fixas, defina 2-3 opções representativas (o usuário pode usar "Other" para resposta livre)
-- Use `multiSelect: true` quando múltiplas respostas forem igualmente válidas
-- Aguarde o retorno do tool antes de prosseguir para qualquer próximo passo
-
-**Exemplo de estrutura:**
-```json
-{
-  "questions": [
-    {
-      "header": "Validação",
-      "question": "Qual o limite de tamanho para o campo Nome?",
-      "multiSelect": false,
-      "options": [
-        { "label": "100 chars", "description": "Padrão comum para nomes curtos" },
-        { "label": "255 chars", "description": "Máximo típico de banco de dados" },
-        { "label": "Sem limite fixo", "description": "Apenas validação no frontend" }
-      ]
-    }
-  ]
-}
-```
-
-**IMPORTANTE:** Não prossiga para o Passo 5 até receber respostas de TODAS as perguntas!
-
-### Passo 5: Atualizar `spec.md` com Respostas
-
-Após receber respostas do usuário, atualize o spec com:
-
-1. **Seção de Clarificações** no início do spec:
-```markdown
-## Clarifications (FASE 3)
-
-### Q1: {Título}
-**Answer:** {Resposta do usuário}
-**Date:** {YYYY-MM-DD}
-```
-
-2. **Atualizar seções relevantes** com detalhes adicionados
-
-### CHECKPOINT: Validar Respostas Completas
-
-**⏸️ PAUSE - Antes de atualizar spec:**
-
-- [ ] Todas as perguntas foram respondidas pelo usuário?
-- [ ] Nenhuma resposta é ambígua ou contraditória?
-- [ ] Respostas são consistentes com `contracts.cs` existente?
-- [ ] Respostas são consistentes com `schema-analysis.md`?
-
-**❌ Se alguma checkbox NÃO estiver marcada:**
-→ Voltar e pedir esclarecimento adicional ao usuário
-
-**✅ Se TODAS as checkboxes estiverem marcadas:**
-→ Prosseguir para atualizar spec.md
-
-### Passo 6: Validar Edge Cases
-
-Documente no spec como lidar com cada edge case identificado:
-
-```markdown
-## Edge Cases
-
-### EC001: {Nome do Edge Case}
-**Scenario:** {Quando acontece}
-**Expected Behavior:** {Como o sistema deve reagir}
-**Implementation Notes:** {Dicas para implementação}
-```
-
-### Passo 7: Atualizar State
-
-## Outputs Gerados/Atualizados
-
-- `.morph/features/$ARGUMENTS/1-design/spec.md` - Atualizado com:
-  - Seção "Clarifications" com perguntas e respostas
-  - Edge cases documentados
-  - Requisitos mais específicos
-- `.morph/features/$ARGUMENTS/2-clarify/clarifications.md` - Novo arquivo com Q&A estruturado
-
-## Critérios de Avanço
-
-- [x] Perguntas de clarificação identificadas (3-7)
-- [x] Perguntas apresentadas ao usuário
-- [x] Respostas do usuário recebidas
-- [x] `spec.md` atualizado com clarificações
-- [x] Edge cases documentados
-- [x] State atualizado
-- [x] Nenhuma ambiguidade crítica remanescente
-
----
-
-## Integração com Superpowers
-
-> Disponível quando o plugin `superpowers` está instalado.
-
-| Skill | Quando Usar | Invocação |
-|-------|-------------|-----------|
-| `systematic-debugging` | Para investigar ambiguidades técnicas complexas | `Skill(superpowers:systematic-debugging)` |
-
----
-
-Continuar automaticamente para FASE 4 (Tasks) após clarificações resolvidas.