# 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. ## BREADINESS — Seasonal traffic readiness review A fictional course platform expects a registration deadline spike. Capacity assumptions, escalation ownership, and degradation decisions are scattered across old documents. **Field:** Site reliability. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. **Company value:** Produce a concrete launch-readiness assessment with measurable risks and recovery actions. **Delivery agreement:** Deliver a local rehearsal and review packet; external launch approval remains outside the exercise. ### Setup prerequisites - Create synthetic registration traces and local dependency doubles with finite connection and request limits. ### Collect assumptions Define demand, dependencies, and launch invariants. #### BREADINESS-101 — Turn the registration forecast into a workload envelope **Task · Medium priority · Foundational** noCV practice brief v5 · BREADINESS-101 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Collect assumptions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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 launch plan says 'ten times traffic' without a base rate or request mix. Acceptance criteria - Declare arrival range, duration, and request mix. - Separate new registrations from read traffic. - Identify unknown forecast assumptions. Implementation constraints - Use fictional demand figures and label them assumptions. Verification - Convert the forecast into a bounded local trace. - Reject an unspecified multiplier as a complete workload definition. Deliverables - Workload envelope. Rollout and recovery: Review assumptions before capacity testing. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-102 — Inventory dependency quotas and exhaustion behavior **Task · High priority · Intermediate** noCV practice brief v5 · BREADINESS-102 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Collect assumptions. Depends on: BREADINESS-101. Difficulty: Intermediate. Estimated focused work: 120 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. The database pool and email adapter have different limits and failure semantics. Acceptance criteria - Record local pool and mock-provider ceilings. - Describe behavior at each limit. - Assign an owner to unresolved limits. Implementation constraints - No live provider quotas are assumed from memory. Verification - Exhaust a configured local limit. - Keep unknown external quotas marked unverified. Deliverables - Dependency constraint register. Rollout and recovery: Resolve critical unknowns before claiming launch readiness. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. ### Test constraints Exercise saturation and failure paths. #### BREADINESS-103 — Add connection-pool wait time to registration diagnostics **Task · Medium priority · Intermediate** noCV practice brief v5 · BREADINESS-103 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Site reliability 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. Slow registration is blamed on SQL even when requests are waiting for a connection. Acceptance criteria - Measure wait and query duration separately. - Track pool occupancy with bounded labels. - Bound waiting time and cancellation cleanup. Implementation constraints - Do not expose SQL parameters or user identifiers. Verification - Observe deliberate pool contention. - Cancel a waiting request and verify it leaves the queue. Deliverables - Pool diagnostics. Rollout and recovery: Introduce read-only metrics before changing pool size. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-104 — Exercise registration idempotency during client reconnects **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-104 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 40% · Quality engineering 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. A network interruption causes clients to resubmit successful registrations. Acceptance criteria - Reuse stable submission identity. - Preserve one enrollment per intended registration. - Return the accepted result on exact replay. Implementation constraints - Conflicting payload reuse must fail explicitly. Verification - Replay after a lost response. - Race two conflicting submissions under one identity. Deliverables - Reconnect regression suite. Rollout and recovery: Gate the surge rehearsal on idempotency correctness. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-105 — Decouple confirmation delivery from accepted registration **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-105 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Backend 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. A slow notification provider makes accepted registrations appear failed. Acceptance criteria - Commit registration and notification intent atomically. - Return accepted registration independently of delivery latency. - Expose pending delivery without duplicate enrollment. Implementation constraints - Use a local notification double; send no messages. Verification - Accept registration during a notification outage. - Recover delivery and verify one logical notification operation. Deliverables - Notification outbox flow. Rollout and recovery: Retain pending intents through rollback; pause dispatch independently. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-106 — Test read-only degradation when enrollment writes are unavailable **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-106 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-103, BREADINESS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Backend 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A database write outage should not make the entire course catalog disappear. Acceptance criteria - Preserve declared safe read behavior. - Fail enrollment explicitly when writes cannot commit. - Show data age when serving a cached catalog. Implementation constraints - Never queue unacknowledged enrollments invisibly. Verification - Read the catalog during a write failure. - Attempt enrollment and verify no false confirmation. Deliverables - Write-outage behavior. Rollout and recovery: Enable only documented degradation; clear stale cache on incompatible catalog changes. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-107 — Review cache warmup without creating a database stampede **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-107 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-103, BREADINESS-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Distributed systems 30% · 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. Every process warms the same popular course pages simultaneously after deployment. Acceptance criteria - Bound warmup concurrency and total work. - Coalesce identical cache fills. - Keep cache failure from multiplying database reads. Implementation constraints - Use a finite synthetic course list. Verification - Warm popular entries under the configured budget. - Expire entries together and verify bounded database pressure. Deliverables - Cache warmup controller. Rollout and recovery: Warm gradually before synthetic peak; disable warmup if database wait rises. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. ### Prepare operations Make readiness gaps and controls reviewable. #### BREADINESS-108 — Decide launch capacity with cost and failure headroom **Task · High priority · Expert** noCV practice brief v5 · BREADINESS-108 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare operations. Depends on: BREADINESS-102, BREADINESS-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Site reliability 40% · Cloud infrastructure 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 cheapest configuration passes average load but fails when one worker is unavailable. Acceptance criteria - Compare configurations under identical peak and degraded-capacity traces. - Measure accepted work, latency, errors, and resource cost assumptions. - Document required headroom and untested scale. Implementation constraints - Local observations do not prove production capacity. Verification - Rehearse the selected configuration with one simulated worker loss. - Reject a configuration that only passes by dropping critical work. Deliverables - Capacity decision record. Rollout and recovery: Adopt only within the declared workload envelope and retain rollback settings. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-109 — Run a launch tabletop with explicit stop conditions **Task · High priority · Intermediate** noCV practice brief v5 · BREADINESS-109 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare operations. Depends on: BREADINESS-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Operators lack a shared decision point for pausing registration during a surge. Acceptance criteria - Define measurable pause and resume conditions. - Assign incident and product decision roles. - Rehearse notification outage and database saturation scenarios. Implementation constraints - Record decisions as simulation outcomes. Verification - Walk through a recoverable surge. - Keep writes paused when integrity is uncertain. Deliverables - Tabletop record. Rollout and recovery: Review open actions before the hypothetical launch. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-110 — Publish a launch handoff with unresolved readiness gaps **Chore · Low priority · Foundational** noCV practice brief v5 · BREADINESS-110 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare operations. Depends on: BREADINESS-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 100%. 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 green test report obscures that external quotas and target-environment recovery remain unverified. Acceptance criteria - List observed checks and unresolved assumptions separately. - Include active configuration and recovery commands. - Name owners for deferred verification. Implementation constraints - Do not mark unexecuted checks complete. Verification - Trace a readiness claim to its local result. - Keep an unverified provider limit visible. Deliverables - Readiness handoff packet. Rollout and recovery: Update after configuration changes; withdraw stale readiness conclusions. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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.