specrails-desktop 2.42.2 → 2.43.1

package/docs/ci-cd.md

@@ -42,7 +42,7 @@ The macOS job retains `artifacts/chromium-signing/` as the `chromium-signing-mac
 ## Credentials and external requirements
 
 - `RELEASE_PAT` must be authorized for release-please's pull requests and releases. It also permits tag pushes to trigger publication workflows; events created with the repository's ordinary `GITHUB_TOKEN` generally do not trigger another workflow.
-- `NPM_TOKEN` must authenticate an account with publishing permission for `specrails-desktop`. The workflow checks authentication and gives an explicit error before publishing. Provenance requires `id-token: write`; it does **not** grant npm publishing permission. Trusted publishing requires separate registry configuration and is not silently enabled here. An npm `E404` during publication is not sufficient evidence to identify a particular token or permission failure. [npm publishing and provenance](https://docs.github.com/en/actions/tutorials/publish-packages/publish-nodejs-packages).
+- Publication uses one of two credentials. When the `NPM_TOKEN` secret is set, it must authenticate an account with publishing permission for `specrails-desktop` (npm now requires such tokens to be granular with *bypass 2FA*, and they expire within 90 days); the workflow checks authentication and gives an explicit error before publishing. When the secret is empty, the job publishes through npm **trusted publishing**: it installs npm 11, removes the empty token line that `setup-node` writes, and lets npm exchange the job's OIDC identity (`id-token: write`) for a short-lived publish grant. That path only works once the package's *Trusted publisher* on npmjs.com names this repository (`fjpulidop/specrails-desktop`) and workflow file (`npm-publish.yml`, no environment); registry configuration is never changed from here. Provenance does **not** grant publishing permission in either mode. An npm `E404` during publication is npm's answer to an unauthorized publish and does not identify which token or permission failed; an `E403` mentioning two-factor authentication means the stored token lacks *bypass 2FA*. [npm publishing and provenance](https://docs.github.com/en/actions/tutorials/publish-packages/publish-nodejs-packages).
 - Existing Apple signing/notarization and Tauri updater signing secrets remain required. Installer build steps retain their platform-specific checks.
 - Hostinger credentials must support **explicit FTPS**, a valid TLS certificate, uploads and `RNFR`/`RNTO` in the release directory. There is no plaintext FTP fallback. A failed transfer or rename fails the workflow before old files are removed. [FTP action protocol and security options](https://github.com/SamKirkland/FTP-Deploy-Action/blob/v4.3.6/action.yml).
 

package/docs/codex.md

@@ -46,9 +46,9 @@ binary isn't on `PATH`; it shows install commands if you click "More info".
    The first provider you select becomes the project default.
 4. Submit. The app writes `.specrails/install-config.yaml` (with
    `provider: codex` and `tier: quick` as YAML keys) and spawns
-   `npx --yes --prefer-online specrails-core@^4.12.0 init --yes --from-config <file>`
+   `npx --yes --prefer-online specrails-core@^5.1.0 init --yes --from-config <file>`
    — the provider and tier live in the YAML, not as CLI flags. (The app
-   pins `specrails-core@^4.12.0`; that floor is the version that ships the
+   pins `specrails-core@^5.1.0`; that floor is the version that ships the
    current provider targets, including Kimi and the Codex skill set.) The install
    produces:
    - `.codex/config.toml` — model, reasoning effort, sandbox mode, and

package/docs/customizing.md

@@ -148,7 +148,7 @@ Most settings live in the UI. A few app-level switches are env-only because they
 
 | Variable | Effect |
 |----------|--------|
-| `SPECRAILS_CORE_BIN` | Override the `specrails-core` binary (default: `npx --yes --prefer-online specrails-core@^4.12.0` — the 4.12.0 floor is the release that ships the Kimi provider target) |
+| `SPECRAILS_CORE_BIN` | Override the `specrails-core` binary (default: `npx --yes --prefer-online specrails-core@^5.1.0` — the 5.1.0 floor is the release that quotes the command path in its Windows shell runner, so OpenSpec init works from an install directory with spaces; it is also the version bundled with the app) |
 | `SPECRAILS_TECH_URL` | Override the specrails-tech proxy base URL |
 | `SPECRAILS_AGENTS_SECTION=false` | Hide the Agents section from every project |
 | `SPECRAILS_PLUGINS_SECTION=false` | Hide the Integrations section from every project |

package/docs/gemini.md

@@ -24,11 +24,11 @@ Specrails supports **four AI providers**: Anthropic's
 |---|---|---|
 | `gemini` CLI ≥ 0.11.0 | Earlier versions lack `--output-format stream-json` + headless `--resume`, which the app relies on | `npm i -g @google/gemini-cli` · check with `gemini --version` |
 | A Gemini API key | The app spawns Gemini headlessly, so it needs non-interactive auth | Set `GEMINI_API_KEY` to a paid Gemini Developer API key from [Google AI Studio](https://aistudio.google.com/apikey) |
-| `specrails-core` ≥ 4.8.0 in the project | 4.8.0 ships the Gemini provider target (`.gemini/` commands + agents) that the rails pipeline needs | The current Add-Project install flow uses `specrails-core@^4.12.0` automatically |
+| `specrails-core` ≥ 4.8.0 in the project | 4.8.0 ships the Gemini provider target (`.gemini/` commands + agents) that the rails pipeline needs | The current Add-Project install flow uses `specrails-core@^5.1.0` automatically |
 | `git`, `node`, `npm`, `npx` | Same as Claude — needed for `specrails-core init` | Use your usual installer |
 
 > **Two different minimums.** The `gemini` **binary** floor is **0.11.0**.
-> The current Desktop `specrails-core` **package** floor is **4.12.0** (a
+> The current Desktop `specrails-core` **package** floor is **5.1.0** (a
 > single shared version for all providers, including Kimi). They are separate
 > things — the binary on your
 > machine vs. the artifacts installed into the project.
@@ -52,7 +52,7 @@ the Gemini provider checkbox with a "not found" hint when the binary isn't on
    project](#running-multiple-providers-in-one-project)). The first provider
    you select becomes the project default.
 4. Submit. The app writes `.specrails/install-config.yaml` and spawns
-   `npx --yes --prefer-online specrails-core@^4.12.0 init --yes --from-config <file>`.
+   `npx --yes --prefer-online specrails-core@^5.1.0 init --yes --from-config <file>`.
    The install produces the `.gemini/` artifacts (commands + `sr-*` agents),
    plus a `GEMINI.md` instructions file.
 

package/docs/getting-started.md

@@ -61,7 +61,7 @@ specrails-desktop list   # verify
 The setup wizard runs automatically. Three steps:
 
 1. **Configure** — choose which agents to install (the baseline trio `sr-architect`, `sr-developer`, `sr-reviewer` is always selected; optional agents like Test Writer or Security Reviewer are opt-in). Pick a model preset (Balanced / Budget / Max) and optionally override the model per agent.
-2. **Install** — the app runs the installer (`npx --yes --prefer-online specrails-core@^4.12.0 init --yes --from-config <config>`) non-interactively and streams the output live. The version is pinned to the core release the app ships with — it never silently jumps to a new major.
+2. **Install** — the app runs the installer (`npx --yes --prefer-online specrails-core@^5.1.0 init --yes --from-config <config>`) non-interactively and streams the output live. The version is pinned to the core release the app ships with — it never silently jumps to a new major.
 3. **Done** — a summary tells you how many agents and commands landed. Click **Continue to project**.
 
 That's the whole onboarding. No tier picker, no second wizard. You can manage agents and their per-agent models later from the **Agents** page (Profiles tab).

package/docs/internals/interactive-jobs.md

@@ -314,3 +314,56 @@ delivery row — stranded uncommitted work. Loops disabled ⇒ the legacy QueueM
 unchanged. Relatedly, the agent-chat operator prompt gained the ask-confirmation-once
 turn-discipline rule (`server/agent-operator-prompt.ts`): a confirmation question is asked
 exactly once and ends the reply — the answer arrives as the next user message.
+
+## Decider starved by its own tool budget (2026-09-07)
+
+A two-repo `factory:implement` run (pipeline run `47b9a423`) finished its work, and the
+verify step answered `VERIFICATION: PASS` with a freshly re-run receipt across both
+repositories. The loop continued anyway. The Decider step's log line was the tell:
+
+```
+Decision: continue — error_max_turns: Reached maximum number of turns (1)
+```
+
+That is not a verdict. The Decider never emitted one — it died before answering, and the
+executor's fail-open default did the rest.
+
+- **The starvation.** `runDecider` spawned with `maxTurns: 1` *and* `toolPolicy:
+  'read-only'`, which on claude is `--tools Read,Grep,Glob` **plus `--permission-mode plan
+  --safe-mode`**. One tool call — a repo read, or plan mode's own exit call — consumes the
+  single allowed turn, so the run ends `error_max_turns` **before** the JSON verdict is
+  produced. Nothing about it is intermittent: a Decider that touches any tool can never
+  answer. The step burned 2 turns and ~$0.09 to say nothing.
+- **Reproduced across loops and tiers.** A `SDD Quick (OpenSpec)` run on claude/**sonnet**
+  showed the identical signature — every Decider step `2 turns`, ~7 s, `Decision: continue
+  — error_max_turns`. Its verify step reported `VERIFICATION: PASS` twice, and the loop
+  still cycled `opsx:ff → opsx:apply → opsx:verify` for two full iterations (the fix steps
+  correctly finding nothing to do and saying so) until the user cancelled it. So the bug is
+  not model-, tier- or loop-specific: it is every Decider on claude.
+- **Why it became a `continue`.** A failed Decider invocation is deliberately forced to
+  `{ continue: true, parsed: false }` — a streamed verdict from an interrupted run is not
+  an authoritative completion gate, and `maxIterations`/`timeout` are the hard stop. Sound
+  in isolation, but combined with the starvation above it meant *every* such run silently
+  discarded a real STOP and paid for another iteration: here a fix step that invented work
+  (tautological cascade tests, a mutation probe, a wrong conclusion, then a full revert)
+  plus a second full re-verification, for no change to the delivered candidate.
+- **The fix.** The Decider judges from the prompt it is GIVEN (goal + spec + iteration
+  history) and must answer with one JSON object, so it needs no tools at all.
+  `runDecider` now picks the tightest boundary the CLI enforces via
+  `pureOutputToolPolicy(adapter)`: `'none'` on claude (`--tools __none__`, no approval
+  bypass needed), `'read-only'` on codex/gemini — byte-identical there, since neither has
+  a native no-tools mode. The null case is unreachable: `LoopRunManager.run` already
+  rejects a decider-bearing graph whose provider cannot enforce `read-only` natively
+  (kimi), before allocating or persisting the run. `'none'` also drops the plan-mode flags
+  (the adapter attaches them only to `read-only`), removing the second way the single turn
+  could be consumed. This aligns the Decider with the repo's other single-turn spawns —
+  `file-summary-generator.ts` and both `contract-refine-runner.ts` invocations already
+  resolve a pure-output policy rather than hardcoding `read-only`; the Decider was the last
+  one left with tools it could not afford to use.
+- **Deliberately NOT changed:** the fail-open `continue` on a genuinely failed Decider
+  (timeout, spawn failure, non-zero exit, provider limit). The starvation was the bug; the
+  default is the safety net, and with tools gone it stops firing on every healthy run.
+- **Adjacent, still open:** the verify step re-ran the full cross-repository suite each
+  iteration because the Core receipt is invalidated per session (*"Verification environment
+  changed: ./mvnw / npm"*) even when the candidate hash is identical. That is a receipt
+  env-hash question in specrails-core, not a desktop one.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specrails-desktop",
-  "version": "2.42.2",
+  "version": "2.43.1",
   "license": "MIT",
   "repository": {
     "type": "git",

package/server/dist/core-package.js

@@ -1,7 +1,10 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.CORE_PACKAGE_SPEC = void 0;
-/** Online fallback selects the supported Core 5 lifecycle. Bundled Core 4 remains
- * readable for installed apps; the runtime resolver selects the newest usable
- * compatible package and never downgrades a newer activated framework. */
-exports.CORE_PACKAGE_SPEC = 'specrails-core@^5.0.0';
+/** Online fallback selects the supported Core 5 lifecycle; 5.1.0 is the floor
+ * because it quotes the command path in its Windows shell runner (OpenSpec init
+ * from an install directory with spaces). The desktop bundles the same version.
+ * Bundled Core 4 remains readable for installed apps; the runtime resolver
+ * selects the newest usable compatible package and never downgrades a newer
+ * activated framework. */
+exports.CORE_PACKAGE_SPEC = 'specrails-core@^5.1.0';

package/server/dist/loop-executors.js

@@ -488,7 +488,20 @@ function createLoopExecutors(opts = {}) {
             const decEnv = aiStepEnv(baseEnv, repoDir, executionManifest);
             // spec-gen is a one-shot, system-prompted invocation (workspace-write on
             // codex, not full-access) — appropriate for a read-only judgment.
-            const buildOpts = { prompt: userPrompt, systemPrompt, model, maxTurns: 1, reasoning_effort: effort, toolPolicy: 'read-only', ...(executionManifest ? { extraArgs: aiStepExtraArgs(adapter, cwd, repoDir, executionManifest) } : {}) };
+            //
+            // The Decider judges the goal from the prompt it is GIVEN (goal + spec +
+            // iteration history) and must answer with a single JSON object, so it
+            // needs no tools. Granting them was actively harmful on claude: with
+            // `--max-turns 1`, one Read/Grep call consumes the whole turn budget and
+            // the run ends `error_max_turns` BEFORE the verdict is emitted. A failed
+            // Decider invocation is forced to `continue` below, so every such run
+            // silently discarded a real STOP verdict and burned another iteration.
+            // `pureOutputToolPolicy` picks the tightest boundary the CLI enforces:
+            // 'none' on claude, 'read-only' on codex/gemini (byte-identical to the
+            // previous behaviour there). The null case is unreachable — `run()`
+            // rejects a decider graph whose provider cannot enforce 'read-only'.
+            const toolPolicy = (0, runtime_1.pureOutputToolPolicy)(adapter) ?? 'read-only';
+            const buildOpts = { prompt: userPrompt, systemPrompt, model, maxTurns: 1, reasoning_effort: effort, toolPolicy, ...(executionManifest ? { extraArgs: aiStepExtraArgs(adapter, cwd, repoDir, executionManifest) } : {}) };
             const wallStartedAt = Date.now();
             const res = await (0, spawn_lifecycle_1.runAiCliInvocation)({
                 adapter,