# 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. ## DREL — Promote one immutable release through every environment A fictional scheduling API is rebuilt separately for test, staging, and production-like local environments. The resulting images differ, release notes list the branch instead of the artifact, and rollback rebuilds old source with new dependencies. Use a local registry simulator and synthetic deployments; no cluster or customer traffic is supplied. **Field:** DevOps. **Suggested stack:** TypeScript, OCI metadata, Git, Deployment simulator. **Engineer value:** Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. **Company value:** Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Artifact digests - Release states - Health checks ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DREL-101 — Bind release identity to an artifact digest **Task · Medium priority · Foundational** noCV practice brief v5 · DREL-101 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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 deployment record stores image:latest and commit branch, so two releases display the same identity after the tag moves. Acceptance criteria - Release stores immutable artifact digest, source revision, and build manifest hash - Mutable tags resolve to a digest before approval - Display distinguishes requested tag from deployed digest Implementation constraints - Use the local registry simulator and never pull public images. Verification - Resolve and deploy one fixture tag while retaining its digest. - Move the tag and confirm the approved release identity does not change. Deliverables - Immutable release record and moved-tag test Rollout and recovery: Require digest resolution before any environment accepts a new release. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-102 — Generate release notes from the promoted revision range **Bug · Medium priority · Foundational** noCV practice brief v5 · DREL-102 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DREL-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Notes include commits merged after the artifact was built because they query the current branch head. Acceptance criteria - Notes bind previous and current immutable source revisions - Each change links to its synthetic pull-request identity - Empty, missing, and nonancestor ranges have explicit outcomes Implementation constraints - Do not use current branch state after release creation. Verification - Generate notes for a declared three-change revision range. - Advance the branch and confirm the existing notes remain unchanged. Deliverables - Revision-bound notes generator and history fixtures Rollout and recovery: Publish notes as draft until artifact and range reconciliation pass. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-103 — Promote the built artifact instead of rebuilding it **Story · Medium priority · Intermediate** noCV practice brief v5 · DREL-103 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DREL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Cloud infrastructure 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. Staging and production-like environments run images compiled at different times from the same source label. Acceptance criteria - Build creates one content-addressed artifact - Promotion changes environment references without changing bytes - Environment record retains promotion actor, time, and source environment Implementation constraints - Configuration remains external and versioned; it is not baked differently into each image. Verification - Promote one digest through two fixture environments and compare bytes. - Attempt promotion with a mismatching manifest and block the transition. Deliverables - Promotion command and byte-identity tests Rollout and recovery: Adopt from test to staging before changing the final environment. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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 change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DREL-104 — Gate promotion on database compatibility **Chore · Medium priority · Intermediate** noCV practice brief v5 · DREL-104 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A release expects a renamed column while rollback still expects the old one, making the nominal rollback artifact unusable. Acceptance criteria - Manifest declares required and provided schema compatibility window - Promotion checks current environment schema before deployment - Rollback target is validated against post-migration schema Implementation constraints - Use fixture schema versions; do not execute migrations against a real database. Verification - Promote an expand-compatible release and validate its rollback target. - Attempt a contract-first release and show the gate identifies the incompatible direction. Deliverables - Schema compatibility gate and rollout matrix Rollout and recovery: Require expand, migrate, contract phases for destructive changes. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-105 — Canary one cohort with a measurable abort rule **Task · High priority · Advanced** noCV practice brief v5 · DREL-105 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-103, DREL-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A canary is called healthy because no one watched it for long, despite a synthetic error spike in one endpoint. Acceptance criteria - Canary binds cohort, duration, traffic minimum, and comparison baseline - Abort evaluates declared error and latency thresholds - Insufficient observations remain inconclusive Implementation constraints - Use deterministic synthetic traffic; thresholds apply only to this exercise. Verification - Run a healthy canary through the full observation window. - Inject an endpoint-specific regression and confirm automatic halt before wider rollout. Deliverables - Canary policy, evaluator, and regression fixtures Rollout and recovery: Expand only after a conclusive passing result. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-106 — Pause a release when deployment state drifts **Bug · High priority · Advanced** noCV practice brief v5 · DREL-106 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A manual fixture change replaces one replica image, but the release controller continues and records the target digest as complete. Acceptance criteria - Reconciliation compares desired and observed digest per instance - Unexpected drift pauses rollout and identifies affected instances - Repair requires an explicit decision to restore desired state or adopt a new release Implementation constraints - Do not overwrite drift before recording it. Verification - Complete a rollout whose observations match the release. - Change one instance out of band and confirm the controller pauses without erasing evidence. Deliverables - Drift detector and paused-release flow Rollout and recovery: Begin with report-only drift detection in the simulator. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-107 — Authorize release approval for the exact artifact **Story · High priority · Expert** noCV practice brief v5 · DREL-107 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-101, DREL-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Security 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 approval made for one digest remains valid after the release record is edited to point at another artifact. Acceptance criteria - Approval binds artifact digest, environment, policy version, and expiry - Any bound-field change invalidates approval - Requester cannot satisfy a required independent approval role Implementation constraints - Use synthetic identities and permissions; this is workflow authorization, not proof of code authorship. Verification - Approve and promote the exact eligible release. - Change digest and replay the approval token, then verify denial and audit. Deliverables - Release approval boundary and replay tests Rollout and recovery: Require explicit approval for the final simulated environment first. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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 and improve Measure the workflow, rehearse recovery, and document ownership. #### DREL-108 — Rollback to a known artifact without rebuilding source **Chore · High priority · Advanced** noCV practice brief v5 · DREL-108 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DREL-104, DREL-105, DREL-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. The rollback command checks out an old tag and rebuilds it with current dependencies, producing bytes never previously tested. Acceptance criteria - Rollback selects a previously promoted immutable digest - Compatibility gate evaluates current schema and configuration - Release history records the failed and restored identities Implementation constraints - Rollback does not delete the failed artifact or rewrite its record. Verification - Roll forward, trigger the abort rule, and restore the exact prior digest. - Remove the prior artifact from the registry fixture and block rollback with a recovery instruction. Deliverables - Digest-based rollback command and rehearsal Rollout and recovery: Maintain at least one verified compatible rollback target per environment. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-109 — Resume promotion after the registry response disappears **Task · High priority · Expert** noCV practice brief v5 · DREL-109 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DREL-103, DREL-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Integrations 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 registry accepts a promotion tag and drops the response; retry sees the tag but cannot tell whether it was created by this operation. Acceptance criteria - Promotion uses deterministic operation identity - Retry reads digest and operation metadata before mutation - Conflicting existing tag becomes visible and blocks automatic continuation Implementation constraints - The registry adapter is local and provider responses are treated as untrusted input. Verification - Promote and replay one operation with the same result. - Drop the acceptance response and separately precreate a conflicting tag. Deliverables - Idempotent promotion adapter and ambiguity tests Rollout and recovery: Enable one registry namespace while retaining digest-only deployment. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-110 — Publish a release ledger that answers what is running **Bug · Medium priority · Intermediate** noCV practice brief v5 · DREL-110 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DREL-102, DREL-106, DREL-108, DREL-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. During a rehearsal, responders compare commit hashes from logs because there is no single view of release, artifact, configuration, and schema identity. Acceptance criteria - Ledger shows desired and observed artifact per environment - Entries include configuration and schema compatibility identities - Failed, paused, rolled-back, and superseded releases remain inspectable Implementation constraints - The ledger is append-oriented planning and operational data; it is not candidate evidence. Verification - Trace a promotion, pause, and rollback from ledger entries. - Remove an observation and confirm the view displays uncertainty rather than inferred state. Deliverables - Release ledger projection and responder guide Rollout and recovery: Use the ledger during a full local rollback rehearsal before handoff. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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.