@gjsify/cli 0.30.0 → 0.31.0

package/lib/utils/gjsify-shim.d.ts

@@ -1,6 +1,33 @@
 /**
- * Ensure a GJS-runnable `gjsify` is on `process.env.PATH` for child processes.
+ * True when nested `gjsify` calls in this process tree are being routed through
+ * a self-shim rather than through the workspace's `node_modules/.bin/gjsify`.
+ *
+ * `detectPackageManager()` reads this: a bootstrap CLI must run package scripts
+ * ITSELF, because npm re-prepends `node_modules/.bin` for every lifecycle
+ * script it starts — which puts the tree's dead shim back ahead of the shim dir
+ * this module placed on PATH, and undoes the whole repair one level down.
+ */
+export declare function usingSelfShim(): boolean;
+/**
+ * Does this invocation need its own `gjsify` on PATH, rather than the
+ * workspace's npm bin?
+ *
+ * Pure, and takes the host facts as PARAMETERS rather than reading them
+ * ambiently — the same shape `platform-check.ts` documents, and what lets the
+ * Windows-relevant branch be tested from a Linux host.
+ *
+ * @param gjs           running under GJS (the npm bin is the Node entry there)
+ * @param selfEntry     absolute path of the CLI entry currently executing
+ * @param workspaceRoot absolute path of the workspace the command will act on
+ */
+export declare function needsSelfShim(opts: {
+    gjs: boolean;
+    selfEntry: string;
+    workspaceRoot: string;
+}): boolean;
+/**
+ * Ensure a runnable `gjsify` is on `process.env.PATH` for child processes.
  * Idempotent per process; children inherit the shim via `GJSIFY_SHIM_DIR` and
- * reuse it instead of creating their own. No-op when not running under GJS.
+ * reuse it instead of creating their own.
  */
 export declare function ensureGjsifyShimOnPath(): void;

package/lib/utils/gjsify-shim.js

@@ -1,52 +1,161 @@
-// Node-free orchestration: a GJS-runnable `gjsify` on PATH.
+// A runnable `gjsify` on PATH, for the two trees where the npm bin is not one.
 //
-// The CLI's npm `bin` (`node_modules/.bin/gjsify`) is the NODE entry — useless
-// in a node-free environment (the Flatpak sandbox has no Node). But multi-
-// package orchestration and compound package scripts resolve `gjsify` from
-// PATH and would hit that Node bin:
+// The CLI's npm bin (`node_modules/.bin/gjsify`) is a DISPATCHER written at
+// install time: it prefers `packages/infra/cli/dist/cli.gjs.mjs` on a host that
+// has `gjs`, and otherwise execs the Node entry `packages/infra/cli/lib/index.js`.
+// Multi-package orchestration and compound package scripts resolve `gjsify`
+// from PATH and go through it:
 //   - `gjsify workspace`/`foreach` spawn `<pm> run <script>` per package; under
 //     GJS the package manager is `gjsify` itself, and `spawn('gjsify', …)`
 //     searches PATH.
 //   - a compound script like `gjsify run a && gjsify run b` is executed via
-//     `/bin/sh -c …`, and the shell resolves each `gjsify` from PATH.
-// Both fail without Node (`spawn npm ENOENT`, `gjsify: not found`).
+//     `/bin/sh -c …` (or `%COMSPEC% /c …`), and the shell resolves each
+//     `gjsify` from PATH.
 //
