TASK-IMP-134: End-to-end regression for the cs/memory/cuo rename

Summary

Prove the combined result of TASK-IMP-130/131/132 — the renamed cs bin with memory and cuo both added to the same dispatch table — works as an integrated whole via an offline, in-repo test, and separately checklist the genuinely network/Homebrew-dependent "clean machine" portion the plan describes, which cannot run in this repo's CI.

Problem

TASK-IMP-130, 131, and 132 each have their own acceptance criteria proving their own change in isolation. None of them proves the three changes compose correctly once all land — in particular, TASK-IMP-131 and TASK-IMP-132 both edit the same cli.mjs dispatch table object and were flagged in their own specs as having a sibling merge-conflict risk (each depends only on TASK-IMP-130, not on each other, so nothing stops them being authored/implemented in parallel). An e2e test that builds the payload fresh after all four tasks land and exercises cs install, cs memory, and cs cuo together in one process is the only check that would catch a dispatch-table integration break that per-task unit tests would miss.

Separately, the plan's own item 7 describes a "clean machine" regression involving a real Homebrew install and a real npm release — this repo's only existing e2e precedent, test_e2e_skeleton.sh, is explicit that it runs "with NO model, NO network, NO credentials." The plan's literal ask does not fit that convention, and TASK-IMP-133's own audit (ISS-005) already found that no task in this batch actually covers cutting the release this regression would need. Presenting a network-dependent AC as if this repo's CI could run it would be the same class of fabricated-citation defect TASK-IMP-133's audit found and fixed.

Proposed Solution

Two halves, not one:

