# 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. ## ABOOK — Repair appointment holds and cancellation windows A fictional equipment service books maintenance visits. Expiring checkout holds and reschedules occasionally double-book a technician. **Field:** Backend. **Suggested stack:** TypeScript, PostgreSQL, REST. **Engineer value:** Practice resource allocation, interval conflicts and durable workflows. **Company value:** Review scheduling correctness and recovery before exposing scarce capacity. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Build synthetic technicians, slots and booking records. - Use an injectable clock and separate clients for concurrency probes. ### Define availability Make time and availability rules unambiguous. #### ABOOK-101 — Normalize maintenance-slot requests to explicit UTC intervals **Task · Medium priority · Foundational** noCV practice brief v5 · ABOOK-101 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define availability. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 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 technician's daylight-saving transition produces two appointments labelled 01:30 with no offset in the booking request. Acceptance criteria - Require start, end and explicit offset. - Reject end-before-start and zero-duration intervals. - Persist UTC while returning the requested display zone separately. Implementation constraints - Create synthetic ambiguous-hour cases rather than reading real calendars. Verification - Round-trip two different offsets for the repeated hour. - Reject an offset-free repeated-hour request. Deliverables - Slot input contract and DST cases Rollout and recovery: Add validation before new slot creation; retain original timestamps for existing rows. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-102 — Model overlapping technician availability as half-open intervals **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOOK-102 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define availability. Depends on: ABOOK-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Database engineering 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. Adjacent visits are rejected as overlapping, while a visit completely containing another can pass a naive endpoint check. Acceptance criteria - Adjacent end and start boundaries do not conflict. - Contained and partially overlapping intervals conflict. - Conflict checks include the technician's organization. Implementation constraints - Document the half-open interval convention in the query. Verification - Check adjacent, contained and identical intervals. - Try the same technician identifier in another organization and deny access. Deliverables - Overlap query and interval matrix Rollout and recovery: Shadow-check overlap decisions; restore the old route if new conflicts need review. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-103 — Return bookable slots in stable bounded pages **Story · Medium priority · Foundational** noCV practice brief v5 · ABOOK-103 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define availability. Depends on: ABOOK-101, ABOOK-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. A busy service desk loads every future slot; several slots disappear from the second page when a new slot is inserted. Acceptance criteria - Order by start instant and opaque slot ID. - Use a cursor bound to technician and date window. - Enforce a maximum page size and bounded date range. Implementation constraints - Do not expose unassigned technicians outside the organization. Verification - Insert a slot between pages and inspect stable cursor progression. - Reject an altered cursor scope and excessive range. Deliverables - Availability page contract and cursor tests Rollout and recovery: Introduce cursor pagination alongside the old bounded endpoint; roll back its link. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. ### Protect reservations Handle simultaneous actions and durable transitions. #### ABOOK-104 — Reserve one active hold for a contested maintenance slot **Story · High priority · Advanced** noCV practice brief v5 · ABOOK-104 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-102. Difficulty: Advanced. Estimated focused work: 240 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 customers reach checkout together and each receives a valid hold token for the same appointment. Acceptance criteria - One active hold wins for a slot under concurrent requests. - The loser gets a conflict without another customer's details. - Hold creation and its expiry time commit atomically. Implementation constraints - Use a database invariant as the final concurrency guard. Verification - Start two clients at a barrier and assert one live hold. - Force commit failure and assert no usable token escapes. Deliverables - Hold command and concurrent reservation test Rollout and recovery: Enable holds on synthetic slots; pause new holds if invariant monitoring detects duplicates. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-105 — Expire holds without cancelling a booking confirmed at the boundary **Bug · High priority · Expert** noCV practice brief v5 · ABOOK-105 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-104. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database engineering 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 expiry worker reads an old hold while checkout confirms it; the worker then frees a slot already sold. Acceptance criteria - Confirm and expire use guarded state transitions. - Exactly one terminal outcome wins at the expiry boundary. - A stale expiry job cannot alter a confirmed booking. Implementation constraints - Specify whether confirmation at the exact deadline is rejected. Verification - Race confirmation and expiry with a controlled clock. - Retry the stale expiry after confirmation and retain the booking. Deliverables - Hold state machine and boundary race reproduction Rollout and recovery: Canary the guarded worker; stop expiry consumption while preserving stored deadlines. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-106 — Reschedule a visit without releasing its old slot prematurely **Story · Medium priority · Advanced** noCV practice brief v5 · ABOOK-106 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-104, ABOOK-105. Difficulty: Advanced. Estimated focused work: 240 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. A reschedule releases the old appointment before reserving the new one, leaving customers unbooked if the target is taken. Acceptance criteria - Reserve the target and release the source atomically. - Retain the original appointment on target conflict. - A retried successful command returns the same replacement. Implementation constraints - Keep both slot locks in a documented stable order. Verification - Move a visit and inspect one confirmed appointment. - Race for the target and verify the losing reschedule keeps its source. Deliverables - Reschedule command and transaction tests Rollout and recovery: Enable for synthetic bookings; disable rescheduling while ordinary reads continue. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-107 — Calculate the cancellation window from the booked service policy **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOOK-107 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-105. Difficulty: Intermediate. Estimated focused work: 150 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. A policy update changes the cancellation deadline for appointments sold under yesterday's terms. Acceptance criteria - Booking retains the applied policy version. - Deadline calculation uses that frozen policy and UTC start. - Cancellation returns the policy version and eligibility reason. Implementation constraints - This exercise models eligibility only, without charging money. Verification - Cancel bookings created under two policy versions. - Change the current policy and verify old booking deadlines remain fixed. Deliverables - Versioned cancellation calculator Rollout and recovery: Publish a new policy version for new bookings; keep historical policy references intact. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. ### Operate the calendar Reconcile state and explain cancellations. #### ABOOK-108 — Detect orphan holds without changing confirmed appointments **Chore · Medium priority · Advanced** noCV practice brief v5 · ABOOK-108 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate the calendar. Depends on: ABOOK-105, ABOOK-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Database engineering 30% · Site reliability 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 simulated outage leaves holds whose expiry jobs were never dispatched; operations needs a bounded reconciliation command. Acceptance criteria - Scan expired held rows with cursor checkpoints. - Release only rows still held at the checked version. - Report confirmed rows skipped after concurrent change. Implementation constraints - Use dry-run by default and limit each batch. Verification - Reconcile an expired orphan and resume from a checkpoint. - Confirm between scan and update and verify the booking survives. Deliverables - Orphan-hold reconciler and race check Rollout and recovery: Dry-run a bounded window; stop reconciliation and retain checkpoints if unexpected skips grow. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-109 — Hide customer details in scheduling conflict responses **Bug · High priority · Foundational** noCV practice brief v5 · ABOOK-109 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate the calendar. Depends on: ABOOK-106, ABOOK-107. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Backend 30% · API design 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 failed reschedule currently returns the target booking object, exposing the name and contact information of its owner. Acceptance criteria - Conflict responses contain only code and requested slot identity. - Internal logs omit customer contact fields. - Successful owners still receive their own booking projection. Implementation constraints - Use explicit response schemas instead of deleting selected fields. Verification - Check an owner's successful reschedule response. - Force a conflict and assert another customer's fields appear nowhere in response or log. Deliverables - Sanitized conflict schema and disclosure regression Rollout and recovery: Deploy response shaping first; revert only with the same restricted projection. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-110 — Prove booking recovery after a lost confirmation response **Task · High priority · Expert** noCV practice brief v5 · ABOOK-110 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate the calendar. Depends on: ABOOK-105, ABOOK-108, ABOOK-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 40% · Backend 30% · Distributed systems 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. Checkout commits successfully, then the connection closes. A customer retries while the expiry worker is also running. Acceptance criteria - Document persisted state at each interruption point. - A stable command key resolves the committed confirmation. - No retry creates a second booking or frees its slot. Implementation constraints - Build a deterministic fault-injection harness using synthetic visits. Verification - Drop the response after commit and retry to the same booking. - Drop before commit, run expiry, and verify the declared expired outcome. Deliverables - Recovery trace and executable interruption probe Rollout and recovery: Run the drill before enabling checkout; fall back to read-only booking lookup during incidents. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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.