@gobing-ai/spur 0.3.28 → 0.3.30

package/config/rules/strict/runtime-boundaries.yaml

@@ -60,6 +60,7 @@ rules:
             - "packages/app/src/services/token-ledger-service.ts" # FD byte-window log tailing
             - "packages/app/src/services/token-ledger-watcher.ts" # node:fs watch() live watcher
             - "packages/app/src/services/project-registry.ts" # atomic projects.json persistence
+            - "packages/app/src/observability/run-output-sink.ts" # sync FD append for mid-run tail-able artifact (task 0414 R2); observe() is sync from the lifecycle relay
             - "apps/web/src/modules/discover.ts" # Vite/Astro module scanner fallback under bun test
 
             # Synchronous bootstrap & path resolution:

package/config/rules/typescript/no-syscall-emulation-in-boundary-mock.yaml

@@ -0,0 +1,57 @@
+$schema: "@gobing-ai/spur/schemas/rule-file.schema.json"
+# Forbid mocking the syscall under test where the mock emulates it (task 0415 R4).
+#
+# WHY: `sp:test-driven-development` SKILL.md:164 already states the rule — "Mock
+# what crosses a process/IO boundary; never mock the code under test." This rule
+# enforces the narrow, mechanically detectable case: a test that mocks a
+# subprocess/syscall boundary (Bun.spawnSync / node:child_process) AND whose mock
+# handler emulates the syscall output (stat / mtime / %m) that the code under test
+# consumes. The 0411 defect is the canonical fixture: the verdict-mtime tests
+# mocked `Bun.spawnSync` INCLUDING the `stat -f %m` call, so the BSD-only stat
+# syntax silently returned nothing on Linux while 57 tests stayed green — the mock
+# replaced the very portability the tests were supposed to verify.
+#
+# SCOPE / discriminator: mocking the subprocess boundary to control *subprocess
+# responses* (e.g. feature-sync-bounded.test.ts intercepting `show`/`list`/`sync`
+# commands) is legitimate and NOT flagged — the boundary mock returns canned
+# responses, it does not re-implement the syscall the code under test calls. The
+# rule fires only when the mock handler itself references `stat`/`%m`/`birthtime`
+# (emulating the syscall) within a bounded window after the mock installation.
+#
+# FIX: use real files + real statSync/utimesSync (the 0411 remediation), or mock a
+# higher-level seam the code under test does NOT depend on for the behavior under
+# test. If a legit syscall-emulating mock is unavoidable, waive with a stated
+# reason in the test.
+include:
+  - "apps/**/tests/**/*.test.ts"
+  - "apps/**/tests/**/*.test.tsx"
+  - "packages/**/tests/**/*.test.ts"
+  - "packages/**/tests/**/*.test.tsx"
+  - "plugins/**/tests/**/*.test.ts"
+  - "plugins/**/tests/**/*.test.tsx"
+exclude:
+  - "**/node_modules/**"
+  - "**/dist/**"
+
+rules:
+  - id: no-syscall-emulation-in-boundary-mock
+    description: >
+      A test that mocks a subprocess/syscall boundary (Bun.spawnSync assignment,
+      spyOn(Bun,'spawnSync'), or mock.module('node:child_process')) MUST NOT have
+      the mock handler emulate the syscall output the code under test consumes
+      (stat / `-f %m` / birthtime / mtime-derived fingerprints). That mocks the
+      code under test, not the boundary: platform-specific syscall syntax (e.g.
+      BSD-only `stat -f %m`) silently no-ops on Linux while the test stays green —
+      the 0411 verdict-mtime defect. Prefer real files + real statSync/utimesSync
+      (the 0411 remediation) or mock a higher-level seam. Control of *subprocess
+      responses* (show/list/sync commands) is fine — only syscall emulation is
+      forbidden. sp:test-driven-development SKILL.md:164.
+    severity: warning
+    evaluator:
+      type: rg
+      config:
+        # Correlation in one bounded window: a boundary-mock installation followed
+        # (within ~700 chars) by stat/mtime syscall emulation. The window keeps
+        # legit subprocess-response mocks (which never mention stat/%m) quiet.
+        multiline: true
+        pattern: "(?:Bun\\.spawnSync\\s*=|spyOn\\(\\s*Bun\\s*,\\s*['\"]spawnSync['\"]\\s*\\)|mock\\.module\\(\\s*['\"]node:child_process['\"]\\s*\\))[\\s\\S]{0,700}?(?:cmd\\.includes\\(\\s*['\"]stat|stat\\s+-[fc]|%m|birthtime)"

package/config/templates/AGENTS.md

