# 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. ## REPLAY — A webhook replay lab for incident recovery An integration team closes incidents with screenshots of provider dashboards, then struggles to reproduce the same delivery sequence. Build a synthetic event corpus and replay runner against an allowlisted local receiver. **Field:** Quality engineering. **Suggested stack:** TypeScript, HTTP, HMAC, SQLite. **Engineer value:** Practice protocol verification, controlled fault injection, and reproducible incident investigation. **Company value:** Review concrete evidence that webhook consumers tolerate real delivery failure patterns. **Delivery agreement:** A synthetic event corpus, safe local replay runner, and repeatable incident scenarios. ### Setup prerequisites - Create a local receiver fixture with an inspectable event store. - Use generated test signing keys and synthetic payloads only. ### Build inspectable event fixtures Represent exact request bytes and expected receiver effects. #### REPLAY-101 — Define a portable synthetic webhook fixture **Task · Medium priority · Foundational** noCV practice brief v5 · REPLAY-101 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build inspectable event fixtures. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Integrations 20% · 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. A copied JSON payload loses its original whitespace and cannot reproduce a signature mismatch. Store exact request bytes with safe headers and an expected event identity. Acceptance criteria - The fixture preserves body bytes, content type, event ID, and schema version. - Loading rejects unknown fields that could supply credentials or arbitrary destination URLs. - The fixture includes a content digest and validates it before replay. Implementation constraints - Generate synthetic examples; do not import production customer payloads. Verification - Round-trip a body with whitespace and non-ASCII text byte-for-byte. - Change one payload byte and verify digest validation fails before a request is sent. Deliverables - Fixture schema and three synthetic event examples Rollout and recovery: Version the fixture format; retain older samples read-only until a validated converter exists. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-102 — Generate signatures from raw bytes and an injected clock **Task · High priority · Intermediate** noCV practice brief v5 · REPLAY-102 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build inspectable event fixtures. Depends on: REPLAY-101. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Security 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. The receiver accepts fresh signatures but rejects replay fixtures because timestamp generation depends on the wall clock. Add a deterministic signer for the lab contract. Acceptance criteria - Signing covers the timestamp and exact raw body according to the documented lab protocol. - The clock and generated test key are supplied explicitly. - Signature values and secret keys are not printed in ordinary run logs. Implementation constraints - Use an established HMAC implementation and document byte encoding. Verification - Check a fixed key/time/body vector against an independently calculated digest. - Change only whitespace or timestamp and confirm the signature changes. Deliverables - Test signer and fixed signature vectors Rollout and recovery: Restrict signing to the local lab adapter; rotate fixture keys by changing the versioned test configuration. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. ### Reproduce delivery failures Control signing, ordering, duplicates, and lost responses. #### REPLAY-103 — Assert duplicate delivery produces one business effect **Story · High priority · Intermediate** noCV practice brief v5 · REPLAY-103 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Integrations 30% · 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. A subscription-created event is delivered three times with separate request IDs. The replay should test event-level deduplication rather than merely identical HTTP responses. Acceptance criteria - A scenario sends one event identity with three distinct delivery identities. - The receiver records delivery attempts but creates one subscription effect. - Changing the event ID while preserving business data follows an explicitly documented business-key policy. Implementation constraints - Observe effects through the local receiver inspection API. Verification - Replay three duplicates and assert delivery and effect counts separately. - Disable receiver deduplication in a fixture variant and confirm the scenario detects extra effects. Deliverables - Duplicate-delivery scenario and effect assertions Rollout and recovery: Add as the first consumer acceptance scenario; use the same fixture revision when comparing receiver changes. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-104 — Deliver update-before-create with a reproducible schedule **Story · High priority · Advanced** noCV practice brief v5 · REPLAY-104 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Real-time systems 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 subscription update arrived before its create event during an outage. Add a schedule format that can hold, reorder, and release specific events without relying on elapsed sleeps. Acceptance criteria - The scenario declares event order and release barriers separately from payload data. - The receiver converges to the latest declared resource revision when all events arrive. - Stale events cannot overwrite a newer stored revision. Implementation constraints - Define revision ordering in the lab contract instead of inferring it from arrival time. Verification - Run create-update and update-create schedules and compare final state. - Append a stale update after convergence and verify the state remains at the newest revision. Deliverables - Barrier-based schedule runner and out-of-order scenarios Rollout and recovery: Keep scheduling deterministic by default; random ordering is optional and must record a replayable seed. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-105 — Exercise signature rotation without accepting expired requests **Story · High priority · Advanced** noCV practice brief v5 · REPLAY-105 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-102. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. During key rotation the receiver must accept old and new keys briefly, while still rejecting requests outside the timestamp tolerance. Add a table of rotation boundaries. Acceptance criteria - Cases cover current key, overlap key, unknown key, and retired key. - Freshness boundaries are tested immediately inside and outside the documented tolerance. - Invalid signatures and stale timestamps produce no persisted business effect. Implementation constraints - Use an injected clock and generated lab keys. - Verify signature checks occur before trusted event fields are consumed. Verification - Accept both keys inside the overlap window and reject the retired key afterward. - Send a validly signed but stale event and a fresh tampered event; both must have zero effects. Deliverables - Rotation boundary matrix and receiver assertions Rollout and recovery: Run rotation cases before changing receiver key policy; keep retired test keys only in synthetic fixtures. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-106 — Reproduce a receiver commit followed by a dropped response **Story · High priority · Expert** noCV practice brief v5 · REPLAY-106 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-103, REPLAY-104. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Distributed systems 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. The receiver committed the event, then the connection closed before the sender received 200. Model this boundary and verify sender retries and receiver effects independently. Acceptance criteria - A controlled fault drops the response only after the receiver commits its effect. - The sender retries the original event identity under a bounded policy. - Final reporting distinguishes transport uncertainty from receiver business success and proves one effect. Implementation constraints - Implement the fault in a local transport or receiver double. - Do not treat a missing response as proof the receiver did nothing. Verification - Drop after commit and observe a retry with exactly one effect. - Drop before commit and verify a later retry creates the missing effect once. Deliverables - Before/after-commit fault scenarios and uncertainty report Rollout and recovery: Keep fault controls unavailable outside the local lab; preserve failed-run reports when rerunning the scenario. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. ### Make incidents repeatable Bound replay authority and preserve useful run reports. #### REPLAY-107 — Block replay targets outside the approved local receiver **Bug · High priority · Advanced** noCV practice brief v5 · REPLAY-107 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-101. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Quality engineering 20% · Networking 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 fixture author added a destination that points at a metadata endpoint. Move destination control out of fixture data and enforce a fixed local target policy. Acceptance criteria - Only configured loopback receiver hosts and ports can be selected. - Redirects are rejected and userinfo, ambiguous IP syntax, and non-HTTP schemes are denied. - The resolved address is validated at connection time; rejected destinations send zero payload bytes, and redirect responses trigger no follow-up request. Implementation constraints - Keep replay configuration separate from imported fixture content. - Bound request body size and connection timeout. Verification - Replay to the configured local receiver successfully. - Reject an external host, unapproved port, and alternate IP notation before any receiver request; for a redirect, allow one request to the approved receiver and assert zero requests to its redirect target. Deliverables - Destination policy and SSRF regression cases Rollout and recovery: Make the target policy mandatory before exposing fixture import; disable replay on target-validation uncertainty. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-108 — Summarize deliveries and effects in separate report sections **Task · Medium priority · Foundational** noCV practice brief v5 · REPLAY-108 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-103. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · Developer tooling 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 current report says three successes even though three deliveries produced one intended change. Report transport attempts and business effects as separate facts. Acceptance criteria - The report lists delivery ID, event ID, response category, and receiver effect reference separately. - A timeout remains unknown at the transport level even if later reconciliation finds an effect. - Output is stably ordered and includes scenario and fixture revisions. Implementation constraints - Use synthetic receiver record IDs; these are not noCV Evidence IDs. Verification - Report a three-delivery duplicate scenario with three attempts and one effect. - Report a timeout followed by reconciliation without rewriting the timeout as an HTTP success. Deliverables - JSON report contract and readable summary renderer Rollout and recovery: Version the new report format; preserve original attempt records when generating summaries. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-109 — Honor Retry-After without creating an unbounded replay **Story · Medium priority · Intermediate** noCV practice brief v5 · REPLAY-109 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-106, REPLAY-107. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Integrations 30% · Networking 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 local receiver responds 429 with Retry-After, but the runner retries immediately. Add bounded backoff with a fake clock and explicit terminal reasons. Acceptance criteria - Supported Retry-After forms are parsed and capped by the run time budget. - Malformed or negative values fall back to documented bounded backoff. - Maximum attempts and overall deadline stop retries with a terminal reason in the report. Implementation constraints - Seed jitter or disable it for deterministic fixtures. Verification - Advance a fake clock through 429, 503, and success and assert scheduled retry times. - Return an excessive delay and confirm the deadline ends the run without waiting in real time. Deliverables - Retry policy and fake-clock timing cases Rollout and recovery: Apply bounded retry policy to all replay scenarios; allow zero retries for transport debugging. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-110 — Export an incident recipe another engineer can rerun **Task · Medium priority · Intermediate** noCV practice brief v5 · REPLAY-110 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-105, REPLAY-108, REPLAY-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Developer tooling 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 engineer reproduced the incident but left only terminal history. Export the scenario, fixture digests, scheduler seed, and safe configuration as a portable recipe. Acceptance criteria - The recipe resolves every fixture by immutable content digest and records the runner version. - It excludes signing keys, credentials, destination overrides, and captured production payloads. - A fresh local receiver can reproduce the expected effect and failure categories from the recipe. Implementation constraints - Require generated replacement keys on import. - Keep original run reports separate from rerun reports. Verification - Export and rerun an out-of-order lost-response recipe in a clean temporary directory. - Remove one referenced fixture and confirm import fails before sending requests. Deliverables - Incident-recipe export/import and a worked recovery exercise Rollout and recovery: Use recipes for internal synthetic exercises first; reject unsupported runner or fixture versions with migration guidance. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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.