Files
Codeman/src/utils/pi-cli-resolver.ts
T
DevvynandClaude Opus 5 4830e662f9 refactor(cli-registry): make CLI backends data instead of per-mode branching
Every run mode is now a `CliEntry` in `src/config/cli-registry/` — discovery
(search dirs, version + identity probes), the launch argv template, env
handling, the `capabilities` flags that replace per-CLI branching, and the
`overlays` that back the remote/docker pane commands. Code that used to ask
"which CLI is this?" reads the entry instead.

Behaviour is unchanged. `test/cli-registry-spawn-golden.test.ts` pins every
spawn command as a literal string, captured from the hand-written builders
before they were deleted, and `test/location-overlay-commands.test.ts` does the
same for all 20 remote and in-container pane commands.

Config can never contain shell text: an entry declares typed argv tokens,
literals are validated against a safe-word pattern at LOAD time (a bad literal
rejects the whole entry — a silently dropped `--no-approve` is not cosmetic),
and values resolve through patterns NAMED in code, so a user `clis.json` cannot
widen its own validation. `~/.codeman/clis.json` overrides any entry, read-only
in this release.

OMP is included as a registry entry rather than a tenth hand-written builder,
so `buildOmpCommand()`, the omp availability pre-flight, the omp arm of
`buildPathExport()` and the omp entries in the truecolor/NO_COLOR, alt-screen
and doctor ladders all drop out.

Guard rails:

- `test/cli-registry-no-id-branching.test.ts` fails the build if per-CLI-id
  branching reappears outside `stock.ts`, in any of its four shapes (`===`,
  `!==`, `switch`/`case`, `includes`) — an `===`-only version would miss the
  negated forms, which is how 36 of them survived an earlier pass. Every
  allowlisted branch carries its reason.
- `external`, `hooks` and `altScreen` stay three INDEPENDENT capabilities;
  deriving one from another shipped the `until=stop`-hangs-on-shell bug.
- `param` is two namespaces. `launch.params` keys, `configSetenv.fromParam` and
  `privilegedParams[].param` all name a LAUNCH param; the legacy `<Mode>Config`
  wire field is separate, bridged only by `legacyConfigAliases`. Getting
  `privilegedParams[].param` wrong is SILENT — it is the multi-user bypass
  clamp's only handle on a CLI's privilege switch, and a wrong name clamps
  nothing with no error and no failing test — so `schema.ts` rejects an entry
  naming a param it never declared.
- Registry data resolves AT CALL TIME (`sessionModeSchema()`,
  `allowedEnvPrefixes()`, `dependencyRegistry()`, the resolvers' `searchDirs`
  thunks). A module-level const freezes at first import, so a CLI enabled while
  the server ran moved the run menu but not that surface.
- Six fields are annotated DECLARED-FOR-LATER and read by nothing
  (`shortBadge`, `accent`, `capabilities.echo`/`wheelForward`/
  `keyboardAccessory`/`maxFrameBytes`): all frontend behaviour, transcribed
  rather than measured. A test pins the list so it cannot quietly grow.

Three user-visible changes, all deliberate and named:

- `probeDockerCliVersion()` derives the in-container binary from the registry
  rather than assuming it equals the mode name (`antigravity` runs `agy`).
- The remote CLI version probe now covers grok and deepseek, which the
  hardcoded map it replaces omitted while its own comment said the rule was
  "every mode except shell".
- `codeman doctor`'s CLI rows are generated from the entries, so Claude's
  install hint is the install command rather than a docs URL, five CLIs gain
  hints they never had, and the row order follows the catalog.

Also hardened along the way: `sessionModeSchema()` is bounded at 24 chars
(matching the `cliId` pattern) before its failure message quotes the value
back, and `deepMerge` skips `__proto__`/`constructor`/`prototype` when reading
the hand-editable `clis.json`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WQkoi1cNegqVwZHgzx5SbJ
2026-09-02 08:26:45 +08:00

146 lines
6.0 KiB
TypeScript

