# Demo Iteration Mode

## Purpose
- Move fast on client demos while product direction is still pivoting.
- Keep the Ballbox core stable so demo speed does not create expensive cleanup later.

## Operating Rule
- Build demo value in presentation/workflow layers.
- Keep domain contracts and core persistence changes intentional and limited.
- No demo-only shortcuts inside core domain modules.

## Delivery Levels

### L1 Story
- UI and narrative only.
- Simulated data allowed.
- Use when the goal is testing message and product direction quickly.

### L2 Contracted Demo (default)
- UI runs against Ballbox contracts/routes.
- Uncertain external dependencies use adapters/mocks behind a boundary.
- Use when the goal is a believable demo with low implementation risk.

### L3 Production Candidate
- End-to-end real integration path.
- Use only after the hypothesis survives discovery.

## Anti-Debt Guardrails
- Keep integration boundaries explicit (`mockAtcClient`/future real client pattern).
- Put demo fixtures in seed/bootstrap paths, not in runtime business logic.
- Any demo-specific behavior needs an explicit flag or boundary, never hidden branching.
- Every demo slice defines a clear exit path (what gets kept, replaced, or removed).

## Slice Checklist
- Which hypothesis this page/flow validates.
- Which delivery level (L1/L2/L3) was chosen and why.
- What is demo-only versus expected to survive pivots.
- What dependency is still mocked and where the boundary lives.

## First Live Usage
- `/classes/me` ships as a small L2 demo slice.
- Scope is intentionally narrow: read-only student request history by email.
- It communicates demand capture and follow-up state without claiming booking confirmation.