# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## STOCK — Stop overselling the last warehouse unit 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. **Field:** Backend. **Suggested stack:** TypeScript, NestJS, PostgreSQL, Redis. **Engineer value:** Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. **Company value:** Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. **Delivery agreement:** Three phases of ten reviewable issues, from a stock lookup to a concurrency and recovery handoff using synthetic orders. ### Setup prerequisites - Relational modeling - Concurrent API requests - State transitions ### Stock contract Define quantities and safe reservation boundaries. #### STOCK-101 — Return available stock for a specific warehouse **Story · Medium priority · Foundational** noCV practice brief v5 · STOCK-101 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stock contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Database engineering 30% · Security 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Product pages display total stock across both warehouses, although East cannot ship West inventory. A customer sees four brake kits available when their shipping warehouse has none. Acceptance criteria - Return on-hand, reserved, and available quantities for the selected warehouse and SKU. - Unknown SKUs return a documented not-found response. - Reject warehouse IDs outside the caller's retailer scope. Implementation constraints - Available means on-hand minus active reservations; do not silently substitute another warehouse. Verification - Read the same SKU from East and West with different balances. - Deny a foreign warehouse and reject an empty SKU. Deliverables - Warehouse stock endpoint and response examples Rollout and recovery: Switch the synthetic product page lookup by warehouse behind a flag; restore the earlier lookup if contract errors rise. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### STOCK-102 — Define legal reservation transitions **Task · High priority · Foundational** noCV practice brief v5 · STOCK-102 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stock contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 100%. 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: State (compare). State — Compare: Compare a transition table with State objects for the reservation lifecycle. Legal transitions and terminal-state protection matter more than the number of classes. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A support script changed a paid reservation from COMMITTED back to ACTIVE. Inventory is now counted twice because each endpoint writes status directly. 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 - 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. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Checkout under contention Handle retries, timeouts, and allocations consistently. #### STOCK-103 — Reserve the last unit atomically **Bug · Urgent priority · Advanced** noCV practice brief v5 · STOCK-103 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-101, STOCK-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Two checkouts both read one remaining wheelset before either writes a reservation. Both succeed, leaving the warehouse with available stock of minus one. Acceptance criteria - At most one of two concurrent requests for the last unit succeeds. - Availability never drops below zero for committed reservation transactions. - An insufficient-stock failure creates neither a reservation nor an audit success. Implementation constraints - The database must enforce correctness when requests arrive at different API processes. Verification - Run overlapping reservations against one unit and inspect final state. - Inject a failure before commit and prove the available quantity is restored. Deliverables - Atomic reservation path and deterministic race reproduction Rollout and recovery: Canary with one synthetic SKU under contention; disable reservation writes if the invariant monitor fails. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### STOCK-104 — Replay checkout retries without extending a hold **Bug · High priority · Intermediate** noCV practice brief v5 · STOCK-104 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 70% · API design 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A flaky mobile connection retries the reserve call every minute. Each retry adds another ten minutes to the hold and can change the requested quantity. Acceptance criteria - The same order request replays the original reservation and expiry. - Changing quantity or warehouse under the same request key returns conflict. - An expired reservation remains expired when the request is replayed. Implementation constraints - Bind the request identity to retailer and order; a replay is not a renewal. Verification - Retry after nine minutes and assert the original expiry remains. - Replay with changed quantity and replay after expiry; inspect both responses. Deliverables - Reservation idempotency contract and time-controlled examples Rollout and recovery: Enable replay behavior for new keys; retain legacy key interpretation until outstanding holds expire. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### STOCK-105 — Decide the winner when payment and expiry arrive together **Task · High priority · Expert** noCV practice brief v5 · STOCK-105 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Distributed systems 30% · Database engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Payment confirmation and the expiry sweeper reach reservation R-42 at the same instant. Today both handlers succeed and a paid order loses its stock. Acceptance criteria - Document one deadline rule using server time and apply it in both handlers. - Exactly one terminal transition wins under concurrency. - A payment arriving after a lost hold enters an explicit exception path without reserving unavailable stock. Implementation constraints - Payment success alone does not authorize negative stock; retain callback identity for replay. Verification - Exercise callback just before, at, and just after the deadline. - Run callback and sweeper concurrently, then replay both and inspect one terminal audit. Deliverables - Deadline decision record, race tests, and late-payment exception contract Rollout and recovery: Shadow-classify deadline decisions first; rollback new routing while preserving terminal decisions already recorded. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### STOCK-106 — Reserve a multi-line order without partial holds **Story · High priority · Advanced** noCV practice brief v5 · STOCK-106 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. An order for a cassette and chain reserves the cassette, then fails on the chain. The abandoned partial hold blocks another buyer for ten minutes. Acceptance criteria - Reserve all requested lines or none within one warehouse. - Combine repeated SKU lines before checking stock. - Concurrent orders listing SKUs in opposite orders finish or return bounded retryable failures. Implementation constraints - Set a maximum of 50 distinct SKUs per request and define deterministic acquisition order. Verification - Reserve two available lines and verify both holds. - Fail the second line and run opposite-order concurrent carts; check no partial state. Deliverables - Atomic basket reservation operation and deadlock exercise Rollout and recovery: Opt in synthetic multi-line carts; fall back to rejecting whole baskets if contention exceeds the agreed budget. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Warehouse operations Introduce corrections and operational visibility without corrupting reservations. #### STOCK-107 — Apply a stock count correction with an explicit shortage **Story · High priority · Intermediate** noCV practice brief v5 · STOCK-107 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-102, STOCK-103. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 80% · Security 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A warehouse count finds two damaged lights while three lights are reserved. Operations needs to record the loss without silently cancelling customer holds. Acceptance criteria - Append an authorized adjustment with reason and counted quantity. - Represent a shortage when active reservations exceed the corrected on-hand quantity. - Block new holds during a shortage while preserving existing reservation history. Implementation constraints - An inventory correction is not permission to cancel a paid allocation. Verification - Correct an unreserved SKU and inspect the new available balance. - Create a shortage and assert existing holds survive while new requests fail. Deliverables - Stock adjustment command and shortage response contract Rollout and recovery: Limit adjustments to a test warehouse role; reverse mistakes through a compensating adjustment. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### STOCK-108 — Split existing stock rows by warehouse without a write outage **Chore · High priority · Expert** noCV practice brief v5 · STOCK-108 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-101, STOCK-103. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · Platform engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The old table has one quantity per SKU. The East/West launch needs a warehouse key, but a one-shot table rewrite blocks checkout on the large synthetic inventory fixture. Acceptance criteria - Provide expand, backfill, validation, and contract steps with explicit compatibility windows. - Backfill is resumable and preserves total on-hand quantities. - Demonstrate old and new application versions coexist during the supported migration window. Implementation constraints - Define the mapping of legacy stock to East before backfill; never infer a warehouse from a SKU. Verification - Interrupt the backfill and resume without duplicate inventory. - Run reservation traffic during migration and test rollback before the contract step. Deliverables - Versioned migration set and measured lock-duration report Rollout and recovery: Use the documented expand/backfill/switch sequence; prohibit old-version rollback after incompatible cleanup. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### STOCK-109 — Invalidate availability cache after committed stock changes **Bug · Medium priority · Intermediate** noCV practice brief v5 · STOCK-109 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Distributed systems 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The product page shows an old available count for five minutes after a warehouse adjustment. A failed adjustment also evicts unrelated retailers' cached stock. Acceptance criteria - Invalidate only the retailer, warehouse, and SKU affected by a committed change. - A rolled-back transaction emits no successful invalidation event. - Reservation correctness remains database-backed when the cache is stale or unavailable. Implementation constraints - The cache is a display optimization and cannot authorize a hold. Verification - Apply an adjustment and observe the next lookup refresh. - Rollback an adjustment and disable Redis; check scope and successful authoritative reads. Deliverables - Scoped cache invalidation and stale-read behavior notes Rollout and recovery: Reduce cache lifetime before enabling invalidation; bypass the cache if refresh failures rise. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### STOCK-110 — Give support a safe reservation incident view **Task · Medium priority · Foundational** noCV practice brief v5 · STOCK-110 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-105, STOCK-107. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 40% · Security 30% · Privacy engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Support needs to explain why an order lost its hold. The current workaround is database access that exposes customer addresses and permits accidental stock edits. Acceptance criteria - Show reservation transitions, expiry, warehouse, and exception reason for one authorized order. - Exclude addresses, payment payloads, and write controls. - Distinguish a late payment exception from a normal expiry in readable text. Implementation constraints - The view is diagnostic only; corrective actions remain separate audited commands. Verification - Inspect committed, expired, and shortage examples. - Deny another retailer and assert sensitive fields are absent. Deliverables - Support projection and a three-case incident walkthrough Rollout and recovery: Grant read access to the synthetic support role; revoke the route permission to rollback. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.