sdg-agents 1.0.5

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/00-foundation/01-legacy-vision.md

@@ -0,0 +1,73 @@
+# 01 - Legacy Vision
+
+## Intervention Objective
+
+- Why are we touching this legacy system now?
+- What is the desired end state?
+
+## Scale and Magnitude
+
+- What is the current load (Users/Transactions)?
+- What is the projected load for the new system?
+
+## Budget and Resources
+
+- What is the monthly maintenance cost of the legacy system (infra + support)?
+- What is the maximum approved budget for the full migration?
+- Will the team be dedicated or manage the legacy in parallel?
+
+## Deadlines and Expectations
+
+- Final date for legacy decommissioning (Sunset date).
+- Progressive migration milestones.
+
+## Constraints
+
+- Maximum period for coexistence.
+- Budget or infrastructure limitations.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 01 - Legacy Vision
+
+## Objective
+
+Improve the old code.
+
+## Budget and Resources
+
+Whatever IT releases.
+
+## Constraints
+
+Until it's ready.
+```
+
+> **Rationale**: "Improve" is not a technical or business objective. Without a budget or deadline, the risk of failure is extremely high.
+
+### ✅ Good Example
+
+```markdown
+# 01 - Legacy Vision
+
+## Objective
+
+Ensure stability in the legacy billing system until full migration in Q4 2026.
+
+## Budget and Resources
+
+- **Budget**: $200k for stack modernization.
+- **Team**: 1 Architect and 2 Mid-level devs 100% focused on migration.
+
+## Deadlines and Expectations
+
+- **Decommissioning**: December 2026.
+- **Milestone**: 50% of users migrated by August.
+```
+
+> **Rationale**: Defines clear financial and temporal milestones, as well as a team allocation strategy.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/00-foundation/02-foundation-approval.md

@@ -0,0 +1,53 @@
+# 02 - Foundation Approval (Legacy)
+
+## Artifacts Checklist
+
+- [ ] 01-legacy-vision.md (Complete)
+
+## Stakeholder Approval
+
+- **Legacy Manager**: [Signature/Date]
+- **Technical Team**: [Signature/Date]
+
+## Definition of Readiness (Ready for Analysis)
+
+- [ ] Budget approved for initial audit.
+- [ ] Basic mapping of security risks completed.
+- [ ] Stakeholders agree on the stabilization/migration objective.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 02 - Foundation Approval
+
+## Checklist
+
+- [x] Filled.
+
+## Definition of Readiness
+
+- [x] Let's analyze.
+```
+
+> **Rationale**: How do you prove that the technical team agrees with the vision?
+
+### ✅ Good Example
+
+```markdown
+# 02 - Foundation Approval
+
+## Stakeholder Approval
+
+- **Manager**: Ferdinand Coast (Approved on 2026-06-05)
+
+## Definition of Readiness
+
+- [x] $50k budget for technical debt analysis approved.
+- [x] GDPR/LGPD risks documented in the vision.
+```
+
+> **Rationale**: Ensures formal approval and budget for the next critical stage.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/01-analysis/01-tech-debt-inventory.md

