@juzser/blacksmith 0.3.0 → 0.5.0

package/.claude/skills/bs/mcp.md

@@ -3,10 +3,10 @@
 Every project leaving the factory ships an MCP surface
 (`docs/standards/mcp.md`). It is due **late** — at the mandatory
 `<project> — mcp surface` milestone, once the tools worth exposing are known.
-Running this at `smith new` time would produce a manifest declaring nothing,
+Running this at `bs new` time would produce a manifest declaring nothing,
 which is the rubber stamp the standard exists to prevent.
 
-1. Run `smith mcp init <project>`. It layers `src/mcp/`, `test/mcp/`, and a
+1. Run `bs mcp init <project>`. It layers `src/mcp/`, `test/mcp/`, and a
    root `mcp.manifest.json` onto the already-scaffolded project, merges the
    `mcp:serve` script and the pinned SDK dependency into its `package.json`,
    and appends the `mcp surface` milestone to `factory/specs/roadmap.md`.
@@ -22,8 +22,8 @@ which is the rubber stamp the standard exists to prevent.
    `main`) are not allowed at all (mcp.md MCP-S3). A signed `destructive` tool
    is permission to act inside the project, never a way around an operator
    gate.
-4. Run `smith mcp check <project>` before closing anything under that
+4. Run `bs mcp check <project>` before closing anything under that
    milestone. Exit 0 means green; exit 1 prints one `{ rule, path, message }`
-   per violation. `smith epic close` runs the same check and refuses while it
+   per violation. `bs epic close` runs the same check and refuses while it
    is red — the only way past it is `--override-rationale`, which is the
    operator's call and their name in the event log, never yours.

package/.claude/skills/bs/new.md

@@ -1,8 +1,8 @@
 # `/bs new <project> [--ui]` — scaffold a target project
 
-1. Ask where the project should live, then run `smith new <project> [--ui]
+1. Ask where the project should live, then run `bs new <project> [--ui]
    [--target-dir <dir>]`. Without `--target-dir` it lands beside the clone, in
-   `<repo-parent>/<project>` — or, when `smith` is an installed package rather
+   `<repo-parent>/<project>` — or, when `bs` is an installed package rather
    than a clone, in the directory you run it from, never inside the package.
    Either way that is a default rather than a requirement —
    the answer becomes the `<project-dir>` every later command takes, so take
@@ -15,7 +15,7 @@
    bootstrap milestone in `factory/specs/roadmap.md` — all in one call.
    An answer the templates cannot build (`frontend: react`) makes it **refuse
    before creating anything**, rather than quietly handing over the frontend
-   they do ship. `smith stack check` says in advance which answers are
+   they do ship. `bs stack check` says in advance which answers are
    honoured, merely recorded, or refused.
 2. The gate run is `pnpm install` then `lint`, `typecheck`, `test:coverage`,
    `build` — `ci.yml`'s order, so the lockfile lands in the first commit and no

package/.claude/skills/bs/plan.md

@@ -11,8 +11,8 @@ one — and it scales steps 3–4 below plus most of `/bs run`. Ask, do not
 recall:
 
 ```bash
