@gobing-ai/spur 0.3.81 → 0.3.83

package/.claude-plugin/marketplace.json

@@ -7,7 +7,7 @@
     "plugins": [
         {
             "name": "sp",
-            "version": "0.3.81",
+            "version": "0.3.83",
             "source": "./plugins/sp"
         }
     ]

package/config/config.example.yaml

@@ -180,24 +180,26 @@ agent:
   #   dev-run: omp
   #   dev-review: claude
 
-  # A project's agent roster is a **fleet** declared in the project's own tree,
-  # not in this file: `<projectPath>/.spur/fleet.json` (ADR-116, task 0835).
-  # Materialized at `spur serve` start; preview with `spur projects list --fleet`.
-  # Shape (version is pinned; a member declares role or executor):
-  #   {
-  #     "version": 1,
-  #     "members": [
-  #       { "role": "planner", "purpose": "orchestrator" },
-  #       { "role": "coder", "executor": "omp" },
-  #       { "role": "reviewer", "enabled": false }
-  #     ],
-  #     "orchestrator": "planner-1"
-  #   }
+  # A project's agent roster is a **fleet** declared in the project's own
+  # `.spur/config.yaml` under `agent.fleet` — never in this global file, and never
+  # in the retired `<projectPath>/.spur/fleet.json` (ADR-116 carrier moved by task
+  # 0858). Materialized and autostarted at `spur serve` start only when
+  # `agent.fleet.enabled` is true; preview with `spur projects list --fleet`.
+  # Shape (project layer; a member declares role or executor):
+  #   agent:
+  #     fleet:
+  #       enabled: true
+  #       strategy: gtd            # rest | gtd (default rest)
+  #       orchestrator: planner-1
+  #       members:
+  #         - { role: planner, purpose: orchestrator }
+  #         - { role: coder, executor: omp }
+  #         - { role: reviewer, enabled: false }
   # `enabled: false` keeps the member's derived `<role>-<n>` id index, so later
-  # members never silently reallocate ids. The legacy `agent.team.<teamId>`
-  # config key still parses — the `spur team` noun is deprecated, not removed —
-  # but the roster is keyed on the worktree path now, not on a config-global
-  # team name.
+  # members never silently reallocate ids. The retired per-team config key is no
+  # longer read — a leftover block fails the load and names `agent.fleet` as the
+  # replacement — a leftover `fleet.json` fails the load too, and the roster is
+  # keyed on the worktree path now, not on a config-global team name.
 
 rules:
   paths:

package/config/config.global.yaml

@@ -19,9 +19,12 @@
 # Only machine-wide keys belong in this file. Project-shaped keys — `name`,
 # `bootstrap`, `rules`, `redaction`, `tasks`, `features` — resolve against a
 # project's own folder structure and must stay in `.spur/config.yaml`. The agent
-# roster is not a config key at all any more: it is `<projectPath>/.spur/fleet.json`
-# (ADR-116, task 0835). The legacy `agent.team` key still parses; the `spur team`
-# noun is deprecated (0848).
+# roster is not a config key at all any more: it is the project-layer `agent.fleet`
+# section of `.spur/config.yaml` (ADR-116 carrier moved by 0858; it replaced
+# `<projectPath>/.spur/fleet.json`). The retired team roster key is gone: a leftover
+# block fails the load and names `agent.fleet` as the replacement (0857), a leftover
+# `fleet.json` fails it too (0858), and the `spur team` noun was removed at the G64
+# cutover.
 
 $schema: "@gobing-ai/spur/schemas/spur-config.schema.json"
 

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

@@ -3,7 +3,7 @@ name: Project Constitution
 doc: 99_PROJECT_CONSTITUTION
 owns: PROCESS — how the key files are maintained
 authority: authoritative-on-process
-version: 1.6.0
+version: 1.7.0
 created_at: {{init-date}}
 updated_at: {{init-date}}
 edit_rules: 99 §6.8
@@ -35,10 +35,12 @@ Within project documentation, authority is scoped to the question:
 | Visual and interaction design | Root `DESIGN.md`, when present |
 | Delivery sequence, current mechanisms, non-UI contracts, feature state | `02`–`05`, derived within their respective responsibilities |
 
