legacy-squad 1.0.0-beta.6 → 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/architecture.md

@@ -9,34 +9,45 @@ Leia estes arquivos para entender o projeto:
 ## Sua Missão
 Mapear a arquitetura atual do sistema e identificar riscos estruturais. Analise:
 
-1. **Separação de camadas** — existe separação clara entre UI, lógica e dados?
+1. **Separação de camadas** — existe separação clara entre apresentação, lógica de negócio e dados?
 2. **Acoplamento** — quais módulos dependem fortemente uns dos outros?
-3. **State management** — como o estado é gerenciado? Há single source of truth?
-4. **Integrações** — como o sistema se comunica com serviços externos?
-5. **Navegação** — como o roteamento é estruturado?
+3. **Gestão de estado / sessão** — como o estado é gerenciado? Há single source of truth?
+4. **Integrações** — como o sistema se comunica com serviços externos, bancos, filas?
+5. **Roteamento / entrypoints** — como o roteamento HTTP/navegação é estruturado?
 6. **Padrões conflitantes** — há mais de um padrão para a mesma coisa?
 
+## Stack-aware analysis
+
+Antes de analisar, leia `repo-index.json` e identifique a stack. Adapte vocabulário e patterns à stack detectada:
+
+- **PHP / Laravel / Symfony**: identifique Controllers, Models (Eloquent/Doctrine), Services, Repositories, Middlewares, Service Providers; avalie se a separação MVC está respeitada ou se há lógica espalhada em views/blade; veja como Routes e Form Requests organizam validação.
+- **.NET / ASP.NET Core**: identifique Controllers, Services, Repositories, DTOs, Middleware pipeline, Dependency Injection container; avalie uso de Minimal APIs vs Controllers; veja como `Program.cs/Startup.cs` configura o pipeline.
+- **Java / Spring Boot / Spring MVC**: identifique `@RestController/@Controller`, `@Service`, `@Repository`, `@Configuration`, `@Component`; avalie uso de DTOs vs entidades expostas; veja como Spring Profiles e `application.yml/properties` separam ambientes.
+- **React Native / Expo / mobile**: identifique screens, navigators (React Navigation), state stores (MobX/Redux/Zustand/Context), API clients; avalie separação de UI vs lógica de negócio em hooks/services.
+- **Node backend / Express / NestJS**: identifique routes, controllers, middlewares, services; em NestJS observe modules e DI; em Express puro avalie se há separação de camadas ou tudo está em handlers.
+
 ## Arquivos para Analisar
-Com base no repo-index, priorize:
-- Stores e gerenciamento de estado
-- Rotas e navegação
-- Configurações de API
-- Componentes compartilhados
-- Entrypoints da aplicação
+Com base no `repo-index.json`, priorize:
+- Entrypoints da aplicação (`index.php`, `Program.cs`, `Application.java`, `App.tsx`, `server.js`)
+- Configurações de roteamento e middleware
+- Camada de persistência (repositories, DAOs, ORMs)
+- Componentes/módulos compartilhados (utils, shared, common)
+- Configurações de infraestrutura (Dockerfile, docker-compose, application.yml)
 
 ## Output
 Salve em: `.legacy-squad/outputs/assessments/architecture-assessment.md`
 
 Estrutura:
-1. Current Architecture Overview (com diagrama em mermaid se possível)
-2. Layer Separation Analysis
-3. Coupling & Cohesion Assessment
-4. Integration Points Map
-5. Architecture Risks
-6. Target Architecture Recommendations
+1. **Current Architecture Overview** (com diagrama em mermaid se possível)
+2. **Layer Separation Analysis** (camadas detectadas e quanto a separação é respeitada)
+3. **Coupling & Cohesion Assessment** (módulos com alto fan-out, dependências circulares)
+4. **Integration Points Map** (bancos, APIs externas, filas, caches)
+5. **Architecture Risks** (dívidas estruturais, padrões conflitantes, god classes)
+6. **Target Architecture Recommendations** (alvo incremental — sem big-bang)
 
 ## Regras
