specrails-core 4.10.1 → 4.11.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -134,6 +134,12 @@ specrails is not a chat interface. It's a **development pipeline** that coordina
134
134
 
135
135
  Architect designs → developer builds → reviewer validates → PR created. Multiple features run in parallel with git worktrees.
136
136
 
137
+ #### Letting a host own version control (`SPECRAILS_GIT_AUTO`)
138
+
139
+ By default the pipeline ships automatically (`GIT_AUTO=true`): it creates a branch, commits, pushes, and opens a pull request. When specrails-core runs **inside a host that owns version control itself** — such as [specrails-desktop](https://github.com/fjpulidop/specrails-desktop), which runs each pipeline in an isolated git worktree and opens the pull request for you — that host sets the `SPECRAILS_GIT_AUTO` environment variable to `false`.
140
+
141
+ When `SPECRAILS_GIT_AUTO=false` (or `0`), the Ship phase is forced onto the **manual** path regardless of configuration: the pipeline stops at "code written and verified" and makes **no branch, commit, push, or PR** — the host does that. This prevents a second, uncoordinated pull request. Leave the variable unset for the normal standalone behaviour (automatic shipping, subject to your `GIT_AUTO` configuration). It composes with `--dry-run`, which independently skips all git/GitHub/backlog operations.
142
+
137
143
  #### Dry-run / preview mode
138
144
 
139
145
  Not ready to commit? Run the full pipeline without touching git or GitHub:
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "specrails-core",
3
- "version": "4.10.1",
3
+ "version": "4.11.1",
4
4
  "description": "AI agent workflow system for Claude Code — installs 12 specialized agents, orchestration commands, and persona-driven product discovery into any repository",
5
5
  "type": "module",
6
6
  "bin": {
@@ -98,6 +98,15 @@ Only after Step 0's proof gate passes do you proceed to Steps 1–6.
98
98
  - **Why this approach**: Justify key design decisions, especially when trade-offs exist
99
99
  - **What to watch out for**: Identify risks, edge cases, potential regressions, and concurrency concerns
100
100
 
101
+ ### 2.5 Calibrate effort to the change's blast radius
102
+
103
+ 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*.
104
+
105
+ - **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).
106
+ - **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."
107
+ - **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.
108
+ - 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.
109
+
101
110
  ### 3. Organize Tasks
102
111
  - Break the implementation into **ordered, atomic tasks** that can be executed sequentially
103
112
  - Each task should:
@@ -1213,6 +1213,8 @@ Then skip the rest of Phase 4c and proceed directly to Phase 4e.
1213
1213
 
1214
1214
  This phase respects the `GIT_AUTO` and `BACKLOG_WRITE` settings from configuration.
1215
1215
 
1216
+ **Environment override (host owns version control).** Before applying the `GIT_AUTO` logic below, check the `SPECRAILS_GIT_AUTO` environment variable. If it is set to `false` or `0`, treat `GIT_AUTO` as `false` for the rest of this phase (and Phase 4d) **regardless of configuration** — do not create a branch, commit, push, or open a PR; follow the `GIT_AUTO=false` (manual shipping) path instead. A host such as [specrails-desktop](https://github.com/fjpulidop/specrails-desktop) sets this when it owns version control (it runs the pipeline in an isolated worktree and opens the pull request itself), so honouring it prevents a second, uncoordinated PR. When `SPECRAILS_GIT_AUTO` is unset or any other value, resolve `GIT_AUTO` from configuration as normal.
1217
+
1216
1218
  #### If `GIT_AUTO=true` (automatic shipping)
1217
1219
 
1218
1220
  All git operations run against the repo via `git -C "${SPECRAILS_REPO_DIR:-.}"`, and `gh` runs from inside the repo so it can detect the remote.