-// Fix: under GJS, write a tiny wrapper that re-invokes the running GJS bundle
-// under `gjs -m`, and prepend its directory to `process.env.PATH` so every
-// child process (and grandchild, via the inherited `GJSIFY_SHIM_DIR` marker)
-// resolves `gjsify` to a GJS-runnable executable. No-op on Node.
+// Fix: write a tiny wrapper that re-invokes the RUNNING CLI, and prepend its
+// directory to `process.env.PATH` so every child process (and grandchild, via
+// the inherited `GJSIFY_SHIM_DIR` marker) resolves `gjsify` to a CLI that
+// actually exists.
+//
+// TWO HOSTS NEED IT, FOR TWO DIFFERENT REASONS
+//
+// GJS — always. The npm bin is the NODE entry and is useless in a node-free
+// environment (the Flatpak sandbox has no Node): without the shim the failures
+// are `spawn npm ENOENT` and `gjsify: not found`.
+//
+// Node — only when the running CLI came from OUTSIDE the workspace, which is
+// exactly the cold-tree bootstrap (`npx @gjsify/cli@latest …`, or a global
+// install). ADR 0002 untracked BOTH bundles, so on a tree that is installed but
+// not yet built, `node_modules/.bin/gjsify` exists and everything it dispatches
+// to is missing. The bin shim is then a live landmine: it resolves, and then
+// dies with `Cannot find module …/packages/infra/cli/lib/index.js` on the FIRST
+// nested `gjsify` — which for `gjsify run build:infra` is its first clause,
+// `gjsify workspace @gjsify/vite-plugin-blueprint build`.
+//
+// THE INCIDENT, because a rule without it gets simplified back into the bug.
+//
+// `windows-suites.yml` (added #1021) and `macos-suites.yml` (#1022) both landed
+// during the 2026-08-06 GitHub Actions degradation with NO checks reported on
+// their PRs, and neither leg had ever been green. Both ordered the cold-tree
+// bootstrap as `run build:infra` BEFORE `install`, which cannot work either:
+// `@gjsify/vite-plugin-blueprint` declares `"types": ["node"]`, so with no
+// `node_modules` its `gjsify tsc` fails `TS2688: Cannot find type definition
+// file for 'node'`. Correcting the order to install-then-build then exposed
+// THIS gap, one step later.
+//
+// Reproduced on Linux at de7f5525 in a cold worktree — nothing about it is
+// Windows-specific:
+//
+//   npx --yes @gjsify/cli@latest install --immutable   # ok
+//   npx --yes @gjsify/cli@latest run build:infra       # Cannot find module …
+//
+// Linux CI never saw it because its bootstrap runs `gjs -m <published bundle>
+// run build:infra` (`.github/actions/gjsify-setup`), which takes the GJS branch
+// above. Windows is simply the only leg with no `gjs` to fall back on, so it is
+// where the gap became load-bearing.
+//
+// Scoped to an outside-the-workspace CLI ON PURPOSE: when the invocation
+// already came through the workspace's own `node_modules/.bin/gjsify`, that
+// shim IS the CLI the tree wants, and today's dispatch (GJS bundle first on a
+// host with `gjs`) stays byte-for-byte unchanged. Widening this to every Node
+// invocation would silently move in-repo nested builds off the GJS bundle.
 import { mkdtempSync, writeFileSync, chmodSync, existsSync } from 'node:fs';
 import { tmpdir } from 'node:os';
-import { join, delimiter } from 'node:path';
+import { join, delimiter, relative, isAbsolute } from 'node:path';
 import { fileURLToPath } from 'node:url';
 import { isGjs } from '@gjsify/rolldown-plugin-gjsify/runtime';
+import { buildLauncherShims } from './bin-shim.js';
+import { findWorkspaceRoot } from './workspace-root.js';
 let _ensured = false;
