@polymorphism-tech/morph-spec 4.5.0 → 4.7.0

package/framework/skills/level-1-workflows/{phase-design.md → phase-design/SKILL.md}

@@ -1,7 +1,6 @@
 ---
 name: phase-design
-description: >
-  MORPH-SPEC Phase 2 (Design). Expands the approved proposal into spec.md, contracts.cs, decisions.md, and schema-analysis.md. Called by /morph-proposal after setup completes.
+description: MORPH-SPEC Phase 2 (Design). Analyzes codebase/schema, then produces spec.md, contracts-level{N}.cs, schema-analysis.md, and decisions.md for the feature. Use after setup phase to create a full technical specification with C# contracts based on the real database schema and architecture decision records.
 argument-hint: "[feature-name]"
 user-invocable: false
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
@@ -21,8 +20,9 @@ Expanda a proposta em especificação técnica completa, contracts, decisões ar
 
 ## Ferramentas Recomendadas
 
-> **Ref:** `framework/skills/level-0-meta/tool-usage-guide.md` para guia completo.
+> **Ref:** `framework/skills/level-0-meta/tool-usage-guide/SKILL.md` para guia completo.
 > **Ref:** `framework/standards/integration/mcp/mcp-tools.md` para referência MCP.
+> **Example:** `references/spec-example.md` — filled-in spec.md showing expected output quality.
 
 | Ação | Ferramenta | Alternativa |
 |------|------------|-------------|
@@ -35,7 +35,7 @@ Expanda a proposta em especificação técnica completa, contracts, decisões ar
 | Ler arquivos de query/tipos (fallback) | **Read** cada arquivo encontrado | — |
 | Pesquisar biblioteca para ADR | **Context7 MCP** `query_docs()` | **WebSearch** + **WebFetch** |
 | Buscar padrões no código | **GitHub MCP** `search_code()` | **Grep** padrões no projeto |
-| Renderizar template contracts.cs | **Bash** `npx morph-spec template render code/dotnet/contracts/contracts.cs ...` | — |
+| Renderizar template contracts (nível detectado) | **Bash** `npx morph-spec template render code/dotnet/contracts/contracts-level{N}.cs ...` onde N = nível detectado no Passo 1.5 | — |
 | Renderizar template spec.md | **Bash** `npx morph-spec template render docs/spec ...` | — |
 | Renderizar template decisions.md | **Bash** `npx morph-spec template render docs/decisions ...` | — |
 | Criar schema-analysis.md | **Write** no diretório de outputs | — |
@@ -47,7 +47,7 @@ Expanda a proposta em especificação técnica completa, contracts, decisões ar
 - ❌ Adivinhar nomes de campos sem verificar schema (use MCP ou Grep primeiro!)
 - ❌ Task agent para ler um único arquivo spec (use Read direto)
 - ❌ WebSearch para schema do banco (use Supabase MCP ou análise de código)
-- ❌ Escrever contracts.cs do zero (use template render)
+- ❌ Escrever contracts-level{N}.cs do zero (use template render)
 
 ---
 
