# 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. ## QUEUE — Bring document processing back under control A fictional internal document portal creates previews through a trusted mock renderer. Large batches crowd out small teams, failed documents retry forever, and operators lack a safe replay command. This exercise never executes uploaded code or real document macros. **Field:** Platform engineering. **Suggested stack:** TypeScript, BullMQ, Redis, PostgreSQL, Object storage. **Engineer value:** Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. **Company value:** See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. **Delivery agreement:** Ten tickets in intake, resilience, and operations phases; use only synthetic document metadata and a trusted deterministic renderer. ### Setup prerequisites - Queue semantics - Database transactions - Operational metrics ### Account for accepted work Create traceable jobs with bounded inputs. #### QUEUE-101 — Expose a document job's current phase and terminal reason **Story · Medium priority · Foundational** noCV practice brief v5 · QUEUE-101 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Account for accepted work. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Platform engineering 30% · Backend 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 portal shows Processing for both queued and permanently rejected documents. Support cannot tell whether a file is waiting, rendering, or never going to finish. Acceptance criteria - Expose QUEUED, RUNNING, SUCCEEDED, FAILED, and CANCELLED through an allowlisted projection. - Include a stable terminal reason code and last transition time. - Deny jobs owned by another tenant. Implementation constraints - Only service transition methods may update lifecycle state; logs are not the source of truth. Verification - Read queued and failed fixture jobs with distinct explanations. - Reject foreign-tenant lookup and ensure renderer payloads are absent. Deliverables - Job status contract and authorized read endpoint Rollout and recovery: Switch status reads for synthetic jobs first; retain historical transition records if the view is reverted. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-102 — Reject oversized document batches before accepting work **Task · High priority · Foundational** noCV practice brief v5 · QUEUE-102 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Account for accepted work. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Performance engineering 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 client submits 50,000 document references in one call. Validation exhausts API memory before the queue sees a single job. Acceptance criteria - Enforce a documented request byte limit and a maximum of 100 document references. - Reject duplicate references within the batch with a clear validation reason. - Create no jobs when batch validation fails. Implementation constraints - Validate metadata only; the API must not download or render document contents. Verification - Accept a valid 100-reference synthetic batch. - Reject 101 references, excessive bytes, and duplicate references without partial jobs. Deliverables - Bounded batch contract and boundary cases Rollout and recovery: Publish limits before enforcing them on the test client; rollback client batching rather than raising limits without measurement. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-103 — Commit job acceptance and dispatch intent together **Bug · High priority · Advanced** noCV practice brief v5 · QUEUE-103 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Account for accepted work. Depends on: QUEUE-101, QUEUE-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Database engineering 30% · 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. Pattern topics: Transactional Outbox (apply). Transactional Outbox — Apply: Commit acceptance and dispatch intent in one transaction, then demonstrate recovery after the queue is unavailable or the process stops before dispatch. 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. The portal returns 202 after storing a job, then loses Redis connectivity before enqueueing it. The job stays QUEUED forever with no delivery attempt. Acceptance criteria - Commit accepted job records and durable dispatch intents atomically. - Dispatch retries use deterministic job identities. - A failed database transaction cannot return accepted status. Implementation constraints - Queue messages contain identifiers and bounded metadata, not document bytes. Verification - Lose Redis after acceptance and recover every job when dispatch resumes. - Fail the database commit and assert neither job nor dispatch intent exists. Deliverables - Outbox-backed acceptance and recovery reproduction Rollout and recovery: Drain synthetic pending intents through the new dispatcher; pause dispatch without deleting accepted work to rollback. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. ### Handle failures deliberately Control retries, concurrency, cancellation, and worker loss. #### QUEUE-104 — Stop retrying unsupported document formats **Bug · High priority · Intermediate** noCV practice brief v5 · QUEUE-104 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Site reliability 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. The trusted mock renderer returns UNSUPPORTED_FORMAT for a fixture file. The worker retries it every minute, consuming the same capacity as a temporary storage timeout. Acceptance criteria - Classify unsupported format as terminal and storage timeout as retryable. - Apply a bounded attempt count and backoff policy to retryable failures. - Record each attempt and the final exhaustion reason without replacing earlier failures. Implementation constraints - Unknown provider errors need an explicit conservative policy; do not retry forever. Verification - Retry a transient failure that succeeds on its third attempt. - Verify unsupported format runs once and persistent timeout reaches a bounded terminal state. Deliverables - Failure classification table and retry policy Rollout and recovery: Apply new classification to future attempts; stop scheduling exhausted jobs without erasing their attempt history. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-105 — Keep one team's bulk import from occupying every worker **Story · High priority · Advanced** noCV practice brief v5 · QUEUE-105 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-103, QUEUE-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Performance engineering 30% · Distributed systems 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 synthetic tenant uploads 10,000 documents. A second tenant's single preview waits behind the entire batch although the renderer has spare concurrency slots between completions. Acceptance criteria - Enforce configured global and per-tenant active-job limits. - Allow eligible tenants to make progress while a bulk tenant has backlog. - Release capacity after success, terminal failure, cancellation, or expired execution lease. Implementation constraints - Do not create an unbounded queue or metric family per tenant; explain the fairness policy. Verification - Run one bulk tenant and two small tenants and measure their wait times. - Crash a worker while holding capacity and prove another eligible tenant eventually progresses. Deliverables - Fair dispatch policy and controlled-load report Rollout and recovery: Start with conservative synthetic limits; disable new intake and drain leases if accounting diverges. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-106 — Fence a late worker after its rendering lease expires **Bug · High priority · Expert** noCV practice brief v5 · QUEUE-106 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-104, QUEUE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Platform 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. Worker A pauses long enough to lose its lease. Worker B completes the same preview, then A resumes and overwrites B's artifact pointer with stale output. Acceptance criteria - Associate each execution attempt with a monotonic fencing identity. - Accept completion only from the current authorized lease holder. - Keep rejected late completions observable and prevent them from changing terminal job state. Implementation constraints - Lease expiration alone does not stop a process; the persistence boundary must reject stale writes. Verification - Expire A, complete through B, then submit A's completion and inspect unchanged output. - Replay B's completion and assert one terminal transition and artifact reference. Deliverables - Fenced completion operation and paused-worker reproduction Rollout and recovery: Introduce fencing before extending concurrency; rollback dispatch while retaining fencing checks on completions. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-107 — Cancel queued work without racing a completed preview **Story · Medium priority · Advanced** noCV practice brief v5 · QUEUE-107 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Platform engineering 30% · Distributed systems 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 user cancels a batch just as one preview finishes. The portal reports Cancelled while retaining an accessible success artifact, and a retry renders it again. Acceptance criteria - Make cancellation an authorized state transition with documented running-job semantics. - Resolve cancellation and completion races to one terminal result. - Prevent cancelled jobs from being newly dispatched or retried. Implementation constraints - For the mock renderer, cancellation can be cooperative; disclose work that cannot stop immediately. Verification - Cancel queued work and prove the renderer is never called. - Race running completion and cancellation, then replay both commands and inspect stable state. Deliverables - Cancellation contract and race regression Rollout and recovery: Enable queued cancellation first, then running cancellation after the race cases pass; retain terminal records on rollback. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. ### Make recovery routine Expose useful lag signals and safe repair operations. #### QUEUE-108 — Measure oldest runnable work instead of queue size alone **Chore · Medium priority · Intermediate** noCV practice brief v5 · QUEUE-108 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make recovery routine. Depends on: QUEUE-104, QUEUE-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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 queue contains only ten jobs, but the oldest eligible preview has waited 40 minutes. A queue-depth alert never fires, while scheduled retries inflate another dashboard. Acceptance criteria - Measure oldest eligible-job age separately from delayed retries and running age. - Expose attempt exhaustion and stale-lease counts with bounded labels. - Alert when eligible wait exceeds the fixture's ten-minute budget for two observations. Implementation constraints - Exclude document IDs and tenant IDs from metric label sets. Verification - Advance a controlled clock and trigger runnable-age paging. - Keep a future retry delayed and verify it does not inflate eligible wait. Deliverables - Queue age metrics and diagnosis-oriented alert Rollout and recovery: Compare alerts with the synthetic workload trace in report-only mode before paging. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-109 — Replay a failed preview through an audited repair command **Task · High priority · Intermediate** noCV practice brief v5 · QUEUE-109 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make recovery routine. Depends on: QUEUE-104, QUEUE-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 40% · Backend 30% · Security 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. Operators repair failed jobs by deleting Redis keys. That loses failure history and can replay work for the wrong tenant when a copied ID is mistaken. Acceptance criteria - Allow an authorized operator to create a linked repair attempt for a terminal failure. - Require tenant scope, expected job revision, and a reason. - Preserve original failure history and make duplicate repair requests idempotent. Implementation constraints - Do not reopen the failed record in place or expose a general queue-management console. Verification - Repair one terminal fixture failure and follow the linked attempts. - Reject a foreign tenant, stale revision, and repair of a successful job. Deliverables - Scoped repair command and audit projection Rollout and recovery: Grant repair permission to a synthetic operator role; revoke command access while retaining read-only audit history. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-110 — Collect orphaned preview artifacts without deleting live output **Task · Medium priority · Advanced** noCV practice brief v5 · QUEUE-110 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make recovery routine. Depends on: QUEUE-106, QUEUE-107, QUEUE-109. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Platform engineering 30% · Distributed systems 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 worker writes an artifact then loses its lease before committing the pointer. Storage grows with orphaned previews, but a naive age-based cleanup can delete an output still being committed. Acceptance criteria - Separate temporary attempt artifacts from committed output references. - Delete only unreferenced artifacts beyond a documented grace period with no active lease. - Make cleanup resumable and record bounded deletion outcomes. Implementation constraints - Use synthetic objects; an artifact listing alone cannot prove an object is unreferenced. Verification - Collect an abandoned attempt artifact after its grace period. - Race cleanup with a valid completion and prove committed output survives. Deliverables - Orphan collector, race fixture, and dry-run manifest Rollout and recovery: Review deletion manifests in dry-run mode, then enable cleanup for the synthetic storage prefix only. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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.