[GH-ISSUE #2939] fix(verify-package): distinguish host readiness from Hopper installer support #1035

New issue

Closed

opened 2026-10-15 18:30:31 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

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

Reproduction

On Debian12/bookworm x64, Node24.18.0/npm11.16.0, normally built commit f5a4665cce2e36b33cbf0055c44587913126a8aa (captured main 1b6c899b031421dcf2d725a63e67d99375028d6e plus the unrelated equivalent Android regex fix):

npm run verify:package

Archive, package install, CLI/MCP loading, discovery, artifact/managed/platform/capability and Evidence stages pass. The verifier fails at verify-package-setup.mjs:403 after114.30s. Initial/aligned configuration is ready; aligned has zero actions. Explicit Hopper reinstall correctly returns needs_human, proposes installation and applies nothing because automatic Hopper setup does not support this distribution.

Root cause

packageSetupSupport in scripts/verify-package-discovery.mjs derives hopperSetupSupported from the general doctor host check plus a non-Windows condition. Actual public doctor reports node/host healthy for Debian12, so this helper returns both flags true. The existing owning readLinuxDistribution() instead reports hopperSetupSupported: false. Host readiness and automated Hopper installer applicability are different facts.

The incorrect flag makes verifySetupApply expect needs_confirmation rather than the correct needs_human result. This is a package verification rule defect; the actual setup rejection is correct.

Expected correction and verification

Reuse the existing owner's parsed applicability facts. Keep generic REA configuration/idempotence checks and independent supported/unsupported Hopper installer checks. Do not broadly skip Linux, parse doctor prose, infer support from package family, or derive expected status from the request being asserted. Preserve unknown applicability explicitly.

Verify normal packaged CLI/MCP on Debian and Ubuntu24, plus positive/negative applicability selection tests. The earlier pinned d4f0c5e66 diagnostic run reproduced the same assertion with lifecycle scripts disabled; the current reproduction above uses the normal successful build/prepack. No real Hopper installation is requested by this package fixture, and no engine compatibility claim follows from its simulated provider environment.

PR2073 addresses related host-versus-installer semantics in production, but its changed files do not include this package verifier consumer.

Originally created by @N0zoM1z0 on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2939 ## Reproduction On Debian12/bookworm x64, Node24.18.0/npm11.16.0, normally built commit `f5a4665cce2e36b33cbf0055c44587913126a8aa` (captured main `1b6c899b031421dcf2d725a63e67d99375028d6e` plus the unrelated equivalent Android regex fix): ```sh npm run verify:package ``` Archive, package install, CLI/MCP loading, discovery, artifact/managed/platform/capability and Evidence stages pass. The verifier fails at `verify-package-setup.mjs:403` after114.30s. Initial/aligned configuration is ready; aligned has zero actions. Explicit Hopper reinstall correctly returns `needs_human`, proposes installation and applies nothing because automatic Hopper setup does not support this distribution. ## Root cause `packageSetupSupport` in `scripts/verify-package-discovery.mjs` derives `hopperSetupSupported` from the general doctor host check plus a non-Windows condition. Actual public doctor reports node/host healthy for Debian12, so this helper returns both flags true. The existing owning `readLinuxDistribution()` instead reports `hopperSetupSupported: false`. Host readiness and automated Hopper installer applicability are different facts. The incorrect flag makes `verifySetupApply` expect `needs_confirmation` rather than the correct `needs_human` result. This is a package verification rule defect; the actual setup rejection is correct. ## Expected correction and verification Reuse the existing owner's parsed applicability facts. Keep generic REA configuration/idempotence checks and independent supported/unsupported Hopper installer checks. Do not broadly skip Linux, parse doctor prose, infer support from package family, or derive expected status from the request being asserted. Preserve unknown applicability explicitly. Verify normal packaged CLI/MCP on Debian and Ubuntu24, plus positive/negative applicability selection tests. The earlier pinned d4f0c5e66 diagnostic run reproduced the same assertion with lifecycle scripts disabled; the current reproduction above uses the normal successful build/prepack. No real Hopper installation is requested by this package fixture, and no engine compatibility claim follows from its simulated provider environment. PR2073 addresses related host-versus-installer semantics in production, but its changed files do not include this package verifier consumer.

bsakaguchi

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

closed this issue
added the
bug
label

bsakaguchi referenced this issue

2026-10-17 21:08:02 +00:00

[PR #1035] [MERGED] fix: select Node legacy package entry fields for import and require #2599

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#1035

No description provided.

Rows
Columns