# 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. ## PPROVIDER — Evolve a notification boundary with predictable failure behavior A fictional maintenance scheduler sends appointment notices through two providers. Their request shapes, error codes, and acknowledgement semantics differ. Build two local scripted provider doubles and a TypeScript application module; use synthetic recipients, block external network access, and never send real notifications. No provider accounts, starter repository, or production delivery qualification is supplied. **Field:** Integrations. **Suggested stack:** TypeScript, Node.js, Vitest, Local HTTP stubs. **Engineer value:** Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. **Company value:** Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. **Delivery agreement:** Ten tickets over three phases. Create local provider doubles and contract fixtures, evolve the integration layer, and supply a fault replay plus an operational handoff. ### Setup prerequisites - HTTP contracts - Asynchronous cancellation - Dependency injection ### Define the provider boundary Separate scheduling intentions from transport details. #### PPROVIDER-101 — Normalize the second provider's acknowledgement without inventing delivery **Story · High priority · Foundational** noCV practice brief v5 · PPROVIDER-101 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the provider boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. Pattern topics: Adapter (apply). Adapter — Apply: Translate incompatible acknowledgement payloads into a shared contract without overstating queued or accepted messages as delivered. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Provider A returns accepted plus a request ID; provider B returns queued with a nested reference. The existing mapper calls both delivered, even though neither acknowledgement confirms a recipient received the notice. Acceptance criteria - Define a shared result contract for accepted, rejected, and unknown outcomes with provider identity and an optional provider reference. - Map both declared acknowledgement shapes to accepted while preserving their references; never map acknowledgement alone to delivered. - Malformed success payloads and unknown response codes return a typed integration error without exposing raw recipient data. Implementation constraints - Use an Adapter for each local stub; preserve unsupported semantics explicitly rather than forcing every response into a success boolean. Verification - Map representative A and B acknowledgements and compare the shared contract. - Return a success status with a missing required reference and an undocumented state; assert explicit failure. Deliverables - Provider adapters, shared result contract, and mapping fixtures Rollout and recovery: Run both adapters against local scripted responses before selecting B for synthetic requests; retain A's mapping for regression comparison. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-102 — Keep provider SDK types out of appointment rules **Chore · Medium priority · Intermediate** noCV practice brief v5 · PPROVIDER-102 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the provider boundary. Depends on: PPROVIDER-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · System design 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. Pattern topics: Ports and Adapters (apply). Ports and Adapters — Apply: Move vendor request types and error codes behind a domain-owned notification port so scheduling rules can run without initializing transport code. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Rescheduling logic imports provider B's request object and recognizes its numeric error codes. A provider SDK change now forces changes in domain tests that never make a network request. Acceptance criteria - Appointment logic depends on a small notification port using domain-owned request and result types. - Place provider-specific mapping, serialization, and error interpretation in adapters selected at the composition boundary. - Run appointment decisions against an in-memory port double with no provider package imports or transport initialization. Implementation constraints - Keep this a module boundary in one process; the exercise does not justify splitting the application into services. Verification - Replace A with B through composition wiring and run the same appointment behavior cases. - Make the port return rejected and unknown outcomes and verify the domain does not treat either as successful acceptance. Deliverables - Domain notification port and provider-free appointment tests Rollout and recovery: Migrate one appointment use case to the port, compare results, then migrate the remaining local caller; revert adapter wiring if parity fails. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-103 — Validate notice inputs before choosing a provider **Bug · High priority · Foundational** noCV practice brief v5 · PPROVIDER-103 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the provider boundary. Depends on: PPROVIDER-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. Pattern topics: Chain of Responsibility (compare). Chain of Responsibility — Compare: Choose an ordered, short-circuiting validation structure that guarantees notice preferences are checked before any provider side effect. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. An invalid synthetic recipient passes provider selection and fails differently for A and B. Another path checks the notification preference only after the stub has already accepted the request. Acceptance criteria - Validate appointment identity, synthetic recipient format, and declared notice preference before any adapter call. - Define the order and short-circuit behavior of validation stages, returning stable reason codes. - Compare a Chain of Responsibility with an explicit sequence of validation functions; a skipped preference check must be structurally impossible. Implementation constraints - Use only synthetic .invalid addresses; do not contact any external address or interpret this exercise as a compliance certification. Verification - Accept valid synthetic input and assert each required check runs before one provider call. - Reject malformed recipient and disabled preference with a provider-call count of zero; verify the documented first error when both fail. Deliverables - Ordered preflight validation and no-send regression fixtures Rollout and recovery: Apply the shared validation path to both local providers together; leave explicit rejection visible to the scheduler. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. ### Compose cross-cutting behavior Keep orchestration and wrapper ordering visible and testable. #### PPROVIDER-104 — Decouple notice format from the selected transport **Story · Medium priority · Advanced** noCV practice brief v5 · PPROVIDER-104 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-102, PPROVIDER-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · System design 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. Pattern topics: Bridge (compare). Bridge — Compare: Separate independently varying notice content and provider transport so their combinations do not require a growing subclass matrix. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. ReminderEmailProviderA and CancellationEmailProviderA have matching ProviderB subclasses. Adding a third notice type is multiplying classes even though formatting and transport are independent choices. Acceptance criteria - Separate notice-content construction from provider transport, with two notice types runnable through both local providers. - Document required transport capabilities and reject incompatible content before sending; do not silently drop a cancellation reason. - Compare a Bridge between notice abstraction and transport with two composed functions, avoiding one subclass for every combination. Implementation constraints - Use plain text only in the exercise; user-provided content remains data and is never executed as a template or command. Verification - Exercise all four type/provider combinations and compare semantic content after adaptation. - Configure a transport without a required capability and assert rejection before any stub call. Deliverables - Independent content/transport composition and capability matrix tests Rollout and recovery: Replace combination classes after all four fixtures pass; keep the declared provider contract stable while moving formatting code. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-105 — Record one bounded telemetry event around each provider attempt **Story · Medium priority · Intermediate** noCV practice brief v5 · PPROVIDER-105 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Site reliability 30% · Privacy 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. Pattern topics: Decorator (apply). Decorator — Apply: Add consistent attempt instrumentation around interchangeable adapters without embedding logging behavior in each provider mapping. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Adapter A logs full payloads while B logs nothing on exceptions. The team cannot compare local attempt outcomes without exposing synthetic recipient and notice content in generic logs. Acceptance criteria - Wrap provider attempts with a common duration and outcome recorder that emits exactly one completion event per attempt. - Limit event fields to operation identity, provider, outcome category, elapsed duration, and declared adapter version; omit recipient, body, and credentials. - A telemetry sink failure cannot change the provider result or mask an adapter exception. Implementation constraints - Use a Decorator or explicit higher-order function; inject clock and event sink for deterministic tests, and avoid high-cardinality recipient labels. Verification - Run accepted, rejected, thrown-error, and cancellation cases and assert one correctly categorized event each. - Make the sink throw and inspect all event payloads for synthetic secret and recipient markers. Deliverables - Attempt telemetry wrapper and privacy/failure regression fixtures Rollout and recovery: Enable the wrapper on local stubs first; disable the sink independently while preserving attempt behavior and correlation identities. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-106 — Replace the scheduler's six-call notification sequence with one bounded operation **Chore · Medium priority · Advanced** noCV practice brief v5 · PPROVIDER-106 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-103, PPROVIDER-104, PPROVIDER-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Backend 30% · System design 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. Pattern topics: Facade (apply). Facade — Apply: Offer scheduling callers one explicit notification operation while preserving distinct validation, content, and transport responsibilities underneath. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Every scheduling handler must validate, format, select an adapter, initialize telemetry, call send, and map the result in the right order. One handler skips validation and another catches all failures as accepted. Acceptance criteria - Expose one application operation that coordinates the declared preflight, content, adapter, and result steps. - Return typed accepted, rejected, and unknown outcomes without concealing which stage failed. - Keep policy and transport modules independently testable; the Facade must not absorb appointment rules, template storage, or unrelated administration. Implementation constraints - This operation makes at most one provider attempt. Automatic failover and retries are excluded until duplicate-acceptance behavior is defined. Verification - Call the operation from reminder and cancellation flows and compare stage order and result handling. - Fail every stage in turn and assert later side effects do not run; preserve an unknown outcome after ambiguous transport completion. Deliverables - Notification Facade and stage-failure test matrix Rollout and recovery: Move the two local scheduling handlers behind the operation with parity fixtures; revert one caller only if its behavior remains explicit. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-107 — Remove the transparent send proxy that retries an ambiguous timeout **Bug · High priority · Advanced** noCV practice brief v5 · PPROVIDER-107 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. Pattern topics: Proxy (remove). Proxy — Remove: Remove transparent retry behavior that changes send semantics after ambiguous completion, exposing retry decisions and operation identity to the application. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A transparent Proxy automatically repeats any timed-out call. The local stub can accept a notice and drop the response, so the hidden retry records two accepted deliveries while the application sees one success. Acceptance criteria - Remove hidden retry behavior from the send proxy and expose ambiguous completion as unknown. - If a retry is explicitly requested, preserve the original operation identity and require a declared provider deduplication contract; otherwise refuse the retry. - Record attempt identities separately from operation identity so the handoff can explain what was tried without claiming recipient delivery. Implementation constraints - Keep the exercise local and deterministic; a timeout does not prove a provider rejected the operation, and selecting the other provider is not a safe default. Verification - Have the stub accept then lose its response; assert one attempt and an unknown outcome with hidden retries disabled. - Try an explicit retry against a stub lacking deduplication support and confirm it is refused; test convergence on a deduplicating stub. Deliverables - Proxy simplification, explicit retry contract, and ambiguous-timeout reproduction Rollout and recovery: Disable automatic retry in the local composition first; review stored unknown operations before any explicit retry experiment. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. ### Contain provider failure Bound outstanding work and verify recovery without duplicate delivery. #### PPROVIDER-108 — Pause a failing provider and admit one recovery probe **Story · High priority · Advanced** noCV practice brief v5 · PPROVIDER-108 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain provider failure. Depends on: PPROVIDER-105, PPROVIDER-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Pattern topics: Circuit Breaker (apply). Circuit Breaker — Apply: Stop repeated attempts to a failing provider with explicit failure classification and a single controlled recovery probe. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Provider B returns transport failures for every synthetic request. Callers continue spending the full timeout on each attempt even though the service needs a short recovery window. Acceptance criteria - Open the circuit after three consecutive declared transport failures, reject further attempts locally for thirty simulated seconds, and then admit one recovery probe. - A successful probe closes the circuit; a failed probe reopens it. Validation errors and provider business rejections do not count as transport failures. - Track circuits independently per provider, return a distinct circuit-open outcome, and never report rejected local attempts as provider calls. Implementation constraints - Use an injected monotonic clock and explicit transition logic; no real-time sleeps, external service, or automatic cross-provider failover is required. Verification - Advance the fake clock through closed, open, and half-open states and assert allowed call counts. - Race several requests at the recovery boundary and confirm exactly one probe; verify A remains usable while B is open. Deliverables - Circuit Breaker state transitions and deterministic recovery tests Rollout and recovery: Enable the breaker around B's local stub first, observe transitions, and preserve unknown-operation records when resetting circuit state. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-109 — Keep one slow provider from occupying every notification slot **Story · High priority · Advanced** noCV practice brief v5 · PPROVIDER-109 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain provider failure. Depends on: PPROVIDER-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Site reliability 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. Pattern topics: Bulkhead (apply). Bulkhead — Apply: Partition active and queued capacity by provider so stalled requests cannot exhaust another provider's execution slots or grow an unbounded queue. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Twenty stalled B requests consume the module's shared work pool. A's immediate responses cannot start, and callers keep adding pending requests until memory grows. Acceptance criteria - Give each provider at most three active attempts and five queued operations, with a typed overload result when its queue is full. - Queued cancellations remove work before execution; every completion or failure releases its slot exactly once. - A stalled B provider cannot consume A's admission capacity, and queue wait contributes to the caller's overall deadline. Implementation constraints - Use bounded in-process queues and local promise gates; do not add an external broker or unbounded task buffers. Verification - Saturate B, submit A work, and verify A starts promptly while B's active and queued counts stay within bounds. - Cancel queued work, throw inside an attempt, and resolve an attempt twice through a faulty stub; verify no slot leak or over-release. Deliverables - Per-provider Bulkhead and overload/cancellation regression harness Rollout and recovery: Start with the declared local limits and record saturation behavior; reject new work explicitly while draining queues before a configuration change. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-110 — Prove wrapper order preserves deadlines, probe limits, and attempt counts **Task · High priority · Expert** noCV practice brief v5 · PPROVIDER-110 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain provider failure. Depends on: PPROVIDER-108, PPROVIDER-109. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Site reliability 30% · 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. Pattern topics: Decorator (refactor) · Circuit Breaker (refactor) · Bulkhead (refactor). Decorator — Refactor: Make wrapper ordering explicit so instrumentation describes real attempts and cancellation is respected across queue, breaker, and adapter boundaries. Circuit Breaker — Refactor: Release unused half-open probe reservations when queued operations expire or are cancelled, preserving a path to later recovery. Bulkhead — Refactor: Coordinate queue admission and slot release with the overall operation deadline without leaking capacity during concurrent completion and cancellation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The breaker, queue, telemetry, and adapter work in isolation, but a half-open probe can expire while queued and leave the circuit stuck. Another wrapper order records circuit-open rejections as actual provider attempts. Acceptance criteria - Document wrapper order and distinguish operation admission, queue wait, probe reservation, and physical provider attempt. - An overall deadline or cancellation releases queue capacity and any unused probe reservation, with no adapter call after cancellation commits. - Telemetry reconciles submitted, locally rejected, cancelled, and actually attempted operations; terminal outcomes and slot release occur once under every tested interleaving. Implementation constraints - Use a deterministic fake scheduler and clock. Change composition boundaries where needed rather than adding retries that could duplicate an accepted notice. Verification - Exercise a half-open probe queued behind slow work, then cancel it and verify a later eligible request can probe. - Race deadline expiry with adapter completion and circuit opening; assert exact attempt counts, bounded slots, and one terminal outcome. Deliverables - Reviewed composition order, interleaving matrix, and local failure-recovery runbook Rollout and recovery: Run the full fault replay against both local providers before selecting the new composition; preserve a configuration switch and unknown-operation list for rollback analysis. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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.