@polymorphism-tech/morph-spec 2.2.0 → 2.4.0

package/content/.claude/skills/specialists/po-pm-advisor.md

@@ -1,197 +1,197 @@
-# PO/PM Advisor
-
-Especialista em requisitos, priorização e gestão de produto para clarificar features e ROI.
-
-## Responsabilidades
-
-1. **Clarificar requisitos** ambíguos ou incompletos
-2. **Priorizar features** por valor de negócio
-3. **Calcular ROI** e esforço estimado
-4. **Definir critérios** de aceitação
-
-## Triggers
-
-Keywords: `unclear`, `requirements`, `priority`, `ROI`, `mvp`, `scope`, `acceptance criteria`, `user story`
-
-## Framework de Clarificação
-
-### Perguntas Essenciais
-
-Quando receber uma feature request ambígua, faça estas perguntas:
-
-1. **Quem?** - Qual o usuário/persona principal?
-2. **O quê?** - O que exatamente deve acontecer?
-3. **Por quê?** - Qual problema resolve? Qual o valor?
-4. **Quando?** - Urgência? Deadline externo?
-5. **Como medir?** - Como saberemos que funcionou?
-
-### Template de User Story
-
-```markdown
-## User Story: {Nome da Feature}
-
-**Como** {persona/usuário},
-**Eu quero** {ação/funcionalidade},
-**Para que** {benefício/valor}.
-
-### Critérios de Aceitação
-
-**Dado** {contexto inicial},
-**Quando** {ação do usuário},
-**Então** {resultado esperado}.
-
-### Fora do Escopo
-
-- {Item explicitamente excluído}
-
-### Perguntas Pendentes
-
-- [ ] {Dúvida não resolvida}
-```
-
-## Matriz de Priorização (RICE)
-
-| Fator | Descrição | Escala |
-|-------|-----------|--------|
-| **R**each | Quantos usuários impacta | 1-10 |
-| **I**mpact | Quanto impacta cada usuário | 0.25, 0.5, 1, 2, 3 |
-| **C**onfidence | Confiança nas estimativas | 0-100% |
-| **E**ffort | Pessoa-semanas de trabalho | 1+ |
-
-```
-RICE Score = (Reach × Impact × Confidence) / Effort
-```
-
-### Exemplo
-
-| Feature | Reach | Impact | Confidence | Effort | Score |
-|---------|-------|--------|------------|--------|-------|
-| Login social | 8 | 1 | 80% | 1 | 6.4 |
-| Dashboard | 5 | 2 | 90% | 3 | 3.0 |
-| Export PDF | 3 | 0.5 | 100% | 0.5 | 3.0 |
-| Dark mode | 4 | 0.25 | 100% | 1 | 1.0 |
-
-## MVP vs Nice-to-Have
-
-### Critérios para MVP
-
-1. **Resolve o problema core** do usuário
-2. **Diferencia** da concorrência
-3. **Validável** em 2-4 semanas
-4. **Mensurável** (métricas definidas)
-
-### Framework MoSCoW
-
-| Categoria | Significado | Exemplo |
-|-----------|-------------|---------|
-| **M**ust have | Essencial, sem isso não funciona | Login, CRUD básico |
-| **S**hould have | Importante, mas não crítico | Filtros avançados |
-| **C**ould have | Desejável se houver tempo | Exportar relatório |
-| **W**on't have | Fora deste release | Integração X |
-
-## Estimativa de Esforço
-
-### T-Shirt Sizing
-
-| Size | Dias | Complexidade |
-|------|------|--------------|
-| XS | 0.5 | Task trivial |
-| S | 1-2 | Feature simples |
-| M | 3-5 | Feature com complexidade |
-| L | 5-10 | Feature complexa |
-| XL | 10+ | Épico, precisa quebrar |
-
-### Fatores de Risco
-
-Multiplicar estimativa por:
-
-| Fator | Multiplicador |
-|-------|---------------|
-| Tecnologia nova | 1.5x |
-| Integração externa | 1.3x |
-| Requisitos vagos | 1.5x |
-| Primeiro da equipe | 1.3x |
-
-## Template de ADR (Architecture Decision Record)
-
-```markdown
-# ADR-{XXX}: {Título da Decisão}
-
-## Status
-{PROPOSED | ACCEPTED | DEPRECATED | SUPERSEDED}
-
-## Contexto
-{Situação que requer decisão}
-
-## Opções Consideradas
-
-### Opção 1: {Nome}
-- Prós: ...
-- Contras: ...
-- Custo: ...
-
-### Opção 2: {Nome}
-- Prós: ...
-- Contras: ...
-- Custo: ...
-
-## Decisão
-{Opção escolhida e por quê}
-
-## Consequências
-- {Implicação positiva}
-- {Implicação negativa}
-- {Trade-off aceito}
-```
-
-## Cálculo de ROI
-
-```markdown
-## ROI Estimado: {Feature}
-
-### Benefícios (anual)
-- Aumento de conversão: R$ X
-- Redução de suporte: R$ Y
-- Economia de tempo: R$ Z
-- **Total Benefícios**: R$ (X+Y+Z)
-
-### Custos
-- Desenvolvimento: R$ A (horas × rate)
-- Infraestrutura: R$ B/mês × 12
-- Manutenção: R$ C/ano
-- **Total Custos**: R$ (A+B+C)
-
-### ROI
-**ROI = (Benefícios - Custos) / Custos × 100**
-
-ROI = (X+Y+Z - A+B+C) / (A+B+C) × 100 = **{N}%**
-
-### Payback
-**Meses = Custo Inicial / (Benefício Mensal - Custo Mensal)**
-```
-
-## Red Flags em Requisitos
-
-Alertar quando detectar:
-
-- "Deve ser igual ao [concorrente X]" sem especificar
-- "Simples" ou "rápido" sem estimativa
-- "Usuários querem..." sem evidência
-- Escopo crescente sem priorização
-- Deadline impossível sem trade-offs
-
-## Checklist de Requisitos
-
-- [ ] Persona/usuário definido
-- [ ] Problema claramente articulado
-- [ ] Valor de negócio quantificado
-- [ ] Critérios de aceitação escritos
-- [ ] Fora do escopo explícito
-- [ ] Dependências mapeadas
-- [ ] Riscos identificados
-- [ ] Estimativa de esforço
-- [ ] Prioridade definida (RICE/MoSCoW)
-
----
-
-*MORPH-SPEC by Polymorphism Tech*
+# PO/PM Advisor
+
+Especialista em requisitos, priorização e gestão de produto para clarificar features e ROI.
+
+## Responsabilidades
+
+1. **Clarificar requisitos** ambíguos ou incompletos
+2. **Priorizar features** por valor de negócio
+3. **Calcular ROI** e esforço estimado
+4. **Definir critérios** de aceitação
+
+## Triggers
+
+Keywords: `unclear`, `requirements`, `priority`, `ROI`, `mvp`, `scope`, `acceptance criteria`, `user story`
+
+## Framework de Clarificação
+
+### Perguntas Essenciais
+
+Quando receber uma feature request ambígua, faça estas perguntas:
+
+1. **Quem?** - Qual o usuário/persona principal?
+2. **O quê?** - O que exatamente deve acontecer?
+3. **Por quê?** - Qual problema resolve? Qual o valor?
+4. **Quando?** - Urgência? Deadline externo?
+5. **Como medir?** - Como saberemos que funcionou?
+
+### Template de User Story
+
+```markdown
+## User Story: {Nome da Feature}
+
+**Como** {persona/usuário},
+**Eu quero** {ação/funcionalidade},
+**Para que** {benefício/valor}.
+
+### Critérios de Aceitação
+
+**Dado** {contexto inicial},
+**Quando** {ação do usuário},
+**Então** {resultado esperado}.
+
+### Fora do Escopo
+
+- {Item explicitamente excluído}
+
+### Perguntas Pendentes
+
+- [ ] {Dúvida não resolvida}
+```
+
+## Matriz de Priorização (RICE)
+
+| Fator | Descrição | Escala |
+|-------|-----------|--------|
+| **R**each | Quantos usuários impacta | 1-10 |
+| **I**mpact | Quanto impacta cada usuário | 0.25, 0.5, 1, 2, 3 |
+| **C**onfidence | Confiança nas estimativas | 0-100% |
+| **E**ffort | Pessoa-semanas de trabalho | 1+ |
+
+```
+RICE Score = (Reach × Impact × Confidence) / Effort
+```
+
+### Exemplo
+
+| Feature | Reach | Impact | Confidence | Effort | Score |
+|---------|-------|--------|------------|--------|-------|
+| Login social | 8 | 1 | 80% | 1 | 6.4 |
+| Dashboard | 5 | 2 | 90% | 3 | 3.0 |
+| Export PDF | 3 | 0.5 | 100% | 0.5 | 3.0 |
+| Dark mode | 4 | 0.25 | 100% | 1 | 1.0 |
+
+## MVP vs Nice-to-Have
+
+### Critérios para MVP
+
+1. **Resolve o problema core** do usuário
+2. **Diferencia** da concorrência
+3. **Validável** em 2-4 semanas
+4. **Mensurável** (métricas definidas)
+
+### Framework MoSCoW
+
+| Categoria | Significado | Exemplo |
+|-----------|-------------|---------|
+| **M**ust have | Essencial, sem isso não funciona | Login, CRUD básico |
+| **S**hould have | Importante, mas não crítico | Filtros avançados |
+| **C**ould have | Desejável se houver tempo | Exportar relatório |
+| **W**on't have | Fora deste release | Integração X |
+
+## Estimativa de Esforço
+
+### T-Shirt Sizing
+
+| Size | Dias | Complexidade |
+|------|------|--------------|
+| XS | 0.5 | Task trivial |
+| S | 1-2 | Feature simples |
+| M | 3-5 | Feature com complexidade |
+| L | 5-10 | Feature complexa |
+| XL | 10+ | Épico, precisa quebrar |
+
+### Fatores de Risco
+
+Multiplicar estimativa por:
+
+| Fator | Multiplicador |
+|-------|---------------|
+| Tecnologia nova | 1.5x |
+| Integração externa | 1.3x |
+| Requisitos vagos | 1.5x |
+| Primeiro da equipe | 1.3x |
+
+## Template de ADR (Architecture Decision Record)
+
+```markdown
+# ADR-{XXX}: {Título da Decisão}
+
+## Status
+{PROPOSED | ACCEPTED | DEPRECATED | SUPERSEDED}
+
+## Contexto
+{Situação que requer decisão}
+
+## Opções Consideradas
+
+### Opção 1: {Nome}
+- Prós: ...
+- Contras: ...
+- Custo: ...
+
+### Opção 2: {Nome}
+- Prós: ...
+- Contras: ...
+- Custo: ...
+
+## Decisão
+{Opção escolhida e por quê}
+
+## Consequências
+- {Implicação positiva}
+- {Implicação negativa}
+- {Trade-off aceito}
+```
+
+## Cálculo de ROI
+
+```markdown
+## ROI Estimado: {Feature}
+
+### Benefícios (anual)
+- Aumento de conversão: R$ X
+- Redução de suporte: R$ Y
+- Economia de tempo: R$ Z
+- **Total Benefícios**: R$ (X+Y+Z)
+
+### Custos
+- Desenvolvimento: R$ A (horas × rate)
+- Infraestrutura: R$ B/mês × 12
+- Manutenção: R$ C/ano
+- **Total Custos**: R$ (A+B+C)
+
+### ROI
+**ROI = (Benefícios - Custos) / Custos × 100**
+
+ROI = (X+Y+Z - A+B+C) / (A+B+C) × 100 = **{N}%**
+
+### Payback
+**Meses = Custo Inicial / (Benefício Mensal - Custo Mensal)**
+```
+
+## Red Flags em Requisitos
+
+Alertar quando detectar:
+
+- "Deve ser igual ao [concorrente X]" sem especificar
+- "Simples" ou "rápido" sem estimativa
+- "Usuários querem..." sem evidência
+- Escopo crescente sem priorização
+- Deadline impossível sem trade-offs
+
+## Checklist de Requisitos
+
+- [ ] Persona/usuário definido
+- [ ] Problema claramente articulado
+- [ ] Valor de negócio quantificado
+- [ ] Critérios de aceitação escritos
+- [ ] Fora do escopo explícito
+- [ ] Dependências mapeadas
+- [ ] Riscos identificados
+- [ ] Estimativa de esforço
+- [ ] Prioridade definida (RICE/MoSCoW)
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*

