sdg-agents 1.0.5

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

@@ -0,0 +1,47 @@
+# 01 - Migration Roadmap
+
+## Migration Steps
+
+1.  [ ] Parallel infrastructure setup.
+2.  [ ] Database migration.
+
+## Final Checklist
+
+- [ ] 0 critical bugs in the new system.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 01 - Migration Roadmap
+
+## Steps
+
+Move everything tomorrow and re-test.
+
+## Checklist
+
+App 100% live.
+```
+
+> **Rationale**: "Tomorrow" is not a roadmap. "100% live" ignores quality or consistency.
+
+### ✅ Good Example
+
+```markdown
+# 01 - Migration Roadmap
+
+## Steps
+
+Configure RDS Read Replica -> New Cloud Instance from October 1st to 31st.
+
+## Checklist
+
+- [x] Data Sync < 10ms (replica lag).
+- [x] 100% of users migrated via DNS redirection.
+```
+
+> **Rationale**: Defines technologies (RDS, DNS) and technical success metrics (latency and users).

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

@@ -0,0 +1,56 @@
+# 02 - Data Sync and Load Strategy
+
+## Synchronization Model (Sync)
+
+- Will data need to be synchronized in real-time between the Legacy and New systems? Or will there be an asynchronous maintenance window (e.g., Midnight Batch)?
+- Will the synchronization flow be Unidirectional (Legacy -> New) or Bidirectional (updates in one reflect in the other)?
+
+## ETL Track (Extract, Transform, Load)
+
+- Which tool or script will ensure the conversion of old data (e.g., a formatted string `"1"`) to the new typing in the database (pure _Boolean_)?
+- Will there be a mirror table or _Read-replica_ to offload the main legacy database during migration?
+
+## Rollback and Legacy Disposal
+
+- What are the criteria and estimated timeframe for safely "switching off" the old database after the new one becomes operational?
+- How will an emergency rollback re-synchronize data that had already been persisted only in the modern database?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 02 - Data Synchronization
+
+## Sync Model
+
+We'll keep writing to the new API and hope the legacy system doesn't need to read it.
+
+## ETL Track
+
+Copy MySQL data using a Python script at the end of the day.
+```
+
+> **Rationale**: How does the operation remain online while the Python script runs freely? If the script fails halfway through, we break both databases simultaneously.
+
+### ✅ Good Example
+
+```markdown
+# 02 - Data Synchronization
+
+## Sync Model
+
+- **Continuous Bidirectional**: We will use Debezium (CDC - Change Data Capture) to listen for changes from MongoDB (Legacy) to PostgreSQL (New) via Kafka. The user microservice will trigger the reverse via the Legacy API in the callback.
+
+## ETL Track
+
+- **Clean Load Batch**: Heavy historical migrations will be done at 03:00 AM (Sunday) using optimized routines via AWS Glue, mapping obsolete columns to `.jsonb`.
+
+## Disposal
+
+- **Shadow DB Period**: The old database will run in _Read-Only_ mode for 14 days post-migration. If PostgreSQL breaks irreversibly, we use a reverse Glue script and flip the router switch back to MongoDB.
+```
+
+> **Rationale**: Fault-tolerant approach. Based on the industrial CDC model (real-time events), drastically reducing inconsistencies for users of the mixed system.

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

