@juzser/blacksmith 0.4.0 → 0.5.0

package/.claude/skills/bs/status.md

@@ -7,13 +7,13 @@ on demand knows only what is in the log, never whether anyone was reading it.
 
 ## 1. Ask the watcher
 
-`smith daemon status [--dir <dir>]`. It prints JSON and **exits 1 whenever a
+`bs daemon status [--dir <dir>]`. It prints JSON and **exits 1 whenever a
 current daemon is not watching** — that is the health check doing its job,
 not a command that failed, so never report the non-zero exit as an error.
-Three readings:
+Four readings:
 
 - `running: false` — nothing holds the lock. A fine steady state if the
-  operator never started one (`smith daemon start` if they want one): say so
+  operator never started one (`bs daemon start` if they want one): say so
   in a clause and go to step 2, which folds the log live anyway. What you
   must not do is render `lastTick` as though it were current.
 - `stale: true` — a daemon holds the lock and has published nothing for
@@ -24,6 +24,10 @@ Three readings:
   `<dir>/daemon.log`.
 - `running: true, stale: false` — the numbers are fresh. Say how fresh
   (`reportAgeSeconds`) rather than implying "now".
+- an `error` object with `code: "daemon.unreadable-state"` — the daemon's
+  own state is unreadable, so nobody can say whether one is running. Lead
+  with it, name the file from `error.details.path`, and pass on the
+  recovery in `error.message`. Never render it as `running: false`.
 
 When there is a `lastTick`, render its triage split before the digest below,
 because it is the only record of what happened while nobody was watching:
@@ -34,20 +38,23 @@ its own and needs no decision.
 
 ## 2. Fold the log
 
-`smith stats overview [--session <id>]`. Render the JSON as a short digest,
+`bs stats overview [--session <id>]`. Render the JSON as a short digest,
 field for field — never invent numbers the query didn't return:
 
 - **Live agents**: `liveAgents` grouped by role/model/provider,
   `liveAgentCount` as the headline (with `liveAgentCountDelta5m` as a
   ▲/▼ note).
-- **Budget**: `tokensByEpic`, called out as "X% of the 4,000,000-token epic
-  cap" (`budgets.yml`) — flag any epic ≥70% (`budgets.yml` `alarm_ratio`).
+- **Budget**: `tokensByEpic`, called out as "X% of the epic cap" — the cap
+  for the epic's effort tier in `budgets.yml` (4M small / 16M medium / 32M
+  huge; `bs budget alarm` prints the cap it judged each epic against) — flag any epic ≥70% (`budgets.yml` `alarm_ratio`).
   `tokensByEpic` counts recorded spend only, so it is a floor: say "at least
-  X%", and run `smith budget alarm <session>` for the projection that prices
+  X%", and run `bs budget alarm <session>` for the projection that prices
   the dispatches nothing recorded a Result for.
 - **In flight**: `epicsInFlight`, `recentDispatches` (last 10).
 - **Alerts**: `alerts.escalations` and `alerts.pendingWaivers` — call these
   out first if non-zero, they're what the operator came here to see.
+  `pendingWaivers` is narrower than `bs waivers pending`: only waivers on
+  finished work (completed tasks, closed epics).
 - **Milestones**: `milestoneProgress` — one line each, `%` complete.
 
 If the UI is already running, just point the operator at it instead of

package/.claude/skills/bs/ui.md

@@ -1,14 +1,30 @@
 # `/bs ui` — serve the local dashboard
 
