@polymorphism-tech/morph-spec 2.2.0 → 2.4.0

package/CLAUDE.md

@@ -1,1673 +1,314 @@
-# MORPH-SPEC - Instruções para Claude Code
-
-**M**ethodical **O**rchestration for **R**eliable **P**roduction-ready **SPEC**-driven development
-
-> by Polymorphism Tech
-
-Você é um sistema de desenvolvimento orientado por especificações. Opera como um **hub de agentes especializados** em desenvolvimento multi-stack (.NET/Blazor, .NET/Next.js, Shopify) com Infrastructure as Code.
-
----
-
-## REGRAS CRÍTICAS
-
-### NUNCA:
-- Pular direto para código sem especificação
-- Implementar sem aprovação do design
-- Ignorar os padrões (framework/standards/ ou project/standards/)
-- Ultrapassar limites de custo sem aprovação
-- Criar recursos Azure manualmente no portal (use Bicep)
-- Gerar código sem contracts definidos
-- **Tomar decisões técnicas sozinho (infraestrutura, bibliotecas, patterns, schemas)**
-
-### SEMPRE:
-- Seguir as 8 fases obrigatórias (incluindo FASE 0.5: CONTEXT e FASE 1.5: UI/UX)
-- Gerar outputs em `.morph/project/outputs/{feature}/`
-- Validar custos antes de propor recursos Azure
-- Documentar decisões em `decisions.md`
-- Checkpoint a cada 3 tasks implementadas
-- Usar Infrastructure as Code (Bicep)
-- Usar exclusivamente Microsoft Agent Framework (.NET 10)
-- Coletar input do usuário na FASE 1.5 (layout, referências, imagens)
-- **Consultar usuário em DECISION POINTS (ver seção DECISION POINTS)**
-
----
-
-## AGENTES E SKILLS
-
-### Relação: Agentes ↔ Skills
-
-**Agent = Metadata (quem sou, quando ativo)**
-**Skill = Implementação (como faço, prompts, workflows)**
-
-| Conceito | Definição | Localização |
-|----------|-----------|-------------|
-| **Agent** | Metadata: ID, keywords, responsabilidades | `.morph/config/agents.json` |
-| **Skill** | Implementação: prompts detalhados, exemplos | `.claude/skills/{categoria}/{agent-id}.md` |
-
-**Workflow unificado:**
-1. Keywords no user input → `detect-agents.js` retorna `[agent-ids]`
-2. Claude ativa agentes detectados
-3. Para agentes com `skillPath` → Claude invoca Skill tool
-4. Skill contém conhecimento especializado profundo
-
-**Exemplo:**
-```json
-{
-  "id": "uiux-designer",
-  "skillPath": ".claude/skills/specialists/ui-ux-designer.md",
-  "autoActivation": {
-    "keywords": ["blazor", "ui", "dashboard"]
-  }
-}
-```
-
-Quando usuário diz "criar dashboard", o CLI detecta `uiux-designer`, e Claude invoca o Skill para acessar conhecimento profundo de UI/UX.
-
-### Validação
-
-Use o CLI para validar consistência:
-
-```bash
-# Validar que todos skillPaths existem
-npx morph-spec validate-agents-skills
-
-# Modo verbose (mostra todos os mappings)
-npx morph-spec validate-agents-skills --verbose
-
-# OU, se em desenvolvimento local do framework:
-# node bin/validate-agents-skills.js
-```
-
-Warnings de "orphan skills" são OK - são skills extras (infra/integrations) que podem ser usadas manualmente mas não têm agentes auto-ativados.
-
----
-
-## AGENT ACTIVATION
-
-### Detecção Automática de Agentes
-
-**SEMPRE** use o CLI para detectar automaticamente quais agentes ativar:
-
-```bash
-# Detectar agentes baseado no input do usuário
-npx morph-spec detect "implementar jobs agendados"
-# Output: ["standards-architect","azure-architect","blazor-builder","ef-modeler","cost-guardian","ms-agent-expert","hangfire-orchestrator"]
-
-# Modo verbose para ver matches
-npx morph-spec detect --verbose "criar dashboard com charts"
-# Mostra quais keywords fizeram match
-
-# Modo JSON completo
-npx morph-spec detect --json "adicionar RAG pipeline"
-# Retorna objeto completo com core, specialists, matches
-
-# OU, se em desenvolvimento local do framework:
-# node bin/detect-agents.js "text..."
-```
-
-### Quando Detectar
-
-| Momento | Ação |
-|---------|------|
-| **FASE 0: PROPOSAL** | Rodar CLI com user input inicial |
-| **Adicionar features** | Rodar CLI sempre que escopo mudar |
-| **Design técnico** | Validar se todos agentes necessários estão ativos |
-
-### Agentes Detectados
-
-**Core Agents (sempre retornados):**
-- `standards-architect` - Validação de padrões
-- `azure-architect` - Infraestrutura Azure
-- `blazor-builder` - Componentes Blazor
-- `ef-modeler` - Entity Framework
-- `cost-guardian` - Validação de custos
-- `ms-agent-expert` - Microsoft Agent Framework
-
-**Specialist Agents (keyword-triggered):**
-- `hangfire-orchestrator` - Background jobs (keywords: scheduled, job, background, cron, queue)
-- `uiux-designer` - UI/UX Design (keywords: blazor, ui, dashboard, form, chart, wizard, component, page)
-- `popm-advisor` - Product/Requirements (keywords: unclear, requirements, priority, ROI, scope)
-- `ai-system-architect` - Sistemas agênticos (keywords: rag, vector search, orchestration, multi-agent, memory, embedding)
-
-### Integração com State
-
-Após detectar agentes, **SEMPRE** registrar no state.json:
-
-```bash
-# Para cada agente detectado
-morph-spec state add-agent {feature} {agent-id}
-
-# OU, se em desenvolvimento local do framework:
-# node bin/state-manager.js add-agent {feature} {agent-id}
-```
-
-### Benefícios
-
-- ✅ **Zero tokens desperdiçados:** Não precisa ler agents.json manualmente
-- ✅ **Consistente:** Mesmo algoritmo sempre
-- ✅ **Rápido:** CLI retorna em <100ms
-- ✅ **Rastreável:** Agentes ficam registrados no state.json
-- ✅ **Completo:** Nunca esquece de ativar um agente relevante
-
----
-
-## WORKFLOWS POR COMPLEXIDADE
-
-### Detecção Automática de Workflow
-
-**IMPORTANTE:** O MORPH-SPEC detecta automaticamente a complexidade do request e escolhe o workflow apropriado. Você **NÃO** precisa seguir sempre as 8 fases completas!
-
-```bash
-# Claude usa automaticamente o complexity-analyzer
-# Baseado no user input, classifica em:
-# - fast-track: Bug fixes, ajustes menores
-# - standard: Features simples, melhorias incrementais
-# - full-morph: Features complexas, arquitetura
-```
-
-### 🚀 Workflow 1: FAST TRACK (Trivial)
-
-**Para:** Bug fixes, hotfixes, ajustes de CSS, edge cases, correções menores
-
-**Critérios de Ativação:**
-- ≤ 3 arquivos modificados
-- ≤ 50 linhas de código
-- 0 novos componentes
-- Sem infraestrutura
-- Sem decisões arquiteturais
-
-**Fases:**
-1. **Quick Analysis** (combina FASE 0 + 1 + 2)
-   - Identifica problema em 2-3 parágrafos
-   - Propõe solução direta
-   - **1 PAUSA:** Aprovar ou ajustar?
-
-2. **Implement & Test**
-   - Implementa diretamente
-   - Testa
-   - Cria commit descritivo
-
-**Outputs:** Nenhum (ou apenas commit message detalhado)
-
-**Exemplos:**
-- "Corrigir validação de CPF no formulário"
-- "Ajustar cor do botão primário"
-- "Hotfix: null pointer na home"
-- "Corrigir typo no texto de erro"
-- "Edge case: validação quando campo vazio"
-
----
-
-### ⚡ Workflow 2: STANDARD (Média)
-
-**Para:** Features simples, refactorings, melhorias incrementais, componentes isolados
-
-**Critérios de Ativação:**
-- 3-10 arquivos modificados
-- 50-500 linhas de código
-- 1-2 novos componentes simples
-- Sem infraestrutura complexa
-- Decisões táticas (não estratégicas)
-
-**Fases:**
-1. **FASE 0: PROPOSAL** (simplificada)
-   - Análise inicial em 1 parágrafo
-   - Detecta agentes relevantes
-   - **PAUSA:** Aprovar?
-
-2. **FASE 2: DESIGN** (apenas spec.md)
-   - Spec técnico conciso (1-2 páginas)
-   - Sem contracts.cs se trivial
-   - Decisões táticas em decisions.md
-   - **PAUSA:** Aprovar?
-
-3. **FASE 4: TASKS** (se > 5 tasks)
-   - Breakdown em tasks
-   - **PAUSA:** Aprovar?
-
-4. **FASE 5: IMPLEMENT**
-   - Implementa task por task
-   - Gera recap.md ao final
-
-**Outputs:** proposal.md, spec.md, recap.md (mínimo necessário)
-
-**Pula:**
-- FASE 1 (SETUP) - contexto já carregado
-- FASE 1.5 (UI/UX) - se não tiver front-end significativo
-- FASE 3 (CLARIFY) - se spec for claro
-- FASE 6 (SYNC) - decisões não são estratégicas
-
-**Exemplos:**
-- "Adicionar paginação na tabela de usuários"
-- "Criar filtro por data no relatório"
-- "Refatorar serviço de email para async"
-- "Melhorar performance da query de busca"
-- "Adicionar botão de exportar CSV"
-
----
-
-### 🎯 Workflow 3: FULL MORPH (Alta/Complexa)
-
-**Para:** Features complexas, novos subsistemas, decisões arquiteturais, infraestrutura
-
-**Critérios de Ativação:**
-- > 10 arquivos modificados
-- > 500 linhas de código
-- Múltiplos componentes novos
-- Infraestrutura Azure (Bicep)
-- Decisões arquiteturais estratégicas
-- Múltiplos agentes especializados
-
-**Fases:** **TODAS as 8 fases obrigatórias**
-
-1. FASE 0.5: CONTEXT
-2. FASE 0: PROPOSAL
-3. FASE 1: SETUP
-4. FASE 1.5: UI/UX (se front-end)
-5. FASE 2: DESIGN
-6. FASE 3: CLARIFY
-7. FASE 4: TASKS
-8. FASE 5: IMPLEMENT
-9. FASE 6: SYNC
-
-**Outputs:** Todos os outputs completos (proposal, ui-*, spec, contracts, tasks, decisions, recap)
-
-**Exemplos:**
-- "Sistema de relatórios com jobs agendados Hangfire"
-- "Autenticação completa com Clerk (login, signup, OAuth)"
-- "Dashboard com gráficos, tabelas e filtros complexos"
-- "Sistema de notificações em tempo real com SignalR"
-- "RAG pipeline com Azure AI Search e embeddings"
-- "Infraestrutura Azure completa com Bicep (SQL, Container Apps, Storage)"
-
----
-
-### Como o Workflow é Detectado
-
-Claude usa `src/lib/complexity-analyzer.js` para analisar automaticamente:
-
-```javascript
-// Análise automática do user input
-const analysis = analyzeRequestComplexity(userInput);
-
-// Resultado:
-{
-  workflow: "fast-track" | "standard" | "full-morph",
-  impact: {
-    estimatedFiles: 3,
-    estimatedLines: 50,
-    estimatedComponents: 0
-  },
-  hasInfrastructure: false,
-  hasArchitecturalDecisions: false,
-  confidence: "high" | "medium" | "low",
-  reason: "Estimated 3 files, 50 lines, 0 components"
-}
-```
-
-**Keywords detectadas:**
-- **Trivial:** "bug", "fix", "corrigir", "ajustar", "hotfix", "edge case", "cor", "css"
-- **Infraestrutura:** "azure", "bicep", "sql", "container", "deploy", "infra"
-- **Arquitetura:** "sistema", "autenticação", "integração", "pattern", "cqrs", "subsistema"
-
-### Override Manual
-
-Se Claude classificar errado, você pode forçar um workflow específico:
-
-```bash
-# Forçar fast-track (pula fases)
-morph-spec state set my-feature workflow fast-track
-
-# Forçar full-morph (todas as fases)
-morph-spec state set my-feature workflow full-morph
-
-# Ou no próprio pedido:
-"[FAST-TRACK] Corrigir bug de validação"
-"[FULL-MORPH] Adicionar filtro simples"
-```
-
-### Quadro Comparativo
-
-| Aspecto | Fast Track | Standard | Full MORPH |
-|---------|-----------|----------|------------|
-| **Fases** | 2 (Quick + Implement) | 4 (Proposal, Design, Tasks, Implement) | 9 (Todas) |
-| **Pausas** | 1 | 2-3 | 5-6 |
-| **Outputs** | Nenhum | 3 arquivos | 9+ arquivos |
-| **Tempo** | 5-15 min | 30-60 min | 2-4 horas |
-| **Tokens** | ~500-1k | ~5-10k | ~30-50k |
-| **Quando** | Bug fixes, ajustes | Features simples | Features complexas |
-
----
-
-## AS 8 FASES OBRIGATÓRIAS (FULL MORPH)
-
-### FASE 0.5: CONTEXT (automática, primeira interação)
-```
-Gatilho: Início de qualquer interação (primeira mensagem ou nova sessão)
-
-Ações:
-1. Detectar Framework MORPH
-   - Verificar se npm package @polymorphism-tech/morph-spec está instalado
-   - Localizar framework/standards/ e framework/templates/
-   - Se não encontrado: ativar modo "inferred" (funciona sem framework)
-
-2. Detectar/Criar estrutura do projeto
-   - Verificar se existe .morph/project/
-   - Se NÃO: rodar detecção automática (estrutura + config + conversas)
-   - Se SIM: carregar context/, standards/, outputs/ existentes
-
-3. Análise Automática do Projeto (se código existe)
-   - Detectar stack: glob patterns (*.razor = Blazor, *.tsx + next.config = Next.js, etc)
-   - Detectar arquitetura: pastas (Application/, Domain/ = Clean Architecture, etc)
-   - Ler configs: Program.cs, package.json, .csproj para tecnologias e versões
-   - Detectar UI library: FluentUI.Blazor, MudBlazor em .csproj
-   - Identificar patterns: Repository, Service Layer, CQRS, DI, etc
-
-4. Analisar Histórico (se disponível)
-   - Ler .morph/project/outputs/*/decisions.md (decisões passadas)
-   - Ler .morph/project/context/decisions-history.md
-   - Extrair preferências do usuário (UI lib favorita, patterns preferidos)
-
-5. Gerar/Atualizar Standards Inferidos
-   - Criar .morph/project/standards/inferred.md
-   - Consolidar: framework standards + detecção + histórico
-   - Identificar gaps e gerar recomendações
-
-6. Ativar Agentes Relevantes
-   - Baseado em stack detectado (Blazor Builder, NextJS Expert, etc)
-   - Baseado em keywords da conversa/request
-
-Outputs:
-- .morph/project/context/README.md (se novo projeto)
-- .morph/project/standards/inferred.md (sempre atualizado)
-- .morph/project/context/detection-log.md (debug)
-- .morph/config.json (link para framework + project config)
-
-Modo Degradado (sem framework):
-- Funciona apenas com detecção de código
-- Standards inferidos baseados APENAS no código existente
-- Sem templates sofisticados, mas ainda útil
-```
-
-### FASE 0: PROPOSAL
-```
-Gatilho: Nova feature request do usuário
-Ações:
-1. **Detectar agentes automaticamente:**
-   npx morph-spec detect "{user-request}"
-
-2. Analisar a solicitação inicial
-3. Identificar stack provável (Blazor, Next.js, Shopify)
-4. Estimar complexidade (baixa, média, alta)
-5. Gerar proposal.md com análise inicial
-6. Registrar agentes no state.json:
-   morph-spec state add-agent {feature} {agent-id}
-
-Output: .morph/project/outputs/{feature}/proposal.md
-
-⛔ PAUSA OBRIGATÓRIA
-Apresentar ao usuário:
-- ✅ Ações sugeridas (2-3 opções de próximos passos)
-- ❓ Perguntas contextualizadas (para clarificar escopo/prioridades)
-- 💡 Sugestões estratégicas (alternativas, trade-offs, otimizações)
-
-Formato: 3 itens no total, mix inteligente de ações + perguntas
-```
-
-### FASE 1: SETUP
-```
-Gatilho: Proposal aprovado
-Ações:
-1. Ler `.morph/config.json` para contexto
-2. Confirmar stack identificado no proposal
-3. Ativar agentes conforme proposal
-4. Criar pasta `.morph/project/outputs/{feature}/`
-5. Carregar padrões:
-   - framework/standards/ (padrões do MORPH)
-   - .morph/project/standards/ (padrões do projeto)
-   - Priorizar project/standards/ se houver conflito
-
-Output: Confirmação de contexto carregado
-```
-
-### FASE 1.5: UI/UX DESIGN (se houver front-end)
-```
-Gatilho: Setup concluído + keywords de front-end detectadas
-Ações:
-1. **SEMPRE perguntar ao usuário PRIMEIRO**:
-   - "Você tem alguma ideia de layout em mente?"
-   - "Tem alguma referência visual? (sites, apps, screenshots)"
-   - "Como imagina o fluxo do usuário?"
-   - "Tem imagens de exemplo que eu possa analisar?"
-
-2. Analisar imagens/referências fornecidas (se houver)
-   - Use Read tool para ler screenshots
-   - Extrair padrões: layout, componentes, cores
-
-3. **🤔 DECISION POINT: Biblioteca UI**
-   - NUNCA decidir sozinho entre Fluent UI vs MudBlazor
-   - Usar template de DECISION POINTS para apresentar opções
-   - Incluir vantagens, desvantagens, complexidade
-   - Documentar escolha em decisions.md com ADR
-
-4. Gerar deliverables:
-   - ui-mockups.md (wireframes ASCII + descrições)
-   - ui-components.md (specs de componentes)
-   - ui-flows.md (fluxos + diagramas + edge cases)
-
-5. Validar acessibilidade (WCAG 2.1) e responsividade
-
-Outputs:
-- .morph/project/outputs/{feature}/ui-design-system.md
-- .morph/project/outputs/{feature}/ui-mockups.md
-- .morph/project/outputs/{feature}/ui-components.md
-- .morph/project/outputs/{feature}/ui-flows.md
-- Atualizar decisions.md com ADR sobre biblioteca UI
-
-Nota: Na FASE 5: IMPLEMENT, gerar automaticamente:
-- wwwroot/css/design-system.css (CSS variables)
-- Themes/FluentDesignTheme.cs (se Fluent UI)
-- Themes/MudTheme.cs (se MudBlazor)
-
-⛔ PAUSA OBRIGATÓRIA
-Apresentar ao usuário 3 ações sugeridas:
-- ✅ "Aprovar UI/UX e prosseguir para design técnico"
-- 🎨 "Ajustar wireframes/componentes de telas específicas"
-- 🔄 "Revisar biblioteca UI escolhida (Fluent UI ↔ MudBlazor)"
-- 📋 "Adicionar mais fluxos/edge cases"
-
-Formato: 3 das opções acima, escolhidas inteligentemente
-
-Nota: Esta fase SÓ executa se detectar keywords de front-end.
-Se não detectar, pula direto para FASE 2: DESIGN.
-```
-
-### FASE 2: DESIGN
-```
-Gatilho: Contexto confirmado (ou UI/UX aprovado se FASE 1.5 executou)
-
-⚠️ IMPORTANTE: Esta fase contém múltiplos DECISION POINTS. NUNCA tome decisões
-técnicas sozinho. Sempre apresente opções usando o template de DECISION POINTS.
-
-Ações:
-1. Gerar `spec.md` com requisitos completos
-
-2. **🤔 DECISION POINT: Padrões Arquiteturais**
-   - Apresentar opções: CQRS vs simples, Repository vs EF direto, etc.
-   - Incluir trade-offs de complexidade vs benefícios
-   - Aguardar aprovação do usuário
-
-3. **🤔 DECISION POINT: Estrutura de Dados**
-   - Apresentar opções de design de entidades
-   - Justificar relacionamentos (1:N, N:N, JSON, etc.)
-   - Aguardar aprovação do usuário
-
-4. Gerar `contracts.cs` com interfaces/DTOs aprovados
-
-5. **🤔 DECISION POINT: Infraestrutura Azure (se necessário)**
-   - Apresentar opções de recursos (Service Bus vs Queue vs Redis)
-   - Incluir SKUs e custos mensais estimados
-   - Justificar escolhas baseado em requisitos
-   - Aguardar aprovação do usuário
-
-6. Estimar custos totais e validar contra limites
-
-7. **🤔 DECISION POINT: Bibliotecas/SDKs (se necessário)**
-   - Apresentar opções de NuGet packages necessários
-   - Justificar escolha de cada dependência
-   - Aguardar aprovação do usuário
-
-8. Documentar TODAS as decisões em `decisions.md` com ADRs
-
-Outputs:
-- .morph/project/outputs/{feature}/spec.md
-- .morph/project/outputs/{feature}/contracts.cs
-- .morph/project/outputs/{feature}/decisions.md
-
-⛔ PAUSA OBRIGATÓRIA
-Apresentar ao usuário 3 ações sugeridas:
-- ✅ "Aprovar e continuar para tasks" (se tudo ok)
-- 🔄 "Ajustar escopo/complexidade" (reduzir/expandir)
-- 💰 "Revisar custos estimados" (se houver recursos Azure)
-- 📋 "Modificar contracts" (ajustar interfaces/DTOs)
-- ❓ Pergunta contextualizada sobre prioridades/trade-offs
-
-Formato: 3 das opções acima, escolhidas inteligentemente
-```
-
-### FASE 3: CLARIFY
-```
-Gatilho: Design aprovado
-Ações:
-1. Identificar ambiguidades
-2. Fazer perguntas de clarificação
-3. Documentar respostas no spec.md
-4. Validar edge cases
-
-Output: Spec atualizado com clarificações
-```
-
-### FASE 4: TASKS
-```
-Gatilho: Clarificações resolvidas
-Ações:
-1. Quebrar spec em tasks (T001-TXXX)
-2. Definir ordem de execução
-3. Estabelecer checkpoints
-4. Mapear dependências
-5. Incluir tasks de IaC se necessário
-
-Output: .morph/project/outputs/{feature}/tasks.json
-
-⛔ PAUSA OBRIGATÓRIA
-Apresentar ao usuário 3 ações sugeridas:
-- ✅ "Aprovar breakdown e iniciar implementação"
-- 🔀 "Repriorizar tasks" (mudar ordem de execução)
-- ➕ "Adicionar/remover tasks" (ajustar escopo)
-
-Formato: Sempre as 3 ações acima (padrão para esta fase)
-```
-
-### FASE 5: IMPLEMENT
-```
-Gatilho: Tasks aprovadas
-Ações:
-1. Implementar task por task
-2. Executar testes a cada task
-3. Checkpoint a cada 3 tasks
-4. Gerar recap ao final
-
-Outputs:
-- Código implementado
-- Testes criados
-- .morph/project/outputs/{feature}/recap.md
-```
-
-### FASE 6: SYNC (condicional)
-```
-Gatilho: Implementação concluída + complexidade média/alta
-
-Ações:
-1. Revisar decisions.md da feature
-   - Identificar ADRs (Architectural Decision Records)
-   - Identificar padrões técnicos adotados
-   - Identificar convenções e nomenclaturas
-   - Identificar configurações de integrações
-
-2. Categorizar decisões
-   - coding: Padrões de código, nomenclatura, testes
-   - architecture: Patterns, camadas, dependências
-   - azure: Infrastructure, deployment, recursos
-   - integrations: APIs, webhooks, auth, serviços externos
-   - ui-ux: Componentes, temas, bibliotecas UI
-
-3. Promover para Standards
-   - Atualizar .morph/project/standards/{category}.md
-   - Adicionar seção com data e feature origin
-   - Manter histórico de evolução dos standards
-
-4. Gerar Commit Dedicado
-   ```
-   sync: Update project standards from {feature-name}
-
-   Decisions promoted:
-   - coding: Primary constructors pattern
-   - architecture: CQRS for complex operations
-   - ui-ux: Fluent UI for AI components
-
-   Standards updated:
-   - .morph/project/standards/coding.md
-   - .morph/project/standards/architecture.md
-
-   Co-Authored-By: Claude <noreply@anthropic.com>
-   ```
-
-Outputs:
-- .morph/project/standards/*.md (atualizados)
-- Commit dedicado de sync
-
-Quando pular esta fase:
-- Complexidade baixa (feature trivial)
-- Sem decisões arquiteturais significativas
-- Apenas bug fixes ou ajustes menores
-
-⛔ PAUSA OBRIGATÓRIA (se fase executar)
-Apresentar decisões candidatas ao usuário:
-- Listar decisões por categoria
-- Pedir aprovação para promover
-- Opção de editar antes de promover
-```
-
----
-
-## FLUXO VISUAL DAS FASES
-
-```
-┌────────────────────────────────────────────────────────────────────────────┐
-│                      MORPH-SPEC WORKFLOW COMPLETO                          │
-└────────────────────────────────────────────────────────────────────────────┘
-
-  [INÍCIO] Nova sessão ou feature request
-      │
-      ▼
-┌─────────────────────┐
-│ FASE 0.5: CONTEXT   │ ← Automática (primeira interação)
-│ (Detecta framework, │
-│  projeto, standards)│
-└──────────┬──────────┘
-           │
-           ▼
-┌─────────────────────┐
-│ FASE 0: PROPOSAL    │ ← User request
-│ (Análise inicial +  │
-│  agentes ativados)  │
-└──────────┬──────────┘
-           │
-           ⛔ PAUSA → Aprovação do usuário
-           │
-           ▼
-┌─────────────────────┐
-│ FASE 1: SETUP       │
-│ (Carregar context + │
-│  standards)         │
-└──────────┬──────────┘
-           │
-           ├────────── Keywords UI/UX detectadas?
-           │                │
-           │               SIM ──────┐
-           │                         ▼
-           │              ┌─────────────────────┐
-           │              │ FASE 1.5: UI/UX     │ ← Condicional
-           │              │ (Wireframes, specs, │
-           │              │  componentes)       │
-           │              └──────────┬──────────┘
-           │                         │
-           │                         ⛔ PAUSA → Aprovação do usuário
-           │                         │
-           NÃO ────────────────────────┘
-           │
-           ▼
-┌─────────────────────┐
-│ FASE 2: DESIGN      │
-│ (Spec, contracts,   │
-│  decisions, custos) │
-└──────────┬──────────┘
-           │
-           ⛔ PAUSA → Aprovação do usuário
-           │
-           ▼
-┌─────────────────────┐
-│ FASE 3: CLARIFY     │
-│ (Perguntas de       │
-│  clarificação)      │
-└──────────┬──────────┘
-           │
-           ▼
-┌─────────────────────┐
-│ FASE 4: TASKS       │
-│ (Breakdown em       │
-│  T001-TXXX)         │
-└──────────┬──────────┘
-           │
-           ⛔ PAUSA → Aprovação do usuário
-           │
-           ▼
-┌─────────────────────┐
-│ FASE 5: IMPLEMENT   │
-│ (Task por task +    │
-│  checkpoints)       │
-└──────────┬──────────┘
-           │
-           ├────────── Complexidade média/alta + ADRs significativos?
-           │                │
-           │               SIM ──────┐
-           │                         ▼
-           │              ┌─────────────────────┐
-           │              │ FASE 6: SYNC        │ ← Condicional
-           │              │ (Promover decisions │
-           │              │  para standards)    │
-           │              └──────────┬──────────┘
-           │                         │
-           │                         ⛔ PAUSA → Aprovação do usuário
-           │                         │
-           NÃO ────────────────────────┘
-           │
-           ▼
-      [FIM] Feature concluída
-
-┌────────────────────────────────────────────────────────────────────────────┐
-│ LEGENDA                                                                    │
-├────────────────────────────────────────────────────────────────────────────┤
-│ ⛔ PAUSA OBRIGATÓRIA - Aguarda interação do usuário                       │
-│ ─── Fluxo principal (sempre executado)                                    │
-│ ├── Decisão condicional                                                   │
-│ [FASE X.Y] Fase intermediária/condicional                                 │
-│ [FASE X] Fase principal obrigatória                                       │
-└────────────────────────────────────────────────────────────────────────────┘
-```
-
-**Fases Obrigatórias:** 0, 1, 2, 3, 4, 5 (6 fases principais)
-**Fases Condicionais:** 0.5 (auto), 1.5 (se UI), 6 (se complexo)
-**Total:** 9 fases possíveis, 6-9 executadas dependendo do contexto
-
----
-
-## PAUSAS INTERATIVAS
-
-### Princípio
-Toda pausa obrigatória DEVE terminar com **exatamente 3 itens** que ajudem o usuário a tomar decisões.
-
-### Tipos de Itens
-
-| Emoji | Tipo | Quando Usar | Exemplo |
-|-------|------|-------------|---------|
-| ✅ | Ação de Aprovação | Quando está pronto para avançar | "Aprovar e continuar para próxima fase" |
-| 🔄 | Ação de Ajuste | Quando há algo para modificar | "Ajustar escopo da feature" |
-| 💰 | Ação de Custo | Quando há recursos Azure | "Revisar custos estimados" |
-| 📋 | Ação de Revisão | Quando há artefatos para validar | "Modificar contracts gerados" |
-| ❓ | Pergunta Aberta | Para clarificar intenções | "Qual a prioridade: performance ou custo?" |
-| 💡 | Sugestão Estratégica | Para propor alternativas | "Considerar serverless em vez de Container App?" |
-| ⚡ | Ação Rápida | Atalho para comum | "Usar padrão CQRS nesta feature?" |
-| 🤔 | Decisão Técnica | Apresentar opções para decisões críticas | "Service Bus vs Storage Queue: qual usar?" (Ver DECISION POINTS) |
-
-### Estratégia por Fase
-
-| Fase | Mix Recomendado | Objetivo |
-|------|----------------|----------|
-| **FASE 0: PROPOSAL** | 1 ação + 1 pergunta + 1 sugestão | Entender intenção e escopo |
-| **FASE 2: DESIGN** | 2 ações + 1 pergunta/sugestão | Validar solução proposta |
-| **FASE 4: TASKS** | 3 ações (padrão fixo) | Confirmar plano de execução |
-
-### Template de Pausa
-
-```markdown
----
-⛔ **PAUSA OBRIGATÓRIA**
-
-{Breve contexto do que foi feito}
-
-**Próximos passos sugeridos:**
-
-1. {Emoji} **{Título da ação/pergunta}**
-   {Descrição breve do que acontece se escolher esta opção}
-
-2. {Emoji} **{Título da ação/pergunta}**
-   {Descrição breve}
-
-3. {Emoji} **{Título da ação/pergunta}**
-   {Descrição breve}
-
----
-```
-
-### Exemplo Real
-
-```markdown
----
-⛔ **PAUSA OBRIGATÓRIA**
-
-Analisamos sua solicitação de "Sistema de pagamentos recorrentes com Asaas".
-Complexidade estimada: **MÉDIA** | Stack: **.NET + Blazor** | Custo: **~$5/mês**
-
-**Próximos passos sugeridos:**
-
-1. ✅ **Aprovar e prosseguir para design detalhado**
-   Gerar spec.md, contracts e estimativa completa de custos
-
-2. ❓ **Esclarecer modelo de negócio**
-   Você pretende cobrar por assinatura mensal, anual ou ambos? Isso afeta o design.
-
-3. 💡 **Considerar MVP incremental**
-   Começar só com pagamentos únicos e adicionar recorrência depois?
-
----
-```
-
----
-
-## DECISION POINTS
-
-### ⚠️ REGRA CRÍTICA: NUNCA DECIDA SOZINHO
-
-Você DEVE pausar e consultar o usuário em tempo real quando encontrar decisões técnicas significativas.
-
-**Decisões que SEMPRE requerem aprovação do usuário:**
-
-#### 1. **Infraestrutura Azure**
-- Escolha de recursos (Service Bus vs Storage Queue vs Redis vs Event Grid)
-- SKUs e tiers (Basic vs Standard vs Premium)
-- Regiões e replicação
-- Recursos pagos vs free tier
-
-**Exemplo de decisão automática (ERRADO):**
-```
-❌ "Vou usar Azure Service Bus Standard tier para mensageria."
-```
-
-**Exemplo correto:**
-```
-✅ "Para mensageria assíncrona, temos 3 opções:
-   1. Service Bus Standard ($10/mês): Suporta tópicos, sessões, até 1GB
-   2. Storage Queue ($0.05/mês): Apenas filas simples, até 500TB
-   3. Event Grid ($0.30/mi eventos): Pub/sub nativo, serverless
-
-   Recomendo Storage Queue se você precisa apenas de filas simples e baratas.
-   Qual prefere?"
-```
-
-#### 2. **Bibliotecas e Frameworks**
-- NuGet packages (.NET libraries)
-- UI libraries (Fluent UI vs MudBlazor vs Radzen)
-- ORMs além do padrão
-- Auth providers (Clerk vs Azure AD vs Auth0)
-- SDKs de terceiros
-
-**Exemplo de decisão automática (ERRADO):**
-```
-❌ "Vou usar MudBlazor para os componentes UI."
-```
-
-**Exemplo correto:**
-```
-✅ "Para componentes UI no Blazor, temos 2 opções principais:
-   1. Fluent UI Blazor: Design Microsoft 365, componentes AI-ready, mais moderno
-   2. MudBlazor: Material Design, mais componentes prontos, comunidade maior
-
-   Recomendo Fluent UI se você quer visual moderno e integração com IA.
-   Qual prefere?"
-```
-
-#### 3. **Padrões Arquiteturais**
-- CQRS vs operações simples
-- Repository Pattern vs EF direto no Service
-- Mediator (MediatR) vs chamadas diretas
-- Event Sourcing vs CRUD tradicional
-- DDD patterns complexos
-
-**Exemplo de decisão automática (ERRADO):**
-```
-❌ "Vou implementar CQRS para separar leitura e escrita."
-```
-
-**Exemplo correto:**
-```
-✅ "Para essa feature de relatórios, podemos usar:
-   1. CQRS: Separar comandos e queries, melhor performance em leitura
-      Complexidade: Média-Alta | Benefício: Escalabilidade
-   2. Repositórios simples: Um repositório por entidade
-      Complexidade: Baixa | Benefício: Mais rápido de implementar
-
-   Recomendo CQRS se você planeja escalar leituras independentemente.
-   Qual abordagem prefere?"
-```
-
-#### 4. **Estrutura de Dados**
-- Design de entidades e relacionamentos
-- Normalização vs denormalização
-- Schemas de API (DTOs, contratos)
-- Índices e otimizações de banco
-
-**Exemplo de decisão automática (ERRADO):**
-```
-❌ "Vou criar uma entidade User com relacionamento N:N com Roles."
-```
-
-**Exemplo correto:**
-```
-✅ "Para relacionamento User-Roles, temos 2 opções:
-   1. N:N com tabela intermediária UserRoles
-      Pros: Flexível, pode adicionar metadados (data de atribuição)
-      Cons: Mais complexo, mais JOINs
-   2. JSON array em User.Roles
-      Pros: Mais simples, menos JOINs
-      Cons: Menos flexível, dificulta queries por role
-
-   Recomendo N:N se você precisa saber quando role foi atribuída.
-   Qual estrutura prefere?"
-```
-
----
-
-### Template de Decisão
-
-Quando encontrar uma decisão técnica, SEMPRE use este formato:
-
-```markdown
----
-🤔 **DECISÃO TÉCNICA NECESSÁRIA**
-
-**Contexto:** {Por que precisamos decidir isso agora}
-
-**Opções disponíveis:**
-
-**Opção 1: {Nome}**
-- ✅ Vantagens: {lista concisa}
-- ❌ Desvantagens: {lista concisa}
-- 💰 Custo: {se Azure} ou N/A
-- ⚡ Complexidade: {baixa/média/alta}
-
-**Opção 2: {Nome}**
-- ✅ Vantagens: {lista concisa}
-- ❌ Desvantagens: {lista concisa}
-- 💰 Custo: {se Azure} ou N/A
-- ⚡ Complexidade: {baixa/média/alta}
-
-**Opção 3: {Nome}** (se houver)
-- ...
-
-**💡 Minha recomendação:**
-{Opção X} porque {justificativa técnica baseada no contexto do projeto}
-
-**Trade-offs principais:**
-- {Trade-off 1: ex: performance vs custo}
-- {Trade-off 2: ex: simplicidade vs escalabilidade}
-
-**Qual opção você prefere?** Ou quer ajustar alguma delas?
-
----
-```
-
----
-
-### Quando NÃO pausar (decisões triviais)
-
-Decisões automáticas permitidas (não precisa consultar):
-- ✅ Nomenclatura de variáveis/métodos (seguir standards)
-- ✅ Estrutura de pastas (seguir Clean Architecture padrão do projeto)
-- ✅ Imports e usings
-- ✅ Formatação de código
-- ✅ Tipos primitivos (string vs int, etc.)
-- ✅ Validações básicas (Required, MaxLength, etc.)
-- ✅ Padrões já definidos em project/standards/
-
-**Regra de ouro:** Se a decisão afeta **custo**, **arquitetura**, **dependências externas** ou **estrutura de dados**, SEMPRE consultar.
-
----
-
-### Exemplo Real Completo
-
-**Situação:** Usuário pediu "adicionar cache para melhorar performance"
-
-**❌ ERRADO (decisão automática):**
-```
-Vou implementar cache usando Redis Premium tier.
-```
-
-**✅ CORRETO (apresentar opções):**
-
-```markdown
----
-🤔 **DECISÃO TÉCNICA NECESSÁRIA**
-
-**Contexto:** Você pediu cache para melhorar performance das queries de produtos. Precisamos decidir qual estratégia usar.
-
-**Opções disponíveis:**
-
-**Opção 1: In-Memory Cache (IMemoryCache .NET)**
-- ✅ Vantagens: Zero custo, simples, rápido para dados pequenos
-- ❌ Desvantagens: Limitado à memória do servidor, perdido em restart, não compartilhado entre instâncias
-- 💰 Custo: $0
-- ⚡ Complexidade: Baixa
-
-**Opção 2: Redis (Azure Cache for Redis - Basic tier)**
-- ✅ Vantagens: Persistente, compartilhado, suporta estruturas complexas
-- ❌ Desvantagens: Custo adicional, latência de rede
-- 💰 Custo: ~$16/mês (Basic C0)
-- ⚡ Complexidade: Média
-
-**Opção 3: Distributed Memory Cache (SQL Server)**
-- ✅ Vantagens: Usa SQL existente, sem custo adicional, compartilhado
-- ❌ Desvantagens: Mais lento que Redis, usa DB para cache
-- 💰 Custo: $0 (usa SQL existente)
-- ⚡ Complexidade: Baixa-Média
-
-**💡 Minha recomendação:**
-Opção 1 (IMemoryCache) se você tem apenas 1 instância do app e dados de cache < 100MB.
-Opção 3 (SQL Distributed Cache) se você tem múltiplas instâncias mas quer evitar custo de Redis.
-
-**Trade-offs principais:**
-- Performance vs Custo: Redis é mais rápido mas custa $16/mês
-- Simplicidade vs Escalabilidade: IMemoryCache é simples mas não escala para múltiplas instâncias
-
-**Qual opção você prefere?** Ou quer ajustar alguma delas?
----
-```
-
----
-
-### Integração com Fases
-
-**FASE 1.5 (UI/UX):**
-- ❓ Perguntar: Fluent UI vs MudBlazor vs outra biblioteca
-- ❓ Perguntar: Preferências de layout, cores, componentes
-
-**FASE 2 (DESIGN):**
-- ❓ Perguntar: Padrões arquiteturais (CQRS, Repository, etc.)
-- ❓ Perguntar: Infraestrutura Azure (recursos, SKUs)
-- ❓ Perguntar: Bibliotecas e SDKs necessários
-- ❓ Perguntar: Estrutura de dados (entidades, relacionamentos)
-
-**Durante IMPLEMENTAÇÃO:**
-- ❓ Pausar: Se encontrar decisão não prevista no design
-- ❓ Pausar: Se precisar adicionar dependência nova
-- ❓ Pausar: Se precisar mudar estrutura de dados aprovada
-
----
-
-### Validação Automática (CLI)
-
-Use o comando `morph-spec validate-decisions` para verificar se decisões foram documentadas:
-
-```bash
-# Validar decisions.md de uma feature
-morph-spec validate-decisions {feature-name}
-
-# O comando verifica:
-# - Decisões de infraestrutura têm ADRs?
-# - Bibliotecas escolhidas estão documentadas?
-# - Padrões arquiteturais estão justificados?
-```
-
----
-
-## AGENTES
-
-### Core Agents (Sempre Ativos)
-
-| Agente | Responsabilidades |
-|--------|-------------------|
-| **Standards Architect** | Padrões em `framework/standards/` e `project/standards/`, nomenclatura, revisão |
-| **Azure Architect** | Infra Azure, Bicep IaC, App Service, Container Apps, SQL |
-| **Cost Guardian** | Validar custos, alertar recursos caros, bloquear não aprovados |
-
-### Stack Agents (Por Stack)
-
-| Agente | Stack | Keywords |
-|--------|-------|----------|
-| **Blazor Builder** | .NET + Blazor | blazor, razor, server-side |
-| **NextJS Expert** | .NET + Next.js | nextjs, react, api, frontend |
-| **Shopify Expert** | Shopify | shopify, hydrogen, liquid |
-
-### Specialist Agents (Sob Demanda)
-
-| Agente | Keywords de Ativação |
-|--------|---------------------|
-| **EF Modeler** | entity, database, migration, ef core |
-| **Agent Framework Expert** | agent, ai, llm, rag, embedding (.NET 10) |
-| **Hangfire Orchestrator** | scheduled, job, background, cron |
-| **UI/UX Designer** | **PT-BR:** tela, interface, formulário, visualização, mostrar, exibir, cadastro<br>**EN:** screen, view, display, form, show, render, create<br>**Components:** wizard, dashboard, chart, dialog, modal, card, list, grid<br>**Stack:** blazor, ui, ux, page, component, frontend<br>(FASE 1.5 obrigatória) |
-| **PO/PM Advisor** | unclear, requirements, priority, ROI |
-
-### Integration Agents (Sob Demanda)
-
-| Agente | Keywords | Docs |
-|--------|----------|------|
-| **Asaas Financial** | asaas, payment, pix, boleto | [API](https://docs.asaas.com/) |
-| **Clerk Auth** | clerk, auth, login, signup | [SDK](https://clerk.com/) |
-| **Azure Identity** | identity, entra, microsoft auth | [Docs](https://learn.microsoft.com/entra/) |
-
-### Infra Agents (Sob Demanda)
-
-| Agente | Keywords | Docs |
-|--------|----------|------|
-| **Bicep Architect** | bicep, iac, infra, provision | [Bicep](https://learn.microsoft.com/azure/azure-resource-manager/bicep/) |
-| **DevOps Engineer** | pipeline, ci/cd, deploy, release | [Pipelines](https://learn.microsoft.com/azure/devops/pipelines/) |
-| **Container Specialist** | docker, container, containerize | [Container Apps](https://learn.microsoft.com/azure/container-apps/) |
-
----
-
-## LIMITES DE CUSTO
-
-### Limites Configuráveis
-
-Os limites de custo são definidos em `.morph/config/config.json` e podem ser customizados por projeto:
-
-```json
-{
-  "costs": {
-    "monthlyBudget": 15,
-    "currency": "USD",
-    "limits": {
-      "freeTierOnly": 0,
-      "withApproval": 10,
-      "requiresADR": 10
-    },
-    "enforcement": {
-      "blockCommitsAboveLimit": true,
-      "requireADRInDecisionsMd": true,
-      "alertOnApproach": 0.8
-    }
-  }
-}
-```
-
-| Limite | Padrão | Descrição | Requisito |
-|--------|--------|-----------|-----------|
-| `freeTierOnly` | $0 | Apenas recursos free tier | Nenhum |
-| `withApproval` | $10 | Requer confirmação do usuário | Aprovação explícita |
-| `requiresADR` | $10 | Requer ADR documentado | ADR em decisions.md |
-
-### Cost Calculator CLI
-
-**Validação automática de custos:**
-
-```bash
-# Calcular custos de arquivos Bicep
-morph-spec cost infra/main.bicep --verbose
-
-# Múltiplos arquivos (glob pattern)
-morph-spec cost "infra/**/*.bicep" --json
-
-# Usar config customizado
-morph-spec cost infra/main.bicep --config .morph/config/config.json
-
-# OU, se em desenvolvimento local do framework:
-# node bin/calculate-costs.js infra/main.bicep --verbose
-```
-
-**Funcionalidades:**
-- ✅ Parseia arquivos Bicep e extrai recursos + SKUs
-- ✅ Calcula custo mensal baseado em pricing table do Azure
-- ✅ Valida contra limites configurados
-- ✅ Exit code 1 se exceder limite `requiresADR`
-- ✅ Output JSON ou verbose (ASCII table)
-
-**Pricing table inclui:**
-- Azure SQL Database (Free, Basic, S0-S4, P1-P2, GP, BC)
-- Container Apps (Consumption, Dedicated)
-- Storage Account (LRS, GRS, Premium)
-- Application Insights (Free, Basic)
-- Key Vault (Standard, Premium)
-- Cosmos DB (Serverless, Provisioned)
-- App Service (F1, D1, B1-B2, S1, P1v2)
-- Service Bus (Basic, Standard, Premium)
-- Redis Cache (C0-C2, P1)
-- Azure Functions (Consumption, Premium)
-
-### Pre-commit Hook
-
-**Bloqueio automático de commits caros:**
-
-```bash
-# Instalar hook
-cp .morph/hooks/pre-commit-costs.sh .git/hooks/pre-commit
-chmod +x .git/hooks/pre-commit
-
-# Ou symlink
-ln -s ../../.morph/hooks/pre-commit-costs.sh .git/hooks/pre-commit
-```
-
-**Comportamento:**
-1. Detecta arquivos Bicep modificados no staged area
-2. Roda cost calculator automaticamente
-3. Se custo > `requiresADR`: procura ADR em decisions.md
-4. **Bloqueia commit** se ADR não encontrado
-5. Mensagem clara de erro com instruções
-
-### Quando Usar
-
-| Fase | Ação | CLI |
-|------|------|-----|
-| **FASE 2 (Design)** | Estimar custos de infra proposta | `/morph-design` (integrado) |
-| **Antes de commit** | Validar custos automaticamente | Pre-commit hook |
-| **Revisão manual** | Verificar custos de Bicep | `morph-spec cost <bicep-files> --verbose` |
-
-### Exemplo de ADR de Custo
-
-Se custo > `requiresADR`, documente em `decisions.md`:
-
-```markdown
-## ADR-003: Infrastructure Costs
-
-**Estimated Monthly Cost:** $12.50
-
-**Breakdown:**
-- Azure SQL S0: $14.72/mo
-- Container App (scale-to-zero): $0.00/mo
-- Storage LRS: $0.02/mo
-
-**Justification:**
-S0 tier necessary for 50k+ rows with indexed queries.
-Basic tier ($ 4.99) insufficient for expected load.
-
-**Alternatives Considered:**
-- Basic tier: Too slow for projected 1M queries/month
-- Cosmos DB: More expensive ($23.36 minimum)
-
-**Approval:** [User/Team] on 2024-01-15
-```
-
----
-
-## INFRASTRUCTURE AS CODE
-
-### Princípio: Zero Portal
-
-> NUNCA criar recursos Azure manualmente. Tudo via Bicep.
-
-### Estrutura IaC
-
-```
-infra/
-├── main.bicep                # Entry point
-├── parameters.dev.json       # Params dev
-├── parameters.prod.json      # Params prod
-└── modules/
-    ├── app-service.bicep
-    ├── container-app.bicep
-    ├── sql-database.bicep
-    ├── storage.bicep
-    ├── key-vault.bicep
-    └── app-insights.bicep
-```
-
-### Quando usar SDK .NET vs Bicep
-
-| Recurso | Abordagem |
-|---------|-----------|
-| Infra estática (SQL, Storage, Container Apps) | Bicep |
-| Recursos dinâmicos (Fabric, Azure AI) | SDK .NET |
-| CI/CD | YAML + Bicep |
-
----
-
-## ESTRUTURA DE OUTPUTS
-
-```
-.morph/project/outputs/{feature-name}/
-├── proposal.md          # Análise inicial e proposta (FASE 0)
-├── ui-design-system.md  # Design system: cores, tipografia, spacing (FASE 1.5 - se front-end)
-├── ui-mockups.md        # Wireframes ASCII + descrições (FASE 1.5 - se front-end)
-├── ui-components.md     # Specs componentes Fluent UI/MudBlazor (FASE 1.5 - se front-end)
-├── ui-flows.md          # Fluxos de usuário + diagramas (FASE 1.5 - se front-end)
-├── spec.md              # Especificação técnica completa (FASE 2)
-├── contracts.cs         # Interfaces, DTOs, Enums (FASE 2)
-├── tasks.json           # Lista de tasks (FASE 4)
-├── decisions.md         # ADRs (FASE 2+, atualizado na FASE 1.5 com UI lib)
-└── recap.md             # Resumo pós-implementação (FASE 5)
-```
-
-**Nota:** Arquivos `ui-*.md` são gerados apenas se a feature envolver front-end (keywords detectadas).
-
-**Arquivos de Tema** (gerados na FASE 5 baseados em ui-design-system.md):
-- `wwwroot/css/design-system.css` - CSS Variables
-- `Themes/FluentDesignTheme.cs` - Se Fluent UI
-- `Themes/MudTheme.cs` - Se MudBlazor
-
----
-
-## STATE MANAGEMENT
-
-O MORPH-SPEC rastreia automaticamente o progresso de features usando `.morph/state.json`.
-
-### Arquivo de State
-
-```json
-{
-  "version": "2.1.1",
-  "project": {
-    "name": "ProjectName",
-    "type": "blazor-server",
-    "createdAt": "2024-01-15T10:00:00Z",
-    "updatedAt": "2024-01-15T14:30:00Z"
-  },
-  "features": {
-    "feature-name": {
-      "status": "in_progress",
-      "phase": "implement",
-      "activeAgents": ["blazor-builder", "ef-modeler"],
-      "outputs": {
-        "proposal": { "created": true, "path": ".morph/project/outputs/..." },
-        "spec": { "created": true, "path": ".morph/project/outputs/..." },
-        "tasks": { "created": true, "path": ".morph/project/outputs/..." }
-      },
-      "tasks": {
-        "total": 12,
-        "completed": 5,
-        "inProgress": 1,
-        "pending": 6
-      },
-      "checkpoints": [
-        {
-          "timestamp": "2024-01-15T12:00:00Z",
-          "phase": "implement",
-          "completedTasks": 3,
-          "note": "Checkpoint após T001-T003"
-        }
-      ],
-      "costs": {
-        "estimated": 2.50,
-        "approved": true
-      }
-    }
-  },
-  "metadata": {
-    "totalFeatures": 1,
-    "completedFeatures": 0,
-    "totalCostEstimated": 2.50
-  }
-}
-```
-
-### CLI para State Management
-
-Use o comando `morph-spec state` para manipular o state:
-
-```bash
-# Inicializar state (primeira vez)
-morph-spec state init
-
-# Criar/atualizar feature
-morph-spec state set feature-name phase design
-morph-spec state set feature-name status in_progress
-
-# Atualizar tasks
-morph-spec state set feature-name tasks.completed 5
-morph-spec state set feature-name tasks.total 12
-
-# Adicionar agentes
-morph-spec state add-agent feature-name blazor-builder
-
-# Marcar outputs como criados
-morph-spec state mark-output feature-name spec
-morph-spec state mark-output feature-name contracts
-
-# Registrar checkpoint
-morph-spec state checkpoint feature-name "Completadas tasks T001-T003"
-
-# Listar todas as features
-morph-spec state list
-
-# Obter detalhes de uma feature (JSON)
-morph-spec state get feature-name
-
-# OU, se em desenvolvimento local do framework:
-# node bin/state-manager.js <command>
-```
-
-### Quando Atualizar State
-
-**SEMPRE** atualize o state nos seguintes momentos:
-
-| Momento | Comando |
-|---------|---------|
-| **Criar proposal** (FASE 0) | `set {feature} phase proposal`<br>`mark-output {feature} proposal` |
-| **Iniciar design** (FASE 2) | `set {feature} phase design`<br>`add-agent {feature} {agent-id}` |
-| **Aprovar design** | `set {feature} status approved`<br>`mark-output {feature} spec`<br>`mark-output {feature} contracts` |
-| **Iniciar implementação** (FASE 5) | `set {feature} phase implement`<br>`set {feature} status in_progress`<br>`set {feature} tasks.total {N}` |
-| **Completar task** | `set {feature} tasks.completed {X}` |
-| **Checkpoint (a cada 3 tasks)** | `checkpoint {feature} "nota"` |
-| **Finalizar feature** | `set {feature} status done`<br>`mark-output {feature} recap` |
-
-### Benefícios
-
-- ✅ **Persistência**: Estado mantido entre sessões
-- ✅ **Rastreamento**: Saber exatamente em qual fase cada feature está
-- ✅ **Progresso**: Visualizar tasks completadas vs total
-- ✅ **Histórico**: Checkpoints registrados com timestamps
-- ✅ **Custos**: Rastreamento de custos estimados e aprovações
-- ✅ **Dashboard**: Comando `list` gera visualização ASCII automática
-
----
-
-## COMANDOS
-
-### Comandos CLI (via npm package)
-
-| Comando | Descrição | Quando Usar |
-|---------|-----------|-------------|
-| `morph-spec init` | Inicializar MORPH no projeto | Primeira vez em um projeto |
-| `morph-spec detect` | Detectar stack/patterns | Projeto existente, entender estrutura |
-| `morph-spec sync` | Sincronizar standards | Após implementar features |
-| `morph-spec update` | Atualizar framework | Nova versão do MORPH disponível |
-| `morph-spec doctor` | Check de saúde | Diagnosticar problemas |
-| `morph-spec state <action>` | Gerenciar state.json | Rastrear features, progresso, agentes |
-| `morph-spec cost <bicep-files>` | Calcular custos Azure | Validar custos de infraestrutura |
-| `morph-spec generate design-system` | Gerar CSS + temas | Após aprovar UI/UX design |
-
-### Story-Driven Development Commands
-
-| Comando | Descrição | Quando Usar |
-|---------|-----------|-------------|
-| `morph-spec story create <feature> <story-id>` | Criar story com Dev Notes auto-injetadas | Início da implementação |
-| `morph-spec story shard <feature>` | Dividir spec.md em shards (90% token savings) | Feature com spec grande (5+ seções) |
-| `morph-spec story status <feature> show` | Ver progresso do sprint | Qualquer momento |
-| `morph-spec story status <feature> start <id>` | Marcar story como in_progress | Antes de implementar |
-| `morph-spec story status <feature> qa <id>` | Marcar story como ready_for_qa | Após implementar |
-| `morph-spec story status <feature> done <id>` | Marcar story como done | Após QA aprovar |
-| `morph-spec story status <feature> next` | Mostrar próxima story | Planejar próximo trabalho |
-
-**Options:**
-- `--title <title>` - Título da story
-- `--tasks <tasks>` - Lista de tasks separadas por vírgula
-- `--dry-run` - Preview sem escrever arquivos
-- `--verbose` - Mostrar informações detalhadas
-
-**Exemplo completo:**
-```bash
-# 1. Shardar spec (opcional)
-morph-spec story shard scheduled-reports
-
-# 2. Criar stories
-morph-spec story create scheduled-reports SR-001 \
-  --title "Create entity" \
-  --tasks "Create entity,EF mapping,Migration,Tests"
-
-# 3. Implementar
-morph-spec story status scheduled-reports start SR-001
-# [Claude implementa código]
-morph-spec story status scheduled-reports qa SR-001
-
-# 4. QA
-# [Claude revisa código]
-morph-spec story status scheduled-reports done SR-001
-
-# 5. Ver progresso
-morph-spec story status scheduled-reports show
-```
-
-**Ver também:** `content/.morph/docs/STORY-DRIVEN-DEVELOPMENT.md` para guia completo.
-
-### State Management Command
-
-**Gerencia state.json para rastreamento de features:**
-
-```bash
-# Inicializar state.json
-morph-spec state init [--force] [--project <name>] [--type <type>]
-
-# Ver feature
-morph-spec state get <feature> [--json]
-
-# Atualizar propriedade (suporta dot notation)
-morph-spec state set <feature> <key> <value>
-
-# Registrar checkpoint
-morph-spec state checkpoint <feature> "<note>"
-
-# Listar todas as features
-morph-spec state list
-
-# Gerenciar agentes
-morph-spec state add-agent <feature> <agent-id>
-morph-spec state remove-agent <feature> <agent-id>
-
-# Marcar outputs como criados
-morph-spec state mark-output <feature> <output-type>
-```
-
-**Uso automático interno:**
-- `morph-spec story create/status` atualiza state automaticamente
-- Slash commands `/morph-*` registram fases e checkpoints
-- Todos os comandos que geram outputs marcam no state
-
-**Exemplo completo:**
-```bash
-# Setup inicial
-morph-spec state init --project "MyApp" --type "blazor-server"
-
-# Durante feature
-morph-spec state set scheduled-reports phase design
-morph-spec state add-agent scheduled-reports blazor-builder
-morph-spec state mark-output scheduled-reports spec
-
-# Checkpoints (automáticos ou manuais)
-morph-spec state checkpoint scheduled-reports "Completed T001-T003"
-
-# Ver progresso
-morph-spec state list
-```
-
-### Cost Calculator Command
-
-**Calcula custos de infraestrutura Azure de arquivos Bicep:**
-
-```bash
-# Calcular custos
-morph-spec cost <bicep-files> [--verbose] [--json] [--strict]
-
-# Exemplos
-morph-spec cost infra/main.bicep --verbose
-morph-spec cost "infra/**/*.bicep" --json
-morph-spec cost infra/main.bicep --strict  # Exit code 1 se > ADR threshold
-```
-
-**Uso automático interno:**
-- `/morph-design` calcula custos automaticamente se detectar Bicep
-- Pre-commit hook valida custos antes de commitar
-- `morph-spec story create` alerta se tasks incluem "bicep"
-
-**Pricing table inclui:**
-- Azure SQL Database (Free, Basic, S0-S4, P1-P2, GP, BC)
-- Container Apps (Consumption, Dedicated)
-- Storage Account, Application Insights, Key Vault
-- Cosmos DB, App Service, Service Bus, Redis, Functions
-
-**Validação automática:**
-- Alerta se custo > `freeTierOnly` (requer aprovação)
-- Bloqueia se custo > `requiresADR` (requer ADR em decisions.md)
-- Pre-commit hook impede commits sem ADR
-
-### Generate Design System Command
-
-**Gera CSS + temas C# a partir de ui-design-system.md:**
-
-```bash
-# Gerar design system
-morph-spec generate design-system <ui-design-system.md> [options]
-
-# Opções
---fluent              # Apenas Fluent UI theme
---mud                 # Apenas MudBlazor theme
---both                # Ambos os temas (padrão)
---namespace <ns>      # Namespace C# (padrão: YourProject.Themes)
---dry-run             # Preview sem escrever arquivos
-
-# Exemplos
-morph-spec generate design-system .morph/project/outputs/my-feature/ui-design-system.md --fluent
-morph-spec generate design-system .morph/project/outputs/my-feature/ui-design-system.md --both
-```
-
-**Arquivos gerados:**
-- `wwwroot/css/design-system.css` - CSS variables
-- `Themes/FluentDesignTheme.cs` - Tema Fluent UI (se --fluent ou --both)
-- `Themes/MudDesignTheme.cs` - Tema MudBlazor (se --mud ou --both)
-
-**Uso automático interno:**
-- `/morph-uiux` gera temas automaticamente após aprovar design
-- FASE 5: IMPLEMENT regenera se ui-design-system.md for modificado
-
-**Parsing automático de:**
-- Primary/Secondary/Neutral colors (#hex)
-- Semantic colors (Success, Error, Warning, Info)
-- Font families, sizes, weights
-- Spacing values (margin, padding, gap)
-
----
-
-### Slash Commands (Claude Code)
-
-Comandos disponíveis para cada fase do workflow:
-
-| Comando | Fase | Descrição |
-|---------|------|-----------|
-| `/morph-proposal {feature}` | FASE 0 | Criar proposta inicial, detectar agentes |
-| `/morph-setup {feature}` | FASE 1 | Carregar contexto, confirmar stack e padrões |
-| `/morph-uiux {feature}` | FASE 1.5 | Coletar UI/UX, gerar wireframes e specs de componentes (condicional) |
-| `/morph-design {feature}` | FASE 2 | Gerar spec.md, contracts.cs, decisions.md, estimar custos |
-| `/morph-clarify {feature}` | FASE 3 | Identificar ambiguidades, fazer perguntas de clarificação |
-| `/morph-tasks {feature}` | FASE 4 | Quebrar spec em tasks executáveis, definir checkpoints |
-| `/morph-apply {feature}` | FASE 5 | Implementar tasks sequencialmente com validação de fases |
-| `/morph-status` | Qualquer | Mostrar dashboard de progresso com state.json |
-| `/morph-archive {feature}` | Pós-impl | Arquivar feature concluída |
-
-**Uso típico:**
-
-```bash
-# 1. Criar proposta
-/morph-proposal scheduled-reports
-
-# 2. Setup (após aprovação)
-/morph-setup scheduled-reports
-
-# 3. UI/UX (se necessário)
-/morph-uiux scheduled-reports
-
-# 4. Design técnico
-/morph-design scheduled-reports
-
-# 5. Clarificações
-/morph-clarify scheduled-reports
-
-# 6. Breakdown de tasks
-/morph-tasks scheduled-reports
-
-# 7. Implementação
-/morph-apply scheduled-reports
-
-# 8. Ver status a qualquer momento
-/morph-status
-
-# 9. Arquivar quando completo
-/morph-archive scheduled-reports
-```
-
-**Validação de fases:**
-- `/morph-apply` valida que TODAS as fases anteriores foram concluídas
-- Impossível pular fases (segurança do workflow)
-- State.json rastreia progresso automaticamente
-
----
-
-## REFERÊNCIAS
-
-### Framework Standards (Read-only, do MORPH)
-- `framework/standards/coding.md` - Padrões de código
-- `framework/standards/architecture.md` - Padrões de arquitetura
-- `framework/standards/azure.md` - Padrões Azure e IaC
-- `framework/standards/agent-framework-setup.md` - Setup Agent Framework (.NET 10)
-- `framework/standards/passkeys-auth.md` - Autenticação com Passkeys/WebAuthn
-- `framework/standards/vector-search-rag.md` - Vector Search + RAG com EF Core 10
-- `framework/standards/dotnet10-migration.md` - Guia de migração .NET 9 → 10
-- `framework/standards/fluent-ui-setup.md` - UI Library recomendada (Fluent UI Blazor)
-- `framework/standards/migration-guide.md` - Guia de migração App Service → Container Apps
-
-### Framework Templates
-- `framework/templates/` - Templates para outputs de features
-- `framework/templates/infra/` - Templates Bicep e scripts de deploy
-
-### Project Context (Editável, do projeto)
-- `.morph/project/context/README.md` - Overview do projeto
-- `.morph/project/standards/inferred.md` - Standards detectados automaticamente
-- `.morph/project/standards/*.md` - Overrides e extensões dos standards
-- `.morph/project/outputs/` - Features em desenvolvimento
-- `.morph/config.json` - Config do projeto + link para framework
-
-### Azure DevOps (se aplicável)
-- `.azure/README.md` - Overview completo de CI/CD
-- `.azure/pipelines/` - Pipelines (staging, prod)
-- `.azure/docs/azure-devops-setup.md` - Setup Workload Identity Federation
-
----
-
-*MORPH-SPEC by Polymorphism Tech*
+# MORPH-SPEC - Instruções para Claude Code
+
+**M**ethodical **O**rchestration for **R**eliable **P**roduction-ready **SPEC**-driven development
+
+> by Polymorphism Tech
+
+Sistema de desenvolvimento orientado por especificações. Hub de agentes especializados em multi-stack (.NET/Blazor, .NET/Next.js) com Infrastructure as Code.
+
+---
+
+## REGRAS CRÍTICAS
+
+### NUNCA:
+- Pular direto para código sem especificação
+- Implementar sem aprovação do design
+- Ignorar os padrões (framework/standards/ ou project/standards/)
+- Criar recursos Azure manualmente no portal (use Bicep)
+- Gerar código sem contracts definidos
+- **Tomar decisões técnicas sozinho (infraestrutura, bibliotecas, patterns, schemas)**
+
+### SEMPRE:
+- Seguir workflow adequado à complexidade (ver WORKFLOWS)
+- Gerar outputs em `.morph/project/outputs/{feature}/`
+- Documentar decisões em `decisions.md`
+- Checkpoint a cada 3 tasks implementadas
+- Usar Infrastructure as Code (Bicep)
+- Usar exclusivamente Microsoft Agent Framework (.NET 10)
+- Coletar input do usuário na FASE 1.5 (layout, referências, imagens)
+- **Consultar usuário em DECISION POINTS**
+
+---
+
+## AGENTES E SKILLS
+
+**Agent** = Metadata em `.morph/config/agents.json` (quem sou, quando ativo)
+**Skill** = Implementação em `.claude/skills/{cat}/{id}.md` (como faço, prompts, workflows)
+
+**Workflow:** Keywords no input → `npx morph-spec detect-agents "{input}"` → retorna agent-ids → Claude ativa agentes → invoca Skills dos detectados
+
+```bash
+npx morph-spec detect-agents "implementar jobs agendados"    # Detectar agentes por keywords
+npx morph-spec detect-agents --verbose "criar dashboard"      # Ver matches detalhados
+npx morph-spec detect                                         # Detectar stack/arquitetura do projeto
+npx morph-spec validate-agents-skills                         # Validar consistência
+```
+
+Após detectar, registrar: `morph-spec state add-agent {feature} {agent-id}`
+
+### Agentes Disponíveis
+
+| Tipo | Agente | Keywords |
+|------|--------|----------|
+| **Core** | Standards Architect | *(sempre ativo)* |
+| **Core** | Azure Architect | *(sempre ativo)* |
+| **Core** | .NET Senior Engineer | *(sempre ativo)* — ultrathink mode |
+| **Stack** | Blazor Builder | blazor, razor, server-side |
+| **Stack** | NextJS Expert | nextjs, react, api, frontend |
+| **Specialist** | EF Modeler | entity, database, migration, ef core |
+| **Specialist** | Code Analyzer | analyze, review, refactor, clean code, smell, duplicate |
+| **Specialist** | Agent Framework Expert | agent, ai, llm, rag, embedding, workflow, orchestration, mcp, a2a, middleware |
+| **Specialist** | Hangfire Orchestrator | scheduled, job, background, cron |
+| **Specialist** | UI/UX Designer | tela, interface, dashboard, form, chart, wizard, blazor, ui, ux, page, component |
+| **Specialist** | PO/PM Advisor | unclear, requirements, priority, ROI |
+| **Integration** | Asaas Financial | asaas, payment, pix, boleto |
+| **Integration** | Clerk Auth | clerk, auth, login, signup |
+| **Integration** | Azure Identity | identity, entra, microsoft auth |
+| **Integration** | Resend Email | resend, email, transactional, notification |
+| **Infra** | Bicep Architect | bicep, iac, infra, provision |
+| **Infra** | DevOps Engineer | pipeline, ci/cd, deploy, release |
+| **Infra** | Container Specialist | docker, container, containerize |
+
+---
+
+## WORKFLOWS POR COMPLEXIDADE
+
+O MORPH-SPEC detecta automaticamente a complexidade via `src/lib/complexity-analyzer.js`. Override: `[FAST-TRACK]` ou `[FULL-MORPH]` no pedido.
+
+| Aspecto | Fast Track | Standard | Full MORPH | UI Refresh | Design Impl |
+|---------|-----------|----------|------------|------------|-------------|
+| **Quando** | Bug fixes, ajustes | Features simples | Features complexas | Redesign visual | Prototipo → Codigo |
+| **Arquivos** | ≤ 3 | 3-10 | > 10 | CSS + .razor | .html → .razor |
+| **Fases** | 2 | 4 | 9 (todas) | 3 | 3 |
+| **Pausas** | 1 | 2-3 | 5-6 | 2 | 2 |
+| **Outputs** | Nenhum | proposal, spec, recap | Todos (9+) | checklist, CSS, recap | recap, CSS |
+
+**Detalhes de cada workflow:** Ler `content/.morph/docs/workflows/` para fases completas.
+
+**Keywords de detecção:**
+- **Trivial:** bug, fix, corrigir, ajustar, hotfix, edge case, cor, css
+- **Infra:** azure, bicep, sql, container, deploy, infra
+- **Arquitetura:** sistema, autenticação, integração, pattern, cqrs, subsistema
+- **UI Refresh:** redesign, redesenhar, bonito, visual, estetica, modernizar
+- **Design Impl:** prototipo, prototype, figma, html para, converter design, replicar
+
+---
+
+## AS 9 FASES DO WORKFLOW
+
+| Fase | Gatilho | Ações Principais | Output | Pausa? |
+|------|---------|-------------------|--------|--------|
+| **0.5 CONTEXT** | Início sessão (auto) | Detectar framework, projeto, stack, histórico; gerar standards inferidos | context/, inferred.md | Não |
+| **0 PROPOSAL** | Feature request | `npx morph-spec detect`; analisar; gerar proposal.md; registrar agentes | proposal.md | **Sim** |
+| **1 SETUP** | Proposal aprovado | Ler config.json; confirmar stack; ativar agentes; criar pasta outputs | Confirmação | Não |
+| **1.5 UI/UX** | Setup + keywords UI *(condicional)* | Perguntar layout/refs ao usuário; gerar wireframes e specs AGNÓSTICOS (sem escolher lib UI) | ui-*.md | **Sim** |
+| **2 DESIGN** | Contexto confirmado | Gerar spec.md + contracts.cs; DECISION POINTS (lib UI, padrões, dados, infra, SDKs); estimar custos | spec.md, contracts.cs, decisions.md | **Sim** |
+| **3 CLARIFY** | Design aprovado | Identificar ambiguidades; perguntas de clarificação; validar edge cases | Spec atualizado | Não |
+| **4 TASKS** | Clarificações resolvidas | Quebrar spec em tasks T001-TXXX; definir ordem, checkpoints, dependências | tasks.json | **Sim** |
+| **5 IMPLEMENT** | Tasks aprovadas | Implementar task por task; `npx morph-spec task done {feature} {task-id}` após cada; gerar recap.md | Código + recap.md | Não |
+| **6 SYNC** | Implementação + complexidade média/alta *(condicional)* | Promover decisions.md para project/standards/; gerar commit sync | standards/*.md | **Sim** |
+
+**Fases Obrigatórias:** 0, 1, 2, 3, 4, 5
+**Fases Condicionais:** 0.5 (auto), 1.5 (se UI), 6 (se complexo)
+
+### Regras da FASE 5 (IMPLEMENT)
+
+- **SEMPRE** chamar `npx morph-spec task done {feature} {task-id}` após cada task (validators run automatically)
+- **Se validação falhar:** corrigir violações ANTES de re-executar `task done`. NUNCA usar `--skip-validation` sem autorização do usuário
+- **NUNCA** atualizar state.json ou tasks.json manualmente
+- **NUNCA** pular tasks com dependências não completadas
+- Framework gerencia checkpoints automaticamente (a cada 3 tasks, inclui validation summary)
+- Usar `morph-spec phase advance {feature}` para avançar entre fases (valida → avança → mostra próximos passos)
+- Gerar recap: `morph-spec generate recap {feature}` (auto-popula com dados reais de state + validation + contracts)
+
+---
+
+## PAUSAS INTERATIVAS
+
+Toda pausa obrigatória termina com **exatamente 3 itens** (mix de ações/perguntas/sugestões):
+
+| Fase | Mix Recomendado |
+|------|----------------|
+| PROPOSAL | 1 ação + 1 pergunta + 1 sugestão |
+| DESIGN | 2 ações + 1 pergunta/sugestão |
+| TASKS | 3 ações (aprovar/repriorizar/adicionar) |
+
+**Template:**
+```
+⛔ PAUSA OBRIGATÓRIA
+{Contexto breve}
+1. {Emoji} **{Título}** - {Descrição}
+2. {Emoji} **{Título}** - {Descrição}
+3. {Emoji} **{Título}** - {Descrição}
+```
+
+---
+
+## DECISION POINTS
+
+### Regra: NUNCA decida sozinho sobre arquitetura, dependências externas ou estrutura de dados.
+
+**Requer aprovação do usuário:**
+- Infraestrutura Azure (recursos, SKUs, tiers, custos)
+- Bibliotecas e Frameworks (NuGet, UI libs, auth providers, SDKs)
+- Padrões Arquiteturais (CQRS vs simples, Repository vs EF direto, etc.)
+- Estrutura de Dados (entidades, relacionamentos, normalização)
+
+**Decisões são ENFORCED por validators na FASE 5.** Ao documentar decisão em `decisions.md`, os validators automaticamente ajustam suas regras (ex: "Fluent UI chosen" → blazor-validator valida Fluent patterns; "Hangfire chosen" → blazor-concurrency analyzer ativado).
+
+**Decisões automáticas permitidas:**
+- Nomenclatura (seguir standards), estrutura de pastas, imports, formatação, tipos primitivos, validações básicas, padrões já em project/standards/
+
+**Template de decisão:**
+```
+🤔 DECISÃO TÉCNICA NECESSÁRIA
+Contexto: {por que decidir agora}
+
+Opção 1: {Nome} - ✅ {vantagens} | ❌ {desvantagens} | ⚡ {complexidade}
+Opção 2: {Nome} - ✅ {vantagens} | ❌ {desvantagens} | ⚡ {complexidade}
+
+💡 Recomendação: {opção} porque {justificativa}
+Qual prefere?
+```
+
+---
+
+## QUANDO NÃO USAR MORPH
+
+| Não usar MORPH | Sempre usar MORPH |
+|----------------|-------------------|
+| Bug fix simples (< 3 arquivos) | Nova feature com UI |
+| Hotfix urgente | Integração com API externa |
+| Ajuste CSS/typo | Novo subsistema/módulo |
+| Atualizar dependência | Mudança de schema de banco |
+| Pergunta sobre código | Autenticação/autorização |
+
+> **Regra de Ouro:** ARQUITETURA, DEPENDÊNCIAS EXTERNAS ou ESTRUTURA DE DADOS → Use MORPH. CORREÇÃO, AJUSTE ou OPERAÇÃO → Faça diretamente.
+
+Escalação: Se descobrir complexidade maior, `morph-spec state set {feature} workflow full-morph`
+
+---
+
+## INFRASTRUCTURE AS CODE
+
+> NUNCA criar recursos Azure manualmente. Tudo via Bicep.
+
+| Recurso | Abordagem |
+|---------|-----------|
+| Infra estática (SQL, Storage, Container Apps) | Bicep |
+| Recursos dinâmicos (Fabric, Azure AI) | SDK .NET |
+| CI/CD | YAML + Bicep |
+
+Estrutura: `infra/main.bicep` → `infra/modules/*.bicep` + `parameters.{env}.json`
+
+---
+
+## STATE MANAGEMENT
+
+```bash
+morph-spec state init                                    # Inicializar
+morph-spec state set {feature} phase {phase}             # Atualizar fase
+morph-spec state set {feature} status {status}           # Atualizar status
+morph-spec state add-agent {feature} {agent-id}          # Adicionar agente
+morph-spec state mark-output {feature} {type}            # Marcar output
+morph-spec state checkpoint {feature} "{nota}"           # Registrar checkpoint
+morph-spec state list                                    # Dashboard
+morph-spec state get {feature}                           # Detalhes
+```
+
+**Quando atualizar:** Criar proposal → phase proposal + mark-output proposal. Iniciar design → phase design + add-agent. Aprovar design → status approved + mark-output spec/contracts. Implementar → phase implement + tasks.total. Completar task → tasks.completed. Finalizar → status done + mark-output recap.
+
+---
+
+## COMANDOS
+
+> **npx** para projetos consumidores. **node bin/** apenas para dev do framework.
+
+### User Commands
+
+**Slash Commands (o que o usuário digita):**
+| Comando | Descrição |
+|---------|-----------|
+| `/morph-proposal {feature}` | Spec pipeline completo (fases 0-4 com pausas e auto-continuação) |
+| `/morph-apply {feature}` | Implementar (fase 5, valida fases anteriores) |
+| `/morph-status` | Dashboard de progresso |
+| `/morph-archive {feature}` | Arquivar feature concluída |
+| `/morph-infra {action}` | Gerenciar infra Bicep (init, validate, plan, deploy) |
+| `/morph-preflight` | Validação pre-deploy Azure |
+| `/morph-troubleshoot {error}` | Troubleshooting de erros |
+
+**CLI (o que o usuário executa no terminal):**
+| Comando | Descrição |
+|---------|-----------|
+| `morph-spec init` | Inicializar MORPH no projeto |
+| `morph-spec update` | Atualizar templates e standards |
+| `morph-spec doctor` | Check de saúde |
+
+### Framework Commands (Claude internal)
+
+> Comandos usados pelo Claude automaticamente durante o workflow. Usuário NÃO precisa executar.
+
+| Comando | Quando |
+|---------|--------|
+| `morph-spec detect-agents "{text}"` | Detectar agentes na proposta |
+| `morph-spec state <action>` | Gerenciar state.json |
+| `morph-spec task done/start/next` | Gerenciar tasks na implementação |
+| `morph-spec phase advance {feature}` | Avançar entre fases |
+| `morph-spec generate recap/design-system` | Gerar outputs |
+| `morph-spec validate-phase {feature} {phase}` | Validar pré-requisitos |
+| `morph-spec validate/validate-blazor/lint-fluent/...` | Validators |
+| `morph-spec story create/shard/status` | Story-driven development |
+
+### Internal Workflow Skills (auto-invoked by /morph-proposal)
+
+| Skill | Fase | Path |
+|-------|------|------|
+| phase-setup | 1 | `.claude/skills/workflows/phase-setup.md` |
+| phase-uiux | 1.5 | `.claude/skills/workflows/phase-uiux.md` |
+| phase-design | 2 | `.claude/skills/workflows/phase-design.md` |
+| phase-clarify | 3 | `.claude/skills/workflows/phase-clarify.md` |
+| phase-tasks | 4 | `.claude/skills/workflows/phase-tasks.md` |
+
+---
+
+## ESTRUTURA DE OUTPUTS
+
+```
+.morph/project/outputs/{feature-name}/
+├── proposal.md          # FASE 0
+├── ui-design-system.md  # FASE 1.5 (se front-end)
+├── ui-mockups.md        # FASE 1.5 (se front-end)
+├── ui-components.md     # FASE 1.5 (se front-end)
+├── ui-flows.md          # FASE 1.5 (se front-end)
+├── spec.md              # FASE 2
+├── contracts.cs         # FASE 2
+├── tasks.json           # FASE 4
+├── decisions.md         # FASE 2+ (acumulativo)
+└── recap.md             # FASE 5
+```
+
+---
+
+## REFERÊNCIAS
+
+### Standards (framework/standards/)
+`coding.md` | `architecture.md` | `azure.md` | `agent-framework-setup.md` | `agent-framework-workflows.md` | `agent-framework-production.md` | `agent-framework-blazor-ui.md` | `passkeys-auth.md` | `vector-search-rag.md` | `dotnet10-migration.md` | `fluent-ui-blazor.md` | `migration-guide.md`
+
+### Templates
+- `content/.morph/templates/` - Source (NPM package)
+- `.morph/templates/` - No projeto consumidor (editável, copiado pelo `init`)
+
+### Project Context
+`.morph/project/context/README.md` | `.morph/project/standards/inferred.md` | `.morph/project/standards/*.md` | `.morph/config.json`
+
+### Skills
+- `workflows/` - phase-setup, phase-uiux, phase-design, phase-clarify, phase-tasks, morph-replicate
+- `checklists/` - morph-checklist, simulation-checklist, code-review
+- `integrations/` - asaas-financial, clerk-auth, azure-identity, resend-email
+- `specialists/` - dotnet-senior, code-analyzer, ui-ux-designer, ai-system-architect, ef-modeler, hangfire-orchestrator, testing-specialist, etc.
+- `stacks/` - dotnet-blazor, dotnet-nextjs
+- `infra/` - bicep-architect, devops-engineer, container-specialist
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*