# 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. ## BLOADSHED — Overload admission and graceful degradation A fictional ticketing service becomes unresponsive during event releases because optional recommendation calls consume the same resources as reservation checks. **Field:** Site reliability. **Suggested stack:** TypeScript, HTTP, Redis. **Engineer value:** Practice overload behavior, admission control, and fair performance experiments. **Company value:** Create predictable failure and degradation behavior under declared capacity constraints. **Delivery agreement:** Deliver local controls and measurements; no live load generation. ### Setup prerequisites - Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. ### Characterize overload Define essential outcomes and bounded workload assumptions. #### BLOADSHED-101 — Classify essential and optional ticketing requests **Task · Medium priority · Foundational** noCV practice brief v5 · BLOADSHED-101 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Characterize overload. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Recommendation requests compete with reservation checks without any priority policy. Acceptance criteria - List request classes and user impact. - Define allowed degradation per class. - Keep reservation correctness invariant. Implementation constraints - Do not prioritize users by inferred personal traits. Verification - Classify a reservation and recommendation request. - Identify a request that must fail explicitly rather than degrade silently. Deliverables - Request-class policy. Rollout and recovery: Review classification before applying limits. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-102 — Build a workload that preserves offered arrival rate **Task · High priority · Advanced** noCV practice brief v5 · BLOADSHED-102 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Characterize overload. Depends on: BLOADSHED-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 70% · 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 closed-loop load script hides overload by sending fewer requests as responses slow. Acceptance criteria - Record offered, admitted, completed, and rejected rates. - Use bounded open-loop scheduling. - Report dropped generator work and resource limits. Implementation constraints - Run only against the local fixture. Verification - Generate the declared steady arrival rate. - Overload the generator and report its invalid measurement window. Deliverables - Load harness. Rollout and recovery: Cap duration and concurrency; discard runs with unreported generator saturation. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. ### Protect service capacity Limit queues and isolate optional work. #### BLOADSHED-103 — Bound the waiting queue before worker slots are exhausted **Task · High priority · Intermediate** noCV practice brief v5 · BLOADSHED-103 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Platform engineering 40% · Performance 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. Requests accumulate indefinitely while waiting for a shared dependency. Acceptance criteria - Enforce a finite waiting capacity. - Return a documented overload response when full. - Remove cancelled requests from the queue. Implementation constraints - Never report rejected requests as successful degradation. Verification - Admit work below the limit. - Overflow and cancel queued requests without leaked slots. Deliverables - Bounded admission queue. Rollout and recovery: Start with conservative limits; restore the previous policy if essential outcomes regress. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-104 — Isolate optional recommendation concurrency **Task · High priority · Advanced** noCV practice brief v5 · BLOADSHED-104 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-101, BLOADSHED-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Performance engineering 30% · Networking 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: Bulkhead (apply). Bulkhead — Apply: Bound optional recommendation concurrency separately from essential requests and show that exhausted optional capacity cannot consume the essential reserve. 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. Slow recommendations consume every outbound connection. Acceptance criteria - Use a separate optional-work concurrency budget. - Reserve declared capacity for essential requests. - Skip optional work when its budget is unavailable. Implementation constraints - Use a real bounded pool, not an unbounded background task list. Verification - Serve reservations while recommendations stall. - Exhaust optional slots and verify graceful omission. Deliverables - Optional-work bulkhead. Rollout and recovery: Enable the bulkhead before increasing overall concurrency. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-105 — Propagate request deadlines to downstream work **Bug · High priority · Advanced** noCV practice brief v5 · BLOADSHED-105 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-103, BLOADSHED-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 40% · Site reliability 30% · Networking 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 client has timed out while its dependency request continues holding a slot. Acceptance criteria - Derive child deadlines from remaining request time. - Abort owned work on cancellation. - Release capacity even when a double ignores cancellation. Implementation constraints - Bound cleanup time and track late completions safely. Verification - Complete within a shared deadline. - Timeout an uncooperative dependency and reclaim the slot. Deliverables - Deadline propagation. Rollout and recovery: Default to shorter optional deadlines; retain explicit timeout responses. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-106 — Provide retry guidance that does not synchronize every client **Task · Medium priority · Intermediate** noCV practice brief v5 · BLOADSHED-106 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Site reliability 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. All rejected clients retry exactly one second later and recreate the spike. Acceptance criteria - Return bounded retry guidance. - Document jitter and attempt ceilings for clients. - Avoid automatic retry of unsafe writes. Implementation constraints - Use deterministic random input in tests. Verification - Spread synthetic client retries across the window. - Verify non-idempotent requests are not blindly retried. Deliverables - Overload response contract. Rollout and recovery: Publish guidance with admission changes; monitor repeated rejection bursts. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-107 — Preserve fair access across tenant request queues **Task · High priority · Advanced** noCV practice brief v5 · BLOADSHED-107 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-103, BLOADSHED-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Platform engineering 40% · Site reliability 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. One large tenant fills every waiting slot and blocks smaller tenants. Acceptance criteria - Bound per-tenant queued work. - Define a transparent scheduling policy. - Prevent idle tenant allocation from wasting all spare capacity. Implementation constraints - Use synthetic tenant classes and document fairness assumptions. Verification - Serve concurrent tenants under sustained load. - Flood one tenant and verify others retain declared progress. Deliverables - Tenant scheduling policy. Rollout and recovery: Trial with fixed limits; disable new policy if starvation appears. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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 recovery Compare policies and verify return to normal operation. #### BLOADSHED-108 — Compare rejection policies under the same offered workload **Task · High priority · Expert** noCV practice brief v5 · BLOADSHED-108 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate recovery. Depends on: BLOADSHED-102, BLOADSHED-105, BLOADSHED-106, BLOADSHED-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Site reliability 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 team must choose between a larger queue and earlier rejection. Acceptance criteria - Compare identical arrival traces and resource budgets. - Measure essential latency, rejection, completion, and recovery separately. - Explain tradeoffs and remaining uncertainty. Implementation constraints - Do not compare only successful-response latency or hide rejected work. Verification - Run both policies on the same synthetic burst. - Expose a policy that improves accepted latency by rejecting more work. Deliverables - Admission policy assessment. Rollout and recovery: Choose a bounded default and retain a tested configuration rollback. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-109 — Prevent capacity oscillation when the burst ends **Bug · High priority · Advanced** noCV practice brief v5 · BLOADSHED-109 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate recovery. Depends on: BLOADSHED-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Platform 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. Degradation switches on and off rapidly near the threshold. Acceptance criteria - Add declared hysteresis or cooldown semantics. - Return to normal after sustained recovery. - Keep manual emergency controls auditable. Implementation constraints - Avoid permanent degradation after transient overload. Verification - Recover after a controlled burst. - Oscillate near thresholds and verify bounded mode changes. Deliverables - Recovery controller tests. Rollout and recovery: Run in observation mode first; allow a safe fixed-policy fallback. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-110 — Document the customer-visible degraded service contract **Chore · Low priority · Foundational** noCV practice brief v5 · BLOADSHED-110 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate recovery. Depends on: BLOADSHED-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Product support cannot explain which features disappear during overload. Acceptance criteria - List omitted features and explicit failures. - Describe recovery indicators without promising exact times. - Include support diagnosis from safe metrics. Implementation constraints - No false success when essential work was rejected. Verification - Review a degraded response against the guide. - Verify a failed reservation is never described as completed. Deliverables - Degradation guide. Rollout and recovery: Ship alongside controls and update it when request classes change. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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.