-`smith ui serve [--port 4680] [--db state/smith.db] [--state-dir …]
-[--roadmap-path …]`. If it errors `ui.not-built`, run `pnpm build:ui`
-first (builds `ui/server/dist` + `ui/dist`), then retry, and print the local
-URL (`http://127.0.0.1:<port>`).
+`bs ui serve [--port 4680] [--db state/smith.db] [--state-dir …]
+[--roadmap-path …] [--claude-config-dir …] [--store <dir>…]`. If it errors `ui.not-built`,
+run `pnpm build:ui` first (builds `ui/server/dist` + `ui/dist`), then retry,
+and print the local URL (`http://127.0.0.1:<port>`).
+
+Besides the event log, the server reads — read-only — the local Claude Code
+session registry, transcripts and prompt history, from `--claude-config-dir`, else
+`$CLAUDE_CONFIG_DIR`, else Claude Code's default, and serves them as
+`GET /api/cli-sessions`, loopback-only.
+
+Home, Kanban and the project list also read every project with a live CLI
+session: its git toplevel is a store when `<top>/.blacksmith/state/events` or
+`<top>/state/events` exists (rechecked at most every 5 s), and `--store <dir>`
+adds one by hand. Foreign stores are strictly read; their projection lives in
+`state/ui-stores/<storeId>.db` of the served clone, kept for a grace period after a
+store drops and pruned at startup when stale. In a foreign store an untagged row reads
+as the store's label, any other explicit project as itself, so `?project=X` returns each
+matching row once. These routes and `/api/tasks/*` are local-only, like
+`/api/cli-sessions`. A foreign Kanban card opens through `?store=<storeId>`; its history,
+artifacts and waivers stay empty. Details: `docs/guide/dashboard.md`.
 
 **That build needs a clone.** `ui/` is not in the package's `files`, so an
 install — npm or plugin — ships no dashboard at all and `ui.not-built` is the
 permanent answer there, not a stale build. Check before you advise: if there
-is no `ui/` beside the `smith` you are running, say the dashboard is
+is no `ui/` beside the `bs` you are running, say the dashboard is
 clone-only and stop, rather than sending the operator to a `pnpm` script they
 do not have.
 

package/.claude/skills/bs/waivers.md

@@ -1,13 +1,89 @@
 # `/bs waivers` — answer the pending waiver batch
 