-Lower numbers win content conflicts within the same subject; `99` governs maintenance across
-all key files. Neither an ADR nor a task can silently change the constitution. An ADR is not
-a universal override for unrelated scope or UI facts. Fix the authoritative statement first,
-then affected projections; never average conflicting statements. Keep document numbers stable.
+The designated subject owner governs; document numbers do not confer authority over another
+owner's subject. `99` governs maintenance across all key files. Neither an ADR nor a task can
+silently change the constitution. Identify the governing statement first; correct it only if
+defective, otherwise repair the conflicting projection. If authoritative statements conflict and
+existing authorization does not resolve them, report the conflict rather than invent a decision.
+Never average conflicting statements. Keep document numbers stable.
 
 ## 3. Shared tools
 
@@ -118,7 +120,7 @@ it does not require touching every key file for each feature or task.
 | T1 | New architectural choice passing §6.1, or reversal | Record `00` before divergence; update affected `03`/`04`; `01` only if scope changes |
 | T2 | Implementation would contradict an existing ADR | Record the decision amendment or superseding ADR before implementing the contradiction |
 | T3 | CLI/API/config/schema/DTO or non-UI behavior changes | Update the owning `04` satellite; index and `AGENTS.md` only if their own facts change |
-| T4 | Feature lifecycle or acceptance changes | Update through the feature tool and refresh its generated projection; `01` only for scope changes |
+| T4 | Feature hierarchy, scope, lifecycle or acceptance changes | Apply §6.6 authorization; update through the feature tool and refresh its generated projection; `01` only for product scope changes |
 | T5 | Phase goal, order, dependency, or exit changes | Update `02`; task completion alone does not trigger a roadmap entry |
 | T6 | Product scope added, removed, or deferred | Update `01`; `02` if sequencing changes |
 | T7 | Authorized change to document responsibilities, authority, or maintenance rules | Update `99`, affected entry/routing instructions, and in-scope init templates |
@@ -141,18 +143,23 @@ Do not append to a key file merely to prove work happened.
 
 ### 6.1 `docs/00_ADR.md`
 
-Admit a decision only if it selects among meaningful alternatives and establishes or changes
+Every entry and amendment MUST select among meaningful alternatives and establish or change
 a lasting architecture boundary or invariant across features/modules: dependency direction,
 persistence ownership, trust model, protocol, runtime or shared execution model. Record the
 choice, context/reason, material tradeoff/consequence, status/date, and a detail pointer.
 
+Entries and amendments MUST remain precise and concise. State the decision and its rationale
+once; link detailed contracts and implementation guidance to their owners. Naming a feature,
+task, technology or technical concern alone does not establish architectural significance.
+
 Single-feature design, public-surface consent, task progress, test results and implementation
 receipts go to their design/task records. Bug fixes that restore an existing contract need no ADR.
 Doc-map and maintenance changes belong in `99`, not an ADR certifying a constitution edit.
 
 - One architectural decision per entry. New choices append; reversals name the superseded ADR.
 - Never renumber, reuse or delete an ADR ID. Preserve original titles/anchors and dates.
-- Corrections to the decision use dated amendments; amendments record a decision delta only.
+- Corrections to the decision use dated amendments stating only what changed and why. Amendments
+  must pass the same admission test; editorial corrections update wording in place without an addendum.
 - Editorial condensation may remove repetition and misplaced detail while preserving the choice,
   rationale, material alternatives, consequences and amendment history. It must not silently
   reverse a decision or present a historical choice as current.
@@ -195,6 +202,26 @@ parallel hand-written status table. Requirements, acceptance and decomposition l
 records; execution evidence lives in task records. Verify status and acceptance against evidence
 before relying on them. Never raw-edit satellites or generated regions.
 
+The project is the logical tree root; its direct children are top-level features, without requiring
+an extra persisted project node. Each top-level feature MUST represent a durable project module,
+product capability or project-wide concern. Its scope and top-level placement MUST be supported
+by an explicit requirement or approval from the operator or designated product owner.
+
+Record the supporting requirement or approval reference in the feature record through its tool.
+Existing explicit authorization is sufficient. Implementation, silence, task approval or an agent's
+recommendation does not establish approval for top-level placement.
+
+Prefer an existing owner. Children decompose their parent's approved scope; sibling boundaries
+must be clear and avoid duplicate ownership. A task, delivery wave, incident, technical detail or
+child-count limit alone does not justify a new top-level feature.
+
+Creating or promoting a top-level feature, materially redefining its scope, or merging or removing
+top-level boundaries requires explicit authorization covering that change. Routine decomposition
+within approved scope needs no repeated approval.
+
+For legacy roots without recorded provenance, report the gap without inventing approval or
+automatically restructuring the tree. Preserve history and references during authorized migration.
+
 ### 6.7 `AGENTS.md`
 
 Keep essential orientation, commands, boundaries and document routing. Verify facts from the
