@gobing-ai/spur 0.3.61 → 0.3.62

package/plugins/sp/skills/history-anatomy/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: history-anatomy
+description: "Independent owner of diagnostic interpretation over already-imported history — the daily/ad-hoc mode contract, a closed finding taxonomy, the eleven-section report contract, and the enrich/validate rubrics. Triggers: history-anatomy, run the daily report, ad-hoc diagnosis, find issues over history."
+license: Apache-2.0
+version: 1.0.0
+metadata:
+  author: spur
+  platforms: "claude-code,codex,openclaw,opencode,antigravity,pi"
+  category: analysis-core
+  interactions:
+    - pipeline
+    - inversion
+  pipeline_steps:
+    - report
+    - identify
+    - propose
+    - generate
+  openclaw:
+    emoji: "🩺"
+see_also:
+  - sp:issue-finding
+  - sp:spur-cli
+  - sp:spur-dev
+---
+
+# sp:history-anatomy
+
+Owns **interpretation only** over already-imported history. It decides which arguments are legal
+in which mode, what counts as evidence, how findings are keyed and graded, and what a published
+report must contain, plus the rubrics its `enrich` and `validate` operations follow. It never
+launches a workflow, never reprocesses raw history files, and never mutates the corpus, docs, or sources —
+all orchestration lives in `history-anatomy.yaml` (0660), not here.
+
+This body routes to the three references; the procedure lives there (the BODY_BUDGET shape — a
+fresh skill cannot be added to the BASELINE exemption map).
+
+**Choose the mode first.** The single entry is `--mode daily|ad-hoc` (default `daily`):
+`references/modes.md`.
+
+**Then hold the report to the contract.** Every report must contain the eleven sections and every
+finding the full field set, with evidence rules and an explicit comparability verdict:
+`references/report-contract.md`.
+
+**Then apply the operations.** The workflow calls `enrich` to author the model half, and
+`validate` to gate a candidate report; neither operation launches a workflow:
+`references/operations.md`.
+
+## Primary directive
+
+- The artifact is the only evidence plane. A dimension the forensics artifact cannot support is a
+  **telemetry gap** reported as `not available` — never a raw history-file fallback.
+- Every causal claim needs **two independent signals** (or one labelled hypothesis with a
+  confirmation path). Every finding carries at least one evidence anchor. No anchor, no finding.
+- The report never states a trend, delta, or percentage it cannot support — an insufficient or
+  materially different baseline renders `not comparable`, with no fabricated comparison.
+- Findings are keyed on a **stable key**, never the prose title, so rewording never reclassifies
+  recurrence.
+- Remediation options are **proposals only**: an owner surface, expected impact, a verification
+  method, and reversibility. No applied change, diff, or command the report claims to have run.
+
+## Read the references
+
+| Reference | Owns |
+| --- | --- |
+| [`references/modes.md`](references/modes.md) | The daily/ad-hoc mode matrix, bounds normalization, the DST-aware calendar-day rule, and the fail-loud message shape. |
+| [`references/report-contract.md`](references/report-contract.md) | The eleven sections (in order), the per-finding field set, the closed category vocabulary, the stable-key grammar, the evidence rules, comparison semantics, recurrence classes, and the positive-pattern / remediation standards. |
+| [`references/operations.md`](references/operations.md) | The `enrich` and `validate` operation rubrics; neither launches a workflow. |

package/plugins/sp/skills/history-anatomy/references/modes.md