+let _selfShimActive = false;
 /**
- * Ensure a GJS-runnable `gjsify` is on `process.env.PATH` for child processes.
+ * True when nested `gjsify` calls in this process tree are being routed through
+ * a self-shim rather than through the workspace's `node_modules/.bin/gjsify`.
+ *
+ * `detectPackageManager()` reads this: a bootstrap CLI must run package scripts
+ * ITSELF, because npm re-prepends `node_modules/.bin` for every lifecycle
+ * script it starts — which puts the tree's dead shim back ahead of the shim dir
+ * this module placed on PATH, and undoes the whole repair one level down.
+ */
+export function usingSelfShim() {
+    return _selfShimActive;
+}
+/**
+ * Does this invocation need its own `gjsify` on PATH, rather than the
+ * workspace's npm bin?
+ *
+ * Pure, and takes the host facts as PARAMETERS rather than reading them
+ * ambiently — the same shape `platform-check.ts` documents, and what lets the
+ * Windows-relevant branch be tested from a Linux host.
+ *
+ * @param gjs           running under GJS (the npm bin is the Node entry there)
+ * @param selfEntry     absolute path of the CLI entry currently executing
+ * @param workspaceRoot absolute path of the workspace the command will act on
+ */
+export function needsSelfShim(opts) {
+    if (opts.gjs)
+        return true;
+    // Outside the workspace ⇒ a bootstrap CLI (npx / global install), so the
+    // tree's own `.bin/gjsify` may well point at build outputs that do not
+    // exist yet. Inside ⇒ the tree's CLI is the one running; leave PATH alone.
+    const rel = relative(opts.workspaceRoot, opts.selfEntry);
+    return rel === '' || rel.startsWith('..') || isAbsolute(rel);
+}
+/**
+ * Ensure a runnable `gjsify` is on `process.env.PATH` for child processes.
  * Idempotent per process; children inherit the shim via `GJSIFY_SHIM_DIR` and
- * reuse it instead of creating their own. No-op when not running under GJS.
+ * reuse it instead of creating their own.
  */
 export function ensureGjsifyShimOnPath() {
-    if (_ensured || !isGjs())
+    if (_ensured)
         return;
     _ensured = true;
-    // A parent gjsify (also under GJS) already created the shim — reuse it so
-    // nested orchestration doesn't pile up temp dirs / PATH entries.
+    // A parent gjsify already created the shim — reuse it so nested
+    // orchestration doesn't pile up temp dirs / PATH entries. The
+    // extension-less member is written on every host, so it stays the probe.
     const inherited = process.env.GJSIFY_SHIM_DIR;
     if (inherited && existsSync(join(inherited, 'gjsify'))) {
+        _selfShimActive = true;
         if (!(process.env.PATH ?? '').split(delimiter).includes(inherited)) {
             process.env.PATH = inherited + delimiter + (process.env.PATH ?? '');
         }
         return;
     }
-    // `import.meta.url` resolves to the running GJS bundle (cli.gjs.mjs) — the
-    // whole CLI collapses into that single file, so this module's URL is it.
-    const selfBundle = fileURLToPath(import.meta.url);
-    const gjs = process.env.GJS_CONSOLE || 'gjs';
+    const gjs = isGjs();
+    // Under GJS `import.meta.url` IS the entry — the whole CLI collapses into
+    // the single `cli.gjs.mjs` bundle, so this module's URL is it. Under Node
+    // this module is `lib/utils/gjsify-shim.js` and the npm bin is
+    // `lib/index.js` (package.json `bin`), one hop up.
+    const selfEntry = gjs ? fileURLToPath(import.meta.url) : fileURLToPath(new URL('../index.js', import.meta.url));
+    const workspaceRoot = findWorkspaceRoot(process.cwd()) ?? process.cwd();
+    if (!needsSelfShim({ gjs, selfEntry, workspaceRoot }))
+        return;
     const dir = mkdtempSync(join(tmpdir(), 'gjsify-shim-'));
     const shim = join(dir, 'gjsify');
-    writeFileSync(shim, `#!/bin/sh\nexec "${gjs}" -m "${selfBundle}" "$@"\n`, { mode: 0o755 });
+    // The interpreter is named, not pathed, on every member — matching
+    // `buildShLauncher`'s `exec gjs` / `exec node` and `buildLauncherShims`'
+    // documented contract, so a missing interpreter fails the same way on every
+    // OS. `process.execPath` is deliberately NOT used: the batch member cannot
+    // quote an interpreter argument (`<interpreter> "<target>" %*`), so a path
+    // like `C:\Program Files\nodejs\node.exe` would split, and a trio whose
+    // members disagree about which interpreter they re-enter is worse than one
+    // name resolved consistently.
+    const interpreter = gjs ? process.env.GJS_CONSOLE || 'gjs' : 'node';
+    const interpreterArgs = gjs ? ['-m'] : [];
+    const argv = interpreterArgs.length > 0 ? `${interpreterArgs.join(' ')} ` : '';
+    writeFileSync(shim, `#!/bin/sh\nexec "${interpreter}" ${argv}"${selfEntry}" "$@"\n`, { mode: 0o755 });
     chmodSync(shim, 0o755);
+    // cmd.exe and pwsh cannot run the extension-less member: it is not on
+    // PATHEXT and Windows has no shebang handling. npm's three-sibling answer
+    // is the de-facto standard, and `buildLauncherShims` is this repo's
+    // reviewed port of it — including the IF/ELSE ERRORLEVEL handling that
+    // `&&`/`||` chaining gets wrong.
+    if (!gjs && process.platform === 'win32') {
+        const { cmd, ps1 } = buildLauncherShims({ interpreter, interpreterArgs, target: selfEntry });
+        writeFileSync(`${shim}.cmd`, cmd);
+        writeFileSync(`${shim}.ps1`, ps1);
+    }
+    _selfShimActive = true;
     process.env.GJSIFY_SHIM_DIR = dir;
     process.env.PATH = dir + delimiter + (process.env.PATH ?? '');
 }