-- Base toda análise em evidência dos arquivos reais
-- Use terminologia C4 (Context, Container, Component)
-- Propostas de arquitetura alvo devem ser incrementais
-- Considere que o sistema está em produção
+- Base toda análise em evidência dos arquivos reais (arquivo, linha, snippet)
+- Use terminologia C4 (Context, Container, Component) quando aplicável
+- Propostas de arquitetura alvo devem ser incrementais (Strangler Fig, Branch by Abstraction)
+- Considere que o sistema está em produção — toda recomendação deve ser deployável isoladamente
+- Recomendações específicas devem citar APIs/bibliotecas da stack (e.g., "introduza um Service Provider em Laravel", "extraia para um `@Service` Spring", "use DI nativo do ASP.NET Core")

package/dist/templates/claude-commands/business-rules.md

@@ -11,25 +11,42 @@ Extrair regras de negócio escondidas no código. Sistemas legados frequentement
 1. **Regras explícitas** — validações, permissões, fluxos visíveis
 2. **Regras implícitas** — condicionais obscuros, magic numbers, comportamentos em catch blocks
 3. **Modelo de domínio** — entidades principais e seus relacionamentos
-4. **Fluxos de negócio** — jornadas do usuário codificadas nas telas/stores
+4. **Fluxos de negócio** — jornadas do usuário codificadas no sistema
 5. **Regras que devem ser preservadas** — lógica que não pode mudar na modernização
 
-## Arquivos para Analisar
-Priorize stores, screens com lógica de negócio, validações e fluxos de login/autenticação.
+## Stack-aware analysis
+
+Antes de analisar, leia `repo-index.json` e identifique a stack. Adapte onde procurar:
+
+- **PHP / Laravel / Symfony**: olhe FormRequests/Validators (regras explícitas de input), Controllers (lógica de fluxo), Models/Eloquent (relacionamentos, scopes, accessors), Service classes, Middleware (regras de autorização), Policies/Gates.
+- **.NET / ASP.NET Core**: olhe DataAnnotations e FluentValidation (validações), Controllers/Minimal APIs, Services, EF Core entities (constraints, relationships), Authorization Policies, Filters (regras transversais).
+- **Java / Spring Boot**: olhe Bean Validation (`@NotNull`, `@Pattern`, `@Valid`), `@RestController` methods, `@Service` classes, JPA entities (`@Entity`, `@OneToMany`, lifecycle callbacks), `@PreAuthorize/@Secured`, Aspects.
+- **React Native / mobile**: olhe screens com lógica de submissão, hooks/services com validações, state stores (regras de transição de estado), middleware de API (autorização do cliente), formulários e suas validações inline.
+- **Node backend**: olhe middlewares de validação (Joi, Zod, class-validator), controllers/handlers, services, schemas de banco (Mongoose, Sequelize, Prisma — constraints e hooks).
+
+## Padrões a procurar (independente da stack)
+
+- `switch/case` ou `if/else if/else` em cadeia com nomes de operações ou status — fluxos de máquina de estado escondidos
+- `ifs` aninhados com condições compostas — regras de negócio camufladas
+- Magic numbers e magic strings (e.g., `if (status == 3)`, `if (tipo == "PJ")`) — devem virar enums/constantes nomeadas
+- Lookups em arrays/maps hardcoded — tabelas de domínio que poderiam ser configuráveis
+- Try/catch que silencia erro mas faz uma ação alternativa — fluxo de negócio em fallback
+- Cálculos com fórmulas literais — regras tarifárias/de cálculo que ninguém entende mais
 
 ## Output
 Salve em: `.legacy-squad/outputs/assessments/business-rules-assessment.md`
 
 Estrutura:
-1. Business Domain Overview
-2. Extracted Business Rules (table: ID, rule, file, line, type explicit/implicit)
-3. Validation Rules Catalog
-4. Permission Model
-5. Implicit Rules (hidden in code)
-6. Rules Preservation Checklist for Modernization
+1. **Business Domain Overview** (entidades principais, glossário de domínio extraído do código)
+2. **Extracted Business Rules** (tabela: ID, regra, arquivo, linha, tipo explícito/implícito)
+3. **Validation Rules Catalog** (consolidado por campo/entidade)
+4. **Permission Model** (quem pode fazer o quê — extraído de middlewares, policies, guards)
+5. **Implicit Rules** (regras escondidas em código — magic numbers, condicionais sem documentação)
+6. **Rules Preservation Checklist for Modernization** (lista do que NÃO pode mudar)
 
 ## Regras
 - Toda regra extraída deve citar arquivo e linha
 - Distinga regras de negócio de detalhes técnicos de implementação
 - Sinalize regras que parecem acidentais vs intencionais