@@ -63,6 +63,9 @@ All product development work goes through the harness by default.
    multi-noun corpus → `sp:expert-spur`; review → `sp:super-reviewer`; docs process → `sp:doc-evolve`.
 5. **Keep tool ownership explicit** — project lifecycle/corpus/gates → Spur; plugin installation and
    capability lifecycle → Superskill. Do not hand-maintain per-platform adapters Superskill generates.
+6. **Run dev skills inline by default** — direct model-bearing `/sp:dev-*` commands execute in the
+   current coding-agent session. `--subprocess` or a named dispatch-surface trigger uses
+   `spur agent run`; direct `spur agent run` and workflow `agent.run` remain subprocess surfaces.
 
 **Platform fallback:** Platforms without slash commands and/or subagents still use the harness.
 Install the plugin through Superskill for the target platform, then use skills `sp:spur-dev`,
@@ -101,14 +104,9 @@ feature status → `05`. Working-layer, audit, and satellite rules live in the p
 
 ## Design system
 
-**Conditional contract:** If repository-root `DESIGN.md` exists, read it before planning or
-implementing any change to UI, styling, interaction, accessibility, or responsive behavior. Treat
-it as the project source of truth for visual and interaction design — tokens, components, patterns,
-and UX constraints — and keep affected work consistent with it. If it is absent, continue with the
-project's established UI conventions.
+**Conditional contract:** If repository-root `DESIGN.md` exists, leverage it dynamically as the industry-standard SSOT for UI design documentation — visual language, color tokens, typography, component specs, layout, micro-animations, accessibility, and responsive patterns. Read it before planning or implementing any UI changes, and keep affected work consistent with it. If `DESIGN.md` is absent, ignore it and continue with the project's established UI conventions.
 
-Root `DESIGN.md` owns UI/UX guidance; `docs/04_DESIGN.md` still owns command, config, schema, and DTO
-surface shapes under the doc map above.
+**Boundary distinction:** Root `DESIGN.md` owns UI/UX design guidance; `docs/04_DESIGN.md` owns non-UI surface design by default (command signatures, flags, config schemas, DTOs, and system boundaries). When working with design teams, choose `DESIGN.md` for UI/UX visual design and `docs/04_DESIGN.md` for non-UI API/schema surfaces.
 
 ---
 

package/config/templates/docs/04_DESIGN.md

@@ -18,12 +18,15 @@ sync: [T3, T9]
 > `docs/design/<slug>.md` satellite; this index carries the surface map + pointers.
 > Edit order: satellite first, then index row — same change (T9).
 
-## UI/UX boundary
+## UI/UX boundary & DESIGN.md
 
-Repository-root `DESIGN.md` owns all UI/UX design, including visual language, design tokens,
-components, layout, interaction, accessibility, and responsive behavior. Read and update it for UI
-work; keep this document focused on non-UI surface design. If `DESIGN.md` is absent, follow the
-project's established UI conventions rather than adding UI guidance here.
+Repository-root `DESIGN.md` owns all UI/UX design documentation (industry standard visual language, color tokens, typography, component specs, accessibility, and responsive patterns). Read and update it for UI work; keep `docs/04_DESIGN.md` focused on non-UI surface design by default. If `DESIGN.md` is absent, ignore it and follow the project's established UI conventions.
+
+By contrast, `docs/04_DESIGN.md` is our SSOT of non-UI surface design by default — covering CLI command signatures, flags, config schemas, DTOs, tables, and system boundaries.
+
+When collaborating with the design team:
+- **UI/UX & Visual Design:** Refer to and update repository-root `DESIGN.md`.
+- **Non-UI Surface & API/Schema DTOs:** Refer to and update `docs/04_DESIGN.md` (and `docs/design/<slug>.md` satellites).
 
 ## 1. CLI commands
 

package/config/templates/docs/99_PROJECT_CONSTITUTION.md

@@ -80,7 +80,8 @@ Each project's `AGENTS.md` embeds an instantiated copy of this table (§4.4). A
 | `docs/01_PRD.md` | **WHAT** — product vision, users, scope (in / out / deferred) | **Authoritative on scope** | Read before adding a command/feature; edit when scope changes |
 | `docs/02_ROADMAP.md` | **WHEN** — phases, current vs deferred, sequencing | Derived | Read to place work in a phase; edit when phase status changes |
 | `docs/03_ARCHITECTURE.md` | **HOW** — module boundaries, data flow, runtime model, invariants, rationale-in-depth | Derived (ADR wins) | Read before cross-module/seam/schema work; edit when boundaries or mechanisms change |