@@ -0,0 +1,55 @@
+# 01 - Technical Debt Inventory
+
+## Risk Mapping
+
+- Which modules are the most fragile?
+- Where are the biggest performance bottlenecks?
+
+## Obsolete Technologies
+
+- Unsupported libraries (e.g., Python 2.7, .NET 4.5).
+- Runtime versions (End-of-Life).
+
+## Cost of Inertia (Inertia vs. Migration)
+
+- **Financial Risk**: What is the estimated cost of a compliance fine or a data leak?
+- **Operational Cost**: How much time does the team lose "extinguishing fires" in the legacy system?
+- **Opportunity Cost**: Which new features are we failing to launch?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 01 - Technical Debt Inventory
+
+## Risk Mapping
+
+The code is confusing and full of if-statements.
+
+## Cost of Inertia
+
+We're losing time cleaning the code.
+```
+
+> **Rationale**: "Confusing" and "losing time" are sentimental metrics, not executive ones. They do not justify the investment of a migration.
+
+### ✅ Good Example
+
+```markdown
+# 01 - Technical Debt Inventory
+
+## Risk Mapping
+
+`OrderProcessor` module is highly coupled to `DBContext`, making unit testing impossible.
+
+## Cost of Inertia
+
+- **Operational**: The team spends 60% of the sprint fixing recurring bugs in the legacy system.
+- **Economic**: Monthly maintenance of the legacy server costs 3x more than a modern serverless instance.
+- **Risk**: Potential $500k fine due to the lack of audit logs required by the new banking regulation.
+```
+
+> **Rationale**: Transforms technical debt into **business numbers**. A 60% loss in productivity and real fines are unbeatable arguments for project approval.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/01-analysis/02-security-audit.md

@@ -0,0 +1,63 @@
+# 02 - Legacy Security Audit
+
+## Current Vulnerabilities Identification
+
+- Are there CVEs (known vulnerabilities) in obsolete libraries?
+- Were secrets (passwords, API keys) found hardcoded in the code?
+
+## Attack Surface Mapping
+
+- Which ports and services are unnecessarily exposed?
+- Which insecure protocols (e.g., HTTP, SSL v2/v3) are still permitted?
+
+## Compliance Audit (LGPD/GDPR)
+
+- What sensitive data is handled without encryption or anonymization?
+- Does the current system meet the minimum legal privacy requirements?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 02 - Legacy Security Audit
+
+## Current Vulnerabilities
+
+The system is old but has never been hacked.
+
+## Attack Surface
+
+Normal internet.
+
+## Compliance Audit
+
+I think everything is fine with LGPD.
+```
+
+> **Rationale**: "Never been hacked" is not a guarantee of security. "Normal internet" and "I think it's fine" are unacceptable answers for a staff engineer.
+
+### ✅ Good Example
+
+```markdown
+# 02 - Legacy Security Audit
+
+## Current Vulnerabilities
+
+- 45 critical vulnerabilities (CVE-2021-xxxx) in the Django 1.8 framework.
+- AWS Production API key found in the `settings.py` file.
+
+## Attack Surface
+
+- Port 21 (FTP) open on the application server, allowing anonymous access.
+- Support for TLS 1.0 and 1.1 still active (vulnerable to BEAST/POODLE).
+
+## Compliance Audit
+
+- Patient health data stored in plain text in the database.
+- Absence of user consent logs (LGPD non-compliance).
+```
+
+> **Rationale**: Identifies specific vulnerabilities, insecure open ports, and serious legal compliance failures.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/01-analysis/03-regression-baseline.md