package/content/.claude/skills/specialists/standards-architect.md

@@ -1,78 +1,156 @@
-# Standards Architect
-
-Especialista em padrões de código, arquitetura e boas práticas para projetos .NET.
-
-## Responsabilidades
-
-1. **Garantir aderência aos padrões** definidos em `.morph/standards/`
-2. **Validar nomenclatura** de classes, métodos, variáveis
-3. **Revisar código** antes de aprovar merges
-4. **Definir convenções** de projeto
-
-## Triggers
-
-Ativado automaticamente em todo projeto MORPH-SPEC (Core Agent).
-
-Keywords: `standards`, `naming`, `convention`, `pattern`, `review`, `quality`
-
-## Padrões de Código (.NET)
-
-### Nomenclatura
-
-```csharp
-// Classes: PascalCase
-public class OrderService { }
-
-// Interfaces: I + PascalCase
-public interface IOrderService { }
-
-// Métodos: PascalCase
-public async Task<Order> GetOrderAsync(int id) { }
-
-// Variáveis: camelCase
-private readonly ILogger _logger;
-
-// Constantes: UPPER_SNAKE_CASE
-public const string DEFAULT_STATUS = "pending";
-```
-
-### Estrutura de Projeto
-
-```
-src/
-├── {Project}.Domain/          # Entidades, Value Objects
-├── {Project}.Application/     # Services, DTOs, Interfaces
-├── {Project}.Infrastructure/  # EF, External Services
-├── {Project}.Web/             # Blazor, API Controllers
-└── {Project}.Tests/           # Unit, Integration tests
-```
-
-### Padrões Blazor
-
-```razor
-@* Componentes: PascalCase.razor *@
-@* Parameters: [Parameter] obrigatório *@
-@* EventCallbacks: On{Event}Async *@
-
-<OrderList Orders="@_orders" OnSelectAsync="HandleSelectAsync" />
-```
-
-## Documentação de Referência
-
-- [C# Coding Conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions)
-- [.NET Naming Guidelines](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines)
-- [Blazor Best Practices](https://learn.microsoft.com/en-us/aspnet/core/blazor/performance)
-
-## Checklist de Revisão
-
-- [ ] Nomenclatura segue convenções
-- [ ] Async/await usado corretamente
-- [ ] Nullable reference types habilitado
-- [ ] DI registrado corretamente
-- [ ] Logs estruturados com ILogger
-- [ ] Exceptions tratadas adequadamente
-- [ ] Código sem warnings
-
----
-
-*MORPH-SPEC by Polymorphism Tech*
+# Standards Architect
+
+> **Layer:** 0 | **Load:** always | **Scope:** All .NET projects (Core Agent)
+
+Guardiao dos padroes de codigo, nomenclatura e arquitetura. Valida aderencia aos standards antes de aprovar merges.
+
+> **Ref:** `framework/standards/coding.md` for complete C# naming conventions and .editorconfig template.
+> **Ref:** `framework/standards/architecture.md` for Clean Architecture layers, SOLID, service patterns.
+
+## Responsabilidades
+
+1. **Garantir aderencia aos padroes** definidos em `framework/standards/` e `.morph/project/standards/`
+2. **Validar nomenclatura** contra `coding.md` (PascalCase, _camelCase, etc.)
+3. **Revisar codigo** antes de aprovar merges
+4. **Definir convencoes** de projeto
+5. **Orquestrar validacao:** Standards Architect (naming) -> Code Analyzer (architecture) -> Code Review (runtime patterns)
+
+## Triggers
+
+Ativado automaticamente em todo projeto MORPH-SPEC (Core Agent).
+
+Keywords: `standards`, `naming`, `convention`, `pattern`, `review`, `quality`, `editorconfig`, `style`
+
+---
+
+## Naming Quick Reference
+
+> Full reference: `framework/standards/coding.md`
+
+| Element | Convention | Example |
+|---------|-----------|---------|
+| Classes, Methods, Properties | PascalCase | `OrderService`, `GetOrderAsync` |
+| Interfaces | `I` + PascalCase | `IOrderService` |
+| Constants | PascalCase | `DefaultPageSize`, `MaxRetryCount` |
+| Private fields | `_camelCase` | `_repository`, `_logger` |
+| Parameters, locals | camelCase | `orderId`, `orderTotal` |
+| Enums | PascalCase | `OrderStatus.PendingPayment` |
+| Async methods | PascalCase + `Async` | `ProcessPaymentAsync` |
+
+**CRITICAL:** Constants use PascalCase, NOT UPPER_SNAKE_CASE. This follows Microsoft .NET guidelines.
+
+---
+
+## Instant-Fail Rules (Severity: Error)
+
+These rules MUST be satisfied. Code that violates them cannot be merged.
+
+| # | Rule | Signal | Ref |
+|---|------|--------|-----|
+| 1 | **Constants in ALL_CAPS** | `MAX_RETRY_COUNT` instead of `MaxRetryCount` | coding.md |
+| 2 | **Hungarian notation** | `strName`, `iCount`, `btnSubmit` | coding.md |
+| 3 | **Missing CancellationToken** | Async method without `ct` parameter | coding.md |
+| 4 | **`.Result` or `.Wait()`** | Synchronous blocking on async (deadlock) | coding.md |
+| 5 | **Scoped DbContext in background** | Direct `DbContext` in Task.Run/Hangfire | blazor-efcore.md |
+| 6 | **Empty catch block** | `catch { }` or `catch (Exception) { }` | coding.md |
+| 7 | **Domain referencing Infrastructure** | `using MyApp.Infrastructure` in Domain project | architecture.md |
+| 8 | **Hardcoded secrets** | Connection strings, API keys in code | architecture.md |
+| 9 | **Missing `sealed`** | Non-abstract class without `sealed` | coding.md |
+| 10 | **Generic `Exception` throw** | `throw new Exception("...")` | coding.md |
+
+---
+
+## Warning Rules (Severity: Warning)
+
+| # | Rule | Signal |
+|---|------|--------|
+| 1 | Method > 30 lines | Needs extraction |
+| 2 | Class > 300 lines | SRP violation, split |
+| 3 | > 4 constructor parameters | Consider grouping or splitting |
+| 4 | Missing structured logging | Service method without `ILogger` usage |
+| 5 | `string.Format` or `$""` in log | Use message templates |
+| 6 | Abbreviations in names | `repo`, `ctx`, `mgr` (use full words) |
+| 7 | Missing `null` check | Parameter not validated at boundary |
+| 8 | Unused `using` | Dead imports |
+
+---
+
+## Enforcement
+
+### .editorconfig
+
+Every project MUST have an `.editorconfig` in the root. Template in `coding.md`.
+
+```bash
+# Validate naming rules at build time
+dotnet build /warnaserror:IDE1006
+```
+
+### Validation Workflow
+
+```
+1. Standards Architect    → Naming, style, conventions (coding.md)
+2. Code Analyzer          → Architecture, clean code, duplication (architecture.md)
+3. Code Review Checklist  → Runtime patterns: async, DI, logging (code-review.md)
+```
+
+This pipeline runs:
+- **Automatically** at FASE 5 completion and at every checkpoint (every 3 tasks)
+- **Manually** when requested via `review`, `analyze`, `check standards`
+
+---
+
+## Estrutura de Projeto
+
+> Full reference: `framework/standards/architecture.md`
+
+```
+src/
+├── {Project}.Domain/          # Entidades, Value Objects, Enums
+├── {Project}.Application/     # Services, DTOs, Interfaces
+├── {Project}.Infrastructure/  # EF Core, External Services
+├── {Project}.Web/             # Blazor, API Controllers
+└── tests/                     # Unit, Integration tests
+```
+
+---
+
+## Padroes Blazor
+
+```razor
+@* Componentes: PascalCase.razor *@
+@* Parameters: [Parameter] obrigatorio *@
+@* EventCallbacks: On{Event}Async *@
+
+<OrderList Orders="@_orders" OnSelectAsync="HandleSelectAsync" />
+```
+
+---
+
+## Documentacao de Referencia
+
+- `framework/standards/coding.md` — C# naming, style, .editorconfig
+- `framework/standards/architecture.md` — Clean Architecture, SOLID, DI
+- `framework/standards/blazor-efcore.md` — DbContext, Repository Factory
+- `framework/standards/blazor-pitfalls.md` — Common Blazor issues
+- [Microsoft C# Coding Conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions)
+- [.NET Naming Guidelines](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines)
+
+---
+
+## Checklist de Revisao
+
+- [ ] Nomenclatura segue `coding.md` (PascalCase constants, _camelCase fields)
+- [ ] `.editorconfig` presente no projeto
+- [ ] Async/await com CancellationToken
+- [ ] Nullable reference types habilitado
+- [ ] DI registrado corretamente (lifetimes corretos)
+- [ ] Logs estruturados com `ILogger<T>` (message templates)
+- [ ] Exceptions tratadas adequadamente (Result pattern para business)
+- [ ] Classes `sealed` por padrao
+- [ ] Codigo sem warnings (IDE1006 enforced)
+- [ ] Arquitetura segue `architecture.md` (layers, SOLID)
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*