# 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. ## RCONSENT — Keep communication preferences consistent across dispatch channels A fictional event workspace offers optional product announcements and operational booking messages. Its product policy treats these as separate purposes. A stale audience cache currently sends optional messages after a member opts out. The brief implements fictional preference rules and makes no legal-consent certification. **Field:** Privacy engineering. **Suggested stack:** TypeScript, PostgreSQL, Queue adapter, Email provider double. **Engineer value:** Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. **Company value:** Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. **Delivery agreement:** Ten tickets using provider doubles and synthetic choices. No live mailing lists, legal advice or real outreach are part of the project. ### Setup prerequisites - Create synthetic members, versioned notice text and two purpose-tagged message types. - Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. ### Model explicit choices Make purpose, notice version and user intent distinguishable. #### RCONSENT-101 — Separate optional announcements from booking operations **Task · Medium priority · Foundational** noCV practice brief v5 · RCONSENT-101 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model explicit choices. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 80% · Backend 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. A single email-enabled flag suppresses booking confirmations when a member opts out of product announcements. Acceptance criteria - Define separate purpose identifiers and allowed message categories. - Specify defaults and unknown-purpose behavior under the fictional product policy. - Keep preference evaluation explicit for each dispatch request. Implementation constraints - Do not infer a legal basis from a message label; the exercise uses a declared product rule. Verification - Evaluate announcement and booking fixtures with optional announcements disabled. - Reject an unknown purpose instead of silently treating it as operational. Deliverables - Purpose registry and preference truth table Rollout and recovery: Introduce purpose tags before migrating existing preference checks. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-102 — Record the notice version shown when a preference changes **Story · Medium priority · Intermediate** noCV practice brief v5 · RCONSENT-102 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model explicit choices. Depends on: RCONSENT-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Data engineering 30% · Security 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 database stores only the latest boolean, so support cannot tell which choice text the member saw. Acceptance criteria - Append subject, purpose, choice, UTC instant and notice version for each accepted change. - Preserve the prior event and derive current state deterministically. - Reject unknown notice versions and keep notice content immutable once referenced. - Derive the subject from authenticated authority and enforce subject/tenant authorization for preference mutations at the repository boundary. Implementation constraints - Use bounded metadata; do not collect device fingerprints or unrelated browsing history to record a choice. Verification - Change a preference twice under two published notice versions and inspect the retained events. - Submit an unknown version and verify no state change or append. - Attempt a foreign subject and a foreign tenant through the mutation boundary; verify denial with no preference state change or appended event. Deliverables - Versioned preference events and immutable notice fixtures Rollout and recovery: Publish notice versions before accepting their changes; corrections create new versions. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-103 — Make the preference form submit the user’s explicit final choice **Bug · High priority · Intermediate** noCV practice brief v5 · RCONSENT-103 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model explicit choices. Depends on: RCONSENT-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 40% · Privacy engineering 30% · Accessibility 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. An autosave race restores a checked box after the user turns it off and navigates away. Acceptance criteria - Represent pending, saved and failed states without presenting an unconfirmed value as saved. - Use version-aware updates so an older response cannot overwrite a newer choice. - Keep controls keyboard-operable and associate errors with the affected purpose. Implementation constraints - Do not use preselected optional choices or obscured controls as a substitute for the declared interaction contract. Verification - Complete two opposite updates out of order and verify the latest accepted choice appears. - Fail a save and navigate back; the form must distinguish persisted state from the unsaved attempt. Deliverables - Preference form state and out-of-order response tests Rollout and recovery: Deploy with the versioned API; reverting the UI must not rewrite stored preference events. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. ### Enforce choices at delivery Handle stale audiences and queued work with current policy checks. #### RCONSENT-104 — Recheck optional-message eligibility immediately before provider dispatch **Bug · High priority · Advanced** noCV practice brief v5 · RCONSENT-104 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce choices at delivery. Depends on: RCONSENT-101, RCONSENT-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Security 30% · Platform 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. An audience list was built yesterday. A member who opted out this morning still receives the queued announcement. Acceptance criteria - Evaluate current purpose-specific preference at the dispatch boundary. - Suppress ineligible work with a recorded safe reason and no provider call. - Define behavior when preference state is unavailable; optional delivery must not assume permission from a stale list. Implementation constraints - The audience snapshot is planning input, not final dispatch authority. Verification - Queue while enabled, opt out, then release the job and verify no provider request. - Make the preference repository unavailable and verify the declared hold/suppression path without sending. Deliverables - Dispatch guard and stale-audience regressions Rollout and recovery: Deploy the guard before replaying old queue entries; monitor bounded suppression categories. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-105 — Bind a queued announcement to its purpose and content revision **Story · Medium priority · Advanced** noCV practice brief v5 · RCONSENT-105 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce choices at delivery. Depends on: RCONSENT-101, RCONSENT-104. Difficulty: Advanced. Estimated focused work: 180 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. An operator edits a queued campaign from a booking reminder into promotional content while retaining the original operational tag. Acceptance criteria - Freeze purpose and content revision for each queued delivery request. - Require a new reviewed request when a material content/purpose change occurs. - Reject dispatch when the referenced purpose or content revision cannot be resolved. Implementation constraints - Use synthetic content and a local review state; this ticket sends nothing outside the provider double. Verification - Edit the source campaign after queueing and verify the queued revision remains identifiable. - Attempt to retag optional content as operational through a mutable field and verify the request is rejected. Deliverables - Immutable dispatch request contract and revision tests Rollout and recovery: Version the queue payload and hold unresolved legacy jobs for explicit conversion. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-106 — Stop an opt-out retry from being lost behind an older opt-in event **Bug · High priority · Expert** noCV practice brief v5 · RCONSENT-106 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce choices at delivery. Depends on: RCONSENT-102, RCONSENT-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Preference events reach a delivery replica out of order. A delayed older opt-in restores eligibility after a newer opt-out. Acceptance criteria - Apply a subject/purpose ordering rule with comparable revisions. - Ignore older duplicates while preserving their receipt for bounded diagnosis. - Expose replica freshness and define dispatch behavior when current ordering cannot be established. Implementation constraints - Wall-clock arrival order is not a reliable source revision; document the authority issuing revisions. Verification - Deliver opt-out, then older opt-in, then duplicate opt-out and verify current state remains disabled. - Create a missing-revision gap and verify optional dispatch follows the declared fail-closed or authoritative-read path. Deliverables - Replica ordering protocol and event permutation tests Rollout and recovery: Canary replica reads with authoritative comparisons; disable replica-based optional dispatch if gaps cannot be resolved. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. ### Review history and consistency Reconcile replicas and explain what was actually enforced. #### RCONSENT-107 — Explain which queued messages an opt-out can still prevent **Task · Medium priority · Advanced** noCV practice brief v5 · RCONSENT-107 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-103, RCONSENT-104, RCONSENT-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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 settings page promises instant cancellation even when the provider has already accepted a message that cannot be recalled. Acceptance criteria - Define queued, dispatching, provider-accepted and completed boundaries. - Describe prevention guarantees in user-facing copy consistent with those states. - Cancel controllable work and report when a provider-accepted message is beyond the supported recall boundary. Implementation constraints - Do not claim that recording a preference change reverses an already completed delivery. Verification - Opt out at each controlled boundary and compare provider calls with displayed status. - Simulate a provider without recall support and verify the interface does not show a false cancellation success. Deliverables - Cancellation state contract and truthful settings copy Rollout and recovery: Publish the clarified contract with the dispatch guard; preserve accepted-delivery history under the declared retention policy. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-108 — Expose preference history only to its subject and scoped support role **Story · Medium priority · Intermediate** noCV practice brief v5 · RCONSENT-108 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-102, RCONSENT-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Privacy 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. A support page returns all members’ preference histories after checking only that the requester has any staff role. Acceptance criteria - Apply subject or tenant-scoped support authorization at the repository boundary. - Return purpose, choice, notice version and time without unrelated contact details. - Audit privileged history access using safe identifiers and bounded reason categories. Implementation constraints - An audit event records access, not an inference about why a person made their choice. Verification - Read the matching subject’s history and an authorized support fixture. - Attempt a foreign-tenant subject and an unscoped staff role; verify denial and no history leakage. Deliverables - Scoped history endpoint and access regressions Rollout and recovery: Enable the history view after repository-level checks pass; keep analytics separate from preference content. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-109 — Reconcile audience caches without restoring old optional choices **Chore · Medium priority · Advanced** noCV practice brief v5 · RCONSENT-109 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-104, RCONSENT-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Privacy engineering 40% · Data 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. A nightly audience rebuild copies an old export over the current preference cache. Acceptance criteria - Bind rebuild inputs to a declared cutoff and subject/purpose revisions. - Prevent rebuild writes from replacing newer authoritative or replicated choices. - Report missing and contradictory inputs as reconciliation exceptions. Implementation constraints - Treat audience caches as derived state; preserve current choice authority outside the rebuild. Verification - Run a rebuild while a member opts out and verify the newer revision wins. - Feed contradictory same-revision values and verify the rebuild stops or quarantines them without guessing. Deliverables - Audience reconciliation and concurrent-choice tests Rollout and recovery: Build into a new cache generation and switch only after consistency checks; retain the prior generation for diagnosis. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-110 — Rehearse preference enforcement from settings through provider acknowledgement **Task · Medium priority · Expert** noCV practice brief v5 · RCONSENT-110 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-103, RCONSENT-105, RCONSENT-106, RCONSENT-107, RCONSENT-108, RCONSENT-109. Difficulty: Expert. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 40% · Privacy engineering 40% · Integrations 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. Unit tests cover the checkbox and worker separately, but not a user changing a preference while replicas lag and provider requests are in flight. Acceptance criteria - Run a deterministic end-to-end matrix of opt-in/out, replica delay, queued work and provider acknowledgement. - Reconcile every provider request with the exact purpose, content and evaluated preference revisions. - Report tested conditions and unavoidable in-flight limits without claiming legal consent compliance. Implementation constraints - All deliveries terminate at a fake provider; the exercise never sends messages to real recipients. Verification - Exercise out-of-order events and opt-out at each dispatch boundary. - Fail preference lookup and provider acknowledgement separately, then verify retries cannot send an ineligible optional message. Deliverables - Preference-enforcement rehearsal and decision trace Rollout and recovery: Enable the full synthetic workflow only after the matrix passes; hold optional dispatch when authority or revision consistency is unresolved. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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.