# 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. ## DESK — A support console that survives a busy shift The fictional Alder support team handles billing and delivery conversations in a browser console. Agents keep several tickets open, share filtered queues, and work through unreliable office Wi-Fi. The API contract returns ticket revisions and cursor-based pages; work stays within the console and its test adapter. **Field:** Frontend. **Suggested stack:** React, TypeScript, CSS Modules, Testing Library, Playwright. **Engineer value:** Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. **Company value:** Inspect how an engineer protects agent work and handles failures that interrupt support operations. **Delivery agreement:** Choose one ticket or deliver the phases as separate pull requests. Use synthetic customer content; live email delivery is outside scope. ### Setup prerequisites - A ticket-list and reply API contract to implement or stub - Synthetic conversations across two organizations with revision conflicts ### Make the queue dependable Keep navigation and list state understandable. #### DESK-101 — Keep shared queue links useful after refresh **Story · Medium priority · Foundational** noCV practice brief v5 · DESK-101 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the queue dependable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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 shift lead shares the unassigned billing queue, but recipients land on All tickets. Put filters in the URL so opening the link, refreshing, and using Back retain the intended view. Acceptance criteria - Status, team, and reference filters round-trip through the URL. - Unknown filter values use documented defaults without crashing. - Back restores the preceding filters and clears any cursor invalidated by them. Implementation constraints - Reference search targets synthetic ticket IDs; customer message text must not enter query parameters. Verification - Open team=billing and status=unassigned in a fresh tab and inspect the request. - Use an unknown status, then navigate Back after two filter changes; verify fallback and history order. Deliverables - Queue URL parser and browser navigation regression case Rollout and recovery: Enable URL filters for the internal queue; a flag restores the default queue without invalidating ticket links. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-102 — Separate an empty queue from a failed request **Bug · High priority · Foundational** noCV practice brief v5 · DESK-102 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the queue dependable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 70% · Accessibility 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. During an API outage the console said No tickets, and an agent assumed the queue was clear. Give loading, empty, stale, and failed responses distinct presentations. Acceptance criteria - An empty successful response shows active filters and a clear-filters action. - A failed refresh retains previously loaded rows and labels them stale. - Retry fetches the active query once and exposes an accessible error if it fails again. Implementation constraints - Keep the last successful response while refreshing. Verification - Return an empty successful page and verify no outage message appears. - Load three rows, reject refresh, then recover on retry; rows persist until replacement. Deliverables - Explicit queue request states and failure screenshots Rollout and recovery: Release state rendering independently; revert the presentation component if the queue becomes unusable. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-103 — Stop a late search response replacing the current queue **Bug · High priority · Intermediate** noCV practice brief v5 · DESK-103 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the queue dependable. Depends on: DESK-101, DESK-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. On a slow connection, searching DL-42 and immediately clearing the field sometimes repopulates the screen with DL-42 results. Make response ownership follow the active query. Acceptance criteria - Only a response for the active query updates rows, counts, or errors. - Changing filters abandons the previous page cursor. - Unmounting the queue prevents late responses from changing visible state. Implementation constraints - Guard against adapters that resolve after cancellation. Verification - Resolve two requests in reverse order and confirm the last selection wins. - Reject a superseded request after the current one succeeds; no stale error appears. Deliverables - Query ownership fix and deterministic out-of-order response test Rollout and recovery: Canary with the support pilot; revert the coordinator if current-query results stop loading. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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 the conversation Keep drafts, revisions, and focus tied to the right ticket. #### DESK-104 — Restore the right reply draft when switching tickets **Story · High priority · Intermediate** noCV practice brief v5 · DESK-104 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the conversation. Depends on: DESK-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Agents alternate between conversations while checking orders. The editor resets on every switch, and one experimental fix restored a draft into the wrong customer thread. Acceptance criteria - Draft keys include organization, signed-in agent, and ticket. - Returning to a ticket restores its text without copying it to another conversation. - Sign-out clears local drafts; storage refusal leaves editing usable with a persistence notice. Implementation constraints - Use synthetic text and never record draft content in analytics. Verification - Write different drafts on two tickets, switch repeatedly, and reload in the same account. - Switch organizations and simulate quota failure; no prior-account draft appears and typing still works. Deliverables - Scoped draft store and account-switch regression coverage Rollout and recovery: Start with session-scoped storage; disable persistence and retain the in-memory editor if corruption is reported. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-105 — Make ticket switching predictable from the keyboard **Task · Medium priority · Intermediate** noCV practice brief v5 · DESK-105 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the conversation. Depends on: DESK-102. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 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. An agent navigating by keyboard loses their place after closing ticket details. Define focus behavior for opening, closing, and removing the selected row. Acceptance criteria - Opening details moves focus to the detail heading or first intentional control. - Closing returns focus to the originating row or a documented adjacent fallback. - Shortcuts do not fire in text inputs or during input method composition. Implementation constraints - Shortcuts supplement semantic controls and the ordinary tab sequence. Verification - Open and close details using only the keyboard and inspect focus. - Remove the originating row while details are open, then close; focus remains visible and useful. Deliverables - Focus restoration and keyboard walkthrough notes Rollout and recovery: Ship focus restoration before shortcuts; disable shortcuts separately if they conflict with editing. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-106 — Show assignment conflicts without pretending a save worked **Bug · High priority · Advanced** noCV practice brief v5 · DESK-106 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the conversation. Depends on: DESK-103. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Two leads assign the same ticket within a second. One console displays its optimistic assignment forever even though the API rejected the stale revision. Acceptance criteria - Writes include the last observed ticket revision. - A conflict restores authoritative assignment and explains the competing update. - An older rollback cannot overwrite a newer confirmed assignment. Implementation constraints - The API remains authoritative; never automatically retry a stale assignment. Verification - Accept an assignment and verify the returned revision replaces the local one. - Interleave two changes with a conflict arriving last; the newest authoritative owner remains visible. Deliverables - Revision-aware assignment flow and interleaving tests Rollout and recovery: Enable for one team and inspect conflicts; fall back to confirmed saves if optimistic rollback proves unreliable. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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 interruptions Recover from partial failures and concurrent work. #### DESK-107 — Report partial bulk-close results per ticket **Story · Medium priority · Advanced** noCV practice brief v5 · DESK-107 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruptions. Depends on: DESK-106. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 80% · API 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. Closing 25 conversations returns 22 successes, two permission denials, and one revision conflict. Today a green toast appears and every selected row disappears. Acceptance criteria - Successful IDs leave the queue only if its filter excludes closed work. - Denied and conflicting tickets remain selected with individual reasons. - Retry targets retryable failures without replaying confirmed closes. Implementation constraints - Interpret the result per ID; a successful HTTP status does not mean every item succeeded. Verification - Run mixed outcomes and compare row visibility and selection with each result. - Inspect retry IDs; denied and already closed items are excluded. Deliverables - Bulk result summary and mixed-outcome integration test Rollout and recovery: Limit the first release to 25 tickets; disable bulk close while retaining individual close on regression. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-108 — Reconcile an uncertain reply send after a connection drop **Bug · Urgent priority · Expert** noCV practice brief v5 · DESK-108 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruptions. Depends on: DESK-104, DESK-106. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. The server accepts a reply, but Wi-Fi drops before acknowledgement. Clicking Send again duplicates the email. Model an uncertain result and recover through operation lookup. Acceptance criteria - One operation key survives timeout and explicit retry. - Uncertain sending preserves the draft and checks status before clearing it. - Changed text receives a new operation only after reconciliation; account changes stop status polling. Implementation constraints - Use a stubbed idempotent send/status contract; actual email delivery is excluded. Verification - Accept sending but drop the response, then report accepted from lookup; display one reply. - Return unknown and then unavailable from lookup; preserve the draft and prevent an unkeyed duplicate. Deliverables - Reply send state machine and lost-acknowledgement test Rollout and recovery: Pilot with synthetic mailboxes; disable the new sending flow if operation reconciliation cannot be trusted. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-109 — Keep a long conversation responsive without hiding context **Task · Medium priority · Advanced** noCV practice brief v5 · DESK-109 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruptions. Depends on: DESK-105. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Frontend 30% · Accessibility 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. An 800-message synthetic conversation makes expanding attachments slow. Reduce initial rendering while preserving chronological reading and position when older messages load. Acceptance criteria - Initial rendering uses a bounded window and explicit load-older control. - Prepending older messages preserves the visible anchor and keyboard focus. - A before/after profile on the same fixture records the performance budget and measurement environment. Implementation constraints - Prefer explicit pagination if virtualization would break assistive-technology reading order. Verification - Profile the 800-message fixture and load two older pages without a scroll jump. - Fail and retry an older-page request; no messages duplicate and the current position remains. Deliverables - Bounded message rendering and reproducible profile note Rollout and recovery: Enable above an agreed conversation size; restore full rendering if reading order regresses. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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 the next shift Make the release diagnosable and supportable. #### DESK-110 — Give support a useful report when the console fails **Chore · Medium priority · Intermediate** noCV practice brief v5 · DESK-110 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare the next shift. Depends on: DESK-107, DESK-108, DESK-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 40% · Privacy engineering 30% · Site reliability 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. On-call receives screenshots saying It stopped working with no clue whether loading, assignment, or sending failed. Add redacted diagnostics and a release handoff. Acceptance criteria - Diagnostics include build version, operation category, timestamp, and safe correlation ID. - Customer text, drafts, tokens, and raw responses are excluded. - Copying diagnostics after failure preserves current draft and navigation. Implementation constraints - Use a field allowlist and document the owner of each operation category. Verification - Trigger sending failure and match its correlation ID to the synthetic trace. - Put secret-like strings in messages and errors; copied diagnostics contain none. Deliverables - Redacted diagnostics panel and one-page console runbook Rollout and recovery: Enable diagnostic copying for the pilot; hide it immediately if excluded content appears. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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.