package/lib/utils/install-global.d.ts

@@ -29,8 +29,36 @@ export declare function defaultGlobalLayout(): GlobalLayout;
  * story already degrades on Node.
  */
 export declare const GJS_ENGINE_PACKAGES: readonly ["@gjsify/rolldown-native", "@gjsify/lightningcss-native", "@gjsify/oxfmt-native"];
-/** True when `<prefix>/node_modules/@gjsify/rolldown-native` is laid down. */
-export declare function hasBundlerEngineInstalled(prefix: string): boolean;
+/**
+ * The one engine whose absence is fatal rather than degrading: `gjsify build`
+ * has no fallback under GJS. Named separately because two different questions
+ * ("what do we install") and ("is a build possible") want different sets.
+ */
+export declare const BUNDLER_ENGINE_PACKAGE = "@gjsify/rolldown-native";
+/**
+ * True when a bundler engine `gjsify build` can actually LOAD is reachable from
+ * `dir`.
+ *
+ * This used to `existsSync` the bridge's own `package.json` and stop there. That
+ * answer was correct before ADR 0017 and is wrong after it: the bridge is now
+ * pure TypeScript (`files: ["lib", "meson.build", "src/rust", "src/vala"]`) and
+ * the binary lives in a per-target child (`@gjsify/rolldown-native-<os>-<arch>`).
+ * So "bridge present, child missing" reported `true` — which is why
+ * `self-update`'s repair gate could say "Already up to date" about a prefix whose
+ * engine cannot load. A live defect, not a hypothetical one.
+ *
+ * Asks `detectNativePackages` instead, which is the same walk-up
+ * `findRolldownNativeDir` performs at BUILD time. That matters more than the
+ * shortcut it replaces: an installer that disagrees with the builder about
+ * whether the engine is present is worse than one that is merely slow. It also
+ * makes the gjsify monorepo a no-op — the workspace symlink resolves — which is
+ * what keeps ADR 0001's non-destructive invariant safe from a registry copy
+ * landing on top of `packages/infra/rolldown-native`.
+ *
+ * `dir` is a prefix for a global install and a project root for a project one;
+ * the walk handles both.
+ */
+export declare function hasBundlerEngineInstalled(dir: string): boolean;
 /**
  * Best-effort install of the GJS-native engine packages into a global prefix.
  *

package/lib/utils/install-global.js

@@ -23,7 +23,7 @@
 import * as fs from 'node:fs';
 import * as os from 'node:os';
 import * as path from 'node:path';
-import { detectNativePackages } from './detect-native-packages.js';
+import { detectHostLibc, detectNativePackages, hostPlatformTokens, platformPackageName, } from './detect-native-packages.js';
 import { buildLauncherShims, buildNativeEnvPreamble, buildShLauncher, isGjsBundlePath, parseShebang, pickBinMap, } from './bin-shim.js';
 /**
  * Compute the canonical global install layout for the current user. Honours
@@ -63,9 +63,43 @@ export const GJS_ENGINE_PACKAGES = [
     '@gjsify/lightningcss-native',
     '@gjsify/oxfmt-native',
 ];
-/** True when `<prefix>/node_modules/@gjsify/rolldown-native` is laid down. */
-export function hasBundlerEngineInstalled(prefix) {
-    return fs.existsSync(path.join(prefix, 'node_modules', '@gjsify/rolldown-native', 'package.json'));
+/**
+ * The one engine whose absence is fatal rather than degrading: `gjsify build`
+ * has no fallback under GJS. Named separately because two different questions
+ * ("what do we install") and ("is a build possible") want different sets.
+ */
+export const BUNDLER_ENGINE_PACKAGE = '@gjsify/rolldown-native';
+/**
+ * True when a bundler engine `gjsify build` can actually LOAD is reachable from
+ * `dir`.
+ *
+ * This used to `existsSync` the bridge's own `package.json` and stop there. That
+ * answer was correct before ADR 0017 and is wrong after it: the bridge is now
+ * pure TypeScript (`files: ["lib", "meson.build", "src/rust", "src/vala"]`) and
+ * the binary lives in a per-target child (`@gjsify/rolldown-native-<os>-<arch>`).
+ * So "bridge present, child missing" reported `true` — which is why
+ * `self-update`'s repair gate could say "Already up to date" about a prefix whose
+ * engine cannot load. A live defect, not a hypothetical one.
+ *
+ * Asks `detectNativePackages` instead, which is the same walk-up
+ * `findRolldownNativeDir` performs at BUILD time. That matters more than the
+ * shortcut it replaces: an installer that disagrees with the builder about
+ * whether the engine is present is worse than one that is merely slow. It also
+ * makes the gjsify monorepo a no-op — the workspace symlink resolves — which is
+ * what keeps ADR 0001's non-destructive invariant safe from a registry copy
+ * landing on top of `packages/infra/rolldown-native`.
+ *
+ * `dir` is a prefix for a global install and a project root for a project one;
+ * the walk handles both.
+ */
+export function hasBundlerEngineInstalled(dir) {
+    const names = new Set(detectNativePackages(dir).map((p) => p.name));
+    if (names.has(BUNDLER_ENGINE_PACKAGE))
+        return true;
+    // The per-target child is the thing that actually carries the binary, so its
+    // presence is the honest positive answer even when the umbrella is absent.
+    const libc = detectHostLibc(process.platform);
+    return hostPlatformTokens(process.platform, process.arch, libc).some((token) => names.has(platformPackageName(BUNDLER_ENGINE_PACKAGE, token)));
 }
 /**
  * Best-effort install of the GJS-native engine packages into a global prefix.

package/lib/utils/oxc-resolve.d.ts

@@ -69,7 +69,7 @@ export declare function shouldUseNativeOxfmt(): Promise<boolean>;
  *
  * oxlint: always spawned via its Node ESM launcher on a real Node host
  * (`nodeBinary()`: `process.execPath` under Node, PATH `node` under the GJS
- * bundle where `process.execPath` is the bundle itself) so the JS plugin host
+ * bundle where `process.execPath` is the `gjs` interpreter) so the JS plugin host
  * is available — required for the `jsPlugins`-wired `gjsify/register-class-order`
  * rule. Under GJS a `node` on PATH is required (oxlint has no native bridge
  * yet); its absence surfaces as a clear OxcNotFoundError, never a hang.

package/lib/utils/oxc-resolve.js

@@ -53,6 +53,7 @@ import { pathToFileURL } from 'node:url';
 import { hostLibc } from './platform-check.js';
 import { findWorkspaceRoot } from './workspace-root.js';
 import { resolveNpmPackage } from './resolve-npm-package.js';
+import { activateNativePrebuilds } from './gi-search-path.js';
 import { nodeBinary } from './run-node.js';
 import { spawnToCompletion } from './spawn.js';
 import { isGjs, gjsExit } from '@gjsify/rolldown-plugin-gjsify/runtime';
@@ -245,6 +246,10 @@ async function tryLoadNativeOxfmt() {
         if (!isGjs())
             return null;
         try {
+            // Same reason as `bundler-pick.ts`'s `tryLoadNative()`: put the
+            // prebuild on girepository's own search paths so the bridge loads
+            // without the `gjsify` launcher having exported anything. ADR 0021.
+            activateNativePrebuilds();
             const specifier = '@gjsify/oxfmt-native';
             const resolved = resolveNpmPackage(specifier, { bundleUrl: import.meta.url }) ??
                 createRequire(import.meta.url).resolve(specifier);
@@ -293,7 +298,7 @@ export async function shouldUseNativeOxfmt() {
  *
  * oxlint: always spawned via its Node ESM launcher on a real Node host
  * (`nodeBinary()`: `process.execPath` under Node, PATH `node` under the GJS
- * bundle where `process.execPath` is the bundle itself) so the JS plugin host
+ * bundle where `process.execPath` is the `gjs` interpreter) so the JS plugin host
  * is available — required for the `jsPlugins`-wired `gjsify/register-class-order`
  * rule. Under GJS a `node` on PATH is required (oxlint has no native bridge
  * yet); its absence surfaces as a clear OxcNotFoundError, never a hang.
@@ -323,11 +328,10 @@ export async function runOxc(tool, args, opts = {}) {
 /**
  * Spawn an oxc tool via its Node ESM launcher (`node_modules/<tool>/bin/…`) on
  * a real Node host. CRITICAL: use `nodeBinary()`, not `process.execPath`
- * directly — under the committed GJS bundle `process.execPath` is the CLI
- * bundle path (`gjs`/the `.mjs`), so spawning it re-executes the CLI with the
- * launcher as its first positional (yargs prints top-level help) and the parent
- * hangs waiting on a child that never does the intended work. `nodeBinary()`
- * resolves to PATH `node` under GJS, so the launcher runs on Node as required.
+ * directly — under GJS `process.execPath` is the `gjs` interpreter, so spawning
+ * it runs the Node ESM launcher under GJS, where the plugin host does not exist.
+ * `nodeBinary()` resolves to PATH `node` under GJS, so the launcher runs on Node
+ * as required.
  *
  * `completion: 'return'`: `lint` / `format` / `fix` hand the tool's exit code
  * to `setOxcExitCode`, which deliberately does NOT terminate the process on a

package/lib/utils/stdin.d.ts

@@ -1,19 +1,9 @@
 /**
  * Read the whole of stdin as UTF-8. Works on Node and under the GJS bundle.
  *
- * Branches on WHICH RUNTIME CAN WORK, not on which capability is present. The
- * distinction matters because the two branches are not interchangeable:
- * `readFileSync(0)` is correct on Node/Bun/Deno and can NEVER work under GJS —
- * `@gjsify/fs` has no numeric-fd path, so the `0` is coerced to a relative
- * PATH and the call opens `./0`. A GJS run that reaches that line is already
- * lost, so using it as GJS's fallback only converts a clear failure into
- * `ENOENT … read '0'`, which is what a capability probe returning a false
- * negative did.
- *
- * So: the presence of `imports.gi` decides. On GJS both GJS readers are tried
- * and a failure THROWS with what was attempted; the Node reader is never
- * reached. Off GJS there is no gi namespace and `readFileSync(0)` is the only
- * and correct answer.
+ * Synchronous on purpose: the callers are CLI argument-parsing paths that run
+ * before any main loop exists, and the async `process.stdin` route carries the
+ * documented resume/pause races (see `utils/prompt.ts`).
  */
 export declare function readStdinText(): string;
 /**

package/lib/utils/stdin.js

@@ -1,119 +1,40 @@
 // SPDX-License-Identifier: MIT
 // Read ALL of stdin, on Node AND inside the committed GJS bundles.
 //
-// `readFileSync(0, 'utf-8')` is the Node idiom for "slurp stdin", and it is
-// what `gjsify affected --changed-from-stdin` used. It does NOT survive the
-// GJS bundle: `@gjsify/fs` has no numeric-file-descriptor path, so the `0` is
-// coerced to a PATH and the call opens the relative file `./0` — every GJS
-// caller died with
+// `readFileSync(0, 'utf-8')` is the Node idiom for "slurp stdin". It used NOT to
+// survive the GJS bundle: `@gjsify/fs` had no numeric-file-descriptor path, so
+// the `0` was coerced to a PATH and the call opened the relative file `./0` —
+// every GJS caller died with
 //
 //     Error: ENOENT: … read '0'   (readStdinLines → readFileSync)
 //
 // which silently disabled the ONE fixture-driven entry point AGENTS.md
 // documents for testing the CI classifier (`--changed-from-stdin`).
 //
-// Under GJS we therefore read fd 0 through `GioUnix.InputStream`. Two
-// deliberate choices:
+// THE GAP IS CLOSED AT THE CORE, so the workaround is gone: `@gjsify/fs` maps
+// the parent-supplied descriptors 0/1/2 onto the process's own Unix streams
+// (`packages/node/fs/src/std-fd.ts`, reached from `readFileSync` through
+// `sync.ts`), which makes the Node idiom mean the same thing under GJS. This
+// module used to carry two GJS-only readers for that gap — a
+// `GioUnix.InputStream` chunk loop and a `/dev/stdin` `Gio.File` fallback —
+// plus a runtime branch to choose between them. All three were consumer-side
+// repair for a missing core capability.
 //
-//   - `globalThis.imports.gi.GioUnix` rather than a `gi://GioUnix` import.
-//     `packages/infra/cli/lib/**` is ALSO the Node entry point of
-//     `@gjsify/cli` (`bin: lib/index.js`); a static `gi://` import anywhere
-//     reachable from it breaks `gjsify` on Node, and a dynamic one would need
-//     an `@girs/giounix-2.0` type dependency the CLI does not otherwise have.
-//     The legacy `imports.gi` form is the sanctioned GJS-bootstrap escape
-//     hatch (AGENTS.md "Reading globals", exception 4) and adds NO new typelib
-//     to the classifier bundle — `gi://GioUnix?version=2.0` is already in its
-//     import graph via `@gjsify/fs`.
-//   - a synchronous read. The callers are CLI argument-parsing paths that run
-//     before any main loop exists, and the async `process.stdin` route carries
-//     the documented resume/pause races (see `utils/prompt.ts`).
+// Anything re-adding a GJS branch HERE is re-adding the workaround. If stdin
+// misbehaves under GJS the defect is in `@gjsify/fs` and belongs there, with a
+// test — that is what made the branch removable in the first place
+// (`packages/node/fs/src/fd-ops.spec.ts` + `tests/e2e/fs-std-fd`, which needs a
+// real pipe and so cannot live in a unit spec).
 import { readFileSync } from 'node:fs';
-const CHUNK = 64 * 1024;
-/** Read fd 0 to EOF under GJS via GioUnix (no `@gjsify/fs` fd support needed). */
-function readStdinTextGioUnix() {
-    const gi = giNamespace();
-    const GioUnix = gi?.GioUnix;
-    if (typeof GioUnix?.InputStream !== 'function') {
-        throw new Error('GioUnix.InputStream is unavailable');
-    }
-    const stream = new GioUnix.InputStream({ fd: 0, close_fd: false });
-    const chunks = [];
-    let total = 0;
-    for (;;) {
-        const bytes = stream.read_bytes(CHUNK, null);
-        if (bytes.get_size() === 0)
-            break;
-        const arr = bytes.toArray();
-        chunks.push(arr);
-        total += arr.length;
-    }
-    if (total === 0)
-        return '';
-    const buf = new Uint8Array(total);
-    let offset = 0;
-    for (const c of chunks) {
-        buf.set(c, offset);
-        offset += c.length;
-    }
-    return new TextDecoder().decode(buf);
-}
-/**
- * Read stdin under GJS through Gio ALONE, without GioUnix.
- *
- * `/dev/stdin` is fd 0 by another name, and `Gio` is present in every bundle
- * that can reach this code at all. This exists because the GioUnix route has
- * been observed to be unavailable on a host where it should have worked, and a
- * second independent mechanism is cheaper than another round of guessing.
- */
-function readStdinTextGioFile() {
-    const gi = giNamespace();
-    const Gio = gi?.Gio;
-    if (!Gio?.File)
-        throw new Error('Gio.File is unavailable');
-    const [ok, contents] = Gio.File.new_for_path('/dev/stdin').load_contents(null);
-    if (!ok)
-        throw new Error('Gio.File.load_contents("/dev/stdin") returned false');
-    return new TextDecoder().decode(contents);
-}
-/**
- * The GJS `imports.gi` namespace, or `undefined` when not running on GJS.
- * Same optional-chained probe as `isGjs()` — off GJS `imports` is simply
- * absent and the read yields `undefined`; there is no throw path.
- */
-function giNamespace() {
-    return globalThis.imports?.gi;
-}
 /**
  * Read the whole of stdin as UTF-8. Works on Node and under the GJS bundle.
  *
- * Branches on WHICH RUNTIME CAN WORK, not on which capability is present. The
- * distinction matters because the two branches are not interchangeable:
- * `readFileSync(0)` is correct on Node/Bun/Deno and can NEVER work under GJS —
- * `@gjsify/fs` has no numeric-fd path, so the `0` is coerced to a relative
- * PATH and the call opens `./0`. A GJS run that reaches that line is already
- * lost, so using it as GJS's fallback only converts a clear failure into
- * `ENOENT … read '0'`, which is what a capability probe returning a false
- * negative did.
- *
- * So: the presence of `imports.gi` decides. On GJS both GJS readers are tried
- * and a failure THROWS with what was attempted; the Node reader is never
- * reached. Off GJS there is no gi namespace and `readFileSync(0)` is the only
- * and correct answer.
+ * Synchronous on purpose: the callers are CLI argument-parsing paths that run
+ * before any main loop exists, and the async `process.stdin` route carries the
+ * documented resume/pause races (see `utils/prompt.ts`).
  */
 export function readStdinText() {
-    if (!giNamespace())
-        return readFileSync(0, 'utf-8');
-    const attempts = [];
-    for (const read of [readStdinTextGioUnix, readStdinTextGioFile]) {
-        try {
-            return read();
-        }
-        catch (err) {
-            attempts.push(`${read.name}: ${err.message}`);
-        }
-    }
-    throw new Error(`gjsify: cannot read stdin under GJS. Tried ${attempts.join('; ')}. ` +
-        'Pass the input as an argument instead (e.g. --base <ref> rather than --changed-from-stdin).');
+    return readFileSync(0, 'utf-8');
 }
 /**
  * Read stdin and split it into trimmed, non-empty lines. Accepts LF and CRLF

package/lib/utils/system-gi.js

@@ -87,7 +87,16 @@
 // bundle's first line runs.
 import { spawnSync } from 'node:child_process';
 import { statSync } from 'node:fs';
-import { basename, dirname, join } from 'node:path';
+// POSIX path semantics, not the HOST's. This function answers a question about
+// a darwin filesystem — `platform` is a PARAMETER, so the host running the code
+// may be any of the three. Node's default `join`/`dirname`/`basename` follow the
+// host, so on win32 `join('/usr/local/lib', 'girepository-1.0')` becomes
+// `\usr\local\lib\girepository-1.0` and never matches the darwin path the
+// caller (or the injected `existsDir`) is holding. Measured on the Windows leg:
+// three `systemGiLibraryDirs` specs returned `[]` where they assert a prefix.
+// `PROBED_GI_LIBDIRS` is darwin-only, so POSIX is always the right dialect here.
+import { posix } from 'node:path';
+const { basename, dirname, join } = posix;
 /**
  * Prefixes a macOS GI stack is installed under in practice — probed, never
  * assumed: each is accepted only when it actually holds a `girepository-1.0/`.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/cli",
-    "version": "0.30.0",
+    "version": "0.31.0",
     "description": "CLI for Gjsify",
     "type": "module",
     "main": "lib/index.js",
@@ -101,6 +101,11 @@
             "__PACKAGE_VERSION__": {
                 "field": "version"
             }
+        },
+        "os": {
+            "linux": "supported",
+            "darwin": "supported",
+            "win32": "supported"
         }
     },
     "files": [
@@ -129,19 +134,19 @@
         "cli"
     ],
     "dependencies": {
-        "@gjsify/buffer": "^0.30.0",
-        "@gjsify/create-app": "^0.30.0",
-        "@gjsify/node-globals": "^0.30.0",
-        "@gjsify/node-polyfills": "^0.30.0",
-        "@gjsify/npm-registry": "^0.30.0",
-        "@gjsify/resolve-npm": "^0.30.0",
-        "@gjsify/rolldown-plugin-gjsify": "^0.30.0",
-        "@gjsify/rolldown-plugin-pnp": "^0.30.0",
-        "@gjsify/semver": "^0.30.0",
-        "@gjsify/tar": "^0.30.0",
-        "@gjsify/tsc": "^0.30.0",
-        "@gjsify/web-polyfills": "^0.30.0",
-        "@gjsify/workspace": "^0.30.0",
+        "@gjsify/buffer": "^0.31.0",
+        "@gjsify/create-app": "^0.31.0",
+        "@gjsify/node-globals": "^0.31.0",
+        "@gjsify/node-polyfills": "^0.31.0",
+        "@gjsify/npm-registry": "^0.31.0",
+        "@gjsify/resolve-npm": "^0.31.0",
+        "@gjsify/rolldown-plugin-gjsify": "^0.31.0",
+        "@gjsify/rolldown-plugin-pnp": "^0.31.0",
+        "@gjsify/semver": "^0.31.0",
+        "@gjsify/tar": "^0.31.0",
+        "@gjsify/tsc": "^0.31.0",
+        "@gjsify/web-polyfills": "^0.31.0",
+        "@gjsify/workspace": "^0.31.0",
         "cosmiconfig": "^9.0.2",
         "get-tsconfig": "^4.14.0",
         "pkg-types": "^2.3.1",
@@ -149,13 +154,13 @@
         "yargs": "^18.0.0"
     },
     "devDependencies": {
-        "@gjsify/unit": "^0.30.0",
+        "@gjsify/unit": "^0.31.0",
         "@types/yargs": "^17.0.35",
         "typescript": "^6.0.3"
     },
     "peerDependencies": {
-        "@gjsify/oxfmt-native": "^0.30.0",
-        "@gjsify/rolldown-native": "^0.30.0"
+        "@gjsify/oxfmt-native": "^0.31.0",
+        "@gjsify/rolldown-native": "^0.31.0"
     },
     "peerDependenciesMeta": {
         "@gjsify/oxfmt-native": {