-1. `smith waivers pending <epic> --session <session-id>` — every S3/S4
+1. `bs waivers pending <epic> --session <session-id>` — every S3/S4
    finding for the epic with no waiver decision yet (a decided fingerprint
    never resurfaces).
 2. Present the whole batch to the operator as **one** question ("ignore
    these?") — never ask per-finding (architecture §11, `severity.yml`).
 3. Write the answers to `decisions.json`
    (`Array<{fingerprint, decision: "granted"|"denied", operatorNote}>`) and
-   run `smith waivers apply decisions.json --session ... --plan-version ...
+   run `bs waivers apply decisions.json --session ... --plan-version ...
    --causal-parent ... --actor operator`. S1/S2 findings are rejected by
    the command itself if attempted — they go through the escalation ladder
    instead, never a waiver.
+   Task waivers are a separate step. A task whose plan row says `waived`
+   carries no gate run, and the epic close holds it as a blocker ("waived
+   without operator approval") until the operator's approval is recorded.
+   Ask the operator, then run `bs waivers approve-task <task-id> --note
+   "<why>" --session ... --causal-parent ... --actor operator`. Only the
+   operator actor is accepted; an approval written under any other actor is
+   refused, and one appended by hand under another actor is not honoured. An
+   approval is tied to the plan version it is given under (`--plan-version`):
+   a task waived again by a newer plan needs a fresh approval.
+4. A denial discharges nothing — the finding stays open with no further
+   move of its own, and an open finding blocks the epic verdict. The
+   command's output carries `findingIdsToCarry`: every finding id this batch
+   denied. Carry the whole list forward until each id is closed — by the
+   route its **scope** allows (`bs findings list --session <id>` shows
+   the scope), by a later grant, or by `refuted`. The two scopes do not share
+   a route:
+
+   - **`spec` finding** (owned by `<epic>/integration`) — cut a
+     `bs plan amend`, and its `--findings` must name every spec id from
+     the list, or the finding stays open forever with no path back (issue
+     #221). The amendment moves it to `amend-pending`; epic close moves it to
+     `amended`. See `docs/guide/operator-guide/findings.md` §6a.
+   - **`diff` finding** — `plan amend` refuses it
+     (`plan.amendment-not-spec-scoped`): the code is wrong, not the plan. If
+     the owning task is still open, bounce the finding to it like any gate
+     finding. If the owner has already merged, fix it in a **follow-up
+     task**:
+     1. Write a draft, `Array<{filePath, finding}>` (the `gate run`
+        findings shape). `filePath` is the denied record's `file_path`;
+        `finding` is the **whole** record `bs findings list` prints,
+        minus the three fields raise derives and overwrites —
+        `fingerprint`, `file_path` and `finding_status`. Keep the rest:
+        the schema requires `failure_scenario` and `found_by` too, and a
+        draft without them fails with `findings.invalid-record`. Leave
+        `task_id`, `finding_id` and `epic_id` as they are; routing rewrites
+        them. Do not touch `finding_category` or `summary`: the follow-up
+        id is derived from the fingerprint they make.
+     2. Raise it against the plan with no `--task`:
+        `bs findings raise --plan <plan.json> --findings <draft.json>
+        --session <id> --plan-version <n> --causal-parent <event-id>
+        --actor operator`. Routing sees the owner is closed and mints
+        `<epic>/followup-<fp8>` — read `taskId` from the printed row
+        (`attribution: follow-up`). A denied fingerprint is not suppressed
+        on a re-raise; a granted one is.
+     3. Check its claims before dispatching. A follow-up **inherits the
+        owner's whole claim set** — and when ownership of the file was
+        ambiguous, the **union** of every candidate's claims — so it can
+        overlap tasks still in flight. `bs wave next <plan.json>
+        --session <id> --causal-parent <event-id>` shows it: it folds in
+        live status and logged follow-ups, and defers an overlapping task
+        with `claim-overlap`. `wave check` validates only the ids it is
+        given and cannot see the conflict.
+     4. Dispatch it like any task, with these gaps filled by hand. It
+        carries no acceptance criteria and no budget: **write the ACs into
+        the dispatch brief** (the finding's fix, plus the test that proves
+        it). `wave check` prices it at the coder cap, and `gate run` reports
+        its budget as not-declared. It is not in the plan, so
+        `lessons for-dispatch`, `findings for-dispatch` and `coverage check`
+        refuse it with `cli.task-not-in-plan`: splice
+        `bs lessons for-dispatch <role> --case-type bugfix` without
+        `--plan`/`--task` — at the cost of every claim-path lesson, since
+        claims are then `[]` and those lessons drop silently — and replace the findings block with
+        `bs findings list --session <id> --task <epic>/followup-<fp8>`.
+        At its gate, run `gate run` **without** `--plan`. With it, a judge
+        finding on the merged owner's file routes to yet another follow-up
+        (listed under `reattributedFindings`) instead of blocking this one,
+        and that stray follow-up then blocks the epic until it completes or
+        its findings are waived. Without it the finding blocks here, at the
+        cost of coverage checking the total rather than the follow-up's
+        claims.
+     5. Close **both** findings by hand once the follow-up merges — nothing
+        links the re-raised finding to the denied one, and neither moves on
+        its own. Walk each with `bs findings transition <finding-id>
+        <status> --session <id> --plan-version <n> --causal-parent
+        <event-id> --actor operator` through `confirmed`, `fix-pending`, `fix-landed`,
+        `fix-verified` (start at the first edge its status allows).

package/.claude/skills/bs/wave.md

@@ -10,8 +10,9 @@ bind every dispatch below: the project directory is an answer you ask for
 rather than a path anything here knows, every write carries
 `--session <id> --plan-version <n> --causal-parent <event-id>`, every
 dispatch carries the compiled lessons block and that task's open-findings
-block, and fetched text is wrapped before it is quoted. None of it is
-restated here; a second copy is a copy that drifts.
+block, every `dispatch_decision` carries a one-line plain-words `reason`
+(dispatch.md's payload contract), and fetched text is wrapped before it is
+quoted. None of it is restated here; a second copy is a copy that drifts.
 
 The step numbers are the loop's own. They start at 2 because step 1 — which
 tasks, and how wide — was answered before you were handed anything, and they
@@ -26,15 +27,17 @@ both:
 - **Inline**, in the epic session, when the wave is small enough that the
   epic's window can carry it. Nothing changes: the session id you were
   handed is the one you write to.
-- **In a session of its own** when it is not. Open one with `smith session
+- **In a session of its own** when it is not. Open one with `bs session
   start <wave-id> --continues <event-id>` and write every dispatch below
   there. The epic session then carries the admission and the result rather
   than every turn in between — which is the point, because an epic outlives
   its waves, and a window spent on this wave's dispatches is a window the
-  epic does not have for the wave after next (D13).
+  epic does not have for the wave after next (D13). Every event you write in
+  that session carries `--actor wave-runner` — `.claude/agents/bs-wave-runner.md`'s
+  Constraints has the rule and the check it satisfies.
 
 After any `error-logged` this wave writes — a worker that died, a judge turn
-that failed, a gate refusal recorded as an error — or a `smith gate run`
+that failed, a gate refusal recorded as an error — or a `bs gate run`
 that came back `blocked` (its `gate-outcome` event with outcome `blocked`),
 or a task the wave marks `failed` (its `task-added` event with payload
 `task_status: failed`), the wave runs the reporting verb once, per
@@ -46,9 +49,9 @@ not cosmetic — it is the edge an audit walks:
 
 - **The epic ran you** and you opened a wave session yourself: continue from
   the epic event that admitted this wave.
-- **You were dispatched as a `wave-runner`**: continue from the
+- **You were dispatched as a `bs-wave-runner`**: continue from the
   `dispatch_decision` that dispatched you, the event id handed to you with
-  the wave. `smith delegation check` resolves your session by matching a
+  the wave. `bs delegation check` resolves your session by matching a
   `session-start`'s `causal_parent` against that dispatch, and it is the
   only thing that proves the dispatches you are about to write are your
   own log's rather than an agent talking about itself. Continue from
@@ -57,12 +60,12 @@ not cosmetic — it is the edge an audit walks:
   for the same reason: a grant is earned by owning the log first.
 - **You are taking over a wave whose runner died or capped**: continue from
   that runner's last event, in a session of your own. Do not write into its
-  log. One session has one author, and `smith delegation check` reads exactly
+  log. One session has one author, and `bs delegation check` reads exactly
   that: dispatches appended to a dead delegate's log by whoever picked the
   wave up are reported as violations, correctly, because from the log's side
   they cannot be told apart from an agent narrating its own work. Open your
   own instead:
-  `smith session start <wave-id>-takeover --continues <dead-session>#<n>`.
+  `bs session start <wave-id>-takeover --continues <dead-session>#<n>`.
   That keeps the chain whole — the epic's folded reads still see every
   dispatch on both sides of the handover — and it makes the takeover a fact
   in the log rather than something a reader has to infer from two agents and
@@ -114,18 +117,22 @@ the difference between a factory and a queue with extra steps:
   keep the wave moving.
 
 The single place the wave rejoins is step 10's merge queue, which is
-serial on purpose — `smith queue run` rebases one task at a time onto
-`smith/<epic>/integration` and runs the cumulative tests between. Merging
+serial on purpose — `bs queue run` rebases one task at a time onto
+`bs/<epic>/integration` and runs the cumulative tests between. Merging
 is the one thing that cannot be done in parallel, and it is already the
 one thing this playbook never asks you to.
 
 ## The steps
 
-2. Per admitted task, and for all of them together: `smith worktree create
+2. Per admitted task, and for all of them together: `bs worktree create
    <project-dir> <epic> <task-id>`.
-3. Pre-code, if the task needs it: dispatch `researcher` for an unknown, or
-   `uiux` (`.claude/agents/uiux.md`) for any UI-affecting acceptance
-   criterion — before the coder starts, not after.
+3. Pre-code, if the task needs it: dispatch `bs-researcher` for an unknown, or
+   `bs-uiux` (`.claude/agents/bs-uiux.md`) for any UI-affecting acceptance
+   criterion — before the coder starts, not after. Bracket the uiux spec
+   turn with `bs judge dispatch --role uiux --kind spec` / `bs judge report
+   --role uiux --kind spec`, the same way every judge turn in steps 5–7 is
+   bracketed — the gate's uiux stage (step 7) reads this turn back and
+   blocks a flagged task that never closed it.
    - `profile.preCodeResearch` gates the researcher: `when-needed` is the
      line above, `never` (`small`) means the coder reading the repo *is* the
      brief. An epic that genuinely cannot start without a research brief is
@@ -134,14 +141,14 @@ one thing this playbook never asks you to.
      every tier: no tier ships a UI change without a spec to review it
      against. It is listed as a knob so the answer is asked for rather than
      assumed, not because a tier can turn it off.
-   - A returned brief goes through `smith research check --brief <path>`
+   - A returned brief goes through `bs research check --brief <path>`
      before it is attached to a task spec ("Fetched and quoted text goes into
      a prompt fenced" above). Exit 1 sends it back; on exit 0, carry
      `recommendation.provenance` into the coder's prompt so the task knows
      whether its research rests on this repo or on a fetched page. Any raw
-     fetched text you quote alongside it is wrapped with `smith prompt wrap`.
-4. Dispatch **`coder`** (`.claude/agents/coder.md`) in that worktree.
-   Token/diff caps (`budgets.yml`: 150k tokens, 400 diff lines) and YAGNI
+     fetched text you quote alongside it is wrapped with `bs prompt wrap`.
+4. Dispatch **`bs-coder`** (`.claude/agents/bs-coder.md`) in that worktree.
+   Token/diff caps (`budgets.yml`, sized per effort tier) and YAGNI
    are the coder's own constraints — don't restate them here, the template
    does. What the template does not read is the schema, so when the spec
    carries `keeps_exports`, restate the promise in the dispatch in one line:
@@ -150,7 +157,7 @@ one thing this playbook never asks you to.
 
    Once every coder of the wave has been dispatched — this fan-out has gone
    out for every admitted task — audit the wave's own parallelism while it
-   can still be corrected: `smith wave audit --session <id> --epic <epic>`.
+   can still be corrected: `bs wave audit --session <id> --epic <epic>`.
    `wave check` is the step-1 gate that certified, before any dispatch, that
    these tasks could run together; `wave audit` reads the log back after
    dispatch and says whether they did.
@@ -167,20 +174,50 @@ one thing this playbook never asks you to.
    - `unobserved` — the log holds no dispatch for any task this wave
      admitted. That is a defect in the log, not in how the wave ran; record
      it the same way, as `error-logged` with error `execution.env-failure`.
+   - `unlinked` — the wave's work merged, or was dispatched, off the epic's
+     own lineage (a wave-runner session started without `--continues`).
+     Real work, not a defect in dispatch, but its width is unmeasured —
+     record it as `error-logged` with error `contract.constraint-decay` so
+     the session gets linked under `--continues` next time.
    - `parallel` or `single` — nothing further; the wave ran as wide as it
      was admitted.
-5. Dispatch **`tester`** (`.claude/agents/tester.md`) for missing unit
+5. Dispatch **`bs-tester`** (`.claude/agents/bs-tester.md`) for missing unit
    coverage and epic-level e2e/screenshots.
+   - The moment it returns, project its result: `bs results record --task
+     <task-id> --result <tester-result.json> --agent tester --provider <name>
+     --model-tier <tier> --worktree <dir> --session ... --plan-version N
+     --causal-parent ...`. `--agent` stamps the envelope, token_usage
+     included, as `gate run` does; `--worktree` is the coder's worktree the
+     tester shares, and records the HEAD that proves the screenshots fresh
+     (D2) — step 7's uiux stage blocks `screenshots-stale` when this HEAD
+     doesn't match the gate's. The tester has no tests of its own to run, so
+     it never reaches `gate run` itself — without this, its screenshots sit
+     in the result file and never reach the task page.
    - Then the **uiux visual pass**, but only when all three hold: the task
      is UI-affecting, the tester actually returned screenshot artifacts, and
-     step 3 wrote a uiux spec for this task (agent-interviews.md N-6). Miss
-     any one and skip it — say so; a "visual pass" over screenshots that do
-     not exist is worse than no pass. Dispatch it with the spec path and the
+     step 3 wrote a uiux spec for this task (agent-interviews.md N-6). For a
+     UI-affecting task, miss any one and stop, do not skip — step 7's gate
+     blocks a flagged task with no fresh, reviewed screenshot set, so a
+     missing condition here is not a quiet pass-through to the gate, it is a
+     reason to fix the condition first. Dispatch it with the spec path and the
      image paths and **nothing else**: no diff, no components, no test code.
      The pass is a judgment about the rendered screen, and a uiux session
      that reads the diff ends up reviewing intent, which the reviewer
      already covers.
-6. Dispatch **`grader`** (`.claude/agents/grader.md`) — bounded rubric
+     Bracket it with `bs judge dispatch --role uiux --kind visual` / `bs
+     judge report --role uiux --kind visual`: a dispatch with no `--kind` is
+     refused (`judges.kind-required`), because a kindless turn is one the gate's
+     uiux stage never reads.
+   - **Blast radius.** When the task's claims touch a shared primitive (a
+     design-system/kit component or a global stylesheet), a screenshot of
+     the task's own screens is not the full surface: the tester re-shoots
+     and the uiux visual pass reviews every screen that renders that
+     primitive, not only the task's screens. The tester determines that
+     list — from the screenshot suite already on disk or from the
+     primitive's importers — and records it alongside the screenshots it
+     captures. The "max 4 per feature" screenshot cap (bs-tester.md) still applies per
+     screen; it is the screen count that grows, not the shots on each one.
+6. Dispatch **`bs-grader`** (`.claude/agents/bs-grader.md`) — bounded rubric
    loop, `profile.graderRounds` rounds (2 at `huge`, 1 below; never more
    than 2, agent-constraints.md "grader (v3)"), before any gate
    runs; it never decides pass/fail itself. At one round the grader scores
@@ -189,12 +226,23 @@ one thing this playbook never asks you to.
    gates nothing (D-34). A round-2 `fail` re-scopes via dispatch.md's "Round
    counting and escalation", not a round 3 on this id.
 7. Run the gate pipeline:
-   `smith gate run <task-id> --worktree <dir> --checks checks.json --result
+   `bs gate run <task-id> --worktree <dir> --checks checks.json --result
    result.json --grader state/results/<task-id>.grader-r<round>.json
-   --findings findings.json --session ... --plan-version N
+   --findings findings.json --plan <plan.json> --uiux-visual
+   state/results/<task-id>.uiux-visual.json --session ... --plan-version N
    --causal-parent ...` (schema check → grader verdict → tests → coverage
    evidence → findings intake → severity decision,
    `docs/guide/operator-guide/queue-and-gate.md` §5).
+   - `--plan` is what lets the gate's uiux stage read the task's
+     `ui_affecting` flag; without it the stage records "unverifiable" and
+     does not block. `--uiux-visual` hands over the visual pass's result
+     file when step 5 ran one — omit it for a task that is not UI-affecting.
+   - `checks.json`'s unit check must be the project's full test command,
+     never a hand-picked list of files — `gate run` runs each check command
+     literally, with no narrowing of its own. Narrowing by changed files is
+     `bs queue run --select-test-cmd` (`factory/orchestrator/src/testSelect.ts`),
+     a queue-tier flag `--batch` refuses; it does not reach `checks.json`. A
+     scoped-down unit check is how red tests have merged before.
    - `--grader` takes step 6's file, latest round. A criterion that came back
      `fail` or `partial` blocks before any check command runs — the outcome is
      `blocked` with `reason: "grader-fail"`, and the payload's
@@ -205,11 +253,11 @@ one thing this playbook never asks you to.
      add (D-40). `blocked` with `reason: "coverage-evidence"` means the run
      produced no per-file number for a file this task's claims name; fix the
      reporter or the include glob, not the code. Ask the same question
-     outside a gate run with `smith coverage check <worktree-dir> --plan
+     outside a gate run with `bs coverage check <worktree-dir> --plan
      <plan.json> --task <task-id>` (§5c).
-   - Findings come from dispatching **`reviewer`**
-     (`.claude/agents/reviewer.md`, fresh context, read-only) then
-     **`verifier`** (`.claude/agents/verifier.md`, adversarial refute
+   - Findings come from dispatching **`bs-reviewer`**
+     (`.claude/agents/bs-reviewer.md`, fresh context, read-only) then
+     **`bs-verifier`** (`.claude/agents/bs-verifier.md`, adversarial refute
      mandate) — never skip the adversarial stage on an S1/S2 finding
      (`crosscheck.yml` `asymmetric_roles`). Which findings that covers is
      `profile.verifierSeverities`, plus a
@@ -219,25 +267,26 @@ one thing this playbook never asks you to.
      thing a cheaper tier drops; `S1-stop-the-line` is in every tier's list
      and no tier may remove it. A finding outside the tier's list still goes
      to the coder — it is verified by the coder's fix, not waived.
-   - Dispatch **`security-reviewer`** only when its conditional triggers
+   - Dispatch **`bs-security-reviewer`** only when its conditional triggers
      fire — never per-task by default. Ask, do not recall:
-     `smith security triggers --task <spec.json>` and dispatch iff
+     `bs security triggers --task <spec.json>` and dispatch iff
      `dispatchSecurityReviewer` is true ("Dispatching the security-reviewer"
      above).
    - Every judge dispatched in steps 5–7 — uiux visual pass, grader,
      reviewer, verifier, security-reviewer — is bracketed by
-     `smith worktree fingerprint` / `smith worktree verify`
+     `bs worktree fingerprint` / `bs worktree verify`
      ("Fingerprint the worktree around every judge" above). Exit 1 discards
      that judge's result; it does not become a finding against the coder.
-   - Each of those is also bracketed by `smith judge dispatch` /
-     `smith judge report` ("Declare each judge's artifact before you dispatch
-     it" above). `smith judge outstanding --task <task-id>` exits 1 while any
+   - Each of those is also bracketed by `bs judge dispatch` /
+     `bs judge report` ("Declare each judge's artifact before you dispatch
+     it" above); paste `judge dispatch`'s `expected_line` inline in the
+     judge's prompt, or the `Agent` call is refused. `bs judge outstanding --task <task-id>` exits 1 while any
      judge still owes its file — re-poke it and report before running the
      gate, because the gate now refuses to score with a non-empty outstanding
      set (`reason: judges-outstanding`) rather than reading a silent judge as
      zero findings.
    - The gate scores tests it did not write, so once it has run, make the log
-     say who did: `smith tester check <session-id> --task <task-id>`
+     say who did: `bs tester check <session-id> --task <task-id>`
      (`crosscheck.yml` `role_isolation`, operator-guide/dispatch-audits.md §2d). Exit 1
      means no `tester` dispatch precedes this task's `testgate-result`, the
      coder and tester dispatches share one `agent_id`, or the answer is
@@ -246,9 +295,9 @@ one thing this playbook never asks you to.
      downstream still goes green — step 5 is what prevents that, and this is
      the log checking that step 5 happened.
 8. Every dispatch in steps 3–7 carries the compiled lessons block for that
-   role (`smith lessons for-dispatch <role> --plan … --task …`), every
+   role (`bs lessons for-dispatch <role> --plan … --task …`), every
    worktree dispatch also carries the open-findings block for that task
-   (`smith findings for-dispatch --plan … --task …`) — both under "Dispatch
+   (`bs findings for-dispatch --plan … --task …`) — both under "Dispatch
    contract" above — and each is a `dispatch_decision` event with a `causal_parent`
    chaining back to the prompt/decision that caused it (architecture §7) —
    this is the timeline, not optional bookkeeping.
@@ -259,22 +308,25 @@ one thing this playbook never asks you to.
    rung, never loop past one. Count the rounds from this task's
    `dispatch_decision` events, not from the agent's own account of itself
    — see "Round counting and escalation" above. Then have the log check
-   you: `smith escalation check <session-id> --task <task-id>`, which
+   you: `bs escalation check <session-id> --task <task-id>`, which
    exits 1 if the rung you just climbed is not evidenced.
 10. Gate outcome `pass`/`pass-with-waivers-pending` → before admitting, audit
-    the wave's own parallelism: `smith wave audit --session <id> --epic
+    the wave's own parallelism: `bs wave audit --session <id> --epic
     <epic>`. It reads the log back and says whether the tasks admitted
     together actually ran together — `parallel` when every admitted task was
     in flight at once, `partial` when two or more overlapped but never all,
     `serialized` when work is recorded but no two tasks ever overlapped,
     `single` when the wave admitted one task (nothing to be parallel about),
-    and `unobserved` when the wave was admitted and the log shows no work for
-    any of its tasks. Exit 1 on `serialized`, exit 2 on `unobserved` — either
+    `unlinked` when the work merged or dispatched but off the epic's own
+    lineage (width unmeasured, not zero — usually a wave-runner session
+    started without `--continues`), and `unobserved` when the wave was
+    admitted and the log shows no work for any of its tasks. Exit 1 on
+    `serialized`, exit 2 on `unobserved`, exit 0 on `unlinked` — each
     is a fact for the wave-loop's hand-back, not a reason to hold the merge:
     report the verdict and keep going to admission. Then ask what the diff
     did to everyone outside the claims, and whether it
     kept what the spec promised:
-    `smith claims impact <worktree-dir> <spec.json>`. Exit 1 means a
+    `bs claims impact <worktree-dir> <spec.json>`. Exit 1 means a
     `proven` break — this task removed an export a file outside its claims
     still imports — **or a broken promise**: a file the spec's
     `keeps_exports` names lost an export or changed one's declaration.
@@ -282,10 +334,14 @@ one thing this playbook never asks you to.
     entries in the bounce. A `possible` / `signature-changed` entry in
     `breaks` exits 0 and is a note: the scanner reads text, not types
     (operator-guide/wave.md §2). Then admit into the
-    merge queue: `smith queue run <epic> --project <project-dir>
-    --test-cmd "<cumulative test command>" --tasks tasks.json`. On a
-    `rebase-conflict` outcome, dispatch **`merger`**
-    (`.claude/agents/merger.md`) with both diffs + specs, and note three
+    merge queue: `bs queue run <epic> --project <project-dir>
+    --test-cmd "<cumulative test command>" --tasks tasks.json --plan
+    <plan.json> --session <id> --plan-version <n> --causal-parent
+    <event-id>` — the same write triple as every other dispatch above; a
+    merge that lands with no session to log it into is a fact the
+    timeline never gets. On a
+    `rebase-conflict` outcome, dispatch **`bs-merger`**
+    (`.claude/agents/bs-merger.md`) with both diffs + specs, and note three
     things the queue's own behaviour forces (agent-interviews.md N-12):
     - **Into the failing task's existing worktree** — a fresh one would not
       reproduce the conflict. The result gives you only `taskId` and
@@ -296,7 +352,7 @@ one thing this playbook never asks you to.
     - The queue already ran `git rebase --abort` (`queue.ts`), so the
       merger arrives at a clean tree and **replays** the rebase rather than
       resuming it — and it **never lands the merge**. When it returns
-      `resolution: "mechanical"`, re-run `smith queue run`; the queue stays
+      `resolution: "mechanical"`, re-run `bs queue run`; the queue stays
       the single place a merge can happen.
 
     `resolution: "escalated"` — low confidence, or both sides changed the
@@ -305,10 +361,10 @@ one thing this playbook never asks you to.
     `conflict_resolution_ladder`).
 
     An `integration-dirty` outcome names a `worktree` holding
-    `smith/<epic>/integration` with uncommitted tracked changes (`dirty`):
-    commit or stash those there, then re-run `smith queue run`.
+    `bs/<epic>/integration` with uncommitted tracked changes (`dirty`):
+    commit or stash those there, then re-run `bs queue run`.
 
-    Once the wave is merged, check the epic's spend — `smith budget alarm
+    Once the wave is merged, check the epic's spend — `bs budget alarm
     <session-id> [--epic <epic>]`. Exit 1 means either the epic crossed
     `alarm_ratio` (re-plan the remaining work to fit, or ask the operator —
     extension is always an operator question) **or** the log is too holey to