# 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. ## BAPIHOOK — Public webhook delivery contract A fictional logistics platform sends shipment events to partner endpoints. Partners need stable schemas and recovery semantics despite duplicate delivery, failures, and subscription changes. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, HTTP, PostgreSQL. **Engineer value:** Practice public event contracts, delivery guarantees, and partner recovery workflows. **Company value:** Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. **Delivery agreement:** Deliver local subscription and delivery contracts; send no external webhook traffic. ### Setup prerequisites - Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. ### Define public events Specify immutable identities, schemas, and subscription authority. #### BAPIHOOK-101 — Define immutable webhook envelopes independently of database rows **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIHOOK-101 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define public events. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 80% · 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. Event payloads mirror internal shipment rows and change whenever the schema changes. Acceptance criteria - Publish event ID, type, version, and occurrence time. - Use a deliberate public payload projection. - Preserve emitted event bytes or canonical content identity. Implementation constraints - Exclude internal fields and hidden operational metadata. Verification - Create a documented shipment event. - Change an internal-only field without altering the public contract. Deliverables - Webhook envelope schema. Rollout and recovery: Version public payloads before accepting subscriptions. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-102 — Authorize subscription creation and event scope per organization **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-102 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define public events. Depends on: BAPIHOOK-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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 caller can subscribe its endpoint to another organization's shipment events. Acceptance criteria - Derive organization scope from authenticated authority. - Validate permitted event types. - Recheck subscription authority before delivery. Implementation constraints - Endpoint ownership does not grant access to event data. Verification - Create a scoped synthetic subscription. - Reject foreign-organization event scope and unauthorized event types. Deliverables - Subscription authorization boundary. Rollout and recovery: Enable subscriptions only after cross-tenant denial checks pass. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-103 — Validate webhook destinations through the restricted network boundary **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-103 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define public events. Depends on: BAPIHOOK-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Networking 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. An arbitrary callback URL could direct the sender toward unapproved network resources. Acceptance criteria - Enforce approved schemes, origins, and ports. - Validate resolution and redirects for every delivery. - Bind destinations to reviewed subscription revisions. Implementation constraints - Use local receiver doubles and an explicit lab allowlist. Verification - Deliver to an approved local receiver. - Reject an unapproved redirect or changed destination authority. Deliverables - Webhook destination policy. Rollout and recovery: Default to no external destinations until the policy is configured. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. ### Deliver predictably Handle signatures, retries, ordering, and endpoint boundaries. #### BAPIHOOK-104 — Sign exact webhook bytes with versioned verification metadata **Task · High priority · Intermediate** noCV practice brief v5 · BAPIHOOK-104 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-101, BAPIHOOK-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Partners cannot verify signatures after the sender serializes the same event differently on retry. Acceptance criteria - Sign the exact delivered bytes. - Include key identity and bounded timestamp semantics. - Document receiver verification before payload trust. Implementation constraints - Use generated test keys and never log signing material. Verification - Verify a valid local delivery. - Change one byte or timestamp and reject verification. Deliverables - Signing contract and receiver example. Rollout and recovery: Introduce a versioned signature format with a bounded rotation overlap. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-105 — Document at-least-once delivery with stable event identities **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-105 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · API 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 platform advertises one delivery even though connection loss can cause duplicates. Acceptance criteria - Keep event identity stable across attempts. - Record delivery attempts separately from event facts. - Provide a receiver deduplication example. Implementation constraints - Do not claim exactly-once delivery across HTTP. Verification - Lose a receiver acknowledgement and retry. - Verify the receiver applies the event once using its deduplication record. Deliverables - Delivery semantics and replay checks. Rollout and recovery: Preserve event identity through all retries and support actions. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-106 — Bound retry scheduling and distinguish terminal receiver responses **Task · High priority · Intermediate** noCV practice brief v5 · BAPIHOOK-106 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · API 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. The sender retries every response indefinitely, including malformed-endpoint failures. Acceptance criteria - Define retryable status classes and total delivery age. - Respect bounded retry-after guidance. - Move exhausted deliveries to an inspectable terminal state. Implementation constraints - Use an injected clock and fixed maximum attempts. Verification - Recover from a temporary receiver failure. - Exhaust a persistent failure without unbounded work. Deliverables - Retry contract. Rollout and recovery: Start with conservative limits; expose terminal state to authorized subscription owners. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-107 — Expose event ordering limits without requiring global sequencing **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-107 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-105, BAPIHOOK-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · API 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. Partners assume events arrive in the order they happened, but parallel delivery reorders them. Acceptance criteria - Declare the actual ordering scope. - Include resource revision where needed for stale-event handling. - Document how receivers handle gaps and older revisions. Implementation constraints - Avoid promising global ordering without implementing it. Verification - Deliver two resource revisions out of order. - Verify a receiver preserves its declared monotonic state. Deliverables - Ordering contract and receiver tests. Rollout and recovery: Publish ordering guidance before increasing delivery parallelism. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. ### Support evolution and replay Make recovery and schema migration explicit. #### BAPIHOOK-108 — Replay terminal deliveries without mutating original event content **Story · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-108 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support evolution and replay. Depends on: BAPIHOOK-106, BAPIHOOK-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 30% · Data 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. Support repairs a payload during replay and leaves the same event ID representing different facts. Acceptance criteria - Replay the original immutable event under a new attempt identity. - Require authorized subscription scope and reason. - Reject replay when current destination or data authority is revoked. Implementation constraints - Corrections require a new event identity and explicit relation. Verification - Replay a failed synthetic delivery. - Reject changed payload bytes and revoked subscription authority. Deliverables - Audited replay endpoint. Rollout and recovery: Keep replay bounded and visible to subscription owners. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-109 — Design webhook schema migration for independently deployed receivers **Task · High priority · Expert** noCV practice brief v5 · BAPIHOOK-109 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support evolution and replay. Depends on: BAPIHOOK-104, BAPIHOOK-107, BAPIHOOK-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. A required payload change cannot be safely deployed to all partner receivers at once. Acceptance criteria - Compare versioned subscriptions and additive-compatible evolution. - Define supported version overlap and retirement evidence. - Rehearse receiver upgrade, rollback, and replay of historical events. Implementation constraints - Historical events retain their original schema identity. Verification - Upgrade one synthetic receiver while another stays legacy. - Replay an old event after upgrade and verify documented handling. Deliverables - Webhook evolution decision record. Rollout and recovery: Keep supported schema serializers and examples through the retention window. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-110 — Publish a webhook receiver checklist with failure recovery **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIHOOK-110 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support evolution and replay. Depends on: BAPIHOOK-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 30% · Distributed systems 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. Partners acknowledge before persisting event identity and lose events after a crash. Acceptance criteria - Show signature verification before parsing trusted fields. - Persist deduplication and accepted work before acknowledgement. - Document retry, replay, and unknown-version behavior. Implementation constraints - Use the local receiver double and synthetic events. Verification - Recover after a receiver crash before acknowledgement. - Reject an unsupported event version without discarding its identity. Deliverables - Executable receiver guide. Rollout and recovery: Version the guide with event and signature contracts. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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.