@polymorphism-tech/morph-spec 4.9.0 → 4.10.1

package/framework/commands/commit.md

@@ -0,0 +1,166 @@
+---
+allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*)
+argument-hint: [message] | --no-verify | --amend
+description: Create well-formatted commits with conventional commit format and emoji
+---
+
+# Smart Git Commit
+
+Create well-formatted commit: $ARGUMENTS
+
+## Current Repository State
+
+- Git status: !git status --porcelain
+- Current branch: !git branch --show-current
+- Staged changes: !git diff --cached --stat
+- Unstaged changes: !git diff --stat
+- Recent commits: !git log --oneline -5
+
+## What This Command Does
+
+1. Unless specified with --no-verify, automatically runs pre-commit checks:
+   - pnpm lint to ensure code quality
+   - pnpm build to verify the build succeeds
+   - pnpm generate:docs to update documentation
+2. Checks which files are staged with git status
+3. If 0 files are staged, automatically adds all modified and new files with git add
+4. Performs a git diff to understand what changes are being committed
+5. Analyzes the diff to determine if multiple distinct logical changes are present
+6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
+7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
+
+## Best Practices for Commits
+
+- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
+- **Atomic commits**: Each commit should contain related changes that serve a single purpose
+- **Split large changes**: If changes touch multiple concerns, split them into separate commits
+- **Conventional commit format**: Use the format <type>: <description> where type is one of:
+  - feat: A new feature
+  - fix: A bug fix
+  - docs: Documentation changes
+  - style: Code style changes (formatting, etc)
+  - refactor: Code changes that neither fix bugs nor add features
+  - perf: Performance improvements
+  - test: Adding or fixing tests
+  - chore: Changes to the build process, tools, etc.
+- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
+- **Concise first line**: Keep the first line under 72 characters
+- **Emoji**: Each commit type is paired with an appropriate emoji:
+  - ✨ feat: New feature
+  - 🐛 fix: Bug fix
+  - 📝 docs: Documentation
+  - 💄 style: Formatting/style
+  - ♻️ refactor: Code refactoring
+  - ⚡️ perf: Performance improvements
+  - ✅ test: Tests
+  - 🔧 chore: Tooling, configuration
+  - 🚀 ci: CI/CD improvements
+  - 🗑️ revert: Reverting changes
+  - 🧪 test: Add a failing test
+  - 🚨 fix: Fix compiler/linter warnings
+  - 🔒️ fix: Fix security issues
+  - 👥 chore: Add or update contributors
+  - 🚚 refactor: Move or rename resources
+  - 🏗️ refactor: Make architectural changes
+  - 🔀 chore: Merge branches
+  - 📦️ chore: Add or update compiled files or packages
+  - ➕ chore: Add a dependency
+  - ➖ chore: Remove a dependency
+  - 🌱 chore: Add or update seed files
+  - 🧑‍💻 chore: Improve developer experience
+  - 🧵 feat: Add or update code related to multithreading or concurrency
+  - 🔍️ feat: Improve SEO
+  - 🏷️ feat: Add or update types
+  - 💬 feat: Add or update text and literals
+  - 🌐 feat: Internationalization and localization
+  - 👔 feat: Add or update business logic
+  - 📱 feat: Work on responsive design
+  - 🚸 feat: Improve user experience / usability
+  - 🩹 fix: Simple fix for a non-critical issue
+  - 🥅 fix: Catch errors
+  - 👽️ fix: Update code due to external API changes
+  - 🔥 fix: Remove code or files
+  - 🎨 style: Improve structure/format of the code
+  - 🚑️ fix: Critical hotfix
+  - 🎉 chore: Begin a project
+  - 🔖 chore: Release/Version tags
+  - 🚧 wip: Work in progress
+  - 💚 fix: Fix CI build
+  - 📌 chore: Pin dependencies to specific versions
+  - 👷 ci: Add or update CI build system
+  - 📈 feat: Add or update analytics or tracking code
+  - ✏️ fix: Fix typos
+  - ⏪️ revert: Revert changes
+  - 📄 chore: Add or update license
+  - 💥 feat: Introduce breaking changes
+  - 🍱 assets: Add or update assets
+  - ♿️ feat: Improve accessibility
+  - 💡 docs: Add or update comments in source code
+  - 🗃️ db: Perform database related changes
+  - 🔊 feat: Add or update logs
+  - 🔇 fix: Remove logs
+  - 🤡 test: Mock things
+  - 🥚 feat: Add or update an easter egg
+  - 🙈 chore: Add or update .gitignore file
+  - 📸 test: Add or update snapshots
+  - ⚗️ experiment: Perform experiments
+  - 🚩 feat: Add, update, or remove feature flags
+  - 💫 ui: Add or update animations and transitions
+  - ⚰️ refactor: Remove dead code
+  - 🦺 feat: Add or update code related to validation
+  - ✈️ feat: Improve offline support
+
+## Guidelines for Splitting Commits
+
+When analyzing the diff, consider splitting commits based on these criteria:
+
+1. **Different concerns**: Changes to unrelated parts of the codebase
+2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
+3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
+4. **Logical grouping**: Changes that would be easier to understand or review separately
+5. **Size**: Very large changes that would be clearer if broken down
+
+## Examples
+
+Good commit messages:
+- ✨ feat: add user authentication system
+- 🐛 fix: resolve memory leak in rendering process
+- 📝 docs: update API documentation with new endpoints
+- ♻️ refactor: simplify error handling logic in parser
+- 🚨 fix: resolve linter warnings in component files
+- 🧑‍💻 chore: improve developer tooling setup process
+- 👔 feat: implement business logic for transaction validation
+- 🩹 fix: address minor styling inconsistency in header
+- 🚑️ fix: patch critical security vulnerability in auth flow
+- 🎨 style: reorganize component structure for better readability
+- 🔥 fix: remove deprecated legacy code
+- 🦺 feat: add input validation for user registration form
+- 💚 fix: resolve failing CI pipeline tests
+- 📈 feat: implement analytics tracking for user engagement
+- 🔒️ fix: strengthen authentication password requirements
+- ♿️ feat: improve form accessibility for screen readers
+
+Example of splitting commits:
+- First commit: ✨ feat: add new solc version type definitions
+- Second commit: 📝 docs: update documentation for new solc versions
+- Third commit: 🔧 chore: update package.json dependencies
+- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
+- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
+- Sixth commit: 🚨 fix: resolve linting issues in new code
+- Seventh commit: ✅ test: add unit tests for new solc version features
+- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
+
+## Command Options
+
+- --no-verify: Skip running the pre-commit checks (lint, build, generate:docs)
+
+## Important Notes
+
+- By default, pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs) will run to ensure code quality
+- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
+- If specific files are already staged, the command will only commit those files
+- If no files are staged, it will automatically stage all modified and new files
+- The commit message will be constructed based on the changes detected
+- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
+- If suggesting multiple commits, it will help you stage and commit the changes separately
+- Always reviews the commit diff to ensure the message matches the changes

