specrails-core 4.11.0 → 4.11.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specrails-core",
-  "version": "4.11.0",
+  "version": "4.11.2",
   "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/agents/sr-architect.md

@@ -98,6 +98,15 @@ Only after Step 0's proof gate passes do you proceed to Steps 1–6.
   - **Why this approach**: Justify key design decisions, especially when trade-offs exist
   - **What to watch out for**: Identify risks, edge cases, potential regressions, and concurrency concerns
 
+### 2.5 Calibrate effort to the change's blast radius
+
+Right-size BOTH your investigation depth and your written output to how much the change actually touches. Over-investigating a small change burns time and tokens without adding correctness — `detail_level: full` means *complete where it matters*, not *maximal everywhere*.
+
+- **Scope the blast radius first.** Before deep-diving, estimate what the change touches: a handful of files in one layer, or many files across layers / a contract surface (commands, agents, flags, config keys).
+- **Localized change** (few files, one layer, no new contract surface): produce a FOCUSED impact analysis and design. Do NOT emit exhaustive call-site catalogs, whole-file transcriptions, or multi-section codebase surveys — name the specific files/identifiers that matter and move on. The Step 6 compatibility check will still confirm "no contract surface changes."
+- **Cross-cutting change** (many modules, a migration, contract-surface edits, real concurrency): the full depth of Steps 2–6 is warranted — go deep and be exhaustive.
+- Investigate only as far as it changes a design decision. When you already know the answer, state it — don't prove it at length. Depth must earn its cost in correctness, not thoroughness for its own sake.
+
 ### 3. Organize Tasks
 - Break the implementation into **ordered, atomic tasks** that can be executed sequentially
 - Each task should:

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

@@ -12,7 +12,7 @@ Macro-orchestrator above `/specrails:implement`. Accepts a set of feature refere
 - **`--wave-size N`**: max features per wave regardless of concurrency (default: unlimited)
 - **`--dry-run` / `--preview`**: passed through to each `/specrails:implement` invocation; no git or backlog operations will run
 
-**IMPORTANT:** Before running, ensure Read/Write/Bash/Glob/Grep permissions are set to "allow" — background agents cannot request permissions interactively.
+**IMPORTANT:** Before running, ensure Read/Write/Bash/Glob/Grep permissions are set to "allow" — subagents cannot request permissions interactively.
 
 ---
 
@@ -198,7 +198,8 @@ For each wave `W`:
      SPECRAILS_PROFILE_PATH=<resolved-per-rail-path> /specrails:implement <ref> [--dry-run]
      ```
    - Each ref in the batch spawns with its own resolved profile path — **distinct rails in the same batch MAY use distinct profiles concurrently**.
-   - Run invocations in the batch in parallel (`run_in_background: true`).
+   - Run invocations in the batch **concurrently in the FOREGROUND**: emit every agent invocation for the batch in a single message with `run_in_background: false`. They still run in parallel, and your turn blocks until all of them return.
+   - **NEVER use `run_in_background: true`, and NEVER end your reply while a wave is still running.** In headless/pipeline execution (`claude -p`, specrails-desktop loops) the host tears the process down as soon as your turn ends — background agents are killed before they write a single file. Replies like "wave 1 is running in the background, I'll pick it up when it finishes" lose the entire wave.
    - Wait for all in the batch to complete before starting the next batch.
 3. For each completed invocation, record outcome in `WAVE_RESULTS`:
    - `{ref, wave, status: "done" | "failed", profile: "<name or empty>", error_summary: "..." | null}`