@@ -0,0 +1,49 @@
+# 03 - Regression Baseline (Security Tests)
+
+## Critical Flow Coverage
+
+- How will we ensure that the refactoring/migration won't break current functionalities?
+- What are the "Golden Paths" (most critical business routes) that must have _End-to-End_ (E2E) tests?
+
+## Assertion Tools
+
+- Which tool will be used to record the current behavior of the legacy system before altering it (e.g., Playwright, Cypress, Postman Collections)?
+- Is there any load/stress test (e.g., k6) mapped to ensure the new code performs as well as or better than the legacy one?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 03 - Regression Baseline
+
+## Coverage
+
+We'll test it manually before uploading.
+
+## Tools
+
+The QA will use their Postman.
+```
+
+> **Rationale**: Refactoring legacy systems without automated regression tests is like jumping out of a plane without a methodological parachute. "Manual testing" creates bias and overlooks _edge cases_.
+
+### ✅ Good Example
+
+```markdown
+# 03 - Regression Baseline
+
+## Critical Flow Coverage
+
+- **Mapped Routes**: `POST /checkout` and `GET /invoice/:id`.
+- **Strategy**: 100% success coverage on these two flows via E2E tests running in a mirrored Legacy _Staging_ environment.
+
+## Assertion Tools
+
+- **Automated E2E**: Playwright (Scripts in the `qa-legacy-suite` repository).
+- **Performance Validation**: k6 script to prove that the new Cart route in Node.js matches the 150ms of the old PHP one.
+```
+
+> **Rationale**: Creates a real "electric fence." The developer has the peace of mind to rip out parts of the system knowing that Playwright will immediately notify them if they broke the old business logic.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/01-analysis/04-analysis-approval.md

@@ -0,0 +1,65 @@
+# 04 - Analysis Approval
+
+## Artifacts Checklist
+
+- [ ] 01-tech-debt-inventory.md (Complete)
+- [ ] 02-security-audit.md (Mapped)
+- [ ] 03-regression-baseline.md (Approved / "Electric Fence" enabled)
+
+## Technical Approval
+
+- **Solutions Architect**: [Signature/Date]
+- **Security Lead**: [Signature/Date]
+- **QA Engineer**: [Signature/Date]
+
+## Definition of Readiness (Ready for Strategy)
+
+- [ ] Legacy critical failure points identified.
+- [ ] Libraries with security CVEs mapped.
+- [ ] Clear understanding of data coupling.
+- [ ] Initial E2E/Regression test suite running green on the current legacy system.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 04 - Analysis Approval
+
+## Checklist
+
+- [x] Tech debt listed.
+
+## Definition of Readiness
+
+- [x] Ready to choose the strategy.
+```
+
+> **Rationale**: How do you prove that security was involved in the analysis? Where are the tests ensuring the legacy system works before you touch it?
+
+### ✅ Good Example
+
+```markdown
+# 04 - Analysis Approval
+
+## Checklist
+
+- [x] 01-tech-debt-inventory.md (Approved)
+- [x] 02-security-audit.md (Approved)
+- [x] 03-regression-baseline.md (Approved: 95% of Cart Flow guaranteed by E2E Playwright)
+
+## Technical Approval
+
+- **Architect**: Sandra Adams (2026-06-15)
+- **Security**: Paul Mendez (2026-06-16)
+
+## Definition of Readiness
+
+- [x] OWASP scanner executed on the legacy system with 15 vulnerabilities mapped.
+- [x] `Payment` module identified as the most critical for refactoring.
+- [x] Legacy Purchase Flow E2E test suite ran successfully 3 times in the pipeline.
+```
+
+> **Rationale**: Evidence of security scanning, technical hot-spot identification, and, fundamentally, proven regressive protection (_Ready to break_ safely).

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/02-strategy/01-modernization-approach.md

@@ -0,0 +1,60 @@
+# 01 - Modernization Approach
+
+## Chosen Strategy
+
+- [ ] Rehost, [ ] Refactor, [ ] Rearchitect, etc.
+
+## Coexistence Pattern
+
+- How will the legacy system talk to the new one?
+
+## Security in Transition
+
+- How will credentials be shared (Single Sign-On)?
+- How do we ensure that the weaker system (Legacy) does not compromise the new one?
+
+## Interface Modernization (UX/UI)
+
+- Will we keep the legacy UI or migrate to a new Design System?
+- How will the visual transition be for the end user?
+
+## AI Opportunities in Legacy
+
+- How can AI automate manual processes of the old system?
+- Data extraction (OCR/LLM) from legacy documents.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 01 - Modernization Approach
+
+## Interface Modernization
+
+Make the frontend more modern.
+
+## AI Opportunities
+
+Put a chat in the old system.
+```
+
+> **Rationale**: "Modern" is subjective. "Chat in the old system" might be an error if the backend is not stable enough to provide reliable data to the AI.
+
+### ✅ Good Example
+
+```markdown
+# 01 - Modernization Approach
+
+## Interface Modernization (UX/UI)
+
+Migration to the new Design System in React, replacing Delphi screens via controlled iframe (Progressive Isolation).
+
+## AI Opportunities
+
+Implement an Agent via MCP for automated data extraction from old invoices that do not have an API.
+```
+
+> **Rationale**: Defines interface technologies (React, iframe) and a real AI use case (MCP/OCR) to "save" inefficient legacy processes.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/02-strategy/02-versioning-and-coexistence.md

@@ -0,0 +1,57 @@
+# 02 - Versioning and Coexistence Strategy
+
+## Versioning and Code Freeze
+
+- What will be the repository strategy? (Create a NEW repository from scratch or create a `modernization` branch in the current repository?)
+- Will there be a `Code Freeze` (pause on new features) in the legacy system during modernization? If not, how will new legacy features sync with the new architecture?
+
+## Traffic Routing (Strangler Fig)
+
+- How will users access the new system? (Gradually via **Feature Flags**, or a overnight **Big Bang** migration)?
+- Will the **API Gateway** or **Load Balancer** be configured to direct specific calls (e.g., `/api/v2/orders`) to the new system and the rest to the legacy one?
+
+## User Interface (Micro-frontends / iFrames)
+
+- If the interface also changes, will the new interface screen coexist in the legacy window via `<iframe>`, Federated Modules (Webpack), or will the user transition between tabs/domains (e.g., `legacy.app.com` -> `app.com`)?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 02 - Versioning and Coexistence
+
+## Versioning
+
+We'll write the code in a separate repository. The maintenance team continues in the other one.
+
+## Routing
+
+Once finished, we switch the DNS to the new server on a Saturday night.
+```
+
+> **Rationale**: The famous "Big Bang." Statistically, the chance of a Big Bang failure is massive, resulting in the classic "Rollback Sunday." Two teams running in parallel without a bridge causes divergence of rules in production.
+
+### ✅ Good Example
+
+```markdown
+# 02 - Versioning and Coexistence
+
+## Versioning and Code Freeze
+
+- Separate repositories.
+- **No Code Freeze**: However, the maintenance team _must_ notify the modernization squad if any Legacy DB Model undergoes an `.alter table`.
+
+## Routing (Strangler Fig)
+
+- **Strangler Fig Pattern** standard with proxy (NGINX/Kong).
+- Traffic will be transferred endpoint-by-endpoint. Once `v2/sales` in the new language is completed, Kong starts routing 15% of that sales traffic to the new server while keeping the rest (85%) of the traffic on PHP.
+
+## Coexistence
+
+- The user will feel as if they are in the same system. The Legacy portal header will have the "Sales" button pointing to the new micro-frontend via Cloudfront.
+```
+
+> **Rationale**: "Thin Slices" approach. Failure risk is isolated to smaller endpoints, allowing modernization to deliver value in the first week of deployment rather than only in 6 months during a single event.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/02-strategy/03-new-demands-triage.md

