@polymorphism-tech/morph-spec 4.3.7 → 4.6.0

package/framework/skills/level-1-workflows/phase-design.md

@@ -1,213 +0,0 @@
-# MORPH Design - FASE 2
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Expanda a proposta em especificação técnica completa, contracts, decisões arquiteturais e estimativa de custos.
-
-## Pré-requisitos
-
-- [ ] FASE 1 (Setup) concluída
-- [ ] FASE 1.5 (UI/UX) concluída OU pulada (se não houver front-end)
-- [ ] Proposta aprovada pelo usuário
-
-## Workflow
-
-### Passo 1: Carregar Contexto e Standards
-
-**Obtenha feature state e standards context:**
-
-```bash
-npx morph-spec state get {feature-name}
-```
-
-Parse o JSON para obter `activeAgents`, então use standards context (já carregado na FASE 1):
-- Standards relevantes estão em `standardsSummary` do detect-agents
-- Padrões já incluem project overrides + inferred learnings
-
-**Leia outputs existentes:**
-1. `.morph/project/outputs/{feature}/proposal.md` - Proposta inicial
-2. `.morph/project/outputs/{feature}/ui-*.md` - UI/UX specs (se existirem)
-
-**Use standards context ao gerar spec.md:**
-- Architecture standards → guiam Technical Architecture section
-- Coding standards → definem contracts.cs patterns
-- Azure standards → determinam Infrastructure Requirements
-
-### Passo 2: Gerar `spec.md`
-
-Crie `.morph/project/outputs/{feature}/spec.md` com:
-
-#### 2.1. Overview
-- **Objetivo:** Resumo de 1-2 parágrafos
-- **Usuários afetados:** Quem vai usar?
-- **Problema resolvido:** Qual dor/necessidade?
-
-#### 2.2. Functional Requirements
-Lista detalhada de requisitos funcionais:
-```markdown
-### FR001: {Requisito}
-**Description:** {O que deve fazer}
-**Acceptance Criteria:**
-- [ ] Critério 1
-- [ ] Critério 2
-**Priority:** High/Medium/Low
-```
-
-#### 2.3. Non-Functional Requirements
-- Performance (tempos de resposta esperados)
-- Segurança (autenticação, autorização)
-- Escalabilidade (volume de dados/usuários)
-- Disponibilidade (uptime esperado)
-
-#### 2.4. Technical Architecture
-- **Camadas:** (Presentation, Application, Domain, Infrastructure)
-- **Patterns:** (Repository, CQRS, DI, etc.)
-- **Dependências:** Bibliotecas/serviços externos necessários
-
-#### 2.5. Data Model
-- Entities principais
-- Relacionamentos (1:1, 1:N, N:N)
-- Campos obrigatórios vs opcionais
-- Validações de negócio
-
-#### 2.6. Infrastructure Requirements
-Se houver recursos Azure:
-- Banco de dados (Azure SQL, Cosmos DB)
-- Storage (Blob Storage)
-- Compute (Container Apps, App Service)
-- Monitoring (App Insights)
-
-**SEMPRE usar Bicep para infra!**
-
-### Passo 3: Gerar `contracts.cs`
-
-Crie `.morph/project/outputs/{feature}/contracts.cs` com:
-
-```csharp
-// Interfaces, DTOs, Enums, Value Objects
-
-namespace {ProjectName}.Features.{FeatureName};
-
-// DTOs (Data Transfer Objects)
-public record {Feature}CreateDto(
-    string Name,
-    DateTime Date
-);
-
-public record {Feature}ResponseDto(
-    Guid Id,
-    string Name,
-    DateTime Date,
-    DateTime CreatedAt
-);
-
-// Interfaces
-public interface I{Feature}Service
-{
-    Task<{Feature}ResponseDto> CreateAsync({Feature}CreateDto dto, CancellationToken ct);
-    Task<{Feature}ResponseDto?> GetByIdAsync(Guid id, CancellationToken ct);
-}
-
-// Enums
-public enum {Feature}Status
-{
-    Pending,
-    Active,
-    Completed
-}
-```
-
-**Padrões obrigatórios:**
-- Records para DTOs (immutable)
-- Interfaces para serviços
-- CancellationToken em métodos async
-- Nullable reference types habilitados
-
-### Passo 4: Iniciar `decisions.md`
-
-Crie `.morph/project/outputs/{feature}/decisions.md` com ADRs relevantes:
-
-```markdown
-# Architectural Decision Records (ADRs)
-
-## ADR-001: {Decisão Arquitetural}
-
-**Status:** Proposed/Accepted/Deprecated
-
-**Context:**
-{Por que esta decisão foi necessária}
-
-**Decision:**
-{O que foi decidido}
-
-**Consequences:**
-**Pros:**
-- Pro 1
-
-**Cons:**
-- Con 1
-
-**Alternatives Considered:**
-- Alternativa 1: {Por que foi rejeitada}
-
-**Date:** {YYYY-MM-DD}
-```
-
-**ADRs obrigatórios:**
-- Escolha de biblioteca UI (se FASE 1.5 executou)
-- Padrões arquiteturais (CQRS, Repository, etc.)
-- Recursos Azure (se houver infra)
-- Integrações externas (APIs, webhooks, etc.)
-
-### Passo 5: Estimar Custos
-
-Se houver recursos Azure na spec:
-
-**Limites configuráveis** (em config.json):
-- `costs.limits.freeTierOnly`: $0 (apenas free tier)
-- `costs.limits.withApproval`: $10 (requer confirmação do usuário)
-- `costs.limits.requiresADR`: $10 (requer ADR documentado)
-
-Documente custos em `decisions.md` e atualize state:
-
-```bash
-npx morph-spec state set {feature-name} costs.estimated {X.XX}
-npx morph-spec state set {feature-name} costs.approved {true/false}
-```
-
-### Passo 6: Atualizar State
-
-```bash
-npx morph-spec state set {feature-name} phase design
-npx morph-spec state mark-output {feature-name} spec
-npx morph-spec state mark-output {feature-name} contracts
-npx morph-spec state mark-output {feature-name} decisions
-```
-
-## Outputs Gerados
-
-- `.morph/project/outputs/{feature}/spec.md` - Especificação técnica completa
-- `.morph/project/outputs/{feature}/contracts.cs` - Interfaces, DTOs, Enums
-- `.morph/project/outputs/{feature}/decisions.md` - ADRs (novo ou atualizado)
-- State atualizado com custos estimados
-
-## PAUSA OBRIGATÓRIA
-
-Apresente ao usuário 3 ações sugeridas:
-
-1. **Aprovar design e continuar para clarificação**
-2. **Ajustar escopo/complexidade** - Revisar spec.md
-3. **Modificar contracts** - Ajustar interfaces/DTOs
-
-## Critérios de Avanço
-
-- [x] `spec.md` completo com todos os requisitos
-- [x] `contracts.cs` com interfaces e DTOs
-- [x] `decisions.md` com ADRs relevantes
-- [x] Custos estimados e documentados (se houver infra)
-- [x] State atualizado
-- [x] Usuário aprovou design
-
----
-
-Continuar automaticamente para FASE 3 (Clarify) após aprovação.

