# 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. ## ROLL — Make a small service release recoverable A fictional scheduling service has an API, a worker, and PostgreSQL. Releases use immutable images on two application instances. The team needs compatibility checks, staged traffic, and a rehearsed rollback without introducing a new orchestration platform. **Field:** Platform engineering. **Suggested stack:** TypeScript, OCI image metadata, PostgreSQL, CI workflows. **Engineer value:** Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. **Company value:** Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. **Delivery agreement:** Ten phased issues using a synthetic service and simulated release provider; submit manifests, failure drills, and an operator handoff. ### Setup prerequisites - HTTP health checks - CI pipelines - Database migrations ### Know what is running Establish artifact identity and useful health signals. #### ROLL-101 — Display the exact release identity in diagnostics **Task · Medium priority · Foundational** noCV practice brief v5 · ROLL-101 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what is running. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. Two API instances report version latest even though only one received yesterday's build. On call cannot connect a failing request to its deployed artifact. Acceptance criteria - Expose build revision, immutable artifact digest, and deployment ID through an authorized diagnostic endpoint. - Fail validation when a release manifest lacks immutable identity. - Keep build secrets and environment values outside the response. Implementation constraints - The build injects identity; request parameters cannot override it. Verification - Read distinct diagnostics from two synthetic release versions. - Reject a manifest containing only a mutable tag and inspect response redaction. Deliverables - Release manifest schema and diagnostic projection Rollout and recovery: Add diagnostics before changing deployment routing; remove endpoint exposure without changing artifact identities. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-102 — Separate liveness from database readiness **Bug · High priority · Foundational** noCV practice brief v5 · ROLL-102 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what is running. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. A brief database outage makes the process liveness endpoint fail. The restart policy kills every API instance and turns a recoverable connection issue into a restart loop. Acceptance criteria - Liveness reports whether the process can serve its own health handler. - Readiness fails when required database operations cannot complete within a bounded timeout. - Dependency errors return a stable diagnostic code without connection strings. Implementation constraints - A readiness probe must not create user records or run migrations. Verification - Assert both probes succeed with healthy synthetic dependencies. - Disable the database and verify readiness fails while liveness remains successful. Deliverables - Separate health routes and dependency-outage reproduction Rollout and recovery: Switch traffic readiness first, then restart-policy probes; restore prior routing if probe semantics are misconfigured. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-103 — Refuse deploys with incomplete runtime configuration **Task · High priority · Intermediate** noCV practice brief v5 · ROLL-103 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what is running. Depends on: ROLL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. The new worker image needs STORAGE_REGION, but its environment is missing the setting. The rollout reports success while every document job fails on first use. Acceptance criteria - Validate required settings and allowed combinations before readiness succeeds. - Produce setting names and reason codes without printing values. - Validate API and worker manifests against their own declared configuration versions. Implementation constraints - Use dummy values in fixtures; configuration validation cannot contact production services. Verification - Validate complete API and worker manifests. - Reject missing storage region and incompatible settings while checking log redaction. Deliverables - Configuration preflight and role-specific fixtures Rollout and recovery: Run preflight as an advisory CI step, then block invalid synthetic release manifests. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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 release risk Enforce compatibility, serialization, and staged rollout decisions. #### ROLL-104 — Keep old API instances working during a column rename **Task · High priority · Advanced** noCV practice brief v5 · ROLL-104 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control release risk. Depends on: ROLL-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. A migration renames booking.start to booking.starts_at before old API instances finish draining. Half the requests fail until every instance updates. Acceptance criteria - Define expand, compatible application rollout, backfill, and contract stages. - Prove old and new application versions work during the supported overlap. - Block destructive cleanup while the old reader version remains active. Implementation constraints - Include rollback compatibility explicitly; a reverse rename alone is not a release strategy. Verification - Run mixed-version synthetic requests through the expanded schema. - Attempt cleanup with an old instance present and assert the gate blocks. Deliverables - Versioned migration plan and mixed-version compatibility checks Rollout and recovery: Apply only expansion first; rollback application traffic before the contract stage if errors appear. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-105 — Prevent two release jobs from overwriting the same environment **Bug · High priority · Advanced** noCV practice brief v5 · ROLL-105 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control release risk. Depends on: ROLL-101, ROLL-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. Two commits deploy simultaneously. The older job finishes last and marks its artifact current after the newer release already passed validation. Acceptance criteria - Serialize mutations per environment with a bounded renewable lease. - Reject state updates from expired or superseded lease holders. - Record the winning release identity and every rejected stale update. Implementation constraints - A process-local mutex cannot coordinate independent CI jobs. Verification - Race two simulated releases and inspect one current manifest. - Expire a lease, acquire a successor, and prove the old holder cannot publish. Deliverables - Release lease protocol and stale-writer regression Rollout and recovery: Enable serialization on the test environment; disable dispatch while investigating lease failures. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-106 — Base canary decisions on enough comparable requests **Story · High priority · Expert** noCV practice brief v5 · ROLL-106 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control release risk. Depends on: ROLL-102, ROLL-104, ROLL-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Platform engineering 40% · Performance 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. A release automatically promotes after five error-free canary requests while the stable version serves thousands. Low traffic makes an untested version look healthy. Acceptance criteria - Require a configured minimum request count and observation window before promotion. - Compare matching route classes with error-rate and latency budgets declared in the fixture. - Return HOLD for insufficient traffic and ABORT for breached safety thresholds. Implementation constraints - Use bounded route labels; a percentage alone cannot justify a decision without sample counts. Verification - Promote a synthetic canary with adequate comparable traffic. - Exercise sparse traffic, a route-mix shift, and rising errors; inspect HOLD or ABORT reasons. Deliverables - Canary decision function, fixture traces, and decision report Rollout and recovery: Run decisions in observe mode against simulated traffic before allowing the simulated provider to advance stages. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. ### Recover with evidence Drain work, diagnose failures, and rehearse rollback. #### ROLL-107 — Drain long requests before retiring an API instance **Bug · High priority · Intermediate** noCV practice brief v5 · ROLL-107 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Networking 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. During release, an instance exits halfway through a report download. The load balancer keeps sending new requests during its shutdown grace period. Acceptance criteria - Mark the instance unready before starting its bounded drain period. - Allow existing requests to complete until the documented deadline. - Close remaining connections and report forced terminations at deadline without hanging shutdown. Implementation constraints - Do not count idle keep-alive connections as unfinished business requests indefinitely. Verification - Start a long synthetic request, initiate shutdown, and observe completion. - Keep a request stuck beyond the deadline and confirm bounded exit and termination count. Deliverables - Graceful shutdown behavior and request-drain reproduction Rollout and recovery: Exercise draining on one test instance; restore the previous grace settings if traffic does not stop arriving. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-108 — Do not roll back a worker into an unreadable job format **Task · High priority · Expert** noCV practice brief v5 · ROLL-108 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-104, ROLL-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Distributed systems 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 v8 enqueues a new payload shape. Rolling back to v7 starts a retry storm because v7 cannot parse jobs already accepted by v8. Acceptance criteria - Version job envelopes and declare the worker versions able to consume each version. - Gate rollback when queued work would become unreadable. - Provide a safe drain or compatibility path that preserves accepted job identities. Implementation constraints - Do not rewrite historical payloads in place or discard incompatible jobs to make rollback green. Verification - Process old and new fixture envelopes with the declared compatible worker. - Attempt an incompatible rollback with queued v8 work and assert a useful blocking reason. Deliverables - Job compatibility matrix and rollback preflight Rollout and recovery: Deploy backward readers before new writers; remove old readers only after the compatibility window closes. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-109 — Attach a release marker to bounded operational telemetry **Chore · Medium priority · Intermediate** noCV practice brief v5 · ROLL-109 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-101, ROLL-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. An error spike starts near a deploy, but the dashboard has no release event or stable artifact link. Engineers compare screenshots and guess which change was live. Acceptance criteria - Emit a release event with environment, deployment ID, artifact digest, and stage outcome. - Link stage failures to sanitized diagnostic references. - Keep request bodies, secret values, and arbitrary commit messages out of metric labels. Implementation constraints - Store high-cardinality release details in events; use bounded dimensions for metrics. Verification - Trace a simulated canary abort from its marker to its release manifest. - Inject secret-like fixture metadata and verify the telemetry projection excludes it. Deliverables - Release event schema and incident dashboard query Rollout and recovery: Add markers without changing alert thresholds; disable the new event sink if it delays release decisions. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-110 — Rehearse an aborted release and write the operator handoff **Task · Medium priority · Intermediate** noCV practice brief v5 · ROLL-110 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-106, ROLL-107, ROLL-108, ROLL-109. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Site reliability 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 release checklist says rollback tested, but nobody has timed recovery or tried it with an expanded database schema and pending worker jobs. Acceptance criteria - Run one simulated failed canary with pending jobs and expanded schema. - Record detection, abort, drain, and recovery timestamps with observed limitations. - Provide exact preconditions and stop conditions for the documented rollback path. Implementation constraints - A simulated drill establishes fixture behavior only; label its measured timings accordingly. Verification - Recover the previous compatible release and reconcile accepted jobs. - Include an incompatible rollback example and prove the checklist tells the operator to stop. Deliverables - Recorded release drill and operator runbook Rollout and recovery: Version the runbook with the tested manifests; repeat the bounded drill when compatibility assumptions change. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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.