-- Use linguagem de domínio, não jargão técnico
+- Use linguagem de domínio (a do negócio do projeto), não jargão técnico
+- Quando achar magic numbers/strings, sugira o nome da constante apropriado (e.g., `STATUS_APROVADO` em vez de `3`)

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-prs.md

@@ -9,6 +9,8 @@ Leia estes arquivos:
 ## Sua Missão
 Consolidar todos os assessments em um único **PRS (Product Refactor Specification)** — o documento final de diagnóstico do legado.
 
+Leia primeiro o `repo-index.json` para conhecer a stack do projeto. O PRS deve usar vocabulário da stack detectada (PHP/Laravel, .NET, Java/Spring, React Native, Node, etc.) ao consolidar findings e recomendações — nada de termos mobile-only se o projeto é PHP, nem termos backend se é mobile.
+
 ## Output
 Salve em: `.legacy-squad/outputs/reports/PRS.md`
 

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/dist/templates/claude-commands/legacy-code.md

@@ -3,32 +3,45 @@ Você é o **Legacy Code Agent** do Legacy Squad Framework.
 ## Contexto
 Leia estes arquivos para entender o projeto:
 - `.legacy-squad/memory/repo-index.json` — inventário do repositório
-- `.legacy-squad/memory/findings.json` — achados do compliance engine
+- `.legacy-squad/memory/findings.json` — achados do compliance engine (atenção especial a CQ-DEPRECATED-001 e CQ-MIX-001)
 - `.legacy-squad/memory/context-packs.json` — resumo dos módulos
 
 ## Sua Missão
 Avaliar a qualidade do código, identificar hotspots e propor prioridades de refatoração:
 
 1. **Hotspots** — arquivos maiores, mais complexos ou mais acoplados
-2. **Migração JS→TS** — status atual e prioridades
-3. **Duplicação** — padrões repetidos que poderiam ser extraídos
-4. **Cobertura de testes** — quais áreas críticas não têm testes?
-5. **Código morto** — imports não usados, funções órfãs
-6. **Error handling** — padrões de tratamento de erros
+2. **APIs depreciadas / removidas** — uso de bibliotecas/funções obsoletas
+3. **Migração de versão de linguagem** — código que ainda usa padrões antigos da linguagem
+4. **Duplicação** — padrões repetidos que poderiam ser extraídos
+5. **Cobertura de testes** — quais áreas críticas não têm testes?
+6. **Código morto** — imports/dependências não usados, funções/classes órfãs
+7. **Error handling** — padrões de tratamento de erros (incluindo catches vazios)
+
+## Stack-aware analysis
+
+Antes de analisar, leia `repo-index.json` e identifique a stack. Adapte vocabulário e patterns à stack detectada:
+
+- **PHP / Laravel / Symfony**: procure por `mysql_*` (removido no PHP 7), `ereg/eregi/split` (removidos), uso de superglobais sem filtro, classes God com 500+ linhas, controllers fat sem service layer; verifique se `composer.json` aponta para versões PHP/framework EOL; uso de `array()` em vez de `[]`, `var` em vez de `private/protected`.
+- **.NET / ASP.NET / C#**: procure por `WebClient` (obsoleto, use `HttpClient`), `ConfigurationManager.AppSettings` (legado, use `IConfiguration`), `BinaryFormatter` (banido a partir de .NET 5), `HashAlgorithm.Create()` sem argumento; verifique `.csproj` com `net4xx` (Framework legado) vs `net8.0+` (moderno); regions excessivas, classes parciais sem necessidade.
+- **Java / Spring**: procure por `Vector/Hashtable/Stack` (use `ArrayList/HashMap/Deque`), `Date` legado (use `java.time`), `synchronized` excessivo, `Object[]` em vez de generics, `instanceof` em cadeia (deveria ser polimorfismo); verifique se `pom.xml/build.gradle` aponta para Java/Spring EOL; uso de `@Autowired` em fields vs constructor injection.
+- **React Native / TypeScript / mobile**: procure por arquivos `.js` que poderiam ser `.ts/.tsx`, class components que poderiam ser functional, lifecycle methods deprecated (`componentWillMount`), uso de `any` em larga escala, `require()` em vez de `import`; verifique versão do RN/Expo SDK em uso vs LTS atual.
+- **Node backend**: procure por uso de `require` em vez de `import`, callbacks sem promises/async-await, `var` em vez de `const/let`, `Buffer()` (deprecated, use `Buffer.from`), `process.on('uncaughtException')` sem handler decente, `domain` (deprecated).
 
 ## Output
 Salve em: `.legacy-squad/outputs/assessments/legacy-code-assessment.md`
 
 Estrutura:
