commandmate 0.26.1 → 0.27.0

package/dist/server/src/lib/cli-tools/composer-spec.js

@@ -0,0 +1,96 @@
+"use strict";
+/**
+ * What each tool's composer is, in one declaration per tool (Issue #1933, §6.3).
+ *
+ * Before this module `submit-verified-sender.ts` carried the same knowledge as
+ * three unrelated module-level tables — `INPUT_LINE_MARKER_TOOLS`, a
+ * `cliToolId === 'opencode'` branch in `verifyCaptureLines()`, and
+ * `COMPOSER_CLEAR_SUPPORTED_TOOLS` — plus a fourth fact (`submitEnterCount`)
+ * that only vibe-local's call site knew. Adding a tool meant finding four
+ * places, and #1906 is what happens when one of them is missed: opencode went
+ * through the marker reader, never matched, and every opencode send was
+ * classified `submitted` without evidence for the whole life of #1471's
+ * recovery.
+ *
+ * ## Why the table is here rather than only on the tool classes
+ *
+ * `BaseCLITool.describeComposer()` answers from this function and every tool
+ * may override it, which is the §4 D4 shape. The lookup still exists because
+ * `sendMessageWithSubmitVerification` is imported *by* the tool modules: asking
+ * it to reach back for a tool instance would put a cycle under every send. So
+ * the sender takes a `ComposerSpec` when it is given one and resolves the
+ * tool's default here when it is not, and both roads lead to this one table.
+ *
+ * @module lib/cli-tools/composer-spec
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DEFAULT_COMPOSER_SPEC = exports.COMPOSER_VERIFY_WINDOW_LINES = void 0;
+exports.resolveComposerSpec = resolveComposerSpec;
+const tmux_pane_config_1 = require("../../config/tmux-pane-config");
+/**
+ * Rows of pane tail read back when verifying a submit on a marker tool.
+ *
+ * The composer is the last thing on those panes, so a short tail is enough and
+ * keeps `capture-pane` cheap.
+ */
+exports.COMPOSER_VERIFY_WINDOW_LINES = 12;
+/**
+ * The claude-shaped default, which is also `BaseCLITool`'s.
+ *
+ * A marked input line at the bottom of the pane, a twelve-row read-back, one
+ * Enter to submit, and the composer emptied before the body is typed (#1880 —
+ * claude is the tool that was measured for it).
+ */
+exports.DEFAULT_COMPOSER_SPEC = {
+    reader: 'input-line-marker',
+    verifyCaptureLines: exports.COMPOSER_VERIFY_WINDOW_LINES,
+    clearBeforeSend: true,
+    submitEnterCount: 1,
+};
+/**
+ * Per-tool composer descriptions.
+ *
+ * Every value is the behaviour that was already in force before this Issue;
+ * `tests/unit/cli-tools/composer-spec-1933.test.ts` pins each one against the
+ * constant or the call site it came from, so this is a move, not a redesign.
+ */
+const COMPOSER_SPECS = {
+    claude: exports.DEFAULT_COMPOSER_SPEC,
+    // Joined the clear-before-send path in #1890: shipping #1880 claude-only left
+    // codex measurably broken (its ケース7 reproduced the splice verbatim).
+    codex: exports.DEFAULT_COMPOSER_SPEC,
+    // Marker tools whose input box has NOT been captured at the production
+    // geometry, so `clearComposer` cannot observe them and must not blind-fire
+    // `C-e`+`C-u` into a box nobody has measured (#1880).
+    gemini: { ...exports.DEFAULT_COMPOSER_SPEC, clearBeforeSend: false },
+    copilot: { ...exports.DEFAULT_COMPOSER_SPEC, clearBeforeSend: false },
+    antigravity: { ...exports.DEFAULT_COMPOSER_SPEC, clearBeforeSend: false },
+    // vibe-local's IME mode makes the first Enter insert a newline, so the
+    // initial submit is two presses (see VIBE_LOCAL_DOUBLE_ENTER_WAIT_MS).
+    'vibe-local': { ...exports.DEFAULT_COMPOSER_SPEC, clearBeforeSend: false, submitEnterCount: 2 },
+    // opencode draws a bordered box with a gutter and no marker anywhere, and it
+    // centres that box under the banner until the first turn is answered —
+    // roughly 100 rows above the bottom of a 200-row pane. A twelve-row tail of a
+    // first send therefore contains nothing but blank padding and the cwd footer,
+    // which is why the read-back asks for the whole visible frame (#1906,
+    // measured live on opencode 1.18.21). It runs in the alternate screen with no
+    // scrollback, so the frame is all there is.
+    opencode: {
+        reader: 'opencode-box',
+        verifyCaptureLines: tmux_pane_config_1.OPENCODE_PANE_HEIGHT,
+        clearBeforeSend: false,
+        submitEnterCount: 1,
+    },
+};
+/**
+ * The composer description for a CLI tool.
+ *
+ * @param cliToolId - CLI tool identifier
+ * @returns That tool's {@link ComposerSpec}; the claude-shaped default for an
+ *   id outside `CLI_TOOL_IDS` (a JavaScript caller or a cast — the default's
+ *   reader is the conservative one, since an unreadable composer classifies
+ *   every send as submitted without evidence)
+ */
+function resolveComposerSpec(cliToolId) {
+    return COMPOSER_SPECS[cliToolId] ?? exports.DEFAULT_COMPOSER_SPEC;
+}