package/framework/skills/level-1-workflows/phase-setup.md

@@ -1,106 +0,0 @@
-# MORPH Setup - FASE 1
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Inicialize o contexto e prepare o ambiente para uma feature aprovada.
-
-## Pré-requisitos
-
-- [ ] Feature tem `proposal.md` criado (FASE 0 concluída)
-- [ ] Proposal foi aprovado pelo usuário
-- [ ] Agentes foram detectados e registrados no state
-
-## Workflow
-
-### Passo 1: Verificar State
-
-Confirme que a feature existe no state:
-
-```bash
-npx morph-spec state get {feature-name}
-```
-
-Se não existir, volte para FASE 0 (proposal).
-
-### Passo 2: Carregar Contexto e Standards Automaticamente
-
-**Use detect-agents --json para obter standards context:**
-
-```bash
-npx morph-spec detect-agents --json "{feature description from proposal}"
-```
-
-O output JSON contém `standardsSummary` com todos os standards relevantes para cada agente ativo:
-
-```json
-{
-  "standardsSummary": {
-    "blazor-builder": {
-      "standards": ["blazor-lifecycle", "blazor-state", "coding", ...],
-      "fullContent": "# blazor-lifecycle\n\n...",  // Full standards text
-      "count": 10
-    }
-  }
-}
-```
-
-**Standards resolution order** (automático):
-1. `.morph/project/standards/*.md` (project overrides - highest priority)
-2. `.morph/standards/*.md` (AI Agent Framework, Azure)
-3. `framework/standards/*.md` (Blazor, CSS, .NET)
-4. `.morph/project/standards/inferred.md` (always loaded if exists)
-
-**Contexto geral** (leia manualmente):
-- `.morph/project/context/README.md` - Overview do projeto
-- `.morph/config.json` - Configurações
-
-### Passo 3: Confirmar Stack
-
-Baseado no proposal e contexto, confirme:
-- Stack tecnológica (Blazor Server, Next.js, etc.)
-- Padrões arquiteturais aplicáveis
-- Componentes reutilizáveis existentes
-
-### Passo 4: Listar Agentes Ativos
-
-Mostre os agentes detectados no proposal:
-
-```bash
-npx morph-spec state get {feature-name}
-```
-
-Parse o JSON e liste os `activeAgents` com seus emojis e responsabilidades (consulte `.morph/config/agents.json`).
-
-### Passo 5: Atualizar State
-
-Marque a feature como na fase SETUP:
-
-```bash
-npx morph-spec state set {feature-name} phase setup
-npx morph-spec state set {feature-name} status in_progress
-```
-
-## Outputs
-
-**Apresente ao usuário:**
-
-1. **Contexto carregado**:
-   - Nome do projeto
-   - Stack confirmado
-   - Standards aplicáveis
-
-2. **Agentes ativos**:
-   - Lista de agentes com emojis
-   - Responsabilidades de cada um
-
-## Critérios de Avanço
-
-- [x] Contexto do projeto carregado
-- [x] Standards identificados (framework + project)
-- [x] Stack confirmado
-- [x] Agentes listados
-- [x] State atualizado para phase: setup
-
----
-
-Continuar automaticamente para próxima fase (UI/UX se detectado, ou Design).

