# 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. ## ACDC — Move customer preferences through a durable change feed A fictional messaging service builds a read model from database changes. Restarts and schema changes can re-enable preferences that customers disabled. **Field:** Data engineering. **Suggested stack:** PostgreSQL, TypeScript, Object storage. **Engineer value:** Practice change-feed ordering, snapshots and privacy-preserving deletion. **Company value:** Review whether replicated customer preferences remain correct during recovery. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic preference records and a replayable local change log. - Use adapters or fixtures without provisioning a production broker. ### Specify the change contract Identify ordering, identities and deletions. #### ACDC-101 — Define the preference change envelope with source position **Task · Medium priority · Foundational** noCV practice brief v5 · ACDC-101 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the change contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · API design 20% · Distributed systems 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 consumer sees a timestamp and payload but cannot distinguish two changes committed in the same millisecond. Acceptance criteria - Include stable source position, record identity and operation. - Separate source commit time from consumer receipt time. - Validate the envelope version before applying changes. Implementation constraints - Use fabricated positions from a deterministic local log. Verification - Parse two same-time changes with distinct positions. - Reject an unknown envelope version without moving the checkpoint. Deliverables - Change envelope schema Rollout and recovery: Publish the contract before consumer rollout; quarantine unsupported versions. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-102 — Redact preference change diagnostics without losing traceability **Bug · High priority · Foundational** noCV practice brief v5 · ACDC-102 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the change contract. Depends on: ACDC-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Data 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. Malformed preference payloads are dumped into generic logs with email addresses and free-text notes. Acceptance criteria - Log source position, safe record token and reason code. - Exclude contact details and raw payload bodies. - Retain restricted diagnostic access only through a scoped fixture store. Implementation constraints - Use synthetic contact data in disclosure tests. Verification - Locate a rejected envelope through its safe identifiers. - Inject contact fields and assert they never appear in generic logs. Deliverables - Sanitized diagnostics and disclosure checks Rollout and recovery: Deploy redaction before replay; restrict access to older diagnostic output. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-103 — Represent preference deletion as a durable tombstone **Story · Medium priority · Intermediate** noCV practice brief v5 · ACDC-103 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the change contract. Depends on: ACDC-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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 deleted record disappears from the source snapshot but remains enabled in a downstream projection indefinitely. Acceptance criteria - Define tombstones with identity and source position. - Retain enough ordering metadata to reject stale recreation. - Separate deletion from a false preference value. Implementation constraints - Document retention assumptions for replayable tombstones. Verification - Apply deletion and verify the projected record is absent. - Replay an older enable event and keep the record deleted. Deliverables - Tombstone contract and ordering cases Rollout and recovery: Enable tombstone production before cleanup; stop purging if replay coverage is uncertain. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. ### Build the projection Handle duplicates, schema changes and snapshot handoff. #### ACDC-104 — Advance the feed checkpoint only with the projected transaction **Bug · High priority · Advanced** noCV practice brief v5 · ACDC-104 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-101, ACDC-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Data engineering 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 consumer acknowledges a change before updating the read model; a crash permanently loses the disabled preference. Acceptance criteria - Apply projection and checkpoint in one durable transaction. - Duplicate delivery is a no-op at the same position. - Failed application leaves the previous checkpoint intact. Implementation constraints - Scope checkpoints to source partition and consumer generation. Verification - Replay a committed change and keep one result. - Fail between modeled projection and checkpoint writes and retry successfully. Deliverables - Transactional consumer and interruption test Rollout and recovery: Canary one synthetic partition; stop consumption on checkpoint divergence. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-105 — Reject a stale preference update after a partition retry **Task · Medium priority · Advanced** noCV practice brief v5 · ACDC-105 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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. A retry queue delivers an old enable event after a newer disable event has already committed. Acceptance criteria - Compare per-record source ordering before mutation. - Retain stale-delivery counters without changing state. - Treat equal position with different content as a conflict. Implementation constraints - Do not use consumer wall time to resolve ordering. Verification - Deliver disable before an older enable and retain disabled. - Send contradictory equal-position data and quarantine the conflict. Deliverables - Per-record ordering guard Rollout and recovery: Observe stale counts during canary; pause conflicting partitions instead of guessing order. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-106 — Handoff a preference snapshot to live changes without a gap **Story · Medium priority · Expert** noCV practice brief v5 · ACDC-106 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-104, ACDC-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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. A new replica loads a snapshot while preferences continue changing, leaving a gap between export time and stream start. Acceptance criteria - Record an explicit snapshot boundary position. - Buffer or replay changes after the boundary before activation. - Keep the new generation unavailable until catch-up is complete. Implementation constraints - Document source guarantees needed for a consistent boundary. Verification - Change a preference during snapshot loading and reach final source state. - Interrupt catch-up and verify readers still use the previous generation. Deliverables - Snapshot handoff protocol and executable timeline Rollout and recovery: Build a shadow generation; restore the previous pointer if catch-up checks fail. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-107 — Evolve a preference value enum without silently coercing unknown values **Task · Medium priority · Intermediate** noCV practice brief v5 · ACDC-107 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-101, ACDC-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · API design 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 new source value called paused is mapped to enabled by the old consumer's default branch. Acceptance criteria - Use an explicit compatibility map for each envelope version. - Unknown values enter quarantine without checkpoint loss. - Document how a compatible consumer resumes blocked input. Implementation constraints - Avoid treating missing values as an affirmative preference. Verification - Apply known values under both supported versions. - Deliver paused to an incompatible consumer and verify no enable write. Deliverables - Version compatibility matrix and consumer guard Rollout and recovery: Deploy compatible readers before writers; retain queued unsupported changes for replay. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. ### Repair feed gaps Detect divergence and recover scoped replicas. #### ACDC-108 — Compare source and replica preferences without exporting contacts **Chore · Medium priority · Intermediate** noCV practice brief v5 · ACDC-108 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair feed gaps. Depends on: ACDC-106, ACDC-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Privacy 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. Operators suspect a gap but a full data export would spread contact information across incident tooling. Acceptance criteria - Compare keyed hashes and safe row counts by bounded scope. - Report missing, extra and mismatched record tokens. - Keep raw preference payloads out of the report. Implementation constraints - Use stable canonical hashing and documented null handling. Verification - Compare equal synthetic source and replica states. - Alter one value and delete one row; identify both discrepancy categories. Deliverables - Scoped reconciliation report Rollout and recovery: Run read-only reconciliation first; expire generated diagnostic artifacts after review. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-109 — Repair one preference partition while continuing unrelated reads **Task · Medium priority · Expert** noCV practice brief v5 · ACDC-109 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair feed gaps. Depends on: ACDC-106, ACDC-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Distributed systems 30% · Database 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. One replica partition is corrupted; rebuilding the entire preference service would unnecessarily interrupt all accounts. Acceptance criteria - Rebuild only the selected source scope into a new generation. - Catch up from the recorded boundary before pointer swap. - Prevent repaired and old generations from mixing in one scoped read. Implementation constraints - Require a dry-run plan and explicit partition identity. Verification - Repair a synthetic partition and preserve unrelated output hashes. - Interrupt before swap and retain complete reads from the old generation. Deliverables - Partition repair command and atomic-read probe Rollout and recovery: Canary repair on a synthetic scope; switch its pointer back if reconciliation fails. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-110 — Expose replica freshness with a trustworthy unknown state **Story · Medium priority · Foundational** noCV practice brief v5 · ACDC-110 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair feed gaps. Depends on: ACDC-108, ACDC-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. The dashboard marks a replica healthy when its consumer is running even though no source checkpoint has been observed. Acceptance criteria - Show applied source position and receipt lag separately. - Report unknown when no comparable source watermark exists. - Define stale thresholds in the local operating contract. Implementation constraints - Never infer source completeness from process liveness. Verification - Advance source and replica positions and calculate the documented lag. - Remove the source watermark and return unknown health. Deliverables - Freshness endpoint and unknown-state cases Rollout and recovery: Add freshness as advisory status first; restore the prior view while preserving unknown semantics. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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.