# 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. ## DART — Build an artifact path that can defend what it publishes A fictional command-line product publishes local package archives. Builds contain timestamps, checksums are copied without provenance, and cleanup can delete the only rollback artifact. Use generated source trees, ephemeral development signing keys, and local object storage; no public registry or production key is supplied. **Field:** DevOps. **Suggested stack:** TypeScript, Tar, S3-compatible adapter, Ephemeral signing provider. **Engineer value:** Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. **Company value:** Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. **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 - Content hashing - Archive formats - Release metadata ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DART-101 — Make archive bytes reproducible from the same source manifest **Task · Medium priority · Foundational** noCV practice brief v5 · DART-101 · Build an artifact path that can defend what it publishes 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% · 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. Two builds from identical fixtures differ because archive order, timestamps, ownership, and path separators come from the host. Acceptance criteria - Sort entries by canonical relative path - Normalize declared timestamps, ownership, permissions, and separators - Reject paths escaping or colliding after normalization Implementation constraints - Use generated files only and do not archive the repository working tree. Verification - Build twice in different temporary roots and compare byte digests. - Add traversal and normalization-collision paths and confirm rejection. Deliverables - Deterministic archive writer and reproducibility tests Rollout and recovery: Publish reproducibility metadata before replacing the current archive path. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-102 — Generate a dependency inventory from resolved inputs **Bug · Medium priority · Foundational** noCV practice brief v5 · DART-102 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DART-101. Difficulty: Foundational. Estimated focused work: 90 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 package manifest lists declared ranges, not the exact dependency versions bundled into the archive. Acceptance criteria - Inventory records exact package, version, integrity, and relationship - Generation uses the resolved lock and packaged output - Unknown or duplicate identities fail the release gate Implementation constraints - Do not contact public vulnerability or package services in the exercise. Verification - Generate a stable inventory for the fixture lockfile. - Remove an integrity entry and add a duplicate package identity, then block publication. Deliverables - Dependency inventory generator and malformed-lock tests Rollout and recovery: Attach inventory to local artifacts before enforcing completeness. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-103 — Bind provenance to source, builder, and exact artifact **Story · Medium priority · Intermediate** noCV practice brief v5 · DART-103 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DART-101, DART-102. Difficulty: Intermediate. Estimated focused work: 150 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. A provenance file names a commit but is copied beside a different archive without detection. Acceptance criteria - Statement binds artifact digest, source revision, build recipe, and builder identity - Verification recomputes the artifact digest - Unknown statement fields are preserved or rejected by version policy Implementation constraints - Builder identity is a synthetic workload identity, not a person or authorship claim. Verification - Verify the matching artifact and statement. - Swap artifact and source identities independently and confirm failure. Deliverables - Versioned provenance statement and verifier Rollout and recovery: Require verified provenance for a single fixture channel first. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-104 — Keep signing keys outside the build workspace **Chore · Medium priority · Intermediate** noCV practice brief v5 · DART-104 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · 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. The build job receives an exportable private key file that any build script could read or include in the archive. Acceptance criteria - Build produces an unsigned digest and signing request - Signing provider accepts only authorized artifact metadata - Private key bytes never enter workspace, logs, or artifacts Implementation constraints - Use ephemeral local keys behind a provider interface; production key management remains unprovisioned. Verification - Sign and verify an authorized fixture artifact. - Search outputs for a sentinel key and reject an unauthorized digest request. Deliverables - Signing-provider boundary and leak tests Rollout and recovery: Keep unsigned artifacts nonpromotable while the development signer is enabled. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-105 — Promote only artifacts whose evidence set reconciles **Task · High priority · Advanced** noCV practice brief v5 · DART-105 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-102, DART-103, DART-104. Difficulty: Advanced. Estimated focused work: 240 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. A package is promoted after signature verification even though its inventory belongs to an earlier build. Acceptance criteria - Gate binds artifact, provenance, inventory, signature, and policy versions - Every component references the same artifact digest - Missing or conflicting metadata blocks promotion with exact reasons Implementation constraints - This verifies release metadata, not candidate Outcome Evidence or ownership. Verification - Promote one complete matching fixture set. - Mix inventory, signature, and provenance from neighboring builds and reject each case. Deliverables - Artifact evidence-set gate and mismatch matrix Rollout and recovery: Run the gate in report-only mode before making it mandatory. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-106 — Prevent a mutable channel from changing an approved artifact **Bug · High priority · Advanced** noCV practice brief v5 · DART-106 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Distributed 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. The beta channel is approved while pointing to one digest, then its mutable object is overwritten before clients resolve it. Acceptance criteria - Approval binds channel, digest, and revision - Channel update uses compare-and-set against observed revision - Clients can resolve historical channel revisions Implementation constraints - Channel is discovery metadata; the artifact remains content addressed and immutable. Verification - Advance beta from one approved digest to another. - Race two channel updates and verify only one wins without overwriting history. Deliverables - Versioned channel pointer and concurrency test Rollout and recovery: Enable one nondefault fixture channel before broader use. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-107 — Revoke a compromised signing identity without deleting history **Story · High priority · Expert** noCV practice brief v5 · DART-107 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-104, DART-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 65% · Security 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 development signing key is declared compromised, and the cleanup proposal deletes every artifact it signed, including investigation records. Acceptance criteria - Revocation records key identity, effective scope, time, and reason - Verification distinguishes signed-before, signed-after, and explicitly revoked artifacts - Historical metadata remains inspectable and immutable Implementation constraints - Use ephemeral fixture keys; do not claim real-world trust without a provisioned signer and policy. Verification - Verify artifacts on both sides of a declared rotation under policy. - Present an artifact signed after compromise and confirm promotion denial without deletion. Deliverables - Signing revocation policy and temporal tests Rollout and recovery: Block new promotion first, then review already promoted fixture artifacts. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-108 — Retain rollback artifacts while bounding storage growth **Chore · High priority · Advanced** noCV practice brief v5 · DART-108 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DART-105, DART-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Storage 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. Age-only cleanup removes the last compatible rollback artifact for a supported release line. Acceptance criteria - Retention protects active, rollback, held, and investigation-referenced digests - Deletion plan is deterministic and reviewable before mutation - Partial deletion resumes by immutable digest Implementation constraints - Use local object storage and synthetic artifact bytes; never delete undeclared objects. Verification - Plan and execute cleanup while retaining every protected digest. - Interrupt halfway and replay; add an unknown reference and keep it unresolved. Deliverables - Artifact retention planner and interrupted cleanup drill Rollout and recovery: Run plan-only mode before enabling scoped fixture deletion. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-109 — Recover publication after object storage acknowledges late **Task · High priority · Expert** noCV practice brief v5 · DART-109 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DART-103, DART-105, DART-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Storage 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. The object store commits an archive but the upload times out; retry creates a differently named duplicate and publishes only one metadata set. Acceptance criteria - Object key derives from verified content digest - Retry reconciles size, digest, and metadata before upload - Conflicting existing content is quarantined and never overwritten Implementation constraints - Treat storage metadata as untrusted until content identity is verified. Verification - Upload and replay an identical artifact idempotently. - Lose the response after commit and preplace conflicting bytes under the expected key. Deliverables - Content-addressed publisher and ambiguous-upload tests Rollout and recovery: Enable for one artifact class while retaining the prior publisher for rollback. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-110 — Rehearse artifact compromise from block to recovery **Bug · Medium priority · Intermediate** noCV practice brief v5 · DART-110 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DART-107, DART-108, DART-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. The response plan says rotate and rebuild but does not identify affected channels, compatible rollback artifacts, or how clients learn the block. Acceptance criteria - Runbook traces key, artifact, channel, environment, and consumer relationships - Rehearsal blocks promotion and selects a verified compatible artifact - Recovery publishes a new identity without rewriting compromised history Implementation constraints - The scenario uses fictional artifacts and ephemeral keys only. Verification - Complete a synthetic compromise and restore a safe channel. - Remove the expected rollback artifact and follow the documented blocked path. Deliverables - Artifact incident runbook and tabletop transcript Rollout and recovery: Review findings before treating the workflow as ready for an external registry. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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.