commandmate 0.27.1 → 0.29.0

package/dist/server/src/lib/skills/compatibility-matrix.js

@@ -90,6 +90,14 @@ exports.AGENT_LIMITATION_MESSAGE_KEYS = {
 /** Evidence reference for the 2026-07-26 isolated-environment measurement. */
 const G4_EVIDENCE_SOURCE = 'https://github.com/Kewton/CommandMate/issues/1513#issuecomment-5083878264';
 const MEASURED_DATE_2026_07_26 = '2026-07-26';
+/**
+ * Evidence reference for the opencode 1.18.22 measurement (Issue #2037).
+ *
+ * The design note is the primary record — it carries the harness, the controls
+ * and the raw endpoint output, which an issue comment cannot.
+ */
+const OPENCODE_EVIDENCE_SOURCE = 'https://github.com/Kewton/CommandMate/blob/main/docs/design/opencode-server-live-verification.md#11-issue-2036--2037-opencode-11822-2026-08-25';
+const MEASURED_DATE_2026_08_25 = '2026-08-25';
 function unmeasuredEntry(agent) {
     return {
         agent,
@@ -174,7 +182,48 @@ const AGENT_DISCOVERY_MATRIX = [
     },
     unmeasuredEntry('gemini'),
     unmeasuredEntry('vibe-local'),
-    unmeasuredEntry('opencode'),
+    {
+        agent: 'opencode',
+        // Measured, not read off the docs. The docs do say opencode scans
+        // `.claude/skills` and `.agents/skills`, and Issue #2037 said outright that
+        // this would probably come back `native` — neither is why this row is what
+        // it is. Six probe Skills were planted, one per candidate root, each told to
+        // answer a unique token; `GET /skill` returned all six with their absolute
+        // SKILL.md paths, including both roots below.
+        discoveryRoots: [constants_1.SKILL_INSTALL_ROOT_PREFIX, constants_1.SKILL_CLAUDE_INSTALL_ROOT_PREFIX],
+        discovery: {
+            outcome: 'verified',
+            evidenceKind: 'mechanical',
+            labelKey: exports.AGENT_AXIS_OUTCOME_LABEL_KEYS.verified,
+            evidenceKindKey: exports.AGENT_EVIDENCE_KIND_LABEL_KEYS.mechanical,
+            limitationKey: null,
+        },
+        invocation: {
+            // Submitting `/probe-agents-root` loaded that Skill's instructions and the
+            // agent answered `PROBE_OK_probe-agents-root`; `.claude/skills` answered
+            // its own token the same way. That is a slash command that runs, so this
+            // is `verified` rather than codex's `unsupported`.
+            //
+            // The limitation is narrower than "no slash command" and is recorded as
+            // one anyway: opencode's *own* palette does not offer Skills (typing the
+            // full name shows "No matching items" — positive control `/status` matched
+            // its own row, negative control `/zzzznotacommand` matched nothing), so
+            // without CommandMate's palette the route is invisible. The `/skills`
+            // picker is opencode's own way in, and it inserts exactly this `/name`.
+            outcome: 'verified',
+            evidenceKind: 'mechanical',
+            labelKey: exports.AGENT_AXIS_OUTCOME_LABEL_KEYS.verified,
+            evidenceKindKey: exports.AGENT_EVIDENCE_KIND_LABEL_KEYS.mechanical,
+            limitationKey: exports.AGENT_LIMITATION_MESSAGE_KEYS.NO_SLASH_COMMAND,
+        },
+        testedVersion: '1.18.22',
+        testedDate: MEASURED_DATE_2026_08_25,
+        evidenceSource: OPENCODE_EVIDENCE_SOURCE,
+        // Also measured: the server scans commands and Skills once at boot and
+        // caches them, so a freshly installed Skill appears only after a restart.
+        reloadKey: exports.AGENT_RELOAD_MESSAGE_KEYS.SESSION_RESTART,
+        skipReasonKey: null,
+    },
     unmeasuredEntry('copilot'),
     // CommandMate's own slash palette serves `.agents/skills` entries to
     // antigravity sessions (#1504). That is CommandMate injecting a command, not

package/dist/server/src/lib/tmux/tmux.js

@@ -13,6 +13,7 @@ exports.listSessions = listSessions;
 exports.createSession = createSession;
 exports.sendKeys = sendKeys;
 exports.sendKeySequence = sendKeySequence;
+exports.isSendableSpecialKey = isSendableSpecialKey;
 exports.sendSpecialKeys = sendSpecialKeys;
 exports.capturePane = capturePane;
 exports.killSession = killSession;
@@ -381,16 +382,58 @@ async function sendKeySequence(sessionName, steps) {
  * Restricts input to prevent command injection via arbitrary tmux key names.
  *
  * Separate from ALLOWED_SINGLE_SPECIAL_KEYS which covers control keys for sendSpecialKey().
+ *
+ * INVARIANT (Issue #2032): `NAVIGATION_KEY_VALUES` ⊆ this set. The special-keys API
+ * publishes `NAVIGATION_KEY_VALUES` as its accepted vocabulary, and every key it
+ * accepts must be deliverable here — otherwise the route validates a request and
+ * then throws while sending it. The relation is one-way containment, NOT equality:
+ * `Space` / `BSpace` / `DC` are sendable but deliberately absent from the navigation
+ * vocabulary, so asserting set equality would be wrong.
+ * Pinned by tests/unit/tmux/special-keys-allowlist-2032.test.ts.
  */
 const ALLOWED_SPECIAL_KEYS = new Set([
     'Up', 'Down', 'Left', 'Right',
     'Enter', 'Space', 'Tab', 'Escape',
+    // Issue #2032: BTab (back-tab / Shift-Tab) has been part of the special-keys API
+    // vocabulary since Issue #473 but was never added here, so `POST
+    // /api/worktrees/[id]/special-keys` with `["BTab"]` passed validation and then
+    // threw `Invalid special key: BTab` inside sendSpecialKeys() → HTTP 500.
+    'BTab',
     'BSpace', 'DC', // Backspace, Delete
     // Issue #1017: Codex pager / edit-previous mode navigation. PageUp/PageDown/Home/End
     // are tmux named keys; 'q' is the pager's literal "quit" character (sent verbatim by
     // `tmux send-keys`, no injection risk — single fixed char via execFile, not a shell).
     'PageUp', 'PageDown', 'Home', 'End', 'q',
+    // Issue #2046: opencode's own chords. `C-x` is its leader prefix (measured
+    // default of 1.18.22, 2000 ms window), `C-p` opens the command palette and
+    // `C-t` cycles the model variant. The lower-case letters complete a leader
+    // chord and are LITERAL characters on the wire, exactly like `q` above —
+    // `tmux send-keys -- a` types an `a`.
+    //
+    // Widening the transport does NOT widen what any pane can be sent: since
+    // #2046 the special-keys route validates each key against the requested
+    // tool's own `navigationKeys()` declaration, so `a` is deliverable here but
+    // only opencode declares it. Every other caller of `sendSpecialKeys()`
+    // (`prompt-answer-sender`, the submit-verified sender, the tool classes)
+    // passes fixed key names it wrote itself, so nothing here becomes reachable
+    // from user-controlled text.
+    'C-x', 'C-p', 'C-t',
+    'a', 'l', 'n', 't', 'm', 'g', 'u', 'r', 'c',
 ]);
+/**
+ * Type guard for "sendSpecialKeys() will actually deliver this key" (Issue #2032).
+ *
+ * Exported so callers can pre-flight a key against the transport's allow-list
+ * instead of discovering the rejection as a thrown error mid-send, and so the
+ * `NAVIGATION_KEY_VALUES` ⊆ `ALLOWED_SPECIAL_KEYS` invariant is observable from a
+ * test without exposing the mutable Set itself.
+ *
+ * @param key - String to validate
+ * @returns True if sendSpecialKeys() accepts the key
+ */
+function isSendableSpecialKey(key) {
+    return ALLOWED_SPECIAL_KEYS.has(key);
+}
 /** Delay between individual key presses for TUI apps that need processing time (ms). */
 const SPECIAL_KEY_DELAY_MS = 100;
 /**
@@ -693,15 +736,42 @@ async function clearComposerLine(sessionName) {
 }
 /**
  * Type guard for navigation key validation (special-keys API).
- * Returns true if the key is in the NAVIGATION_KEY_VALUES set.
+ * Returns true if the key is in the NAVIGATION_KEY_VALUES set AND sendSpecialKeys()
+ * can actually deliver it.
  * Named "SpecialKey" to align with the special-keys API route that calls it,
  * though it validates NavigationKey (a subset of all special keys).
  *
+ * Issue #2046 — `vocabulary` is the *declaring tool's* key list
+ * (`ICLITool.navigationKeys().keys`), which the route passes in. It defaults to
+ * `NAVIGATION_KEY_VALUES` so a caller that has no tool in hand keeps the exact
+ * pre-#2046 behaviour, and so the #2032 pin below still reads as it was written.
+ * The transport half (`isSendableSpecialKey`) is unconditional either way: the
+ * invariant is "everything a tool declares is deliverable", quantified over the
+ * registry instead of over one global list.
+ *
+ * Issue #2032 — why the transport check lives in the *input validation* guard, i.e.
+ * why a vocabulary/transport divergence answers 400 and not 500:
+ *
+ * - The caller-visible contract of the endpoint is "the keys I may send". A key the
+ *   transport refuses is, from the caller's side, a key that cannot be sent — the
+ *   only actionable response is "send a different key", which is exactly what 4xx
+ *   means. 500 tells the caller "retry later, the server broke", and retrying a
+ *   `BTab` that will never be deliverable is not actionable.
+ * - Letting it reach sendSpecialKeys() converts the same condition into a thrown
+ *   error that the route can only report as an opaque 500, i.e. the divergence is
+ *   laundered into "server fault" and shows up in error dashboards as an outage.
+ * - The divergence really *is* a server-side configuration bug, but it is one the
+ *   build must catch, not production: the `NAVIGATION_KEY_VALUES` ⊆
+ *   `ALLOWED_SPECIAL_KEYS` invariant is pinned by
+ *   tests/unit/tmux/special-keys-allowlist-2032.test.ts, so this branch is a
+ *   defense-in-depth backstop that cannot fire in a green build.
+ *
  * @param key - String to validate
- * @returns True if key is a valid NavigationKey
+ * @param vocabulary - The declaring tool's key list (defaults to `NAVIGATION_KEY_VALUES`)
+ * @returns True if key is in `vocabulary` AND sendSpecialKeys() can deliver it
  */
-function isAllowedSpecialKey(key) {
-    return terminal_keys_1.NAVIGATION_KEY_VALUES.includes(key);
+function isAllowedSpecialKey(key, vocabulary = terminal_keys_1.NAVIGATION_KEY_VALUES) {
+    return vocabulary.includes(key) && isSendableSpecialKey(key);
 }
 /**
  * Send special keys to a tmux session and invalidate the capture cache.

package/dist/server/src/lib/verification/gate-runner.js

@@ -50,6 +50,11 @@ const verify_config_1 = require("./verify-config");
 Object.defineProperty(exports, "ENV_CLEAN_GATE_ID", { enumerable: true, get: function () { return verify_config_1.ENV_CLEAN_GATE_ID; } });
 Object.defineProperty(exports, "SCOPE_GATE_ID", { enumerable: true, get: function () { return verify_config_1.SCOPE_GATE_ID; } });
 Object.defineProperty(exports, "WORK_EVIDENCE_GATE_ID", { enumerable: true, get: function () { return verify_config_1.WORK_EVIDENCE_GATE_ID; } });
+// Issue #2043: the second work-evidence witness. opencode-only by construction
+// -- it answers null for every other tool -- so this import adds no behaviour
+// to any run that is not judging an opencode instance.
+const diff_1 = require("../../lib/hooks/sources/opencode/diff");
+const tool_id_1 = require("../../lib/hooks/sources/opencode/tool-id");
 const logger = (0, logger_1.createLogger)('lib/verification/gate-runner');
 /**
  * Pseudo-gate used to carry a config-load failure into the run record.
@@ -558,9 +563,26 @@ function runGit(args, cwd) {
         child.on('close', (code) => resolve({ code, stdout }));
     });
 }
-// =============================================================================
-// Built-in work-evidence gate
-// =============================================================================
+/**
+ * Whether this run is judging an opencode instance (Issue #2043).
+ *
+ * **An unnamed instance answers `false`, deliberately.** work-evidence's git
+ * counts are worktree-wide, so a bare `wait --verify` on a worktree that also
+ * happens to run an opencode pane would otherwise start reading that pane's
+ * diff into a verdict about a claude session. The rule Issue #2043 was given is
+ * that no other tool's judgement moves by a byte, and the way to guarantee that
+ * is to consult the second witness only when the caller pointed at it --
+ * `wait --instance opencode --verify`, or a `verify` naming an opencode
+ * instance from the roster.
+ */
+function namesOpencodeInstance(db, worktreeId, instanceId) {
+    if (instanceId === undefined)
+        return false;
+    // The primary instance is addressed by the tool id itself.
+    if (instanceId === tool_id_1.OPENCODE_CLI_TOOL_ID)
+        return true;
+    return (0, db_1.getAgentInstances)(db, worktreeId).some((instance) => instance.id === instanceId && instance.cliTool === tool_id_1.OPENCODE_CLI_TOOL_ID);
+}
 /**
  * Decide whether the worktree contains work at all.
  *
@@ -571,8 +593,29 @@ function runGit(args, cwd) {
  *
  * Contract files are evidence of the *orchestrator*, not of the agent, so
  * neither side counts them (see {@link CONTRACT_DIR_PREFIX}).
+ *
+ * ## The opencode second witness (Issue #2043)
+ *
+ * **Strictly additive, and only in the branch that would otherwise fail.** The
+ * git counts above are computed and interpreted exactly as they were; the only
+ * new behaviour is that a run which found *nothing at all* asks opencode
+ * whether it names files before reporting `not_started`. Every other tool
+ * reaches {@link opencodeWorkEvidenceFileCount} as `null` and takes the same
+ * path it always did.
+ *
+ * The reason it is worth asking is the feature #2043 adds: **its revert button
+ * can make a worktree look untouched to git** while opencode still holds the
+ * turn's whole file list. `requireCommit` is deliberately *not* relaxed — a
+ * diff opencode is holding is not a commit — so a repository that demands one
+ * still gets the same verdict.
+ *
+ * Measured limit, so this is not read as more than it is: opencode's ledger is
+ * git snapshots and shares git's blind spots. A `.gitignore`d file the agent
+ * created was invisible to `git status` **and** answered `[]` from
+ * `GET /session/:id/diff` (`docs/design/opencode-server-live-verification.md`
+ * §16.6). This corroborates git; it does not see past it.
  */
-async function evaluateWorkEvidence(worktreePath, baseRef, requireCommit) {
+async function evaluateWorkEvidence(worktreePath, baseRef, requireCommit, agentEvidence) {
     const startedAt = Date.now();
     const done = (status, logTail, exitCode) => ({
         status,
@@ -621,7 +664,16 @@ async function evaluateWorkEvidence(worktreePath, baseRef, requireCommit) {
         (requireCommit.required ? ' requireCommit=true' : '') +
         ' (contract files excluded)';
     if (!Number.isFinite(commitCount) || (commitCount === 0 && uncommittedCount === 0)) {
-        return done('failed', `${summary}\nNo commits and no uncommitted changes: nothing to verify.`, 1);
+        // Issue #2043, and the ONLY place this gate's verdict differs from what it
+        // was: git found nothing, so ask the agent. `null` — every tool but
+        // opencode, and every opencode pane that never reported a turn — falls
+        // straight through to the same failure as before.
+        const agentFiles = Number.isFinite(commitCount) ? agentEvidence.fileCount() : null;
+        if (agentFiles === null || agentFiles === 0) {
+            return done('failed', `${summary}\nNo commits and no uncommitted changes: nothing to verify.`, 1);
+        }
+        return done('passed', `${summary}\n${agentEvidence.label}: ${agentFiles} file(s) changed. ` +
+            'git found nothing; the agent did.', 0);
     }
     // Issue #1628 (D-4): `commits=0 uncommitted=1` passing is what let a task
     // contract that says "未 commit の作業は未完了とみなされる" still end in
@@ -757,9 +809,20 @@ function aggregateRunStatus(gateStatuses) {
         return 'error';
     return 'passed';
 }
-async function executeRun(db, runId, worktreeId, worktreePath, config, selection, baseRef, task, detachedContract, envClean) {
+async function executeRun(db, runId, worktreeId, worktreePath, 
+/** Issue #2043: which agent instance the run is judging, for the second witness. */
+instanceId, config, selection, baseRef, task, detachedContract, envClean) {
     const { maxLogTailBytes, skipInPrimaryCheckout } = config.options;
     const { runWorkEvidence, gates } = selection;
+    // Issue #2043. A thunk rather than a number so the store is read at the
+    // instant the gate runs, not at the instant the run was set up — a turn can
+    // finish in between.
+    const agentEvidence = {
+        label: 'opencode session diff',
+        fileCount: () => namesOpencodeInstance(db, worktreeId, instanceId)
+            ? (0, diff_1.opencodeWorkEvidenceFileCount)(worktreeId, instanceId)
+            : null,
+    };
     // ORed with the repository-wide switch rather than replacing it (#1642): a
     // delegation may tighten the rule, never relax one the repository declared.
     const requireCommit = (0, contract_message_1.resolveRequireCommit)(task?.contract ?? null, config);
@@ -826,7 +889,7 @@ async function executeRun(db, runId, worktreeId, worktreePath, config, selection
     };
     const statuses = [];
     if (runWorkEvidence) {
-        const outcome = await runGate(verify_config_1.WORK_EVIDENCE_GATE_ID, WORK_EVIDENCE_GATE_COMMAND, 'builtin', () => evaluateWorkEvidence(worktreePath, baseRef, requireCommit));
+        const outcome = await runGate(verify_config_1.WORK_EVIDENCE_GATE_ID, WORK_EVIDENCE_GATE_COMMAND, 'builtin', () => evaluateWorkEvidence(worktreePath, baseRef, requireCommit, agentEvidence));
         if (outcome.status !== 'passed') {
             // Nothing was produced, so every command gate below would be judging the
             // base commit. Record them as skipped so the run shows what was not run.
@@ -1142,7 +1205,7 @@ async function startVerification(input) {
         await acquireSlot();
         let terminalStatus = 'error';
         try {
-            const status = await executeRun(db, run.id, input.worktreeId, input.worktreePath, resolvedConfig, resolvedSelection, baseRef, task, detachedContract, envCleanContext);
+            const status = await executeRun(db, run.id, input.worktreeId, input.worktreePath, input.instanceId, resolvedConfig, resolvedSelection, baseRef, task, detachedContract, envCleanContext);
             terminalStatus = status;
             (0, db_1.finishVerificationRun)(db, run.id, status);
             return status;

package/dist/server/src/types/agent-session.js

@@ -0,0 +1,63 @@
+"use strict";
+/**
+ * What the browser is told about the conversation an instance is in (#2042).
+ *
+ * A structural copy of `lib/hooks/agent-session-telemetry`'s two records rather
+ * than an import of them, for a mechanical reason: that module reaches the
+ * agent's own server, so its module graph pulls in `fs` and `crypto` and it
+ * cannot be imported from a `'use client'` component. The shapes are the wire's,
+ * so they are declared where the wire is read.
+ *
+ * Every field is optional or nullable and the reason is the same one the CLI
+ * mirror gives: this describes what a *server* answered, and the server may be
+ * older than the page talking to it.
+ *
+ * @module types/agent-session
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.sumAgentSessionTokens = sumAgentSessionTokens;
+exports.hasAgentSessionDiff = hasAgentSessionDiff;
+/**
+ * The tokens this session has spent in total, or null.
+ *
+ * **This is the display layer summing five numbers the server publishes
+ * separately, and it is the only place that does.** The server refuses to: a
+ * `total` it invented would be a number no agent stands behind, and
+ * `AgentSessionTokensView.total` stays the agent's own declaration (null today).
+ * Here the sum is a rendering decision with a checkable answer — it is what
+ * `opencode stats` prints for the same session, measured at `input 6 / output 11
+ * / cache.read 8482 / cache.write 8500` → `17.0K`.
+ *
+ * Nulls are skipped rather than counted as zero, and an all-null usage answers
+ * null rather than `0`: a session that has not run a turn has not spent nothing,
+ * it has not said.
+ */
+function sumAgentSessionTokens(tokens) {
+    if (!tokens)
+        return null;
+    if (tokens.total !== null)
+        return tokens.total;
+    const parts = [
+        tokens.input,
+        tokens.output,
+        tokens.reasoning,
+        tokens.cacheRead,
+        tokens.cacheWrite,
+    ].filter((value) => typeof value === 'number' && Number.isFinite(value));
+    if (parts.length === 0)
+        return null;
+    return parts.reduce((sum, value) => sum + value, 0);
+}
+/**
+ * Whether this pane has anything to show in the turn-diff panel.
+ *
+ * The panel's whole visibility rule in one place, because Issue #2043's second
+ * acceptance criterion is that **claude and codex never see an empty panel** —
+ * and those tools publish no `sessionDiff` at all, so `null` has to be a "no"
+ * rather than a shape the panel renders zero rows of.
+ */
+function hasAgentSessionDiff(diff) {
+    if (!diff)
+        return false;
+    return diff.files.length > 0 || diff.revertedFiles.length > 0;
+}

package/dist/server/src/types/agent-transcript.js

@@ -0,0 +1,80 @@
+"use strict";
+/**
+ * How a history row says it holds the agent's own words (Issue #2041).
+ *
+ * Every `chat_messages` row written before this Issue came off a terminal: the
+ * poller captured a pane, cleaned the box drawing out of it and saved what was
+ * left. That text is a *rendering* — the agent's Markdown after the TUI has
+ * already laid it out — so the browser must show it verbatim, and it does
+ * (`whitespace-pre-wrap`).
+ *
+ * opencode publishes the Markdown itself, and a row holding source rather than
+ * a rendering has to be told apart from its neighbours, because rendering the
+ * scraped rows as Markdown would be wrong in both directions: a `┌───` box
+ * would become a table cell, and a `# ` a heading. The two kinds live in one
+ * table, are listed by one query and are drawn by one card, so the distinction
+ * has to travel on the row.
+ *
+ * ## Why the marker rides on `request_id`
+ *
+ * It is the only column on `chat_messages` that is (a) already there, (b)
+ * indexed, (c) nullable, and (d) written by exactly one existing producer
+ * (`parseClaudeOutput`, for `claude` rows only), so a new value cannot collide
+ * with a meaning something already reads. `message_type` was the alternative
+ * and was rejected: {@link MessageType} is a three-word union that a dozen call
+ * sites switch on, and a fourth word would have every one of them treating a
+ * perfectly ordinary reply as something they do not recognise.
+ *
+ * A column of its own would have been cleaner and is deliberately not taken:
+ * Issue #2044 is adding schema v58 in parallel, and two v58s do not merge.
+ *
+ * ## It is an idempotency key as well as a marker
+ *
+ * The same string is what stops one turn being saved twice — see
+ * {@link opencodeTurnRequestId}. That is not a coincidence being exploited: the
+ * marker has to name *which* turn it came from to be a key, and a key that
+ * names its origin is exactly what a provenance marker is.
+ *
+ * @module types/agent-transcript
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.AGENT_MARKDOWN_REQUEST_ID_PREFIX = void 0;
+exports.isAgentAuthoredMarkdown = isAgentAuthoredMarkdown;
+exports.opencodeTurnRequestId = opencodeTurnRequestId;
+/**
+ * Prefix on `chat_messages.request_id` for a row whose `content` is the agent's
+ * own Markdown rather than a scrape of its terminal.
+ *
+ * The `:` is load-bearing — it cannot appear in a claude request id, so
+ * {@link isAgentAuthoredMarkdown} cannot answer true for a pre-existing row.
+ */
+exports.AGENT_MARKDOWN_REQUEST_ID_PREFIX = 'oc-turn:';
+/**
+ * Whether this row's `content` may be rendered as Markdown.
+ *
+ * Conservative by construction: an absent or unrecognised `requestId` answers
+ * false, which is the pre-#2041 rendering. Nothing is ever *upgraded* to
+ * Markdown by guessing at its content.
+ *
+ * @param requestId - `ChatMessage.requestId`, which is usually absent
+ */
+function isAgentAuthoredMarkdown(requestId) {
+    return typeof requestId === 'string' && requestId.startsWith(exports.AGENT_MARKDOWN_REQUEST_ID_PREFIX);
+}
+/**
+ * The row id for one opencode turn.
+ *
+ * The turn is named by the **user message it answers** (`parentID` on every
+ * assistant message opencode produces — measured on 1.18.22, see
+ * `docs/design/opencode-server-live-verification.md` §13). Deliberately not the
+ * assistant message's own id: one turn can produce several assistant messages —
+ * measured, a `bash` call and the sentence about its output arrived as
+ * `msg_…002` (`finish: "tool-calls"`) and `msg_…003` (`finish: "stop"`) — and
+ * keying on those would split one reply into two history rows and re-split it
+ * differently on a backfill.
+ *
+ * @param userMessageId - `msg_…`, the `parentID` the assistant messages carry
+ */
+function opencodeTurnRequestId(userMessageId) {
+    return `${exports.AGENT_MARKDOWN_REQUEST_ID_PREFIX}${userMessageId}`;
+}