| name | implement-feature |
| description | Use when adding a new feature or endpoint to KimPay - guides spec-driven, TDD implementation that respects module boundaries and payment security rules. |
Implement Feature
Disciplined workflow for adding functionality to the KimPay payment gateway.
Before writing code
- Confirm there is a spec (
docs/superpowers/specs/) and plan (docs/superpowers/plans/). If not, brainstorm and plan first — do not improvise a payment feature.
- Identify which module each change belongs to (see
.claude/rules/architecture-principles.md):
- Entity/enum →
payment-domain
- Business logic / repository / infra interface →
payment-core
- Controller / security / transport impl / config →
payment-api
- Shared utility (crypto, masking) →
payment-common
- Check the relevant rules:
security.md, api-design.md, testing-strategy.md, path-scoped/backend/database.md.
Implementation loop (TDD, per task)
- Write the failing test (unit first; integration only where wiring matters).
- Run it — confirm it fails for the expected reason.
- Write the minimal code to pass. Constructor injection, records for DTOs,
BigDecimal for money.
- Run the test — confirm green. Run the module suite.
- Commit with a conventional message (
feat:, fix:, test:...).
Payment-specific checklist
Done means
All new tests pass, the full ./mvnw test suite is green, the change is committed, and any new architectural decision is recorded in .claude/docs/decision-log.md.