# 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. ## DCI — Make pull-request CI trustworthy under load A fictional TypeScript monorepo has twelve packages and a local CI simulator. Pull requests wait for redundant work, stale caches occasionally pass broken changes, and superseded runs continue consuming executors. Create synthetic package graphs and fake check APIs; no hosted CI credentials or production repositories are supplied. **Field:** DevOps. **Suggested stack:** TypeScript, pnpm, Git, CI simulator. **Engineer value:** Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. **Company value:** Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. **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 - Dependency graphs - Process exit codes - Test isolation ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DCI-101 — Pin the required-check contract before optimizing the pipeline **Task · Medium priority · Foundational** noCV practice brief v5 · DCI-101 · Make pull-request CI trustworthy under load 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% · 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. Branch protection expects names that differ from the workflow after a recent rename, leaving one required check permanently pending. Acceptance criteria - Declare stable check identities and their owning commands - Map every protected check to exactly one terminal report - Unknown or duplicated check names fail workflow validation Implementation constraints - The local simulator must not call a real repository or modify branch protection. Verification - Complete every declared check and reconcile its final status. - Rename and duplicate a check, then confirm validation blocks the workflow. Deliverables - Required-check manifest and consistency test Rollout and recovery: Publish the manifest before changing job topology. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-102 — Fail the pipeline when a command exits through a hidden pipe **Bug · Medium priority · Foundational** noCV practice brief v5 · DCI-102 · Make pull-request CI trustworthy under load 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% · 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. Test output is piped through a formatter; the formatter succeeds after the test process fails, so the job reports green. Acceptance criteria - Job status reflects every command in the pipeline - Original stdout and stderr remain available - Signal termination and ordinary nonzero exit are distinguished Implementation constraints - Do not parse human-readable output to determine success. Verification - Run successful tests through the formatter and retain readable logs. - Fail the upstream process and verify the job reports its exact failure. Deliverables - Exit-status wrapper and pipeline regression Rollout and recovery: Apply first to test jobs, then audit every piped command. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-103 — Compute affected packages from both dependency directions **Story · Medium priority · Intermediate** noCV practice brief v5 · DCI-103 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DCI-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Developer tooling 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. Changing a shared type package runs its own tests but skips three consumers that compile against the changed contract. Acceptance criteria - Changed packages and transitive consumers enter the affected set - Deleted and renamed files map to their owning package - Global configuration changes select the declared full set Implementation constraints - Use the synthetic graph and explicit ownership rules; filename substring guesses are insufficient. Verification - Change a leaf, shared library, and root configuration and compare selected packages. - Create a dependency cycle fixture and fail analysis without silently dropping nodes. Deliverables - Affected-graph selector and graph fixtures Rollout and recovery: Run selection in report-only mode beside the current full pipeline. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-104 — Key build caches from every semantic input **Chore · Medium priority · Intermediate** noCV practice brief v5 · DCI-104 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-103. Difficulty: Intermediate. Estimated focused work: 150 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. A cache hit reuses generated clients after the schema changed because only source-directory files contribute to the key. Acceptance criteria - Cache identity includes command, toolchain, environment contract, direct inputs, and dependency outputs - Secrets and absolute workspace paths are excluded - Restore verifies metadata before using outputs Implementation constraints - A cache hit may improve speed but cannot waive required checks. Verification - Repeat an identical build and verify a safe hit. - Change schema, compiler version, and an upstream output independently and require misses. Deliverables - Canonical cache manifest and invalidation tests Rollout and recovery: Enable read-only restore before allowing new cache writes. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-105 — Cancel superseded pull-request runs without erasing evidence **Task · High priority · Advanced** noCV practice brief v5 · DCI-105 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-101, DCI-102. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A force-push starts a new run while the old run still publishes late check results under the branch name. Acceptance criteria - Concurrency identity binds repository, pull request, and immutable revision - New revision requests cancellation of older active runs - Late results remain tied to their original revision and cannot satisfy the new one Implementation constraints - Cancellation is cooperative and must not mark unfinished checks successful. Verification - Start two revisions and verify only the new one remains eligible. - Deliver a late success from the old run and prove it cannot update the new revision. Deliverables - Revision-scoped concurrency controller and race test Rollout and recovery: Canary on the local simulator while recording saved executor time. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-106 — Quarantine a flaky test without making it optional forever **Bug · High priority · Advanced** noCV practice brief v5 · DCI-106 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-101. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Quality 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 timing-sensitive test is retried until it passes, hiding a rising failure rate and extending every pull request. Acceptance criteria - First-attempt and retry outcomes remain separate - Quarantine has owner, reason, expiry, and tracking reference - Expired quarantine fails the policy check Implementation constraints - Do not classify a test as flaky from one failure; use the supplied deterministic failure history. Verification - Quarantine the documented test and keep its outcomes visible. - Expire or omit ownership and confirm the pipeline blocks rather than silently skips. Deliverables - Quarantine registry, policy check, and trend fixture Rollout and recovery: Limit quarantine to named tests and review before expiry. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-107 — Prevent untrusted pull requests from receiving release secrets **Story · High priority · Expert** noCV practice brief v5 · DCI-107 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-101, DCI-103. 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. The same reusable workflow handles internal branches and external pull requests, and a broad token is present before trust is evaluated. Acceptance criteria - Trust context is resolved before selecting credentials or privileged jobs - Untrusted revisions receive read-only checkout and no protected environment - Privileged continuation binds the reviewed immutable revision Implementation constraints - Use fake secret handles and repository events; never place a credential value in fixtures or logs. Verification - Run trusted and untrusted event fixtures and compare granted capabilities. - Change the revision after approval and confirm privileged jobs refuse to start. Deliverables - CI trust-boundary policy and event matrix Rollout and recovery: Fail closed for ambiguous event provenance. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-108 — Measure queue and execution delay separately **Chore · High priority · Advanced** noCV practice brief v5 · DCI-108 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DCI-103, DCI-104, DCI-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. The team calls CI slow from total duration, but most delay occurs before an executor starts during the morning burst. Acceptance criteria - Record created, queued, started, and completed timestamps - Report queue, setup, execution, and artifact phases separately - Percentiles retain workload and executor-class dimensions only Implementation constraints - Use bounded synthetic dimensions and state the observation window. Verification - Reconcile phase durations for a mixed local workload. - Omit a timestamp and confirm the run is marked incomplete rather than assigned zero delay. Deliverables - CI latency model and workload report Rollout and recovery: Use the baseline before changing runner count or job structure. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-109 — Resume reporting after the checks API loses a response **Task · High priority · Expert** noCV practice brief v5 · DCI-109 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DCI-105, DCI-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 fake checks API accepts a final status and drops the response; the reporter retries by creating a second check with conflicting output. Acceptance criteria - One deterministic external-check identity exists per run and check - Retry reconciles remote state before creating anything - Conflicting terminal state becomes visible and stops automation Implementation constraints - Provider calls occur outside database transactions and use the local controllable adapter. Verification - Publish each terminal status once and replay reporting safely. - Drop the response after acceptance and verify reconciliation finds the existing result. Deliverables - Idempotent check reporter and lost-response drill Rollout and recovery: Enable for one check family while retaining the prior reporter for rollback. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-110 — Hand off CI ownership with a safe degraded mode **Bug · Medium priority · Intermediate** noCV practice brief v5 · DCI-110 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DCI-106, DCI-107, DCI-108, DCI-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. When the cache or check provider is unavailable, maintainers do not know which failures can fall back and which must block merging. Acceptance criteria - Runbook names owners, dependencies, alerts, and escalation conditions - Cache outage falls back to uncached required checks - Check-reporting uncertainty blocks eligibility while preserving local results Implementation constraints - Do not claim merge protection changes; the exercise documents the intended integration contract. Verification - Rehearse cache loss and complete an uncached run. - Lose final check acknowledgement and follow the block-and-reconcile path. Deliverables - CI runbook and two recovery rehearsals Rollout and recovery: Review the runbook with a second engineer before adopting the workflow. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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.