@@ -213,20 +240,54 @@ is not a reason to edit this file or bump its metadata. Keep implementation-spec
 and tool bindings in their owners. Do not automatically promote lessons into constitutional rules.
 Update authorized templates/copies; do not mutate unrelated repositories without authorization.
 
+### 6.9 `DESIGN.md` (root, when present)
+
+Keep shared visual and interaction rules, including accessibility and responsive behavior. Link
+detailed UI references; distinguish current conventions from proposed changes. Preserve required
+accessibility behavior when simplifying. Non-UI contracts belong in `04`; delivery status stays
+in feature/task records. Update this owner when shared UI rules change, not for every screen edit.
+
 ## 7. Drift control
 
-Audit the affected owners, using source/help, manifests, Git diffs, generated indexes and links:
+### 7.1 Detection
+
+During relevant document edits and task wrap-up, check affected owners and their references using
+source/help, manifests, Git diffs, generated indexes and links. A comprehensive audit is a separate
+scope; routine work does not require a repository-wide sweep.
 
 - Responsibility: content belongs to the file's §4.1 row; no competing ledger or rule owner.
 - Reality: current contracts/mechanisms match source; proposed/historical content is labeled.
 - Scope/status: `01` covers capabilities; phase/feature claims have current evidence.
+- Feature structure: top-level boundaries have §6.6 provenance; decomposition stays within approved scope.
 - References: IDs, heading anchors, index pointers and aliases still resolve.
 - Synchronization: apply §5 to changed facts; unchanged owners need no edit.
 - Metadata/templates: contracts and dates match actual edits; portable guidance agrees.
 
-Repair authority first, then affected detail/index/entry files. Record findings and verification
-in the task or a dated report, including unverified claims. Do not claim a repository-wide audit
-from focused checks. An ADR content reversal follows §6.1; editorial cleanup preserves history.
+### 7.2 Automatic repair
+
+Automatically repair confirmed documentation defects when authoritative evidence supports the
+correction, approved meaning is preserved, and the repair falls within authorized work. Examples
+include broken references with a verified destination, duplicate prose, misplaced detail, stale
+factual descriptions, and generated projections refreshed through their owning tools.
+
+Identify the governing owner first. Correct it only if its statement is defective; otherwise repair
+the conflicting projection. Observed implementation is evidence of current behavior, not authorization
+to change accepted scope, decisions or contracts.
+
+Auto-healing MUST NOT invent requirements or approvals, reverse architectural decisions, weaken
+acceptance criteria or gates, fabricate completion evidence, or amend this constitution outside §6.8
+authorization. Apply an already-authorized change without requesting approval again; otherwise report
+the conflict and proposed resolution. An authorized ADR reversal follows §6.1.
+
+Preserve decision history, stable references and unrelated edits. Regenerate tool-owned content
+through its tool. Synchronize affected detail/index/entry files and in-scope templates under §5.
+
+### 7.3 Verification and unresolved findings
+
+After repair, verify affected contracts, links, metadata and template parity with the applicable
+checks. Record findings, verification and unresolved or unverified claims in the task or a dated
+report. Do not claim a repository-wide audit from focused checks. If evidence remains ambiguous
+or a repair fails verification, stop that repair and report the cause; do not declare it healed.
 
 ## 8. Lessons learned per file
 
@@ -243,6 +304,7 @@ this routing rule, not an instruction to append lessons here.
 Seed `00`–`05`, this constitution and `AGENTS.md` through the project initializer. Fill project
 facts from actual requirements and manifests; leave unknowns explicit. Do not pre-accept an
 ADR, invent a completed phase, or create fictitious feature/status rows in a fresh project.
-Use the feature tool for its index. Keep `DESIGN.md` optional; author it when UI work needs a
+Start feature decomposition from approved requirements and apply §6.6 before creating top-level
+features. Use the feature tool for its index. Keep `DESIGN.md` optional; author it when UI work needs a
 shared design language. Preserve existing customized docs and supported entry symlinks.
 Read `AGENTS.md` first, then the owners relevant to the work.

package/config/transition-shims.json