-smith effort show --effort <small|medium|huge>   # no plan file exists yet
-smith effort show --plan factory/specs/active/<epic>/plan-vN.json
+bs effort show --effort <small|medium|huge>      # no plan file exists yet
+bs effort show --plan factory/specs/active/<epic>/plan-vN.json
 ```
 
 `profile` is what this epic buys, and every step below that a tier touches
@@ -34,17 +34,41 @@ there means "not looked at", not "looked at and clean".
 
 1. **Static analysis for claims first.** Before any decomposition, get the
    target repo's import/dependency graph so claims are computed, not
-   guessed (architecture §5) — dispatch `researcher`
-   (`.claude/agents/researcher.md`) for an unfamiliar repo, or do it
+   guessed (architecture §5) — dispatch `bs-researcher`
+   (`.claude/agents/bs-researcher.md`) for an unfamiliar repo, or do it
    directly with Grep/Read for a small one.
-2. Dispatch a **`planner`** session (`.claude/agents/planner.md`, frontier
+2. Dispatch a **`bs-planner`** session (`.claude/agents/bs-planner.md`, frontier
    tier) with the goal + the claims analysis. It drafts the epic spec and
    task specs (`factory/specs/schema/task-spec.schema.json` shape).
-3. Dispatch a **`spec-reviewer`** session (`.claude/agents/spec-reviewer.md`)
+3. Dispatch a **`bs-spec-reviewer`** session (`.claude/agents/bs-spec-reviewer.md`)
    — a *different model* than the planner's, per its own frontmatter — to
    hunt spec gaps/ambiguities/missing-nonfunctional clauses
    (`docs/standards/agent-constraints.md` "planner"; `severity.yml`: most
-   spec gaps land S2, blocking sign-off).
+   spec gaps land S2, blocking sign-off). Name the review focus in the
+   dispatch itself, as a short list of at most six items, so findings come
+   back tagged to one of them:
+
+   1. Claims and dependency edges, cross-checked against
+      `bs claims impact`.
+   2. TDD-ability -- a named failing test per task, before its code.
+   3. Nonfunctional and security clauses.
+   4. Budget and diff-cap fit.
+   5. Acceptance-criterion coverage -- every epic criterion maps to a task.
+   6. From round 2 on, only the previous round's findings plus any task
+      that changed since then.
+
+   The prompt also carries, inline on its own line,
+   `Declared artifact: /abs/path/to/state/results/<epic-id>.spec-review.json`
+   — the absolute form of the path `bs-spec-reviewer.md` names. The PreToolUse
+   guard refuses a judge dispatch without it.
+
+   When `size.small` reads true on the draft (`bs wave schedule` or
+   `bs plan ingest`'s `parallelism.size`, run against the draft plan
+   file), recommend effort tier `small` -- single-pass spec review -- to
+   the operator unless a security trigger floors it first, and say why in
+   the same message: a plan that cannot spread past a few tasks and a
+   handful of claim paths does not need a second review round to find what
+   one pass already covers.
 4. Planner fixes flagged issues; repeat 2–3 until the spec-reviewer has
    nothing S1/S2 left — or exactly once when `profile.specReviewRounds` is
    `single-pass` (`small`), where the planner fixes what came back and
@@ -55,9 +79,10 @@ there means "not looked at", not "looked at and clean".
    confidence) for you:
 
    ```bash
-   smith plan quorum --plan <the draft's plan.json> --plan-version <n> \
+   bs plan quorum --plan <the draft's plan.json> --plan-version <n> \
      --session <session-id> --causal-parent <event-id> \
      --confidence <your own 0–1 confidence in this plan> \
+     --project <project-dir> \
      --out <scratch>/quorum-v<n>.json
    ```
 
@@ -67,7 +92,10 @@ there means "not looked at", not "looked at and clean".
    exist. (`--epic <epic>` instead of `--plan` critiques a version already
    filed.) The draft's own `epic_id`/`version` must be the ones the command
    names, or it refuses (`plan.identity-mismatch`) rather than record one
-   plan's identity with another plan's triggers. `--out` keeps the outcome
+   plan's identity with another plan's triggers. `--project <project-dir>`
+   has no worktree to derive from at this step — no task has one yet — so
+   name it directly, or a `<project-dir>/.blacksmith/crosscheck.yml` overlay
+   never reaches the providers this quorum weighs. `--out` keeps the outcome
    — three rationales of several kB each — where step 5 can hand it to the
    operator whole instead of quoting a terminal.
 
@@ -90,10 +118,10 @@ there means "not looked at", not "looked at and clean".
    "planner: autonomy — spec sign-off per epic").
 6. On approval, write task specs to
    `factory/specs/active/<epic>/plan-v1.json` and validate:
-   `smith plan validate factory/specs/active/<epic>/plan-v1.json` must
+   `bs plan validate factory/specs/active/<epic>/plan-v1.json` must
    report `{"valid":true}` before anything else touches this plan. Write the
    tier onto the plan file as a top-level `"effort": "<tier>"` — that is
-   where `/bs run` reads it, and `smith plan amend` carries it into
+   where `/bs run` reads it, and `bs plan amend` carries it into
    v(n+1) so a re-plan is not a fresh choice. Omit the field to take the
    policy default; a value that is not `small`/`medium`/`huge` fails
    validation rather than degrading to it.
@@ -102,7 +130,7 @@ there means "not looked at", not "looked at and clean".
    against it:
 
    ```bash
