morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #2973] [MERGED] fix(verify-package): read Hopper installer applicability from its owner #5530

New issue

Closed

opened 2026-10-31 01:07:20 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:07:20 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2973
Author: @txiki739
Created: 10/13/2026
Status: ✅ Merged
Merged: 10/13/2026
Merged by: @morluto

Base: main ← Head: fix/verify-package-hopper-installer-support

📝 Commits (3)

1f3924a fix(verify-package): read Hopper installer applicability from its owner
eda44ba fix(ci): preserve Hopper doctor readiness checks
e6f9e87 Merge commit '2895a18ca9' into codex/ci-review-pr2973-20261014

📊 Changes

4 files changed (+165 additions, -19 deletions)

View changed files

📝 scripts/verify-package-discovery.d.mts (+23 -4)
📝 scripts/verify-package-discovery.mjs (+54 -12)
📝 scripts/verify-package-setup.mjs (+2 -3)
➕ tests/evaluation/package/packageSetupSupport.test.ts (+86 -0)

📄 Description

What

npm run verify:package fails on Debian-family hosts that REA supports but the automatic Hopper installer never tested — Debian 12 in the report, Kali 2026.3 here. The packaged setup correctly answers needs_human to --install-hopper; the verifier expected needs_confirmation.

Root cause

packageSetupSupport derived hopperSetupSupported from the general doctor host check plus a non-Windows condition. After #2073 that check means "REA runs here", which is a different fact from "the Hopper package was tested on this distribution", so on Kali and Debian both flags came back true while the owning readLinuxDistribution() reports hopperSetupSupported: false.

Change

scripts/verify-package-discovery.mjs — installer applicability now comes from readLinuxDistribution() in the built application, so the verifier follows the predicate the package ships instead of restating it. An unreadable distribution stays undefined rather than collapsing into a known-unsupported host, nothing is inferred from packageFamily, and doctor prose is never parsed. The distribution is imported lazily, which also keeps the derivation testable without a build.
scripts/verify-package-setup.mjs — the expected status for the explicit --install-hopper request is needs_confirmation only when applicability is explicitly true. The generic configuration and idempotence assertions (first, aligned) are untouched and remain independent of installer applicability; the expectation is still derived from the host rather than from the request being asserted.
scripts/verify-package-discovery.d.mts — contract updated. It is the source of truth for this script's types, and the previous one still declared platform: NodeJS.Platform.
tests/evaluation/package/packageSetupSupport.test.ts — positive/negative applicability selection: a Kali fixture (REA-supported, installer-untested) selects false; Ubuntu 24 selects true even when the doctor host check fails; an unreadable distribution stays undefined; macOS follows the owner's predicate; Windows selects false; agent setup support still comes from the node check alone. Fixtures are derived from what readLinuxDistribution() actually returns for those os-release files.

Verification

On Kali 2026.3 (Debian-family, hopperSetupSupported: false), with the packaged fixture's simulated Hopper environment and no other deep provider — the reporter's host profile:

	`npm run verify:package`
before this change	fails at `verify-package-setup.mjs:403`; packaged setup returns `needs_human` with an `install_hopper` plan and nothing applied
after this change	passes every stage, exit `0`

npm run test:local -- tests/evaluation/package/packageSetupSupport.test.ts tests/evaluation/package/packagePlatformDiagnostics.test.ts → 12 passed, and the new file needs no build.
npm run typecheck and npm run lint (including verify:module-boundaries) clean.
Branch coverage: this host exercises the negative branch; the Native package baseline job runs npm run verify:package on ubuntu-latest and ubuntu-24.04-arm, where applicability is true, so the positive branch stays exercised. Debian 12 itself was not re-run here.
No real Hopper installation was exercised, so no engine-compatibility claim follows from the simulated provider environment.