@@ -0,0 +1,55 @@
+# 03 - Migration Approval
+
+## Artifacts Checklist
+
+- [ ] 01-migration-roadmap.md (Defined)
+- [ ] 02-data-sync-strategy.md (Successfully tested n-times)
+
+## Operational Approval
+
+- **SRE / DevOps**: [Signature/Date]
+- **Operations / Support Team**: [Signature/Date]
+
+## Definition of Readiness (Ready for Rollout)
+
+- [ ] _Dry-run_ (Shadow Load) of data migration completed successfully.
+- [ ] Rollback plan tested and time limit metrics approved (e.g., MTTR < 10min).
+- [ ] Maintenance window officially communicated to corporate stakeholders.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 03 - Migration Approval
+
+## Checklist
+
+- [x] Migrate and re-test.
+
+## Definition of Readiness
+
+- [x] Script is on the machine and ready to run and switch the APIs.
+```
+
+> **Rationale**: How do you prove that the migration script doesn't corrupt Database B? And worse, if it does, how do you switch the user back to an intact Database A?
+
+### ✅ Good Example
+
+```markdown
+# 03 - Migration Approval
+
+## Operational Approval
+
+- **DevOps**: Bruno Costa (Approved on 2026-07-20)
+
+## Definition of Readiness
+
+- [x] 01-migration-roadmap.md (Window set for Saturday 02:00 AM)
+- [x] 02-data-sync-strategy.md (Bidirectional Kafka synchronization tested)
+- [x] Rollback tested in an isolated environment (DNS router takes 59 seconds to cancel the migration if the new infra health check turns red).
+```
+
+> **Rationale**: Showcases high operational maturity evidence. Data synchronization and rollback activation times are metered, converting the chaotic, critical moment of a legacy deployment into a controlled procedure.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/05-sunset/01-decommission-plan.md

@@ -0,0 +1,47 @@
+# 01 - Decommissioning Plan (Sunset Plan)
+
+The Sunset Plan is the final stage of modernizing a legacy (Brownfield) system. Once 100% of routes and data are in the new system, the old one MUST be deactivated. Unmaintained code left online becomes the primary gateway for security failures in the company.
+
+## Phase 1: Isolation and Read-Only Modes
+
+- **Redirection:** Is all legacy domain traffic now (via proxy/DNS) traveling strictly to the new software?
+- **Freezing:** Was the legacy database locked as `Read-Only` to prevent forgotten users or routines from continuing to create technical trash?
+
+## Phase 2: Termination and Physical Decommissioning
+
+- **Orphan Dependencies:** Did we delete all crons and scheduled routines (background jobs)?
+- **The End:** Official shutdown of the legacy virtual machine (EC2), cluster, or app service.
+- **Data Retention & Backups:** Was the legacy database dump stored in cold storage (e.g., Amazon S3 Glacier) for the legal retention period before deleting the hot database in the cloud?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Shutdown
+
+The new software launched last week. We stopped using the old one. At the end of the year, the sysadmin deletes the server.
+```
+
+> **Rationale**: Extremely dangerous. What ensures that no B2B customer continues using the old backend API? If the old dashboard has vulnerabilities and continues running without maintenance until the end of the year, hackers will use this bridge to steal data (Shadow IT).
+
+### ✅ Good Example
+
+```markdown
+# Decommissioning Plan: Sales Module V1
+
+## Phase 1: Isolation
+
+- The `/v1/sales` routes were configured via Nginx to trigger a `301 Redirect` to the new `/v2/sales`.
+- The Legacy MySQL DB had its `writer` password revoked, operating only as a `read-only replica`. It will remain this way for 15 days (Smoke Monitoring Period).
+
+## Phase 2: Physical Decommissioning (2026-08-20)
+
+- Shutdown of all V1 EC2 instances identified under the AWS Tag `env:legacy-sales`.
+- Full dump generated and sent to **S3 Deep Glacier** with a Lifecycle rule for definitive purge in 5 years (Tax/Legal Compliance).
+- Definitive Drop of the legacy RDS database, resulting in a saving of $850/month of Cloud TCO.
+```
+
+> **Rationale**: Pure professionalism. Shutting down software is as technically considered as building it. We mitigate failures, handle accounting data retention, and celebrate the exact savings in infrastructure dollars.

package/src/assets/dev-guides/prompt-tracks/02-legacy-modernization/05-sunset/02-sunset-approval.md

