# 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. ## BUILD — Make the monorepo feedback loop trustworthy A product team waits for every package to rebuild after small changes. An experimental cache is faster but occasionally returns success after a shared type changed. Build a small, auditable task runner around fixture packages. **Field:** Developer tooling. **Suggested stack:** TypeScript, Node.js, pnpm, JSON. **Engineer value:** Practice incremental computation, dependency scheduling, cache correctness, and cancellation. **Company value:** Inspect whether faster checks preserve the guarantees reviewers depend on. **Delivery agreement:** A dependency-aware check runner with a local cache and reproducible benchmark report. ### Setup prerequisites - Prepare four fixture packages with one shared library and two applications. - Use only trusted fixture commands in local tests. ### Model checks and dependencies Make task selection and scheduling predictable. #### BUILD-101 — Reject invalid task configuration before starting a command **Task · Medium priority · Foundational** noCV practice brief v5 · BUILD-101 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model checks and dependencies. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · Security 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A misspelled dependsOn entry silently removed a typecheck prerequisite. Introduce a validated task configuration with clear locations for configuration errors. Acceptance criteria - Every task has a unique ID, command argument list, working directory, and declared dependencies. - Unknown dependencies and paths outside the workspace fail validation. - Validation reports all independent configuration errors without starting commands. Implementation constraints - Commands are trusted fixture configuration; no shell interpolation. - Keep configuration parsing independent of execution. Verification - Validate a four-task graph successfully. - Submit a missing dependency and escaping working directory together and confirm both errors and zero process starts. Deliverables - Configuration schema and validation diagnostics Rollout and recovery: Use validation in a read-only plan command first; refuse execution for older unsupported config versions. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-102 — Show why a task is selected after a file change **Story · Medium priority · Intermediate** noCV practice brief v5 · BUILD-102 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model checks and dependencies. Depends on: BUILD-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. Changing packages/shared/types.ts reruns one app but not its sibling. Build a changed-file planner that includes affected dependents and prints the reason for each selected task. Acceptance criteria - Changes under a shared package select all configured downstream checks. - A root configuration change selects the documented full validation set. - Deleted files and renamed files are handled using both old and new affected paths. Implementation constraints - Sort explanation paths for reproducible output. Verification - Change shared types and inspect both application check reasons. - Delete a file from one leaf package and confirm unrelated leaf tasks remain unselected. Deliverables - Affected-task planner and explanation output Rollout and recovery: Compare selection with full checks in report-only mode before using it to skip work. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-103 — Schedule independent checks without exceeding the worker limit **Story · High priority · Advanced** noCV practice brief v5 · BUILD-103 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model checks and dependencies. Depends on: BUILD-101. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. Two independent application tests could run together, but shared compilation must finish first. Add bounded scheduling and explicit blocked states for dependent tasks. Acceptance criteria - A task starts only after every prerequisite succeeds. - Active process count never exceeds the configured positive concurrency limit. - A failed prerequisite marks descendants blocked while unrelated tasks may finish. Implementation constraints - Detect cycles before execution and return the cycle path. - Store task transitions through one scheduler boundary. Verification - Run a diamond graph with barrier-controlled fixture tasks and assert start order and concurrency. - Fail the shared task and verify descendants never start while an independent task completes. Deliverables - Bounded scheduler and graph execution trace Rollout and recovery: Default concurrency to one; increase only after the scheduling trace demonstrates the limit. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. ### Cache only valid results Prove when outputs may safely be reused. #### BUILD-104 — Include tool versions and declared environment in the cache key **Bug · High priority · Advanced** noCV practice brief v5 · BUILD-104 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cache only valid results. Depends on: BUILD-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · Storage 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. The cache reused a successful check after the TypeScript version changed. Define a canonical cache key that captures the command, inputs, dependency results, and supported environment. Acceptance criteria - Changing input bytes, lockfile, command arguments, tool version, or a declared environment value changes the key. - File enumeration order and path separators do not change an otherwise equivalent key. - Undeclared environment dependence is documented as unsupported and such tasks can disable caching. Implementation constraints - Hash values rather than logging environment contents. - Use content hashes, not modification times, as input identity. Verification - Reorder file enumeration and assert the key is unchanged. - Change each declared input dimension independently and assert a cache miss. Deliverables - Cache-key specification and canonicalization tests Rollout and recovery: Version the cache namespace and discard entries produced by the old key algorithm. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-105 — Restore cached outputs without touching unrelated files **Story · High priority · Expert** noCV practice brief v5 · BUILD-105 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cache only valid results. Depends on: BUILD-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Developer tooling 30% · Storage 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 cached archive restored ../config.json during a local corruption test. Replace blind extraction with a validated manifest and staged restoration inside declared output roots. Acceptance criteria - Every restored file has a normalized in-root path and verified content digest. - Absolute paths, traversal paths, symlink escapes, and unexpected output entries are rejected. - A rejected or interrupted restoration preserves the prior output set and reports a cache miss. Implementation constraints - Treat cache entries as untrusted even when the cache is local. - Separate verification from replacement and avoid executing archive hooks. Verification - Restore a valid two-directory output manifest and compare every digest. - Use traversal, digest mismatch, and interrupted replacement fixtures and verify unrelated files are unchanged. Deliverables - Validated cache restorer and corruption fixtures Rollout and recovery: Enable restoration behind an opt-in flag; on any integrity error rebuild from source and quarantine that cache entry. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-106 — Never cache failed or incompletely written task outputs **Bug · High priority · Intermediate** noCV practice brief v5 · BUILD-106 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cache only valid results. Depends on: BUILD-103, BUILD-104. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Storage systems 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A killed build left an output directory that the next run accepted as a hit. Publish a cache entry only after successful exit and complete output hashing. Acceptance criteria - Nonzero exit, cancellation, and missing declared outputs never create reusable entries. - Entries become visible through one final commit marker after all files and metadata are written. - Concurrent identical writers either publish equivalent complete entries or report an integrity conflict. Implementation constraints - Use a unique staging directory per attempt. Verification - Kill a fixture build after it creates one output and assert the next run executes it again. - Race two successful writes for one key and verify readers observe only complete entries. Deliverables - Atomic cache publisher and partial-output test Rollout and recovery: Invalidate legacy entries without a completion marker; keep cache misses safe by running the original task. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. ### Make the runner usable in CI Control resources and report failures without hiding them. #### BUILD-107 — Cancel running checks and report what did not run **Story · Medium priority · Advanced** noCV practice brief v5 · BUILD-107 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-103. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. Pressing Ctrl+C stops the runner but leaves a test child consuming CPU. Add cancellation with a bounded grace period and explicit cancelled outcomes. Acceptance criteria - Cancellation stops new starts immediately and requests termination of every owned process tree. - After the configured grace period remaining owned processes are forcefully terminated using supported platform behavior. - The summary distinguishes failed, cancelled, blocked, and completed tasks and returns a nonzero exit. Implementation constraints - Exercise only controlled fixture child processes. - Do not terminate processes outside the operation ownership set. Verification - Cancel a parent fixture that owns a long-lived child and confirm both are gone. - Cancel while one independent task has completed and verify its successful result remains in the summary. Deliverables - Cancellation handler and process-cleanup test Rollout and recovery: Enable cancellation together with process ownership tracking; retain the serial execution fallback if cleanup fails on a supported OS. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-108 — Keep parallel task output readable and bounded **Task · Medium priority · Foundational** noCV practice brief v5 · BUILD-108 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-103. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. Concurrent test logs interleave half-lines and a noisy task consumes hundreds of megabytes of memory. Prefix complete lines and cap retained output per task. Acceptance criteria - Every rendered line carries its task ID without splitting UTF-8 characters. - Retained output per task stays below a configured byte limit with a visible truncation notice. - The final summary includes exit code, duration, and an indication that output was truncated. Implementation constraints - Handle a final line that has no newline. - Keep stderr attribution separate from status. Verification - Emit split multibyte characters from two fixture processes and check rendered text. - Write beyond the limit and verify bounded retention and a single clear truncation notice. Deliverables - Streaming output formatter and noisy-task fixture Rollout and recovery: Use bounded capture by default and document an explicit file-output option for deeper local debugging. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-109 — Explain a cache miss without exposing input contents **Story · Low priority · Intermediate** noCV practice brief v5 · BUILD-109 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-104, BUILD-106. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · Privacy engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The team cannot tell whether frequent misses come from the lockfile or an unstable generated file. Add an explain command comparing safe input metadata from two runs. Acceptance criteria - Explanation identifies added, removed, or changed input paths and changed key categories. - File contents and environment values are never printed. - A missing prior run produces a useful first-run result instead of an error. Implementation constraints - Retain hashes and category names only for environment-sensitive inputs. Verification - Change a source file and a tool version and assert both reasons appear. - Place a secret fixture value in a declared environment variable and confirm no output includes it. Deliverables - Cache-miss explanation command and safe metadata format Rollout and recovery: Make explanation read-only; deleting history must not alter cache correctness. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-110 — Measure the faster loop against a full-check baseline **Task · Medium priority · Intermediate** noCV practice brief v5 · BUILD-110 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-105, BUILD-106, BUILD-107, BUILD-108, BUILD-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Developer tooling 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. A timing screenshot says the cache is faster but omits cases where it skipped a required check. Produce a reproducible comparison covering clean, warm, leaf-change, and shared-change runs. Acceptance criteria - The report records machine context, fixture revision, task counts, cache hits, and wall-clock timings. - Each incremental result is compared with the full-check result for the same input state. - A deliberate shared-type error fails both workflows and is never reported as a valid cache hit. Implementation constraints - Present measured numbers with run count and variability. - Avoid a hard speed claim based on one run. Verification - Run the documented matrix from an empty cache and reproduce task selection. - Introduce a dependent type error and confirm the benchmark records failed correctness before reporting speed. Deliverables - Benchmark script and correctness-first comparison report Rollout and recovery: Adopt skipped-task execution only after parity is demonstrated; retain a scheduled full-check path as a diagnostic baseline. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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.