# 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. ## ANOTIFY — Design notification delivery around preferences and receipts A fictional collaboration tool sends email and in-app notifications. Duplicate alerts and preference changes reveal that the design has no single definition of delivery. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, Provider interfaces. **Engineer value:** Practice asynchronous contracts, preference timing and delivery uncertainty. **Company value:** Review a notification design that controls nuisance, disclosure and 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 recipients, events and fake delivery providers. - Do not send real email or messages. ### Define communication intent Identify recipients, semantics and privacy boundaries. #### ANOTIFY-101 — Separate notification intent from channel delivery and human receipt **Task · Medium priority · Foundational** noCV practice brief v5 · ANOTIFY-101 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define communication intent. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Backend 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. Product labels a notification delivered when an email provider accepts it, though no human receipt is observed. Acceptance criteria - Define intent, attempted, provider-accepted and observed-read states. - Keep channel-specific facts separate. - Avoid claiming reading from provider acceptance. Implementation constraints - Use synthetic provider receipts and explicit unknown states. Verification - Map an accepted email and an opened in-app item separately. - Timeout the provider and retain unknown delivery rather than sent. Deliverables - Notification semantics table Rollout and recovery: Adopt precise status labels in the prototype; preserve uncertain older observations. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. #### ANOTIFY-102 — Specify recipient resolution without copying event payloads broadly **Task · Medium priority · Intermediate** noCV practice brief v5 · ANOTIFY-102 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define communication intent. Depends on: ANOTIFY-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · System design 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 event producer includes every collaborator's contact details so downstream handlers can decide recipients. Acceptance criteria - Resolve recipients through a scoped authority boundary. - Keep generic event payloads to opaque identifiers. - Authorize recipient access before creating a channel attempt. Implementation constraints - Use synthetic addresses and a dedicated contact provider fake. Verification - Resolve members of the correct synthetic workspace. - Request recipients across workspaces and produce no channel attempts. Deliverables - Recipient-resolution contract Rollout and recovery: Review the contract before broad event publication; quarantine events without valid scope. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. #### ANOTIFY-103 — Choose when notification preferences are evaluated **Task · Medium priority · Foundational** noCV practice brief v5 · ANOTIFY-103 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define communication intent. Depends on: ANOTIFY-101, ANOTIFY-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Privacy engineering 30% · 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 user opts out after an event is queued but still receives the email, and the team has no documented policy. Acceptance criteria - Compare preference-at-intent and preference-at-send semantics. - Choose and document behavior for opt-out and critical notices. - Define how a changed preference version affects queued work. Implementation constraints - Do not silently invent a legal or mandatory-notice requirement. Verification - Trace an opt-out between event and send. - Trace a missing preference record under the declared default policy. Deliverables - Preference-timing architecture decision Rollout and recovery: Review with product before adapter work; keep unresolved categories unsent. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. ### Specify delivery contracts Handle preference changes, retries and provider uncertainty. #### ANOTIFY-104 — Model notification intent and dispatch in one durable transaction **Story · Medium priority · Advanced** noCV practice brief v5 · ANOTIFY-104 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-102, ANOTIFY-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · 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. A collaboration action commits but crashes before queue publication, so some recipients never receive an alert. Acceptance criteria - Persist domain reference and notification intent atomically. - Use an outbox fact with deterministic intent identity. - Make repeated event delivery resolve the same logical intent. Implementation constraints - Keep intent creation inside the existing modular application boundary. Verification - Crash after action commit and replay the outbox to one intent. - Repeat the originating event and verify no duplicate recipient intent. Deliverables - Intent/outbox model and interruption probe Rollout and recovery: Use a local provider fake initially; pause originating notifications if intent persistence fails. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. #### ANOTIFY-105 — Design per-channel attempt identity and provider reconciliation **Task · Medium priority · Expert** noCV practice brief v5 · ANOTIFY-105 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-101, ANOTIFY-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System design 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 email provider times out after accepting a request; retrying blindly sends the same message twice. Acceptance criteria - Bind each logical channel delivery to a stable provider key. - Represent unknown acceptance and define a status lookup path. - Document provider limitations that prevent exactly-once claims. Implementation constraints - The local fake must support accepted-but-response-lost behavior. Verification - Reconcile lost response to one accepted synthetic delivery. - Use a provider without lookup support and retain an explicit uncertain state. Deliverables - Channel contract and uncertainty probe Rollout and recovery: Select adapters only after contract review; stop automatic retries where duplicate risk is unresolved. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. #### ANOTIFY-106 — Bound notification fan-out without creating one huge transaction **Task · Medium priority · Advanced** noCV practice brief v5 · ANOTIFY-106 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-102, ANOTIFY-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 30% · 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. One workspace event targets 50,000 hypothetical members and the proposed transaction attempts to create every delivery row at once. Acceptance criteria - Specify bounded recipient pages and stable page checkpoints. - Preserve one logical intent per recipient across retries. - Define membership snapshot versus live-membership semantics. Implementation constraints - Use a synthetic membership generator with documented cardinality. Verification - Process a 1,000-recipient local sample in fixed-size pages. - Interrupt a page and resume without duplicate recipient intents. Deliverables - Fan-out plan and checkpoint prototype Rollout and recovery: Validate with local samples before wider scale assumptions; pause dispatch while keeping checkpoints. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. #### ANOTIFY-107 — Keep in-app notification reads separate from email provider state **Story · Medium priority · Intermediate** noCV practice brief v5 · ANOTIFY-107 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-101, ANOTIFY-105, ANOTIFY-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 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. Marking an in-app alert read currently suppresses an unrelated email retry by changing one shared status column. Acceptance criteria - Model channel delivery and in-app acknowledgement separately. - Bind acknowledgement to the authenticated recipient. - Preserve delivery-attempt history after acknowledgement. Implementation constraints - Use an explicit read model for the in-app feed. Verification - Mark one in-app item read and retain email attempt state. - Acknowledge another recipient's item and reject it. Deliverables - Read-model contract and channel-isolation probe Rollout and recovery: Prototype the read model behind a local route; revert read wiring without changing delivery history. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. ### Validate operating behavior Model load and rehearse recovery without real messaging. #### ANOTIFY-108 — Calculate notification drain time under a channel rate limit **Task · Medium priority · Expert** noCV practice brief v5 · ANOTIFY-108 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate operating behavior. Depends on: ANOTIFY-105, ANOTIFY-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · System design 30% · 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. A launch generates a burst of alerts, but the architecture plan ignores provider quotas and retry traffic. Acceptance criteria - Model initial backlog, arrival rate and provider throughput. - Reserve capacity for retries within a bounded budget. - Show conditions where backlog cannot drain. Implementation constraints - Use explicitly hypothetical rates and an executable calculation. Verification - Calculate drain time for a named burst and fixed delivery rate. - Raise arrivals above capacity and report unbounded growth instead of a finite answer. Deliverables - Capacity calculator and quota assumptions Rollout and recovery: Use results to propose admission and batching limits; replace assumptions before real rollout. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. #### ANOTIFY-109 — Exercise preference revocation during a notification backlog **Task · Medium priority · Advanced** noCV practice brief v5 · ANOTIFY-109 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate operating behavior. Depends on: ANOTIFY-103, ANOTIFY-105, ANOTIFY-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Privacy engineering 30% · 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. A user disables a channel while thousands of queued intents wait for provider quota, exposing ambiguous preference timing. Acceptance criteria - Apply the chosen preference-timing policy consistently. - Record suppressed versus attempted outcomes without contact details. - Keep already accepted provider facts immutable. Implementation constraints - Use a local backlog and fake provider; send no real messages. Verification - Change preferences before a queued intent reaches its decision boundary. - Change preferences after provider acceptance and preserve the accepted fact without claiming recall. Deliverables - Backlog preference drill and outcome trace Rollout and recovery: Run before adapter approval; suspend the affected category if policy and implementation diverge. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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. #### ANOTIFY-110 — Document notification architecture limits for stakeholder review **Chore · Medium priority · Foundational** noCV practice brief v5 · ANOTIFY-110 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate operating behavior. Depends on: ANOTIFY-105, ANOTIFY-108, ANOTIFY-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 70% · Integrations 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 launch plan describes exactly-once delivery and confirmed readership even though the provider contract supports neither. Acceptance criteria - List supported guarantees and unresolved provider dependencies. - Link each guarantee to a contract or local probe. - Include retry suspension and backlog recovery decisions. Implementation constraints - State that local tests do not prove real provider delivery. Verification - Trace an accepted guarantee to its executable probe. - Identify an unsupported receipt claim and replace it with the observed state. Deliverables - Notification design review packet Rollout and recovery: Review the packet before provider rollout; revise claims when adapter evidence changes. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and 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.