-| `docs/04_DESIGN.md` | **SURFACE** — concrete shapes: every CLI command, flag, config key, env var, table, DTO; **index over `docs/design/<slug>.md`** (§4.5) | Derived | Read/edit when changing a command, flag, env var, or schema — same commit |
+| `docs/04_DESIGN.md` | **SURFACE** — concrete shapes: every CLI command, flag, config key, env var, table, DTO; **index over `docs/design/<slug>.md`** (§4.5) | Derived | Read/edit when changing a non-UI command, flag, env var, or schema — same commit |
+| `DESIGN.md` (repo root) | **UI/UX SURFACE** — visual design, color tokens, typography, component specs, layout, micro-animations, accessibility | **Authoritative for UI/UX when present** | Read/edit when planning or implementing UI/UX visual changes (dynamically supported; ignored when absent) |
 | `docs/05_FEATURES.md` | **STATUS** — feature decomposition + state (✅ done / 🔶 partial / ⏳ planned / 💤 deferred); **index over `docs/features/<id>_<slug>.md`** (§4.5) | Derived | Read to find a feature's state; edit when a feature's status changes |
 | `docs/99_PROJECT_CONSTITUTION.md` | **PROCESS** — how the files above are maintained | **Authoritative on process** | Read before editing any doc above; edit per §6.8 |
 | `AGENTS.md` (repo root) | **ENTRY** — how agents work in this repo: stack, commands, gates, conventions + the instantiated doc map | Derived (from 99 + 00/01/04) | Read first every session; regenerate factual blocks from code (§6.7) |
@@ -89,7 +90,8 @@ Each project's `AGENTS.md` embeds an instantiated copy of this table (§4.4). A
 
 - Decision + one-line reason → `00`. Rationale/mechanism in depth → `03`.
 - Scope (in/out/deferred) → `01`. Mechanism / data flow / invariants → `03`.
-- Command/flag/config/schema/DTO shapes → `04`. Phase timing → `02`. Feature status → `05`.
+- UI/UX visual design, design tokens, component specs & accessibility → `DESIGN.md` (when present; otherwise follow established project UI conventions).
+- Non-UI command/flag/config/schema/DTO shapes → `04`. Phase timing → `02`. Feature status → `05`.
 - If you are writing *how it's built* or *why* inside `00`/`01`/`02`, it belongs in `03`/`04`.
 
 ### 4.2 Working layers (outside the authority chain)

package/config/workflows/feature-lifecycle.yaml

@@ -5,11 +5,13 @@ description: >
   Feature lifecycle FSM (design §2.3, §5.1, DD-13). States are the canonical
   FeatureStatus vocabulary; transitions encode the §2.3 graph including the
   `verifying` status (DD-13). Guards invoke `${vars.spurBin} feature check`
-  at the active→verifying and verifying→done placements. `cancelled` is terminal.
-  Guard commands reference the check verb (0057) — structural validation passes
-  today, behavioral wiring activates as the verb ships. Unconditional transitions
-  use the `always` guard (externally-driven via `requestTransition`, not
-  auto-advance).
+  at the active→verifying and verifying→done placements, passing the edge's
+  target via `--as <status>` (0418) so the one-active-goal rule evaluates the
+  post-transition state and never denies the exit it would relieve.
+  `cancelled` is terminal. Guard commands reference the check verb (0057) —
+  structural validation passes today, behavioral wiring activates as the verb
+  ships. Unconditional transitions use the `always` guard (externally-driven
+  via `requestTransition`, not auto-advance).
 initialState: backlog
 terminalStates:
   - cancelled
@@ -47,7 +49,7 @@ transitions:
     guard:
       kind: shell
       options:
-        command: '${vars.spurBin} feature check ${vars.featureId}'
+        command: '${vars.spurBin} feature check ${vars.featureId} --as verifying'
   - from: verifying
     to: done
     description: >
@@ -55,7 +57,7 @@ transitions:
     guard:
       kind: shell
       options:
-        command: '${vars.spurBin} feature check ${vars.featureId} --strict'
+        command: '${vars.spurBin} feature check ${vars.featureId} --strict --as done'
 
   # Rework: verifying → active (mandatory History entry)
   - from: verifying

package/config/workflows/task-pipeline.yaml

@@ -182,7 +182,8 @@ states:
       Record pipeline results into the task file via `spur task record` —
       Testing/Review from the verdict, Solution backfilled from git diff as a
       safety net, optional transition to testing. Post-record step conditionally syncs
-      feature status if `feature_id` is present, or appends an orphan link proposal
+      feature status via the bounded `feature-sync-bounded` wrapper (task 0411
+      retry-suppression) if `feature_id` is present, or appends an orphan link proposal
       to the run report if absent (task 0328 / ADR-0322).
     onEnter:
       - kind: shell