@@ -21,13 +21,6 @@
             "file": "packages/app/src/services/agent-service.ts",
             "keepsWorking": "a configured executor name in agent.default still resolves during the transition, warned once by warnAgentDefaultExecutorOnce; the value domain moved to roles (recommended default: coder)",
             "removalCondition": "no agent.default value names an agent.executors entry (scan .spur/config.yaml and config/config.example.yaml against the agent.executors names)"
-        },
-        {
-            "id": "team-noun-retired",
-            "wbs": "0848",
-            "file": "apps/cli/src/commands/team.ts",
-            "keepsWorking": "the `spur team` noun keeps working after its six verbs moved to owning nouns (0848): assign → `spur task update --assignee`, status → `spur agent list --specs`, up → fleet materialization at serve start (`spur projects list --fleet` for --check), down/start/stop → `spur agent stop|start|stop <spec-id>`; a one-time stderr warning (warnTeamNounRetiredOnce) names the replacement for the invoked verb and every verb keeps its previous exit code and output",
-            "removalCondition": "no `spur team` invocation remains in config/workflows/, plugins/sp/, scripts/, or docs/, and the cutover window is recorded in docs/features/G64_retire-workspace-inbox-teams-and-spur-team.md"
         }
     ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gobing-ai/spur",
-    "version": "0.3.81",
+    "version": "0.3.83",
     "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",

package/plugins/sp/README.md

@@ -185,7 +185,7 @@ pipeline step.
 
 ```
 plugins/sp/
-├── skills/                          # Domain knowledge + workflow docs (34 skills)
+├── skills/                          # Domain knowledge + workflow docs (38 skills)
 │   ├── brainstorm/                  # Structured ideation workflow
 │   │   ├── agents/openai.yaml
 │   │   ├── examples/ideation-example.md
@@ -231,9 +231,10 @@ plugins/sp/
 │   ├── spur-doctor/                 # Read-only artifact evaluation → proposal table (backs spur-composer)
 │   ├── spur-dev/                    # Thin planning→execution orchestration spine
 │   │   └── references/  # ac-style-guide, cross-cutting, decision-brief, dev-operations,
-│   │                      execution-batch, execution-workflow, feature-link-helper,
-│   │                      flag-glossary, gate-checklists, glossary, planning-workflow,
-│   │                      product-planning  (12 files)
+│   │                      done-housekeeping, execution-batch, execution-workflow,
+│   │                      feature-link-helper, flag-glossary, gate-checklists, glossary,
+│   │                      idea-evaluation, inline-pipeline-driver, planning-workflow,
+│   │                      product-planning, section-batching  (16 files)
 │   ├── test-driven-development/                    # TDD workflow companion (SKILL.md only)
 │   ├── reverse-engineering/         # Codebase reverse engineering / HLD / audit
 │   │   ├── agents/openai.yaml
@@ -255,6 +256,10 @@ plugins/sp/
 │   │   └── references/decision-method.md
 │   ├── sys-debugging/               # Structured debugging protocol
 │   │   └── references/debugging-protocol.md
+│   ├── taste-refactoring-api/       # API contract design + refactor (checklists, examples, references)
+│   ├── taste-refactoring-architect/ # Minimum-sufficient architecture review + refactor
+│   ├── taste-refactoring-tests/     # Test-suite failure-sensitivity refactor
+│   ├── taste-refactoring-ui/        # UI hierarchy, layout, typography + interaction refactor
 │   └── wayfinder/                   # Multi-session investigation maps (SKILL.md only)
 ├── commands/                        # 39 slash-command wrappers — the SSOT (hand-editable thin wrappers; see Commands below)
 ├── agents/                          # 4 specialist subagents (expert-spur, super-coder, super-planner, super-reviewer)
@@ -323,7 +328,7 @@ surface or run one workflow. All skills target the same five core platforms: `cl
 | `brainstorm`                | 1.0.0 | Structured ideation workflow — generate solution options with trade-offs and confidence scoring                                                                                                                                            |
 | `wayfinder`                 | 1.0.0 | Multi-session investigation maps — chart a spur feature as the map when the destination itself is foggy, then resolve one ticket per session until the route is clear                                                                      |
 | `daily-summary`             | 1.0.0 | Daily summary report generator — orchestrates ccusage CLI + git history into structured markdown summaries                                                                                                                                 |