package/framework/commands/morph-apply.md

@@ -1,220 +1,221 @@
-# Apply MORPH Feature Implementation - FASE 5
+---
+description: Implement the specified feature following the task breakdown from the MORPH-SPEC workflow. Orchestrates task execution with state tracking, checkpoints, agent dispatch, and verification.
+argument-hint: <feature-name>
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion
+---
 
-Implemente a feature especificada seguindo as tasks definidas.
+# /morph-apply — Feature Implementation
 
-## Uso
+Implement the feature by executing its task breakdown, tracking progress through the morph-spec state machine, and producing a recap at the end.
+
+## Usage
 
 ```
 /morph-apply {feature-name}
 ```
 
-## Pré-requisitos
+## Recommended Tools
+
+> **Ref:** `framework/skills/level-0-meta/morph-tool-usage-guide/SKILL.md` for complete guide.
+> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` for MCP reference.
+
+| Action | Tool | Alternative |
+|--------|------|-------------|
+| Read spec, tasks, contracts | **Read** all outputs | — |
+| Detect architecture style | **Bash** `cat .morph/config/config.json \| grep architecture` | — |
+| Agent dispatch config | **Bash** `npx morph-spec dispatch-agents $ARGUMENTS implement` | — |
+| Parallel task execution | **Agent** subagent per task group | Sequential fallback |
+| Look up implementation patterns | **Context7 MCP** `query_docs()` | **WebSearch** |
+| Track progress | **Bash** `npx morph-spec state get $ARGUMENTS` | — |
+
+---
 
-### CRÍTICO: Validar Fases Anteriores
+## Pre-flight Validation
 
-**SEMPRE verifique que fases anteriores foram concluídas:**
+Before writing any code, verify all prior phases are complete. This gate prevents implementation from starting with missing specs, unapproved designs, or incomplete task breakdowns.
+
+### 1. Check state and approvals
 
 ```bash