@@ -0,0 +1,41 @@
+# 03 - New Demands Triage (Triage Matrix)
+
+A legacy modernization creates a "Tug of War" between the team migrating the system and the Product (PMs) / Sales area that keeps requesting _new features (New Buttons)_ all the time. The Decision Tree below shields the system to avoid building eternal "trash" on the old platform.
+
+## Decision Support Tree (Where to Develop)
+
+For each new "Epic" requested during the migration, the Tech Lead must apply the following questionnaire:
+
+1. **Does the requested feature touch modules that will be decommissioned in less than 6 months?**
+   - **Yes:** Reject in the Legacy system, unless it is Critical/Legal Compliance (Bugfix/Tax). Only perform workarounds or advance the schedule in the New Architecture.
+2. **Is it a functionality completely independent of the current core?** (e.g., A new SMS sending module)
+   - **Yes:** Build **100% in the New Ecosystem** (Microservice or V2) and integrate via API Bridge/Strangler Fig so that Legacy screens can call it without cluttering the internal logic.
+3. **Does the Cost x Benefit require it to be in the Legacy system?**
+   - Injecting into the spaghetti code will take X hours, but we'll refactor it regardless. How can we deliver quickly _now_ without blocking future database migrations? (e.g., Add-only table extension).
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Matrix
+
+Every new button goes into the new system, and the old system only gets bug fixes.
+```
+
+> **Rationale**: Too simplistic. How will the user use something in the "new" system if Single Sign-On hasn't been created yet? An automatic "no" will generate unsustainable friction with the PM, who will demand it go into the Legacy system to serve the customer tomorrow.
+
+### ✅ Good Example
+
+```markdown
+# Feature Triage: "Loyalty and Cashback Module"
+
+- **Request:** Massive new module.
+- **Legacy Analysis:** The PHP 5 Legacy system will make complex calls to calculate cashback.
+- **Decision (Strangler Fig):** The Cashback calculation will be built in the NEW architecture (Python V2) as an isolated endpoint (`/api/v2/cashback`).
+- **Integration:** We will add 20 lines in the old PHP just to perform the HTTP request passing `{user_id, sale_total}` to the new API. All computational heavy lifting, New Postgres Database, and logic will remain shielded in the new software!
+```
+
+> **Rationale**: Resolves the Product Manager's pain point (delivering Sales tomorrow) while protecting the Staff-level architecture. You delivered the tied value to the end customer using the old screens but built the solid, portable "castle" in the new backend.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/02-strategy/04-strategy-approval.md

@@ -0,0 +1,56 @@
+# 04 - Strategy Approval
+
+## Artifacts Checklist
+
+- [ ] 01-modernization-approach.md (Strategy, UX, and AI defined)
+- [ ] 02-versioning-and-coexistence.md (Strangler Fig / Branches / Deploy)
+
+## Strategic Approval
+
+- **Chief Technology Officer (CTO)**: [Signature/Date]
+- **Technical Lead (Staff)**: [Signature/Date]
+
+## Definition of Readiness (Ready for Refactor)
+
+- [ ] Decision between Refactoring vs. Replacement formalized.
+- [ ] UX Modernization decision (Maintain vs. New DS) made.
+- [ ] AI Opportunities (Automation/Extraction) evaluated.
+- [ ] Network routing pattern (e.g., Proxy/API Gateway) designed to isolate the new from the old.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 04 - Strategy Approval
+
+## Checklist
+
+- [x] We're going to rewrite.
+
+## Definition of Readiness
+
+- [x] Team excited to code.
+```
+
+> **Rationale**: How do you ensure that user traffic correctly reaches the refactored version the team is supposedly "excited" to code?
+
+### ✅ Good Example
+
+```markdown
+# 04 - Strategy Approval
+
+## Strategic Approval
+
+- **CTO**: Andrew Vanes (Approved on 2026-06-25)
+
+## Definition of Readiness
+
+- [x] Strangler Fig pattern chosen for the Cart module and AWS API Gateway configured.
+- [x] UX Strategy: New Design System in React (Coexistence via Web Components).
+- [x] Code Freeze: Legacy User tables frozen for any `Migration` involving `DROP`.
+```
+
+> **Rationale**: Specific technical decision (Strangler Fig/AWS), interface strategy (Web Components), and clear coexistence rules (Code Freeze) documented at the ecosystem level.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/03-refactor/01-cleanup-backlog.md

