# 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. ## LIVE — A collaborative incident room with a reliable timeline The fictional Harbor operations team coordinates synthetic incidents in a shared room. Engineers post status notes and claim response tasks while connections come and go. Scope is one application gateway, a durable room event store, and fixture clients; alert paging and external chat delivery are excluded. **Field:** Real-time systems. **Suggested stack:** TypeScript, Node.js, WebSocket, PostgreSQL, Redis. **Engineer value:** Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. **Company value:** Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. **Delivery agreement:** Deliver one issue or a phase at a time against synthetic rooms. Keep load fixtures bounded and avoid real incident channels. ### Setup prerequisites - Room membership and command contracts - Synthetic incident events and a controllable transport harness ### Establish the room contract Make connection state and event boundaries explicit. #### LIVE-101 — Show the difference between connected and caught up **Story · Medium priority · Foundational** noCV practice brief v5 · LIVE-101 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the room contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Frontend 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 room shows Connected immediately after a socket opens, even while the last five minutes of events are still missing. Give connection and synchronization separate states. Acceptance criteria - The UI distinguishes connecting, recovering, current, disconnected, and unavailable. - Current appears only after the server-defined replay boundary has been applied. - The latest confirmed timeline remains readable during reconnect with a visible freshness notice. Implementation constraints - Use a deterministic transport fixture; socket open alone is not proof of complete room state. Verification - Open a connection and delay replay completion; the room stays recovering until the boundary arrives. - Disconnect after a confirmed note and fail reconnect; the note remains readable but is not labeled current. Deliverables - Room connection/sync state model and delayed-replay UI test Rollout and recovery: Enable state labels in the pilot room; force read-only mode if synchronization cannot be established. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-102 — Reject malformed room events before they reach the reducer **Task · High priority · Foundational** noCV practice brief v5 · LIVE-102 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the room contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 50% · API design 30% · Security 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A gateway change sends a string sequence number and crashes every open room tab. Define a versioned event envelope with deliberate unknown-version behavior. Acceptance criteria - The boundary validates version, room ID, event ID, sequence, type, and bounded payload. - Malformed or unsupported events never enter the state reducer. - Protocol errors expose a safe category and recovery action without echoing raw note content. Implementation constraints - Treat transport input as untrusted and impose a documented frame-size limit. Verification - Accept a valid status-note envelope and verify its typed reducer input. - Send an oversized frame, invalid sequence, and unknown version; reject each without crashing or leaking raw payloads. Deliverables - Versioned event parser and invalid-envelope fixture suite Rollout and recovery: Deploy readers that understand the new version before changing writers; pause the stream on unsupported contracts. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-103 — Authorize room subscription before replaying its history **Bug · High priority · Intermediate** noCV practice brief v5 · LIVE-103 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the room contract. Depends on: LIVE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Real-time systems 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 client changes the room ID in its subscribe message and receives a few private timeline entries before the gateway rejects membership. Move authority checks ahead of all history and live delivery. Acceptance criteria - Subscription derives tenant and user from the authenticated session. - Current room membership is checked before replay queries and live listener registration. - Denied subscriptions leave no active listener or partially delivered room data. Implementation constraints - Enforce room scope in repository methods as well as at the transport boundary. Verification - Subscribe as an authorized synthetic member and inspect permitted replay. - Request a room in another organization and revoke membership before listener installation; deliver zero room events in both cases. Deliverables - Authorized subscription boundary and cross-room denial tests Rollout and recovery: Require this before private-room pilots; disable subscriptions if membership authority is unavailable. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. ### Recover a coherent timeline Order, deduplicate, and replay confirmed events. #### LIVE-104 — Stop duplicate and out-of-order notes confusing the timeline **Bug · High priority · Advanced** noCV practice brief v5 · LIVE-104 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover a coherent timeline. Depends on: LIVE-101, LIVE-102, LIVE-103. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Distributed systems 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 reconnect overlaps live delivery with replay. The same mitigation note appears twice, and a late earlier event moves a resolved task back to active. Acceptance criteria - Event identity deduplicates replay and live delivery for the same room. - Only a contiguous server sequence advances the applied cursor. - Out-of-order gaps are buffered within a configured bound and trigger recovery rather than arbitrary state application. Implementation constraints - A wall-clock timestamp is presentation metadata, not the authoritative event order. Verification - Deliver a duplicate event through replay and live paths; the timeline shows it once. - Deliver sequences 12, 14, 13 and then an oversized gap; apply contiguous state correctly and enter recovery at the bound. Deliverables - Ordered room reducer and duplicate/gap test vectors Rollout and recovery: Shadow the reducer against fixed logs before use; reset from a validated snapshot if gap recovery fails. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-105 — Recover when a reconnect cursor is older than retained history **Story · High priority · Advanced** noCV practice brief v5 · LIVE-105 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover a coherent timeline. Depends on: LIVE-104. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Distributed systems 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 laptop wakes after the room’s replay window has expired. The gateway returns recent events after the old cursor, leaving an invisible gap in the task state. Acceptance criteria - An expired cursor receives an explicit resync-required response. - The client replaces state from a room-scoped snapshot and resumes after its exact sequence boundary. - Snapshot and post-snapshot events cannot combine data from different rooms or snapshot revisions. Implementation constraints - Keep the prior timeline visibly stale until the replacement state is validated. Verification - Resume a retained cursor and confirm ordinary incremental replay. - Use an expired cursor and deliver a live event during snapshot loading; apply it once after the snapshot boundary, or reject mismatched room data. Deliverables - Snapshot/replay recovery protocol and expired-cursor tests Rollout and recovery: Pilot with a short synthetic retention window; disable writes during unresolved resync and retain safe read-only context. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. ### Coordinate work safely Protect commands, presence, and changing access. #### LIVE-106 — Reconcile a task claim when its acknowledgement is lost **Bug · High priority · Advanced** noCV practice brief v5 · LIVE-106 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate work safely. Depends on: LIVE-105. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 40% · Backend 30% · Database 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 responder claims Investigate cache saturation, loses the acknowledgement, and retries. The room appends duplicate claims and briefly shows two owners. Acceptance criteria - A claim command has a stable operation key and expected task revision. - The durable event and operation result commit together or neither becomes authoritative. - Retry returns the existing result; a competing confirmed claim produces a conflict instead of a second owner. Implementation constraints - Use the application transaction boundary and an outbox if broadcasting crosses processes. Verification - Accept a claim, drop the acknowledgement, and retry with the same key; one logical claim exists. - Race two responders at the same revision and fail broadcast after commit; one owner remains and replay recovers the event. Deliverables - Idempotent claim command and lost-acknowledgement/concurrent-claim tests Rollout and recovery: Enable claims after replay recovery; disable new claims if transaction/result consistency fails while keeping confirmed assignments readable. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-107 — Expire disconnected presence without rewriting incident history **Task · Medium priority · Intermediate** noCV practice brief v5 · LIVE-107 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate work safely. Depends on: LIVE-103. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 70% · 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. Closing a laptop leaves its user shown as In room for hours. Presence currently uses the same durable event path as incident notes, making heartbeat traffic dominate replay. Acceptance criteria - Presence expires from a bounded lease using server-observed heartbeats. - Multiple tabs collapse to one visible member while preserving presence if one tab remains connected. - Presence expiration never removes authored notes or changes task ownership. Implementation constraints - Presence is advisory activity state, not proof that someone read or understood an incident. Verification - Open two tabs, close one, and verify the member remains until the final lease expires. - Delay heartbeats and restart the presence store; stale members expire without changing durable timeline or ownership. Deliverables - Ephemeral presence lease model and multi-tab expiry tests Rollout and recovery: Release advisory presence independently; hide it when its store is unavailable rather than retaining indefinite online claims. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-108 — Cut off room delivery when membership is revoked mid-replay **Bug · Urgent priority · Expert** noCV practice brief v5 · LIVE-108 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate work safely. Depends on: LIVE-105, LIVE-106, LIVE-107. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Real-time systems 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 temporary responder is removed while a long history replay is streaming. The established socket keeps receiving new private notes until reconnect. Acceptance criteria - Membership changes invalidate active subscriptions and pending replay batches for that session and room. - Commands recheck current authority before committing, even when the socket was previously authorized. - After the defined revocation barrier, no queued private frames are delivered and listener resources are released. Implementation constraints - Specify the barrier and in-flight message limits; do not promise retroactive removal of data already delivered. Verification - Revoke a member between replay batches and assert no subsequent private frames cross the barrier. - Race revocation with task claim and a queued live note; reject unauthorized commit and remove all room listeners. Deliverables - Revocation-aware subscription lifecycle and race harness Rollout and recovery: Require the race harness before temporary-member use; close affected room sockets if revocation propagation is uncertain. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. ### Handle operational pressure Bound resource use and rehearse recovery. #### LIVE-109 — Keep one slow room client from exhausting gateway memory **Task · High priority · Expert** noCV practice brief v5 · LIVE-109 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle operational pressure. Depends on: LIVE-105, LIVE-108. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Real-time 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. A paused browser cannot consume events, but its send buffer grows throughout a synthetic incident drill. Add bounded per-connection delivery and a recoverable overload path. Acceptance criteria - Each connection has explicit queued-byte and queued-event limits. - Overloaded clients receive a safe resync/close outcome when possible; durable events are never silently skipped while claiming currency. - Healthy clients continue receiving events and per-connection resources are reclaimed after closure. Implementation constraints - Keep a bounded load fixture; distinguish disposable presence updates from durable timeline events. Verification - Pause one consumer while a second reads normally; measure bounded memory and uninterrupted healthy delivery. - Exceed limits, reconnect the slow client, and recover by cursor/snapshot with no silently missing timeline events. Deliverables - Backpressure policy and bounded slow-consumer load report Rollout and recovery: Canary conservative queue limits with disconnect metrics; reduce admission or disable live updates if memory bounds fail. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-110 — Rehearse gateway restart during incident coordination **Chore · High priority · Advanced** noCV practice brief v5 · LIVE-110 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle operational pressure. Depends on: LIVE-106, LIVE-108, LIVE-109. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 40% · Site reliability 30% · 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. The team has not tested what room users see during a gateway restart. Create a repeatable drill with one pending claim, a disconnected reader, and a recently revoked member. Acceptance criteria - The drill records final durable event IDs, sequence, task owner, and subscription count. - Restart recovery neither duplicates the claim nor grants the revoked member replay access. - The runbook defines safe metrics and a rollback action without logging private note bodies. Implementation constraints - Restart only disposable practice processes and use synthetic room content. Verification - Run the restart drill twice from the same fixture and compare final authoritative room state. - Make the event store unavailable during reconnect; clients remain explicitly stale/read-only and no command is falsely confirmed. Deliverables - Gateway restart drill and incident-room operator runbook Rollout and recovery: Require the drill before pilot expansion; keep room writes disabled if durable replay or authorization recovery is unavailable. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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.