Offline integration test (this task's own automatable deliverable). A new test, tools/install/tests/test_cs_rename_e2e.sh, following test_e2e_skeleton.sh's established shape (build from source into a scratch dir, no network) that builds a scratch payload after TASK-IMP-130/131/132's changes are present, then in one continuous run: confirms the generated package.json's bin is cs (not cyberos); confirms cs -h's usage text lists memory and cuo alongside install/uninstall/version/status/create/gates/mcp/help; confirms cs memory <cmd> and cs cuo <name> both dispatch correctly using the same stub techniques TASK-IMP-131/132's own tests established, run back-to-back against the SAME built payload (proving the combined SCRIPTS-table object is well-formed, not just each entry individually reachable).
Manual release-time checklist (not an automated AC). A short checklist, recorded in this task's own body rather than as a testable AC, for whoever performs the actual release: install the released cs via the updated Homebrew formula (TASK-IMP-133) on a real machine, confirm cyberos (bare) resolves only to a locally pip-installed cyberos-memory if present (no competing public-CLI claim on that name), and confirm cs memory <cmd> reaches the same store. This half is explicitly NOT gated by this task's own ready_to_implement → done transition, since it cannot happen until a real release exists (the same operational gap TASK-IMP-133's audit named).

Alternatives Considered

Author a single AC requiring a real Homebrew install on a clean VM, matching the plan's literal wording. Rejected: this repo's CI has no such capability and no prior task in this codebase (including test_e2e_skeleton.sh, the closest precedent) does this — authoring an AC nothing can mechanically satisfy would be the same fabricated-test-authority problem TASK-IMP-133's audit caught and fixed, repeated here.
Skip the offline portion entirely and treat this task as pure documentation/checklist. Rejected: the dispatch-table integration risk (TASK-IMP-131/132's sibling merge-conflict flag) is real and IS testable offline today; dropping it would leave the one distinctly valuable, achievable check this task can add unbuilt.
Fold this task's offline portion into TASK-IMP-131 or 132 individually instead of a separate task. Rejected: neither of those tasks' own scope is "prove the combination of both plus 130 works together" — that is inherently a task that can only exist once all three have landed, matching the plan's own dependency ordering (item 7 listed last, after items 1-6).

Success Metrics

Primary: bash tools/install/tests/test_cs_rename_e2e.sh passes in CI, offline, after TASK-IMP-130/131/132 land. Baseline today: no such test exists, and none of the three per-task test suites runs all three verbs against one shared built payload in sequence.
Guardrail: the manual release-time checklist (this task's §3 edge cases / body text) is followed at least once before the release containing TASK-IMP-130's own CHANGELOG rename entry (clause 1.6 of that task) is tagged and published - a concrete, checkable trigger event rather than a subjective "announced as complete" - tracked as a release-process step, not as this task's own done criterion.

Scope

In scope: tools/install/tests/test_cs_rename_e2e.sh (new), and the manual release-time checklist recorded in this spec's body.

Out of scope / Non-Goals

Any code change to cli.mjs, build.sh, or the memory/cuo dispatch logic itself — this task only tests what TASK-IMP-130/131/132 already implement.
Actually performing the manual release-time checklist — that is a release-process action, not a deliverable this task's own status transition depends on.
Cutting the npm release or merging the Homebrew tap PR — those are TASK-IMP-130's and TASK-IMP-133's concerns respectively (and, per TASK-IMP-133's audit ISS-005, not fully owned by any task in this batch).

Dependencies

Depends on TASK-IMP-130, 131, and 132 — the automated offline portion (clauses 1.1-1.5) only needs their CODE to exist, not TASK-IMP-133's completion. TASK-IMP-133 is deliberately NOT in depends_on: its own audit (ISS-005) established that it cannot reach done until an npm release is actually cut and published, an externally-gated, indefinite-duration event. Making this task's depends_on include TASK-IMP-133 would block this task's own immediately-implementable, fully-automated portion behind that external gate for no reason — only the MANUAL checklist in Edge Cases (clause 1.6, not gated by this task's status transitions) actually needs TASK-IMP-133 to have shipped. Nothing in this batch depends on this task (blocks: []).

Relationship to TASK-IMP-107. That task built test_e2e_skeleton.sh, the offline e2e precedent this task's own test file follows structurally (build-from-source into scratch, no network, no credentials) — including its file-level pattern of building ONE scratch payload before any check function runs, which this task's own clause 1.1 depends on directly (see §1.1's revised wording).

AI Authorship Disclosure

Tools used: Claude (Fable 5) running the CyberOS task-author skill inside Cowork.
Scope: the offline-vs-network split was authored after reading test_e2e_skeleton.sh's actual header comment and cross-referencing TASK-IMP-133's audit finding (ISS-005) authored earlier in this same batch, not asserted independently.
Human review: task decomposition approved at the 2026-07-22 PLAN gate. The offline/manual split is an authoring-time call, flagged for the operator in the batch report.

1. Description (normative)

1.1 tools/install/tests/test_cs_rename_e2e.sh MUST build exactly one scratch payload from source, at file level before any check function is defined or called — matching test_sync_host_plugins.sh's own established pattern ("building scratch payload..." once, consumed by every tNN_* function below it) — and every check below MUST consume that SAME built payload; no check function may perform its own independent build.
1.2 The test MUST confirm the built payload's package.json declares bin: {"cs": ...} and does NOT declare a cyberos bin key.
1.3 The test MUST confirm cs -h's usage output lists all of install, uninstall, version, status, create, gates, mcp, help, memory, and cuo.
1.4 The test MUST confirm, against the ONE built payload, that both cs memory <cmd> (via a stub python3) and cs cuo <name> (via the redirect-stub check) behave correctly when invoked back-to-back in the same test run.
1.5 The test MUST run offline — no network access, no real npm registry query, no real Homebrew invocation — matching test_e2e_skeleton.sh's own established convention.
1.6 This task's spec MUST record the manual release-time checklist as body text, explicitly marked as not gating this task's own ready_to_implement → done transition.

2. Acceptance criteria

[x] AC 1 (traces_to: #1.1) - a grep of tools/install/tests/test_cs_rename_e2e.sh's own source for build invocations (bash "$BUILD" or equivalent) returns exactly 1, and that invocation appears before the first t0[0-9]_ function definition in the file - test: grep -c 'bash "\$BUILD"' tools/install/tests/test_cs_rename_e2e.sh returns 1, combined with a line-number comparison against the first t0 function definition
[x] AC 2 (traces_to: #1.2) - $TMP/payload/package.json's bin object has key cs and does not have key cyberos - test: tools/install/tests/test_cs_rename_e2e.sh::t02_bin_is_cs_only
[x] AC 3 (traces_to: #1.3) - node $TMP/payload/cli/bin/cli.mjs -h output contains all ten command names listed in clause 1.3, matched with word-boundary-safe patterns (e.g. grep -wo) so that a substring coincidence (e.g. "create" inside a hypothetical unrelated "created") cannot produce a false pass - test: tools/install/tests/test_cs_rename_e2e.sh::t03_usage_lists_all_ten_verbs
[x] AC 4 (traces_to: #1.4) - within the same test run, a stub-python3 cs memory doctor call and a cs cuo plan call both produce their expected outputs, run in sequence against the one built payload from AC 1-3 - test: tools/install/tests/test_cs_rename_e2e.sh::t04_memory_and_cuo_both_work_on_shared_build
[x] AC 5 (traces_to: #1.5) - the test file contains no invocation of curl, npm view, npm install <remote>, or brew anywhere in its body - test: grep -Ec 'curl |npm view|npm install [^-]|brew ' tools/install/tests/test_cs_rename_e2e.sh returns 0
[x] AC 6 (traces_to: #1.6) - a grep of THIS spec file for the literal heading text Manual release-time checklist returns at least 1 match - test: grep -c 'Manual release-time checklist' docs/tasks/improvement/TASK-IMP-134-cs-rename-e2e-regression/spec.md returns >=1

3. Edge cases

If TASK-IMP-131 or TASK-IMP-132 ships with a different exact dispatch-table shape than either task's own spec describes (e.g. a routing function instead of a flat object key), this test's assertions about cli.mjs's internal structure (if any are added beyond black-box CLI invocation) would need updating - mitigated by keeping all assertions black-box (invoke the CLI, read stdout/exit code) rather than parsing cli.mjs's source, so implementation-detail changes in HOW the dispatch is built don't break this test as long as the observable behaviour matches.
Manual release-time checklist (not gated by this task's own acceptance criteria — see clause 1.6 and Scope): (1) confirm the npm release referenced by the updated Homebrew Formula (TASK-IMP-133) is live via npm view @cyberskill/cyberos version; (2) on a machine with cyberos-memory separately pip-installed, brew install cyberos-cli then confirm cyberos (bare) resolves to the pip-installed memory CLI and cs resolves to the Homebrew-installed public CLI, with neither shadowing the other; (3) confirm cs memory doctor on that same machine reaches the real BRAIN store and its output matches what cyberos doctor (the direct invocation) would show for the same store path.
A machine with NEITHER cyberos nor cs previously installed (the actual "clean machine" the plan's wording literally describes): the manual checklist's step 2 is vacuously about "no collision" since there is nothing pre-existing to collide with - the meaningful clean-machine claim is narrower than the plan's wording suggests, and is really about a machine that has BOTH the old internal tool and the new public one, which is the founder's own originally-reported scenario (plan §2).
Security-class: this task adds a new offline test file only; it introduces no new runtime code path and no new attack surface.

Audit

§1 — Verdict summary

Six §1 clauses, six ACs, three edge cases (one of which is the manual checklist itself, one a documented scope-narrowing note, one security-class). The most consequential finding was a depends_on error that would have blocked this task's fully-automatable portion behind an indefinite external gate for no real reason — a batch-level sequencing defect, not a wording issue.

§2 — Findings (all resolved)

ISS-001 — `depends_on` included TASK-IMP-133, blocking the automated portion behind an indefinite external gate

This task's clauses 1.1-1.5 need only TASK-IMP-130/131/132's CODE to exist. TASK-IMP-133's own audit (this same batch, ISS-005) established that task cannot reach done until a real npm release is cut and published — an operational event with no owning task and no fixed timeline. Making this task depend on TASK-IMP-133's completion would have blocked its own immediately-implementable, fully-automated test behind that indefinite wait, for a manual checklist section that isn't even gated by this task's own status transitions. Resolved: removed TASK-IMP-133 from depends_on; it remains a named soft-prerequisite for the manual checklist only.

ISS-002 — AC 1 deferred to "code review" for a mechanically checkable claim

Clause 1.1 (build exactly once, before any check) is directly checkable by grepping the test file's own source for the build-invocation count and its position relative to the first check function — the same technique AC 5 already used successfully on the same file. The first draft instead said "confirmed by reading the test file's own control flow at review time." Resolved: converted to the same grep-based technique as AC 5.

ISS-003 — AC 6 deferred to "manual review of this document" for an equally mechanical claim, with a confusing self-referential sub-clause

Clause 1.6 (the spec records a manual checklist) is checkable by grepping this very spec file for the required heading text. The original AC additionally required the checklist section "not be referenced by any traces_to in this AC list," a confusing, circular condition that added no real verification value. Resolved: converted to a plain grep-count check on the spec file itself; the confusing sub-clause was dropped rather than fixed, since it was not protecting against anything the simpler check misses.

ISS-004 — clause 1.1's single-shared-build requirement didn't cite the concrete precedent that makes it implementable

The clause stated the principle ("one build, not per-assertion") without pointing at test_sync_host_plugins.sh's own file-level build-once-then-many-checks pattern, the exact structure an implementer should copy. Resolved: the clause now cites that file directly.

ISS-005 — AC 3's ten-verb check was vulnerable to substring false positives

A naive grep for each of ten command names against cs -h's usage text could pass on an incidental substring match (a hypothetical future word containing "create" or similar) without the actual command name being listed. Resolved: tightened to word-boundary-safe matching (grep -wo or equivalent).

ISS-006 — the guardrail metric's completion trigger was subjective

"Before the cs rename is announced as complete to any external user" has no fixed, checkable moment - "announced" is a judgment call, not an event. Resolved: retied to a concrete artifact already established elsewhere in this batch — the release that includes TASK-IMP-130's own CHANGELOG entry (clause 1.6 of that task) being tagged and published.

ISS-007 — FM-101: title exceeded the 72-character limit (caught by the machine floor)

task-lint.mjs, run after the six findings above were resolved, flagged the title at 76 code points. Resolved: shortened to "End-to-end regression for the cs/memory/cuo rename" (title metadata only).

§3 — TRACE-006 semantic sufficiency (per clause)

Clause	Verb demand	Cited test asserts	Verdict
1.1 MUST build once, shared by all checks	a countable, positioned fact about the test file's own source	AC 1 (revised): grep count + line-position check	sufficient after revision (was manual-review - ISS-002)
1.2 MUST confirm bin.cs / no bin.cyberos	both halves on the built artifact	AC 2: both asserted directly	sufficient
1.3 MUST list all ten verbs	precise, non-substring-vulnerable match	AC 3 (revised): word-boundary-safe	sufficient after revision (was substring-vulnerable - ISS-005)
1.4 MUST confirm memory+cuo work together on shared build	both dispatches succeed in one run	AC 4: both asserted in sequence	sufficient
1.5 MUST run offline	absence of network-invoking commands in the test's own source	AC 5: grep-based	sufficient
1.6 MUST record manual checklist in spec body	a countable fact about this spec file's own text	AC 6 (revised): grep count on the spec file itself	sufficient after revision (was manual-review - ISS-003)

§4 — Resolution

Six findings, including one batch-sequencing defect (ISS-001, the most consequential), all resolved in the audited revision. Score = 10/10.

Status transition draft -> ready_to_implement is authorised by this verdict per STATUS-REFERENCE.md §1.1. The two /ship-tasks human-acceptance gates remain unchanged; the manual release-time checklist inside this spec is explicitly NOT part of that gate and is tracked as a separate release-process step.

End of TASK-IMP-134 audit.