# Definition of Done: Drop — Fintech Payment App

# Definition of Done: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | 2026-02-23 | John | Initial DoD — fintech-specific with pass-through model invariants |

---

## 1. Purpose

The Definition of Done (DoD) is a shared agreement across the Drop team on what must be true before any work item can be considered complete. It exists to:

- Prevent technical debt accumulation through rushed or incomplete work
- Ensure consistent quality across all team members and work types (Builder agent, Validator agent, John)
- Create a shared language for "done" that developers, QA, and Alem (CEO) all agree on
- Prevent issues from reaching production that could have been caught earlier
- Protect the pass-through model: Drop NEVER stores customer money, card numbers, or CVV data

**Enforcement:** The DoD is non-negotiable for Drop. Any exception requires explicit sign-off from John (AI Director) and must be tracked as a Mission Control task with a linked risk acceptance from Alem Bašić (CEO). Undocumented shortcuts are not acceptable in a fintech product.

---

## 2. Feature-Level DoD

When is a **feature** done?

### Code Quality
- [ ] Code is complete and implements all acceptance criteria from the AC document (`docs/BUSINESS-REQUIREMENTS/acceptance-criteria.md`)
- [ ] Code reviewed and approved by Validator agent (read-only reviewer)
- [ ] All review comments resolved or explicitly deferred with a Mission Control task
- [ ] No TODO/FIXME comments left without corresponding Mission Control tasks
- [ ] Code follows Drop coding standards — TypeScript, Next.js App Router patterns, parameterized SQL
- [ ] No unnecessary dead code added
- [ ] No `console.log` / debug statements left in production code

### Testing — Drop Specific
- [ ] Unit tests written for all new business logic (≥ 80% coverage; 100% for auth + transaction logic)
- [ ] Integration tests written for all new API endpoints (`api-endpoints.test.ts`)
- [ ] DB compliance assertions added if any schema changes (`db.test.ts` — no balance, no CVV)
- [ ] All existing tests still pass (no regressions — all 40+ Vitest tests green)
- [ ] Test coverage has not decreased below project minimum (80% overall)
- [ ] Edge cases tested: age boundary (exactly 18), amount boundaries (100 NOK min, 50,000 NOK max)
- [ ] **Pass-through invariant test**: if new DB schema changes, `db.test.ts` must assert:
  - `users` table has NO `balance` column
  - `cards` table has NO `card_number` or `cvv` columns

### Security — Drop Fintech Standards
- [ ] OWASP Top 10 reviewed for this feature (especially if touching auth or payments)
- [ ] Input validation in place for all user inputs (Zod schema — server-side)
- [ ] Authorization checks correct (JWT cookie required for all protected endpoints)
- [ ] No sensitive data logged (no passwords, no card numbers, no full JWT tokens in logs)
- [ ] No sensitive data in API responses (no password hashes, no full card numbers)
- [ ] Rate limiting applies to new endpoints if they handle auth or financial actions
- [ ] CSRF token required on all new POST/PATCH/DELETE endpoints
- [ ] Parameterized SQL only — no string concatenation in DB queries
- [ ] `npm audit` passes — no new HIGH/CRITICAL CVEs introduced

### Performance
- [ ] Performance budget met — no P95 regression > 15% vs baseline (api-benchmarks.test.ts)
- [ ] No N+1 query problems (each API call makes a bounded number of DB queries)
- [ ] bcrypt timing within 1,000ms P95 (after registration/login changes)
- [ ] No synchronous heavy operations blocking the event loop

### Documentation
- [ ] Code is self-documenting or has inline comments for non-obvious Drop business logic
- [ ] API reference updated if new endpoints added (`docs/backend/API-REFERENCE.md`)
- [ ] Architecture Decision Record created for significant architectural choices (e.g., pass-through model changes)
- [ ] CLAUDE.md or relevant project docs updated if dev workflow changes

### API (if applicable)
- [ ] API documentation updated (`docs/backend/API-REFERENCE.md`)
- [ ] Breaking changes explicitly documented in release notes
- [ ] Response schema consistent with existing patterns (error format, HTTP status codes)

### Error Handling
- [ ] All error conditions handled gracefully (no unhandled promise rejections)
- [ ] Error messages are user-friendly and in Norwegian where applicable
- [ ] No stack traces in production API responses
- [ ] External service failures handled (mock BaaS timeout → user-friendly error)
- [ ] Financial errors use correct HTTP status codes (402 Insufficient Balance; 403 KYC Required)

### Compliance Checklist (Drop-specific — MANDATORY)
- [ ] **PCI-DSS**: No `card_number` or `cvv` stored or returned in full
- [ ] **Pass-through model (ADR-003)**: No `balance` column added to users table
- [ ] **AML**: Transaction amounts ≤ 50,000 NOK enforced
- [ ] **Age verification**: Age ≥ 18 validation in place for any new user-facing flows
- [ ] **Audit trail**: New financial events logged in `audit_logs` table

