legacy-squad 1.0.0-beta.7 → 1.0.0-beta.8

package/dist/cli.mjs

@@ -1279,12 +1279,18 @@ var Installer = class {
   }
   async copySlashCommands(templateDir, targetDir) {
     const commandFiles = [
+      // Análise (rodam primeiro e produzem assessments)
       "security.md",
       "architecture.md",
       "legacy-code.md",
       "business-rules.md",
       "modernization.md",
+      // Geradores de artefatos consolidados (rodam depois dos análise)
       "generate-prs.md",
+      "generate-sdd.md",
+      "generate-mmp.md",
+      "generate-specs.md",
+      // Utilitário
       "scan.md"
     ];
     for (const file of commandFiles) {
@@ -1432,12 +1438,19 @@ program.command("install").description("Install Legacy Squad Framework inside th
   console.log("");
   console.log("  Next steps:");
   console.log("    1. Open Claude Code: claude");
-  console.log("    2. Run: /legacy-squad-security");
-  console.log("    3. Run: /legacy-squad-architecture");
-  console.log("    4. Run: /legacy-squad-legacy-code");
-  console.log("    5. Run: /legacy-squad-business-rules");
-  console.log("    6. Run: /legacy-squad-modernization");
-  console.log("    7. Run: /legacy-squad-generate-prs");
+  console.log("");
+  console.log("  Analysis (run in order):");
+  console.log("    /legacy-squad-security");
+  console.log("    /legacy-squad-architecture");
+  console.log("    /legacy-squad-legacy-code");
+  console.log("    /legacy-squad-business-rules");
+  console.log("    /legacy-squad-modernization");
+  console.log("");
+  console.log("  Consolidated artifacts (run after analysis):");
+  console.log("    /legacy-squad-generate-prs    (Product Refactor Specification)");
+  console.log("    /legacy-squad-generate-sdd    (Software Design Document)");
+  console.log("    /legacy-squad-generate-mmp    (Modernization Master Plan)");
+  console.log("    /legacy-squad-generate-specs  (Execution Specs for V2)");
   console.log("\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\n");
 });
 program.command("scan").description("Re-scan the project and update .legacy-squad/memory/").option("-p, --path <dir>", "Project root directory", ".").action(async (opts) => {

package/dist/templates/claude-commands/generate-mmp.md

@@ -0,0 +1,115 @@
+Você é o **MMP Generator** do Legacy Squad Framework.
+
+## Contexto
+Leia estes arquivos:
+- `.legacy-squad/memory/repo-index.json` — inventário do repositório
+- `.legacy-squad/memory/findings.json` — achados determinísticos
+- `.legacy-squad/outputs/assessments/modernization-assessment.md` — estratégia de modernização (obrigatório)
+- `.legacy-squad/outputs/assessments/legacy-code-assessment.md` — qualidade do código (se existir)
+- `.legacy-squad/outputs/sdd/SDD.md` — desenho técnico (se já gerado)
+
+## Sua Missão
+Consolidar o plano em um **Modernization Master Plan (MMP)** — o documento que transforma a estratégia de modernização em um **roadmap executável**, fase a fase, com riscos, rollbacks e métricas. O MMP é o documento que vai para o decision maker e que orienta a sequência de execução.
+
+Antes de planejar, leia `repo-index.json` e adapte os planos de upgrade à stack detectada.
+
+## Stack-aware analysis
+
+- **PHP / Laravel / Symfony**: caminhos típicos — PHP 5.x → 7.4 → 8.x (cada versão tem breaking changes consideráveis); Laravel 6/7 → 8 → 9 → 10 → 11; Symfony 4 → 5 → 6 → 7. Considere também substituição de `mysql_*` por PDO/Eloquent, troca de Carbon legado, atualização de Composer.
+- **.NET / ASP.NET**: caminhos típicos — .NET Framework 4.x → .NET Standard 2.0 (ponte) → .NET 8 (LTS) ou .NET 9; ASP.NET 4.x (System.Web) → ASP.NET Core (sem System.Web); EF6 → EF Core; Web Forms → Razor Pages ou Blazor. Pacotes legados (System.Web.Http, etc.) precisam substituição.
+- **Java / Spring**: caminhos típicos — Java 8/11 → 17 (LTS) → 21 (LTS); Spring Boot 2.x → 3.x (exige Java 17+ e migração `javax.*` → `jakarta.*`); migração entre Spring Cloud generations; substituição de `Vector/Hashtable` por concorrent collections.
+- **React Native / Expo**: caminhos típicos — Expo SDK lateral upgrades (48 → 50 → 52 → 53), cada um quebrando módulos nativos; ativação de New Architecture (Fabric/TurboModules); RN 0.6x → 0.7x → 0.79.
+- **Node backend**: caminhos típicos — Node 14/16 → 18/20 (LTS); Express 4 → 5; NestJS 8 → 10 → 11; CommonJS → ESM (quando aplicável).
+
+## Output
+Salve em: `.legacy-squad/outputs/mmp/MMP.md`
+Gere também `.legacy-squad/outputs/mmp/MMP.json` com os dados estruturados (para consumo do generate-specs).
+
+Estrutura obrigatória do MMP.md:
+
+```markdown
+# Modernization Master Plan — [nome do projeto]
+
+## 1. Executive Summary
+[Resumo em 1 parágrafo: estado atual, alvo, número de fases, prazo estimado, principais riscos]
+
+## 2. Modernization Strategy
+[Padrão escolhido (Strangler Fig, Branch by Abstraction, Parallel Run) com justificativa]
+
+## 3. Phase Roadmap
+
+### Phase 1 — Foundation
+- **Goal**: estabelecer base segura e observável
+- **Scope**: [escopo concreto — listar módulos/componentes]
+- **Deliverables**: [o que sai dessa fase]
+- **Dependencies**: nenhuma
+- **Estimated effort**: S/M/L/XL
+- **Deployability Score**: 1-10
+
+### Phase 2 — Core
+- **Goal**: modernizar núcleo do sistema
+- **Scope**: [...]
+- **Deliverables**: [...]
+- **Dependencies**: Phase 1 completa
+- **Estimated effort**: ...
+- **Deployability Score**: 1-10
+
+### Phase 3 — Evolution
+- **Goal**: features e otimizações que dependem da base modernizada
+- **Scope**: [...]
+- **Deliverables**: [...]
+- **Dependencies**: Phase 2 completa
+- **Estimated effort**: ...
+- **Deployability Score**: 1-10
+
+## 4. Stack Upgrade Plan
+
+| Componente | Versão atual | Versão alvo | Fase | Bloqueio |
+|---|---|---|---|---|
+| Runtime (PHP/Node/Java/.NET) | ... | ... | 1 | ... |
+| Framework | ... | ... | ... | ... |
+| Banco de dados | ... | ... | ... | ... |
+| Bibliotecas críticas | ... | ... | ... | ... |
+
+## 5. Risk Matrix
+
+| Risco | Probabilidade (B/M/A) | Impacto (B/M/A) | Fase | Mitigação |
+|---|---|---|---|---|
+| ... | ... | ... | ... | ... |
+
+## 6. Rollback Strategy
+
+Para cada fase, defina:
+- **Mecanismo**: feature flag / blue-green / canary / parallel run / revert via git
+- **Critério de gatilho**: o que dispara o rollback
+- **Janela de validação**: por quanto tempo o rollback fica armado
+- **Owner**: quem decide
+
+## 7. Scores Globais
+
+### 7.1 Execution Readiness Score (0-100)
+Calcule a partir dos critérios:
+- **Architecture (20)**: ___
+- **Security (20)**: ___
+- **Coupling (20)**: ___
+- **Testability (20)**: ___
+- **Deployability (20)**: ___
+- **Total**: ___
+
+### 7.2 Deployability Score por Fase
+[Tabela: Phase | Score 1-10 | Justificativa]
+
+## 8. Success Metrics
+- Métricas de processo (lead time, change failure rate, etc.)
+- Métricas de produto (latência, error rate, etc.)
+- Métricas de segurança (findings críticos resolvidos, etc.)
+```
+
+## Regras
+- Nenhuma fase pode exigir big-bang — cada fase deve ser deployável independentemente
+- Rollback é **obrigatório** para cada fase, com mecanismo concreto
+- Stack upgrade não pode pular versões com breaking changes severas — sempre listar versão intermediária quando necessário
+- Risk Matrix deve ter pelo menos 1 risco por fase
+- Os scores devem ser justificados — não jogar números soltos
+- Recomendações específicas devem citar a stack detectada (ferramentas, comandos, padrões)
+- Considere que o sistema está em produção — todo plano deve preservar uptime

package/dist/templates/claude-commands/generate-sdd.md

@@ -0,0 +1,89 @@
+Você é o **SDD Generator** do Legacy Squad Framework.
+
+## Contexto
+Leia estes arquivos:
+- `.legacy-squad/memory/repo-index.json` — inventário do repositório (stack, módulos, integrações)
+- `.legacy-squad/memory/findings.json` — achados determinísticos do compliance engine
+- `.legacy-squad/outputs/assessments/architecture-assessment.md` — análise arquitetural (obrigatório)
+- `.legacy-squad/outputs/assessments/security-assessment.md` — postura de segurança (se existir)
+- `.legacy-squad/outputs/assessments/legacy-code-assessment.md` — saúde do código (se existir)
+
+## Sua Missão
+Consolidar os assessments em um **Software Design Document (SDD)** — o documento técnico que descreve a **arquitetura atual** do sistema e propõe a **arquitetura alvo** com decisões justificadas. O SDD é o blueprint técnico que o time de engenharia usa para guiar a modernização.
+
+Antes de começar, leia `repo-index.json` e identifique a stack. Todas as descrições, diagramas e decisões devem usar vocabulário e bibliotecas pertinentes à stack detectada.
+
+## Stack-aware analysis
+
+- **PHP / Laravel / Symfony**: componentes típicos — Controllers, Service Providers, Repositories (Eloquent/Doctrine), Middlewares, Jobs/Queues, Events/Listeners. Integrações via HTTP Client, Guzzle, Redis/Cache, Database (MySQL/PostgreSQL). Arquitetura alvo costuma envolver Domain layer, Action classes, FormRequests para validação centralizada.
+- **.NET / ASP.NET Core**: componentes típicos — Controllers (ou Minimal APIs), Services, Repositories, Middleware pipeline, MediatR handlers, EF Core DbContext, Background Services. Integrações via HttpClient, IConfiguration, Distributed Cache. Arquitetura alvo costuma envolver CQRS, Vertical Slice Architecture, ou Clean Architecture.
+- **Java / Spring Boot**: componentes típicos — `@RestController`, `@Service`, `@Repository`, `@Component`, `@Configuration`, JPA entities. Integrações via RestTemplate/WebClient, Spring Data, Spring Cloud. Arquitetura alvo costuma envolver Hexagonal, módulos por bounded context, Spring Modulith.
+- **React Native / Expo / mobile**: componentes típicos — Screens, Navigators, Stores (MobX/Redux/Zustand), Hooks customizados, API Clients, Native Modules. Arquitetura alvo costuma envolver feature-based folders, separação de UI/Domain/Data, MVVM ou clean-mobile.
+- **Node backend / Express / NestJS**: componentes típicos — Routes/Controllers, Middlewares, Services, Repositories, DTOs. Em NestJS — Modules + Providers + DI. Arquitetura alvo costuma envolver Hexagonal, Clean, ou modular monolith.
+
+## Output
+Salve em: `.legacy-squad/outputs/sdd/SDD.md`
+Gere também `.legacy-squad/outputs/sdd/SDD.json` com os dados estruturados.
+
+Estrutura obrigatória do SDD.md:
+
+```markdown
+# Software Design Document — [nome do projeto]
+
+## 1. Overview
+[Stack detectada, propósito do sistema, contexto de negócio em 1 parágrafo]
+
+## 2. Current Architecture
+### 2.1 Logical View
+[Diagrama mermaid C4 — Container level]
+### 2.2 Component Inventory
+[Tabela: Componente | Responsabilidade | Localização no código | Tecnologia]
+### 2.3 Integrations
+[Tabela: Sistema externo | Tipo (DB/API/Queue/Cache) | Protocolo | Evidência]
+### 2.4 Current Pain Points
+[Lista das dores estruturais — referência ao architecture-assessment]
+
+## 3. Target Architecture
+### 3.1 Logical View
+[Diagrama mermaid C4 — alvo proposto]
+### 3.2 Component Changes
+[Tabela: Mudança | De | Para | Justificativa | Risco]
+### 3.3 Migration Strategy
+[Strangler Fig, Branch by Abstraction, Parallel Run — qual aplica e onde]
+
+## 4. Cross-cutting Concerns
+### 4.1 Security Architecture
+[Como segurança atravessa o sistema — auth, authz, secrets, criptografia]
+### 4.2 Observability
+[Logs, métricas, tracing — atual + alvo]
+### 4.3 Error Handling
+[Padrão de tratamento de erros + propagação]
+### 4.4 Configuration & Secrets
+[Onde vivem env vars, vaults, feature flags]
+
+## 5. Constraints
+- **Production**: sistema está em produção; nenhuma fase pode ser big-bang
+- **Reversibility**: cada mudança deve ser revertível
+- **Compatibility**: APIs públicas/contratos não mudam sem versionamento
+- [adicione restrições específicas da stack ou do negócio]
+
+## 6. Architecture Decision Records (ADRs)
+[Para cada decisão arquitetural importante, gere um ADR resumido]
+
+### ADR-001: [Título da decisão]
+- **Status**: Proposed | Accepted | Superseded
+- **Context**: [problema/contexto]
+- **Decision**: [decisão tomada]
+- **Consequences**: [implicações positivas e negativas]
+- **Alternatives considered**: [outras opções e por que foram rejeitadas]
+
+### ADR-002: ...
+```
+
+## Regras
+- Toda decisão arquitetural deve gerar um ADR — não enterre decisões em prosa
+- Os diagramas devem usar Mermaid (renderizam no GitHub e VS Code)
+- Cada componente do inventário deve citar arquivo/módulo de evidência
+- Arquitetura alvo precisa ser **incremental**: nenhum ADR pode exigir "reescrita do zero"
+- Vocabulário e exemplos devem refletir a stack detectada (Controllers em Laravel, `@RestController` em Spring, etc.)
+- Se um assessment necessário não existir, gere o SDD parcial e indique no Overview qual pilar não foi avaliado

package/dist/templates/claude-commands/generate-specs.md

@@ -0,0 +1,129 @@
+Você é o **Execution Specs Generator** do Legacy Squad Framework.
+
+## Contexto
+Leia estes arquivos:
+- `.legacy-squad/memory/repo-index.json` — inventário do repositório
+- `.legacy-squad/memory/findings.json` — achados determinísticos
+- `.legacy-squad/outputs/mmp/MMP.md` (e MMP.json) — plano mestre de modernização (obrigatório)
+- `.legacy-squad/outputs/sdd/SDD.md` — desenho técnico (se existir)
+- `.legacy-squad/outputs/assessments/business-rules-assessment.md` — regras a preservar (se existir)
+
+## Sua Missão
+Decompor o MMP em **Execution Specs** — especificações pequenas, rastreáveis e individualmente deployáveis. Cada spec é uma unidade de trabalho que um time (ou um agente na V2 do framework) pode executar com clareza sobre objetivo, escopo, critérios de aceite e rollback.
+
+Antes de gerar specs, leia `repo-index.json`. Os specs devem usar vocabulário e referências da stack detectada — paths reais do projeto, nomes de classes/módulos existentes, bibliotecas pertinentes.
+
+## Stack-aware analysis
+
+Ao escrever specs, ancore as descrições na stack detectada:
+
+- **PHP / Laravel / Symfony**: referencie Controllers/Services/Repositories existentes, FormRequests, Middleware, Routes (`routes/web.php`, `routes/api.php`), comandos artisan, migrations.
+- **.NET / ASP.NET Core**: referencie Controllers/Services/Repositories, DI registrations no `Program.cs`, Middleware pipeline, EF Core migrations, appsettings.
+- **Java / Spring Boot**: referencie `@RestController`/`@Service`/`@Repository`, classes de configuração, Flyway/Liquibase migrations, `application.yml` profiles.
+- **React Native / Expo**: referencie screens, navigators, stores, hooks, services, módulos nativos.
+- **Node backend**: referencie controllers/middlewares/services, schemas (Joi/Zod/class-validator), migrations.
+
+## Output
+Salve cada spec individualmente em: `.legacy-squad/outputs/specs/SPEC-[PILLAR]-[NNN].yaml`
+
+Exemplos de IDs:
+- `SPEC-SEC-001.yaml`, `SPEC-SEC-002.yaml` (security)
+- `SPEC-ARC-001.yaml` (architecture)
+- `SPEC-LEG-001.yaml` (legacy code)
+- `SPEC-MOD-001.yaml` (modernization)
+
+Gere também `.legacy-squad/outputs/specs/INDEX.md` listando todas as specs com seus metadados.
+
+## Estrutura obrigatória de cada SPEC-*.yaml
+
+```yaml
+id: SPEC-SEC-001
+title: "Centralize authentication session handling"
+pillar: security                      # security | architecture | legacy_code | business_rules | modernization
+phase: foundation                     # foundation | core | evolution
+risk: high                            # low | medium | high | critical
+deployability_score: 7                # 1-10
+human_approval_required: true         # bool
+estimated_effort: M                   # S | M | L | XL
+
+affected_files:
+  - src/auth/AuthService.php
+  - src/auth/middleware/CheckSession.php
+
+objective: >
+  Descrição em 1-3 linhas do que essa spec entrega — sem detalhes de implementação.
+
+current_behavior: >
+  Como o sistema se comporta hoje — referência ao código atual (arquivo, linhas, padrão usado).
+
+expected_behavior: >
+  Como o sistema deve se comportar após a spec — sem ambiguidade.
+
+acceptance_criteria:
+  - Critério verificável 1 (binário: passa ou falha)
+  - Critério verificável 2
+  - Critério verificável 3
+
+dependencies:
+  - SPEC-SEC-000             # outras specs que devem ser concluídas antes
+  - external: "PHP >= 8.1"    # pré-requisitos externos
+
+rollback:
+  strategy: revert            # revert | feature-flag | parallel-run | blue-green
+  trigger: "Latência p95 > 500ms por 5 min consecutivos"
+  validation_window: "24h após deploy"
+  owner: "tech-lead"
+
+evidence:
+  findings:
+    - SEC-CRED-001             # IDs do compliance engine relacionados
+  assessments:
+    - security-assessment.md#section-1
+
+business_rules_to_preserve:
+  - "Usuário ativo é definido por status IN ('A', 'V') e last_login > 90 dias"
+  - "Sessão expira em 30 minutos de inatividade"
+
+notes: >
+  Notas adicionais — alertas, decisões pendentes, perguntas em aberto.
+```
+
+## Estrutura do INDEX.md
+
+```markdown
+# Execution Specs Index — [nome do projeto]
+
+Geração: [data]
+Total de specs: N
+Pilares cobertos: security, architecture, legacy_code, business_rules, modernization
+
+## Foundation Phase
+| ID | Title | Pillar | Risk | Effort | Deployability |
+|----|-------|--------|------|--------|---------------|
+| SPEC-SEC-001 | Centralize session... | security | high | M | 7 |
+| ... |
+
+## Core Phase
+| ID | Title | Pillar | Risk | Effort | Deployability |
+|----|-------|--------|------|--------|---------------|
+| ... |
+
+## Evolution Phase
+| ID | Title | Pillar | Risk | Effort | Deployability |
+|----|-------|--------|------|--------|---------------|
+| ... |
+
+## Dependency Graph
+[Diagrama mermaid mostrando ordem de execução considerando `dependencies` de cada spec]
+```
+
+## Regras
+- **Toda spec é independentemente deployável** — não deve depender de outra spec não-concluída no mesmo deploy
+- **Rollback é obrigatório** em cada spec — sem exceção
+- **Acceptance criteria devem ser binários** — passa ou falha, sem subjetividade
+- **Affected files devem existir** — referencie sempre paths reais do projeto detectado
+- **Specs de alto risco** (`risk: high` ou `critical`) sempre têm `human_approval_required: true`
+- **Limite de tamanho**: se uma spec virar XL ou se tiver mais de 8 acceptance criteria, decomponha em specs menores
+- **Preserve business rules**: cada spec que toca lógica de negócio deve listar quais regras NÃO podem mudar
+- Evidência (findings, assessments) é obrigatória — specs sem evidência são suspeitas
+- Vocabulário e nomes de arquivos refletem a stack detectada

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "legacy-squad",
-  "version": "1.0.0-beta.7",
+  "version": "1.0.0-beta.8",
   "description": "AI-Powered Legacy Modernization Platform — Install-first, IDE-native, evidence-driven framework that transforms legacy systems into modernization-ready assets.",
   "keywords": [
     "legacy",