package/framework/skills/level-1-workflows/phase-uiux.md

@@ -1,169 +0,0 @@
-# MORPH UI/UX Design - FASE 1.5
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Fase condicional para features com front-end. Coleta requisitos de UI/UX, gera wireframes, specs de componentes e fluxos de usuário.
-
-## Pré-requisitos
-
-- [ ] FASE 1 (Setup) concluída
-- [ ] Feature tem keywords de UI detectadas (blazor, ui, component, page, dashboard, wizard, form, chart)
-- [ ] `uiux-designer` agent ativado
-
-## Workflow
-
-### Passo 0: Verificar Design System Existe
-
-**CRITICAL:** Antes de iniciar a FASE UI/UX, verifique se um design system existe:
-
-```bash
-npx morph-spec detect-agents "{feature description}"
-```
-
-Se nenhum design system for detectado (verificar output):
-
-1. **Opção A - Scaffold automático:**
-   - O sistema criará automaticamente um design system ao avançar para implementação
-   - Você pode gerar manualmente agora: `npx morph-spec generate design-system`
-
-2. **Opção B - Criar manualmente:**
-   - Crie `.morph/project/design-system.md` (project-level, compartilhado)
-   - Ou `.morph/project/outputs/{feature}/ui-design-system.md` (feature-specific)
-
-3. **Opção C - Scan existing CSS:**
-   - Se o projeto já tem CSS com variáveis: `npx morph-spec generate design-system --scan`
-
-**⚠️ IMPORTANTE:**
-- Design system é **obrigatório** para features UI
-- Gate automático bloqueará implementação (FASE 5) se design system não existir
-- Melhor criar agora para garantir consistência visual
-
-### Passo 1: Detectar Se Fase É Necessária
-
-Verifique se agentes ativos incluem `uiux-designer`:
-
-```bash
-npx morph-spec state get {feature-name}
-```
-
-Se `uiux-designer` NÃO estiver nos `activeAgents`, pule esta fase e continue para FASE 2 (Design).
-
-### Passo 2: Coletar Input do Usuário
-
-**SEMPRE perguntar ao usuário PRIMEIRO:**
-
-1. **Layout e estilo**:
-   - Você tem alguma ideia de layout em mente?
-   - Tem alguma referência visual? (sites, apps, screenshots)
-   - Como imagina o fluxo do usuário?
-
-2. **Componentes e interações**:
-   - Quais os principais componentes desta tela/página?
-   - Quais estados precisam ser considerados? (loading, error, empty, success)
-
-3. **Imagens de referência**:
-   - Tem imagens de exemplo que eu possa analisar?
-   - Se SIM: use Read tool para ler screenshots e extrair padrões
-
-### Passo 3: Decidir Biblioteca UI
-
-Escolha entre **Fluent UI Blazor** (recomendado para AI-first) ou **MudBlazor** (componentes complexos):
-
-**Critérios:**
-- Fluent UI: Para dashboards, forms simples, AI components, Microsoft design language
-- MudBlazor: Para data grids avançadas, charts complexos, material design
-
-**Documente a decisão em `decisions.md`.**
-
-### Passo 4: Gerar Deliverables
-
-Crie os seguintes arquivos em `.morph/project/outputs/{feature}/`:
-
-#### 4.1. `ui-design-system.md`
-
-**Se design system project-level existe (`.morph/project/design-system.md`):**
-- Referencie-o nos specs: "Uses project design system at .morph/project/design-system.md"
-- Crie `ui-design-system.md` apenas se houver cores/componentes **específicos** da feature
-
-**Se não existe:**
-- Crie design system feature-level completo com:
-  - Paleta de cores (primary, secondary, accent, semantic)
-  - Tipografia (heading scales, body text, code)
-  - Spacing e layout (grid, margins, paddings)
-  - Componentes base (buttons, inputs, cards)
-
-#### 4.2. `ui-mockups.md`
-
-Wireframes ASCII + descrições:
-- Layout geral de cada tela/página
-- Posicionamento de componentes
-- Responsividade (desktop, tablet, mobile)
-- Estados (loading, error, empty, success)
-
-#### 4.3. `ui-components.md`
-
-Specs técnicas de componentes Fluent UI/MudBlazor:
-- Componente a usar (FluentButton, MudDataGrid, etc.)
-- Props e configurações
-- Eventos e bindings
-- Validações e estados
-
-#### 4.4. `ui-flows.md`
-
-Fluxos de usuário completos:
-- User stories
-- Diagramas de fluxo (texto/ASCII)
-- Edge cases (o que acontece se...?)
-- Validações e feedback
-
-### Passo 5: Validar Acessibilidade e Responsividade
-
-Documente nos arquivos UI:
-- **WCAG 2.1 Level AA** compliance
-  - Contraste de cores adequado
-  - Labels acessíveis para screen readers
-  - Navegação por teclado
-- **Responsive breakpoints**
-  - Desktop (>1200px)
-  - Tablet (768px - 1199px)
-  - Mobile (<768px)
-
-### Passo 6: Atualizar State
-
-```bash
-npx morph-spec state set {feature-name} phase uiux-design
-npx morph-spec state mark-output {feature-name} ui-design-system
-npx morph-spec state mark-output {feature-name} ui-mockups
-npx morph-spec state mark-output {feature-name} ui-components
-npx morph-spec state mark-output {feature-name} ui-flows
-```
-
-## Outputs Gerados
-
-- `.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`
-- `.morph/project/outputs/{feature}/decisions.md` (atualizado com ADR UI library)
-
-## PAUSA OBRIGATÓRIA
-
-Apresente ao usuário 3 ações sugeridas:
-
-1. **Aprovar UI/UX e prosseguir para design técnico**
-2. **Ajustar wireframes/componentes de telas específicas**
-3. **Revisar biblioteca UI escolhida (Fluent UI / MudBlazor)**
-
-## Critérios de Avanço
-
-- [x] Input do usuário coletado (layout, referências)
-- [x] Biblioteca UI escolhida e justificada (ADR)
-- [x] 4 deliverables criados (design-system, mockups, components, flows)
-- [x] Acessibilidade WCAG 2.1 documentada
-- [x] Responsividade especificada
-- [x] State atualizado
-- [x] Usuário aprovou UI/UX
-
----
-
-Continuar automaticamente para FASE 2 (Design) após aprovação.

