specrails-core 4.11.0 → 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/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "specrails-core",
|
|
3
|
-
"version": "4.11.
|
|
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:
|