# 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. ## PWEB — Make a large scheduling screen respond to the next click A fictional repair coordinator opens a week containing 2,000 jobs. The initial page loads, but filtering and selecting a job can freeze the interface. Build a synthetic scheduling screen with keyboard operation before measuring changes. **Field:** Performance engineering. **Suggested stack:** TypeScript, React, CSS Modules, Playwright, Browser Performance API. **Engineer value:** Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. **Company value:** Produce a bounded performance investigation and regression workflow for dense operational interfaces. **Delivery agreement:** Ten tickets across measurement, implementation and regression phases. Lab timings apply only to the documented local browser setup; field-user performance is not inferred. ### Setup prerequisites - Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. - Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. ### Capture the slow interactions Record repeatable navigation and interaction traces with correct results. #### PWEB-101 — Record the schedule workflow that freezes after filtering **Task · Medium priority · Foundational** noCV practice brief v5 · PWEB-101 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the slow interactions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Quality engineering 30% · 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. The issue report says the screen feels slow. Developers reproduce it with different data and disagree about which interaction is responsible. Acceptance criteria - Define a deterministic sequence: load 2,000 jobs, filter by technician, select the final visible job and clear the filter. - Record build mode, browser version, viewport and any throttling alongside trace timestamps. - Assert the selected job and final result count so an incomplete interaction cannot appear fast. Implementation constraints - Use only synthetic names and job descriptions; record navigation and interaction phases separately. Verification - Replay the sequence twice and confirm identical selected IDs and result counts. - Run with an empty technician result and verify the sequence reports that expected state rather than timing an absent control. Deliverables - Browser workflow fixture and annotated baseline trace Rollout and recovery: Keep the baseline workflow versioned before changing the page; fixture changes invalidate direct timing comparisons. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-102 — Identify which schedule code is shipped before the first interaction **Task · Medium priority · Foundational** noCV practice brief v5 · PWEB-102 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the slow interactions. Depends on: PWEB-101. Difficulty: Foundational. Estimated focused work: 90 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. The screen downloads export and map code before the user opens either feature. The team needs sizes and dependency paths before splitting bundles. Acceptance criteria - Report transferred and parsed script sizes for the production build with cache state recorded. - Identify the dependency paths for export and map features and their actual use in the baseline workflow. - Separate first-load transfers from subsequent navigation and avoid adding compressed sizes to uncompressed sizes. Implementation constraints - Use local build artifacts and browser network records; do not compare development bundles with production output. Verification - Capture cold-cache and warm-cache navigation separately. - Open the export and map features after baseline load and verify which additional resources are requested. Deliverables - Bundle inventory and a justified split proposal Rollout and recovery: This ticket changes no loading behavior; preserve the measured build identifier for the implementation comparison. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-103 — Measure long tasks caused by filtering rather than counting renders alone **Story · Medium priority · Intermediate** noCV practice brief v5 · PWEB-103 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the slow interactions. Depends on: PWEB-101. Difficulty: Intermediate. Estimated focused work: 120 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. A render counter improved after memoization, but typing still stalls because sorting and formatting happen before React commits. Acceptance criteria - Record input-event start, result commit and long-task observations around the filter workflow. - Attribute measured time to filtering, sorting, rendering and layout where supported; label gaps as unknown. - Keep measurements bounded and remove observers when the screen is left. Implementation constraints - A lab interaction duration is not a claim about field Core Web Vitals; name the measured boundary explicitly. Verification - Inject a known synchronous filter delay and verify it appears in the recorded interaction. - Navigate away and back repeatedly and confirm only one active observer set remains. Deliverables - Interaction measurement helper and trace interpretation notes Rollout and recovery: Enable the helper only for the local profiling build; detach it without changing application behavior. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. ### Reduce avoidable browser work Change loading and rendering paths while preserving navigation and assistive-technology behavior. #### PWEB-104 — Load the schedule export code when export is requested **Story · Medium priority · Intermediate** noCV practice brief v5 · PWEB-104 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Performance engineering 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. The spreadsheet export dependency adds work to every schedule visit even though the baseline user never exports. Acceptance criteria - Move export-only code behind an explicit load boundary and preserve the generated file contents. - Show a keyboard-accessible loading state and prevent duplicate export starts while the module loads. - Handle module-load failure with a retry action without losing selected filters. Implementation constraints - Compare initial transfer and parse work in the same production build configuration; do not defer code required to display the schedule. Verification - Verify the initial workflow makes no export-module request, then trigger export and compare the file with the baseline fixture. - Fail the module request once and confirm retry succeeds with the original filter state. Deliverables - Deferred export implementation, network comparison and failure regression Rollout and recovery: Keep a loading-boundary switch in the exercise; revert to eager loading if export compatibility fails. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-105 — Render only the visible schedule rows without losing keyboard position **Story · High priority · Advanced** noCV practice brief v5 · PWEB-105 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-101, PWEB-103. Difficulty: Advanced. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Frontend 30% · 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. Every filter mounts hundreds of offscreen job rows. A first virtualization attempt is faster but drops focus when the selected row scrolls away. Acceptance criteria - Bound mounted rows by viewport and overscan while retaining stable job identity. - Define and implement keyboard movement, focus restoration and accessible row position information. - Support long wrapped labels and the empty state without overlapping rows or selecting a different job after filtering. Implementation constraints - Document the chosen virtualization semantics and test with zoom and a narrow viewport; do not hide all nonvisible records from search without an explicit alternative. Verification - Traverse beyond the initial viewport with the keyboard, filter the selected row out and verify the declared focus behavior. - Measure mounted nodes and interaction duration at 200 and 2,000 jobs while checking the selected job ID. Deliverables - Bounded row rendering, accessibility checks and before/after traces Rollout and recovery: Gate virtualization independently; reverting renders the full list while preserving selected IDs and filter state. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-106 — Reuse formatted job data only while its inputs remain unchanged **Bug · Medium priority · Advanced** noCV practice brief v5 · PWEB-106 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-103. Difficulty: Advanced. Estimated focused work: 180 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. Date and duration formatting dominates repeated filters. A broad memoization patch reuses labels after the schedule time zone changes. Acceptance criteria - Cache or precompute expensive formatting with all relevant inputs, including locale and time zone, in the invalidation rule. - Bound retained derived data and remove entries for jobs no longer present. - Keep visible labels identical to the uncached formatter across updates and daylight-saving boundary fixtures. Implementation constraints - Measure formatting calls and interaction time together; memoization alone is not evidence of a useful improvement. Verification - Change the time zone and job start time independently, comparing every visible label with the baseline formatter. - Replace the dataset repeatedly and check that retained derived entries stay within the declared bound. Deliverables - Derived-data cache, invalidation regressions and profiling comparison Rollout and recovery: Disable derived-data reuse through one path if stale labels appear; the original formatter remains the reference behavior. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-107 — Let a new filter supersede expensive work already in progress **Story · High priority · Expert** noCV practice brief v5 · PWEB-107 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-101, PWEB-103, PWEB-105. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. Fast typing schedules several expensive filter computations. Results from an earlier query briefly replace the latest selection and consume time after they are irrelevant. Acceptance criteria - Choose a bounded scheduling or worker strategy and explain why it fits the measured bottleneck. - Publish results only for the current dataset and query revision; discard superseded work safely. - Preserve responsive keyboard input and a clear pending state without moving focus or showing stale result counts. Implementation constraints - If using a worker, include transfer/serialization cost in the comparison and terminate it when the screen unmounts. Verification - Complete an older query after a newer query and verify only current results appear. - Type and clear rapidly while replacing the dataset, then inspect responsiveness, final IDs and worker or task cleanup. - Repeat baseline and selected-strategy runs three times under the same recorded browser workload; compare input-latency distributions and long-task counts, including worker transfer and serialization overhead when applicable. Deliverables - Scheduling decision, implementation and out-of-order completion tests Rollout and recovery: Canary the alternate filter path locally; reverting cancels its work and restores synchronous filtering with the same query state. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. ### Guard responsiveness Cover memory, interrupted work and regression budgets in a repeatable browser check. #### PWEB-108 — Find retained job rows after repeated schedule navigation **Bug · High priority · Advanced** noCV practice brief v5 · PWEB-108 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard responsiveness. Depends on: PWEB-105, PWEB-107. 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. The screen starts responsive and degrades after operators open and close it throughout a shift. Detached rows remain reachable through subscriptions. Acceptance criteria - Identify a reproducible retention path using repeated mount, interaction and unmount cycles. - Release listeners, workers and subscriptions owned by the screen without cancelling shared application resources. - Define a post-cleanup retained-object bound on the declared browser and distinguish temporary allocation from a leak. Implementation constraints - Use heap snapshots and retaining paths; do not claim a leak from one process-memory sample. Verification - Run 20 navigation cycles and inspect retained job objects after the same cleanup procedure at each checkpoint. - Navigate away during a pending filter and verify no late update, leaked listener or unhandled exception. Deliverables - Retention diagnosis, lifecycle fix and repeatable memory check Rollout and recovery: Revert only the offending optimization if cleanup cannot be demonstrated; keep the regression cycle in the local suite. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-109 — Make the schedule performance run include slow devices and empty results **Chore · Medium priority · Intermediate** noCV practice brief v5 · PWEB-109 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard responsiveness. Depends on: PWEB-101, PWEB-104, PWEB-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Performance engineering 30% · 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. The fastest desktop run became the benchmark. It misses the narrow layout and empty-filter transition used by coordinators on older laptops. Acceptance criteria - Define two repeatable local profiles with explicit viewport, throttling and cache state. - Run nonempty, empty and large-label workflows and assert visual state plus selected identity. - Separate trace artifacts by profile and build revision; invalid runs report failure instead of a zero timing. Implementation constraints - Emulation defines an exercise profile, not a claim to reproduce every physical device. Verification - Execute both profiles three times with a fixed warmup rule and retain all measurements. - Remove a required result element deliberately and confirm the run fails its correctness check before reporting success. Deliverables - Browser profile matrix and repeatable benchmark command Rollout and recovery: Use both profiles in local release review; revise profiles only with a recorded reason and a new baseline. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-110 — Approve schedule optimizations only when the measured interaction improves **Task · High priority · Expert** noCV practice brief v5 · PWEB-110 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard responsiveness. Depends on: PWEB-104, PWEB-105, PWEB-106, PWEB-107, PWEB-108, PWEB-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Quality engineering 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. Several changes reduced different counters. The team needs a release decision tied to the actual filter-and-select workflow and its accessibility contract. Acceptance criteria - Compare three paired runs per declared profile and require at least 20% lower median filter-to-result duration on the constrained profile. - Require unchanged selected IDs, keyboard behavior and empty-state behavior, with no increase beyond 10% in initial transferred script bytes. - Report all timings, spread, retained-object observations and inconclusive results; document which changes are included and why. Implementation constraints - The numerical budgets apply only to this fixture and lab profile. Preserve raw traces so reviewers can assess attribution and noise. Verification - Run the complete workflow against baseline and candidate in alternating order. - Revert the combined candidate and verify both functional behavior and measured baseline recovery under the same profiles. Deliverables - Release decision, paired trace bundle and rollback rehearsal Rollout and recovery: Promote the chosen combination only after the exercise gates pass; keep each optimization independently reversible where state compatibility permits. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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.