opencode-swarm 7.188.8 → 7.188.10

package/dist/lang/backend.d.ts

@@ -36,6 +36,13 @@ export interface TestFrameworkSelection {
      * cannot avoid a shell-mediated invocation (e.g. PowerShell `-EncodedCommand`)
      * still produce an array; the array's first element is the binary and the
      * rest are individual arguments.
+     *
+     * On win32 an array whose `argv[0]` is a `cmd.exe` contained-launcher tuple
+     * (from `resolveContainedWindowsBatchCommand`) additionally requires the
+     * spawner to pass `windowsVerbatimArguments: true`, so the pre-quoted tail
+     * reaches cmd.exe unmodified. A caller spawning a Windows wrapper this way
+     * must gate on `isWindowsCommandInterpreterLaunch(cmd)`;
+     * `src/tools/test-runner.ts` is the reference implementation.
      */
     cmd: string[];
     /** Explicit cwd for the spawn (invariant 3). */

package/dist/lang/backends/java.d.ts

@@ -13,6 +13,9 @@
  *   - `selectEntryPoints` scans the tree for `.java` files declaring
  *     `public static void main`.
  *   - `selectFramework` detects Spring vs Servlet from pom.xml / build.gradle.
+ *   - `buildTestCommand` builds the Maven test argv via the exported
+ *     `buildMavenTestCommand` (runnable wrapper first, else `mvn`), which the
+ *     test-runner's legacy switch shares so both paths emit identical argv.
  *
  * Invariants identical to other backends — see `python.ts` and `go.ts` for
  * the rationale; `tests/unit/lang/backend-purity.test.ts` enforces them.
@@ -60,6 +63,41 @@ declare function resolveMvnwCommand(dir: string): string;
  * Maven wrapper.
  */
 declare function resolveGradlewCommand(dir: string): string;
+/**
+ * True when `filePath` is a regular file with at least one POSIX execute bit
+ * set. Uses `statSync({ throwIfNoEntry: false })` so a missing wrapper is a
+ * plain `false` rather than exception-based control flow (the same rationale
+ * as {@link wrapperExists}); any other stat failure is also treated as "not
+ * executable". Only meaningful on POSIX — Windows reports no execute bits.
+ */
+declare function isExecutableFile(filePath: string): boolean;
+/**
+ * Build the Maven wrapper invocation for `dir` when a RUNNABLE wrapper exists,
+ * otherwise null. This is the single source of truth for "is there a usable
+ * Maven wrapper" — the command builders below and the test-runner's nested
+ * Maven detection both use it, so detection never accepts a wrapper the
+ * command path would not launch.
+ *
+ * - win32: only `mvnw.cmd`, launched through a validated `cmd.exe`
+ *   (`resolveContainedWindowsBatchCommand`): the wrapper's realpath must stay
+ *   inside `dir`, and every token (wrapper path and `args`) is rejected when it
+ *   contains a cmd.exe metacharacter. A bare `mvnw.cmd` argv[0] is never
+ *   emitted (spawn resolves it against PATH, not the cwd), and a POSIX-only
+ *   `mvnw` is never used on win32 (it is not runnable there).
+ * - POSIX: `./mvnw` (relative to the spawn cwd, which callers set to `dir`)
+ *   only when it is a regular file with an execute bit. A wrapper that lost
+ *   its mode bit (zip download, Windows-authored checkout) would fail with
+ *   EACCES, so it is skipped.
+ */
+export declare function resolveMavenWrapperCommand(dir: string, args: string[]): string[] | null;
+/**
+ * Build the Maven test argv for `dir`: the runnable wrapper from
+ * {@link resolveMavenWrapperCommand} when there is one, otherwise `mvn` from
+ * PATH. `-Dtest=<targets>` is appended when targets are given. Shared by the
+ * Java backend's dispatch `buildTestCommand` and the test-runner's legacy
+ * (`SWARM_LANG_BACKEND=legacy`) switch so both paths emit identical argv.
+ */
+export declare function buildMavenTestCommand(dir: string, targets?: string[]): string[];
 /**
  * Build the Java backend from the registered profile.
  */
@@ -69,6 +107,7 @@ export declare const _internals: {
     isMainClass: typeof isMainClass;
     detectFramework: typeof detectFramework;
     wrapperExists: typeof wrapperExists;
+    isExecutableFile: typeof isExecutableFile;
     resolveMvnwCommand: typeof resolveMvnwCommand;
     resolveGradlewCommand: typeof resolveGradlewCommand;
     MAX_ENTRY_POINT_ENTRIES: typeof MAX_ENTRY_POINT_ENTRIES;

package/dist/lang/default-backend.d.ts

@@ -34,6 +34,46 @@ export declare function defaultSelectTestFramework(profile: LanguageProfile, dir
  * `opts.scope` defaults to `'all'`; `opts.coverage` defaults to `false`.
  * Returns null when the framework name is not in the supported set.
  */
+/**
+ * Build the Gradle test argv for `dir` (issue #3040). On win32 with a
+ * `gradlew.bat` wrapper, route through the contained cmd.exe launcher
+ * (`resolveContainedWindowsBatchCommand`) — Bun resolves a bare executable
+ * name against PATH only, never the spawn cwd, so a bare `gradlew.bat` can
+ * never start. Falls back to plain `gradle` from PATH when the helper rejects
+ * the wrapper or an argument (including a token ending in a backslash, which
+ * the launcher's quoting would mangle — the same guard `buildMavenTestCommand`
+ * carries). When `gradlew.bat` is absent, the historical chain applies on ANY
+ * platform — `./gradlew` when a `gradlew` file exists (yes, even on win32,
+ * preserving the pre-#3040 behavior), else `gradle`. Shared by
+ * `defaultBuildTestCommand` and the test-runner's legacy
+ * (`SWARM_LANG_BACKEND=legacy`) switch so both routes emit identical argv.
+ */
+export declare function buildGradleTestCommand(dir: string, targets?: string[]): string[];
+/**
+ * Build the argv for a Composer `vendor/bin` tool (`phpunit`, `pest`) for `dir`
+ * (issue #3050).
+ *
+ * On win32 a Composer `.bat` shim must never become a raw spawn target: Node's
+ * `child_process.spawn` rejects a batch file outright (EINVAL), and although
+ * Bun tolerates one, that tolerance is a runtime accident rather than a
+ * contract, so behaviour must not depend on which runtime is hosting the
+ * plugin. Route the wrapper through the contained cmd.exe launcher
+ * (`resolveContainedWindowsBatchCommand`), the same path the Maven (#3021) and
+ * Gradle (#3040) wrappers already take.
+ *
+ * When the launcher declines — no shim present, a symlink escaping `dir`, an
+ * unresolvable `ComSpec`, or an argument carrying a cmd.exe metacharacter — the
+ * fallback runs the PHP interpreter against the extensionless Composer proxy
+ * rather than re-emitting the batch file. Composer writes both, the proxy is
+ * what the `.bat` itself invokes, and the `php-artisan` arm of the very same
+ * switch already hardcodes `php`.
+ *
+ * Non-win32 is unchanged: the historical cwd-relative extensionless proxy.
+ * Shared by `defaultBuildTestCommand`, the test-runner's legacy
+ * (`SWARM_LANG_BACKEND=legacy`) switch, and the PHP backend's
+ * `selectTestFramework`, so all three routes emit identical argv.
+ */
+export declare function buildPhpVendorCommand(dir: string, name: string, args?: string[]): string[];
 export declare function defaultBuildTestCommand(profile: LanguageProfile, framework: string, files: string[], dir?: string, opts?: BuildTestCommandOpts): string[] | null;
 export declare function buildNativeTargetCommand(target: NativeTestTarget): string[];
 /**

package/dist/tools/build-check.d.ts

@@ -37,6 +37,19 @@ export interface BuildRun {
     duration_ms: number;
     stdout_tail: string;
     stderr_tail: string;
+    /**
+     * Set only when the process could not be created at all — the `bunSpawn`
+     * `spawnError` value contract (`src/utils/bun-compat.ts`), which is how
+     * process-creation failures surface on every runtime.
+     *
+     * Without it a launch failure is indistinguishable from a build that ran and
+     * exited non-zero: `spawnError` and `exitCode` are mutually exclusive, so a
+     * failed spawn resolves `exited` to the sentinel 1 and this record would read
+     * "exit 1" either way (issue #3050). Absent — not null — when the process did
+     * start, so "no launch failure" stays distinguishable from "field present but
+     * empty".
+     */
+    spawn_error?: string;
 }
 export interface BuildCheckResult {
     verdict: EvidenceVerdict;

package/dist/tools/test-runner.d.ts

@@ -16,6 +16,7 @@ export declare const MAX_SAFE_SOURCE_FILES = 1;
 export declare const MAX_RAW_FILE_ENTRIES = 512;
 export declare const MAX_FILE_PATH_LENGTH = 4096;
 export declare const MAX_GRAPH_FILE_BYTES: number;
+export declare const MAX_MAVEN_MODULE_PROBE_ENTRIES = 100;
 /**
  * Estimate the fan-out (number of unique test files) for given source files
  * by reading the cached impact map without spawning a subprocess.
@@ -161,7 +162,35 @@ export declare function parseTestOutputViaDispatch(framework: TestFramework, out
     totals: TestTotals;
     coveragePercent?: number;
 } | null>;
-export declare function detectTestFramework(cwd: string): Promise<TestFramework>;
+/**
+ * Resolve the nearest Maven module directory under `root`.
+ *
+ * When `files` is provided, each file is resolved against `root`, paths
+ * outside `root` are dropped, and the directory containing each remaining file
+ * is walked upward toward `root` until a `pom.xml` is found. The first match
+ * wins (files are tried in the given order; later files are consulted only
+ * when an earlier one resolves to no module).
+ *
+ * When `files` is absent/empty, the immediate entries of `root` are probed one
+ * level deep for a `pom.xml`: hidden entries (any name starting with `.`) and
+ * `node_modules` are skipped, the remaining entries are sorted by name and at
+ * most {@link MAX_MAVEN_MODULE_PROBE_ENTRIES} of them are inspected.
+ *
+ * Containment is checked on canonical paths: a candidate module directory is
+ * accepted only when its realpath stays inside the realpath of `root`, so a
+ * symlink or junction that leads outside the project is skipped (the walk /
+ * probe continues with the next candidate). If `root` itself cannot be
+ * realpath'd, no module is resolved (fail closed). The returned path is the
+ * LEXICAL module path under `root`.
+ *
+ * Known limitations:
+ * - Multi-module reactor: nearest `pom.xml` wins. A child module that depends
+ *   on sibling reactor modules may require the aggregator pom (out of scope).
+ * - `scope:'target'` native execution remains rooted at the project root; this
+ *   resolver does not change native target handling.
+ */
+export declare function resolveMavenModuleDir(root: string, files?: string[]): string | null;
+export declare function detectTestFramework(cwd: string, files?: string[]): Promise<TestFramework>;
 /**
  * Returns true when `basename` matches a language-specific test file naming
  * convention that is NOT captured by the compound-extension or dot-separated
@@ -207,6 +236,7 @@ export declare const _internals: {
     existsSync: typeof fs.existsSync;
     readdirSync: typeof fs.readdirSync;
     readFileSync: typeof fs.readFileSync;
+    realpathSync: typeof fs.realpathSync;
     resolveLocalNodeTool: typeof resolveLocalNodeTool;
     bunSpawn: typeof bunSpawn;
     buildNativeTargetCommand: typeof buildNativeTargetCommand;

package/dist/utils/windows-batch.d.ts

@@ -0,0 +1,58 @@
+/**
+ * Safe launch of a Windows batch wrapper (`.cmd` / `.bat`) through a
+ * validated `cmd.exe`.
+ *
+ * Node cannot spawn a batch file directly at all: since the CVE-2024-27980
+ * hardening `child_process.spawn` rejects a `.cmd`/`.bat` target with EINVAL
+ * (measured on Node v24.16.0 for the absolute, cwd-relative and bare-name
+ * forms alike). Bun is more permissive — it routes batch files through cmd.exe
+ * itself — but that tolerance is a runtime accident rather than a contract, so
+ * a launcher must not depend on which runtime hosts the plugin. For the same
+ * reason a bare wrapper name such as `mvnw.cmd` is resolved against PATH only,
+ * never against the spawn `cwd`. The supported shape is
+ * `[<cmd.exe>, '/d', '/s', '/v:off', '/c', 'call "<abs>" "<arg>" ...']`
+ * spawned with `windowsVerbatimArguments: true`, so the pre-quoted tail reaches
+ * cmd.exe unmodified (the same pattern `src/tools/lint.ts` and
+ * `src/tools/pkg-audit.ts` use).
+ *
+ * Every token (the canonical wrapper path and each argument) is rejected when
+ * it contains a cmd.exe metacharacter instead of being escaped, so a caller
+ * never builds a command line cmd.exe could re-interpret. Callers must treat a
+ * `null` result as "do not launch the wrapper" and fall back to a non-batch
+ * command.
+ *
+ * Extracted from `src/tools/lint.ts` without behaviour change. The functions
+ * take their filesystem/environment dependencies explicitly so each caller
+ * keeps its own DI seam: lint passes thunks over `lint._internals`, while
+ * other callers use this module's `_internals` (the default).
+ */
+export declare const WINDOWS_BATCH_WRAPPER_EXTENSIONS: readonly [".cmd", ".bat"];
+/** Filesystem/environment dependencies of the batch-launch helpers. */
+export interface WindowsBatchDeps {
+    platform: () => NodeJS.Platform;
+    comSpec: () => string | undefined;
+    realpathSync: (candidate: string) => string;
+    statSync: (candidate: string) => {
+        isFile(): boolean;
+    };
+}
+/**
+ * Build the constrained `cmd.exe /d /s /v:off /c call "<wrapper>" "<arg>"...`
+ * argv for an already-located batch wrapper, or null when the interpreter
+ * cannot be resolved, the wrapper is not a regular `.cmd`/`.bat` file, or any
+ * token contains a cmd.exe metacharacter.
+ */
+export declare function buildWindowsBatchCommand(wrapperPath: string, args: string[], deps?: WindowsBatchDeps): string[] | null;
+/**
+ * Build the launcher argv for `<cwd>/<fileName>` only on win32, and only when
+ * the wrapper's canonical path stays inside the canonical `cwd` (a symlink or
+ * junction that escapes `cwd` is rejected). Returns null otherwise.
+ */
+export declare function resolveContainedWindowsBatchCommand(cwd: string, fileName: string, args: string[], deps?: WindowsBatchDeps): string[] | null;
+/**
+ * True when `command` is a cmd.exe launcher that must be spawned with
+ * `windowsVerbatimArguments: true` (win32 only).
+ */
+export declare function isWindowsCommandInterpreterLaunch(command: readonly string[], platform?: NodeJS.Platform): boolean;
+/** Default dependencies (live process/filesystem); a DI seam for tests. */
+export declare const _internals: WindowsBatchDeps;

package/dist/workflow/session-view.d.ts

@@ -0,0 +1,47 @@
+import { type TaskWorkflowSnapshot } from '../gate-evidence.js';
+import { type AgentSessionState, type TaskWorkflowState } from '../state.js';
+/**
+ * Session-view refresh for Stage A recovery writers (issue #3043).
+ *
+ * The Stage B settlement loop filters on the session's in-memory
+ * `taskWorkflowStates` view while dispatch admission reads the durable
+ * workflow evidence, so a recovery writer that advances the durable evidence
+ * WITHOUT refreshing the calling session's in-memory twin leaves every later
+ * verdict in that session silently skipped — the #3032 split-brain class.
+ * The blocked-start arm was the last uncovered shape: `blocked` is
+ * at-or-above the durable eligible states, so PR #3038's consumer-side
+ * `isRepairableStageBView` guard deliberately refuses to repair it (it
+ * protects `update_task_status`'s permissive fallback), and only the WRITER —
+ * whose own audited repair write is the authority that the blocked label was
+ * drift, not a real block — may refresh it.
+ */
+/**
+ * Apply a durable workflow snapshot to one session's in-memory view of one
+ * task. The exact mutation steps of the update_task_status recovery legs'
+ * `syncCallerWorkflowFromEvidence` (extracted so the clear-set can never
+ * drift between the two surfaces); the caller owns the refresh DECISION.
+ * Pure in-memory bookkeeping aligned to a durable write the caller already
+ * made or verified — it must never throw into the recovery result.
+ */
+export declare function applySessionWorkflowView(session: AgentSessionState, taskId: string, workflow: TaskWorkflowSnapshot): void;
+/** States a Stage A recovery writer can leave durable evidence at. */
+export type StageARecoveredState = 'pre_check_passed' | 'reviewer_run' | 'tests_run';
+export declare function isStageARecoveredState(state: string): state is StageARecoveredState;
+/**
+ * Whether a session's in-memory view may be refreshed to `recoveredState`
+ * after a Stage A recovery writer committed (or verified) that durable state.
+ *
+ * One ordered rule:
+ * - absent / `rework_required` / `blocked` views always refresh — the first
+ *   two mirror the #3038 consumer-side guard's forward-progress exceptions;
+ *   `blocked` is the #3043 arm and is repairable HERE only, because this
+ *   predicate runs at the writer that just proved the blocked label was
+ *   drift (the consumer-side guard keeps refusing it).
+ * - otherwise refresh only when the view is not barrier-ahead-or-terminal
+ *   (`tests_run` / `closed` / `complete` are never downgraded — a map ahead
+ *   of durable is the legitimate settlement-barrier shape, and terminal
+ *   completions are never un-completed in memory) AND ranks below the
+ *   recovered state (the map lags durable; refreshing is forward, not a
+ *   downgrade).
+ */
+export declare function shouldRefreshStageARecoveryView(view: TaskWorkflowState | undefined, recoveredState: StageARecoveredState): boolean;

package/dist/workflow/stage-a-repair.d.ts

@@ -102,4 +102,5 @@ export declare function scanWedgedStageA(directory: string, options?: {
  */
 export declare function repairWedgedStageA(directory: string, options?: {
     taskIds?: string[];
+    sessionId?: string;
 }): Promise<StageARepairResult>;

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "opencode-swarm",
-	"version": "7.188.8",
+	"version": "7.188.10",
 	"description": "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
 	"main": "dist/index.js",
 	"types": "dist/index.d.ts",