legacy-squad 1.0.0-beta.7 → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +37 -14
- package/README.pt-br.md +37 -14
- package/dist/cli.mjs +19 -6
- package/dist/templates/claude-commands/generate-mmp.md +115 -0
- package/dist/templates/claude-commands/generate-sdd.md +89 -0
- package/dist/templates/claude-commands/generate-specs.md +129 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -285,9 +285,14 @@ The framework was validated against a **production mobile app** (~18k lines of c
|
|
|
285
285
|
- Session recording capturing sensitive data without user consent
|
|
286
286
|
- 63 business rules extracted from code (11 implicit, never documented)
|
|
287
287
|
- Potential bug in a date calculation affecting core business logic
|
|
288
|
-
- 36-week modernization roadmap with scores: Deployability 3→9/10, Readiness 22→87/100
|
|
289
288
|
|
|
290
|
-
**
|
|
289
|
+
**Generated artifacts (4 official deliverables of V1):**
|
|
290
|
+
- **PRS** — Product Refactor Specification consolidating the diagnostic
|
|
291
|
+
- **SDD** — Software Design Document with current/target architecture and 8 ADRs
|
|
292
|
+
- **MMP** — Modernization Master Plan with 4-phase roadmap (Emergency → Foundation → Core → Evolution), Execution Readiness Score 38→88/100, Deployability scores per phase, and concrete rollback strategies
|
|
293
|
+
- **37 Execution Specs** — atomic, individually deployable units of work with binary acceptance criteria, mandatory rollback, evidence traceability, and dependency graph
|
|
294
|
+
|
|
295
|
+
**Total:** 50 findings + 4 consolidated artifacts + 37 executable specs from a single `npx legacy-squad install` followed by 9 slash command activations.
|
|
291
296
|
|
|
292
297
|
---
|
|
293
298
|
|
|
@@ -297,10 +302,12 @@ The framework was validated against a **production mobile app** (~18k lines of c
|
|
|
297
302
|
|
|
298
303
|
Focus: **Understand + Plan**
|
|
299
304
|
|
|
300
|
-
- Scanner,
|
|
301
|
-
-
|
|
302
|
-
-
|
|
303
|
-
-
|
|
305
|
+
- Scanner with multi-stack detection (PHP/Laravel/Symfony, .NET/ASP.NET, Java/Spring, Node, React Native/Expo)
|
|
306
|
+
- Compliance Engine with 14 deterministic rules (OWASP MASVS, ASVS, CWE Top 25)
|
|
307
|
+
- Context Manager (basic)
|
|
308
|
+
- **5 analysis agents** as slash commands: security, architecture, legacy-code, business-rules, modernization
|
|
309
|
+
- **4 artifact generators** as slash commands: PRS, SDD, MMP, Execution Specs
|
|
310
|
+
- Claude Code, Codex CLI support (Cursor / Gemini CLI on the roadmap)
|
|
304
311
|
|
|
305
312
|
### Enterprise Edition (V2) — In development
|
|
306
313
|
|
|
@@ -317,14 +324,30 @@ Focus: **Modernize**
|
|
|
317
324
|
|
|
318
325
|
## Roadmap
|
|
319
326
|
|
|
320
|
-
|
|
321
|
-
|
|
322
|
-
- [x]
|
|
323
|
-
- [x]
|
|
324
|
-
- [
|
|
325
|
-
- [
|
|
326
|
-
- [
|
|
327
|
-
- [
|
|
327
|
+
### V1 — Discovery Platform (Community Edition) ✅
|
|
328
|
+
|
|
329
|
+
- [x] Scanner + Compliance Engine
|
|
330
|
+
- [x] Install command + IDE integration
|
|
331
|
+
- [x] Context Manager (basic)
|
|
332
|
+
- [x] End-to-end validation with real project (mobile, ~18k LoC)
|
|
333
|
+
- [x] Multi-stack rule catalog (PHP, .NET, Java, Node, mobile)
|
|
334
|
+
- [x] Language-agnostic agent templates (stack-aware analysis)
|
|
335
|
+
- [x] 4 official artifacts (PRS, SDD, MMP, Execution Specs)
|
|
336
|
+
|
|
337
|
+
### V1 — Continuous improvements
|
|
338
|
+
|
|
339
|
+
- [ ] Cursor + Gemini CLI support
|
|
340
|
+
- [ ] Framework-specific rule packs (Eloquent raw queries, EF Core, Hibernate HQL)
|
|
341
|
+
- [ ] AST-based scanner (current is regex-based)
|
|
342
|
+
|
|
343
|
+
### V2 — Execution Platform (Enterprise Edition) — In development
|
|
344
|
+
|
|
345
|
+
- [ ] Execution Engine (AI-assisted refactoring from Execution Specs)
|
|
346
|
+
- [ ] Pull Request Engine
|
|
347
|
+
- [ ] QA Gates
|
|
348
|
+
- [ ] CI/CD Integration
|
|
349
|
+
- [ ] Custom Rule Packs
|
|
350
|
+
- [ ] Dashboard + Team Collaboration
|
|
328
351
|
|
|
329
352
|
---
|
|
330
353
|
|
package/README.pt-br.md
CHANGED
|
@@ -285,9 +285,14 @@ O framework foi validado contra um **app mobile em produção** (~18k linhas de
|
|
|
285
285
|
- Gravação de sessão capturando dados sensíveis sem consentimento
|
|
286
286
|
- 63 regras de negócio extraídas do código (11 implícitas, nunca documentadas)
|
|
287
287
|
- Bug potencial em cálculo de datas afetando lógica de negócio central
|
|
288
|
-
- Roadmap de modernização de 36 semanas com scores: Deployability 3→9/10, Readiness 22→87/100
|
|
289
288
|
|
|
290
|
-
**
|
|
289
|
+
**Artefatos gerados (4 entregáveis oficiais do V1):**
|
|
290
|
+
- **PRS** — Product Refactor Specification consolidando o diagnóstico
|
|
291
|
+
- **SDD** — Software Design Document com arquitetura atual/alvo e 8 ADRs
|
|
292
|
+
- **MMP** — Modernization Master Plan com roadmap em 4 fases (Emergência → Foundation → Core → Evolution), Execution Readiness Score 38→88/100, scores de deployability por fase e estratégias concretas de rollback
|
|
293
|
+
- **37 Execution Specs** — unidades de trabalho atômicas, individualmente deployáveis, com critérios de aceite binários, rollback obrigatório, rastreabilidade de evidências e grafo de dependências
|
|
294
|
+
|
|
295
|
+
**Total:** 50 achados + 4 artefatos consolidados + 37 specs executáveis a partir de um único `npx legacy-squad install` seguido de 9 ativações de slash command.
|
|
291
296
|
|
|
292
297
|
---
|
|
293
298
|
|
|
@@ -297,10 +302,12 @@ O framework foi validado contra um **app mobile em produção** (~18k linhas de
|
|
|
297
302
|
|
|
298
303
|
Foco: **Entender + Planejar**
|
|
299
304
|
|
|
300
|
-
- Scanner,
|
|
301
|
-
-
|
|
302
|
-
-
|
|
303
|
-
-
|
|
305
|
+
- Scanner com detecção multi-stack (PHP/Laravel/Symfony, .NET/ASP.NET, Java/Spring, Node, React Native/Expo)
|
|
306
|
+
- Compliance Engine com 14 regras determinísticas (OWASP MASVS, ASVS, CWE Top 25)
|
|
307
|
+
- Context Manager (básico)
|
|
308
|
+
- **5 agentes de análise** como slash commands: security, architecture, legacy-code, business-rules, modernization
|
|
309
|
+
- **4 geradores de artefato** como slash commands: PRS, SDD, MMP, Execution Specs
|
|
310
|
+
- Suporte a Claude Code, Codex CLI (Cursor / Gemini CLI no roadmap)
|
|
304
311
|
|
|
305
312
|
### Enterprise Edition (V2) — Em desenvolvimento
|
|
306
313
|
|
|
@@ -317,14 +324,30 @@ Foco: **Modernizar**
|
|
|
317
324
|
|
|
318
325
|
## Roadmap
|
|
319
326
|
|
|
320
|
-
|
|
321
|
-
|
|
322
|
-
- [x]
|
|
323
|
-
- [x]
|
|
324
|
-
- [
|
|
325
|
-
- [
|
|
326
|
-
- [
|
|
327
|
-
- [
|
|
327
|
+
### V1 — Discovery Platform (Community Edition) ✅
|
|
328
|
+
|
|
329
|
+
- [x] Scanner + Compliance Engine
|
|
330
|
+
- [x] Comando install + integração com IDE
|
|
331
|
+
- [x] Context Manager (básico)
|
|
332
|
+
- [x] Validação end-to-end com projeto real (mobile, ~18k LoC)
|
|
333
|
+
- [x] Catálogo de regras multi-stack (PHP, .NET, Java, Node, mobile)
|
|
334
|
+
- [x] Templates de agentes language-agnostic (stack-aware analysis)
|
|
335
|
+
- [x] 4 artefatos oficiais (PRS, SDD, MMP, Execution Specs)
|
|
336
|
+
|
|
337
|
+
### V1 — Melhorias contínuas
|
|
338
|
+
|
|
339
|
+
- [ ] Suporte a Cursor + Gemini CLI
|
|
340
|
+
- [ ] Pacotes de regras framework-specific (Eloquent raw queries, EF Core, Hibernate HQL)
|
|
341
|
+
- [ ] Scanner baseado em AST (atual é regex)
|
|
342
|
+
|
|
343
|
+
### V2 — Execution Platform (Enterprise Edition) — Em desenvolvimento
|
|
344
|
+
|
|
345
|
+
- [ ] Execution Engine (refatoração assistida por IA a partir das Execution Specs)
|
|
346
|
+
- [ ] Pull Request Engine
|
|
347
|
+
- [ ] QA Gates
|
|
348
|
+
- [ ] Integração CI/CD
|
|
349
|
+
- [ ] Custom Rule Packs
|
|
350
|
+
- [ ] Dashboard + Colaboração em Equipe
|
|
328
351
|
|
|
329
352
|
---
|
|
330
353
|
|
package/dist/cli.mjs
CHANGED
|
@@ -1279,12 +1279,18 @@ var Installer = class {
|
|
|
1279
1279
|
}
|
|
1280
1280
|
async copySlashCommands(templateDir, targetDir) {
|
|
1281
1281
|
const commandFiles = [
|
|
1282
|
+
// Análise (rodam primeiro e produzem assessments)
|
|
1282
1283
|
"security.md",
|
|
1283
1284
|
"architecture.md",
|
|
1284
1285
|
"legacy-code.md",
|
|
1285
1286
|
"business-rules.md",
|
|
1286
1287
|
"modernization.md",
|
|
1288
|
+
// Geradores de artefatos consolidados (rodam depois dos análise)
|
|
1287
1289
|
"generate-prs.md",
|
|
1290
|
+
"generate-sdd.md",
|
|
1291
|
+
"generate-mmp.md",
|
|
1292
|
+
"generate-specs.md",
|
|
1293
|
+
// Utilitário
|
|
1288
1294
|
"scan.md"
|
|
1289
1295
|
];
|
|
1290
1296
|
for (const file of commandFiles) {
|
|
@@ -1432,12 +1438,19 @@ program.command("install").description("Install Legacy Squad Framework inside th
|
|
|
1432
1438
|
console.log("");
|
|
1433
1439
|
console.log(" Next steps:");
|
|
1434
1440
|
console.log(" 1. Open Claude Code: claude");
|
|
1435
|
-
console.log("
|
|
1436
|
-
console.log("
|
|
1437
|
-
console.log("
|
|
1438
|
-
console.log("
|
|
1439
|
-
console.log("
|
|
1440
|
-
console.log("
|
|
1441
|
+
console.log("");
|
|
1442
|
+
console.log(" Analysis (run in order):");
|
|
1443
|
+
console.log(" /legacy-squad-security");
|
|
1444
|
+
console.log(" /legacy-squad-architecture");
|
|
1445
|
+
console.log(" /legacy-squad-legacy-code");
|
|
1446
|
+
console.log(" /legacy-squad-business-rules");
|
|
1447
|
+
console.log(" /legacy-squad-modernization");
|
|
1448
|
+
console.log("");
|
|
1449
|
+
console.log(" Consolidated artifacts (run after analysis):");
|
|
1450
|
+
console.log(" /legacy-squad-generate-prs (Product Refactor Specification)");
|
|
1451
|
+
console.log(" /legacy-squad-generate-sdd (Software Design Document)");
|
|
1452
|
+
console.log(" /legacy-squad-generate-mmp (Modernization Master Plan)");
|
|
1453
|
+
console.log(" /legacy-squad-generate-specs (Execution Specs for V2)");
|
|
1441
1454
|
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");
|
|
1442
1455
|
});
|
|
1443
1456
|
program.command("scan").description("Re-scan the project and update .legacy-squad/memory/").option("-p, --path <dir>", "Project root directory", ".").action(async (opts) => {
|
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
Você é o **MMP Generator** do Legacy Squad Framework.
|
|
2
|
+
|
|
3
|
+
## Contexto
|
|
4
|
+
Leia estes arquivos:
|
|
5
|
+
- `.legacy-squad/memory/repo-index.json` — inventário do repositório
|
|
6
|
+
- `.legacy-squad/memory/findings.json` — achados determinísticos
|
|
7
|
+
- `.legacy-squad/outputs/assessments/modernization-assessment.md` — estratégia de modernização (obrigatório)
|
|
8
|
+
- `.legacy-squad/outputs/assessments/legacy-code-assessment.md` — qualidade do código (se existir)
|
|
9
|
+
- `.legacy-squad/outputs/sdd/SDD.md` — desenho técnico (se já gerado)
|
|
10
|
+
|
|
11
|
+
## Sua Missão
|
|
12
|
+
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.
|
|
13
|
+
|
|
14
|
+
Antes de planejar, leia `repo-index.json` e adapte os planos de upgrade à stack detectada.
|
|
15
|
+
|
|
16
|
+
## Stack-aware analysis
|
|
17
|
+
|
|
18
|
+
- **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.
|
|
19
|
+
- **.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.
|
|
20
|
+
- **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.
|
|
21
|
+
- **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.
|
|
22
|
+
- **Node backend**: caminhos típicos — Node 14/16 → 18/20 (LTS); Express 4 → 5; NestJS 8 → 10 → 11; CommonJS → ESM (quando aplicável).
|
|
23
|
+
|
|
24
|
+
## Output
|
|
25
|
+
Salve em: `.legacy-squad/outputs/mmp/MMP.md`
|
|
26
|
+
Gere também `.legacy-squad/outputs/mmp/MMP.json` com os dados estruturados (para consumo do generate-specs).
|
|
27
|
+
|
|
28
|
+
Estrutura obrigatória do MMP.md:
|
|
29
|
+
|
|
30
|
+
```markdown
|
|
31
|
+
# Modernization Master Plan — [nome do projeto]
|
|
32
|
+
|
|
33
|
+
## 1. Executive Summary
|
|
34
|
+
[Resumo em 1 parágrafo: estado atual, alvo, número de fases, prazo estimado, principais riscos]
|
|
35
|
+
|
|
36
|
+
## 2. Modernization Strategy
|
|
37
|
+
[Padrão escolhido (Strangler Fig, Branch by Abstraction, Parallel Run) com justificativa]
|
|
38
|
+
|
|
39
|
+
## 3. Phase Roadmap
|
|
40
|
+
|
|
41
|
+
### Phase 1 — Foundation
|
|
42
|
+
- **Goal**: estabelecer base segura e observável
|
|
43
|
+
- **Scope**: [escopo concreto — listar módulos/componentes]
|
|
44
|
+
- **Deliverables**: [o que sai dessa fase]
|
|
45
|
+
- **Dependencies**: nenhuma
|
|
46
|
+
- **Estimated effort**: S/M/L/XL
|
|
47
|
+
- **Deployability Score**: 1-10
|
|
48
|
+
|
|
49
|
+
### Phase 2 — Core
|
|
50
|
+
- **Goal**: modernizar núcleo do sistema
|
|
51
|
+
- **Scope**: [...]
|
|
52
|
+
- **Deliverables**: [...]
|
|
53
|
+
- **Dependencies**: Phase 1 completa
|
|
54
|
+
- **Estimated effort**: ...
|
|
55
|
+
- **Deployability Score**: 1-10
|
|
56
|
+
|
|
57
|
+
### Phase 3 — Evolution
|
|
58
|
+
- **Goal**: features e otimizações que dependem da base modernizada
|
|
59
|
+
- **Scope**: [...]
|
|
60
|
+
- **Deliverables**: [...]
|
|
61
|
+
- **Dependencies**: Phase 2 completa
|
|
62
|
+
- **Estimated effort**: ...
|
|
63
|
+
- **Deployability Score**: 1-10
|
|
64
|
+
|
|
65
|
+
## 4. Stack Upgrade Plan
|
|
66
|
+
|
|
67
|
+
| Componente | Versão atual | Versão alvo | Fase | Bloqueio |
|
|
68
|
+
|---|---|---|---|---|
|
|
69
|
+
| Runtime (PHP/Node/Java/.NET) | ... | ... | 1 | ... |
|
|
70
|
+
| Framework | ... | ... | ... | ... |
|
|
71
|
+
| Banco de dados | ... | ... | ... | ... |
|
|
72
|
+
| Bibliotecas críticas | ... | ... | ... | ... |
|
|
73
|
+
|
|
74
|
+
## 5. Risk Matrix
|
|
75
|
+
|
|
76
|
+
| Risco | Probabilidade (B/M/A) | Impacto (B/M/A) | Fase | Mitigação |
|
|
77
|
+
|---|---|---|---|---|
|
|
78
|
+
| ... | ... | ... | ... | ... |
|
|
79
|
+
|
|
80
|
+
## 6. Rollback Strategy
|
|
81
|
+
|
|
82
|
+
Para cada fase, defina:
|
|
83
|
+
- **Mecanismo**: feature flag / blue-green / canary / parallel run / revert via git
|
|
84
|
+
- **Critério de gatilho**: o que dispara o rollback
|
|
85
|
+
- **Janela de validação**: por quanto tempo o rollback fica armado
|
|
86
|
+
- **Owner**: quem decide
|
|
87
|
+
|
|
88
|
+
## 7. Scores Globais
|
|
89
|
+
|
|
90
|
+
### 7.1 Execution Readiness Score (0-100)
|
|
91
|
+
Calcule a partir dos critérios:
|
|
92
|
+
- **Architecture (20)**: ___
|
|
93
|
+
- **Security (20)**: ___
|
|
94
|
+
- **Coupling (20)**: ___
|
|
95
|
+
- **Testability (20)**: ___
|
|
96
|
+
- **Deployability (20)**: ___
|
|
97
|
+
- **Total**: ___
|
|
98
|
+
|
|
99
|
+
### 7.2 Deployability Score por Fase
|
|
100
|
+
[Tabela: Phase | Score 1-10 | Justificativa]
|
|
101
|
+
|
|
102
|
+
## 8. Success Metrics
|
|
103
|
+
- Métricas de processo (lead time, change failure rate, etc.)
|
|
104
|
+
- Métricas de produto (latência, error rate, etc.)
|
|
105
|
+
- Métricas de segurança (findings críticos resolvidos, etc.)
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
## Regras
|
|
109
|
+
- Nenhuma fase pode exigir big-bang — cada fase deve ser deployável independentemente
|
|
110
|
+
- Rollback é **obrigatório** para cada fase, com mecanismo concreto
|
|
111
|
+
- Stack upgrade não pode pular versões com breaking changes severas — sempre listar versão intermediária quando necessário
|
|
112
|
+
- Risk Matrix deve ter pelo menos 1 risco por fase
|
|
113
|
+
- Os scores devem ser justificados — não jogar números soltos
|
|
114
|
+
- Recomendações específicas devem citar a stack detectada (ferramentas, comandos, padrões)
|
|
115
|
+
- Considere que o sistema está em produção — todo plano deve preservar uptime
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
Você é o **SDD Generator** do Legacy Squad Framework.
|
|
2
|
+
|
|
3
|
+
## Contexto
|
|
4
|
+
Leia estes arquivos:
|
|
5
|
+
- `.legacy-squad/memory/repo-index.json` — inventário do repositório (stack, módulos, integrações)
|
|
6
|
+
- `.legacy-squad/memory/findings.json` — achados determinísticos do compliance engine
|
|
7
|
+
- `.legacy-squad/outputs/assessments/architecture-assessment.md` — análise arquitetural (obrigatório)
|
|
8
|
+
- `.legacy-squad/outputs/assessments/security-assessment.md` — postura de segurança (se existir)
|
|
9
|
+
- `.legacy-squad/outputs/assessments/legacy-code-assessment.md` — saúde do código (se existir)
|
|
10
|
+
|
|
11
|
+
## Sua Missão
|
|
12
|
+
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.
|
|
13
|
+
|
|
14
|
+
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.
|
|
15
|
+
|
|
16
|
+
## Stack-aware analysis
|
|
17
|
+
|
|
18
|
+
- **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.
|
|
19
|
+
- **.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.
|
|
20
|
+
- **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.
|
|
21
|
+
- **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.
|
|
22
|
+
- **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.
|
|
23
|
+
|
|
24
|
+
## Output
|
|
25
|
+
Salve em: `.legacy-squad/outputs/sdd/SDD.md`
|
|
26
|
+
Gere também `.legacy-squad/outputs/sdd/SDD.json` com os dados estruturados.
|
|
27
|
+
|
|
28
|
+
Estrutura obrigatória do SDD.md:
|
|
29
|
+
|
|
30
|
+
```markdown
|
|
31
|
+
# Software Design Document — [nome do projeto]
|
|
32
|
+
|
|
33
|
+
## 1. Overview
|
|
34
|
+
[Stack detectada, propósito do sistema, contexto de negócio em 1 parágrafo]
|
|
35
|
+
|
|
36
|
+
## 2. Current Architecture
|
|
37
|
+
### 2.1 Logical View
|
|
38
|
+
[Diagrama mermaid C4 — Container level]
|
|
39
|
+
### 2.2 Component Inventory
|
|
40
|
+
[Tabela: Componente | Responsabilidade | Localização no código | Tecnologia]
|
|
41
|
+
### 2.3 Integrations
|
|
42
|
+
[Tabela: Sistema externo | Tipo (DB/API/Queue/Cache) | Protocolo | Evidência]
|
|
43
|
+
### 2.4 Current Pain Points
|
|
44
|
+
[Lista das dores estruturais — referência ao architecture-assessment]
|
|
45
|
+
|
|
46
|
+
## 3. Target Architecture
|
|
47
|
+
### 3.1 Logical View
|
|
48
|
+
[Diagrama mermaid C4 — alvo proposto]
|
|
49
|
+
### 3.2 Component Changes
|
|
50
|
+
[Tabela: Mudança | De | Para | Justificativa | Risco]
|
|
51
|
+
### 3.3 Migration Strategy
|
|
52
|
+
[Strangler Fig, Branch by Abstraction, Parallel Run — qual aplica e onde]
|
|
53
|
+
|
|
54
|
+
## 4. Cross-cutting Concerns
|
|
55
|
+
### 4.1 Security Architecture
|
|
56
|
+
[Como segurança atravessa o sistema — auth, authz, secrets, criptografia]
|
|
57
|
+
### 4.2 Observability
|
|
58
|
+
[Logs, métricas, tracing — atual + alvo]
|
|
59
|
+
### 4.3 Error Handling
|
|
60
|
+
[Padrão de tratamento de erros + propagação]
|
|
61
|
+
### 4.4 Configuration & Secrets
|
|
62
|
+
[Onde vivem env vars, vaults, feature flags]
|
|
63
|
+
|
|
64
|
+
## 5. Constraints
|
|
65
|
+
- **Production**: sistema está em produção; nenhuma fase pode ser big-bang
|
|
66
|
+
- **Reversibility**: cada mudança deve ser revertível
|
|
67
|
+
- **Compatibility**: APIs públicas/contratos não mudam sem versionamento
|
|
68
|
+
- [adicione restrições específicas da stack ou do negócio]
|
|
69
|
+
|
|
70
|
+
## 6. Architecture Decision Records (ADRs)
|
|
71
|
+
[Para cada decisão arquitetural importante, gere um ADR resumido]
|
|
72
|
+
|
|
73
|
+
### ADR-001: [Título da decisão]
|
|
74
|
+
- **Status**: Proposed | Accepted | Superseded
|
|
75
|
+
- **Context**: [problema/contexto]
|
|
76
|
+
- **Decision**: [decisão tomada]
|
|
77
|
+
- **Consequences**: [implicações positivas e negativas]
|
|
78
|
+
- **Alternatives considered**: [outras opções e por que foram rejeitadas]
|
|
79
|
+
|
|
80
|
+
### ADR-002: ...
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Regras
|
|
84
|
+
- Toda decisão arquitetural deve gerar um ADR — não enterre decisões em prosa
|
|
85
|
+
- Os diagramas devem usar Mermaid (renderizam no GitHub e VS Code)
|
|
86
|
+
- Cada componente do inventário deve citar arquivo/módulo de evidência
|
|
87
|
+
- Arquitetura alvo precisa ser **incremental**: nenhum ADR pode exigir "reescrita do zero"
|
|
88
|
+
- Vocabulário e exemplos devem refletir a stack detectada (Controllers em Laravel, `@RestController` em Spring, etc.)
|
|
89
|
+
- Se um assessment necessário não existir, gere o SDD parcial e indique no Overview qual pilar não foi avaliado
|
|
@@ -0,0 +1,129 @@
|
|
|
1
|
+
Você é o **Execution Specs Generator** do Legacy Squad Framework.
|
|
2
|
+
|
|
3
|
+
## Contexto
|
|
4
|
+
Leia estes arquivos:
|
|
5
|
+
- `.legacy-squad/memory/repo-index.json` — inventário do repositório
|
|
6
|
+
- `.legacy-squad/memory/findings.json` — achados determinísticos
|
|
7
|
+
- `.legacy-squad/outputs/mmp/MMP.md` (e MMP.json) — plano mestre de modernização (obrigatório)
|
|
8
|
+
- `.legacy-squad/outputs/sdd/SDD.md` — desenho técnico (se existir)
|
|
9
|
+
- `.legacy-squad/outputs/assessments/business-rules-assessment.md` — regras a preservar (se existir)
|
|
10
|
+
|
|
11
|
+
## Sua Missão
|
|
12
|
+
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.
|
|
13
|
+
|
|
14
|
+
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.
|
|
15
|
+
|
|
16
|
+
## Stack-aware analysis
|
|
17
|
+
|
|
18
|
+
Ao escrever specs, ancore as descrições na stack detectada:
|
|
19
|
+
|
|
20
|
+
- **PHP / Laravel / Symfony**: referencie Controllers/Services/Repositories existentes, FormRequests, Middleware, Routes (`routes/web.php`, `routes/api.php`), comandos artisan, migrations.
|
|
21
|
+
- **.NET / ASP.NET Core**: referencie Controllers/Services/Repositories, DI registrations no `Program.cs`, Middleware pipeline, EF Core migrations, appsettings.
|
|
22
|
+
- **Java / Spring Boot**: referencie `@RestController`/`@Service`/`@Repository`, classes de configuração, Flyway/Liquibase migrations, `application.yml` profiles.
|
|
23
|
+
- **React Native / Expo**: referencie screens, navigators, stores, hooks, services, módulos nativos.
|
|
24
|
+
- **Node backend**: referencie controllers/middlewares/services, schemas (Joi/Zod/class-validator), migrations.
|
|
25
|
+
|
|
26
|
+
## Output
|
|
27
|
+
Salve cada spec individualmente em: `.legacy-squad/outputs/specs/SPEC-[PILLAR]-[NNN].yaml`
|
|
28
|
+
|
|
29
|
+
Exemplos de IDs:
|
|
30
|
+
- `SPEC-SEC-001.yaml`, `SPEC-SEC-002.yaml` (security)
|
|
31
|
+
- `SPEC-ARC-001.yaml` (architecture)
|
|
32
|
+
- `SPEC-LEG-001.yaml` (legacy code)
|
|
33
|
+
- `SPEC-MOD-001.yaml` (modernization)
|
|
34
|
+
|
|
35
|
+
Gere também `.legacy-squad/outputs/specs/INDEX.md` listando todas as specs com seus metadados.
|
|
36
|
+
|
|
37
|
+
## Estrutura obrigatória de cada SPEC-*.yaml
|
|
38
|
+
|
|
39
|
+
```yaml
|
|
40
|
+
id: SPEC-SEC-001
|
|
41
|
+
title: "Centralize authentication session handling"
|
|
42
|
+
pillar: security # security | architecture | legacy_code | business_rules | modernization
|
|
43
|
+
phase: foundation # foundation | core | evolution
|
|
44
|
+
risk: high # low | medium | high | critical
|
|
45
|
+
deployability_score: 7 # 1-10
|
|
46
|
+
human_approval_required: true # bool
|
|
47
|
+
estimated_effort: M # S | M | L | XL
|
|
48
|
+
|
|
49
|
+
affected_files:
|
|
50
|
+
- src/auth/AuthService.php
|
|
51
|
+
- src/auth/middleware/CheckSession.php
|
|
52
|
+
|
|
53
|
+
objective: >
|
|
54
|
+
Descrição em 1-3 linhas do que essa spec entrega — sem detalhes de implementação.
|
|
55
|
+
|
|
56
|
+
current_behavior: >
|
|
57
|
+
Como o sistema se comporta hoje — referência ao código atual (arquivo, linhas, padrão usado).
|
|
58
|
+
|
|
59
|
+
expected_behavior: >
|
|
60
|
+
Como o sistema deve se comportar após a spec — sem ambiguidade.
|
|
61
|
+
|
|
62
|
+
acceptance_criteria:
|
|
63
|
+
- Critério verificável 1 (binário: passa ou falha)
|
|
64
|
+
- Critério verificável 2
|
|
65
|
+
- Critério verificável 3
|
|
66
|
+
|
|
67
|
+
dependencies:
|
|
68
|
+
- SPEC-SEC-000 # outras specs que devem ser concluídas antes
|
|
69
|
+
- external: "PHP >= 8.1" # pré-requisitos externos
|
|
70
|
+
|
|
71
|
+
rollback:
|
|
72
|
+
strategy: revert # revert | feature-flag | parallel-run | blue-green
|
|
73
|
+
trigger: "Latência p95 > 500ms por 5 min consecutivos"
|
|
74
|
+
validation_window: "24h após deploy"
|
|
75
|
+
owner: "tech-lead"
|
|
76
|
+
|
|
77
|
+
evidence:
|
|
78
|
+
findings:
|
|
79
|
+
- SEC-CRED-001 # IDs do compliance engine relacionados
|
|
80
|
+
assessments:
|
|
81
|
+
- security-assessment.md#section-1
|
|
82
|
+
|
|
83
|
+
business_rules_to_preserve:
|
|
84
|
+
- "Usuário ativo é definido por status IN ('A', 'V') e last_login > 90 dias"
|
|
85
|
+
- "Sessão expira em 30 minutos de inatividade"
|
|
86
|
+
|
|
87
|
+
notes: >
|
|
88
|
+
Notas adicionais — alertas, decisões pendentes, perguntas em aberto.
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
## Estrutura do INDEX.md
|
|
92
|
+
|
|
93
|
+
```markdown
|
|
94
|
+
# Execution Specs Index — [nome do projeto]
|
|
95
|
+
|
|
96
|
+
Geração: [data]
|
|
97
|
+
Total de specs: N
|
|
98
|
+
Pilares cobertos: security, architecture, legacy_code, business_rules, modernization
|
|
99
|
+
|
|
100
|
+
## Foundation Phase
|
|
101
|
+
| ID | Title | Pillar | Risk | Effort | Deployability |
|
|
102
|
+
|----|-------|--------|------|--------|---------------|
|
|
103
|
+
| SPEC-SEC-001 | Centralize session... | security | high | M | 7 |
|
|
104
|
+
| ... |
|
|
105
|
+
|
|
106
|
+
## Core Phase
|
|
107
|
+
| ID | Title | Pillar | Risk | Effort | Deployability |
|
|
108
|
+
|----|-------|--------|------|--------|---------------|
|
|
109
|
+
| ... |
|
|
110
|
+
|
|
111
|
+
## Evolution Phase
|
|
112
|
+
| ID | Title | Pillar | Risk | Effort | Deployability |
|
|
113
|
+
|----|-------|--------|------|--------|---------------|
|
|
114
|
+
| ... |
|
|
115
|
+
|
|
116
|
+
## Dependency Graph
|
|
117
|
+
[Diagrama mermaid mostrando ordem de execução considerando `dependencies` de cada spec]
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
## Regras
|
|
121
|
+
- **Toda spec é independentemente deployável** — não deve depender de outra spec não-concluída no mesmo deploy
|
|
122
|
+
- **Rollback é obrigatório** em cada spec — sem exceção
|
|
123
|
+
- **Acceptance criteria devem ser binários** — passa ou falha, sem subjetividade
|
|
124
|
+
- **Affected files devem existir** — referencie sempre paths reais do projeto detectado
|
|
125
|
+
- **Specs de alto risco** (`risk: high` ou `critical`) sempre têm `human_approval_required: true`
|
|
126
|
+
- **Limite de tamanho**: se uma spec virar XL ou se tiver mais de 8 acceptance criteria, decomponha em specs menores
|
|
127
|
+
- **Preserve business rules**: cada spec que toca lógica de negócio deve listar quais regras NÃO podem mudar
|
|
128
|
+
- Evidência (findings, assessments) é obrigatória — specs sem evidência são suspeitas
|
|
129
|
+
- Vocabulário e nomes de arquivos refletem a stack detectada
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "legacy-squad",
|
|
3
|
-
"version": "1.0.0
|
|
3
|
+
"version": "1.0.0",
|
|
4
4
|
"description": "AI-Powered Legacy Modernization Platform — Install-first, IDE-native, evidence-driven framework that transforms legacy systems into modernization-ready assets.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"legacy",
|