@@ -0,0 +1,82 @@
+# Mode contract — `sp:history-anatomy` (HA-S1, 0658)
+
+The skill resolves exactly two modes. Everything else fails loud. This matrix is the enforcement
+surface the workflow (0660) and the skill share; keep the vocabulary frozen.
+
+## Mode vocabulary (frozen)
+
+- Modes: `daily` | `ad-hoc`.
+- Unsupported value literal: `not available`.
+
+## Resolution rule
+
+`--mode <value>` selects the mode. If `--mode` is omitted, the resolved mode is **`daily`** and the
+resolved window is the **current local calendar day**.
+
+## `--mode daily` (default)
+
+| Allowed | Behavior |
+| --- | --- |
+| (none) | Default window = the current local calendar day. |
+| `--date <YYYY-MM-DD>` | Selects that local calendar day as the window. |
+
+Rejected arguments (each fails loud, naming the offending argument):
+
+| Argument | Why rejected |
+| --- | --- |
+| focus text (positional) | Daily mode has no focus string. |
+| `--since` / `--until` | Daily always uses the calendar-day window. |
+| `--output` | Daily always writes to the run directory (see 0660). |
+
+A daily invocation must print the normalized **inclusive ISO bounds** and the timezone used, so the
+wall-clock window is auditable.
+
+## `--mode ad-hoc`
+
+Requires a **non-empty focus** and **two ordered inclusive bounds**.
+
+| Argument | Rule |
+| --- | --- |
+| focus (positional) | Required; a missing or empty focus fails loud. |
+| `--since <iso>` | Required; the inclusive lower bound. |
+| `--until <iso>` | Required; must be present with `--since`; must not be earlier than `--since`. |
+| `--output <path>` | Optional; when present, writes to that explicit path. When absent, writes to the run directory. |
+
+Rejected arguments (each fails loud, naming the offending argument):
+
+| Argument | Why rejected |
+| --- | --- |
+| `--date` | Ad-hoc windows are explicit bounds, not a single date. |
+| `--recompute` | Ad-hoc never recomputes a cache (0660 owns the cache branch). |
+
+## Bounds normalization
+
+Normalize both bounds to inclusive ISO-8601 instants. The report prints the normalized bounds and
+the timezone used.
+
+## DST-aware calendar-day rule
+
+`--date <YYYY-MM-DD>` must span the **full local calendar day including any DST shift** — it is
+never a fixed 24-hour offset from local midnight.
+
+- Resolve the local timezone (the operator's configured zone; state it in the report).
+- The interval runs from the day's first local instant to the day's last local instant.
+- On a 23-hour or 25-hour daylight-saving day, the interval is that actual length, not 24 hours.
+- The bounds are NOT computed as `midnight + 24h`.
+
+This is what makes a daily report's window reproducible across DST transitions.
+
+## Fail-loud message shape
+
+Every rejection names the offending argument and the rule it violated, e.g.:
+
+```
+--mode daily rejects "focus text" (daily mode has no focus string)
+--mode ad-hoc requires a non-empty focus
+--mode ad-hoc: --until is missing --since
+--mode ad-hoc: --until (2026-08-01T00:00:00Z) is earlier than --since (2026-08-02T00:00:00Z)
+--mode ad-hoc rejects --date (ad-hoc uses explicit --since/--until bounds)
+```
+
+A combined conflict (e.g. `--mode daily --since X`) reports **each** offending argument it can
+attribute; at minimum it names the first conflicting one.

package/plugins/sp/skills/history-anatomy/references/operations.md

@@ -0,0 +1,67 @@
+# Operations — `sp:history-anatomy` (HA-S1, 0658)
+
+The skill exposes exactly two operations, invoked by `history-anatomy.yaml` (0660):
+
+- `enrich` — the model is given the rendered forensics artifacts (current + baseline) and authors
+  the model half of the report.
+- `validate` — the model is given a candidate report and independently checks its evidence claims
+  against the artifacts.
+
+Both are **skill operations**, not workflows. **Neither operation launches a workflow** — that is
+the recursion guard. This is why the rubric lives here, single-sourced, rather than being
+duplicated into the YAML: the rubric cannot recurse.
+
+## Invocation contract
+
+| Operation | Input | Output |
+| --- | --- | --- |
+| `enrich` | current forensics artifact + baseline artifact (plain `HistoryArtifact` JSON) | the model-authored report sections (Baseline comparison, Findings, Recurrence ledger, Remediation options, Performance analysis, Workflow and process improvements, Positive patterns) meeting the report contract |
+| `validate` | a candidate report + the current/baseline artifacts | a PASS / FAIL verdict with per-finding and per-section evidence checks, naming any failing rule |
+
+Freeze these operation names and this input/output contract — 0660 consumes them verbatim.
+
+## `enrich` rubric
+
+Given the current and baseline artifacts, author the model half of the report. Apply, in order:
+
+1. **Scope and provenance** + **Executive summary** + **Evidence ledger** are populated from the
+   artifact and rendered deterministically (or stated as the artifact's own data). The model
+   authors only the sections listed as model-authored.
+2. **Baseline comparison** — apply the comparison semantics: daily → immediately preceding local
+   calendar day; ad-hoc → immediately preceding equal-duration window. If baseline coverage is
+   insufficient or materially different, emit `not comparable` and **no** trend/delta/percentage.
+3. **Findings** — each with the full per-finding field set (key, category, impact, trend,
+   observation, inference, confidence, contradictions, evidenceAnchor). Categories from the closed
+   vocabulary; stable keys of the form `<category>:<owner-surface>:<signal>`.
+4. **Recurrence ledger** — classify every finding against the baseline on the **stable key**.
+5. **Telemetry gaps** — every dimension the artifact cannot support, rendered `not available`.
+6. **Remediation options** — proposals only (owner surface, expected impact, verification method,
+   reversibility). No applied change/diff/command.
+7. **Positive patterns** — same evidence standard as problems.
+
+Never fabricate a value, a trend, an anchor, or an applied fix. Never launch a workflow.
+
+## `validate` rubric
+
+Given a candidate report and the artifacts, independently verify:
+
+- **Eleven-section completeness and order** — all eleven section names present in the frozen
+  order; none renamed/omitted.
+- **Per-finding fields** — every finding (problem and positive) carries key, category, impact,
+  trend, observation, inference, confidence, contradictions, evidenceAnchor; category in the closed
+  vocabulary; stable-key grammar.
+- **Evidence anchors** — every finding has at least one verifiable anchor; no anchor → FAIL.
+- **Causality gate** — a causal claim with one signal must be labelled a hypothesis with a
+  confirmation path; otherwise FAIL.
+- **Inference names observations** — an inference that does not name its supporting observations
+  FAILs.
+- **Comparability** — a `not comparable` baseline must state no trend/delta/percentage; a stated
+  trend must be supported by a comparable baseline.
+- **Recurrence integrity** — classification is consistent with the stable keys (a rewording must
+  not flip a recurring finding to new).
+- **Positive patterns** — held to the same standard; an anchor-less entry FAILs.
+- **Remediation** — proposals only; any applied change, diff, or command the report claims to have
+  run FAILs.
+
+Emit `PASS` only when every rule holds. On FAIL, name the section, the finding key, and the rule
+violated. Never launch a workflow.

package/plugins/sp/skills/history-anatomy/references/report-contract.md

@@ -0,0 +1,133 @@
+# Report contract — `sp:history-anatomy` (HA-S1, 0658)
+
+The published report is the skill's contract. This reference owns the eleven sections (in order),
+the per-finding field set, the closed category vocabulary, the stable-key grammar, the evidence
+rules, comparison semantics, recurrence classes, and the positive-pattern / remediation standards.
+
+## Eleven required sections (in order, frozen)
+
+1. Scope and provenance
+2. Executive summary
+3. Baseline comparison
+4. Findings
+5. Recurrence ledger
+6. Telemetry gaps
+7. Remediation options
+8. Performance analysis
+9. Workflow and process improvements
+10. Positive patterns
+11. Evidence ledger
+
+These names are consumed verbatim by 0659's structure gate and 0660's validation stage. Do not
+rename, reorder, omit, or restate them.
+
+## Closed category vocabulary (frozen)
+
+- Categories: `reliability` | `repetition` | `workflow` | `performance` | `coverage` |
+  `telemetry` | `positive`.
+
+Every finding's category is drawn from this closed set. No category is invented.
+
+## Stable finding key (frozen)
+
+Each finding carries a stable key of the form:
+
+```
+<category>:<owner-surface>:<signal>
+```
+
+- `category` — one of the closed vocabulary above.
+- `owner-surface` — the surface that would own a change (e.g. a module, command, or skill; free
+  text is allowed but must be stable across runs).
+- `signal` — a concise, stable machine-readable identifier of the finding.
+
+The key is the recurrence identity. Rewording a finding's title must **never** reclassify it.
+
+## Per-finding field set
+
+Every finding — problem and positive alike — carries the full field set:
+
+| Field | Requirement |
+| --- | --- |
+| `key` | Stable `<category>:<owner-surface>:<signal>` key. |
+| `category` | From the closed vocabulary, matching the key's first segment. |
+| `impact` | What the situation costs or enables (qualitative, or a concrete number where supported). |
+| `trend` | `new` / `recurring` / `regressed` / `improved` / `resolved` / `not-comparable` (see recurrence). |
+| `observation` | What the artifacts show — evidence, not interpretation. |
+| `inference` | What the observation is reasoned to mean; names its supporting observations. |
+| `confidence` | Per-finding: `high` / `medium` / `low`. Never one blanket report-level score. |
+| `contradictions` | Any contradicting signal shown beside the finding, not silently reconciled. |
+| `evidenceAnchor` | At least one anchor to the forensics artifact or cited `file:line`. An entry with no anchor is invalid. |
+
+## Evidence rules
+
+Enforcement rail for every claim:
+
+1. **Causality needs two independent signals.** A causal claim supported by two or more
+   independent signals passes. Exactly one signal is not causation — it must be labelled a
+   **hypothesis** with a stated confirmation path.
+2. **A process/workflow change needs recurrence** across two independent sessions, or a single
+   **high-impact contract violation cited at `file:line`**.
+3. **Unsupported dimensions read `not available`** and are mirrored into the telemetry-gaps
+   section. Never a fabricated value, never a raw history-file fallback.
+4. **Focus biases ranking, not collection.** A focus string changes finding ranking and emphasis;
+   it never suppresses material off-topic findings within the window.
+5. **Every inference names its supporting observations.** An inference that does not name its
+   observations fails validation.
+6. **Every finding has an evidence anchor.** No anchor, no finding — no row may be dropped because
+   it "lacks evidence" while still appearing in a summary.
+
+## Comparison semantics
+
+The baseline comparison states an explicit comparability verdict.
+
+- **Daily** compares against the **immediately preceding local calendar day**.
+- **Ad-hoc** compares against the **immediately preceding equal-duration window**.
+- **Insufficient or materially different coverage** renders **`not comparable`**.
+- A `not comparable` baseline states no trend, no delta, and no percentage. An unsupported
+  comparison is never fabricated.
+
+## Recurrence ledger
+
+Every finding is classified against the baseline using the **stable key**:
+
+- `new` — not present in the baseline.
+- `recurring` — present in the baseline with comparable severity.
+- `regressed` — present but worse (severity, count, or impact increased).
+- `improved` — present but better.
+- `resolved` — present in the baseline but absent now.
+- `not-comparable` — the baseline was `not comparable`.
+
+Matching is on the stable key, never the prose title. Rewording a title between two runs must not
+reclassify a recurring finding as new.
+
+## Positive patterns
+
+Positive entries are held to the **same evidence standard as problems**: they carry observation,
+inference, confidence, and at least one evidence anchor. An entry without an anchor is invalid. The
+section renders successful workflows, resolved past issues that stay resolved, and healthy,
+repeating behavior worth keeping.
+
+## Remediation options (proposals only)
+
+Each option is a **proposal** that names:
+
+- **owner surface** — who would apply it.
+- **expected impact** — what it is expected to change.
+- **verification method** — how the change would be confirmed.
+- **reversibility** — whether and how it can be rolled back.
+
+The report must contain **no applied change, no diff, and no command it claims to have run**. The
+skill never applies a fix; it proposes one.
+
+## Evidence ledger
+
+The final section lists, for every finding, the artifact anchor(s) and any cited `file:line`,
+so a reader can verify the report's claims against the evidence plane.
+
+## Truthfulness invariants
+
+- `not available` is the true rendering for an unsupported dimension, never a masked gap.
+- `not comparable` is the true rendering for an unsupported comparison, never a computed delta.
+- No bounded leaderboard length is presented as a population total (see 0657 / ADR-080: the
+  coverage section reads `artifact.population` and renders `top N of M`).

package/plugins/sp/skills/spur-dev/references/dev-operations.md

@@ -68,7 +68,7 @@ each would be scope creep for one-liner procedures.
 | 2   | review     | `dev-review`        | `Skill()`         | `sp:code-verification` (`review`) + `sp:functional-review` + `sp:code-improvement` | `[<wbs\|path>] [--agent <inline\|auto\|name>] [--focus <dims>] [--fix (deprecated)]`                                                                                                                   |
 | 3   | verify     | `dev-verify`        | `Skill()`         | `sp:code-verification` (`verify`)                                                  | `<wbs> [--agent <inline\|auto\|name>] [--fix <none\|blockers-first\|all>] [--focus <lens>] [--bdd] [--auto] [--force] [--next] [--skip-shippable]`                                                     |
 | 3a  | verifyall  | `dev-verifyall`     | `Skill()` → agent | `sp:spur-dev` (`verifyall`)                                                        | `--tasks <selector> [--feature <id>] [--agent <inline\|auto\|name>] [--fix <none\|blockers-first\|all>] [--focus <lens>] [--bdd] [--auto] [--force] [--next] [--json] [--skip-shippable] [--worktree [<name>]]` |
-| 4   | run        | `dev-run`           | `Skill()`         | `sp:spur-dev` (`run` / `implement`)                                                | `<wbs> [--mode <full\|implement>] [--agent <inline\|auto\|name>] [--auto] [--next] [--wrap] [--continue]`                                                                                              |
+| 4   | run        | `dev-run`           | `Skill()`         | `sp:spur-dev` (`run` / `implement`)                                                | `<wbs> [--mode <full\|implement>] [--agent <inline\|auto\|name>] [--auto] [--next] [--wrap] [--continue] [--worktree [<name>]]`                                                                                              |
 | 5   | refine     | `dev-refine`        | `Skill()`         | `sp:spur-dev` (`refine`)                                                           | `<wbs> [--focus <mode>] [--description <text>] [--depth <standard\|ready>] [--agent <inline\|auto\|name>] [--auto] [--next]`                                                                           |
 | 5a  | refineall  | `dev-refineall`     | `Skill()`         | `sp:spur-dev` (`refineall`)                                                        | `--feature <id> \| --tasks <selector> [--focus <mode>] [--description <text>] [--depth <standard\|ready>] [--agent <inline\|auto\|name>] [--auto] [--keep-going] [--status <s>] [--json] [--worktree [<name>]]` |
 | 6   | plan       | `dev-plan`          | `Skill()`         | `sp:spur-dev` (`plan`)                                                             | `"<description>" [--feature <id>] [--parent <feature-id>] [--agent <inline\|auto\|name>] [--skip-design] [--auto] [--approve-taste]`                                                                   |
@@ -140,7 +140,7 @@ must not be changed without updating the backing skill.
 ### 4. run
 
 - **Purpose:** Run a task through the execution pipeline (full) or execute a single pipeline step (implement).
-- **Inputs:** `<wbs>` (required). `--mode <full|implement>` selects the execution mode. `implement` invokes `sp:code-implementation` inline by default. Interactive `full` with omitted `--agent` or explicit `--agent inline` reads `task-pipeline.yaml` and drives its actions/guards in the host session — host-controlled and non-subprocess; **omitted** `--agent` keeps 0508 eligibility (eligible `agent.run` stages dispatch once to a native subagent, host fallback), while explicit `--agent inline` is the zero-dispatch carve-out (every stage executes in the invoking session). `--agent auto`, a name, or headless invocation launches the workflow subprocess. `--agent <inline|auto|name>` selects the execution surface (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips the HITL approve gate / confirmations and propagates down the `--next` chain. `--next` controls chaining only and never changes the mode; a pipeline implement stage must invoke `/sp:dev-run <wbs> --mode implement`. On implement success with `--next`, transition `todo → wip → testing` through the FSM (guards honored — no `--no-lifecycle`) + chain to `/sp:dev-verify <wbs> --auto --next`. On a guard failure, stop as review-pending. **Partial-deliverable rule:** if the task ships only part of its requirements (e.g. an R1/R2 split with the rest in a follow-up task), the `## Solution` section must state that explicitly and the verify verdict will record the scope. `--wrap` hands off to `/sp:dev-wrap <wbs>` after the main step; the `--agent` selector is preserved into that handoff when supplied (omission remains omission), and the wrap hop reports its own trigger-3 subprocess override per the wrap contract.
+- **Inputs:** `<wbs>` (required). `--mode <full|implement>` selects the execution mode. `implement` invokes `sp:code-implementation` inline by default. Interactive `full` with omitted `--agent` or explicit `--agent inline` reads `task-pipeline.yaml` and drives its actions/guards in the host session — host-controlled and non-subprocess; **omitted** `--agent` keeps 0508 eligibility (eligible `agent.run` stages dispatch once to a native subagent, host fallback), while explicit `--agent inline` is the zero-dispatch carve-out (every stage executes in the invoking session). `--agent auto`, a name, or headless invocation launches the workflow subprocess. `--agent <inline|auto|name>` selects the execution surface (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips the HITL approve gate / confirmations and propagates down the `--next` chain. `--next` controls chaining only and never changes the mode; a pipeline implement stage must invoke `/sp:dev-run <wbs> --mode implement`. On implement success with `--next`, transition `todo → wip → testing` through the FSM (guards honored — no `--no-lifecycle`) + chain to `/sp:dev-verify <wbs> --auto --next`. On a guard failure, stop as review-pending. **Partial-deliverable rule:** if the task ships only part of its requirements (e.g. an R1/R2 split with the rest in a follow-up task), the `## Solution` section must state that explicitly and the verify verdict will record the scope. `--worktree [<name>]` runs the full pipeline inside an isolated git worktree (create or reuse; FF-merge on success, retain on failure) — the batch lifecycle in [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name) applied to a batch of one; rejected with `--mode implement`. `--wrap` hands off to `/sp:dev-wrap <wbs>` after the main step; the `--agent` selector is preserved into that handoff when supplied (omission remains omission), and the wrap hop reports its own trigger-3 subprocess override per the wrap contract.
 - **Backing:** `sp:spur-dev` skill — `run` operation for the full pipeline (the spine drives it); `sp:code-implementation` competency skill for the implement step (the spine dispatches to it).
 - **Modes:**
   - **`full`** (default): Drive the full pipeline — precheck → implement → test → review → approve(HITL) → verify → record → done. Interactive omit/inline uses [inline-pipeline-driver.md](inline-pipeline-driver.md) (host-controlled; eligible stages may use a native subagent); explicit/headless executor selection invokes `spur workflow run task-pipeline.yaml --vars '{"wbs":"<wbs>"}'` (with `profile: auto` when `--auto`). Both monitor/surface HITL and preserve the YAML gates. `--next` never changes this mode.

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

@@ -421,6 +421,15 @@ isolated git worktree instead of the operator's working directory. This section
 lifecycle for the sequential batch loop. Per-task worktrees and `--mode parallel` isolation stay out
 of scope (task 0142 Slice A); `--worktree --mode parallel` is rejected.
 
+**Single-task `dev-run` (batch of one).** `/sp:dev-run <wbs> --worktree [<name>]` runs this same
+lifecycle with a one-task loop: WT-1…WT-6 apply unchanged, the marker's `command` is `dev-run` and
+its `selector` is the `<wbs>` (so WT-6's command+selector fallback resolves the resume), and the
+derived branch/directory slug is the WBS — `sp/run-<wbs>-<short-id>`. The WT-4 success condition
+"no failed task" reads as "the task reached terminal `done` with no failed stage"; a failing gate, a
+non-PASS verify verdict, or a HITL pause that ends the run take the WT-5 retention path. Only the
+full pipeline is eligible — `--worktree --mode implement` is rejected (WT-7), because that mode is
+the pipeline's implement stage and already runs in the driver's tree.
+
 One flag, two modes (see the glossary entry for the ownership rule). Bare `--worktree` is **create
 mode** (cut a fresh branch + sibling tree). `--worktree <name>` is **reuse mode** (attach to a tree
 that already exists); name resolution (§ WT-2 below) runs before WT-1. The deltas each mode applies
@@ -714,9 +723,13 @@ fallback, because `<name>` was explicit and unambiguous intent.
 ### WT-7 — Exclusions (R8)
 
 - **`dev-next`** does not get `--worktree` — it dispatches a single step; per-step isolation is not
-  worth the worktree cost.
+  worth the worktree cost. `dev-run` is different: it drives a whole task pipeline, so it does get
+  the flag.
 - **`--mode parallel`** is rejected when combined with `--worktree` — per-task worktrees and
   parallel isolation remain task 0142 Slice A.
+- **`--mode implement`** is rejected when combined with `--worktree` on `dev-run` — that mode *is*
+  the pipeline's implement stage (bug-742) and runs in whatever tree the driver set up; a second
+  worktree would split one task's evidence across two trees.
 - **No** create-with-name (`--worktree <name>` never creates; an unresolvable name is an error),
   no `--worktree-keep` variant, no auto-cleanup of stale worktrees or markers from prior runs.
 

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

@@ -100,6 +100,13 @@ cache-conservation discipline (`plugins/sp/skills/dogfood-testing/references/mon
 > - Without `--auto`: warn the operator before calling `spur workflow run` and prompt for confirmation or a plan-item override via `--vars '{"maxImplementPlanItems":"<count>"}'`.
 > - With `--auto`: automatically append `"maxImplementPlanItems": "<count>"` to `--vars` and log a single-line notice (e.g. `Notice: task <wbs> has N plan items (>8 default cap); injecting maxImplementPlanItems override`).
 
+**`--worktree [<name>]` wraps Step 2, on either surface.** When `/sp:dev-run --mode full` carries
+[`--worktree`](flag-glossary.md#flag-worktree), create or adopt the worktree *before* launching the
+pipeline, `cd` into it (`spur workflow run` and the inline driver both resolve cwd from the process),
+and merge-or-retain after the run reports. The lifecycle is
+[execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name)
+applied to a batch of one. Rejected with `--mode implement`.
+
 **Choose the surface before execution.** In an interactive `/sp:dev-run --mode full` invocation,
 omit/`--agent inline` selects the [inline pipeline driver](inline-pipeline-driver.md). Read the YAML
 at invocation time, allocate the inline run id/session provenance, record `task run-link`, and walk

package/plugins/sp/skills/spur-dev/references/flag-glossary.md

@@ -200,16 +200,25 @@ restrictor. On `dev-refineall` it is instead one of a required pair — supply e
 
 Select an execution mode: `full|implement` on `dev-run` (full pipeline vs implement-only),
 `sequential|parallel` on `dev-runall` (serial vs fanned-out-independent-subset),
-`fan-out|review-panel|investigation` on `dev-parallel`, and the reconstruction depth
-`briefing|structure|architecture|design|full` on `dev-reverse`. Mode selection is explicit and orthogonal
+`fan-out|review-panel|investigation` on `dev-parallel`, the reconstruction depth
+`briefing|structure|architecture|design|full` on `dev-reverse`, and `daily|ad-hoc` on
+`dev-find-issue` (the history-anatomy report mode). Mode selection is explicit and orthogonal
 to `--next`.
 
+### `--date <YYYY-MM-DD>` — local calendar day selection
+
+**Anchor:** `#flag-date`.
+
+Select a local calendar day on `dev-find-issue` (daily mode) and `dev-daily` (report date). DST-aware:
+`--date <that-date>` spans the full local calendar day including any daylight-saving shift, never a
+fixed 24-hour offset.
+
 ### `--task <wbs>` — task work or task narrowing
 
 **Anchor:** `#flag-task`.
 
 Connect the current command's result to task work, or narrow a history analysis to one task
-(`dev-brainstorm`, `dev-debug`, `dev-dogfood`, `dev-find-next`, `dev-history-load`). The value and
+(`dev-brainstorm`, `dev-debug`, `dev-dogfood`, `dev-find-next`). The value and
 the effect are per-command — this flag is a family, not one behavior:
 
 - `dev-brainstorm` `[<feature-id>]` — **creates** one task from the chosen approach, landing at
@@ -221,7 +230,6 @@ the effect are per-command — this flag is a family, not one behavior:
   id names the target instead of offering rank 1.
 - `dev-debug` `[<wbs>]` — **attaches** findings to an existing task. Optional WBS names it.
 - `dev-dogfood` (no value) — **records** run outcomes against the task under test.
-- `dev-history-load` `<wbs>` — narrows the `analyze` step to that task's messages.
 
 ### `--since <ref>` — lower bound on a range
 
@@ -250,10 +258,10 @@ Upper bound on a range: a git ref on `dev-changelog` (defaults to `HEAD`), or an
 
 **Anchor:** `#flag-source`.
 
-Scope the operation to one agent source (`dev-find-issue`, `dev-history-load`): one of
-`pi|claude|codex|gemini|opencode|antigravity|openclaw|omp|grok|agy` (or `all`). On
-`dev-history-load` the value is forwarded to **both** `spur history import` and
-`spur history analyze`; on `dev-find-issue` it narrows the report scan to that source's sessions.
+_(Removed 2026-08-24, HA-S1 0661.)_ The only two commands that consumed this flag;
+`dev-find-issue` (now a `sp:history-anatomy` forwarder) and `dev-history-load` (deleted) no
+longer declare it, so the entry is dead and removed. The underlying `spur history` surfaces
+retain their own `--source` handling.
 
 ### `--status <s>` — filter by task status
 
@@ -280,7 +288,8 @@ Omit the design package (system-design satellite + task `### Design`) on plannin
 
 **Anchor:** `#flag-output`.
 
-Write the command's result to a file path (`dev-daily`, `dev-reverse`) instead of stdout.
+Write the command's result to a file path (`dev-daily`, `dev-find-issue`, `dev-reverse`) instead of
+stdout. On `dev-find-issue` (ad-hoc mode) an explicit path replaces the default run-directory write.
 
 ### `--merge` — trigger branch cleanup
 
@@ -359,8 +368,9 @@ flag sets both.
 
 **Anchor:** `#flag-worktree`.
 
-Batch commands only (`dev-refineall`, `dev-runall`, `dev-verifyall`): run the entire driver loop
-inside an isolated git worktree instead of the operator's working directory. One flag, two modes:
+Batch commands plus single-task `dev-run` (`dev-refineall`, `dev-runall`, `dev-verifyall`,
+`dev-run`): run the entire driver loop inside an isolated git worktree instead of the operator's
+working directory. One flag, two modes:
 
 - **Create mode** — bare `--worktree` (no value). Cut a fresh branch from the current HEAD's ref,
   create a sibling worktree with a derived name, run the batch there. On a fully successful batch
@@ -385,8 +395,10 @@ merges but never removes. This keeps the continue-the-work loop stable — after
 **Value binding.** The following token is consumed as `<name>` **only when it does not begin with
 `-`**, so `--worktree --auto` is the bare create form and `--agent`/`--feature`/etc. are never
 swallowed as the name. `--worktree=<name>` is the unambiguous spelling. `/sp:dev-next` does not get
-the flag (single step; not worth the worktree cost), and `--worktree --mode parallel` is rejected
-(per-task parallel isolation stays task 0142). The full lifecycle — name resolution, dirty-tree
+the flag (single *step*; not worth the worktree cost — unlike `dev-run`, which isolates a whole
+task pipeline), `--worktree --mode parallel` is rejected (per-task parallel isolation stays task
+0142), and `--worktree --mode implement` is rejected on `dev-run` (that mode *is* the pipeline's
+implement stage and runs in the driver's tree). The full lifecycle — name resolution, dirty-tree
 precheck, creation or adoption, crash-safe marker, merge-or-retain, and `--continue` re-entry — is
 specified in [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name).
 Portable `git worktree` commands only; the git mechanics are reused from