@gobing-ai/spur 0.3.51 → 0.3.53

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
     },
     "plugins": [
         {
-            "version": "0.3.51",
+            "version": "0.3.53",
             "name": "sp",
             "source": "./plugins/sp",
             "description": "Spur - my harness toolkits"

package/config/corpus-baseline.json

@@ -239,14 +239,6 @@
             "reason": "BDD step-order advisory (\"When\" after \"Then\") — see note § L3.ac-bdd-warning.",
             "since": "2026-08-17"
         },
-        {
-            "kind": "feature",
-            "id": "I",
-            "code": "L4.orphan-scenarios",
-            "severity": "warning",
-            "reason": "Feature AC scenarios have no linked task (orphan scenarios) — see note § L4.orphan-scenarios.",
-            "since": "2026-08-17"
-        },
         {
             "kind": "feature",
             "id": "I1",
@@ -271,6 +263,14 @@
             "reason": "Linked task lacks a PASS verdict with MET requirement — verification pending, see note § L4.scenario-unverified.",
             "since": "2026-08-17"
         },
+        {
+            "kind": "feature",
+            "id": "I",
+            "code": "L4.uncovered-feature-scenario",
+            "severity": "warning",
+            "reason": "Feature I (sp plugin) ownership scenarios (\"Plugin work has one active root\", \"Runtime execution remains separate\", \"Legacy H does not receive new work\") are planning/ownership assertions not covered by any linked task AC. Task 0600 links feature I (superskill-entrypoint alignment) but its AC do not route ownership; the link changed the report from L4.orphan-scenarios to uncovered-feature-scenario (DD-09). Cover by a future feature-I ownership task.",
+            "since": "2026-08-19"
+        },
         {
             "kind": "feature",
             "id": "J",

package/config/tasks/section-matrix.yaml

@@ -1,12 +1,17 @@
 # Section-Status-Matrix: which sections are required/optional/forbidden per task status.
-# Design §3.2 — evaluated CLI-side only. Ships permissive; tightened by compliance data.
+# Design §3.2 — the SOLE semantic authority for task section layout (F92 R1):
+#   * VALIDATION (`spur task check`, incl. target-aware `--as <status>` lifecycle guard)
+#   * CREATION (`spur task create` / `spur task batch-create` -> `buildTaskSkeleton`)
+# There is NO hand-maintained creation or matrix fallback — packaged/compiled
+# execution loads data copied/generated from THIS canonical file and fails loudly
+# if no asset is reachable. Template files supply section BODY content + guidance
+# only; they never own the heading list (which comes from this matrix).
 #
 # Each VARIANT (the unified template axis — TASK_VARIANTS) maps status →
 # { required, optional, forbidden } section lists. Sections reference the canonical
 # section vocabulary (§2.1). `gate: true` on a status makes L2 violations hard errors.
 #
 # The variant is selected by a task's `template:` frontmatter (default: `standard`).
-# It drives BOTH validation (`spur task check`) AND creation (`buildTaskSkeleton`).
 $schema: "@gobing-ai/spur/schemas/section-matrix.schema.json"
 
 variants:

package/config/workflows/task-lifecycle.yaml

@@ -12,15 +12,16 @@ name: task-lifecycle
 description: >
   Task lifecycle FSM (design §2.3, §5.1). States are the canonical TaskStatus
   vocabulary (DD-01); transitions encode the §2.3 graph; guards invoke
-  `${vars.spurBin} task check` at the wip→testing and testing→done placements.
+  `${vars.spurBin} task check --as <target>` at the wip→testing and testing→done
+  placements (F92 R3): each guard evaluates the task AS the transition target so
+  testing→done checks the `done` row instead of the current `testing` row.
   `done` is re-enterable (reopen with a warning); `cancelled` is terminal.
-  Guard commands reference the check verb (0051) — structural validation passes
-  today, behavioral wiring activates as the verb ships. Unconditional transitions
+  Guard commands reference the check verb (0051). Unconditional transitions
   use the `always` guard (externally-driven via `requestTransition`, not
   auto-advance).
 
   Two-layer done gate (task 0292): this workflow's testing→done guard
-  (`spur task check --strict-core`) is the FIRST gate. The CLI verdict guard
+  (`spur task check --as done`, F92 R3 — target-aware) is the FIRST gate. The CLI verdict guard
   (`packages/app/src/services/done-transition-guard.ts`) is the SECOND gate,
   invoked by `apps/cli/src/commands/task.ts` for every `spur task update <wbs>
   done` call — it reads `.spur/run/<wbs>-verdict.json` and blocks non-PASS
@@ -69,14 +70,14 @@ transitions:
     guard:
       kind: shell
       options:
-        command: '$spurBin task check $wbs'
+        command: '$spurBin task check $wbs --as testing'
   - from: testing
     to: done
     description: Testing passed — task complete
     guard:
       kind: shell
       options:
-        command: '$spurBin task check $wbs --strict-core'
+        command: '$spurBin task check $wbs --as done'
 
   # Reopen: done → wip (warned, mandatory History entry)
   - from: done