julian
17c08e6392
- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24) - apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004) - apps/web: React 19 + Vite 8 (ESM) - libs/shared/api-interface: Zod contract base - Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit - WDS artifacts: - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs) - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact) - Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md - AGENTS.md + README.md como entrada para devs/agentes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.0 KiB
2.0 KiB
name, description, borrows_from
| name | description | borrows_from |
|---|---|---|
| implement | Code the designed improvement in a new branch | Phase 5 (development) |
Implement
Goal: Implement the approved design in code, working in a dedicated branch like a developer on the team.
INITIALIZATION
Design Log
Read {output_folder}/_progress/00-design-log.md. Check Current and Backlog for context.
Steps
Step 1: Load Specification
Read the specification from [D] Design Solution:
- Change summary
- Component specifications
- Acceptance criteria
- Pages affected
Step 2: Create Branch
Create a feature branch for this improvement:
git checkout -b evolution/[scenario-name]
Naming convention: evolution/ prefix + kebab-case scenario name.
Step 3: Understand Current Code
Before writing code, understand what exists:
- Locate the files for affected pages/views
- Read current component implementations
- Identify the tech stack patterns (framework, styling approach, state management)
- Note any existing design tokens or theme configuration
Present a brief implementation plan:
- Which files will change
- What new files are needed (if any)
- Estimated complexity
Step 4: Implement Changes
Write the code changes following the specification:
- Follow existing patterns — Match the codebase's conventions, don't introduce new ones
- Minimal changes — Only change what the specification calls for
- Commit incrementally — One logical commit per change unit
- Test as you go — Verify each change works before moving on
For each file changed, explain what was modified and why.
Step 5: Self-Review
Before handing off:
- Diff all changes:
git diff evolution/[scenario-name]..main - Check against specification: every acceptance criterion addressed?
- Check for unintended side effects: other pages/components still work?
- Clean up: no debug code, no commented-out blocks, no unrelated changes
AFTER COMPLETION
- Update design log
- Suggest next action
- Return to activity menu