[GH-ISSUE #3301] test(setup): align positive uninstall fixtures with verified command ownership #1175

New issue

Closed

opened 2026-10-15 18:31:45 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:31:45 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3301

Originally assigned to: @N0zoM1z0 on GitHub.

Three positive uninstall fixtures still treat arbitrary absolute .../bin/rea paths as REA-owned after 187f113f798b5b8a080d22285b51c05596c3e0f2 tightened registration identity. They now exercise conservative retention instead of their intended formatting/removal contracts.

Observed on clean tracked tree main 7c962cc70bcebf6201da9c5db5b7c0edd2564ae7, Linux x86_64 / Node 24.18.0 / npm 11.16.0 / Vitest 5.0.3:

npm exec -- vitest run --project boundary \
  --testNamePattern 'restores original BOM-prefixed JSONC bytes after update and removal|keeps Codex comments and value spelling through setup and uninstall|uninstalls only owned entries and refuses purge symlinks' \
  tests/boundary/filesystem/clientConfigurationBom.test.ts \
  tests/boundary/filesystem/clientLifecycle.test.ts

Result: 3 failed, 67 unselected, exit 1, 6.52 s. The BOM and Codex cases receive status: retained / The rea-named registration is not REA-owned. The removal case keeps the same registration. Hosted PR #3299 shard 2 shows the same three failures; restoring its only changed Rizin fixture to the parent revision reproduces them, and that fixture is outside this focused selection.

Affected positive cases:

clientConfigurationBom.test.ts: first/updated commands point to nonexistent arbitrary absolute prefixes, then expect uninstall to restore original BOM/JSONC bytes.
clientLifecycle.test.ts: Codex comment restoration and filesystem removal both use /isolated prefix/bin/rea and expect removal.

The current isOwnedClientRegistrationCommand intentionally requires an identifiable current entrypoint or an owned package-runner registration; a familiar basename alone is insufficient. Preserve that production safety boundary and all existing unknown/foreign registration retention assertions. Update only these positive fixtures to use genuinely recognized commands, retaining the command-update scenario, byte-preservation checks, unrelated entries, and purge-symlink protection.

Proposed validation: reproduce the failures first, run both complete fixture families plus the registration-identity/retention tests, and inspect current-head hosted CI. No change to production ownership policy is proposed. Broader user-visible regressions are not established by these fixture failures.

Originally created by @N0zoM1z0 on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3301 Originally assigned to: @N0zoM1z0 on GitHub. Three positive uninstall fixtures still treat arbitrary absolute `.../bin/rea` paths as REA-owned after `187f113f798b5b8a080d22285b51c05596c3e0f2` tightened registration identity. They now exercise conservative retention instead of their intended formatting/removal contracts. Observed on clean tracked tree main `7c962cc70bcebf6201da9c5db5b7c0edd2564ae7`, Linux x86_64 / Node 24.18.0 / npm 11.16.0 / Vitest 5.0.3: ```sh npm exec -- vitest run --project boundary \ --testNamePattern 'restores original BOM-prefixed JSONC bytes after update and removal|keeps Codex comments and value spelling through setup and uninstall|uninstalls only owned entries and refuses purge symlinks' \ tests/boundary/filesystem/clientConfigurationBom.test.ts \ tests/boundary/filesystem/clientLifecycle.test.ts ``` Result: **3 failed, 67 unselected**, exit 1, 6.52 s. The BOM and Codex cases receive `status: retained` / `The rea-named registration is not REA-owned.` The removal case keeps the same registration. Hosted PR #3299 shard 2 shows the same three failures; restoring its only changed Rizin fixture to the parent revision reproduces them, and that fixture is outside this focused selection. Affected positive cases: - `clientConfigurationBom.test.ts`: first/updated commands point to nonexistent arbitrary absolute prefixes, then expect uninstall to restore original BOM/JSONC bytes. - `clientLifecycle.test.ts`: Codex comment restoration and filesystem removal both use `/isolated prefix/bin/rea` and expect removal. The current `isOwnedClientRegistrationCommand` intentionally requires an identifiable current entrypoint or an owned package-runner registration; a familiar basename alone is insufficient. Preserve that production safety boundary and all existing unknown/foreign registration retention assertions. Update only these positive fixtures to use genuinely recognized commands, retaining the command-update scenario, byte-preservation checks, unrelated entries, and purge-symlink protection. Proposed validation: reproduce the failures first, run both complete fixture families plus the registration-identity/retention tests, and inspect current-head hosted CI. No change to production ownership policy is proposed. Broader user-visible regressions are not established by these fixture failures.

bsakaguchi closed this issue

2026-10-15 18:31:45 +00:00

bsakaguchi commented

2026-10-15 18:31:46 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 14, 2026):

Resolved independently on main by a154b9752. It preserves conservative command ownership and corrects the same three positive fixtures; the BOM cycle uses the current executable/entrypoint rather than my alternative package-runner fixture.

Verified the landed implementation on main 0351328e5: all five relevant filesystem families passed, 122 tests / 0 failures, using the real setup/uninstall APIs and temporary configuration files (Linux, Node 24.18.0, npm 11.16.0, Vitest 5.0.3). Unknown/foreign registration protections remain intact. My original branch's 122 tests and static checks also passed, and Greptile reviewed its exact head at 5/5.

Closing the duplicate PR/issue rather than replacing the landed implementation. This PR was not merged; the correction is already in main. Its superseded CI run can be canceled. #3299 will incorporate and validate current main separately.

@N0zoM1z0 commented on GitHub (Oct 14, 2026): Resolved independently on main by [a154b9752](https://github.com/morluto/rea/commit/a154b9752c81ff660666d11acd40744f52de81ab). It preserves conservative command ownership and corrects the same three positive fixtures; the BOM cycle uses the current executable/entrypoint rather than my alternative package-runner fixture. Verified the landed implementation on main `0351328e5`: all five relevant filesystem families passed, **122 tests / 0 failures**, using the real setup/uninstall APIs and temporary configuration files (Linux, Node 24.18.0, npm 11.16.0, Vitest 5.0.3). Unknown/foreign registration protections remain intact. My original branch's 122 tests and static checks also passed, and Greptile reviewed its exact head at 5/5. Closing the duplicate PR/issue rather than replacing the landed implementation. This PR was not merged; the correction is already in main. Its superseded CI run can be canceled. #3299 will incorporate and validate current main separately.

bsakaguchi referenced this issue

2026-10-17 21:09:12 +00:00

[PR #1175] [MERGED] fix(cli): advertise defaulted inputs as optional in --schema and help #2699

bsakaguchi referenced this issue

2026-11-01 21:45:22 +00:00

[PR #5880] [CLOSED] test(cli): treat omitted exactOptional inputs as optional #7098