@@ -0,0 +1,60 @@
+# 02 - Approval: Sunset and Final Decommissioning
+
+## Artifacts Checklist
+
+- [ ] 01-decommission-plan.md (Evidence of Read-Only applied and DNS redirections).
+
+## Executive Approval (The Farewell)
+
+- **Migration Tech Lead**: [Signature/Date]
+- **Cost/Finance Team (FinOps)**: [Signature/Date]
+- **Product Owner (PM)**: [Signature/Date]
+
+## Modernization Completion Definition
+
+- [ ] Legacy domain no longer routes active traffic (0 status usage in API Gateway).
+- [ ] Final backup exported for retention (Cold Storage).
+- [ ] Invoices (Billing) confirm that legacy instances have been removed from the cloud cost.
+- [ ] Old DNS officially pointing 100% to the New Ingress Controller.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Sunset Approval
+
+## Checklist
+
+- [x] We turned everything off.
+
+## Completion Definition
+
+- [x] The system stopped billing.
+```
+
+> **Rationale**: Turned everything off "when" and "how"? What about the 5 years of backups required by law? The migration failed at a quiet point.
+
+### ✅ Good Example
+
+```markdown
+# Sunset Approval: Complete Extinction
+
+## Final Approvals
+
+- **Tech Lead**: Renato Vanes (2026-09-20) confirmed via Datadog 0 RPS in the Legacy Node for 30 uninterrupted days.
+- **FinOps**: Claire River (2026-09-21) proved the removal of the old AKS cluster and the T3 RDS database in the Cost panel. ~$2,500 reduction validated!
+
+## Completion Definition (The Trophy)
+
+- [x] Glacier retention approved by the Chief Legal Officer.
+- [x] Legacy CNAME DNS changed to ALB v2.
+
+## Project Completion Ceremony
+
+Modernization officially Closed. The legacy GitHub repository `vendas-delphi-legacy` has been Archived. 🚀
+```
+
+> **Rationale**: Monumental closing of Staff-level work. No loose ends, official cost reduction with FinOps endorsing the project's ROI, dead files secured, and repo "Archived." Everyone celebrates a shielded transition.

package/src/assets/dev-guides/prompt-tracks/README.md

@@ -0,0 +1,144 @@
+# Specification Pipeline
+
+This directory establishes the technical governance and architectural baseline for the project. The core protocol mandates that **no implementation should precede its corresponding specification**.
+
+> [!TIP]
+> **AI Orchestration**: These templates provide high-context engineering standards for AI agents. Proper specification ensures technical density and prevents architectural drift.
+
+---
+
+## Development Tracks
+
+### 00 - Lite Mode (Freelance & MVP)
+
+Standardized flow for rapid iteration on small-scale projects, proofs of concept, and utility tools.
+
+- **Pipeline**: Scope → Stack → Integration.
+- **Location**: `.ai/prompts/dev-tracks/00-lite-mode/`
+
+### 01 - New Evolution (Greenfield)
+
+Primary flow for new system features, domain modules, or greenfield project architecture.
+
+- **Pipeline**: Foundation → Setup → Architecture → Security → Delivery → Features → Evolution.
+- **Location**: `.ai/prompts/dev-tracks/01-new-evolution/`
+
+### 02 - Legacy Modernization (Brownfield)
+
+Standardized protocol for technical rescue, refactoring, and legacy system migration.
+
+- **Pipeline**: Foundation → Analysis → Strategy → Refactoring → Migration.
+- **Location**: `.ai/prompts/dev-tracks/02-legacy-modernization/`
+
+---
+
+## Engineering Principles
+
+1.  **Mandatory Sequential Execution**: Never advance to the next pipeline stage without completing the previous one.
+2.  **Logic over Code**: A feature implementation is only permitted after the **Architecture & Data Model** are consolidated.
+3.  **Local Numeric Prefixing**: All files maintain sequential numbering within their respective folders to preserve the logical order of each stage.
+4.  **Gatekeepers**: Feature development (Phase 04) is only permitted after the Delivery stage (Phase 03) is ready (CI/CD, Linting, and Quality).
+
+---
+
+## Specification Standard (Feature)
+
+Every new functionality in the `04-features` directory follows this standard:
+
+```markdown
+# [ID]- [Feature Name]
+
+## Context
+
+- Problem to be solved and expected business/system impact.
+
+## Scope
+
+- Planned deliverables vs. Non-goals (what will NOT be covered).
+
+## Business Rules
+
+- Critical validations, success cases, and exception flows.
+
+## Architecture & Design
+
+- Integration points, API contracts, and Schema changes.
+
+## Implementation Roadmap
+
+- Concrete steps for the AI Agent or Developer to follow.
+```
+
+---
+
+## Staff Engineering Examples
+
+### ❌ Bad Example (AI Slop / Generic)
+
+```markdown
+# 04-01 - System Improvement
+
+## Context
+
+Improve the system for users and increase sales.
+
+## Scope
+
+Everything to make it good. No non-goals.
+
+## Business Rules
+
+Fast system. Users can buy things.
+
+## Architecture & Design
+
+Market best practices. DB integration.
+
+## Implementation Roadmap
+
+1. [ ] Code it. 2. [ ] Test it.
+
+## Testing Strategy
+
+Test everything.
+```
+
+> **Rationale**: Vague, lacks metrics, no technical definitions, and no clear acceptance criteria. Pure "AI slop".
+
+### ✅ Good Example (Staff Quality)
+
+```markdown
+# 04-01 - One-Click Checkout (Stripe)
+
+## Context
+
+Reduce cart abandonment during the final payment stage.
+**Success Metric**: 15% increase in conversion for returning users.
+
+## Scope
+
+- Integration with Stripe Vault for saved tokens.
+- **Non-Goals**: Full gateway migration or local card storage (PCI Compliance).
+
+## Business Rules
+
+- Only logged-in users with a valid `stripe_customer_id`.
+- Synchronous stock check before `PaymentIntent` confirmation.
+
+## Architecture & Design
+
+- **Integration**: `StripeService` + `OrderOrchestrator`.
+- **Constraint**: All IDs must follow the `chkt_` prefix for traceability.
+
+## Implementation Roadmap
+
+1. [ ] Create inventory pre-validation webhook.
+2. [ ] Implement Stripe Elements in the Guest Checkout flow.
+
+## Testing Strategy
+
+- **Scenario A**: Success with cached card and >0 stock.
+- **Scenario B**: Atomic rollback if payment fails after stock reservation.
+```
+
+> **Rationale**: Specific objectives, business metrics, clear boundaries, and atomic error handling strategies.

package/src/assets/dev-guides/software-development-lifecycle-sdlc.md

@@ -0,0 +1,147 @@
+# Software Development Life Cycle — SDLC (8-Phase Core Trail)
+
+This document defines the technical standards for the project lifecycle. It establishes the baseline for developer onboarding and architectural alignment through 8 cumulative phases.
+
+> [!IMPORTANT]
+> **Documentation Governance**: Update **README**, **CHANGELOG**, and **ROADMAP** at the end of every phase. Documentation must remain synchronized with the implementation to prevent knowledge debt.
+
+## Pipeline Summary
+
+```
+| 01 Foundation        → Project boots and lints cleanly
+| 02 Observability     → Internal state is transparent
+| 03 CI/CD             → Code quality gates are enforced
+| 04 Access Control    → Identity and permissions are established
+| 05 Design System     → UI is consistent and reusable
+| 06 Features          → Domain logic is isolated
+| 07 Production Ready  → Deployment readiness verified
+| 08 Ops Governance    → System health is monitored
+```
+
+Not every project requires all 8 phases. A CLI tool implements focused subsets (e.g., 01, 03, 06), while a SaaS product requires the full trail.
+
+> [!IMPORTANT]
+> **Lifecycle Protocol**: No phase is complete until the implementation is synchronized with the project metadata.
+
+---
+
+## How to read this guide
+
+The pipeline follows a **strict cumulative logic**. Each phase establishes the security and stability required for subsequent steps. Select the appropriate scope for the project stack while maintaining the 01-08 sequence.
+
+---
+
+## 01 — Foundation
+
+Set up the project so that every contributor starts from the same baseline.
+
+1. Initialize git with a **Hardened .gitignore**. Block environment noise (`.DS_Store`, `local.*`) and tool-specific artifacts.
+2. Enforce **Secret Isolation**. Explicitly block `.env*` and credential files. Never commit secrets to the repository history.
+3. Create the **Documentation Baseline**. Initialize `README.md`, `CHANGELOG.md`, and `ROADMAP.md`.
+4. Create `.editorconfig` to enforce indentation and encoding standards.
+5. Configure a linter (e.g., ESLint) aligned with the project scope.
+6. Create a HelloWorld entry point to validate the execution stack.
+7. Install core dependencies. Avoid speculative package installation.
+8. Configure environment variables via `.env` with startup validation.
+9. Structure the entry point as a table of contents. Keep implementation details in secondary modules.
+
+**Criteria**: The project boots, lints, and allows a contributor to run the suite in under 5 minutes.
+
+---
+
+## 02 — Observability & Security
+
+Make the project observable and defensible before writing business logic.
+
+1. Validate all external inputs at the boundary (request body, query params, headers). Reject invalid data early.
+2. Add a `/health` endpoint that returns the application status and dependency connectivity.
+3. Set up structured logging (JSON format). Include request ID, timestamp, and severity. Never log secrets or PII.
+4. If applicable, add distributed tracing (OpenTelemetry or equivalent) so requests can be followed across services.
+5. Define your testing strategy: what gets unit tests, what gets integration tests, what gets E2E.
+
+**Done when:** you can answer "is the app healthy?" and "what happened to request X?" without reading code.
+
+---
+
+## 03 — CI/CD Pipeline
+
+Automate quality gates so that broken code never reaches production.
+
+1. Define your environments: local, staging, production. Document the differences.
+2. Centralize secrets management (vault, CI secrets, cloud KMS). No secrets in code or git history.
+3. Set up CI: on every pull request, run linter + tests + build. Block merge on failure.
+4. Set up CD: define how code gets to staging and production. Prefer automated deploys with manual approval for production.
+5. Validate the full pipeline end-to-end: push a change and watch it flow through all stages.
+
+**Done when:** a PR cannot be merged without passing all quality gates, and deploying to staging is a single action.
+
+---
+
+## 04 — Access Control (if applicable)
+
+Implement identity and permissions before building features that depend on them.
+
+1. Choose your identity strategy based on your users: OAuth for B2B, magic links for low-friction, passkeys for security-critical.
+2. Define roles and permissions. Start simple (admin/user) and expand as needed. Use deny-by-default.
+3. Secure tokens: HttpOnly cookies for web, short-lived JWTs with refresh rotation. Protect against XSS and CSRF.
+4. Implement session control: concurrent session limits, remote revocation, idle timeout.
+5. Build user CRUD as your reference implementation — the first feature that exercises the full pipeline.
+
+**Done when:** you can create a user, log in, access a protected route, and get rejected from an unauthorized one.
+
+---
+
+## 05 — Design System & UI/UX (if applicable)
+
+Establish visual consistency before building screens.
+
+1. Define design tokens: colors, spacing (4/8px system), typography scale, border radius, shadows.
+2. Build a theme matrix: light and dark. Use CSS variables or a utility-first system.
+3. Establish a visual baseline: consistent spacing, WCAG-compliant contrast, and typography hierarchy.
+4. Add micro-interactions: loading states, hover feedback, transitions. The interface should feel responsive.
+5. Scaffold reusable components (Button, Input, Card, Modal) so feature development doesn't reinvent them.
+
+**Done when:** a new screen can be built using existing tokens and components without ad-hoc styling.
+
+---
+
+## 06 — Feature Evolution
+
+Build features with clear domain boundaries and safe delivery.
+
+1. Model the domain first: identify entities, value objects, and aggregates. Name things in business language, not technical jargon.
+2. Implement use cases as orchestrators: they call validators, domain logic, and repositories. They don't contain implementation details.
+3. Use feature flags for anything risky or incomplete. Ship to production behind a flag, validate, then enable.
+4. Practice defensive development: validate assumptions, handle edge cases at the boundary, and follow **The Law of Resilience** (Result Pattern).
+5. Refactor continuously: if a module grows beyond its responsibility, split it. Don't wait for a "refactoring sprint."
+
+**Done when:** each feature is isolated, testable, and can be toggled or rolled back independently.
+
+---
+
+## 07 — Production Readiness
+
+Verify everything before going live.
+
+1. Run through a pre-deploy checklist: environment variables set, secrets rotated, dependencies up to date, no debug flags.
+2. Prepare database changes: migrations tested, rollback plan documented, data integrity validated.
+3. Run smoke tests against the staging environment: happy path, error paths, edge cases.
+4. Deploy to production with a defined strategy (blue/green, canary, or rolling). Never deploy on a Friday without a rollback plan.
+
+**Done when:** production is live, monitored, and you have a documented way to roll back in under 5 minutes.
+
+---
+
+## 08 — Operational Governance
+
+Keep the system healthy after launch.
+
+1. Monitor real-time metrics for the first 24-48 hours after deploy: error rates, latency, resource usage.
+2. Have an incident protocol: who gets paged, how to triage, where to communicate (war room or channel).
+3. For critical issues: fix forward if small, rollback if large. Document the decision.
+4. Execute **Documentation Synchronization**. Update `CHANGELOG.md` with version results and evolve the `ROADMAP.md` based on new insights.
+5. Run retrospectives after incidents: what happened, why, what changes prevent recurrence. Update the pipeline.
+
+**Done when:** the team can respond to a production issue without panic, and every incident leaves the system stronger.
+
+---

package/src/assets/dev-guides/spec-driven-dev-guide.md

@@ -0,0 +1,81 @@
+# Spec-Driven Development Guide (5-Phase Task Cycle)
+
+The **Spec-Driven Guide (SDG)** enforces a standardized lifecycle for every task, ensuring that code is only written after the intent and implementation plan are fully approved.
+
+The cycle follows five mandatory phases: **SPEC → PLAN → CODE → TEST → END**.
+
+> [!TIP]
+> **Deep Dive**: Want to see what happens "Under the Hood"? Read the [**Agent Deep-Flow Guide**](agent-deep-flow.md) for a visual breakdown of internal sub-steps and decision gates.
+
+---
+
+## 1. Phase: SPEC (The Contract)
+
+**Goal:** Define the implementation contract and verification criteria.
+
+- **Process**: The agent analyzes the request (e.g., via `/sdg-feat` or `/sdg-fix`) and produces a formal specification.
+- **Standards**:
+  - Identify the domain (Backend, Frontend, Fullstack).
+  - **Feature Cycle**: Focus on domain modeling and business logic.
+  - **Fix Cycle**: Execute **Root Cause Analysis (RCA)** to identify the specific layer or contract violation.
+  - Define inputs, outputs, and hardware/software constraints.
+  - Create a **Verification Checklist** (binary pass/fail items).
+- **Mandate**: The agent must halt for explicit Developer approval of the Spec before moving to the Plan.
+- **Reasoning Exception**: Modern reasoning models may proceed after emitting an internal `<thought>` block validating the criteria.
+
+---
+
+## 2. Phase: PLAN (The Strategy)
+
+**Goal:** Sequence the Spec into atomic, executable tasks.
+
+- **Process**: The agent drafts a logical roadmap based on the approved Spec.
+- **Standards**:
+  - Produce a numbered task list.
+  - Use the Action Verb + Object pattern (e.g., "1. Create User domain type").
+  - **Task Decomposition**: Split complex tasks into sub-tasks to maintain vertical density and prevent context exhaustion.
+- **Mandate**: The agent must halt for explicit Developer approval of the Plan.
+- **Reasoning Exception**: Autonomous models with built-in reasoning may proceed to Code after validating that the plan reflects the project's engineering rules.
+
+---
+
+## 3. Phase: CODE (The Execution)
+
+**Goal:** Implement the plan following architectural standards.
+
+- **Process**: The agent performs the implementation tasks.
+- **Standards**:
+  - Follow the **Narrative Cascade** (callers above callees).
+  - Adhere to the project's flavor (Vertical Slice, MVC, etc.).
+  - Implement only according to the approved Plan (YAGNI).
+  - Surface blockers immediately; do not work around them.
+
+---
+
+## 4. Phase: TEST (The Verification)
+
+**Goal:** Ensure the implementation matches the Spec's Verification Checklist.
+
+- **What happens:** The Agent runs/writes tests and verifies each item on the checklist.
+- **Agent Behavior:**
+  - Writes new tests if the checklist items aren't covered by existing ones.
+  - Reports PASS/FAIL for every checklist item.
+  - **Refactor Loop:** If a test fails, the agent refactors the code and tries again (up to 3 times before stopping to report a blocker).
+
+---
+
+## 5. Phase: END (The Delivery)
+
+**Goal:** Finalize the task, document changes, and prepare for version control.
+
+- **What happens:** The Agent summarizes the work and updates project logs.
+- **Agent Behavior:**
+  - Summarizes what was implemented (linking to PLAN tasks).
+  - Appends entries to `CHANGELOG.md` following the [Keep a Changelog](https://keepachangelog.com/) standard (`### Added` for features, `### Fixed` for bugs).
+  - Proposes a semantic git commit message (e.g., `feat: ...` or `fix: ...`).
+  - Offers next steps (Push, Deploy, or start a new task).
+
+---
+
+> [!IMPORTANT]
+> The agent only writes code after SPEC and PLAN are approved. This is the mechanism that keeps changes traceable to an explicit decision, not a guess.