package/framework/skills/level-2-domains/backend/api-designer.md

@@ -1,59 +0,0 @@
-# API Designer
-
-**Tier:** 3 (Specialist)
-**Always Active:** No
-**Keywords:** api, endpoint, controller, rest, http, route, dto, request, response
-**Reports to:** dotnet-senior
-
----
-
-## Role
-
-REST API design specialist for .NET Minimal API and controllers, focusing on clean endpoint design and DTO contracts.
-
----
-
-## Standards Applied
-
-```
-framework/standards/core/coding.md
-framework/standards/backend/dotnet/core.md
-framework/standards/backend/dotnet/async.md
-framework/standards/backend/api/rest.md
-framework/standards/backend/api/validation.md
-```
-
----
-
-## Responsibilities
-
-- Design REST API endpoints following conventions
-- Create request/response DTOs
-- Implement API controllers or Minimal API endpoints
-- Apply proper HTTP status codes (200, 201, 400, 404, etc.)
-- Implement input validation with FluentValidation
-- Design API versioning strategy
-- Create error response formats
-
----
-
-## When to Use
-
-- Creating new API endpoints
-- Designing DTO contracts
-- API refactoring
-- Implementing validation logic
-- Designing error responses
-
----
-
-## Collaborates With
-
-- **dotnet-senior** - Service layer consumed by endpoints
-- **ef-modeler** - Entity → DTO mapping
-- **blazor-builder** - Frontend consuming API
-- **testing-specialist** - API integration tests
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-2-domains/backend/ef-modeler.md

