# 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. ## CLI — Release day without the shared spreadsheet A team maintains six related packages. Release notes, version changes, and tags are copied between a spreadsheet and a terminal; a failed upload recently left two packages ahead of their dependents. The exercise uses temporary repositories and a fake registry. **Field:** Developer tooling. **Suggested stack:** TypeScript, Node.js, Git, pnpm. **Engineer value:** Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. **Company value:** Review how an engineer makes release changes inspectable and recoverable before they affect consumers. **Delivery agreement:** A release-plan CLI, local fixtures, recovery tests, and an operator guide. ### Setup prerequisites - Create a temporary Git repository with three related fixture packages. - Use a local registry double; no publishing credentials are required. ### Know what will change Produce a deterministic release plan from repository inputs. #### CLI-101 — Print package versions without depending on the current directory **Task · Medium priority · Foundational** noCV practice brief v5 · CLI-101 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what will change. 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. The release coordinator runs the command from packages/ui and gets an empty package list. Add an inspect command that finds the workspace root and reports each releasable package. Acceptance criteria - Running from the root or a nested package produces the same sorted names and versions. - Private packages are labeled and excluded from the releasable count. - A directory outside a workspace returns a nonzero exit code and an actionable error. Implementation constraints - Read manifests as data; do not run package scripts. - Stop root discovery at the filesystem root. Verification - Run inspect from root, a nested directory, and a path containing spaces. - Pass malformed package JSON and verify that the filename appears without dumping file contents. Deliverables - Inspect subcommand and a three-package fixture Rollout and recovery: Ship as a read-only command first; revert the command registration if root detection regresses. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. #### CLI-102 — Give scripts a stable JSON output contract **Story · Medium priority · Foundational** noCV practice brief v5 · CLI-102 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what will change. Depends on: CLI-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · API design 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. CI currently scrapes a colored table and breaks when a package name wraps. Add --json to inspect so automation can consume a versioned response. Acceptance criteria - JSON output includes schemaVersion, workspace packages, and warnings with stable field names. - Stdout contains exactly one JSON document with no ANSI escapes. - Diagnostics go to stderr and invalid arguments keep a documented nonzero exit code. Implementation constraints - Keep human rendering separate from the result model. Verification - Parse stdout from a successful --json run with JSON.parse. - Combine --json with an unknown flag and assert no partial success document is printed. Deliverables - JSON response schema and CLI exit-code reference Rollout and recovery: Add the opt-in format without changing existing human output; version incompatible schema changes. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. #### CLI-103 — Include dependent packages in the proposed version bump **Story · High priority · Advanced** noCV practice brief v5 · CLI-103 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what will change. Depends on: CLI-101. 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 patch to @fixture/parser requires updating the exact dependency in @fixture/runner. The plan currently includes only parser, leaving runner pinned to the old release. Acceptance criteria - The plan includes transitive dependents whose declared ranges no longer accept the proposed version. - Packages already accepting the new version are not bumped solely because they depend on it. - Cycles are reported with a readable cycle path and no files are written. Implementation constraints - Declare supported workspace range syntax and reject unsupported protocols. - Use a stable topological order with package-name tie breaking. Verification - Plan a chain with exact, compatible-range, and dev-only dependencies and compare expected inclusion. - Feed a dependency cycle and a missing workspace target; both must fail before preparation. Deliverables - Dependency-aware planner and graph fixtures Rollout and recovery: Expose the graph as plan output before enabling its use in file preparation; rollback to read-only inspection. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. ### Prepare a reviewable release Write only the planned files and make failure recovery explicit. #### CLI-104 — Make a dirty checkout a deliberate release decision **Bug · High priority · Intermediate** noCV practice brief v5 · CLI-104 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a reviewable release. Depends on: CLI-103. Difficulty: Intermediate. Estimated focused work: 90 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 teammate prepared a release with an uncommitted dependency change and could not reproduce the resulting versions. Capture the base revision and refuse preparation when tracked files differ. Acceptance criteria - The plan records the full base commit and a digest of release inputs. - Preparation rejects staged or unstaged tracked changes with a list of affected paths. - A plan whose base commit or input digest changed is rejected even when the checkout is clean. Implementation constraints - Use Git argument arrays rather than composing shell commands. - Document whether untracked files participate in the release input set. Verification - Prepare a clean fixture checkout successfully. - Stage one manifest change and separately advance HEAD; the old plan must be rejected in each case. Deliverables - Stale-plan guard and reproducibility note Rollout and recovery: Enable guards before any write command; disable preparation if repository state cannot be determined. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. #### CLI-105 — Turn change fragments into package-specific release notes **Task · Medium priority · Intermediate** noCV practice brief v5 · CLI-105 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a reviewable release. Depends on: CLI-103. 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. The same release note is pasted into all six packages, even when only one changed. Read small checked-in change fragments and render notes grouped by affected package. Acceptance criteria - Each fragment names existing packages and one supported change category. - Rendering is deterministic and includes each fragment once per affected package. - Unknown packages, duplicate fragment IDs, and empty descriptions block generation with file-level errors. Implementation constraints - Treat fragment text as plain Markdown content, never executable templates. - Preserve issue references exactly as supplied. Verification - Render two overlapping fragments and check package-specific sections. - Use duplicate IDs and an unknown package to verify the entire notes step fails without writing output. Deliverables - Fragment format, examples, and release-note renderer Rollout and recovery: Generate notes to a preview path initially; switching to committed notes requires the validated plan. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. #### CLI-106 — Prepare manifests and notes as one recoverable file operation **Story · High priority · Advanced** noCV practice brief v5 · CLI-106 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a reviewable release. Depends on: CLI-104, CLI-105. Difficulty: Advanced. Estimated focused work: 180 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. An interrupted process updated two manifests but left the changelog untouched. Preparation needs a journal so the next invocation can identify exactly which planned writes completed. Acceptance criteria - Validate every target and render every new file before replacing any repository file. - A journal records expected before and after hashes for each target and completed replacements. - Recovery restores only files still matching the recorded after hash and refuses to overwrite user edits. Implementation constraints - Keep staging and target files on the same filesystem. - Resolve paths inside the selected repository and reject symlink escapes. Verification - Inject failure after the first replacement and recover the original bytes. - Edit a prepared file before recovery and confirm a conflict is reported while the edit is preserved. Deliverables - Preparation journal, recovery command, and failure-injection fixtures Rollout and recovery: Enable writes only after preview and recovery pass locally; use the journal to undo an interrupted preparation. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. ### Handle an interrupted release Resume against a fake registry without duplicating or concealing work. #### CLI-107 — Prevent a second release process from using the same checkout **Bug · High priority · Advanced** noCV practice brief v5 · CLI-107 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-106. Difficulty: Advanced. 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. Two terminals started preparation within a second and both used the same temporary filenames. Add an exclusive lease for mutation commands with inspectable ownership. Acceptance criteria - Exactly one of two concurrent preparation commands obtains the repository lease. - The loser exits before replacing a file and reports the existing operation ID. - Stale-lease recovery is an explicit command that verifies the recorded operation is no longer active. Implementation constraints - Do not decide lease ownership from a PID alone; include an operation token. - Read-only commands remain usable while a lease exists. Verification - Start two local fixture processes behind a barrier and count successful mutations. - Simulate a stale lease and verify ordinary preparation refuses it until explicit recovery. Deliverables - Lease implementation and concurrent-process test Rollout and recovery: Require leases for all mutation commands together; rollback by disabling mutations until both versions agree on the lease format. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. #### CLI-108 — Resume a publish rehearsal after the registry response disappears **Story · High priority · Expert** noCV practice brief v5 · CLI-108 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-106, CLI-107. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Distributed systems 30% · Integrations 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 fake registry accepts a package and then drops the connection. A blind retry may conceal a different artifact already registered at that version. Reconcile remote state before resuming. Acceptance criteria - Each planned package records its version and artifact digest before the fake publish call. - An existing version with the same digest is treated as completed; a different digest blocks the entire resume. - Resume respects dependency order and leaves a durable record of ambiguous, reconciled, and completed steps. Implementation constraints - Use a local registry port with deterministic lost-response behavior. - A release record is append-only; do not overwrite the original failed attempt. Verification - Drop the first response after acceptance and verify resume makes no duplicate upload. - Preload the same version with different bytes and confirm dependents remain unpublished. Deliverables - Resumable rehearsal workflow and ambiguity incident walkthrough Rollout and recovery: Keep the registry adapter local for this exercise; require a reviewed digest reconciliation policy before a real adapter. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. #### CLI-109 — Keep release credentials and package contents out of logs **Chore · High priority · Intermediate** noCV practice brief v5 · CLI-109 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-102, CLI-108. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Security 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. A registry error included an authorization header in a debug dump. Add structured diagnostics with an allowlist of safe release fields and a useful correlation ID. Acceptance criteria - Diagnostics include operation ID, package name, step, duration, and error category. - Headers, environment variables, artifact contents, and token-like fixture values are absent from all log levels. - Human and JSON errors reference the same operation ID. Implementation constraints - Map provider failures to safe errors at the adapter boundary. - Do not rely only on replacing known secret strings. Verification - Cause a fake provider error containing a token and scan stdout, stderr, and persisted diagnostics. - Confirm a safe package conflict still carries enough information to locate the failed step. Deliverables - Safe error mapper and redaction regression cases Rollout and recovery: Make safe diagnostics the default; temporarily reduce diagnostic detail if an unknown provider error cannot be classified. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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. #### CLI-110 — Package the CLI so a fresh checkout can rehearse a release offline **Task · Medium priority · Intermediate** noCV practice brief v5 · CLI-110 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-108, CLI-109. 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. The maintainer can run the tool only through a source-tree import. Package the command and document one complete rehearsal using fixture packages and the local registry. Acceptance criteria - The built executable supports --help and --version without source imports. - An offline rehearsal covers inspect, plan, prepare, interrupted publish, and resume. - The guide explains which steps mutate files and how to restore the fixture repository. Implementation constraints - Pin fixture inputs so example output is reproducible. - Do not perform an actual registry publication. Verification - Install the packed artifact into a temporary directory and run the documented rehearsal. - Run without a registry configuration and confirm publishing fails before any network attempt. Deliverables - Packed CLI artifact instructions and end-to-end rehearsal guide Rollout and recovery: Distribute a prerelease artifact for local evaluation; retract it if packed-command behavior differs from source execution. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect 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.