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

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-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/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.7",
   "description": "AI-Powered Legacy Modernization Platform — Install-first, IDE-native, evidence-driven framework that transforms legacy systems into modernization-ready assets.",
   "keywords": [
     "legacy",