@@ -1,58 +0,0 @@
-# EF Modeler
-
-**Tier:** 3 (Specialist)
-**Always Active:** No
-**Keywords:** entity, database, migration, ef core, dbcontext, table, column, relationship, query
-**Reports to:** dotnet-senior
-
----
-
-## Role
-
-Entity Framework Core specialist for database modeling, entities, configurations, and migrations.
-
----
-
-## Standards Applied
-
-```
-framework/standards/core/coding.md
-framework/standards/backend/dotnet/core.md
-framework/standards/backend/database/ef-core.md
-framework/standards/backend/database/migrations.md
-framework/standards/backend/database/repository-patterns.md
-framework/standards/backend/database/performance.md
-```
-
----
-
-## Responsibilities
-
-- Design entity models with private setters and factory methods
-- Create IEntityTypeConfiguration for each entity
-- Configure relationships, indexes, and constraints
-- Generate and review EF Core migrations
-- Optimize database queries (avoid N+1, use proper includes)
-- Implement repository patterns with IDbContextFactory
-
----
-
-## When to Use
-
-- Creating/modifying entity classes
-- Database schema changes
-- Migration creation/review
-- Query optimization
-- DbContext configuration
-
----
-
-## Collaborates With
-
-- **dotnet-senior** - Service layer consuming repositories
-- **api-designer** - DTO mapping from entities
-- **azure-architect** - Database provisioning (Azure SQL, Cosmos DB)
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-3-technologies/README.md

@@ -1,7 +0,0 @@
-# Level 3: Technologies
-
-Technology-specific implementation patterns.
-
-**Purpose:** Skills for specific technologies (EF Core, Blazor, Hangfire, SignalR, etc.).
-
-**To be populated in Phase 8/9.**

package/framework/skills/level-4-patterns/README.md

@@ -1,7 +0,0 @@
-# Level 4: Patterns
-
-Architectural and design patterns.
-
-**Purpose:** Skills for specific patterns (CQRS, Event Sourcing, DDD, Repository, etc.).
-
-**To be populated later.**