@gobing-ai/spur 0.3.57 → 0.3.58

package/plugins/sp/README.md

@@ -601,7 +601,7 @@ All planning entities (tasks and features) share a common lifecycle, managed by
 | **check**   | `spur task check`                   | `spur feature check`                | 4-layer readiness matrix (schema, sections, traceability, AC)                                        |
 | **update**  | `spur task update <wbs> [status]`   | `spur feature update <id> [status]` | Lifecycle transition or scalar field set                                                             |
 | **record**  | `spur task record <wbs>`            | —                                   | Write Testing/Review from a verify verdict; optional Solution backfill (never transitions to `done`) |
-| **refresh** | `spur task refresh`                 | `spur feature refresh`              | Index + feature-tree roll-up regeneration                                                            |
+| **refresh** | `spur task refresh`                 | `spur feature refresh --feature <id> \| --all` | Index + feature-tree roll-up regeneration                                                   |
 
 The **workflow** and **rule** engines have their own lifecycles (author → validate → run → trace /
 refine), documented in their respective `sp:spur-cli` references.

package/plugins/sp/agents/expert-spur.md

@@ -71,7 +71,7 @@ Invoke `sp:spur-cli` for verb guidance and per-noun conventions:
 - [ ] Run the noun's `check`/`validate` verb before and after editing (e.g. `spur task check <wbs> --json`).
 - [ ] Run the corpus-wide sweep after batch edits: `spur task check --corpus --json` (fails on structural errors outside `config/corpus-baseline.json`).
 - [ ] Use `spur task update --section --from-file` for all task section edits.
-- [ ] Run the noun's `refresh` after batch operations where one exists (`spur task refresh`, `spur feature refresh`).
+- [ ] Run the noun's scoped `refresh` after batch operations where one exists (`spur task refresh`, `spur feature refresh --feature <id>` or `--all`).
 
 ### Never
 

package/plugins/sp/commands/dev-feature-change.md

@@ -62,7 +62,7 @@ Do **not** fire independent dry-runs that all claim the same next id. Walk rows
 3. After predicting `new_id`, add it to the occupancy set so the next sibling under the same parent gets the next free digit.
 4. Record `mapping` and `tasksUpdated[]` from each dry-run (with multi-folder scan, tasksUpdated should list every linked WBS).
 
-Plan `spur feature refresh` + `spur feature check --json` after apply.
+Plan `spur feature refresh --all` + `spur feature check --json` after apply.
 
 **Root docs/\*.md references (high-confidence only)**
 
@@ -95,7 +95,7 @@ spur feature move <old_id> --parent <new_parent> --json
 After all moves (or per wave):
 
 ```bash
-spur feature refresh --json
+spur feature refresh --all --json
 spur feature check --json
 ```
 

package/plugins/sp/plugin.json

