# 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. ## SCONCUR — Make a native work queue survive real thread interleavings A fictional image-indexing utility runs CPU-only synthetic jobs through a Rust worker pool. Its prototype loses wakeups, blocks shutdown, and treats cancellation as completion. Build a local library and deterministic concurrency harness; image content, GPU work, and production deployment are excluded. **Field:** Systems programming. **Suggested stack:** Rust, Threads, Loom or deterministic scheduler, Criterion. **Engineer value:** Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. **Company value:** Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - Mutexes and condition variables - Atomics - Thread lifecycle ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SCONCUR-101 — Define queue ownership before starting worker threads **Task · Medium priority · Foundational** noCV practice brief v5 · SCONCUR-101 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer tooling 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. Workers borrow configuration from a stack-owned builder that disappears after start, while the queue handle can outlive the pool. Acceptance criteria - Pool-owned state outlives every worker - Queue handles cannot submit after terminal shutdown - Dropping the final handle has documented behavior Implementation constraints - Avoid leaked static references and process-wide mutable state. Verification - Create, submit, join, and drop a pool repeatedly under a leak checker. - Drop external handles in different orders and verify workers cannot access released state. Deliverables - Ownership diagram and lifecycle tests Rollout and recovery: Keep the single-thread runner until lifecycle checks pass. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-102 — Reject work when the bounded queue is full **Bug · Medium priority · Foundational** noCV practice brief v5 · SCONCUR-102 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Performance 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. Producers append without limit while workers are paused, and the process consumes all available memory. Acceptance criteria - Capacity is explicit and positive - Submission returns accepted, timed out, or closed - A rejected job remains caller-owned Implementation constraints - Do not hide backpressure behind an unbounded overflow list. Verification - Fill the queue, release one slot, and submit the next job. - Keep workers paused and confirm memory and queue length remain bounded. Deliverables - Bounded submission API and overload tests Rollout and recovery: Start with conservative capacity and surface rejections to the local caller. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-103 — Close the lost-wakeup gap between predicate and sleep **Story · Medium priority · Intermediate** noCV practice brief v5 · SCONCUR-103 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SCONCUR-101, SCONCUR-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Quality engineering 35%. 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 producer signals just before a worker begins waiting; queued work then sleeps until another submission arrives. Acceptance criteria - Workers test the queue predicate under the same synchronization boundary as waiting - Spurious wakeups preserve correctness - One job is claimed by one worker Implementation constraints - Document the predicate, mutex, and notification order in code comments beside the wait loop. Verification - Exercise enqueue before, during, and after worker wait. - Force the historical interleaving and prove the queued job completes without a second signal. Deliverables - Correct wait loop and deterministic lost-wakeup test Rollout and recovery: Run the old and new pools against the same scheduler trace before switching. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SCONCUR-104 — Keep cancellation distinct from successful completion **Chore · Medium priority · Intermediate** noCV practice brief v5 · SCONCUR-104 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Real-time 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. A cancelled indexing job resolves the same completion channel as a finished job, so callers publish an empty index. Acceptance criteria - Result distinguishes success, cancellation, job failure, and pool shutdown - Cancellation before claim prevents execution - Cancellation after claim is cooperative and observable Implementation constraints - Do not terminate worker threads asynchronously while they own locks or memory. Verification - Cancel queued and running cooperative jobs and inspect distinct outcomes. - Use a job that ignores cancellation and verify shutdown reports the unresolved work. Deliverables - Cancellation state model and race tests Rollout and recovery: Callers must handle cancellation explicitly before adopting the new result type. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-105 — Prevent priority work from starving maintenance forever **Task · High priority · Advanced** noCV practice brief v5 · SCONCUR-105 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-102, SCONCUR-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Performance 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. A continuous stream of interactive jobs keeps cache-maintenance tasks queued indefinitely. Acceptance criteria - Scheduling policy defines a bounded wait for every admitted class - Interactive latency remains measured under mixed load - Class selection is deterministic for a declared seed Implementation constraints - Do not claim fairness from average completion time; report per-class tail wait. Verification - Replay a mixed workload and verify the declared service ratio. - Saturate the interactive class and confirm maintenance still advances. Deliverables - Fair scheduler policy, simulator, and latency report Rollout and recovery: Canary the policy in the synthetic workload and retain FIFO fallback. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-106 — Remove a lock-order inversion in completion reporting **Bug · High priority · Advanced** noCV practice brief v5 · SCONCUR-106 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-103, SCONCUR-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Quality 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 worker holds the queue lock while acquiring a result lock; the joining thread holds the result lock while closing the queue. Acceptance criteria - Declare a single lock order or remove nested acquisition - Completion remains visible before join returns - Shutdown cannot wait while holding a lock needed by workers Implementation constraints - Keep callbacks outside internal locks because caller code is untrusted by the synchronization design. Verification - Complete and join jobs from several workers under the deterministic scheduler. - Force the prior opposing acquisition order and verify progress. Deliverables - Lock graph, refactor, and deadlock regression Rollout and recovery: Enable lock-wait diagnostics during the local transition. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-107 — Prove the atomic queue fast path has a safe memory order **Story · High priority · Expert** noCV practice brief v5 · SCONCUR-107 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-102, SCONCUR-103. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Performance engineering 35%. 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 lock-free experiment publishes a slot index before all job fields are visible, producing rare partially initialized reads on a weakly ordered target. Acceptance criteria - Every atomic operation has a stated synchronization role - Publication makes complete job data visible before claim - Wraparound cannot confuse a reused slot with an older generation Implementation constraints - Prefer the mutex implementation unless measured need and model checking justify the atomic path. Verification - Model-check bounded producers, consumers, and slot reuse. - Weaken the publication ordering in a mutation and ensure the model detects an invalid read. Deliverables - Memory-order argument, model, and comparison with mutex path Rollout and recovery: Keep the atomic implementation disabled unless correctness and workload benefit are both demonstrated. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SCONCUR-108 — Drain accepted jobs without hanging process shutdown **Chore · High priority · Advanced** noCV practice brief v5 · SCONCUR-108 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SCONCUR-104, SCONCUR-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Site reliability 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. Shutdown closes submissions but waits forever for a worker blocked on an external test double that never returns. Acceptance criteria - Shutdown defines stop-accepting, drain, cancel, and terminal states - A deadline reports unfinished job identities without detaching live threads - Repeated shutdown calls return the same terminal outcome Implementation constraints - Use controlled local jobs; do not kill threads or the host process to simulate recovery. Verification - Drain a pool whose jobs complete before the deadline. - Block one job past the deadline and confirm bounded return with an unresolved record. Deliverables - Shutdown protocol and stuck-job test Rollout and recovery: Callers keep the old process exit path until they handle unresolved shutdown results. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-109 — Capture a concurrency failure without megabytes of logs **Task · High priority · Expert** noCV practice brief v5 · SCONCUR-109 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SCONCUR-105, SCONCUR-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Site reliability 35%. 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 rare stall produces per-poll logs from every worker, changing timing and obscuring the last useful state transition. Acceptance criteria - Record a bounded ring of queue and worker transitions - Events use monotonic sequence and synthetic job identity - Snapshot identifies dropped diagnostic events Implementation constraints - Do not record job payloads, thread stack memory, or unbounded labels. Verification - Reconstruct a normal claim-to-completion path from the ring. - Overflow the ring during the forced deadlock trace and retain an explicit loss marker. Deliverables - Bounded trace recorder and stall diagnostic Rollout and recovery: Enable the recorder only for the local harness until overhead is measured. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-110 — Publish the worker-pool contract and benchmark limits **Bug · Medium priority · Intermediate** noCV practice brief v5 · SCONCUR-110 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SCONCUR-105, SCONCUR-108, SCONCUR-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer tooling 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 build tool and a request server both plan to reuse the pool despite different fairness, blocking, and shutdown requirements. Acceptance criteria - Document supported job behavior and prohibited blocking assumptions - Report throughput, queue wait, memory, and shutdown duration for declared workloads - List cases where a runtime-native executor is preferable Implementation constraints - Do not generalize results beyond the recorded machine and workload profiles. Verification - Reproduce one CPU-bound and one mixed-duration benchmark from a clean checkout. - Run the unsupported permanently blocking job and confirm the guide predicts the outcome. Deliverables - Contract, benchmark manifest, and adoption checklist Rollout and recovery: Require each adopter to select and verify a workload profile. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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.