@@ -71,199 +71,63 @@ Parse o JSON para obter `activeAgents`, então use standards context (já carreg
 
 **Use standards context ao gerar spec.md:**
 - Architecture standards → guiam Technical Architecture section
-- Coding standards → definem contracts.cs patterns
+- Coding standards → definem contracts-level{N}.cs patterns
 - Azure standards → determinam Infrastructure Requirements
 
-### Passo 2: Analisar Código Existente (CRÍTICO - FAZER ANTES DE CONTRACTS!)
-
-**⚠️ ATENÇÃO:** Este passo é OBRIGATÓRIO antes de gerar `contracts.cs`. Previne geração de DTOs com nomes de campos errados.
-
-#### 2.1. Detectar Se Análise É Necessária
-
-A análise de código é necessária se:
-- Feature interage com banco de dados existente
-- Feature usa APIs ou serviços existentes
-- Projeto tem código frontend/backend que será integrado
-
-**Pule este passo apenas se:**
-- Feature é 100% nova (sem dependências em código existente)
-- Não há banco de dados ou APIs envolvidas
-
-#### 2.2. Tentar MCP Tools Primeiro (Preferencial)
-
-**Se MCP Supabase disponível:**
+### Passo 1.5: Detectar Nível de Domínio (domain-architect)
 
-```javascript
-// Verificar se MCP está disponível (procure por ferramentas mcp__supabase__*)
-// Se disponível, use para obter schema real:
+**⚠️ OBRIGATÓRIO:** Execute antes de gerar qualquer contrato.
 
-// 1. Listar todas as tabelas
-await mcp__supabase__list_tables();
+**Ref:** `framework/standards/architecture/ddd/complexity-levels.md`
 
-// 2. Para cada tabela relevante, obter schema completo
-await mcp__supabase__get_table_schema({ table: 'leads' });
-await mcp__supabase__get_table_schema({ table: 'users' });
+O `domain-architect` analisa a `proposal.md` e responde às seguintes perguntas:
 
-// 3. Obter relacionamentos
-await mcp__supabase__get_relationships({ table: 'leads' });
-
-// 4. Documentar findings em SCHEMA-ANALYSIS.md
 ```
-
-**Se MCP Database/ORM disponível:**
-- Use ferramentas MCP equivalentes para PostgreSQL, MySQL, EF Core, etc.
-- Obtenha schema diretamente do banco
-
-#### 2.3. Fallback: Análise Manual de Código
-
-**Se MCP não disponível, use análise estática:**
-
-**Passo A: Encontrar Queries no Código**
-
-```bash
-# Use Grep tool para encontrar todas as queries:
-pattern: "\.from\(|\.select\(|SELECT |supabase\.|context\.|dbContext\.|ef\.Database\."
-type: "ts,tsx,js,jsx,cs"
-output_mode: "files_with_matches"
-```
-
-**Passo B: Ler Arquivos de Query**
-
-Para cada arquivo encontrado, use Read tool para extrair:
-- **Nomes de tabelas:** `from('leads')`, `DbSet<Lead>`, `FROM leads`
-- **Nomes de colunas:** `.select('fullname, phonenumber')`, `l.FullName`, `SELECT full_name`
-- **Tipos de dados:** TypeScript interfaces, C# DTOs, column types
-- **Relacionamentos:** JOIN clauses, navigation properties, foreign keys
-
-**Passo C: Encontrar Type Definitions**
-
-```bash
-# TypeScript/JavaScript projects:
-Glob: "src/**/types/**/*.ts"
-Glob: "src/**/*.d.ts"
-Glob: "src/**/interfaces/*.ts"
-
-# .NET projects:
-Glob: "**/*Dto.cs"
-Glob: "**/Entities/**/*.cs"
-Glob: "**/Models/**/*.cs"
+1. A entidade principal tem estados com transições? (Draft → Confirmed → Shipped)
+2. Existem invariants de negócio? ("só cancela se estiver Ativo")
+3. Cálculos derivados existem? (Total, Saldo, Desconto)
+4. Outros módulos precisam reagir a mudanças? (Domain Events com consumidores)
+5. O usuário declarou explicitamente Bounded Context na proposta?
+
+→ Nenhuma acima: Nível 1 (CRUD)
+→ 1-4 verdadeiros: Nível 2 (Business Logic)
+→ 5 verdadeiro OU múltiplos domínios com modelos conflitantes: Nível 3 (BC)
 ```
 
-Leia cada arquivo e mapeie:
-- Interface/Type → Database Table
-- Property names → Column names
-- Data types → SQL types
-
-**Passo D: Inferir Schema Real**
-
-Com base nos arquivos lidos, criar um mapa:
-
-```markdown
-| Frontend/Code | Database | Type | Notes |
-|--------------|----------|------|-------|
-| user.name | users.fullname | string | MISMATCH! |
-| lead.phone | leads.phonenumber | string | MISMATCH! |
-| order.metadata | orders.metadata | JSONB | Complex type |
-| user.orders | users → orders (1:N) | relation | Foreign key: orders.user_id |
-```
+**Documente no spec.md** (seção `## Domain Complexity`) antes de continuar para o Passo 3.
 
-#### 2.4. Criar SCHEMA-ANALYSIS.md
+**Template a usar no Passo 4 (contracts-level{N}.cs):**
 
-Documente os findings em `.morph/features/$ARGUMENTS/1-design/schema-analysis.md`:
+| Nível | Template |
+|-------|----------|
+| 1 | `code/dotnet/contracts/contracts-level1.cs` |
+| 2 | `code/dotnet/contracts/contracts-level2.cs` |
+| 3 | `code/dotnet/contracts/contracts-level3.cs` |
 
-```markdown
-# Schema Analysis - {Feature Name}
-
-**Date:** {DATE}
-**Method:** {MCP Supabase / Manual Code Analysis}
-
-## Tables Analyzed
-
-### Table: leads
-
-**Source:**
-- MCP: supabase.list_tables()
-- Code: src/lib/database/queries.ts
-
-**Columns:**
-| Column Name | Type | Nullable | Default | Notes |
-|------------|------|----------|---------|-------|
-| id | uuid | NO | gen_random_uuid() | Primary key |
-| fullname | varchar(255) | NO | - | NOT 'name'! |
-| phonenumber | varchar(20) | YES | - | NOT 'phone'! |
-| metadata | jsonb | YES | {} | Complex object |
-| created_at | timestamptz | NO | now() | Auto-generated |
-| user_id | uuid | YES | - | FK to users table |
-
-**Relationships:**
-- leads.user_id → users.id (N:1)
-- leads.id ← roulette_spins.lead_id (1:N)
-
-**Indexes:**
-- PRIMARY KEY (id)
-- INDEX idx_leads_user_id ON (user_id)
-
-### Table: users
-{Repetir para cada tabela}
-
-## ⚠️ CRITICAL FINDINGS
-
-**Field Name Mismatches (MUST FIX):**
-- ❌ Use `fullname`, NOT `name` (column doesn't exist!)
-- ❌ Use `phonenumber`, NOT `phone` (column doesn't exist!)
-
-**Type Mismatches:**
-- ⚠️ `metadata` is JSONB, not `Record<string, string>` (use proper type)
-
-**Relationship Corrections:**
-- ✅ Lead → User is N:1 (NOT 1:1)
-- ✅ Lead → RouletteSpins is 1:N (NOT 1:1)
-
-## Recommendations for contracts.cs
-
-Based on real schema, DTOs should use:
-\`\`\`csharp
-public record LeadDto(
-    Guid Id,
-    string Fullname,        // NOT 'Name'!
-    string? Phonenumber,    // NOT 'Phone'! Nullable!
-    JsonObject? Metadata,   // NOT Record<string,string>!
-    Guid? UserId,           // Nullable FK
-    DateTime CreatedAt
-);
-\`\`\`
-```
+**Para Nível 2+:** Preencha o `## Aggregate Blueprint` no spec.md antes de gerar contracts-level{N}.cs.
 
-#### 2.5. CHECKPOINT OBRIGATÓRIO: Revisar Schema Analysis
+**Para Nível 3:** Adicione `BOUNDED_CONTEXT` como variável ao renderizar o template.
 
-**⏸️ PAUSE - Validar findings antes de continuar:**
+---
 
-Apresente ao usuário:
-- [ ] Analisei {N} arquivos de código
-- [ ] Identifiquei {N} tabelas: {lista}
-- [ ] Encontrei {N} field name mismatches
-- [ ] Encontrei {N} type mismatches
-- [ ] Mapeei {N} relacionamentos
-- [ ] Criei `schema-analysis.md` com todos os findings
+### Passo 2: Analisar Código Existente (CRÍTICO - FAZER ANTES DE CONTRACTS!)
 
-**Perguntas ao usuário:**
-1. "O schema analysis está correto?"
-2. "Encontrei field mismatches (fullname vs name). Confirma?"
-3. "Posso prosseguir para gerar contracts.cs com base nesse schema real?"
+**⚠️ ATENÇÃO:** Este passo é OBRIGATÓRIO antes de gerar `contracts-level{N}.cs`. Previne geração de DTOs com nomes de campos errados.
 
-**❌ Se usuário responder "Não" ou encontrar erros:**
-→ VOLTAR e revisar análise
-→ Corrigir schema-analysis.md
-→ Re-apresentar para aprovação
+**Delegate para skill dedicada:**
 
-**✅ Se usuário aprovar:**
-→ Prosseguir para Passo 3 (Gerar spec.md)
+> **Ref:** `framework/skills/level-1-workflows/phase-codebase-analysis/SKILL.md` — workflow completo de análise de schema (MCP Supabase → fallback análise estática → SCHEMA-ANALYSIS.md → checkpoint de aprovação)
 
-#### 2.6. Atualizar State
+Execute o workflow de `phase-codebase-analysis.md` para:
+1. Detectar se análise é necessária
+2. Tentar MCP Supabase (preferencial) ou análise estática (fallback)
+3. Mapear field name mismatches e type mismatches
+4. Gerar `schema-analysis.md` com findings reais
+5. Apresentar checkpoint ao usuário e aguardar aprovação
 
-```bash
-npx morph-spec state mark-output $ARGUMENTS schema-analysis
-```
+**Pule se:**
+- Feature é 100% nova (sem dependências em código existente)
+- Não há banco de dados ou APIs envolvidas
 
 ### Passo 3: Gerar `spec.md`
 
@@ -311,7 +175,7 @@ Se houver recursos Azure:
 
 **SEMPRE usar Bicep para infra!**
 
-### Passo 4: Gerar `contracts.cs` (BASEADO NO SCHEMA REAL!)
+### Passo 4: Gerar `contracts-level{N}.cs` (BASEADO NO SCHEMA REAL!)
 
 **⚠️ IMPORTANTE:** Use `schema-analysis.md` (do Passo 2) para gerar DTOs corretos!
 
@@ -320,7 +184,7 @@ Se houver recursos Azure:
 ```bash
 # Use o template de contracts com dados do schema-analysis.md:
 npx morph-spec template render \
-  code/dotnet/contracts/contracts.cs \
+  code/dotnet/contracts/contracts-level{N}.cs \
   .morph/features/$ARGUMENTS/1-design/contracts.cs \
   '{
     "FEATURE_NAME": "$ARGUMENTS",
@@ -336,7 +200,7 @@ npx morph-spec template render \
 
 ```bash
 # Leia o template base:
-Read: .morph/framework/templates/code/dotnet/contracts/contracts.cs.hbs
+Read: .morph/framework/templates/code/dotnet/contracts/contracts-level{N}.cs.hbs
 
 # Preencha manualmente usando dados de schema-analysis.md
 # Template contém placeholders para:
@@ -440,7 +304,7 @@ Apresente ao usuário 3 ações sugeridas:
 ## Critérios de Avanço
 
 - [x] `spec.md` completo com todos os requisitos
-- [x] `contracts.cs` com interfaces e DTOs
+- [x] `contracts-level{N}.cs` com interfaces e DTOs
 - [x] `decisions.md` com ADRs relevantes
 - [x] Custos estimados e documentados (se houver infra)
 - [x] State atualizado

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

@@ -0,0 +1,253 @@
+# Feature Specification: Photo Processing Pipeline
+
+> Example of a well-structured spec.md. This is a filled-in reference — not a template.
+
+| Field | Value |
+|-------|-------|
+| **ID** | photo-processing |
+| **Status** | Approved |
+| **Created** | 2025-01-15 |
+| **Stack** | blazor-azure |
+| **Complexity** | Medium |
+| **Estimated Cost** | ~$5.50/month |
+| **Agents** | Core: All / Specialists: azure-architect, dotnet-senior, blazor-builder |
+
+---
+
+## Overview
+
+**Problem:** Users cannot submit photos for AI transformation — the core product value proposition is blocked.
+
+**Solution:** End-to-end pipeline: upload → Blob Storage → Hangfire background job → AI processing → download link.
+
+**Success Criteria:**
+- [ ] Upload endpoint accepts .jpg/.png up to 10MB and stores in Azure Blob
+- [ ] Background job processes photo and updates status to Completed within 120s (p95)
+- [ ] Status polling page reflects real-time processing progress
+- [ ] Failed jobs retry up to 3 times with exponential backoff
+
+---
+
+## Requirements
+
+**Functional:**
+FR1: Upload photo (.jpg/.png, max 10MB) via Blazor form
+FR2: Store photo in Azure Blob Storage under `uploads/{jobId}`
+FR3: Enqueue Hangfire background job for AI processing
+FR4: Status polling endpoint returns `{ status, progress, createdAt }`
+FR5: Download endpoint redirects to Blob URL for completed jobs
+
+**Non-Functional:**
+NFR1: Processing time < 120s for p95 of requests
+NFR2: Upload endpoint < 2s response time
+NFR3: Retry 3x on AI API failure with 5s/30s/120s backoff
+
+---
+
+## User Stories
+
+### US001: Upload Photo
+**As** an authenticated user **I want** to upload a photo **so that** the AI can transform it.
+
+**Acceptance Criteria:**
+1. Accepts .jpg and .png files only — rejects other formats with clear error
+2. Rejects files larger than 10MB with a specific error message
+3. Returns a `jobId` and redirects to `/processing/{jobId}` on success
+
+**Edge Cases:**
+- Network timeout during upload: show retry button
+- Duplicate upload: create new job each time (idempotency not required)
+
+### US002: Track Progress
+**As** a user who uploaded a photo **I want** to see real-time status **so that** I know when my photo is ready.
+
+**Acceptance Criteria:**
+1. Page polls `/api/status/{jobId}` every 5 seconds
+2. Shows status label: Pending / Processing / Completed / Failed
+3. Shows "Download" button when status = Completed
+
+---
+
+## Technical Design
+
+### Stack
+
+| Component | Technology |
+|-----------|------------|
+| Frontend | Blazor Server |
+| Backend | .NET 10 / C# 14 Minimal API |
+| Background Jobs | Hangfire (self-hosted) |
+| Storage | Azure Blob Storage (LRS) |
+| Database | Azure SQL |
+
+### Data Model
+
+#### ProcessingJob
+
+| Column | Type | Constraints |
+|--------|------|-------------|
+| Id | Guid | PK, default NEWID() |
+| OriginalPhotoUrl | nvarchar(500) | NOT NULL |
+| ProcessedPhotoUrl | nvarchar(500) | NULL (populated after processing) |
+| Status | int | NOT NULL, default 0 (Pending) |
+| ErrorMessage | nvarchar(1000) | NULL |
+| RetryCount | int | NOT NULL, default 0 |
+| CreatedAt | datetime2 | NOT NULL, default GETUTCDATE() |
+| UpdatedAt | datetime2 | NOT NULL |
+
+#### ProcessingStatus Enum
+
+```csharp
+public enum ProcessingStatus
+{
+    Pending = 0,
+    Processing = 1,
+    Completed = 2,
+    Failed = 100
+}
+```
+
+### Contracts
+
+```csharp
+// Commands
+public record UploadPhotoCommand(IFormFile Photo, string? Email);
+public record UploadPhotoResult(Guid JobId);
+
+// Queries
+public record GetJobStatusQuery(Guid JobId);
+public record JobStatusDto(Guid JobId, ProcessingStatus Status, string? ProcessedPhotoUrl, DateTime CreatedAt);
+
+// Service Interface
+public interface IPhotoProcessingService
+{
+    Task<UploadPhotoResult> UploadAsync(UploadPhotoCommand command, CancellationToken ct);
+    Task<JobStatusDto> GetStatusAsync(GetJobStatusQuery query, CancellationToken ct);
+}
+
+// Hangfire Job
+public interface IPhotoProcessingJob
+{
+    Task ProcessAsync(Guid jobId, CancellationToken ct);
+}
+```
+
+---
+
+## UI/UX Design
+
+### Upload Page (/upload)
+
+```
+┌─────────────────────────────────────┐
+│  Upload Photo                        │
+│  ─────────────────────────────────  │
+│  [📁 Select File] photo.jpg (2.3MB)  │
+│                                      │
+│  Allowed: JPG, PNG — Max: 10MB       │
+│                                      │
+│             [Upload →]               │
+│                                      │
+│  Error state:                        │
+│  ⚠ File too large. Max size is 10MB. │
+└─────────────────────────────────────┘
+```
+
+### Status Page (/processing/{jobId})
+
+```
+┌─────────────────────────────────────┐
+│  Processing your photo               │
+│  ─────────────────────────────────  │
+│  Status: ⏳ Processing               │
+│  ████████░░░░░░░  60%               │
+│                                      │
+│  Started: 2025-01-15 14:32:01        │
+│                                      │
+│  [Completed state]:                  │
+│  Status: ✅ Done!                    │
+│            [📥 Download]             │
+└─────────────────────────────────────┘
+```
+
+---
+
+## Flows
+
+### Upload Flow
+**Trigger:** User submits photo form
+
+1. User selects file → client validates type/size before submit
+2. `POST /api/upload` — server validates, uploads to Blob at `uploads/{jobId}/original.jpg`
+3. Create `ProcessingJob` entity (status = Pending)
+4. Enqueue Hangfire job with `jobId`
+5. Return `{ jobId }` → client redirects to `/processing/{jobId}`
+
+**End State:** Job queued, user on status page
+
+### Processing Flow
+**Trigger:** Hangfire executes job
+
+1. Load `ProcessingJob` by Id, set status = Processing
+2. Download original from Blob Storage
+3. Call AI API (`POST /transform`, multipart/form-data)
+4. On success: upload result to `uploads/{jobId}/processed.jpg`, set status = Completed
+5. On failure: increment RetryCount, set status = Failed if RetryCount >= 3
+
+**End State:** Job = Completed (photo available) or Failed (user sees error)
+
+---
+
+## Cost Estimate
+
+| Resource | SKU | Monthly | Justification |
+|----------|-----|---------|---------------|
+| Blob Storage | LRS | $0.02 | ~500 photos/month × 2 files × avg 3MB |
+| Azure SQL | Basic | $4.99 | < 100k jobs/month |
+| Container App | Consumption | $0.49 | Scale to zero when idle |
+| Hangfire | Self-hosted | $0.00 | In-process with Container App |
+| **Total** | | **~$5.50** | |
+
+---
+
+## ADRs
+
+### ADR-001: Hangfire over Azure Functions for Background Processing
+**Status:** Accepted
+**Context:** Need async processing for AI photo transformation (30–120s duration).
+**Decision:** Hangfire (self-hosted in Container App)
+**Alternatives:**
+1. Azure Functions — serverless, auto-scaling, but cold start latency + $10/mo for 50k executions
+2. Quartz.NET — more features (CRON, clustering), steeper learning curve
+**Trade-offs:** Simplicity + zero cost vs scalability (Hangfire sufficient for MVP < 10k/month)
+
+### ADR-002: Polling over WebSockets for Status Updates
+**Status:** Accepted
+**Context:** Users need real-time feedback; SSE/WebSocket adds Blazor Hub complexity.
+**Decision:** 5-second HTTP polling from Blazor component
+**Trade-offs:** Slightly higher server load vs significantly simpler implementation; polling sufficient at MVP scale
+
+---
+
+## Security
+
+| Action | Required Policy |
+|--------|-----------------|
+| Upload | Authenticated user |
+| View status | Owner of job (check UserId) |
+| Download | Owner of job (check UserId) |
+
+---
+
+## Definition of Done
+
+- [ ] Upload endpoint working, validated with unit + integration tests
+- [ ] Hangfire job processes photos end-to-end in dev environment
+- [ ] Status page shows correct states (Pending/Processing/Completed/Failed)
+- [ ] Code review approved
+- [ ] Deployed to staging environment
+- [ ] `recap.md` generated with implementation notes
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-1-workflows/{phase-implement.md → phase-implement/SKILL.md}

@@ -1,7 +1,6 @@
 ---
 name: phase-implement
-description: >
-  MORPH-SPEC Phase 5 (Implement). Executes tasks.md task-by-task with checkpoint validation every 3 tasks, producing code and recap.md. Called by /morph-apply.
+description: MORPH-SPEC Phase 5 (Implement). Executes feature tasks using TDD with checkpoint validation every 3 tasks, smoke tests via Playwright, and generates code + recap.md. Use after task list approval when starting feature implementation.
 argument-hint: "[feature-name]"
 disable-model-invocation: true
 context: fork
@@ -25,8 +24,9 @@ Implemente as tasks definidas na FASE 4, com checkpoints a cada 3 tasks e recap
 
 ## Ferramentas Recomendadas
 
-> **Ref:** `framework/skills/level-0-meta/tool-usage-guide.md` para guia completo.
+> **Ref:** `framework/skills/level-0-meta/tool-usage-guide/SKILL.md` para guia completo.
 > **Ref:** `framework/standards/integration/mcp/mcp-tools.md` para referência MCP.
+> **Example:** `references/recap-example.md` — filled-in recap.md showing expected output quality.
 
 | Ação | Ferramenta | Alternativa |
 |------|------------|-------------|