Definition of done

A feature or bug fix is done only when every item on this checklist is satisfied. Partial completion is not done.

Feature checklist

Domain and business rules

The bounded context for this feature has been identified.
A use case exists in packages/application/<context>/ that orchestrates the domain logic.
Business rules and invariants live in packages/domain/<context>/ — not in UI handlers, API routes, or database queries.
No direct page-to-database shortcut exists (UI must not import Drizzle schema or repository implementations).

Data

Schema changes are captured in a migration in db/migrations/.
New schema follows the naming conventions in Database.

Tests

The happy path is covered by at least one test.
Key failure paths (e.g. conflict detected, aircraft grounded, member not active) are covered by tests.
For bug fixes: a regression test exists that would have caught the original bug.
Domain tests run without any infrastructure dependencies (no D1, no Astro).

Documentation

If new domain terms are introduced, Ubiquitous language is updated.
If a new bounded context capability is added, the relevant bounded context page is updated.
If a new reusable UI component is added, it is documented in UX — components.

UI

The feature uses components from @baseleg/ui where applicable.
All colours, spacing, and styles use design tokens (no hardcoded values).
The view handles all four states: loading, empty, error, and success/ready.
The feature has been visually tested at the minimum supported viewport (768px wide).

Architecture

Package boundary rules are respected (see Package boundaries).
If a significant architectural decision was made, an ADR has been written.

Bug fix checklist

Root cause is understood and documented (in PR description or commit message).
A regression test has been added that fails without the fix.
The fix does not introduce a shortcut that violates package boundaries.
If the bug reveals a domain rule that was missing from the domain layer, it has been moved there.