-| `doc-evolve`                | 1.0   | Key-document evolution per `docs/99_PROJECT_CONSTITUTION.md` — drift audits, same-commit sync checks, frontmatter-contract verification, machine-appended lessons                                                                          |
+| `doc-evolve`                | 1.1   | Key-document evolution per `docs/99_PROJECT_CONSTITUTION.md` — drift audits, same-commit sync checks, frontmatter-contract verification, machine-appended lessons                                                                          |
 | `reverse-engineering`       | 1.1   | Codebase analysis / HLD generation / audit — depth-driven reverse engineering with orthogonal mode, focus, and format controls; backs `/sp:dev-reverse`                                                                                    |
 | `issue-finding`             | 2.0   | Session-log forensics — multi-source discovery, bottleneck ranking, optional topic focus, CLI-gated fix task generation; **legacy path** — superseded by `history-anatomy` for indexed reporting; backs no current command; directly invocable as sp:issue-finding |
 | `conflict-finding`          | 1.0   | Authority-aware semantic audit — four-pillar (source/task/feature/authority) conflict discovery, claim-specific authority resolution, reproducible evidence, confirmed owner-routed remediation; backs `/sp:dev-find-conflict`             |
@@ -375,7 +380,7 @@ command is a user-facing entry point that bridges natural language to skill invo
 
 | Prefix       | Count | Delegates to                                                                                                                                                                                                                                                                                                        | Purpose                                                                                |
 | ------------ | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
-| `dev-*`      | 33    | `sp:spur-dev`, `sp:code-implementation`, `sp:code-testing`, `sp:code-verification`, `sp:code-simplification`, `sp:next-router`, `sp:brainstorm`, `sp:dogfood-testing`, `sp:parallel-execution`, `sp:sys-debugging`, `sp:daily-summary`, `sp:history-anatomy`, `sp:session-review`, `sp:conflict-finding`, `sp:reverse-engineering`, `sp:pr-reviewing`, inline | The dev-workflow surface — planning, execution, batch, wrap-up, review/verify, hygiene |
+| `dev-*`      | 33    | `sp:spur-dev`, `sp:spur-cli`, `sp:next-router`, `sp:next-feature`, `sp:brainstorm`, `sp:wayfinder`, `sp:sys-architecture`, `sp:code-implementation`, `sp:code-testing`, `sp:code-verification`, `sp:functional-review`, `sp:code-improvement`, `sp:code-simplification`, `sp:sys-debugging`, `sp:dogfood-testing`, `sp:parallel-execution`, `sp:history-anatomy`, `sp:session-review`, `sp:conflict-finding`, `sp:reverse-engineering`, `sp:pr-reviewing`, inline | The dev-workflow surface — planning, execution, batch, wrap-up, review/verify, hygiene |
 | `rule-*`     | 3     | `sp:spur-cli`                                                                                                                                                                                                                                                                                                       | The rule surface — `rule-add`, `rule-refine`, `rule-scan`                              |
 | `workflow-*` | 2     | `sp:spur-cli`                                                                                                                                                                                                                                                                                                       | The workflow surface — `workflow-add`, `workflow-refine`                               |
 | `spur-init`  | 1     | `sp:doc-evolve`                                                                                                                                                                                                                                                                                                     | Project bootstrap (`spur init`) with doc-evolve integration                            |
@@ -429,17 +434,18 @@ the pipeline's Phase 7 review step.
 
 | Agent            | Shape        | Delegates to                                                            | Color   | Trigger examples                                                                |
 | ---------------- | ------------ | ----------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------- |
-| `expert-spur`    | expert       | `sp:spur-cli`                                                           | green   | "create tasks", "feature lifecycle", "add a rule", "author a workflow"          |
+| `expert-spur`    | expert       | `sp:spur-cli` + `sp:spur-composer` + `sp:spur-doctor`                    | green   | "create tasks", "feature lifecycle", "add a rule", "author a workflow"          |
 | `super-coder`    | builder      | `sp:sys-architecture` + `sp:code-implementation` + `sp:code-testing` + `sp:sys-debugging` | blue    | "implement this", "write the code", "fix this bug", "design the architecture"   |
 | `super-planner`  | orchestrator | `sp:spur-dev` + `sp:parallel-execution` + `sp:dogfood-testing` + `sp:next-router` | green   | "run this task end to end", "run all tasks", "run the batch", "runall"          |
 | `super-reviewer` | reviewer     | `sp:code-verification` + `sp:functional-review` + `sp:code-improvement` | crimson | "review this", "check the code", "SECUA review", "run task 0042 through review" |
 
 Each agent has:
 