-   smith wave schedule factory/specs/active/<epic>/plan-v1.json \
+   bs wave schedule factory/specs/active/<epic>/plan-v1.json \
      --session <session-id> --repo <project-dir>
    ```
 
@@ -127,10 +155,15 @@ there means "not looked at", not "looked at and clean".
    decide whether to re-slice, and say which you chose when you present the
    plan.
 
+   The same JSON also carries `size` -- `{tasks, claims, small}` over live
+   tasks only -- the block `plan ingest` prints again under `parallelism`
+   at step 7; `small` is true at or under 3 live tasks and 10 distinct
+   claim paths, and this is where the step 3 tier read gets confirmed.
+
    Beside the schedule, the read that names what it only counts:
 
    ```bash
-   smith claims impact --plan factory/specs/active/<epic>/plan-v1.json \
+   bs claims impact --plan factory/specs/active/<epic>/plan-v1.json \
      <task-id>... --repo <project-dir>
    ```
 
@@ -138,8 +171,8 @@ there means "not looked at", not "looked at and clean".
    at; `promised` holds the ones a producer's `keeps_exports` already
    answers, which the schedule admits and the diff is later checked against.
 7. Log the sign-off itself as a decision checkpoint (this is exactly what
-   `smith dream`'s "plan sign-off" extraction looks for, `lessons.ts`):
-   `smith event append '{"session_id":"...","actor":"operator",
+   `bs dream`'s "plan sign-off" extraction looks for, `lessons.ts`):
+   `bs event append '{"session_id":"...","actor":"operator",
    "event_type":"plan-version-created","plan_version":1,
    "causal_parent":"...","payload":{"epic_id":"<epic>","version":1,
    "note":"<operator's own words>"}}'`.
@@ -148,7 +181,7 @@ there means "not looked at", not "looked at and clean".
    the sign-off event:
 
    ```bash
-   smith plan ingest factory/specs/active/<epic>/plan-v1.json \
+   bs plan ingest factory/specs/active/<epic>/plan-v1.json --project <project-dir> \
      --session <session-id> --plan-version 1 --causal-parent <sign-off event id>
    ```
 
@@ -163,6 +196,14 @@ there means "not looked at", not "looked at and clean".
    UI check found behind two epics. It is idempotent, so run it again on a
    resumed session; read `added` and `edges` back, and say so when either is
    0 on a plan that has tasks or edges.
+
+   Read `parallelism.widest` back from that same output, too. `parallel_with`
+   underneath it is claims-and-edges only -- import-graph crossings stay
+   `wave schedule --repo`'s job, not this key's -- so it can only ever name
+   a width that job would not contradict. A `widest` of 1 on a
+   plan of two or more tasks means every task the wave loop will ever run
+   sits behind some claim or edge that serializes it: flag that to the
+   operator now, before a run discovers it as a stalled wave.
 8. If this epic opens a new roadmap milestone, add it to
    `factory/specs/roadmap.md` (planner-maintained, architecture §12) — a
    roadmap change is itself a scope change and needs the same operator nod.

package/.claude/skills/bs/report.md

@@ -8,8 +8,8 @@ duties, v3.2)"), plus running the scheduler first — a report that omits
 pending proposals lets them sit invisible instead of surfacing them.
 
 1. **Ask what the factory is answerable for, then run the scheduler.**
-   `smith projects list` reads the roadmap's `- project:` bullets — the
-   register `smith new` writes to — and prints the factory itself plus every
+   `bs projects list` reads the roadmap's `- project:` bullets — the
+   register `bs new` writes to — and prints the factory itself plus every
    project it built that has a checkout, ending in the `--project` line to
    pass on. Do not assemble that list from memory: the maintenance pass
    reads one lockfile per flag and reports one proposal per repo, so a repo