@@ -1,6 +1,6 @@
 {
     "name": "sp",
-    "version": "0.3.57",
+    "version": "0.3.58",
     "description": "Spur — a local-first harness engineering toolkit that wraps mainstream coding agents with constraint checking, workflow orchestration, and history analytics.",
     "extensions": {
         "pi": ["./hooks/pi/guard-extension.ts"]

package/plugins/sp/skills/spur-cli/references/features/hierarchy-mece.md

@@ -158,7 +158,7 @@ work under H.
 - [ ] Sibling set stays MECE at that parent.
 - [ ] Name is capability/outcome, not a package path.
 - [ ] Will attach tasks with `--feature <new-id>` (or parent if intentionally epic-only).
-- [ ] After create: `spur feature refresh` if INDEX must update; `spur feature check <id>`.
+- [ ] After create: `spur feature refresh --feature <new-id>` if INDEX must update; `spur feature check <new-id>`.
 
 ## Checklist: before restructure / `/sp:dev-feature-change`
 
@@ -166,7 +166,7 @@ work under H.
 - [ ] False merges rejected (name overlap ≠ one Goal).
 - [ ] Apply via CLI (`spur feature move`, `spur task update --feature`), not raw ID edits.
 - [ ] Dry-run reviewed; doc rewrites limited to agreed surface (e.g. root `docs/*.md`).
-- [ ] `spur feature refresh` + `spur feature check` after apply.
+- [ ] `spur feature refresh --all` + `spur feature check --json` after apply.
 
 ---
 

package/plugins/sp/skills/spur-cli/references/features/roadmap-priority.md

@@ -78,7 +78,7 @@ For roadmap adjustment work:
 3. Present the proposed moves/status/priority changes before mutating if the blast radius spans
    multiple features.
 4. Apply each accepted deterministic change through `spur feature update` or `spur feature move`.
-5. Run `spur feature refresh` and `spur feature check --json`.
+5. Run `spur feature refresh --all` and `spur feature check --json`.
 
 Do not add `/sp:prd-adjust` for this. The current CLI already has the deterministic primitives; the
 PM value is the ranking and tradeoff judgment.

package/plugins/sp/skills/spur-cli/references/features/verbs.md

@@ -116,7 +116,7 @@ spur feature update  <id> [status] [--field <k> --value <v>] [--section <n> --fr
 spur feature advance <id> [--to <status>] [--folder] [--json]
 spur feature list    [--status <s>] [--priority <p>] [--folder] [--json]
 spur feature move    <id> [--parent <id>] [--dry-run] [--folder] [--json]
-spur feature refresh [--feature <id>] [--folder] [--json]
+spur feature refresh [--feature <id> | --all] [--folder] [--json]
 spur feature sync    [id] | --all [--dry-run] [--force] [--folder] [--json]
 spur feature check   [id] [--strict] [--folder] [--json]
 ```

package/plugins/sp/skills/spur-cli/references/features.md

@@ -27,7 +27,7 @@ what* or *how to write a scenario*, this skill.
 | `advance <id>` | Walk forward along the legal lifecycle path to a target status | `--to <status>` (default `done`) `--folder` `--json` |
 | `list` | List features, filtered | `--status <s>` `--priority <p>` `--folder` `--json` |
 | `move <id>` | Re-parent a subtree (cascade-rename of descendants) | `--parent <id>` `--dry-run` `--folder` `--json` |
-| `refresh` | Rebuild INDEX + each feature `## Tasks` table from task edges (**docs only**; no status change) | `--feature <id>` `--folder` `--json` |
+| `refresh` | Rebuild INDEX + each feature `## Tasks` table from task edges (**docs only**; no status change) | `--feature <id>` `--all` `--folder` `--json` |
 | `check [id]` | Validate one feature / the tree; the 4-layer gate; `--fix` repairs structural findings in place | `--strict` `--fix` `--folder` `--json` |
 | `sync [id]` | Align feature **lifecycle status** with linked task states (real transitions + guards) | `--all` `--dry-run` `--force` `--folder` `--json` |
 
@@ -157,6 +157,9 @@ the AC coverage map. Habits that keep it green:
   the files (files win). This is **not** `sync` — it does not change feature status.
 - **Scope `refresh` to one feature** with `--feature <id>` when only one feature's task links changed
   (INDEX.md is still regenerated for the whole tree): `spur feature refresh --feature H2`.
+- **The broad sweep is explicit** (task 0625 R5a): bare `spur feature refresh` refuses to sweep; pass
+  `--all` to rewrite every feature's `## Tasks` region. A bare sweep silently touched unrelated
+  features during the A3 run.
 
 ## Roadmap and priority habits
 
@@ -192,7 +195,7 @@ reopens. It computes a proposal (`from → to` with a `reason`) and, unless `--d
 via real lifecycle transitions (dogfood / one-active-goal / L4 gates may deny a hop).
 
 **Not for roster tables.** A stale `## Tasks` line (e.g. task still listed `todo` after it is `done`)
-is fixed with `spur feature refresh`, not `sync`. Use `sync --dry-run` first when you only want to
+is fixed with `spur feature refresh --feature <id>` (or explicit `--all`), not `sync`. Use `sync --dry-run` first when you only want to
 see the proposed status hop.
 
 ```bash

package/plugins/sp/skills/spur-dev/references/ac-style-guide.md

@@ -193,7 +193,7 @@ During decomposition, each core scenario maps to ≥1 task:
 | R3 — Login with email and password | 0043, 0044 | Auth service + UI |
 
 The mapping is recorded in the task's `## Background` or in the feature's `## Notes`.
-`spur feature check` warns on unmapped core scenarios after `spur feature refresh`
+`spur feature check` warns on unmapped core scenarios after `spur feature refresh --feature <id>`
 regenerates the `## Tasks` block.
 
 ## Decision-trace → AC-scenario mapping

package/plugins/sp/skills/spur-dev/references/execution-workflow.md

@@ -351,7 +351,7 @@ After a completed task, decide next action:
 - **More tasks in the feature?** Pick the next one, run again.
 - **Feature complete?** Run `spur feature update <id> verifying` to mark it for
   acceptance verification.
-- **All done?** Run `spur task refresh` + `spur feature refresh` to regenerate the kanban
+- **All done?** Run `spur task refresh` + `spur feature refresh --all` to regenerate the kanban
   and index.
 
 ## Skipping HITL

package/plugins/sp/skills/spur-dev/references/planning-workflow.md

@@ -146,7 +146,7 @@ that is the pre-check's job above). Common shape failures:
 - WBS collisions (already-allocated range).
 
 Loop until the command exits 0 — then the batch is created and each task appears in the
-feature's `## Tasks` block on next `spur feature refresh`.
+feature's `## Tasks` block on next `spur feature refresh --feature <id>`.
 
 **If you decomposed a parent task into sub-task files** (the children carry `parent_wbs`), the
 sub-task roster is **auto-generated** — `spur task batch-create` invokes `spur task refresh-roster`