mirror of
https://github.com/morluto/rea
synced 2026-10-25 22:08:11 -04:00
CindyGest
e1897c3c17
* fix(verify-package): read Hopper installer applicability from its owner packageSetupSupport derived hopperSetupSupported from the general doctor host check plus a non-Windows condition, so a Debian-family host REA supports but the Hopper package never tested reported an automated installer the packaged setup never offers. verifySetupApply then expected needs_confirmation for the explicit --install-hopper request and failed at verify-package-setup.mjs:403. Applicability now comes from readLinuxDistribution() in the built application, so the verifier follows the predicate the package ships, and it stays unknown when no distribution can be read instead of collapsing into a known-unsupported host. Generic agent configuration and idempotence assertions stay independent of installer applicability, and the expected status is still derived from the host rather than from the request being asserted. Verified on Kali 2026.3, a Debian-family host with an installer-untested distribution and the simulated Hopper package environment: before the change npm run verify:package fails at verify-package-setup.mjs:403 with the packaged setup correctly returning needs_human; after it the same run passes every stage. Both applicability branches are covered by tests/evaluation/package/packageSetupSupport.test.ts, which runs in the source lane without a build. No real Hopper installation was exercised, so no engine compatibility claim follows. Refs #2939 * fix(ci): preserve Hopper doctor readiness checks --------- Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>