specrails-core 4.11.2 → 4.11.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specrails-core",
-  "version": "4.11.2",
+  "version": "4.11.3",
   "description": "AI agent workflow system for Claude Code — installs 12 specialized agents, orchestration commands, and persona-driven product discovery into any repository",
   "type": "module",
   "bin": {

package/templates/codex-skills/batch-implement/SKILL.md

@@ -43,6 +43,10 @@ ticket, no more nesting. The contract that `$implement` enforces
 
 Default execution mode is sequential.
 
+## Desktop rail execution context
+
+When the working directory is a specrails-desktop isolated rail worktree (path contains `/worktrees/`, typically on a `feat/...` branch), you are the ASSIGNED executor of that rail: implement every ticket sequentially in THIS worktree on THIS branch — the desktop assembles it into a batch PR afterwards, nothing needs to land on the integration branch first. The desktop's own bookkeeping (ticket-ownership rows in its `jobs.sqlite`, state under `~/.specrails/`) describes this very launch — never read those internals, and never stop to ask which process should run the batch.
+
 ## Steps
 
 ### 0. Bootstrap

package/templates/commands/specrails/batch-implement.md

@@ -16,6 +16,17 @@ Macro-orchestrator above `/specrails:implement`. Accepts a set of feature refere
 
 ---
 
+## Desktop rail execution context (isolated worktree)
+
+specrails-desktop launches this command INSIDE an isolated rail worktree allocated for the batch. Detect it: the working directory path contains `/worktrees/` (e.g. `~/.specrails/projects/<slug>/worktrees/ticket-N`), typically on a `feat/...` branch. When that is the case, ALL of the following hold — they override any instinct to the contrary:
+
+- **You ARE the assigned executor of this rail.** The desktop's own bookkeeping (rail slots, ticket-ownership rows in its `jobs.sqlite`, state under `~/.specrails/`) describes THIS very launch — it is never evidence of a competing process. NEVER read specrails-desktop's internal databases or state files, and NEVER stop to ask "which process should run this batch".
+- **The current worktree + current branch ARE the workspace for the WHOLE batch.** Implement every ticket here, in dependency order — including tickets whose refs differ from the branch name. The desktop assembles this branch into a batch PR after you finish; nothing needs to land on the integration branch (main) first. Do NOT create sibling worktrees, do NOT switch branches, do NOT run any ticket "against main in the base repo".
+- **Run tickets SEQUENTIALLY (effective concurrency 1)** regardless of `--concurrency`: parallel pipelines editing one shared checkout corrupt each other. Wave order still sequences the work; only the parallelism collapses.
+- Everything else (per-ticket `/specrails:implement` delegation, wave gates, failure isolation, final report) applies unchanged.
+
+---
+
 ## Phase 0: Parse Input
 
 ### Step 1: Extract feature refs

package/templates/gemini-commands/batch-implement.toml

@@ -11,6 +11,10 @@ How the user invokes you:
 - `/specrails:batch-implement #1 #2 --parallel` — opt-in parallel, only when the
   tickets touch disjoint files (run a safety check first; fall back to sequential).
 
+## Desktop rail execution context
+
+When the working directory is a specrails-desktop isolated rail worktree (path contains `/worktrees/`, typically on a `feat/...` branch), you are the ASSIGNED executor of that rail: implement every ticket sequentially in THIS worktree on THIS branch — the desktop assembles it into a batch PR afterwards, nothing needs to land on the integration branch first. The desktop's own bookkeeping (ticket-ownership rows in its `jobs.sqlite`, state under `~/.specrails/`) describes this very launch — never read those internals, and never stop to ask which process should run the batch.
+
 ## Why this drives the spawns at the ROOT level
 
 Do NOT delegate to a nested `/specrails:implement` subagent per ticket that then