Why
As a backend developer
I want to document the decision around introducing the Order model (with status Draft/Paid/Failed)
So that future contributors understand the rationale, schema impact, and relationship to payments and sessions 
⸻
Acceptance Criteria
• Given the need for an Order model
• When documenting the decision
• Then an ADR should be created in the repository
• Given the ADR is published
• When new contributors review backend issues
• Then they should see:
• Context and problem statement
• Options considered (e.g., storing only in sessions vs. standalone order model)
• Final decision and reasoning
• Schema impact (fields, enums, relationships)
• Given schema changes are outlined
• When database migrations or Firestore rules are applied
• Then they should align with the ADR’s decision
⸻
Proposed Implementation
• Add an ADR markdown file under /docs/adr/ or similar folder.
• Document:
• Problem: Lack of a dedicated Order model separate from session/payment flow.
• Status: Accepted.
• Decision: Introduce Order model with persistence and status enum (Draft/Paid/Failed).
• Consequences: Requires schema update in Firebase (new orders collection).
• Alternatives considered (e.g., continue using session documents).
• Update schema documentation (if exists) to include new Order collection and reference structure.
• Reference this ADR in related issues (e.g., payment flow, checkout).
Why
As a backend developer
I want to document the decision around introducing the Order model (with status Draft/Paid/Failed)
So that future contributors understand the rationale, schema impact, and relationship to payments and sessions 
⸻
Acceptance Criteria
• Given the need for an Order model
• When documenting the decision
• Then an ADR should be created in the repository
• Given the ADR is published
• When new contributors review backend issues
• Then they should see:
• Context and problem statement
• Options considered (e.g., storing only in sessions vs. standalone order model)
• Final decision and reasoning
• Schema impact (fields, enums, relationships)
• Given schema changes are outlined
• When database migrations or Firestore rules are applied
• Then they should align with the ADR’s decision
⸻
Proposed Implementation
• Add an ADR markdown file under /docs/adr/ or similar folder.
• Document:
• Problem: Lack of a dedicated Order model separate from session/payment flow.
• Status: Accepted.
• Decision: Introduce Order model with persistence and status enum (Draft/Paid/Failed).
• Consequences: Requires schema update in Firebase (new orders collection).
• Alternatives considered (e.g., continue using session documents).
• Update schema documentation (if exists) to include new Order collection and reference structure.
• Reference this ADR in related issues (e.g., payment flow, checkout).