@@ -0,0 +1,45 @@
+# 01 - Refactoring Backlog
+
+## Priority Cleanups
+
+- Which files/modules will be cleaned first?
+
+## Patterns to Apply
+
+- [ ] Interface extraction.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 01 - Refactoring Backlog
+
+## Priority Cleanups
+
+Sales and Database Module.
+
+## Patterns to Apply
+
+Clean Code.
+```
+
+> **Rationale**: "Sales" is too broad. "Clean Code" is not a specific refactoring pattern.
+
+### ✅ Good Example
+
+```markdown
+# 01 - Refactoring Backlog
+
+## Priority Cleanups
+
+SQL Repository in `infra/repository/order.sql`.
+
+## Patterns to Apply
+
+Dependency Injection and Interface Extraction to enable Mocks in tests.
+```
+
+> **Rationale**: Focuses on real technical improvements (Mocks/Testing) and components that can be isolated.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/03-refactor/02-refactor-approval.md

@@ -0,0 +1,53 @@
+# 02 - Refactoring Approval
+
+## Artifacts Checklist
+
+- [ ] 01-cleanup-backlog.md (Prioritized)
+
+## Technical Approval
+
+- **Tech Lead**: [Signature/Date]
+- **Development Team**: [Signature/Date]
+
+## Definition of Readiness (Ready for Migration)
+
+- [ ] Critical code extracted into interfaces.
+- [ ] Regression tests (Unit/Integration) cover 80% of the changes.
+- [ ] The monolith is stable for the final migration.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 02 - Refactoring Approval
+
+## Checklist
+
+- [x] We ran the linter.
+
+## Definition of Readiness
+
+- [x] The code is pretty.
+```
+
+> **Rationale**: "Pretty code" is not an operational readiness criterion for migration.
+
+### ✅ Good Example
+
+```markdown
+# 02 - Refactoring Approval
+
+## Technical Approval
+
+- **Lead**: Mark Oliver (2026-07-10)
+
+## Definition of Readiness
+
+- [x] SQL Repository isolated under a common interface.
+- [x] Integration test suite via Docker running in the CI.
+```
+
+> **Rationale**: Focuses on technical isolation and test automation to ensure the security of the migration.