Standards / Definition of Done

Definition of Done

A lean bar, sized for the current team, not a permanent standard (see docs/definition-of-done.md, the canonical source). A requirement counts as Done when: the code implementing it is merged to main, its tests are passing, and — once the team has reached 2 developers — it has an approving peer review on the PR. Peer review is not required while the team is 1 developer; it becomes required the moment a second developer exists, enforced by branch protection (ENG-01 ENG01-10).

Deliberately no fixed code-coverage percentage floor yet, and no performance/security/accessibility gate baked into "Done" itself beyond what STD-01 already requires as platform-wide standards for specific stories. This isn't permanent — it's a starting point sized for the team that exists today, meant to be revisited as the team grows.

Testing Standards (STD01-14)

Every independently deployable integration or critical payment-processing component must demonstrate the failure modes it claims to handle, across these categories: unit/domain (business rules, status transitions, financial precision), idempotency/concurrency (duplicate requests, conflicting keys, simultaneous first requests), contract (internal API/event/Connector schema compatibility), integration simulator/stub (success, business rejection, timeout before/after possible handoff, delayed completion, duplicate callback, provider unavailable), restart/recovery (process termination at each critical point), resilience (circuit open/half-open, capacity rejection, bounded retry), security/isolation (cross-tenant access, prod/non-prod separation, secret leakage), and observability (required logs/metrics/traces produced without leaking sensitive data).

Connector/Adapter conformance tests are built to be reusable, so a new CU/provider integration proves the shared behavior without rewriting the platform's test strategy (ENG01-07, ENG01-11).

The full standard

STD01-14 is one section of a larger cross-cutting standard. See STD-01 for the complete set — application architecture, request context, idempotency, deadlines, retries, external dependency resilience, integration contracts, durable processing, and observability — that every Payment Hub, Payment Product, Channel, and Connector conforms to.