@@ -190,7 +191,7 @@ states:
           command: "${vars.spurBin} task record ${vars.wbs} --solution-from-diff --transition testing"
       - kind: shell
         options:
-          command: 'FID=$(${vars.spurBin} task show ${vars.wbs} --json 2>/dev/null | jq -r ".feature_id // .frontmatter.feature_id // empty"); if [ -n "$FID" ]; then ${vars.spurBin} feature sync "$FID" --json; else echo "Orphan task ${vars.wbs} — no feature_id linked; proposal: consider linking to a parent feature." >> .spur/run/${vars.wbs}-report.txt; fi'
+          command: 'FID=$(${vars.spurBin} task show ${vars.wbs} --json 2>/dev/null | jq -r ".feature_id // .frontmatter.feature_id // empty"); if [ -n "$FID" ]; then bun plugins/sp/scripts/feature-sync-bounded.ts "$FID" --spur-bin "${vars.spurBin}" --json; else echo "Orphan task ${vars.wbs} — no feature_id linked; proposal: consider linking to a parent feature." >> .spur/run/${vars.wbs}-report.txt; fi'
 
   - id: done
     description: >

package/config/workflows/wrapup-pipeline.yaml

@@ -117,13 +117,14 @@ states:
 
   - id: feature-transition
     description: >
-      If vars.feature is set, derive and sync feature status with linked task states via
-      `spur feature sync` (task 0328 / ADR-0322).
-      Replaces prior unconditional `spur feature advance` with conservative status sync.
+      If vars.feature is set, derive and sync feature status with linked task states via the
+      bounded `feature-sync-bounded` wrapper (task 0328 / ADR-0322, task 0411 retry-suppression).
+      Replaces prior unconditional `spur feature advance` with conservative status sync that
+      suppresses identical blocked retries until relevant inputs change.
     onEnter:
       - kind: shell
         options:
-          command: '${vars.spurBin} feature sync ${vars.feature} --json'
+          command: 'bun plugins/sp/scripts/feature-sync-bounded.ts ${vars.feature} --spur-bin "${vars.spurBin}" --json'
 
   - id: branch-cleanup
     description: >

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gobing-ai/spur",
-    "version": "0.3.28",
+    "version": "0.3.30",
     "description": "Spur CLI — local-first harness for mainstream coding agents: constraint checking, workflow orchestration, agent health, and history analytics. Bun-native; exposes the `spur` command.",
     "keywords": [
         "spur",
@@ -50,14 +50,14 @@
     },
     "devDependencies": {
         "@commander-js/extra-typings": "^14.0.0",
-        "@gobing-ai/ts-db": "^0.4.15",
-        "@gobing-ai/ts-ai-runner": "^0.4.15",
-        "@gobing-ai/ts-dual-workflow-engine": "^0.4.15",
-        "@gobing-ai/ts-infra": "^0.4.15",
-        "@gobing-ai/ts-llm-jsonl-importer": "^0.4.15",
-        "@gobing-ai/ts-rule-engine": "^0.4.15",
-        "@gobing-ai/ts-runtime": "^0.4.15",
-        "@gobing-ai/ts-utils": "^0.4.15",
+        "@gobing-ai/ts-db": "^0.4.16",
+        "@gobing-ai/ts-ai-runner": "^0.4.16",
+        "@gobing-ai/ts-dual-workflow-engine": "^0.4.16",
+        "@gobing-ai/ts-infra": "^0.4.16",
+        "@gobing-ai/ts-llm-jsonl-importer": "^0.4.16",
+        "@gobing-ai/ts-rule-engine": "^0.4.16",
+        "@gobing-ai/ts-runtime": "^0.4.16",
+        "@gobing-ai/ts-utils": "^0.4.16",
         "@types/bun": "1.3.14",
         "@types/figlet": "^1.7.0",
         "@types/node-notifier": "8.0.5",

package/schemas/spur-config.schema.json

@@ -239,7 +239,7 @@
         },
         "tasks": {
             "type": "object",
-            "description": "Task-folder registration (design §9). Absorbs the legacy docs/.tasks/config.json folders + base_counter concepts. Mirrors @gobing-ai/spur-config tasksConfigSchema (Zod is SSOT).",
+            "description": "Task-folder registration (design §9). Absorbs the legacy docs/.tasks/config.json folders + baseCounter concepts. Mirrors @gobing-ai/spur-config tasksConfigSchema (Zod is SSOT).",
             "properties": {
                 "folders": {
                     "type": "object",