# 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. ## BMONO — Monorepo change planner A fictional internal tools team maintains eighteen packages. Engineers currently run everything because the affected-package script occasionally misses downstream consumers. **Field:** Developer tooling. **Suggested stack:** TypeScript, pnpm, Git. **Engineer value:** Practice graph analysis, reproducible commands, and safe developer-tool failure modes. **Company value:** Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. **Delivery agreement:** Deliver a local planning CLI, regression fixtures, and an adoption note; hosted CI integration is optional. ### Setup prerequisites - Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. ### Map the inputs Define which repository changes affect which commands. #### BMONO-101 — Document task inputs beyond package dependencies **Task · Medium priority · Foundational** noCV practice brief v5 · BMONO-101 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map the inputs. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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. A root compiler change passed CI although an unchanged package no longer compiled. Inventory inputs the planner must treat as shared. Acceptance criteria - List compiler, lockfile, environment, and generator inputs separately. - Assign an owner and invalidation rule to each input. - Include one change that legitimately affects every package. Implementation constraints - Use the local fixture; do not inspect private repositories. Verification - Trace a package-only edit to its expected tasks. - Trace an unknown root input to conservative full selection. Deliverables - Input ownership matrix. Rollout and recovery: Review the matrix before enabling selection; retain full CI as fallback. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-102 — Parse workspace manifests without executing package scripts **Task · High priority · Intermediate** noCV practice brief v5 · BMONO-102 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map the inputs. Depends on: BMONO-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · Security 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 planner must inspect an unfamiliar checkout without triggering install hooks or repository commands. Acceptance criteria - Resolve workspace package names and paths from manifests. - Reject duplicate names and paths outside the checkout. - Report malformed JSON with file and safe location. Implementation constraints - Treat manifests as data; never evaluate imported configuration. Verification - Load valid nested workspace fixtures. - Reject traversal, duplicate identity, and invalid JSON fixtures. Deliverables - Manifest parser and fixture tests. Rollout and recovery: Use read-only inventory mode first; fall back to full CI on parser errors. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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 the planner Produce deterministic affected sets with conservative fallbacks. #### BMONO-103 — Handle cycles in the downstream impact graph **Bug · High priority · Advanced** noCV practice brief v5 · BMONO-103 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-102. Difficulty: Advanced. Estimated focused work: 210 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 shared packages depend on each other through development tooling, and recursive traversal never finishes. Acceptance criteria - Collapse or explicitly track cycles without dropping members. - Include transitive dependents once each. - Sort output stably regardless of manifest enumeration order. Implementation constraints - Distinguish runtime and development edges in the plan explanation. Verification - Resolve a diamond graph with one cycle. - Verify a disconnected package stays excluded and traversal terminates. Deliverables - Cycle-safe graph traversal. Rollout and recovery: Compare results with full package selection; disable selective mode if membership differs. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-104 — Resolve renamed and deleted files against both revisions **Bug · High priority · Advanced** noCV practice brief v5 · BMONO-104 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-102. Difficulty: Advanced. Estimated focused work: 180 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. A package deletion disappears from the current workspace map and incorrectly produces an empty plan. Acceptance criteria - Read changed paths from a declared base and head. - Account for both source and destination of renames. - Select former dependents when a package is removed. Implementation constraints - Do not assume a remote branch exists in a shallow checkout. Verification - Plan a package move with unchanged contents. - Exercise missing base and deleted-manifest cases with explicit fallback. Deliverables - Revision-aware path ownership logic. Rollout and recovery: Ship behind diagnostic output; preserve full CI for unresolved history. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-105 — Explain why each selected command is necessary **Story · Medium priority · Intermediate** noCV practice brief v5 · BMONO-105 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-103, BMONO-104. Difficulty: Intermediate. Estimated focused work: 120 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. Maintainers cannot review a large affected set because the tool prints only package names. Acceptance criteria - Attach at least one changed input to each selected task. - Represent transitive paths without unbounded recursion. - Emit stable JSON and readable plain-text output. Implementation constraints - Keep absolute workstation paths out of exported plans. Verification - Snapshot a direct and a transitive explanation. - Verify cyclic and missing-owner explanations remain bounded. Deliverables - Plan explanation renderer. Rollout and recovery: Enable explanation output immediately; keep command execution opt-in. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-106 — Make cache keys include generator versions and relevant environment **Bug · High priority · Advanced** noCV practice brief v5 · BMONO-106 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-101, BMONO-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · Storage systems 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. Generated client code changed after a tool upgrade while the cache reused an old successful result. Acceptance criteria - Hash declared inputs using stable ordering. - Include generator version and allowlisted environment names. - Exclude secrets and unrelated environment values from key material. Implementation constraints - A cache hit must never authorize skipping an undeclared dependency. Verification - Change each declared input and observe key changes. - Verify secret values are absent from keys and diagnostic output. Deliverables - Cache-key contract and regression checks. Rollout and recovery: Invalidate old keys on adoption; revert to uncached commands if key provenance is missing. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-107 — Detect stale plan execution after the worktree changes **Task · High priority · Intermediate** noCV practice brief v5 · BMONO-107 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-105, BMONO-106. Difficulty: Intermediate. 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. A developer reviews a plan, edits another package, then executes commands from the earlier plan. Acceptance criteria - Bind plans to revision and relevant working-tree digests. - Check the binding immediately before execution. - Return a distinct stale-plan error with regeneration guidance. Implementation constraints - Do not discard or reset local edits. Verification - Execute an unchanged reviewed plan successfully. - Modify a tracked input and reject the stale plan before spawning commands. Deliverables - Plan freshness guard. Rollout and recovery: Require freshness for execution; allow explicit regeneration without modifying the checkout. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. ### Adopt safely Compare selective runs against full runs before enforcement. #### BMONO-108 — Bound parallel commands and stop cleanly on cancellation **Task · Medium priority · Advanced** noCV practice brief v5 · BMONO-108 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Adopt safely. Depends on: BMONO-107. Difficulty: Advanced. Estimated focused work: 210 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. Selective tasks saturate a laptop and leave child processes alive when the parent command is interrupted. Acceptance criteria - Enforce configured parallelism between one and the fixture package count. - Stop scheduling new work after cancellation. - Report completed, failed, and cancelled tasks separately. Implementation constraints - Execute only trusted fixture commands in this exercise. Verification - Observe the concurrency ceiling with delayed fixtures. - Cancel mid-run and verify owned child processes terminate. Deliverables - Bounded command scheduler. Rollout and recovery: Default to conservative parallelism; provide serial mode for recovery. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-109 — Compare selective and full plans over a recorded change corpus **Task · High priority · Expert** noCV practice brief v5 · BMONO-109 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Adopt safely. Depends on: BMONO-103, BMONO-104, BMONO-106, BMONO-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Developer tooling 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. Before making selection mandatory, the team needs a defensible way to find false negatives rather than celebrate shorter CI runs. Acceptance criteria - Define a corpus covering root, package, rename, and deletion changes. - Compare selected task outcomes with full-run outcomes under identical inputs. - Block adoption on an unexplained excluded failure and record uncertainty. Implementation constraints - Report workload and machine limits; do not promise general speedups from local measurements. Verification - Detect an intentionally omitted shared input. - Show a safe exclusion and publish reproducible comparison commands. Deliverables - Adoption assessment and mismatch report. Rollout and recovery: Run in shadow mode for the corpus; retain a one-command full-run override. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-110 — Write a maintainer playbook for adding a new task input **Chore · Low priority · Foundational** noCV practice brief v5 · BMONO-110 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Adopt safely. Depends on: BMONO-109. Difficulty: Foundational. Estimated focused work: 60 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. New generators will appear after launch, and ownership of the invalidation map is currently undocumented. Acceptance criteria - Show how to declare one generator input and its owner. - Include the regression case required before selective execution. - Document diagnosis of unexpected full and empty plans. Implementation constraints - Use examples from the implemented planner rather than future capabilities. Verification - Follow the guide to add a synthetic generator input. - Verify omission is detected by the comparison procedure. Deliverables - Maintainer guide with worked example. Rollout and recovery: Link the guide from CLI help; withdraw selective defaults if ownership becomes unclear. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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.