-1. Code Quality Overview
-2. Complexity Hotspots (top 10 files by size/complexity)
-3. Migration Status (JS→TS progress)
-4. Duplication Analysis
-5. Test Coverage Assessment
-6. Refactoring Priorities (ranked S/M/L effort)
+1. **Code Quality Overview** (LOC total, distribuição por linguagem, idade média estimada)
+2. **Complexity Hotspots** (top 10 arquivos por tamanho/complexidade)
+3. **Deprecated/Removed APIs** (consolida CQ-DEPRECATED-001 + descobertas adicionais)
+4. **Language Version Migration** (status atual da versão de linguagem/framework vs LTS/atual)
+5. **Duplication Analysis** (padrões repetidos candidatos a extração)
+6. **Test Coverage Assessment** (áreas críticas sem testes)
+7. **Refactoring Priorities** (ranqueadas S/M/L de esforço)
 
 ## Regras
-- Antes de propor refatoração, entenda o que o código faz
-- Priorize refatoração que reduz risco, não só melhora estética
+- Antes de propor refatoração, entenda o que o código faz (negócio, não apenas estética)
+- Priorize refatoração que reduz risco operacional, não só melhora estética
 - Estimativas relativas (S/M/L), não horas absolutas
-- Considere cobertura de testes antes de recomendar mudanças
+- Considere cobertura de testes antes de recomendar mudanças disruptivas
+- Recomendações de modernização devem indicar a versão alvo (e.g., "migrar PHP 7.4 → 8.3", "Spring Boot 2.7 → 3.2", "RN 0.68 → 0.79")

package/dist/templates/claude-commands/modernization.md

@@ -9,27 +9,39 @@ Leia estes arquivos:
 ## Sua Missão
 Sintetizar os achados de todos os pilares em um plano concreto de modernização incremental.
 
-1. **Estratégia** — qual padrão de modernização aplicar? (Strangler Fig, Branch by Abstraction, etc.)
+1. **Estratégia** — qual padrão de modernização aplicar? (Strangler Fig, Branch by Abstraction, Parallel Run)
 2. **Fases** — dividir em Foundation → Core → Evolution
-3. **Stack upgrade** — o que atualizar e em que ordem
+3. **Stack upgrade** — o que atualizar e em que ordem (linguagem, framework, dependências)
 4. **Riscos** — matriz de risco por fase
 5. **Rollback** — estratégia de rollback por fase
 6. **Scores** — Deployability Score (1-10) e Execution Readiness Score (0-100)
 
