# 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. ## READ — A document reader that keeps people oriented The fictional Plainview handbook reader serves versioned HTML documents with headings, tables, footnotes, and annotations. Scope is accessible HTML rendering from a structured model; OCR and arbitrary PDF remediation are excluded. **Field:** Accessibility. **Suggested stack:** React, TypeScript, CSS Modules, Testing Library, Playwright. **Engineer value:** Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. **Company value:** Inspect how an engineer makes information usable while protecting document integrity and access boundaries. **Delivery agreement:** Each ticket targets one reader behavior. Use synthetic documents and record assumptions about the source model. ### Setup prerequisites - Versioned synthetic documents with stable section IDs - Annotation and document-access API contracts to stub ### Make content readable Preserve semantics and text preferences. #### READ-101 — Restore heading and table semantics in handbook chapters **Bug · High priority · Foundational** noCV practice brief v5 · READ-101 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make content readable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 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. Every source block becomes a styled div. Readers cannot navigate by heading, and table cells expose no header relationships. Acceptance criteria - Headings preserve validated source hierarchy in semantic elements. - Tables retain captions and source-model header associations. - Unsupported blocks show a clear fallback rather than silently disappearing. Implementation constraints - Validate the structured model; this ticket does not infer semantics from arbitrary visual formatting. Verification - Navigate by headings and inspect a table with row and column headers. - Supply an unsupported block and invalid hierarchy; content is not silently lost and validation identifies the issue. Deliverables - Semantic block renderer and document-model fixtures Rollout and recovery: Enable for validated documents; retain the accessible source view when model validation fails. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-102 — Let readers adjust text without losing their place **Story · Medium priority · Foundational** noCV practice brief v5 · READ-102 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make content readable. Depends on: READ-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 50% · Frontend 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. Increasing font size resets the chapter to the top, while dark theme leaves footnotes unreadable. Add preferences that preserve position and cover every content type. Acceptance criteria - Font size, spacing, and theme apply to body, footnotes, tables, and annotations. - Preference changes preserve the current section anchor. - System theme is the initial default and invalid stored preferences recover safely. Implementation constraints - Use semantic CSS variables and avoid fixed content heights. Verification - Resize text midway through a chapter; the current section stays in view. - Load corrupt preference data and test dark/system themes; content stays readable and defaults recover. Deliverables - Reader preferences and theme/content fixture page Rollout and recovery: Release session-local preferences first; disable persistence if stored values break rendering. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. ### Keep the reader oriented Make search, contents, and bookmarks predictable. #### READ-103 — Navigate search matches without breaking document text **Story · Medium priority · Intermediate** noCV practice brief v5 · READ-103 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep the reader oriented. Depends on: READ-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Accessibility 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. Highlighting rewrites innerHTML and removes links around matches. Keyboard users also cannot identify the current match. Acceptance criteria - Highlights preserve source text, links, and semantics. - Next/previous exposes index and total without rereading the chapter. - Clearing search restores normal reading at a sensible position. Implementation constraints - Treat queries as literal text and use structured ranges; never interpolate search text into HTML. Verification - Find a phrase spanning emphasis and follow the preserved link around a match. - Search markup-like text and a no-match query; nothing executes and match navigation is correctly disabled. Deliverables - Structured highlight layer and keyboard match-navigation tests Rollout and recovery: Enable for one renderer; disable highlighting separately while retaining plain results if semantics regress. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-104 — Keep contents links and footnote returns oriented **Bug · Medium priority · Intermediate** noCV practice brief v5 · READ-104 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep the reader oriented. Depends on: READ-101, READ-102. Difficulty: Intermediate. Estimated focused work: 105 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. Contents links scroll to sections but leave focus in the sidebar. Following a footnote returns to the document top. Acceptance criteria - Contents navigation updates the URL and focuses the destination heading without obscuring it. - Footnotes offer a named return action to the originating reference. - Back restores the preceding meaningful reading anchor. Implementation constraints - Use stable source IDs and respect reduced motion for scrolling. Verification - Navigate by contents, follow a footnote, and return using only the keyboard. - Open a missing section link and use Back; show a useful fallback without trapping focus. Deliverables - Anchor/focus coordinator and footnote walkthrough Rollout and recovery: Ship stable anchors before custom scrolling; disable scroll effects if focus and visual position diverge. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-105 — Recover bookmarks after a handbook correction **Story · High priority · Advanced** noCV practice brief v5 · READ-105 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep the reader oriented. Depends on: READ-103, READ-104. Difficulty: Advanced. 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. A correction inserts two sections before a bookmark. Its raw character offset now opens an unrelated paragraph. Acceptance criteria - Bookmarks include version, stable section, and optional bounded text anchor. - A newer version resolves the section or explicitly reports that the passage moved or disappeared. - The permitted original version remains reachable without silently rewriting the bookmark. Implementation constraints - Approximate text matching is not exact; disclose ambiguity and retain the original anchor. Verification - Insert content before a stable section and reopen its bookmark; the intended section remains selected. - Delete it and create two similar passages; show ambiguous recovery rather than silently choosing one. Deliverables - Version-aware bookmark resolver and correction fixtures Rollout and recovery: Keep legacy bookmarks readable during migration; fall back to the permitted original version on uncertain resolution. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. ### Support richer reading Add annotations and long-document loading without breaking reading flow. #### READ-106 — Render annotations safely and expose their controls **Bug · High priority · Advanced** noCV practice brief v5 · READ-106 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support richer reading. Depends on: READ-103, READ-104. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Accessibility 30% · Frontend 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. Pasted annotation markup changes layout and introduces active links. Annotation actions are unnamed icons visible only on hover. Acceptance criteria - Annotations use plain text or an explicit constrained format that removes disallowed content. - Edit, delete, and return-to-passage actions have accessible names and work without hover. - Failed saves preserve a draft distinct from confirmed comments. Implementation constraints - Keep document source immutable and treat annotation content as untrusted. Verification - Create a normal annotation and navigate every action by keyboard. - Paste script-like markup and a dangerous link, then reject save; no active content runs and the unsaved draft stays explicit. Deliverables - Safe annotation renderer and keyboard/security regression cases Rollout and recovery: Enable plain text first; disable rich formatting on sanitization regression while preserving stored source text. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-107 — Load long handbooks without losing reading order **Task · Medium priority · Advanced** noCV practice brief v5 · READ-107 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support richer reading. Depends on: READ-102, READ-104. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Accessibility 40% · Frontend 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 200-section handbook blocks interaction, but a virtual-list prototype removes headings while a screen reader navigates them. Acceptance criteria - Initial work is bounded through explicit section loading or an equally accessible documented strategy. - Loaded sections stay in logical order and focused content is never removed. - Section-load failure offers in-place retry without resetting the reading anchor. Implementation constraints - Profile a reproducible fixture and state the environment; do not optimize by hiding required accessible content. Verification - Profile initial load and navigate three loaded sections by keyboard and headings. - Fail the next request while focus stays in the current section; retry without duplicates, reordered headings, or focus loss. Deliverables - Incremental loading and before/after profile with reading-order checks Rollout and recovery: Enable for large documents; keep a full-document option when incremental reading is unsuitable. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-108 — Keep annotation review stable through collaborator updates **Story · Medium priority · Expert** noCV practice brief v5 · READ-108 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support richer reading. Depends on: READ-105, READ-106, READ-107. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Accessibility 30% · Real-time systems 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 colleague resolves a comment while another reader edits a reply. The panel reorders, steals focus, and sends the reply to the newly selected thread. Acceptance criteria - Editing binds to immutable thread identity and revision, not list position. - Remote updates never silently retarget a draft or move current focus. - Resolved/deleted-thread conflicts preserve the draft, announce once, and offer explicit permitted recovery. Implementation constraints - Use fixture events; a full collaboration backend and automatic merging are excluded. Verification - Insert a remote comment above the active thread while typing; the draft keeps its original thread. - Resolve the active thread during reply acknowledgement; no reply lands elsewhere and the confirmed state stays coherent. Deliverables - Revision-aware annotation model and concurrent-update tests Rollout and recovery: Pilot manual refresh before live events; pause remote panel updates if focus or binding becomes unstable. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. ### Verify access and recovery Check interruptions and document the release boundary. #### READ-109 — Handle access loss without an empty-reader trap **Bug · High priority · Advanced** noCV practice brief v5 · READ-109 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify access and recovery. Depends on: READ-107, READ-108. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Accessibility 30% · Frontend 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. Access expires while a reader is on a late section. The next fetch clears the page and leaves focus on a removed annotation button. Acceptance criteria - Confirmed access loss stops fetches and clears protected rendered content. - Focus moves to a named access-state heading with permitted navigation. - Account changes cannot restore prior content through cached sections or Back. Implementation constraints - Omit private authorization details and document account-scoped draft handling on access loss. Verification - Remove access during a section fetch and verify a useful accessible access state. - Switch account and navigate Back; protected cached content stays absent and stale fetches stop. Deliverables - Access-loss boundary and account-switch browser tests Rollout and recovery: Verify before enabling protected handbooks; disable protected caching if invalidation cannot be guaranteed. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-110 — Verify a complete reading-and-annotation session **Chore · Medium priority · Intermediate** noCV practice brief v5 · READ-110 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify access and recovery. Depends on: READ-105, READ-108, READ-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Quality 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. Component checks miss interactions among search, resizing, bookmarks, and drafts. Add a short reader acceptance script to the release checklist. Acceptance criteria - The script follows contents, changes text settings, searches, annotates, bookmarks, and reopens. - Keyboard-only and one documented screen-reader pass record observed limitations. - Version correction and denied annotation save are recovery branches. Implementation constraints - Record the environment and observations; automated checks do not establish complete accessibility. Verification - Run the ordinary synthetic session and verify final bookmark and annotation identities. - Reject saving and replace the version; the draft stays explicit and ambiguous bookmarks require resolution. Deliverables - Reader acceptance script and reproducible barrier notes Rollout and recovery: Use for navigation/annotation changes; pause the affected feature on identity loss or unrecoverable keyboard failure. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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.