Skip to content

ADR Lifecycle and Index

Every ADR uses same frontmatter fields:

  • status: decision lifecycle: proposed, accepted, deprecated, or superseded.
  • id and scope: stable decision identity and domain, platform, or cross-cutting ownership class.
  • contexts, terms, authorities, and gaps: stable ids resolved through apps/docs/ontology.json.
  • technicalOwner: platform fallback owner only; never a substitute for domain ownership.
  • date: original decision date.
  • lastReviewed: latest architecture/evidence audit date.
  • supersedes: prior ADR ids replaced by this decision.
  • supersededBy: current successor ADR id, or null.
  • implementation: observed evidence state: not-started, partial, implemented, or historical.

Decision status and implementation state are independent. accepted means target remains current; it does not mean every path is implemented. partial requires linked code/config evidence plus named gaps. Dated stage or E2E results are historical snapshots unless rerun against current revisions.

ADR references use exact ADR-### format. Supersession is bidirectional: old ADR names successor in supersededBy; successor lists old ADR in supersedes. Superseded ADR text stays available as history.

ADRDecisionStatusImplementationRelationship
ADR-001Repository ownership boundariesacceptedimplemented-
ADR-002Backend DDD and feature boundariessupersededhistoricalsuperseded by ADR-029
ADR-003Colocated test namingacceptedpartial-
ADR-004pnpm-only JavaScript toolingacceptedimplemented-
ADR-005uv-only Python toolingacceptedimplemented-
ADR-006Supabase onlysupersededhistoricalsuperseded by ADR-018
ADR-007Starlight documentation surfaceacceptedimplemented-
ADR-008Strapi content administrationsupersededhistoricalsuperseded by ADR-019
ADR-009Migration evidence control loopacceptedpartial-
ADR-010Service-use contract render sourceacceptedpartial-
ADR-011Booking service-term side-effect assemblyacceptedpartial-
ADR-012Frontend static Atomic Design shellacceptedpartial-
ADR-013Settlement component acknowledgementacceptedpartial-
ADR-014Settlement data-room readinessacceptedpartial-
ADR-015Refreshable preview E2E runnersacceptedimplemented-
ADR-016Branch settlement board projectionacceptedpartial-
ADR-017Financial decision authorityacceptedpartial-
ADR-018Platform authority boundariesacceptedpartialsupersedes ADR-006
ADR-019Directus content administrationacceptedpartialsupersedes ADR-008
ADR-020Reservation payment obligation and actor snapshotacceptedpartial-
ADR-021Family-sponsored reservation contract acceptanceacceptedpartial-
ADR-022Bounded on-demand Starlight runtimeacceptedimplemented-
ADR-023Project-owned remote image buildacceptedimplemented-
ADR-024Reservation care-history read modelacceptedimplemented-
ADR-025Payment-change secure handoffacceptedimplemented-
ADR-026Payment cash-receipt handoff snapshotacceptedpartial-
ADR-027Payment refund settlement reversalacceptedpartial-
ADR-028Authenticated mother booking submissionacceptedpartial-
ADR-029Layer-first context feature slicesacceptedpartialsupersedes ADR-002
ADR-030Branch onboarding and own-profile authorityacceptedpartial-
ADR-031Server-authoritative customer reservation creationacceptedpartial-
ADR-032Customer reservation contract acceptance evidenceacceptednot-started-
ADR-033Strict sequential actor workflow acceptanceacceptedimplemented-
ADR-034Mother account identity, profile, and consent authorityacceptedpartial-
ADR-035Customer authenticated session and account-link proofacceptedpartial-
ADR-036Customer session recovery auditacceptedimplemented-
ADR-037Reservation booking party authority bindingacceptedimplemented-

Update implementation only with pinned repository evidence or dated runtime evidence. Never infer deployment, provider health, or end-to-end behavior from file presence alone.