-# Obter estado da feature
-npx morph-spec state get {feature-name}
+npx morph-spec state get $ARGUMENTS
+npx morph-spec approval-status $ARGUMENTS
+npx morph-spec validate-feature $ARGUMENTS
 ```
 
-**Validações obrigatórias:**
+**All three must pass.** If any fails:
 
-1. **FASE 0 (Proposal):**
-   - [ ] Output `proposal` criado
-   - [ ] Agentes detectados e registrados
+```
+Feature is not ready for implementation.
+Run /morph-proposal $ARGUMENTS to complete planning phases.
+(Resumes automatically from the current phase.)
+```
 
-2. **FASE 1 (Setup):**
-   - [ ] Phase passou por "setup"
-   - [ ] Contexto carregado
+Do NOT proceed until all phases are complete and all gates approved.
 
-3. **FASE 1.5 (UI/UX) - SE APLICÁVEL:**
-   - [ ] Se `uiux-designer` está nos activeAgents → outputs ui-* devem existir
-   - [ ] Se NÃO tem uiux-designer → pode pular
+### 2. Load context in PARALLEL
 
-4. **FASE 2 (Design):**
-   - [ ] Output `spec` criado
-   - [ ] Output `contracts` criado
-   - [ ] Output `decisions` criado
+Read all prerequisite files in a single parallel call — every file listed here matters for implementation quality:
 
-5. **FASE 3 (Clarify):**
-   - [ ] Phase passou por "clarify"
-   - [ ] Spec atualizado com clarificações
+```
+Read: .morph/features/$ARGUMENTS/1-design/spec.md              (→ functional requirements, API contracts)
+    + Read: .morph/features/$ARGUMENTS/1-design/contracts.cs    (or contracts.ts / contracts-vsa.cs → C# interfaces)
+    + Read: .morph/features/$ARGUMENTS/1-design/decisions.md    (→ ADRs, architectural choices)
+    + Read: .morph/features/$ARGUMENTS/3-plan/plan.md           (→ TDD structure, execution strategy)
+    + Read: .morph/features/$ARGUMENTS/4-tasks/tasks.md         (→ task breakdown with T### IDs)
+    + Read: .morph/config/config.json                           (→ architecture.style for VSA routing)
+```
 
-6. **FASE 4 (Tasks):**
-   - [ ] Output `tasks` criado
-   - [ ] `tasks.json` tem array de tasks
-   - [ ] `tasks.total` > 0 no state
+**For VSA projects** (`architecture.style: "vertical-slice"`), also read:
+```
+Read: framework/standards/architecture/vertical-slice/vertical-slice.md
+```
+This contains the 9 VSA implementation rules (Handler+Validator+Endpoint per feature folder, no cross-feature imports, etc.).
+
+Also read relevant standards:
+- `framework/standards/` — coding standards for the detected stack
+- `.morph/context/` — project-specific patterns and conventions
+
+### 3. Detect architecture style
 
-**Se QUALQUER validação falhar:**
+```bash
+cat .morph/config/config.json | grep -A3 '"architecture"'
 ```
-❌ ERRO: Fase {X} não foi concluída!
 
-Para completar as fases de planejamento, execute:
-/morph-proposal {feature-name}
-(Resume automaticamente da fase atual: {current_phase})
+- **`"vertical-slice"`** → follow VSA implementation patterns from `framework/standards/architecture/vertical-slice/vertical-slice.md`. Each task is a complete slice (Handler + Validator + Endpoint in one folder).
+- **Otherwise** → follow DDD/Clean Architecture patterns. Tasks map to domain layers.
+
+### 4. Get agent dispatch config
+
+```bash
+npx morph-spec dispatch-agents $ARGUMENTS implement --table
 ```
 
-**NÃO prossiga com implementação até todas as fases estarem completas!**
+This shows which agents are active for implementation and how tasks can be grouped. If agent teams are enabled and tasks have no dependencies between groups, consider dispatching parallel agents:
+
+```bash
+npx morph-spec dispatch-agents $ARGUMENTS implement
+```
 
-### Arquivos Necessários
+The JSON output includes `shouldDispatch`, `agents[]`, and `taskGroups` for multi-agent coordination.
 
-- [ ] Feature existe em `.morph/features/{feature}/`
-- [ ] `spec.md` está aprovado
-- [ ] `tasks.json` tem tasks definidas
-- [ ] `contracts.cs` define as interfaces
+---
 
 ## Workflow
 
-1. **Carregue o contexto**:
-   - Leia `.morph/features/{feature}/1-design/spec.md`
-   - Leia `.morph/features/{feature}/3-tasks/tasks.md`
-   - Leia `.morph/features/{feature}/1-design/contracts.cs`
-   - Leia framework/standards/ e .morph/context/ para padrões
-
-2. **Inicialize state tracking**:
-   ```bash
-   # Atualizar fase para implement
-   npx morph-spec state set {feature} phase implement
-   npx morph-spec state set {feature} status in_progress
-
-   # Definir total de tasks (baseado em tasks.json)
-   npx morph-spec state set {feature} tasks.total {N}
-   ```
-
-3. **Execute tasks em ordem**:
-   - Marque task como in progress: `npx morph-spec task start {feature} {task-id}`
-   - Implemente seguindo os padrões e contracts.cs
-   - Complete task: `npx morph-spec task done {feature} {task-id}`
-   - **Validators run automatically** on task-done. If validation fails:
-     - Read the error messages and fix violations
-     - Re-run `task done` — do NOT use `--skip-validation` unless user authorizes
-   - Framework auto-manages checkpoints (every 3 tasks, includes validation summary)
-
-4. **Phase advancement**:
-   ```bash
-   # Advance to next phase (validates → advances → shows next steps)
-   npx morph-spec phase advance {feature}
-   ```
-
-5. **Marcar outputs criados**:
-   Sempre que gerar um arquivo de output:
-   ```bash
-   npx morph-spec state mark-output {feature} spec
-   npx morph-spec state mark-output {feature} contracts
-   npx morph-spec state mark-output {feature} tasks
-   # etc.
-   ```
-
-6. **Ao finalizar**:
-   - Generate recap automatically: `npx morph-spec generate recap {feature}`
-   - Atualize state: `npx morph-spec state set {feature} status done`
-   - Marque recap: `npx morph-spec state mark-output {feature} recap`
-   - Liste arquivos criados/modificados
-   - Calcule custo real vs estimado
-
-## Padrões Obrigatórios
-
-Siga sempre (priorize context/ se houver):
-- `framework/standards/coding.md` - Padrões base do MORPH
-- `.morph/context/coding.md` - Padrões específicos do projeto
-- `.morph/context/architecture.md` - Estrutura de projeto
-- `.morph/context/azure.md` - Recursos e custos
+### Step 1: Advance to implement phase
 
----
+```bash
+npx morph-spec phase advance $ARGUMENTS
+```
+
+This validates phase eligibility and emits a SKILL DISPATCH block listing required skills for implementation (verification-before-completion, morph-checklist, etc.).
 
-## Checklist Pré-Deploy Azure
+### Step 2: Initialize state tracking
+
+```bash
+npx morph-spec state set $ARGUMENTS tasks.total {N}
+```
 
-**ANTES de fazer deploy para Azure, execute `/morph-preflight azure` ou verifique manualmente:**
+Where `{N}` is the number of tasks in tasks.md (e.g., 6 for T001-T006).
 
-### Packages e Build
+### Step 3: Execute tasks in order
 
-- [ ] Packages sem conflitos de versão (`dotnet restore` sem warnings NU1605/NU1608)
-- [ ] `Azure.Identity` especificado explicitamente no `.csproj`
-- [ ] Build passa sem erros (`dotnet build`)
+For each task in the breakdown, follow this cycle:
 
-### EF Core Migrations
+```bash
+# 1. Start the task (activates task-tracking guard)
+npx morph-spec task start $ARGUMENTS {task-id}
 
-- [ ] Sem pending model changes (`dotnet ef migrations has-pending-model-changes`)
-- [ ] Migration criada para todas as mudanças de schema
-- [ ] Migration script revisado (`dotnet ef migrations script --idempotent`)
+# 2. Implement the task
+#    - Follow spec.md and contracts
+#    - Follow coding standards from framework/standards/ and .morph/context/
+#    - For VSA: create all slice files in one folder (Handler + Validator + Endpoint)
+#    - For DDD: implement in the correct domain layer
 
-### Blazor .NET 10 (se aplicável)
+# 3. Verify before completing — run validate-feature or check your work
+#    matches the spec and contracts before marking done
 
-- [ ] `.csproj` contém `<RequiresAspNetWebAssets>true</RequiresAspNetWebAssets>`
-- [ ] Static assets funcionando localmente
+# 4. Complete the task (triggers Tier-4 validators automatically)
+npx morph-spec task done $ARGUMENTS {task-id}
+```
 
-### Container/Docker (se Container Apps)
+**If validation fails on `task done`:**
+- Read the error messages carefully
+- Fix the violations in your code
+- Re-run `task done` — do NOT use `--skip-validation` unless the user explicitly authorizes it
+- After 3 consecutive failures, escalate to the user
 
-- [ ] Dockerfile válido e testado localmente
-- [ ] `docker build` funciona sem erros
-- [ ] Container roda localmente (`docker run`)
+**Parallel execution (agent teams):**
+If `dispatch-agents` identified parallelizable task groups and agent teams are enabled, dispatch independent tasks to separate agents. Each agent still calls `task start` and `task done` for its assigned task.
 
-### Infraestrutura Azure
+### Step 4: Checkpoint every 3 tasks
 
-- [ ] Bicep sem erros de sintaxe (`az bicep build`)
-- [ ] Key Vault URI configurado em `appsettings.Production.json`
-- [ ] Connection strings em Key Vault (não hardcoded)
-- [ ] Managed Identity habilitada nos recursos
+After every 3 completed tasks, save a checkpoint:
 
-### Segurança
+```bash
+npx morph-spec checkpoint-save $ARGUMENTS "after-T003"
+npx morph-spec state get $ARGUMENTS
+```
 
-- [ ] Sem secrets em código ou `appsettings.json` (exceto Development)
-- [ ] HTTPS enforçado
-- [ ] CORS configurado corretamente
+Checkpoints validate architecture compliance, check package versions, scan for security issues, and save a restorable snapshot. The cadence is every 3 tasks — for 6 tasks: checkpoint after T003 and T006. For 10 tasks: after T003, T006, T009, and at completion.
 
-### Comandos de Verificação
+After each checkpoint, check progress:
 
 ```bash
-# 1. Package conflicts
-dotnet restore 2>&1 | grep -E "NU1605|NU1608"
+npx morph-spec state list
+```
 
-# 2. Pending migrations
-dotnet ef migrations has-pending-model-changes \
-  --project src/Infrastructure \
-  --startup-project src/Web
+### Step 5: Finalize implementation
 
-# 3. Bicep validation
-az bicep build --file infra/main.bicep --stdout > /dev/null
+After all tasks are complete:
 
-# 4. Docker build
-docker build -t myapp:test .
+```bash
+# Final validation
+npx morph-spec validate-feature $ARGUMENTS
 
-# 5. Secret scan (basic)
-grep -rE "(Password=|Pwd=|Secret=)" appsettings*.json | grep -v Development
-```
+# Generate recap (auto-marks 'recap' output in state)
+npx morph-spec generate recap $ARGUMENTS
 
-### Se QUALQUER item falhar
+# Verify final state
+npx morph-spec state get $ARGUMENTS
 
+# Advance to next phase
+npx morph-spec phase advance $ARGUMENTS
 ```
-❌ BLOQUEADO: Não faça deploy até resolver!
 
-Use /morph-preflight azure para diagnóstico detalhado.
-```
+### Step 6: Post-implementation review
 
-## Validações
+After implementation, present a summary to the user:
 
-Antes de marcar task como completa:
-- [ ] Código compila
-- [ ] Segue padrões de nomenclatura
-- [ ] Testes unitários (se aplicável)
-- [ ] Sem hardcoded secrets
+1. Total tasks completed (X/Y)
+2. Files created/modified
+3. Validation results
+4. Any deviations from spec
 
-## Output
+For Azure projects, remind the user: "Run `/morph-preflight` before deploying to validate packages, migrations, Docker, and secrets."
 
-Ao final de cada task, mostre:
-1. Task completada
-2. Arquivos criados/modificados
-3. Próxima task
-4. Progresso geral (X/Y tasks) - usar `npx morph-spec state get {feature}`
+---
 
-Ao final de cada checkpoint:
-```bash
-npx morph-spec state list
+## Task Output Format
+
+After each task completion, show:
+
+```
+Task {task-id} complete (X/Y tasks done)
+Files: [list of created/modified files]
+Next: {next-task-id} — {next-task-title}
 ```
 
-Isso mostra o progresso atualizado automaticamente.
+---
+
+## Anti-patterns
+
+- Using `state set phase` instead of `phase advance` — phase advance validates eligibility first
+- Skipping `task start` before implementing — the task-tracking guard will warn
+- Using `--skip-validation` without user authorization
+- Implementing without reading spec.md and contracts first
+- Writing code before `phase advance` to implement — the hook will block writes
+- Skipping checkpoints — they catch integration issues early
 
 ---
 

package/framework/commands/morph-archive.md

@@ -1,45 +1,51 @@
+---
+description: Archive a completed feature by moving from features/ to archive/ and updating state
+argument-hint: <feature-name>
+allowed-tools: Read, Write, Edit, Bash
+---
+
 # Archive MORPH Feature
 
-Arquive uma feature concluída, movendo-a de `features/` para `archive/`.
+Archive a completed feature, moving it from `features/` to `archive/`.
 
-## Pré-requisitos
+## Prerequisites
 
-Verifique antes de arquivar:
-- [ ] Feature existe em `.morph/features/{feature}/`
-- [ ] Todas as tasks estão completas
-- [ ] `recap.md` está preenchido
-- [ ] Código está em produção (ou staging)
+Verify before archiving:
+- [ ] Feature exists in `.morph/features/{feature}/`
+- [ ] All tasks are complete
+- [ ] `recap.md` is filled in
+- [ ] Code is in production (or staging)
 
 ## Workflow
 
-1. **Valide a conclusão**:
-   - Leia `.morph/features/{feature}/3-tasks/tasks.md`
-   - Verifique que todas tasks estão completadas
-   - Confirme com o usuário se pode arquivar
+1. **Validate completion**:
+   - Read `.morph/features/{feature}/4-tasks/tasks.md`
+   - Verify all tasks are completed
+   - Confirm with user before archiving
 
-2. **Complete o recap**:
-   - Atualize `.morph/features/{feature}/4-implement/recap.md`
-   - Preencha métricas finais
-   - Documente lições aprendidas
+2. **Complete the recap**:
+   - Update `.morph/features/{feature}/5-implement/recap.md`
+   - Fill in final metrics
+   - Document lessons learned
 
-3. **Extraia specs**:
-   - Se a feature define comportamento permanente
-   - Copie spec relevante para `.morph/specs/`
-   - Isso vira a "verdade atual" do sistema
+3. **Extract specs**:
+   - If the feature defines permanent behavior
+   - Copy relevant spec to `.morph/specs/`
+   - This becomes the "current truth" of the system
 
-4. **Mova para archive**:
+4. **Move to archive**:
    ```
    .morph/features/{feature}/  →  .morph/archive/{feature}/
    ```
 
-5. **Atualize métricas do projeto**:
-   - Incremente contador de features
-   - Atualize custo total
-   - Atualize tempo total
+5. **Update project metrics**:
+   - Increment feature counter
+   - Update total cost
+   - Update total time
 
 ## Output
 
-Apresente resumo do arquivamento:
+Present archival summary:
 
 ```
 ╔════════════════════════════════════════════╗
@@ -66,9 +72,9 @@ Apresente resumo do arquivamento:
 ╚════════════════════════════════════════════╝
 ```
 
-## Specs Extraídas
+## Extracted Specs
 
-Se houver specs extraídas:
+If specs were extracted:
 ```
 Specs extracted to .morph/specs/:
 - {domain}/spec.md - {description}