Define legal reservation transitions
A support script changed a paid reservation from COMMITTED back to ACTIVE. Inventory is now counted twice because each endpoint writes status directly.
- Focused work estimate
- 2h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- State machines · Domain boundaries · Audit trails
Estimated field mix
- Backend100%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- StateCompare
Compare a transition table with State objects for the reservation lifecycle. Legal transitions and terminal-state protection matter more than the number of classes.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional retailer sells bicycle parts from East and West warehouses. Cart reservations last ten minutes, payment callbacks arrive late, and warehouse counts occasionally need correction. The exercise has no real orders or payment integration.
Setup prerequisites
- Relational modeling
- Concurrent API requests
- State transitions
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Allow ACTIVE to become COMMITTED, RELEASED, or EXPIRED through named operations.
- Terminal reservations cannot return to ACTIVE.
- Each successful transition records actor, reason, and timestamp.
Implementation constraints
- Keep transition validation in the domain/service boundary, including maintenance callers.
Verification to include
- Exercise all three allowed exits from ACTIVE.
- Attempt every terminal-to-active transition and assert no quantity or audit mutation.
Deliverables
- Reservation transition table and domain operations
Rollout and recovery
Route existing writes through the new operations first; rollback callers without reopening terminal records.
Value of the work
For the engineer: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair.
For the team: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.