---
name: flag-glossary
description: "Extracted sections (task 0408): the shared-flag glossary — one canonical entry per flag shared by two or more /sp:dev-* commands — and the --next chain contract that expands the --next entry. Moved verbatim from dev-operations.md; the operation catalog stays there."
see_also:
  - spur-dev
  - dev-operations
---

# Flag Glossary

The shared-flag glossary and the `--next` chain contract, extracted from `dev-operations.md` (task
0408). Every flag shared by two or more `/sp:dev-*` commands has exactly one canonical entry here;
the chain contract is the prose expansion of the `--next` entry. The operation catalog (map, backing
patterns, skill-backed, inline) remains in `dev-operations.md`.

## Flag glossary

Every flag shared by two or more commands has exactly one entry here. This is the single place a
shared flag's meaning is stated; command argument-hints and table rows cite it and must not
re-define it. The shared-flag set is derived mechanically from the 28 command argument-hints (a flag
counts as shared when it appears in two or more); flags appearing on a single command stay documented
in that command's body and are not listed here.

**Reference form (mechanically detectable).** A command file points at a glossary entry with a
markdown link whose link target is the entry's anchor — `[`--next`](#flag-next)`. The anchor is
always `#flag-<name>` where `<name>` is the flag minus its leading `--` (so `--keep-going` →
`#flag-keep-going`). The test gate (`command-flag-parity.test.ts`, task 0403) finds these references
with the regex ``\[`--<flag>`\]\(#flag-`` over each command file — **a shared flag declared without
this reference fails the build.** Prose-only citations (the flag name mentioned in a sentence but not
in the link form) do not count; the reference must be the link.

**Availability rule.** Two flags are only declared where the underlying capability already exists:
`--json` where the command already produces a structured result a script could consume; `--auto`
where the command already has at least one HITL gate. The rule forces a declaration only where the
capability exists — a command that would benefit from `--json` but produces only prose is recorded
as a follow-up, not quietly left inconsistent.

### `--agent <inline|auto|name>` — name who does the model-bearing work

**Anchor:** `#flag-agent`.

**SSOT:** the full contract — the one rule, value semantics, executor precedence chain,
`implementAgent` override, objective triggers, and surface-derivation logic — lives in
[cross-cutting.md](cross-cutting.md#inline-default-execution-surface).
The value table below is the C3a cross-file parity surface (kept in lockstep with the SSOT by
`validate-flag-contracts.ts`), not an independent restatement.

| Value                           | Who does the work                                                           | Derived surface                                                             |
| ------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| `(omitted)`                     | The agent running this session                                              | Host session — host-controlled; eligible model stages may use a native subagent (0508). Identical to explicit `inline` (0687 R1: inline is the default selector) |
| `inline`                        | The agent running this session                                              | Host session — eligible model stages may use a native subagent (0508, generalized to explicit inline by 0687 R2); on a headless dispatch surface AgentService substitutes tier resolution with a warning (0687 R3), never a rejection |
| `auto`                          | The role the caller declared — this command's `role:` frontmatter or the workflow step's `role:` (Layer 1, `plugins/sp/references/roles.md`); with nothing declared, `agent.default`'s role (0542) | Subprocess                                                                  |
| `<name>`                        | That coding agent or configured executor                                    | Inline when it is the current session's agent; subprocess otherwise         |

**Declared-role threading (0538 R1).** Every command file declares `role: <scribe|coder|reviewer|planner>`
in its YAML frontmatter, taken from its row in `plugins/sp/references/roles.md`; the dispatcher
threads it into `--agent` so subprocess dispatch routes by the declared role. An explicit `--agent`
value always wins; the declared role is the default when the flag is `auto`/omitted at a subprocess
boundary. The same declaration exists on workflow `agent.run` steps (`role:` beside `agent:`) and is
threaded by `AgentRunActionRunner`; a pin still beats role routing permanently (0536 R2).

The previous `--inline` and `--subprocess` flags (feature H82, task 0413) are collapsed into this
selector: `--inline` → `--agent inline`, `--subprocess` → `--agent auto`. Those two flags are no
longer part of the command surface; their anchors (`#flag-inline`, `#flag-subprocess`) are retained
as stubs below so external links do not dangle. **Restored equivalence (0687 R1/R2):** the
`--inline` → `--agent inline` leg of the collapse means "equivalent to omitting the flag" again —
inline is the default selector and omitted/explicit `inline` resolve identically on every surface
(see [cross-cutting.md](cross-cutting.md#inline-default-execution-surface)). Operator-layer vocabulary (task 0405): `agent` names
the concrete coding-agent tool; `executor` remains the domain-layer role and is not a command flag.
`inline` and `auto` are reserved values — config validation rejects an executor claiming either.

#### `--inline` (removed — collapsed into `--agent`)

**Anchor:** `#flag-inline` (stub retained to avoid dangling external links).

Removed in feature H82 (task 0413). `--inline` is now `--agent inline`. See
[`--agent`](#flag-agent) above and
[cross-cutting.md](cross-cutting.md#inline-default-execution-surface) for the full contract.

#### `--subprocess` (removed — collapsed into `--agent`)

**Anchor:** `#flag-subprocess` (stub retained to avoid dangling external links).

Removed in feature H82 (task 0413). `--subprocess` is now `--agent auto`. See
[`--agent`](#flag-agent) above and
[cross-cutting.md](cross-cutting.md#inline-default-execution-surface) for the full contract.

### `--next` — chain-to-completion with propagation

**Anchor:** `#flag-next`.

On success, hand the task back to `sp:next-router`, which resolves the next dispatch and re-invokes
with `--next` still set, until the work is done or a gate stops it. The flag is a **chain
to completion**, not a single step, a mode selector, or a status transition. `/sp:dev-next` (the
command) runs the next step **once**; `--next` (the flag) makes any command it is passed to **keep
going**. Neither is renamed.

**Redefinition (breaking).** Before this entry (feature H8, task 0399, 2026-07-31) `--next` carried
four incompatible meanings across seven commands: chain-ish (`dev-verify`, `dev-verifyall`), a
mode selector (`dev-run` → implement-only), a deprecated no-op (`dev-review`), and undeclared
declarations never explained (`dev-refine`, `dev-refineall`, `dev-brainstorm`). Task 0401 reconciled
all seven against this single definition. Existing `dev-run --next` invocations selecting
implement-only mode are the only genuinely breaking case; the replacement is `--mode implement`.

### `--json` — emit machine-readable output

**Anchor:** `#flag-json`.

Emit the command's result as structured JSON a script can consume, instead of the human-readable
default. Only declared where the command already produces a structured result; declaring it never
implies building a new output shape.

### `--auto` — skip objective HITL confirmations

**Anchor:** `#flag-auto`.

Skip objective HITL confirmations inside this command (feature-check, batch-create, the approve
gate). Taste gates and irreversible HITL gates (e.g. `--merge`) still pause even under `--auto`.
Only declared where the command already has at least one HITL gate the flag can skip.

### `--keep-going` — batch failure policy: skip dependents, continue independents

**Anchor:** `#flag-keep-going`.

Batch operation only (`dev-refineall`, `dev-runall`). When a task in the batch
fails, skip its in-batch dependents and continue the independent ones, instead of the default
halt-on-first-failure. Never silently retried; the failure is still reported.

### `--continue` — resume an interrupted batch from checkpoint

**Anchor:** `#flag-continue`.

Resume a batch (`dev-runall`) or task (`dev-run`) that was interrupted mid-run, picking up from the
recorded checkpoint rather than restarting. Orthogonal to `--next` (lifecycle chaining) and
`--keep-going` (failure policy): the three axes address different problems and `routing-table.md`
offers `--continue` and `--next` as competing options only when the batch was interrupted mid-run.

### `--wrap` — run the wrap hop after the main step

**Anchor:** `#flag-wrap`.

After the main step completes, run the wrap hop (learnings, metrics, doc-sync). On `dev-runall`
with `--next`, wrap runs **once for the batch** after every task reaches terminal status, mirroring
the batch-once shippable gate `dev-verifyall` uses. Without `--next`, `--wrap` is wrap-without-
chaining — the single task or batch wraps without advancing the lifecycle.

### `--force` — bypass a named guard

**Anchor:** `#flag-force`.

Bypass a specific named guard that would otherwise stop the command (e.g. a shippable check on
`dev-verify`/`dev-verifyall`). Named, not global: the command documentation states which guard is
forced. Never bypasses lifecycle status transitions or irreversible HITL gates.

### `--feature <id>` — scope the operation to a feature

**Anchor:** `#flag-feature`.

Scope the operation to all tasks under a feature id (`^[A-Z][1-9]*$`). On feature-advancing
commands (`dev-wrapall`) it also advances the feature through legal lifecycle edges with guards
honored.

### `--check <cmd>` — validation command for iterate-and-check loops

**Anchor:** `#flag-check`.

Verification command a command iterates against (`dev-simplify`, `dev-refactor`). The command
establishes a baseline with it before the first change and re-runs it after each change.

### `--focus <dims>` — constrain the operation to specific dimensions

**Anchor:** `#flag-focus`.

Constrain the operation to a named subset of dimensions — review dimensions on `dev-review`/
`dev-verify`/`dev-verifyall` (`all|stack|dependencies|data|flows|api|security|quality|performance`),
a refactor lens set on `dev-refactor` (`api|architect|tests|ui|auto`), a refine focus mode on
`dev-refine`/`dev-refineall` (`all|requirements|background|constraints|acceptance|quick` —
[dev-operations.md](dev-operations.md) § refine), or a reconstruction lens on `dev-reverse`.
Narrowing reduces token cost; omitting runs
all dimensions.

### `--scope <path>` — limit the operation to a path

**Anchor:** `#flag-scope`.

Limit the operation to a file or directory path (`dev-arch`, `dev-debug`, `dev-fixall`,
`dev-gitmsg`, `dev-gtd`, `dev-refactor`, `dev-simplify`) to bound the working set.

### `--all` — widen the operation to everything in its domain

**Anchor:** `#flag-all`.

Drop the default narrowing and operate on the full set (`dev-gitmsg`, `dev-refresh`). On
`dev-gitmsg` the default set is the git index, and `--all` widens it to every change in the tree —
unstaged **and untracked**; on `dev-refresh` the default is one feature or task, and `--all` sweeps
every feature. An explicit `--scope <path>` still bounds the result, and always wins over
auto-discovery.

### `--dry-run` — print the plan without executing

**Anchor:** `#flag-dry-run`.

Resolve and print what the command would do, without dispatching or mutating state. The plan output
is the contract; divergence between `--dry-run` and the real run is a bug.

### `--tasks <selector>` — explicit task selector for a batch

**Anchor:** `#flag-tasks`.

Batch operation only (`dev-parallel`, `dev-refineall`, `dev-runall`, `dev-verifyall`). An explicit selector — WBS
list, status pseudo-list (`todo`, `wip`), `feature:<id>`, or `ready` — resolving to the set the
batch runs over. Required on `dev-parallel`, `dev-runall`, and `dev-verifyall`, where `--feature` is an optional
restrictor. On `dev-refineall` it is instead one of a required pair — supply exactly one of
`--feature` or `--tasks`.

### `--mode <kind>` — select an execution mode

**Anchor:** `#flag-mode`.

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`, 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`). 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
  `todo` ready for refine. Optional feature id scopes it.
- `dev-find-next` `[<feature-id>]` — after confirm, dispatches the planning half on the ranked
  winner (`/sp:dev-plan` to decompose, then `/sp:dev-refineall --depth ready` to freeze
  implement-ready). Creates no task itself. Interactive by default; with `--auto`, auto-accepts the
  offered target (rank-1 or the explicit id) and forwards `--auto` to the children. Optional feature
  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.

### `--since <ref>` — lower bound on a range

**Anchor:** `#flag-since`.

Lower bound on a range: a git ref on `dev-changelog`, or an ISO date on `dev-find-issue` and
`dev-wrapall` (filters done
tasks by `updated_at >= date`).

### `--fix <policy>` — remediation policy

**Anchor:** `#flag-fix`.

Remediation policy on verify-family commands (`dev-verify`, `dev-verifyall`) and the refactor
coordinator (`dev-refactor`):
`none|blockers-first|all`. `none` reports findings without fixing; `blockers-first` fixes only P1/P2;
`all` fixes everything found. Deprecated on `dev-review` (routes to `dev-verify --fix`).

### `--until <ref>` — upper bound on a range

**Anchor:** `#flag-until`.

Upper bound on a range: a git ref on `dev-changelog` (defaults to `HEAD`), or an ISO date on
`dev-find-issue` (defaults to now).

### `--source <source>` — agent source to scope the operation

**Anchor:** `#flag-source`.

_(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

**Anchor:** `#flag-status`.

Filter the operation by task status (`dev-wrapall` default `done`; `dev-refineall` to target a
specific status slice).

### `--skip-shippable` — skip the shippable check

**Anchor:** `#flag-skip-shippable`.

Skip the shippable guard on verify-family commands (`dev-verify`, `dev-verifyall`). Used when
verifying a task whose artifact is intentionally not yet shippable (e.g. a doc-only task).

### `--skip-design` — omit the design package

**Anchor:** `#flag-skip-design`.

Omit the design package (system-design satellite + task `### Design`) on planning commands
(`dev-plan`, `dev-idea`). The task is created without the design section; refine supplies it later.

### `--from-file <path>` — read the idea from a file (dev-idea)

**Anchor:** `#flag-from-file`.

`dev-idea` reads the idea text from `<path>` instead of the positional argument. Mutually
exclusive with `"<idea>"` — exactly one must be present. The file's contents become the verbatim
idea text, persisted unmodified to `.spur/run/<run-id>-idea-input.md` (0887 R1) and treated as
the authoritative ask by every model-bearing stage prompt. Useful for long or multiline asks
that are awkward to quote (0887 R7).

### `--output <path>` — write the result to a path

**Anchor:** `#flag-output`.

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

**Anchor:** `#flag-merge`.

Trigger branch cleanup after wrap (`dev-wrap`, `dev-wrapall`). Irreversible HITL gate — always
pauses, even under `--auto`.

### `--max-retry <n>` — bound the retry loop

**Anchor:** `#flag-max-retry`.

Bound the retry loop on fix-family commands (`dev-dogfood`, `dev-fixall`, `dev-gtd`). After `n` consecutive
failed fix attempts, stop and ask the operator rather than looping indefinitely.

### `--full` — rewrite a `--next` run as full pipeline

**Anchor:** `#flag-full`.

**Context-specific — two unrelated meanings; do not collapse them.**

- `dev-next`: rewrite a `dev-run … --next` primary dispatch into `dev-run <wbs> --mode full`
  (without `--next`). No effect on non-run routes (warning W-FULL).
- `dev-dogfood`: full report verbosity — emit all report sections rather than the summary set.

The shared spelling is historical. A rename would be the cleaner fix; until then each command's
Argument Flags row states its own meaning and this entry records that they differ.

### `--description <text>` — supply a description

**Anchor:** `#flag-description`.

Supply a description (`dev-refine` / `dev-refineall` focus description). Used when the operator
wants to inject a specific framing rather than derive it from context. `dev-idea` takes its idea as
a positional argument, not via this flag.

### `--depth <…>` — depth control (context-specific values)

**Anchor:** `#flag-depth`.

**Context-specific — two unrelated value sets; do not collapse them.** Declared on
`dev-brainstorm`, `dev-refine`, and `dev-refineall`.

**`dev-brainstorm`:** `--depth <basic|detailed|comprehensive>` — breadth vs depth of the ideation
tree (default `detailed`). Unrelated to task-section readiness.

**`dev-refine` / `dev-refineall`:** `--depth <standard|ready>` — how deep refine must take target
sections (Background, Requirements, Acceptance Criteria, Design, Plan) before SKIP/success.
Orthogonal to `--focus` (which _narrows_ domains) and to `--mode` on other commands.

| Value (refine family)             | Bar                                                                                                                                                                                | `--auto` SKIP behavior                                                                             |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| `standard` (default when omitted) | L3 structural completeness (not empty/placeholder; check-clean for target sections)                                                                                                | **SKIP** when no L3 findings on target sections                                                    |
| `ready`                           | **Implement-ready** freeze: another agent can implement without inventing design (frozen names/APIs or explicit "no new API", anti-patterns, file targets, handoffs, out-of-scope) | **Do not SKIP** on L3-clean alone — audit existing claims, run the ready checklist, rewrite sections until the bar is met, then promote `backlog → todo` |

Default for refine stays `standard` so ordinary `refineall --auto` remains cheap. Use `ready` for
multi-package / multi-agent handoffs, flaky-pipeline features where a wrong implement is costly, and
evaluating/correcting an existing task (review-triage filing, stale backlog) whose claims may no
longer hold.
Full checklist: [dev-operations.md](dev-operations.md) § refine (depth ready).

### `--bdd` — use BDD scenarios as the verification lens

**Anchor:** `#flag-bdd`.

Use the task's Gherkin scenarios as the verification lens on verify-family commands (`dev-verify`,
`dev-verifyall`).

### `--approve-taste` — pre-clear all taste gates this run

**Anchor:** `#flag-approve-taste`.

Planning commands (`dev-idea`, `dev-plan`): with `--auto`, skip all remaining taste pauses this
run (idea-eval + design-approval). Sets `idea_approved=true` and `design_approved=true`. One CLI
flag sets both.

### `--worktree [<name>]` — run the batch in an isolated git worktree (create or reuse)

**Anchor:** `#flag-worktree`.

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
  the worktree branch is fast-forward-merged onto its base ref, then the worktree is removed and the
  branch deleted; on any failure, halt, or non-fast-forward base, the worktree is **retained intact**
  — never auto-deleted, never auto-merged.
- **Reuse mode** — `--worktree <name>` / `--worktree=<name>`. Attach the batch to a worktree that
  already exists. `<name>` resolves against `git worktree list --porcelain` (exact path → basename →
  checked-out branch); exactly one match must survive or the batch aborts **before any task work**
  (see [execution-batch.md § Name resolution](execution-batch.md#name-resolution---worktree-name)).
  Reuse mode **never creates a worktree** — an unresolvable name is an error, not a create. The batch
  adopts the worktree's checked-out branch (a detached HEAD aborts), adopts or synthesizes the
  `.spur/run/` state marker, and runs. On a fully successful batch the branch is fast-forward-merged
  onto its base ref **but the worktree and branch are retained**; on failure/halt/non-FF the tree is
  retained, same as create mode.

**Ownership rule (one statement, both modes): the flag removes only what it created.** In create
mode the flag owns the tree, so cleanup is its job; in reuse mode the operator owns it, so the flag
merges but never removes. This keeps the continue-the-work loop stable — after a green reuse batch
`baseRef == $BRANCH`, so the same worktree keeps fast-forwarding on the next invocation.

**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 — 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
[worktree-patterns.md](../../branch-workflow/references/worktree-patterns.md).

---

## `--next` chain contract

The canonical definition lives in the glossary above; this section states the chain's stop
conditions, hop bound, and reporting contract that every declaring command and the router inherit.
These are derived from the per-row `Stop / notes` column in
[routing-table.md](../../next-router/references/routing-table.md), not invented here.

**Chain owner.** `sp:next-router` is the single owner of chain progression. Given a task and
`--next`, it resolves the next dispatch, invokes it with `--next` propagated, and repeats. The chain
does **not** live in the command files — per-command "what comes after me" logic would duplicate the
routing table seven or more times. Commands reference the glossary entry and the router; they do not
describe successors.

**Stop conditions.** A chain running under `--next` halts, cleanly, when any of these is true. Each
is named so the operator can tell **which step halted the chain and why**:

| Halt cause                                                         | Who reports it                               | Report shape                                                                                   |
| ------------------------------------------------------------------ | -------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| A failing gate (lint/type/test/rule)                               | The step that hit it                         | "chain halted at `<step>` — `<gate>` failed: `<one-line cause>`"                               |
| A non-PASS verdict (PARTIAL/FAIL)                                  | The verify step                              | "chain halted at `dev-verify <wbs>` — verdict `<VERDICT>`; see `.spur/run/<wbs>-verdict.json`" |
| A HITL pause (taste gate, irreversible gate, multi-candidate fork) | The step that paused                         | "chain halted at `<step>` — HITL pause (`<which>`); resume after operator input"               |
| Unmet dependencies                                                 | `dev-refine`/`dev-run` precheck or router A2 | "chain halted at `<step>` — unmet deps: `<WBS list>`"                                          |
| Terminal status (`done`, `cancelled`)                              | The router                                   | "chain complete — task `<wbs>` is `<status>`" (distinct from a halt)                           |

A chain that stops at a gate is a **normal outcome, not an error**: it reports where and why and
exits cleanly. It is distinct from a chain that stops because the task is complete — the report
wording makes the two unambiguous (one says "halted at", the other says "complete").

**Hop bound.** A single `--next` chain performs at most **8 primary hops** (router invocations). A
routing cycle, or a task whose status never converges on terminal, would otherwise loop forever.
When the bound is hit the chain stops and reports: "chain halted — hop bound (8) reached at
`<step>` without reaching terminal status; this indicates a routing cycle, not completion." The
bound is sized for the longest legitimate chain (refine → run → verify → wrap is four hops; the
extra four absorb probe short-circuits like `dev-fixall`/`dev-unit`) and is a rule the router agent
follows and reports against, not a counter in code (the router is a prompt skill, not executable).

**Flag vs command disambiguation.** `/sp:dev-next` runs the next step **once** and stops;
`--next` makes any command it is passed to **keep going** until the work is done or a gate stops
it. The two compose: `/sp:dev-next <wbs> --next` is valid but redundant (the flag makes the single
dispatch keep going, which is what re-running `/sp:dev-next` without `--next` would do one hop at
a time). Neither is renamed.

---