# 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. ## PDOC — Make a document editor predictable as operations grow A fictional support team edits reusable troubleshooting documents with paragraphs, links, and nested sections. The browser prototype has separate toolbar and keyboard handlers, an unreliable undo stack, and mutable shared formatting objects. Create a local editor and synthetic documents; no starter assets, rich-text engine, collaborative backend, or production service is supplied. **Field:** Frontend. **Suggested stack:** TypeScript, React, Vitest, Playwright. **Engineer value:** Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. **Company value:** Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. **Delivery agreement:** Ten tickets across document structure, interaction consistency, and safe evolution. Build the stated local fixtures and return an editor demo, operation tests, and a short design record. ### Setup prerequisites - Browser events - Immutable updates - Accessible form controls ### Establish document operations Make structure and editing commands consistent. #### PDOC-101 — Give nested sections and paragraphs one structural contract **Task · Medium priority · Foundational** noCV practice brief v5 · PDOC-101 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish document operations. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 80% · 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: Composite (apply). Composite — Apply: Give leaf paragraphs and nested section containers a consistent traversal contract without coupling the document tree to rendered UI elements. 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 outline view handles top-level paragraphs but crashes when a section contains another section. The current arrays do not distinguish leaves from containers or validate imported structure. Acceptance criteria - Represent paragraphs as leaves and sections as containers with stable node identities and explicit discriminated types. - Render and count text nodes consistently through three nested section levels. - Reject duplicate node identities, cycles in programmatic input, and depth above the declared maximum of twenty. Implementation constraints - A Composite may use plain immutable data rather than classes. Keep document structure separate from React elements and DOM nodes. Verification - Render empty, flat, and nested synthetic documents and compare outline counts. - Feed a duplicate identity and a cyclic structure to validation and assert bounded rejection without rendering. Deliverables - Document model, validator, and nested outline example Rollout and recovery: Enable the new model only after validating local sample documents; preserve an untouched input copy when migration rejects a document. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-102 — Make Find next follow document order through collapsed sections **Bug · Medium priority · Foundational** noCV practice brief v5 · PDOC-102 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish document operations. Depends on: PDOC-101. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Accessibility 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: Iterator (apply). Iterator — Apply: Traverse the document model in a stable order so search behavior does not change when presentation hides a section. 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. Find next walks visible DOM elements, so collapsing a section removes its paragraphs from search. Keyboard users cannot tell whether a result was skipped or the query ended. Acceptance criteria - Traverse paragraph text in document preorder, independent of collapsed presentation state. - Find next visits each matching node once, wraps explicitly, and reports position and total through an accessible status message. - An empty query yields no results; a removed node cannot remain the active match after document revision changes. Implementation constraints - Use an Iterator or generator over a stable document snapshot; do not query the DOM to discover content. Verification - Find a match inside a collapsed section and verify the section opens and focus moves to its paragraph control. - Delete the active result and change the query to no matches; confirm stale focus targets and counts are cleared. Deliverables - Snapshot traversal and keyboard search regression Rollout and recovery: Replace local search traversal while retaining the existing search control; fall back to document start when no prior result identity survives. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-103 — Route toolbar and keyboard deletion through one command **Bug · High priority · Intermediate** noCV practice brief v5 · PDOC-103 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish document operations. Depends on: PDOC-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pattern topics: Command (apply). Command — Apply: Represent deletion as one validated document operation shared by toolbar, keyboard, and history so entry points cannot diverge. 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. Toolbar deletion removes an entire selected section, but the keyboard shortcut deletes only its heading and leaves orphaned paragraphs. The two handlers also record different undo entries. Acceptance criteria - Both entry points issue one document command with target identity and expected document revision. - Deleting a section removes its subtree atomically, updates selection to a documented surviving neighbor, and creates one history entry. - Stale, missing, and protected-root targets return explicit failures with no document or history change. Implementation constraints - Command execution belongs outside presentation event handlers; do not store DOM references in history. Verification - Delete the same nested section through toolbar and keyboard and compare document, selection, and history results. - Issue deletion against an old revision and the protected root; assert no partial update. Deliverables - Shared delete command and entry-point parity tests Rollout and recovery: Move both handlers in one local change to prevent mixed semantics; retain saved synthetic documents for replay if the command is reverted. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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 interaction Keep history, controls, and subscriptions tied to one document state. #### PDOC-104 — Restore selection together with content when undoing a deletion **Bug · High priority · Advanced** noCV practice brief v5 · PDOC-104 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pattern topics: Memento (compare). Memento — Compare: Evaluate immutable state snapshots against inverse commands for restoring both document content and logical selection within a bounded undo history. 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. Undo restores paragraph text but leaves the caret pointing to the deleted node identity. A second edit then modifies the wrong paragraph. History currently keeps an editable reference to the live tree. Acceptance criteria - A history entry captures enough immutable document and selection state to restore one completed command consistently. - Undo and redo restore content and logical selection, and a new edit after undo clears the redo branch. - Retain at most fifty entries and disclose the boundary when older history is discarded; failed commands create no entry. Implementation constraints - Compare a Memento snapshot with inverse commands for this bounded editor; do not serialize focusable elements or browser event objects. Verification - Delete, undo, redo, undo, then type; verify the intended restored paragraph receives the edit. - Mutate the live document after recording history and assert old entries remain unchanged; exercise the fifty-entry limit. Deliverables - Bounded undo/redo history and selection restoration tests Rollout and recovery: Start a new local history session on the upgraded model; existing saved document content remains readable even when transient old history is discarded. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-105 — Stop closed editor tabs from receiving document updates **Bug · Medium priority · Intermediate** noCV practice brief v5 · PDOC-105 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Performance 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: Observer (refactor). Observer — Refactor: Repair subscription ownership and notification semantics so repeated panel mounts do not retain listeners or multiply document update work. 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. Opening and closing the preview panel twenty times makes one edit trigger twenty-one outline refreshes. Subscriptions remain in the document store after the panel unmounts. Acceptance criteria - Each subscription has an idempotent unsubscribe operation tied to the subscribing component's lifetime. - One committed document operation sends one versioned notification to each active subscriber, including when callbacks subscribe or unsubscribe during delivery. - A failed subscriber does not stop delivery to other subscribers, and errors are reported without logging document content. Implementation constraints - Keep the Observer surface small and define whether delivery is synchronous; avoid a global application event bus for this document-local need. Verification - Mount and unmount the preview twenty times, edit once, and assert only active listeners run. - Have one listener throw and another unsubscribe during delivery; verify remaining delivery and the next notification set. Deliverables - Subscription lifecycle fix and repeated-mount regression Rollout and recovery: Replace document-local subscriptions together; reset transient listeners on reload without changing saved document data. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-106 — Untangle the toolbar's direct calls into three side panels **Chore · Medium priority · Advanced** noCV practice brief v5 · PDOC-106 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-103, PDOC-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pattern topics: Mediator (compare). Mediator — Compare: Compare a document-scoped coordinator with reducer state to remove circular panel calls without creating a central object that owns every editor feature. 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. Selecting a link makes the toolbar call the inspector, the inspector call the outline, and the outline call the toolbar again. A new panel added another circular dependency and occasional repeated selection updates. Acceptance criteria - Define one direction for selection intents and one authoritative logical selection state. - Toolbar, inspector, and outline remain consistent without importing or invoking each other's component instances. - Compare a document-scoped Mediator with reducer-driven state and callbacks; retain the simpler option that exposes event flow clearly. Implementation constraints - Do not move every unrelated editor concern into a central god object; keep document commands and formatting rules separately testable. Verification - Select a nested link from each panel and compare selection and enabled toolbar actions. - Send the same selection intent twice and remove the selected node; assert bounded updates and a consistent empty selection. Deliverables - Interaction dependency refactor and selection-flow decision record Rollout and recovery: Migrate the three selection participants together in the local editor; retain command behavior and shortcut bindings during the change. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-107 — Prevent edit actions while a replacement document is importing **Bug · High priority · Intermediate** noCV practice brief v5 · PDOC-107 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-104, PDOC-106. Difficulty: Intermediate. Estimated focused work: 150 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. Pattern topics: State (apply). State — Apply: Represent import lifecycle and command eligibility with explicit states so contradictory loading/editing flags cannot erase user work. 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. Import sets isLoading but leaves isEditable true. A user types while the asynchronous parser runs, then the parsed document replaces those edits without a warning. Acceptance criteria - Define explicit ready, importing, and import-failed states and legal transitions, including cancel and retry. - Edit commands are rejected during replacement import, and controls expose their disabled reason accessibly. - A failed or cancelled import preserves the prior document and selection; a late result from a cancelled attempt cannot replace them. Implementation constraints - A tagged union and transition function can implement State semantics; separate state representation from parsing work. Verification - Delay parsing, attempt a keyboard edit, and verify no hidden edit or unexpected replacement occurs. - Cancel one import, start another, then resolve results in reverse order; only the current successful attempt may install a document. Deliverables - Import state transitions and delayed-result interaction tests Rollout and recovery: Replace boolean flags with the explicit local state model; keep the last valid document available until a replacement commits. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. ### Exercise larger and changing documents Measure sharing and preserve compatibility under export and restoration. #### PDOC-108 — Measure whether sharing text styles is worth the indirection **Task · Low priority · Advanced** noCV practice brief v5 · PDOC-108 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise larger and changing documents. Depends on: PDOC-101, PDOC-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. Pattern topics: Flyweight (compare). Flyweight — Compare: Measure immutable sharing of repeated formatting against plain values, while excluding mutable per-paragraph state from the shared objects. 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 generated 20,000-paragraph fixture repeats twelve formatting combinations. A proposed style pool reduces duplicate objects, but its mutable shared entries can change many paragraphs when one is edited. Acceptance criteria - Compare plain immutable style values with Flyweight style identities using the same declared fixture and measurement procedure. - If pooling is retained, intrinsic styles are immutable and per-paragraph selection or editing state stays outside the pool. - Report memory observations and edit/undo latency across five runs, including environment and variance; retain the simpler representation if benefits are inconclusive. Implementation constraints - Measure the model separately from DOM rendering and keep the fixture size fixed; do not claim production performance from one browser snapshot. Verification - Change one paragraph's style and undo it without changing any other paragraph. - Attempt to mutate an interned style and verify prevention; repeat opening and closing documents to check that unused pools are released. Deliverables - Reproducible comparison, isolation tests, and keep-or-remove decision Rollout and recovery: Keep style pooling behind a local representation switch until correctness and measurements support it; preserve a conversion back to plain values. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-109 — Add text and outline export without teaching nodes about file formats **Story · Medium priority · Advanced** noCV practice brief v5 · PDOC-109 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise larger and changing documents. Depends on: PDOC-101, PDOC-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pattern topics: Visitor (compare). Visitor — Compare: Separate growing export operations from relatively stable node types, comparing a Visitor with exhaustive functions and their cost when a new node type arrives. 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 new export format adds another method to paragraph and section objects. The team needs plain text and a structured outline, and expects document node types to change less often than export formats. Acceptance criteria - Both exporters handle every supported node type and preserve documented section order and paragraph boundaries. - Keep export operations outside the document data model using a Visitor or exhaustive discriminated-union functions, with a written choice. - An unknown node type fails with its identity and type instead of silently losing its content. Implementation constraints - Treat link labels as text and serialize structured output through a serializer; exporting must not mutate document state or trigger network requests. Verification - Export a nested fixture containing empty sections and links and compare explicit expected outputs. - Introduce an unsupported node kind and assert both exporters fail visibly while leaving the input unchanged. Deliverables - Two export operations, exhaustive handling tests, and variation tradeoff note Rollout and recovery: Add exports as local downloads after fixture comparison; disable one format independently if its contract changes. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-110 — Reject stale history after replacing the document **Bug · High priority · Expert** noCV practice brief v5 · PDOC-110 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise larger and changing documents. Depends on: PDOC-104, PDOC-107, PDOC-109. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · System design 30% · Quality 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. Pattern topics: Command (refactor) · Memento (refactor). Command — Refactor: Bind queued editor operations to the session that created them so delayed commands cannot operate on a replacement document with reused node IDs. Memento — Refactor: Give history snapshots an explicit document-session boundary and install replacement content together with a coherent history reset. 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 delayed keyboard event queues Undo just before a successful import installs another document. The old history entry then restores part of the previous document into the replacement because both documents happen to contain node p1. Acceptance criteria - Bind commands and history entries to a document session identity as well as a revision. - Replacement import commits document, logical selection, session identity, and history reset as one state transition. - Stale queued commands and incompatible snapshots fail without modifying the active document; cancellation preserves the previous session and valid history. Implementation constraints - Build a deterministic event-order harness rather than timing-dependent sleeps; this ticket does not require collaborative editing or remote persistence. Verification - Interleave queued Undo, successful import, and duplicate node identities; assert the replacement never receives previous-session content. - Fail and cancel imports at each transition boundary, then verify undo remains valid only for the preserved session. Deliverables - Session-bound command/history contract and interleaving regression matrix Rollout and recovery: Introduce session identities at the local editor boundary and clear incompatible transient history once; preserve saved content separately for recovery. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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.