package/dist/server/src/lib/cli-tools/copilot-executable.js

@@ -0,0 +1,155 @@
+"use strict";
+/**
+ * Where GitHub Copilot CLI actually is, and whether it is actually there
+ * (Issue #1907).
+ *
+ * ## Why this is not `gh copilot --help`
+ *
+ * `CopilotTool.isInstalled()` used to answer "is copilot installed?" with
+ * `gh --version` followed by `gh copilot --help`. Measured on gh 2.86.0 with an
+ * empty `gh extension list`, the second command exits 0 in ~20 ms on a machine
+ * where the extension does not exist, because `copilot` is no longer an
+ * extension at all -- it is a preview command built into `gh`, and the help text
+ * it prints says so itself:
+ *
+ * > If already installed, `gh` will execute the Copilot CLI found in your
+ * > `PATH`. If the Copilot CLI is not installed, it will be downloaded to
+ * > ~/.local/share/gh/copilot.
+ *
+ * So the old check proved that `gh` was installed and nothing more. The
+ * consequence was not a wrong badge: `startSession` typed `gh copilot` into the
+ * pane, gh started *downloading* copilot there, `waitForReady` spun its whole
+ * window against a progress bar, and the launch was logged as a success.
+ *
+ * This module answers the question with positive evidence instead (方針書 §4
+ * D1): an executable file that exists, and a `--version` that exits 0 and prints
+ * a version. Nothing here infers presence from the absence of an error.
+ *
+ * ## Why the path is resolved before it is run
+ *
+ * `copilot` is a common word and the probe runs with the server's privileges, so
+ * the candidate is resolved out of `PATH` to an absolute path first, checked to
+ * be an executable *file*, and only then handed to `execFile` with a bounded
+ * timeout, a bounded `maxBuffer` and `sanitizeEnvForChildProcess()`. This is the
+ * rule 方針書 §10.11 / DR4-010 states for version probes; it applies here for the
+ * same reason, since this is the probe that decides what gets launched.
+ *
+ * @module lib/cli-tools/copilot-executable
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.COPILOT_VERSION_PROBE_TIMEOUT_MS = void 0;
+exports.findExecutableOnPath = findExecutableOnPath;
+exports.resolveCopilotExecutable = resolveCopilotExecutable;
+const child_process_1 = require("child_process");
+const fs_1 = require("fs");
+const os_1 = require("os");
+const path_1 = require("path");
+const env_sanitizer_1 = require("../security/env-sanitizer");
+/** Executable name on `PATH`. */
+const COPILOT_BINARY_NAME = 'copilot';
+/** gh's own executable name; the `gh-managed` copy is launched through it. */
+const GH_BINARY_NAME = 'gh';
+/** Budget for one `--version` call. Matches the old two-stage check's per-stage timeout. */
+exports.COPILOT_VERSION_PROBE_TIMEOUT_MS = 5000;
+/** Bounded output for the probe (DR4-009): `--version` prints two short lines. */
+const COPILOT_VERSION_PROBE_MAX_BUFFER = 64 * 1024;
+/**
+ * The version in `GitHub Copilot CLI 1.0.80.` — required, not optional.
+ *
+ * An exit code of 0 alone is what made the previous check useless, so a
+ * `--version` that succeeds while printing nothing recognisable is treated as no
+ * evidence at all.
+ */
+const COPILOT_VERSION_PATTERN = /(\d+\.\d+\.\d+(?:[-+][0-9A-Za-z.-]+)?)/;
+/** True when `candidate` is a regular file this process may execute. */
+function isExecutableFile(candidate) {
+    try {
+        if (!(0, fs_1.statSync)(candidate).isFile())
+            return false;
+        (0, fs_1.accessSync)(candidate, fs_1.constants.X_OK);
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * First executable named `name` on `PATH`, as an absolute path.
+ *
+ * Exported since Issue #1929: `DETECTOR_VERSION_PROBES` has to resolve every
+ * probe command the same way before executing it (DR4-010 (2)), and a second
+ * copy of this walk is exactly the "two probe mechanisms with different trust
+ * models" DR4-010 exists to prevent. The name stays generic because the walk
+ * is; what is copilot-specific is the caller below.
+ */
+function findExecutableOnPath(name) {
+    const rawPath = process.env.PATH;
+    if (!rawPath)
+        return null;
+    for (const directory of rawPath.split(path_1.delimiter)) {
+        if (!directory)
+            continue;
+        const candidate = (0, path_1.join)(directory, name);
+        if (isExecutableFile(candidate))
+            return candidate;
+    }
+    return null;
+}
+/**
+ * Where `gh copilot` puts the copy it downloads.
+ *
+ * gh names `~/.local/share/gh/copilot` in its own help output and honours
+ * `XDG_DATA_HOME`. Both a bare file at that path and a directory containing the
+ * binary are accepted, because which of the two gh writes is gh's business and
+ * guessing wrong here would silently report "not installed".
+ */
+function ghManagedCandidates() {
+    const dataHome = process.env.XDG_DATA_HOME || (0, path_1.join)((0, os_1.homedir)(), '.local', 'share');
+    const base = (0, path_1.join)(dataHome, 'gh', COPILOT_BINARY_NAME);
+    return [base, (0, path_1.join)(base, COPILOT_BINARY_NAME)];
+}
+/** Run `<executable> --version`; the version string, or null for any failure. */
+function probeVersion(executable) {
+    return new Promise((resolve) => {
+        (0, child_process_1.execFile)(executable, ['--version'], {
+            timeout: exports.COPILOT_VERSION_PROBE_TIMEOUT_MS,
+            maxBuffer: COPILOT_VERSION_PROBE_MAX_BUFFER,
+            env: (0, env_sanitizer_1.sanitizeEnvForChildProcess)(),
+        }, (error, stdout, stderr) => {
+            if (error) {
+                resolve(null);
+                return;
+            }
+            const match = COPILOT_VERSION_PATTERN.exec(`${stdout ?? ''}\n${stderr ?? ''}`);
+            resolve(match ? match[1] : null);
+        });
+    });
+}
+/**
+ * The copilot this machine would actually run, or null when there is none.
+ *
+ * `PATH` first, gh's managed copy second — the order the operator experiences,
+ * and the order gh itself uses. Never throws: an unreadable directory, a missing
+ * `PATH`, a probe that times out are all "no evidence", which is the answer that
+ * makes `startSession` refuse instead of starting a download in the pane.
+ */
+async function resolveCopilotExecutable() {
+    const onPath = findExecutableOnPath(COPILOT_BINARY_NAME);
+    if (onPath) {
+        const version = await probeVersion(onPath);
+        if (version)
+            return { path: onPath, version, source: 'path' };
+    }
+    // The managed copy is only reachable through `gh copilot`, so a machine
+    // without gh cannot launch it however present the file is.
+    if (!findExecutableOnPath(GH_BINARY_NAME))
+        return null;
+    for (const candidate of ghManagedCandidates()) {
+        if (!isExecutableFile(candidate))
+            continue;
+        const version = await probeVersion(candidate);
+        if (version)
+            return { path: candidate, version, source: 'gh-managed' };
+    }
+    return null;
+}