@@ -17,9 +17,9 @@ pending proposals lets them sit invisible instead of surfacing them.
    mentioned. (The daemon raises `unwatched-project` for a child project with
    a checkout that is left off the line — not for the factory itself, which is in
    the pass by default, and not for a declared project with no checkout at
-   all, which `smith projects list` marks with `?` instead of leaving it
+   all, which `bs projects list` marks with `?` instead of leaving it
    off the printed list. The two surfaces no longer answer the same
-   question.) Then run `smith scheduler run
+   question.) Then run `bs scheduler run
    [--dry] --session <id> [--project <dir>...]` with those flags — a
    deterministic pass over the event log, it never dispatches an agent
    itself (`factory/policies/scheduler.yml`, architecture §12). Read its
@@ -42,7 +42,7 @@ pending proposals lets them sit invisible instead of surfacing them.
      where the planner reads the living spec/analytics/recheck outcomes
      and proposes new epics — the operator's tick is required regardless
      of confidence, same as any other plan sign-off.
-2. **Ask who may say yes.** `smith scheduler admit --session <id>
+2. **Ask who may say yes.** `bs scheduler admit --session <id>
    [--project <dir>...]`, with the same flag line step 1 printed, re-reads
    the same proposals and classifies
    each one `auto` or `operator` against `scheduler.yml`'s `autonomy:`
@@ -66,9 +66,9 @@ pending proposals lets them sit invisible instead of surfacing them.
      `confidence_floor` is an operator decision about standing policy, not
      a way past one proposal — and a `security-surface` denial is the one
      nothing in the file can lift.
-3. Gather `smith stats overview [--session <id>]` and `smith stats roadmap
+3. Gather `bs stats overview [--session <id>]` and `bs stats roadmap
    [--session <id>]` (milestone progress + budget burn per milestone).
-4. **Read back the disagreements.** `smith judge escalations --session
+4. **Read back the disagreements.** `bs judge escalations --session
    <id>` folds the lineage for `quorum-decision` events whose latest word
    was `escalate` — a gate finding, an epic verdict or a plan critique the
    cross-provider quorum could not settle. It exits `1` on an open
@@ -83,7 +83,7 @@ pending proposals lets them sit invisible instead of surfacing them.
    `mode: shadow` disagreement, which the gate outcome never reported to
    anyone). Resolving one is an operator reading, never this session
    deciding on its own which provider was right.
-5. **Read back the parallelism.** `smith wave audit --session <id>
+5. **Read back the parallelism.** `bs wave audit --session <id>
    [--epic <id>]` folds every `wave-admitted` against the
    `dispatch_decision` intervals underneath it and says whether a wave
    admitted N wide actually *ran* N wide. `wave check` only ever certified
@@ -97,11 +97,11 @@ pending proposals lets them sit invisible instead of surfacing them.
    check before reporting it as a stall. A `partial` verdict is **not** a
    finding; put `widest` in the digest as the one number that says how wide
    this factory has ever actually run.
-6. Dispatch **`scribe`** (`.claude/agents/scribe.md`, small tier) with that
+6. Dispatch **`bs-scribe`** (`.claude/agents/bs-scribe.md`, small tier) with that
    JSON plus step 2's admissions as input: shipped / in-flight / blocked /
    budget burn / next milestone / **N rechecks pending, M maintenance
    bumps auto-schedulable** (never silently dropped), ≤300 words, linking
-   into the dashboard (`smith ui serve`'s URL) — never paraphrase numbers
+   into the dashboard (`bs ui serve`'s URL) — never paraphrase numbers
    the query didn't return.
 7. This fires automatically on a weekly cadence and immediately on any
    milestone completion (architecture §12) — for an ad hoc `/bs report`,
@@ -114,7 +114,7 @@ pending proposals lets them sit invisible instead of surfacing them.
 
 **Provider calibration note (Phase 8).** While any provider in
 `factory/policies/crosscheck.yml` is still `mode: shadow`, run
-`smith stats providers [--session <id>] [--since <iso-date>]` alongside the
+`bs stats providers [--session <id>] [--since <iso-date>]` alongside the
 scheduler pass and fold a one-line mention into the digest when a provider
 has accumulated enough runs to review (`runs`, `verdicts`, `agreementRate`,
 `schemaFailureRate`, `transportFailureRate`, `failuresByCode` per provider —