Closes #2939

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2973 **Author:** [@txiki739](https://github.com/txiki739) **Created:** 10/13/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/verify-package-hopper-installer-support` --- ### 📝 Commits (3) - [`1f3924a`](https://github.com/morluto/rea/commit/1f3924a701de3facd824a145f8f7b596b78a1e91) fix(verify-package): read Hopper installer applicability from its owner - [`eda44ba`](https://github.com/morluto/rea/commit/eda44ba63499ced640b4f42d595ab8b5cb00421f) fix(ci): preserve Hopper doctor readiness checks - [`e6f9e87`](https://github.com/morluto/rea/commit/e6f9e873a447d2f1e34d5ede57093ba37513b96f) Merge commit '2895a18ca92f415ae62f87167ba9c7a672e3b7dc' into codex/ci-review-pr2973-20261014 ### 📊 Changes **4 files changed** (+165 additions, -19 deletions) <details> <summary>View changed files</summary> 📝 `scripts/verify-package-discovery.d.mts` (+23 -4) 📝 `scripts/verify-package-discovery.mjs` (+54 -12) 📝 `scripts/verify-package-setup.mjs` (+2 -3) ➕ `tests/evaluation/package/packageSetupSupport.test.ts` (+86 -0) </details> ### 📄 Description ## What `npm run verify:package` fails on Debian-family hosts that REA supports but the automatic Hopper installer never tested — Debian 12 in the report, Kali 2026.3 here. The packaged setup correctly answers `needs_human` to `--install-hopper`; the verifier expected `needs_confirmation`. ## Root cause `packageSetupSupport` derived `hopperSetupSupported` from the general doctor `host` check plus a non-Windows condition. After #2073 that check means *"REA runs here"*, which is a different fact from *"the Hopper package was tested on this distribution"*, so on Kali and Debian both flags came back `true` while the owning `readLinuxDistribution()` reports `hopperSetupSupported: false`. ## Change - **`scripts/verify-package-discovery.mjs`** — installer applicability now comes from `readLinuxDistribution()` in the built application, so the verifier follows the predicate the package ships instead of restating it. An unreadable distribution stays `undefined` rather than collapsing into a known-unsupported host, nothing is inferred from `packageFamily`, and doctor prose is never parsed. The distribution is imported lazily, which also keeps the derivation testable without a build. - **`scripts/verify-package-setup.mjs`** — the expected status for the explicit `--install-hopper` request is `needs_confirmation` only when applicability is explicitly `true`. The generic configuration and idempotence assertions (`first`, `aligned`) are untouched and remain independent of installer applicability; the expectation is still derived from the host rather than from the request being asserted. - **`scripts/verify-package-discovery.d.mts`** — contract updated. It is the source of truth for this script's types, and the previous one still declared `platform: NodeJS.Platform`. - **`tests/evaluation/package/packageSetupSupport.test.ts`** — positive/negative applicability selection: a Kali fixture (REA-supported, installer-untested) selects `false`; Ubuntu 24 selects `true` even when the doctor host check fails; an unreadable distribution stays `undefined`; macOS follows the owner's predicate; Windows selects `false`; agent setup support still comes from the `node` check alone. Fixtures are derived from what `readLinuxDistribution()` actually returns for those os-release files. ## Verification On Kali 2026.3 (Debian-family, `hopperSetupSupported: false`), with the packaged fixture's simulated Hopper environment and no other deep provider — the reporter's host profile: | | `npm run verify:package` | |---|---| | before this change | fails at `verify-package-setup.mjs:403`; packaged setup returns `needs_human` with an `install_hopper` plan and nothing applied | | after this change | passes every stage, exit `0` | - `npm run test:local -- tests/evaluation/package/packageSetupSupport.test.ts tests/evaluation/package/packagePlatformDiagnostics.test.ts` → 12 passed, and the new file needs no build. - `npm run typecheck` and `npm run lint` (including `verify:module-boundaries`) clean. - Branch coverage: this host exercises the negative branch; the `Native package baseline` job runs `npm run verify:package` on `ubuntu-latest` and `ubuntu-24.04-arm`, where applicability is `true`, so the positive branch stays exercised. Debian 12 itself was not re-run here. - No real Hopper installation was exercised, so no engine-compatibility claim follows from the simulated provider environment. Closes #2939 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:07:20 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

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

[PR #5814] [MERGED] fix(cli): preserve Unicode and text across token windows #7078

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#5530

No description provided.

Rows
Columns