### Deployment
- [ ] Deployed to staging (https://drop-staging.fly.dev/) and manually verified
- [ ] Database migrations tested on staging (up and down migrations)
- [ ] Environment variables documented in `docs/DEVELOPER-EXPERIENCE/local-development-setup.md`
- [ ] Feature flag configured if the feature is gated (e.g., Cards, BankID)
- [ ] John (AI Director) has reviewed and accepted the feature in staging

---

## 3. Sprint-Level DoD

When is a **sprint** done?

- [ ] All committed Mission Control tasks meet their individual Definition of Done
- [ ] All automated tests passing in CI (Vitest: 40+ tests; Playwright: 3 projects)
- [ ] Staging environment is stable (no broken features on https://drop-staging.fly.dev/)
- [ ] Technical debt created during the sprint is tracked in Mission Control backlog
- [ ] Sprint review conducted — John (AI Director) and Alem (CEO if available) have seen deliverables
- [ ] Retrospective findings logged in `docs/CROSS-CUTTING/lessons-learned.md`
- [ ] Next sprint's tasks refined and priority-ordered in Mission Control

---

## 4. Release-Level DoD

When is a **release** done?

- [ ] All features in scope meet the Feature-Level DoD
- [ ] Full regression test suite passing on staging (all 26 API routes via `api-endpoints.test.ts`)
- [ ] Playwright E2E tests passing for all 5 critical journeys (user-flows, full-flows, input-chaos)
- [ ] Performance benchmarks passing — all NFR-P01..P06 targets met (`api-benchmarks.test.ts`)
- [ ] Security scan complete — no unresolved HIGH/CRITICAL findings (`npm audit` clean)
- [ ] DB compliance tests passing — `db.test.ts` all assertions green (no balance, no CVV)
- [ ] UAT conducted with Alem Bašić (CEO) sign-off (or documented conditional approval)
- [ ] Release notes written: `docs/RELEASE/release-notes.md`
- [ ] Deployment checklist complete: `docs/RELEASE/deployment-checklist.md`
- [ ] Rollback plan prepared and tested: `docs/RELEASE/rollback-plan.md`
- [ ] John (AI Director) briefed on all changes and potential failure modes
- [ ] Security audit score ≥ 80/100 (Phase 0.5 requirement)

---

## 5. Bug Fix DoD

When is a **bug fix** done?

- [ ] Root cause understood and documented in the Mission Control task
- [ ] Fix addresses root cause (not just symptoms)
- [ ] Unit/integration test written that would have caught this bug (regression test added)
- [ ] Fix does not introduce new failures (all 40+ tests still passing)
- [ ] Fix verified in staging environment
- [ ] Related areas spot-checked for similar issues
- [ ] Mission Control task updated with root cause and resolution notes
- [ ] `docs/CROSS-CUTTING/lessons-learned.md` updated if the bug reveals a systemic pattern

---

## 6. Hotfix DoD

When is a **hotfix** done?

- [ ] Fix verified locally and on staging (cannot skip staging — even for hotfixes)
- [ ] Validator agent has reviewed the fix (at minimum async review)
- [ ] Smoke tests passing post-deployment (Playwright user-flows project)
- [ ] Mission Control incident task updated with fix details
- [ ] Full regression test run scheduled within 4 hours
- [ ] Post-mortem scheduled within 24 hours if P1/P2 severity (DORA compliance)
- [ ] Rollback plan confirmed (Fly.io rollback ready in case hotfix causes regression)

---

## 7. Drop-Specific Additions

### Pass-Through Model Invariant (Non-Negotiable)

The following assertions must pass on **every commit** — they are not optional:

```typescript
// db.test.ts assertions — NEVER disable these:
expect(columns).not.toContain('balance')       // users table
expect(columns).not.toContain('card_number')   // cards table
expect(columns).not.toContain('cvv')           // cards table
```

If these tests fail, the build fails. No exceptions. No PR merges until fixed.

### Financial Calculation Verification

All fee changes (currently 0.5% remittance, 1% QR) must include:
1. Unit test in `transactions.test.ts` verifying exact fee amount
2. Boundary test at minimum amount (100 NOK) and maximum amount (50,000 NOK)
3. A comment in the code referencing the business rule (BRD section)

### Norwegian Language Compliance

User-facing error messages for age validation must include Norwegian text:
- Age rejection: "Du må være minst 18 år"
- Other messages: Norwegian primary, English secondary
- Check: Playwright input-chaos.spec.ts includes Norwegian error message assertions

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Coding Standards](../DEVELOPER-EXPERIENCE/coding-standards.md)
- [Deployment Checklist](../RELEASE/deployment-checklist.md)
- [UAT Sign-off](../RELEASE/uat-signoff.md)
- [Acceptance Criteria](../BUSINESS-REQUIREMENTS/acceptance-criteria.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| QA Lead | Validator Agent | 2026-02-23 | Approved (AI) |
| Tech Lead | John | 2026-02-23 | Approved |
| CEO (Alem) | Alem Bašić | TBD | |