Files
rea/scripts/verify-package-discovery.d.mts
T
CindyGestandmorluto e1897c3c17 fix(verify-package): read Hopper installer applicability from its owner (#2973)
* 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>
2026-10-14 03:19:45 +08:00

39 lines
1.2 KiB
TypeScript

/**
* Host facts the packaged setup support is derived from.
*
* `linuxDistribution` is the distribution record the Hopper installer owner
* parses; it is absent when no distribution could be read, which leaves
* installer applicability unknown rather than unsupported.
*/
export interface SetupHostFacts {
readonly platform: NodeJS.Platform;
readonly linuxDistribution?: {
readonly hopperSetupSupported: boolean;
};
}
/**
* Derive agent setup support from the doctor node check and automated Hopper
* installer applicability from the facts their owners parse. Applicability is
* undefined when its owning fact is unavailable.
*/
export function packageSetupSupport(
checks:
| readonly { readonly name: string; readonly ok: boolean }[]
| undefined,
host: SetupHostFacts,
): {
supportedSetupHost: boolean;
hopperReadinessRequired: boolean;
hopperSetupSupported: boolean | undefined;
};
/** Validate --help, --llms, and doctor output and determine host setup support. */
export function verifyPackageDiscovery(input: {
readonly cli: string;
readonly environment: Readonly<Record<string, string | undefined>>;
}): Promise<{
supportedSetupHost: boolean;
hopperSetupSupported: boolean | undefined;
}>;