/**
* @fileoverview Resolve the Pi CLI (`pi`) binary across common install paths.
*
* Mirrors antigravity-cli-resolver.ts, with one addition the other external-CLI
* resolvers do not need: `pi` is a SHORT, GENERIC name (Raspberry Pi tooling,
* personal scripts, `$PATH` accidents), so a `which pi` hit is not by itself
* evidence that the coding agent is installed. Every candidate is therefore
* sanity-probed with `pi --version` and required to print a semver-shaped
* string; a binary that fails the probe is treated as absent and the rejected
* path is logged so a misresolution is diagnosable.
*
* Pi ships as the npm package `@earendil-works/pi-coding-agent`, so the search
* dirs are the usual global-bin locations (npm/bun/manual installs).
*
* @module utils/pi-cli-resolver
*/
import { execFileSync } from 'node:child_process';
import { EXEC_TIMEOUT_MS } from '../config/exec-timeout.js';
import { getCli } from '../config/cli-registry/registry.js';
import { expandHome } from './cli-resolver.js';
import {
createCliExecutableResolver,
formatCliNotFoundMessage,
type CliResolverHost,
} from './cli-executable-resolver.js';
/** Common directories where the Pi CLI binary may be installed */
/**
* Directories probed after `which`, read from this CLI's registry entry so the spawn
* path, `codeman doctor` and this resolver cannot disagree about where to look.
* `~` is expanded by `expandHome`; nothing else is interpreted.
*/
const PI_SEARCH_DIRS = (): string[] => (getCli('pi')?.discovery.searchDirs ?? []).map(expandHome);
/**
* A real `pi --version` prints a semver-shaped string (e.g. `0.84.1`).
*
* Exported and SHARED with the `pi` entry in `config/dependency-registry.ts`, so
* `codeman doctor` and the run mode cannot disagree about what counts as an installed
* pi: two copies of this rule would let the Dependencies panel report "Pi CLI ✓" on a
* box where `resolvePiDir()` rejects the same binary and Run Pi stays hidden.
*
* Shape is dictated by the doctor's `extractVersion()`, which returns the first CAPTURE
* GROUP and scans the whole output: hence a capturing group, and a leading boundary
* instead of `^` so `pi 0.84.1` matches while `v0.84.1` (some other program) does not.
* No `g` flag, so there is no shared `lastIndex` to reset.
*/
export const PI_VERSION_REGEX = /(?:^|\s)(\d+\.\d+\.\d+)/;
const PI_NOT_FOUND = 'Pi CLI not found. Install with: npm install -g --ignore-scripts @earendil-works/pi-coding-agent';
/**
* Run `pi --version` on a candidate path and return the trimmed version when it
* looks like the coding agent. Returns null for anything else — a missing
* binary, a non-zero exit, a hang (timeout), or output that is not semver-shaped
* (which is how an unrelated `pi` on PATH gets rejected).
*
* Never runs under vitest: the suites must stay hermetic and must not depend on
* whether the dev box happens to have pi installed — and since `pi` is a short
* GENERIC name, this probe would EXECUTE whatever binary of that name the
* machine carries. The shared resolver host is already inert under vitest, so
* this gate is defense in depth for any opted-in host that still carries the
* default probe; tests drive resolution via `createPiResolverForTest`, whose
* injected probe bypasses it. Pinned by test/pi-cli-resolver.test.ts.
*/
function probePiVersion(binPath: string): string | null {
if (process.env.VITEST) return null;
try {
const out = execFileSync(binPath, ['--version'], {
encoding: 'utf-8',
timeout: EXEC_TIMEOUT_MS,
stdio: ['ignore', 'pipe', 'ignore'],
// A stuck or hostile `pi` that ignores SIGTERM would survive the timeout
// and block the server (execFileSync keeps waiting after the signal).
killSignal: 'SIGKILL',
}).trim();
// Upstream prints a bare version today; tolerate a `pi 0.84.1` style prefix too.
const candidate = PI_VERSION_REGEX.exec(out)?.[1];
if (candidate) return candidate;
console.warn(`[PiResolver] Ignoring ${binPath}: "pi --version" printed ${JSON.stringify(out.slice(0, 80))}`);
} catch (err) {
console.warn(`[PiResolver] Ignoring ${binPath}: "pi --version" failed (${(err as Error).message})`);
}
return null;
}
type PiVersionProbe = (binPath: string) => string | null;
function createPiResolver(host?: CliResolverHost, versionProbe: PiVersionProbe = probePiVersion, now?: () => number) {
return createCliExecutableResolver<string>(
{
binary: 'pi',
searchDirs: PI_SEARCH_DIRS,
validateCandidate: (binPath) => {
const version = versionProbe(binPath);
return version ? { accepted: true, metadata: version } : { accepted: false };
},
now,
},
host
);
}
/**
* Creates an isolated Pi wrapper around an injected host, version probe and
* clock. Omitting `versionProbe` keeps the ambient (VITEST-gated) probe, which
* is exactly what the hermeticity test exercises.
*/
export function createPiResolverForTest(host: CliResolverHost, versionProbe?: PiVersionProbe, now?: () => number) {
return createPiResolver(host, versionProbe ?? probePiVersion, now);
}
const piResolver = createPiResolver();
/**
* Finds the directory containing a verified `pi` binary.
* Checks `which pi` first, then falls back to common install locations. Every
* candidate must pass the `pi --version` sanity probe (§2.6 of the integration
* plan) before it is accepted.
*
* @returns Directory path, or null if not found
*/
export function resolvePiDir(): string | null {
return piResolver.resolve()?.directory ?? null;
}
/**
* Check if the Pi CLI is available on the system.
*/
export function isPiAvailable(): boolean {
return resolvePiDir() !== null;
}
export function getPiNotFoundMessage(): string {
return formatCliNotFoundMessage(PI_NOT_FOUND, piResolver.diagnostics());
}
/**
* Version reported by the resolved `pi` binary, or null when pi is unavailable.
* Surfaced through `GET /api/pi/status` so a misresolution is diagnosable from the UI.
*/
export function getPiCliVersion(): string | null {
return piResolver.resolve()?.metadata ?? null;
}