noCV
DART-106 · Control change and failure

Prevent a mutable channel from changing an approved artifact

Practice briefBugAdvanced

The beta channel is approved while pointing to one digest, then its mutable object is overwritten before clients resolve it.

Focused work estimate
4h + prerequisites
Priority in the scenario
High
Engineering practice
Optimistic concurrency · Artifact channels

Estimated field mix

  • DevOps70%
  • Distributed systems30%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

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.

Setup prerequisites

  • Content hashing
  • Archive formats
  • Release metadata

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

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 to include

  • 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.

Value of the work

For the engineer: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety.

For the team: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.