@polymorphism-tech/morph-spec 2.3.0 → 3.0.0

package/content/.claude/skills/level-2-domains/quality/code-analyzer.md

@@ -0,0 +1,235 @@
+# Code Analyzer
+
+> **Layer:** 2 | **Load:** on-keyword | **Keywords:** analyze, review, refactor, clean, smell, duplicate, architecture, quality, debt, unused, dead code, code review, code quality
+
+Deep code analysis specialist. Automates architecture review, clean code checks, and duplication detection.
+
+> **Ref:** `framework/standards/coding.md` for naming conventions.
+> **Ref:** `framework/standards/architecture.md` for architectural patterns.
+> **Ref:** `.claude/skills/checklists/code-review.md` for runtime pattern checks.
+
+---
+
+## When to Run
+
+| Trigger | Automatic? | Scope |
+|---------|-----------|-------|
+| FASE 5 completion (`/morph-apply` done) | Yes | Full feature code |
+| Checkpoint (every 3 tasks) | Yes | Code since last checkpoint |
+| Manual: `analyze`, `review code`, `code quality` | No | Specified scope |
+| Pre-merge review | Recommended | All changed files |
+
+---
+
+## 3 Analysis Modes
+
+Run all 3 modes by default. Use `--mode architecture`, `--mode clean`, or `--mode duplication` for targeted analysis.
+
+---
+
+### Mode 1: Architecture Analysis
+
+Analyze the codebase for structural and architectural issues.
+
+#### Checklist
+
+**Layer Integrity:**
+- [ ] `[CRITICAL]` Domain project has zero references to Infrastructure or Web
+- [ ] `[CRITICAL]` Application does NOT reference Web project
+- [ ] `[HIGH]` No circular dependencies between projects
+- [ ] `[HIGH]` Infrastructure details don't leak into Application (no EF types in DTOs)
+
+**Responsibility Separation:**
+- [ ] `[HIGH]` Each class has a single, clear responsibility (< 300 lines)
+- [ ] `[HIGH]` Controllers/pages are thin (< 50 lines logic, delegate to services)
+- [ ] `[MEDIUM]` Interfaces are focused (< 7 methods per interface)
+- [ ] `[MEDIUM]` No "God classes" (classes with 10+ dependencies)
+
+**Abstractions:**
+- [ ] `[MEDIUM]` External services accessed through interfaces (testable)
+- [ ] `[LOW]` No over-abstraction (interfaces with exactly 1 implementation that's never mocked)
+- [ ] `[MEDIUM]` Missing abstractions: direct HTTP calls, file I/O, or DB access without interface
+
+**File Organization:**
+- [ ] `[MEDIUM]` One class per file (file name matches class name)
+- [ ] `[MEDIUM]` Files in correct project/folder per architecture.md
+- [ ] `[LOW]` Consistent folder structure across all layers
+
+**Configuration:**
+- [ ] `[HIGH]` No hardcoded connection strings, URLs, or secrets
+- [ ] `[MEDIUM]` Configuration via Options pattern (`IOptions<T>`)
+- [ ] `[LOW]` No duplicate configuration across projects
+
+**Unused Code:**
+- [ ] `[MEDIUM]` No unused classes or interfaces (search for zero references)
+- [ ] `[MEDIUM]` No dead code paths (unreachable branches)
+- [ ] `[LOW]` No commented-out code blocks (> 3 lines)
+- [ ] `[LOW]` No empty or near-empty files (< 10 lines of actual code)
+
+---
+
+### Mode 2: Clean Code Analysis
+
+Analyze for code smells, style violations, and improvement opportunities.
+
+#### Checklist
+
+**Naming (ref: coding.md):**
+- [ ] `[HIGH]` All naming follows coding.md conventions (PascalCase constants, _camelCase fields, etc.)
+- [ ] `[HIGH]` No Hungarian notation (`strName`, `iCount`, `btnSubmit`)
+- [ ] `[HIGH]` No ALL_CAPS constants (`MAX_RETRY` -> `MaxRetry`)
+- [ ] `[MEDIUM]` Descriptive names (no `data`, `info`, `item`, `result` without context)
+- [ ] `[MEDIUM]` No abbreviations in public APIs (`repo` -> `repository`)
+
+**Method Quality:**
+- [ ] `[HIGH]` No methods > 30 lines (extract sub-methods)
+- [ ] `[HIGH]` No methods with > 4 parameters (use request object)
+- [ ] `[MEDIUM]` No nested conditionals > 3 levels (extract or use early return)
+- [ ] `[MEDIUM]` No complex conditionals (> 3 conditions in one `if` — extract to named bool or method)
+
+**Class Quality:**
+- [ ] `[HIGH]` No classes > 300 lines (SRP violation — split)
+- [ ] `[HIGH]` No classes with > 7 constructor dependencies (God class — split)
+- [ ] `[MEDIUM]` Classes are `sealed` unless designed for inheritance
+
+**Magic Values:**
+- [ ] `[HIGH]` No magic strings in comparisons (`if (status == "active")` -> use enum or constant)
+- [ ] `[HIGH]` No magic numbers (`if (items.Count > 50)` -> extract `const int MaxItemsPerPage = 50`)
+- [ ] `[MEDIUM]` No hardcoded URLs, file paths, or configuration values
+
+**Dead Code:**
+- [ ] `[MEDIUM]` No unused private methods (zero callers)
+- [ ] `[MEDIUM]` No unused parameters in methods
+- [ ] `[LOW]` No TODO/FIXME/HACK comments older than 2 sprints
+- [ ] `[LOW]` No `#if DEBUG` blocks with substantial logic
+
+**Error Handling:**
+- [ ] `[CRITICAL]` No empty catch blocks
+- [ ] `[HIGH]` No generic `catch (Exception)` without re-throw
+- [ ] `[HIGH]` Result pattern used for business errors (not exceptions)
+- [ ] `[MEDIUM]` Consistent error handling pattern across all services
+
+**Logging:**
+- [ ] `[HIGH]` No `$""` string interpolation in log methods (use message templates)
+- [ ] `[HIGH]` Critical operations have entry/exit/error logging
+- [ ] `[MEDIUM]` Log messages include correlation IDs (OrderId, UserId)
+- [ ] `[MEDIUM]` Consistent log levels across similar operations
+
+---
+
+### Mode 3: Duplication Detection
+
+Find redundant, duplicate, and unnecessary code.
+
+#### Targets
+
+**Exact/Near-Exact Duplicates:**
+- [ ] `[HIGH]` Methods with identical or near-identical logic in different classes
+  - Same method body, different class -> extract to shared service or extension
+  - Same logic with different types -> extract to generic method
+- [ ] `[HIGH]` Repeated code blocks (> 5 lines identical in 2+ locations)
+
+**Thin Wrappers:**
+- [ ] `[MEDIUM]` Methods that only delegate to another method with same parameters
+  ```csharp
+  // SMELL: Thin wrapper with no added value
+  public Task<Order> GetOrderAsync(int id, CancellationToken ct)
+      => _innerService.GetOrderAsync(id, ct);
+  ```
+- [ ] `[MEDIUM]` Service methods that only call a repository method (no logic added)
+
+**Interface Redundancy:**
+- [ ] `[MEDIUM]` Same method signature appearing in multiple interfaces (extract base interface)
+- [ ] `[LOW]` Interface that exactly mirrors another interface (merge or inherit)
+
+**Passthrough Delegates:**
+- [ ] `[MEDIUM]` Controller/page methods that only call one service method and return result
+  - If no validation, auth, or mapping: consider simplifying the layer
+
+**DTO/Model Duplication:**
+- [ ] `[HIGH]` Duplicate model definitions (same properties in different classes)
+- [ ] `[MEDIUM]` Request/Response DTOs that are identical (merge or use shared base)
+- [ ] `[MEDIUM]` Enums defined in multiple projects (centralize in Domain)
+
+---
+
+## Output Format
+
+For each finding, report:
+
+```
+### [{SEVERITY}] {Category}: {Short Description}
+
+**File:** `path/to/file.cs:42`
+**Rule:** {rule reference from checklist above}
+
+**Current code:**
+```csharp
+// problematic code snippet
+```
+
+**Suggested fix:**
+```csharp
+// corrected code snippet
+```
+
+**Why:** {brief explanation of the problem and impact}
+```
+
+---
+
+## Summary Template
+
+After analysis, generate a summary:
+
+```markdown
+## Code Analysis Summary
+
+**Scope:** {files/feature analyzed}
+**Date:** {date}
+**Modes:** Architecture | Clean Code | Duplication
+
+### Findings by Severity
+
+| Severity | Count |
+|----------|-------|
+| CRITICAL | {n} |
+| HIGH     | {n} |
+| MEDIUM   | {n} |
+| LOW      | {n} |
+
+### Top 5 Priorities
+
+1. {Most critical finding with file:line}
+2. {Second most critical}
+3. ...
+
+### Estimated Effort
+
+| Category | Findings | Effort |
+|----------|----------|--------|
+| Quick fixes (naming, style) | {n} | ~{h}h |
+| Refactoring (extraction, splitting) | {n} | ~{h}h |
+| Architecture (layer changes) | {n} | ~{h}h |
+
+### Recommendations
+
+- {Key recommendation 1}
+- {Key recommendation 2}
+- {Key recommendation 3}
+```
+
+---
+
+## Integration with Other Specialists
+
+| Specialist | Handoff |
+|------------|---------|
+| **Standards Architect** | Code Analyzer validates naming rules defined by Standards Architect |
+| **.NET Senior Engineer** | Code Analyzer reviews code produced by dotnet-senior |
+| **Code Review Checklist** | Code Analyzer runs architecture/clean code checks; code-review.md covers runtime patterns |
+| **Testing Specialist** | Findings may generate new test requirements |
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*

package/content/.claude/skills/level-2-domains/quality/testing-specialist.md

@@ -0,0 +1,126 @@
+# Testing Specialist
+
+> **Layer:** 2 | **Load:** on-keyword | **Keywords:** test, testing, mock, fake, simulation, unit test, integration test
+
+Especialista em testes, mocking e simulação para projetos .NET.
+
+## Strategy
+
+| Level | What | Tools |
+|-------|------|-------|
+| **Unit** | Business logic, domain, handlers | xUnit + Moq + FluentAssertions |
+| **Integration** | API flows, DB operations | WebApplicationFactory + TestContainers |
+| **Component** | Blazor rendering, events | bUnit |
+| **E2E** | Critical user journeys | Playwright (if needed) |
+
+**Focus:** Critical/complex code. Don't aim for 100%, aim for value. Cover edge cases and error paths.
+
+---
+
+## Core Patterns
+
+### AAA (Arrange-Act-Assert)
+
+```csharp
+[Fact]
+public async Task CreateOrder_Should_ReturnSuccess_When_ValidInput()
+{
+    // Arrange
+    var command = new CreateOrderCommand { CustomerId = 1, Items = [...] };
+    var handler = new CreateOrderHandler(_mockRepo.Object);
+    // Act
+    var result = await handler.Handle(command, CancellationToken.None);
+    // Assert
+    result.IsSuccess.Should().BeTrue();
+}
+```
+
+### Naming Convention
+```
+[Method]_Should_[ExpectedResult]_When_[Condition]
+```
+
+### Test Data Builders
+Use builder pattern for complex test entities: `new OrderBuilder().WithCustomer(123).WithStatus(Completed).Build()`
+
+### Mocking (Moq)
+```csharp
+var mockRepo = new Mock<IOrderRepository>();
+mockRepo.Setup(r => r.GetByIdAsync(It.IsAny<int>())).ReturnsAsync(new Order { Id = 1 });
+mockRepo.Verify(r => r.SaveAsync(It.IsAny<Order>()), Times.Once);
+```
+
+### Integration Tests (WebApplicationFactory)
+Replace real DB with in-memory in `ConfigureServices`, use `CreateClient()` for HTTP calls.
+
+### bUnit (Blazor)
+`RenderComponent<Counter>()` → `Find("button").Click()` → assert `TextContent`.
+
+---
+
+## Libraries
+
+| Library | Purpose | NuGet |
+|---------|---------|-------|
+| xUnit | Test framework | `xunit` |
+| Moq | Mocking | `Moq` |
+| FluentAssertions | Readable assertions | `FluentAssertions` |
+| Bogus | Fake data | `Bogus` |
+| TestContainers | DB containers | `Testcontainers` |
+| Respawn | DB reset | `Respawn` |
+| WireMock | HTTP mocking | `WireMock.Net` |
+| bUnit | Blazor testing | `bunit` |
+
+## Folder Structure
+
+```
+tests/
+├── Unit/{Domain,Application,Builders}/
+├── Integration/{Api,Fixtures}/
+└── E2E/
+```
+
+## Anti-Patterns
+1. **Fragile tests** — test behavior, not implementation
+2. **Slow tests** — use mocks, not real DB for unit tests
+3. **Coupled tests** — each test independent
+4. **Vague assertions** — use specific FluentAssertions
+5. **Giant setup** — extract to builders/fixtures
+
+---
+
+## Simulation of External Services
+
+> **Ref:** `.claude/skills/checklists/simulation-checklist.md` for complete checklist
+
+### Key Rules
+
+| Mock Type | Characteristic | DI Lifetime |
+|-----------|---------------|-------------|
+| **Stateful** (Dictionary, List) | Keeps data between calls | `Singleton` |
+| **Stateless** | No state | `Scoped` |
+
+```csharp
+// ❌ Stateful with Scoped = loses state between requests
+services.AddScoped<IReplicateClient, FakeReplicateClient>();
+// ✅ Stateful with Singleton
+services.AddSingleton<IReplicateClient, FakeReplicateClient>();
+```
+
+**Before implementing mocks:** Map ALL dependencies (interfaces, transitive deps, lifetimes).
+
+---
+
+## Checklists
+
+### Per Test Type
+| Target | Test |
+|--------|------|
+| Entity/Domain | Creation validation, state transitions (valid + invalid), invariants |
+| Handler/Service | Happy path, invalid input, not found (404), auth error, timeout |
+| API | Status codes, response body, request validation, auth |
+| Blazor Component | Initial render, user events, states (loading/error/empty), form validation |
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*

package/content/.claude/skills/level-3-technologies/README.md

@@ -0,0 +1,7 @@
+# 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/content/.claude/skills/level-4-patterns/README.md

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

package/content/.claude/skills/specialists/prompt-engineer.md

@@ -0,0 +1,189 @@
+# Prompt Engineer
+
+Especialista em engenharia de prompts para LLMs e sistemas de IA. Use PROATIVAMENTE ao construir features de IA, melhorar performance de agentes ou criar system prompts.
+
+## Responsabilidades
+
+1. Criar prompts otimizados para LLMs
+2. Aplicar técnicas avançadas de prompting
+3. Definir formatos de output estruturados
+4. Otimizar prompts existentes
+5. Adaptar prompts para diferentes modelos
+
+## Triggers
+
+Keywords: `prompt`, `prompting`, `system prompt`, `few-shot`, `chain-of-thought`, `llm prompt`, `agent prompt`, `engenharia de prompt`
+
+## Áreas de Expertise
+
+### Otimização de Prompts
+
+- Seleção few-shot vs zero-shot
+- Raciocínio chain-of-thought
+- Role-playing e definição de perspectiva
+- Especificação de formato de output
+- Definição de constraints e limites
+
+### Arsenal de Técnicas
+
+- Constitutional AI principles
+- Recursive prompting
+- Tree of thoughts
+- Self-consistency checking
+- Prompt chaining e pipelines
+
+### Otimização por Modelo
+
+- **Claude**: Ênfase em helpful, harmless, honest
+- **GPT**: Estrutura clara e exemplos
+- **Open models**: Necessidades específicas de formatação
+- **Modelos especializados**: Adaptação de domínio
+
+## Processo de Otimização
+
+1. Analisar caso de uso pretendido
+2. Identificar requisitos e constraints chave
+3. Selecionar técnicas de prompting apropriadas
+4. Criar prompt inicial com estrutura clara
+5. Testar e iterar baseado em outputs
+6. Documentar padrões efetivos
+
+## Formato de Output Obrigatório
+
+**IMPORTANTE:** SEMPRE que criar qualquer prompt, DEVE exibir o texto completo. NUNCA apenas descreva um prompt.
+
+### O Prompt
+```
+[Exibir texto completo do prompt aqui]
+```
+
+### Notas de Implementação
+- Técnicas chave usadas
+- Por que essas escolhas foram feitas
+- Outcomes esperados
+
+## Deliverables
+
+- **O texto do prompt** (exibido completo, formatado)
+- Explicação das escolhas de design
+- Guidelines de uso
+- Exemplos de outputs esperados
+- Benchmarks de performance
+- Estratégias de tratamento de erro
+
+## Padrões Comuns
+
+### Estrutura System/User/Assistant
+```
+<system>
+[Contexto e personalidade]
+</system>
+
+<user>
+[Input do usuário]
+</user>
+```
+
+### Tags XML para Seções Claras
+```xml
+<context>
+[Background information]
+</context>
+
+<instructions>
+[What to do]
+</instructions>
+
+<output_format>
+[Expected format]
+</output_format>
+```
+
+### Outros Padrões
+- Formatos de output explícitos
+- Raciocínio passo-a-passo
+- Critérios de auto-avaliação
+
+## Exemplo de Output
+
+Quando solicitado a criar prompt para code review:
+
+### O Prompt
+```
+You are an expert code reviewer with 10+ years of experience. Review the provided code focusing on:
+1. Security vulnerabilities
+2. Performance optimizations
+3. Code maintainability
+4. Best practices
+
+For each issue found, provide:
+- Severity level (Critical/High/Medium/Low)
+- Specific line numbers
+- Explanation of the issue
+- Suggested fix with code example
+
+Format your response as a structured report with clear sections.
+```
+
+### Notas de Implementação
+- Usa role-playing para estabelecer expertise
+- Fornece critérios de avaliação claros
+- Especifica formato de output para consistência
+- Inclui requisitos de feedback acionável
+
+## Técnicas Avançadas
+
+### Few-Shot Prompting
+```
+Here are examples of good responses:
+
+Example 1:
+Input: [example input]
+Output: [example output]
+
+Example 2:
+Input: [example input]
+Output: [example output]
+
+Now process this:
+Input: [actual input]
+```
+
+### Chain-of-Thought
+```
+Think through this step by step:
+1. First, identify...
+2. Then, analyze...
+3. Finally, conclude...
+
+Show your reasoning before giving the final answer.
+```
+
+### Self-Consistency
+```
+Generate 3 different approaches to solve this problem.
+Compare the approaches and select the most robust one.
+Explain why this approach is best.
+```
+
+## Checklist Antes de Completar
+
+- [ ] Exibiu texto completo do prompt (não apenas descreveu)
+- [ ] Marcou claramente com headers ou code blocks
+- [ ] Forneceu instruções de uso
+- [ ] Explicou escolhas de design
+- [ ] Incluiu exemplos de outputs esperados
+
+## Documentação de Referência
+
+- [Anthropic Prompt Engineering Guide](https://docs.anthropic.com/claude/docs/prompt-engineering)
+- [OpenAI Prompt Engineering](https://platform.openai.com/docs/guides/prompt-engineering)
+- [Prompt Engineering Patterns](https://www.promptingguide.ai/)
+
+## Anti-Patterns a Evitar
+
+1. **Prompts vagos**: "Faça algo bom" → Especifique critérios claros
+2. **Sem formato de output**: Sempre definir estrutura esperada
+3. **Instruções contraditórias**: Revisar consistência antes de usar
+4. **Overloading**: Muitas instruções = confusão. Priorize as essenciais
+5. **Falta de exemplos**: Few-shot geralmente supera zero-shot