-- `skills: [sp:<skill-name>]` - bound to one (`expert-spur`), four (`sp:sys-architecture`,
-  `sp:code-implementation`, `sp:code-testing`, `sp:sys-debugging` for `super-coder`; `sp:spur-dev`,
-  `sp:parallel-execution`, `sp:dogfood-testing`, `sp:next-router` for `super-planner`), or three
-  (`sp:code-verification`, `sp:functional-review`, `sp:code-improvement` for `super-reviewer`).
+- `skills: [sp:<skill-name>]` - each agent is bound to the skills it dispatches: three for
+  `expert-spur` (`sp:spur-cli`, `sp:spur-composer`, `sp:spur-doctor`) and `super-reviewer`
+  (`sp:code-verification`, `sp:functional-review`, `sp:code-improvement`); four for `super-coder`
+  (`sp:sys-architecture`, `sp:code-implementation`, `sp:code-testing`, `sp:sys-debugging`) and
+  `super-planner` (`sp:spur-dev`, `sp:parallel-execution`, `sp:dogfood-testing`, `sp:next-router`).
 - `model: inherit` — inherits the parent session's model.
 - `color` — roster display accent.
 - `tools` — allowed tool set (`Read`, `Grep`, `Glob`, `Bash`, `Skill`).
@@ -502,7 +508,7 @@ hold `SKILL.md` and prompt-side companions only.
 | `scripts/daily-summary/{daily-summary,logger}.ts`    | ccusage + git-history orchestration helpers for `sp:daily-summary`                                                                                                                                                                                                                                |
 | `scripts/feature-sync-bounded.ts`                    | Bounded retry-suppression wrapper for `spur feature sync` during batch/wrap-up runs — suppresses identical L4-blocked repeats                                                                                                              |
 | `scripts/stage-registry-adapter.ts`                  | dev-next golden-path adapter over the canonical stage registry — TABLE A/B/C resolution bridge for the status-aware facade                                                                                                                |
-| `scripts/task-size-precheck.ts`                      | Pipeline size precheck guard (R2) + size-vs-executor-capability gate (R3) — evaluates R-item/Plan-count limits to PASS/FAIL                                                                                                              |
+| `scripts/task-size-precheck.ts`                      | Pipeline size precheck guard (R2) — evaluates R-item/Plan-count limits to PASS/FAIL                                                                                                              |
 | `scripts/validate-flag-contracts.ts`                 | Mechanical consistency gate — compares flag claims across command files, flag-glossary, cross-cutting, dev-operations, and ADR; reports disagreements                                                                                    |
 | `*.test.ts`                                          | Unit suites — in `hooks/` for guards, in `tests/<skill>/` per ADR-031 pairing                                                                                                                                                                                                                     |
 
@@ -536,7 +542,7 @@ graph TB
     end
 
     subgraph "Execution layer"
-        CLI["spur CLI<br/>task · feature · rule · workflow<br/>· agent · history · team · message"]
+        CLI["spur CLI<br/>task · feature · rule · workflow<br/>· agent · history · message"]
         SCRIPT["hooks/task-write-guard.ts"]
     end
 

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

@@ -87,8 +87,8 @@ their runbook here.
 - Drive a task batch through execution, chain campaigns into a recurring loop, or dispatch and
   coordinate multiple agents — no batch driving, no recurring loops, no coordination dispatch here;
   they hand off to `sp:super-planner` or a workflow.
-- Use `spur team` or `spur agent loop` — both are forbidden surfaces. Agent specs are reached only
-  through `spur agent create|edit|delete|list --specs`.
+- Use `spur agent loop` — a supervisor-internal, forbidden surface. Agent specs are read through
+  `spur agent list --specs`.
 
 ## Output Format
 
@@ -124,4 +124,4 @@ recurring evolution loops, and multi-agent coordination are not dispatch duties
 to `sp:super-planner` or a workflow definition. If the operator explicitly asks for a follow-up
 corpus dispatch, its surface contract is
 [dispatch-surface.md](../skills/parallel-execution/references/dispatch-surface.md): native subagent
-by default, `spur agent run` only on a named trigger — never `spur team` or `spur agent loop`.
+by default, `spur agent run` only on a named trigger — never `spur agent loop`.