+## Stack-aware analysis
+
+Antes de planejar, leia `repo-index.json` e identifique a stack. Adapte o stack-upgrade plan à stack detectada:
+
+- **PHP / Laravel / Symfony**: avalie a versão atual do PHP vs versões com suporte (consulte https://www.php.net/supported-versions.php). Plano típico: PHP 5.x → 7.4 → 8.x; Laravel 6/7/8 → 11; Symfony 4/5 → 7. Use `composer outdated` mental para mapear gaps. Cada upgrade do framework costuma exigir upgrade do PHP primeiro.
+- **.NET / ASP.NET**: avalie TargetFramework atual. Plano típico: .NET Framework 4.x → .NET 8 (LTS) ou .NET 9 via .NET Standard 2.0 como ponte; ASP.NET 4.x → ASP.NET Core; pacotes NuGet com major bumps. Use `Microsoft.DotNet.UpgradeAssistant` como referência mental.
+- **Java / Spring**: avalie versão Java + Spring Boot. Plano típico: Java 8/11 → 17 (LTS) → 21 (LTS); Spring Boot 2.x → 3.x (que exige Java 17+ e troca de `javax.*` → `jakarta.*`); pom.xml/build.gradle precisam revisar todas dependências para versões Jakarta-compatible.
+- **React Native / Expo**: avalie versão atual do RN/Expo SDK. Plano típico: Expo SDK 48 → 50 → 52 → 53; RN 0.6x → 0.7x → 0.79; revisão de New Architecture (Fabric/TurboModules) quando aplicável. Cada upgrade do Expo SDK costuma revisar todos os módulos nativos.
+- **Node backend**: avalie versão do Node + framework. Plano típico: Node 14/16 → 18/20 (LTS); Express 4 → 5 (quando estável); NestJS 8 → 10; revisão de pacotes com vulnerabilidades (`npm audit`).
+
 ## Output
 Salve em: `.legacy-squad/outputs/assessments/modernization-assessment.md`
 
 Estrutura:
-1. Modernization Strategy
-2. Phase Roadmap (Foundation → Core → Evolution)
-3. Stack Upgrade Plan
-4. Risk Matrix
-5. Rollback Strategy
-6. Deployability Score per Phase
-7. Execution Readiness Score
+1. **Modernization Strategy** (padrão escolhido + justificativa)
+2. **Phase Roadmap** (Foundation → Core → Evolution, com escopo por fase)
+3. **Stack Upgrade Plan** (versão atual → alvo, com gates intermediários)
+4. **Risk Matrix** (risco por fase, com mitigação)
+5. **Rollback Strategy** (por fase — feature flags, blue-green, canary, parallel run)
+6. **Deployability Score per Phase** (1-10)
+7. **Execution Readiness Score** (0-100, considerando testes, observabilidade, CI/CD)
 
 ## Regras
-- Nenhuma fase pode exigir big-bang — cada fase é deployável independentemente
+- Nenhuma fase pode exigir big-bang — cada fase deve ser deployável independentemente
 - Rollback obrigatório para cada fase
 - Human approval required para mudanças de alto risco
 - Considere o sistema como estando em produção
+- Stack-upgrade plan deve sempre referenciar a versão LTS mais recente da stack como alvo, e mencionar versões intermediárias seguras quando o salto é grande
+- Para frameworks ainda em EOL ou EOL próximo, sinalize prazo de upgrade como crítico

package/dist/templates/claude-commands/security.md

@@ -7,26 +7,36 @@ Leia estes arquivos para entender o projeto:
 - `.legacy-squad/memory/context-packs.json` — resumo dos módulos com arquivos-chave
 
 ## Sua Missão
-Realizar um assessment profundo de segurança que vai além do pattern matching. O Compliance Engine já detectou achados por regex — sua análise deve:
+Realizar um assessment profundo de segurança que vai além do pattern matching. O Compliance Engine já detectou achados por regex (SEC-SQL-001, SEC-CRYPTO-001, SEC-DESER-001, SEC-CMD-001, SEC-PATH-001, SEC-XSS-001, etc.) — sua análise deve:
 
-1. **Validar findings existentes** — confirme ou refine os achados do compliance engine
+1. **Validar findings existentes** — confirme ou refine os achados do Compliance Engine
 2. **Detectar novos achados** que regex não alcança:
-   - Fluxos de autenticação inseguros
-   - Autorização ausente ou inconsistente
+   - Fluxos de autenticação inseguros (login, refresh token, MFA)
+   - Autorização ausente ou inconsistente entre endpoints/rotas
    - Dados sensíveis transitando sem criptografia
    - Tokens sem expiração ou rotação
-   - Secrets em configurações de CI/CD
+   - Secrets em configurações de CI/CD ou arquivos `.env*` versionados
    - Dependências com vulnerabilidades conhecidas
-3. **Analisar integrações** — cada API externa é um vetor de ataque
-4. **Avaliar LGPD** — todo uso de CPF, dados de saúde e PII
+3. **Analisar integrações** — cada API externa, banco, fila ou serviço é um vetor de ataque
+4. **Avaliar privacidade de dados** — todo uso de PII (CPF, RG, e-mail, dados de saúde) deve ser auditado quanto a LGPD/GDPR
+
+## Stack-aware analysis
+
+Antes de analisar, leia `repo-index.json` e identifique a stack. Adapte vocabulário e patterns à stack detectada:
+
+- **PHP / Laravel / Symfony / CodeIgniter**: foque em `$_GET/$_POST/$_REQUEST` mal sanitizados, sessões (`$_SESSION`), `unserialize()` de input, `include` com input do usuário, hashing fraco (`md5/sha1` no lugar de `password_hash`), uso de PDO sem prepared statements, `composer.json` com pacotes abandonados.
+- **.NET / ASP.NET Core / .NET Framework**: foque em `SqlCommand` com concatenação, `BinaryFormatter/SoapFormatter` em deserialização, `Request.Form/QueryString` sem validação, `Process.Start` com input, NuGet com CVEs conhecidos, cookies sem `HttpOnly/Secure/SameSite`, ausência de antiforgery tokens.
+- **Java / Spring Boot / Spring MVC**: foque em `Statement.execute` com concatenação, `ObjectInputStream.readObject` em deserialização, `Runtime.getRuntime().exec` com input, `request.getParameter` sem validação, `MessageDigest.getInstance("MD5"/"SHA-1")`, dependências Maven/Gradle com CVEs, `@CrossOrigin` permissivo.
+- **React Native / Expo / mobile**: foque em armazenamento inseguro (AsyncStorage sem criptografia para tokens), uso de `expo-secure-store/Keychain/Keystore`, logs em produção (`console.log` com dados sensíveis), deep links sem validação, certificados embarcados, permissões excessivas em `AndroidManifest.xml/Info.plist`.
+- **Node backend / Express / NestJS**: foque em SQL/NoSQL injection, deserialização (`JSON.parse` confiando em input), command injection (`child_process.exec`), uso de `eval`, prototype pollution, middlewares de auth ausentes.
 
 ## Arquivos para Analisar
-Com base no repo-index, priorize:
-- Stores de autenticação e sessão
-- Configurações de API e endpoints
-- Utilitários que manipulam dados sensíveis
-- Telas de login e cadastro
-- Qualquer arquivo referenciado nos findings
+Com base no `repo-index.json`, priorize:
+- Módulos de autenticação e sessão (independente da stack — controllers de auth em Laravel/Spring, AuthContext/stores em mobile, middlewares em Express)
+- Configurações de API, endpoints, integrações externas
+- Repositórios e camadas de acesso a dados (DAOs, repositories, ORMs)
+- Utilitários que manipulam dados sensíveis (criptografia, mascaramento)
+- Qualquer arquivo referenciado nos findings determinísticos
 
 ## Output
 Salve o resultado em: `.legacy-squad/outputs/assessments/security-assessment.md`
@@ -37,19 +47,19 @@ Use esta estrutura:
 # Security Assessment — [nome do projeto]
 
 ## 1. Authentication & Session Analysis
-[análise de fluxos de autenticação]
+[análise de fluxos de autenticação, login, MFA, sessão, JWT/cookies]
 
 ## 2. Secrets & Credential Management
-[análise de gestão de credenciais]
+[análise de gestão de credenciais — env vars, vaults, .env versionado, hardcoded secrets]
 
-## 3. Data Protection & Privacy (LGPD)
-[análise de proteção de dados pessoais]
+## 3. Data Protection & Privacy
+[análise de proteção de dados pessoais — LGPD/GDPR, mascaramento, criptografia at-rest/in-transit]
 
 ## 4. API Security Posture
-[análise de segurança das integrações]
+[análise de segurança das integrações — auth de API, rate limiting, CORS, validação de input]
 
 ## 5. Dependency Vulnerabilities
-[análise de dependências com CVEs conhecidos]
+[análise de dependências com CVEs conhecidos — composer.json/csproj/pom.xml/package.json]
 
 ## 6. Findings Summary
 
@@ -58,7 +68,7 @@ Use esta estrutura:
 | SEC-AI-001 | ... | critical | ... | ... |
 
 ## 7. Recommendations (prioritized)
-[recomendações ordenadas por severidade]
+[recomendações ordenadas por severidade, com remediação específica para a stack do projeto]
 ```
 
 ## Regras
@@ -66,4 +76,5 @@ Use esta estrutura:
 - Severidade: critical > high > medium > low > info
 - Recomendações devem ser incrementais (o sistema está em produção)
 - IDs dos novos achados: SEC-AI-001, SEC-AI-002, etc. (prefixo AI para distinguir dos determinísticos)
-- Referências: OWASP MASVS V2, OWASP ASVS, CWE, LGPD
+- Recomendações devem citar a API/biblioteca correta para a stack do projeto (e.g., `PDO::prepare` para PHP, `SqlParameter` para .NET, `PreparedStatement` para Java, `expo-secure-store` para RN)
+- Referências: OWASP Top 10, OWASP ASVS, OWASP MASVS (mobile), CWE, LGPD/GDPR

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "legacy-squad",
-  "version": "1.0.0-beta.6",
+  "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",