Definition of Done

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?

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:

// 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:

Unit test in transactions.test.ts verifying exact fee amount
Boundary test at minimum amount (100 NOK) and maximum amount (50,000 NOK)
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

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