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.
|
|
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.
|