@juzser/blacksmith 0.1.0

package/factory/policies/budgets.yml

@@ -0,0 +1,262 @@
+# Blacksmith — budget policy
+#
+# Token/turn caps per tier (architecture §2, §4, agent-constraints.md
+# "budgets (factory-wide)").
+#
+# What is mechanical, and what is a request (P9-18, 2026-08-08; `failed_rounds`
+# added P9-32 and `alarm_ratio` P9-33, both 2026-08-10; `max_in_flight_tasks`
+# added 2026-08-26, the same day `epic.cap_tokens` grew a reader that actually
+# blocks). Exactly six numbers here reach a runtime host:
+#
+#   * `epic.cap_tokens` — three readers now, and only the newest of them
+#     blocks. planQuorum's budget trigger sums *declared* task budgets against
+#     it before any dispatch and only ever surfaces the finding for a human to
+#     act on; `smith budget alarm` compares it against spend counted from the
+#     event log, after wave merge, and also stops nothing itself. `smith wave
+#     check` (src/waveBudget.ts) is the reader that blocks: at wave admission —
+#     before any task in the wave has been dispatched — it sums the wave's
+#     declared task budgets against headroom under the cap (measured spend plus
+#     a declared price for every dispatch nothing has measured yet, the same
+#     projection `smith budget alarm` computes) and refuses to admit a wave
+#     that would cross it. It is not a stricter version of the other two
+#     readers' advice; it is the only one of the three standing upstream of the
+#     spend it is judging, so it is the only one that can refuse the spend
+#     instead of merely describing it afterward.
+#   * `epic.alarm_ratio` — `smith budget alarm` (src/budgetAlarm.ts), which
+#     reports each epic's measured and projected spend against
+#     `alarm_ratio * cap_tokens` and exits 1 on a crossing. Measured spend is a
+#     floor, not a total: a judge returns findings rather than a Result, so its
+#     tokens are in no `task-result-recorded` event and are priced from the
+#     caps below instead. A role with no cap here cannot be priced at all, and
+#     the epic is reported unverifiable rather than under — which is why the
+#     `task:` block's coverage of the roles the factory actually dispatches is
+#     load-bearing and not merely documentary.
+#   * a task's `tokens` — compared at the gate against the result's
+#     `token_usage.total_tokens`.
+#   * a task's `diff_lines` — compared at the gate against a real
+#     `git diff --numstat` (src/diffstat.ts), lockfiles and generated output
+#     excluded.
+#   * `escalation_ladder.rungs[].failed_rounds` — counted from `gate-outcome`
+#     events by `smith escalation check` (src/escalation.ts), which asserts the
+#     rung's `enforce` obligation against what the log shows happened next.
+#   * `epic.max_in_flight_tasks` — `smith wave check`, which refuses to admit a
+#     wave that would put more of the epic's tasks in flight at once (admitted,
+#     not yet merged) than this. Null by default; see the field's own comment
+#     below for why it is not the mechanism that bounds cost.
+#
+# The task gate still only records an overrun and reports it; it still does
+# not block on one. An overrun there is as often evidence the plan
+# under-estimated the task as evidence the task overran, and a cap the worker
+# polices itself becomes a pressure on the very work it is supposed to be
+# measuring (D-29: a coder spent its tail shaving lines to land exactly on
+# `diff_lines`, stopping mid-procedure to do it).
+#
+# The epic cap no longer works that way: `smith wave check` blocks on one.
+# The difference is not that an epic overrun matters more than a task overrun
+# — it is *when* each is checked. The task gate polices work already
+# underway, so refusing there distorts the work it is judging. Wave admission
+# asks its question before any task in the wave has started, when there is
+# nothing in flight yet for a refusal to put pressure on. A decision made
+# before the work exists cannot become pressure on the work.
+#
+# Every other number below is prompt-level: read by agents from their own
+# template and by the operator from the /bs playbook. They are requests, not
+# limits, and the sections that follow say which is which. `max_turns` is no
+# longer among them at all — no dispatch harness can enforce a turn limit
+# (agent-interviews.md M-4), so plan validation now rejects it as a task budget
+# field and the number belongs in the dispatch prompt.
+#
+# No concurrency cap on cost grounds, by design (removed 2026-08-05). Workers
+# run in isolated worktrees on disjoint path claims, so parallelism is bounded
+# by the claim graph, not by a worker count — and fan-out buys wall-clock
+# without buying extra tokens (architecture §15.3). Hundreds of concurrent
+# subagents is a supported shape. That reasoning holds only as long as the
+# token cap it leans on actually binds, which — before `smith wave check` —
+# `epic.cap_tokens` did not. `epic.max_in_flight_tasks` below is not that
+# removed cap come back: it defaults to null, and cost stays bounded by
+# `cap_tokens`, not by a worker count. It exists for an operator who wants a
+# wall-clock or rate-limit bound for a reason of their own — a provider's
+# concurrent-request limit, a laptop's CPU count — and setting it changes
+# nothing about what bounds spend.
+
+epic:
+  cap_tokens: 4000000        # planner + all workers + judges, one epic.
+                              # Raised from 2,000,000 by operator decision on
+                              # 2026-08-11 (dogfood-mcp-1), which is the
+                              # operator answer the `alarm_ratio` note below
+                              # requires — an extension, not a silent widening.
+                              # The number the envkit-mcp-surface dogfood
+                              # measured: 1,529,963 tokens for two of four
+                              # tasks, both of them the two smallest in the
+                              # plan. The old cap could not have carried that
+                              # epic to close, and the alarm said so at 109%
+                              # before the third task was ever dispatched.
+                              # Two things this does NOT fix, both worth a
+                              # follow-up: (1) there is no per-epic override,
+                              # so a number raised for one epic is raised for
+                              # every epic black-smith will ever run; (2) a
+                              # large share of that 1.5M was rework — stopped
+                              # dispatches and re-dispatches that `smith
+                              # escalation check` recorded as ladder
+                              # violations — so this cap now accommodates
+                              # waste as well as work. A cap sized from a
+                              # badly-run epic is a ceiling measured at the
+                              # wrong place.
+  alarm_ratio: 0.7           # at 2.8M tokens: planner must re-plan remaining
+                              # work to fit, or ask the operator. Epics that
+                              # cannot fit are split at spec time, never
+                              # silently extended (extension is always an
+                              # operator question). Checked by `smith budget
+                              # alarm <session>`, which the /bs run loop runs at
+                              # each wave merge — before P9-33 this number's
+                              # only reader was a human remembering to look.
+  max_in_flight_tasks: null  # Off by default. "Fan-out buys wall-clock
+                              # without buying extra tokens" above is the
+                              # standing decision, and it only holds while the
+                              # token cap actually binds — which `smith wave
+                              # check` now makes true. So this is NOT the
+                              # mechanism that bounds cost; `cap_tokens` is,
+                              # and it is checked regardless of how this field
+                              # is set. This knob exists for an operator who
+                              # wants a wall-clock or rate-limit bound for a
+                              # reason of their own — a provider's
+                              # concurrent-request limit, a laptop's CPU count
+                              # — and setting it makes `smith wave check`
+                              # refuse to admit a wave that would put more of
+                              # the epic's tasks in flight (admitted, not yet
+                              # merged) than this number at once.
+
+task:
+  # Defaults a planner sizes a task's own `budget` block against. The task's
+  # declared numbers are what the gate checks; these are the shape of a
+  # reasonable declaration, not a second cap applied on top.
+  coder:
+    cap_tokens: 150000       # Second reader, added 2026-08-26: `smith wave
+                             # check` prices a task that exists only in the
+                             # event log at this number. A follow-up minted by
+                             # `findings raise` has claims but no declared
+                             # budget (D-48/P9-31) — no plan ever had a field
+                             # for one — so the wave's sum would otherwise be
+                             # unverifiable and the follow-up inadmissible,
+                             # which would leave the factory's own repair path
+                             # reachable only by hand-editing the plan the
+                             # follow-up exists to avoid. This is a charge,
+                             # not a waiver: it is the most such a task may
+                             # spend, and a wave of follow-ups is refused when
+                             # that many coder caps will not fit under the
+                             # epic headroom. A task the PLAN declares with no
+                             # `budget.tokens` is a different silence and is
+                             # still refused — the schema requires that field,
+                             # so its absence is a plan that never passed
+                             # `smith plan validate`.
+    cap_diff_lines: 400      # excludes lockfiles/generated files
+  researcher:
+    cap_tokens: 60000
+  judges:                    # spec-reviewer, reviewer, verifier, grader
+    cap_tokens: 40000
+  # Not priced here, and dispatched anyway: security-reviewer, merger, tester,
+  # uiux, planner, scribe. `smith budget alarm` cannot put a number on those
+  # dispatches, so an epic that used one is reported unverifiable rather than
+  # under — the omission is visible instead of free. Left unpriced on purpose
+  # until there is real spend data to size them from; inventing a cap would
+  # make the projection look complete without making it true.
+
+pre_code_budget:
+  # researcher + uiux together, before any code is written for the epic
+  share_of_epic_budget_max: 0.15
+
+context_window:
+  # Working-memory discipline (agent-constraints.md "context window
+  # (factory-wide)"). Distinct from the caps above: those are about cost, this
+  # is about the quality of what a session still holds. Prompt-level today
+  # (baked into .claude/agents/*); mechanical with the phase-9 loop daemon.
+  auto_compact_ratio: 0.6      # compact at 60% of the model's context window.
+                               # The other 40% is the room needed to ACT on the
+                               # summary: a session that compacts at 90% knows
+                               # what to do and has no budget left to do it,
+                               # which is what produces re-read loops, dropped
+                               # constraints and half-applied edits.
+  max_compactions_per_task: 1  # a second one means the task is over-scoped:
+                               # stop and return economy.budget-exceeded to the
+                               # planner for splitting, exactly as a token-cap
+                               # hit does. Chained compactions are how a session
+                               # quietly loses the contract it was given.
+  counts_against_budget: true  # tokens spent before a compaction still count
+                               # against the caps above — compacting is not a
+                               # way around the 150k coder cap.
+  compacting_roles: [planner, coder, tester, researcher, uiux, scribe]
+  narrowing_roles: [reviewer, verifier, grader, spec-reviewer, security-reviewer, merger, auditor]
+  # narrowing_roles hold evidence rather than build on it: a judge that compacts
+  # summarizes away the diff it is judging, and a merger that compacts loses one
+  # side of the conflict. At 60% they narrow scope and return a verdict on what
+  # they hold (judges) or escalate to the operator (merger) — they never compact.
+  keep:
+    - epic/task ids and the live plan version
+    - claimed globs
+    - decisions taken and why
+    - what is done vs. what remains
+    - open questions and blocking unknowns
+  drop:
+    - raw file contents
+    - raw tool/command output
+    - superseded reasoning
+  note: >
+    Durable state belongs in the event log, not the context window
+    (architecture §7). Anything that must survive a compaction is an event or a
+    result artifact; the window is working memory, the log is memory.
+
+escalation_ladder:
+  # architecture §12, agent-constraints.md "budgets (factory-wide)"
+  #
+  # `failed_rounds` and `enforce` are the machine-readable half, added P9-32.
+  # src/escalation.ts reads them and `smith escalation check` asserts them
+  # against the log; `trigger`/`action` stay as the human contract and must say
+  # the same thing. A failed round is one `gate-outcome` with outcome
+  # `blocked` for the task.
+  #
+  # enforce values (closed set — an unrecognised one is reported unverifiable,
+  # never skipped):
+  #   model-tier — the next builder dispatch for the task must be a strictly
+  #                higher model_tier than the one that failed.
+  #   operator   — the ladder stops here: no further builder dispatch until the
+  #                operator has answered (a `user_prompt`, or a waiver granted
+  #                or denied for the task).
+  # A rung with no `action` declares no obligation and asserts nothing; a rung
+  # with an `action` and no `enforce` is a rule nothing can check, and the
+  # audit says so rather than passing it.
+  rungs:
+    - rung: 1
+      trigger: bounded retry on the same contract
+      failed_rounds: 1
+    - rung: 2
+      trigger: 2 failed rounds on the same task
+      failed_rounds: 2
+      enforce: model-tier
+      action: escalate model tier automatically (sonnet -> opus), logged
+    - rung: 3
+      trigger: 3 failed rounds on the same task
+      failed_rounds: 3
+      enforce: operator
+      action: escalate to operator
+  note: >
+    Rungs are never skipped and never looped past their bound; doing so is a
+    coordination error (deadlock/livelock/starvation, taxonomy.yml).
+
+effort_scaling:
+  # architecture §15.3, §17 (equal-budget study: extra agents buy wall-clock
+  # + isolation, not reasoning)
+  #
+  # How many agents a step gets. *Which steps run at all* is the other half,
+  # and it lives in `factory/policies/effort.yml`: a per-epic tier
+  # (small/medium/huge) that scales the deliberation steps — pre-code briefs,
+  # spec-review rounds, the plan quorum, grader rounds, verifier severities,
+  # the closing spec review — and nothing else. Ask `smith effort show`; the
+  # two files do not overlap, and neither may touch a mechanical gate.
+  - rule: small fixes get a single coder, not a fan-out.
+  - rule: >
+      wave fan-out (concurrent dispatch of multiple coder/tester pairs) only
+      when claims are disjoint per static analysis (architecture §5); claims
+      that overlap get a dependency edge and run serially instead.
+  - rule: >
+      the scheduler prefers the cheapest shape that meets the acceptance
+      criteria — fan-out is a wall-clock optimization, not a default.

package/factory/policies/crosscheck.yml

@@ -0,0 +1,308 @@
+# Blacksmith — multi-provider cross-check policy
+#
+# architecture §6 "Multi-provider cross-check (anti tunnel vision)". The
+# judge tier is provider-agnostic by contract; the config seam has existed
+# since Phase 1, and Phase 8 (`factory/orchestrator/src/providers/`,
+# `src/quorum.ts`) wires it up for real: `transport` selects which
+# transport module runs a provider (cli-transport.ts / api-transport.ts),
+# `mode` gates how much power its verdict has (see below). `enabled: false`
+# means never invoked at all, regardless of `mode`, and both external
+# providers ship that way. Not a judgement about them: `enabled` is the one
+# field in this file that describes a MACHINE rather than the contract — it
+# answers "does this box have that judge", and for a box the repo has never
+# seen the honest answer is no. Switched on where the precondition is unmet a
+# provider does not fail loudly; it spends a doomed call on every quorum
+# trigger, has it caught, and leaves a failure row that reads like an outage.
+# So turn on the one you actually have — a one-line edit, runbook §2, and
+# `smith judge preflight` says beforehand whether it will work.
+# Full setup/calibration/promotion procedure: docs/runbooks/providers.md.
+#
+# Shadow mode (Phase 8 design decision): `mode: shadow` means a provider's
+# verdicts are RECORDED (judge-verdict events, `smith stats providers`) but
+# have ZERO gating power — quorum.ts falls back to the native verdict alone
+# whenever no provider in a case is `mode: active`. Flipping a provider to
+# `mode: active` in this file (an operator edit, never a runtime write) is
+# the entire promotion step; `mode: shadow` or `enabled: false` is the
+# entire rollback step.
+
+providers:
+  claude:
+    kind: native
+    enabled: true
+  codex:
+    kind: api
+    transport: cli          # `codex exec` headless — ChatGPT-subscription auth (`codex login` once), no API key spend. See docs/runbooks/providers.md.
+    command: codex
+    # NOT `--json` (D-118): that wraps the verdict as an escaped string inside
+    # an `item.completed` event, where no JSON scanner can reach it, and puts a
+    # `thread.started` banner ahead of it. Plain `exec` writes the agent's final
+    # message — and only that — to stdout.
+    #
+    # Re-derived against the live binary on 2026-08-17, codex-cli 0.147.0, on a
+    # subscribed account (D-118 was originally derived from two calls made while
+    # the account was near its quota limit). Both layers still hold, unchanged:
+    # `--json` still nests the verdict in `item.completed.item.text`, and plain
+    # `exec` still echoes the whole prompt to stderr — which the transport merges
+    # into its extraction buffer by design — so a prompt containing `[]` or `{}`
+    # still plants decoy JSON ahead of the answer. Over that real buffer the two
+    # extractor generations diverge exactly as D-118 claimed: first-parseable
+    # returns `[]`, first-validating returns the verdict. If you change these
+    # args, re-run that comparison rather than reasoning about it.
+    args: ["exec", "--color", "never"]
+    model_tier: mid          # taxonomy.yml model_tier — judge tier, architecture §4
+    # PRECONDITION: `codex` on PATH, and `codex login` run on every machine
+    # that dispatches a quorum trigger. Without either the CLI transport still
+    # spawns, fails, and quorum.ts records a provider error per trigger —
+    # caught, so nothing gates on it, but it is latency and noise.
+    # `smith judge preflight` checks the first half locally; only a real call
+    # can check the second.
+    # `auto`, not `true`. This is the one field in the file that describes a
+    # MACHINE, and the file is checked in, so `true` here would be a claim
+    # about every clone: the day this was written `true`, CI — which has no
+    # `codex` binary — started failing `judge preflight`'s soundness check,
+    # correctly, for a line that was true where it was typed.
+    #
+    # `auto` resolves against the precondition above, on the box reading the
+    # file: `codex` on PATH means enabled, no `codex` means silently off, and
+    # neither box needs to edit this line. What it cannot know is the second
+    # half — whether `codex login` was run — so a box with the binary and no
+    # session still spends a call per trigger and records the failure.
+    #
+    # Turned on for THIS box, 2026-09-02, by the operator who owns it: `codex`
+    # resolves on PATH and `codex login` is done, both checked by `smith judge
+    # preflight` and by a real `codex exec` call. Rollback for one box is
+    # `enabled: false` here, which `auto` never overrides.
+    enabled: auto
+    # `active`, not `shadow`: the operator's call (docs/runbooks/providers.md
+    # §3 offers shadow-then-calibrate and this box declined it).
+    #
+    # Be exact about what that buys today, because it is less than it looks:
+    # a shadow provider is still CALLED and still recorded as a participant
+    # (quorum.ts header note) — shadow costs the same call and forfeits only
+    # gating power. With one external judge promoted and `min_providers: 2`,
+    # a finding claude raised escalates either way. The difference is where
+    # codex's rationale lands: under `gating.rationales` when active, only
+    # under `participants` when shadow.
+    #
+    # So the promotion is not what makes the cross-check real — a second
+    # provider is (see quorum_rule.accept_non_gating_actives). What it does
+    # is make this box gate the moment one is enabled, with no second edit
+    # and no second decision to remember. Rollback is `mode: shadow` here.
+    mode: active
+  deepseek:
+    kind: api
+    transport: api
+    base_url: https://api.deepseek.com
+    model: deepseek-reasoner
+    response_format_json_object: true
+    api_key_env: DEEPSEEK_API_KEY
+    model_tier: mid
+    # PRECONDITION: DEEPSEEK_API_KEY must be readable by the dispatching
+    # process -- exported, or in the clone's gitignored `.env`, which the CLI
+    # loads at start without overriding anything already exported (D-270).
+    # Without it api-transport.ts throws `Environment variable "DEEPSEEK_API_KEY"
+    # is not set` on every quorum trigger; quorum.ts catches it, so the gate
+    # holds on the native verdict alone, but each trigger records a provider
+    # error. `smith judge preflight` reports the name it looked for and never
+    # the value it found, so it is safe to run anywhere.
+    #
+    # `auto`, not `true`, for the same reason codex is: this file is checked in
+    # and the key is a fact about one box. A box holding the key gets a second
+    # vendor; a box without one -- CI included -- silently gets none, and
+    # neither has to edit this line.
+    #
+    # Funded for THIS box, 2026-09-04, by the operator who owns the key.
+    enabled: auto
+    # `shadow`, deliberately, and the difference from codex above is the point:
+    # this box declined shadow for codex and chose it here. A shadow provider
+    # is still called and still recorded as a participant -- it forfeits only
+    # gating power -- so what the mode buys is a run of recorded disagreement
+    # to read before a second vendor gets a vote (docs/runbooks/providers.md
+    # §3). Promote by editing this to `active`; that is the calibration pass,
+    # and it is an operator decision, not a default.
+    mode: shadow
+
+quorum_triggers:
+  # architecture §6, agent-constraints.md "cross-check (phase 8)" — all four,
+  # nothing more.
+  - any S1/S2 finding, before it blocks a task
+  - epic-level final verdict, before the integration PR opens
+  - same-mistake findings (judgment.same-mistake)
+  - planner verdicts below the confidence threshold
+
+plan_quorum:
+  # architecture §6 "Plan quorum" — critique-only, never committee writes.
+  triggers:
+    - epic budget ≥ 50% of budgets.yml per-epic cap
+    - epic case is infra, or carries a security-sensitive tag
+    - planner verdict confidence below threshold
+  judges: 2 providers distinct from the planner's
+  on_disagreement: surface both rationales to the operator with the plan
+  # Machine-readable form of the three triggers above, read by
+  # src/crosscheck.ts's parsePlanQuorum() -> src/planQuorum.ts's
+  # evaluatePlanQuorumTriggers(). The prose above is the human contract;
+  # these fields are what the code actually gates on.
+  budget_ratio: 0.5 # trigger 1: sum(plan.tasks[].budget.tokens) >= this * budgets.yml epic.cap_tokens
+  # Same line task-spec.schema.json's `confidence` field and scheduler.yml's
+  # maintenance.auto_schedule_confidence both draw (>=0.8 auto-schedules).
+  # Repeated here (not imported) because this is a crosscheck trigger, not a
+  # scheduling decision — the two policies are allowed to diverge later.
+  confidence_threshold: 0.8 # trigger 3
+  security_cases: [infra] # trigger 2, taxonomy.yml `case` vocabulary
+  security_roles: [security-reviewer] # trigger 2, taxonomy.yml `agent` vocabulary
+  # trigger 2's third arm: contract.nonfunctional_clauses text matched
+  # case-insensitively as a substring (task-spec.schema.json has no `tags`
+  # field to check instead).
+  security_keywords:
+    - auth
+    - authz
+    - authentication
+    - authorization
+    - credential
+    - secret
+    - token
+    - password
+    - crypto
+    - encryption
+    - tls
+    - injection
+    - xss
+    - csrf
+    - sandbox
+    - permission
+    - privilege
+    - sanitize
+    - escalation
+
+quorum_rule:
+  agreement: "2-of-3"
+  min_providers: 2
+  tie_break: a third provider breaks the tie, or the case escalates to the
+    operator with both rationales side by side.
+  # This box promotes exactly one external judge (see providers.codex), and one
+  # cannot meet min_providers 2. On a finding claude raised — which is nearly
+  # all of them, since gate.ts defaults a finding's finder to the native
+  # provider — claude is excluded as the finder, the gating pool is [codex]
+  # alone, and the case escalates for insufficient-providers just as it did
+  # before the promotion, now having paid for the call.
+  #
+  # Set true because that is still the better trade here, not because the
+  # arithmetic is in doubt: the escalation now carries a second model's
+  # rationale instead of none, and the day a second provider is enabled the
+  # pool meets the rule with no further edit. What it buys today is a human
+  # deciding with two opinions in front of them rather than one — which is the
+  # whole point of the file — not an automatic override.
+  #
+  # It silences one advisory in `smith judge preflight` and nothing else. A
+  # provider enabled where it cannot be called is still a problem, and
+  # `gating.canDecide` still reports false, because it is false.
+  accept_non_gating_actives: true
+
+asymmetric_roles:
+  finder_ne_critic: true
+  critic_mandate: refute, not confirm
+  # The machine-readable form of finder_ne_critic (P9-23). Each pair says
+  # "this critic must not run on that finder's own model"; `smith dispatch
+  # check <session>` asserts it against the event log after the fact, using
+  # the `model` field every dispatch_decision now carries. Without this list
+  # the rule was unenforceable prose: it named no roles.
+  pairs:
+    - finder: planner
+      critic: spec-reviewer
+    - finder: reviewer
+      critic: verifier
+  note: >
+    adversarial stage-gating is expected to kill most candidate findings
+    before they cost a round-trip (Refute-or-Promote, §17); reviewer quality
+    is tracked as kill-rate (findings that survive verification and land as
+    verified fixes), never findings volume.
+
+role_isolation:
+  # The other half of "a worker never grades its own work". `finder_ne_critic`
+  # above compares MODELS, which is the wrong question for a tester: a tester
+  # may legitimately run on the coder's model, and forcing a second vendor onto
+  # it would buy nothing. What it may not do is run inside the coder's own
+  # turn — a coder that writes its own tests grades itself, and every gate
+  # downstream still goes green.
+  #
+  # The only evidence of a separate turn the event log can hold is a separate
+  # `dispatch_decision`, written by the node that dispatched, never by an agent
+  # about itself. `smith tester check <session>` asserts that against the log
+  # after the fact, per `testgate-result`.
+  #
+  # That reading survives delegation.yml granting `Agent` because of what the
+  # grant costs: a grantee must open its own session first, so its dispatches
+  # are its own log's, and no grant may hand a role its own auditor from the
+  # `pairs` below. `smith delegation check` enforces both, which is what keeps
+  # a widened grant from quietly disarming this file.
+  #
+  # One entry, and it is meant to stay one until a second role starts grading
+  # work it could have written: every other grader in the pipeline is a judge,
+  # and a judge cannot write at all (`role_write_scopes` in guardrails.yml).
+  pairs:
+    - worker: coder
+      auditor: tester
+  note: >
+    the audit answers "was a tester dispatched separately, and did it report,
+    before this task's tests were graded?" — not "did that tester write the
+    tests". Nothing in the log distinguishes a test file the tester authored
+    from one it merely ran; `role-write-scope` fences where a leased tester may
+    write, and the two checks are complementary, not substitutes.
+
+independent_finder:
+  # Everything else on this page is SUBTRACTIVE. quorum.ts's vocabulary is
+  # `confirm | refute`, a critic is handed one claim and told to kill it, and
+  # the strongest thing a quorum can do is drop a finding the native reviewer
+  # already raised. That makes the external tier a brake and never an eye: a
+  # bug the native reviewer's context did not surface is a bug no amount of
+  # cross-checking will ever reach, because nothing outside that context is
+  # ever asked to look.
+  #
+  # This block is the other direction. A finder from a different vendor reads
+  # the same diff in a fresh context, returns its own evidence, and
+  # crossFinding.ts reconciles the two lists. A quorum can now RAISE.
+  #
+  # Three things it deliberately does not do:
+  #
+  # 1. Silence is not a refutation. A native finding the independent finder did
+  #    not raise stays exactly as it was. The finder was never asked about that
+  #    claim — it was asked to read a diff — so its not mentioning something is
+  #    absence of evidence. Subtracting on it would let a lazy or truncated
+  #    second opinion delete real findings.
+  # 2. Same file and category with different wording is not the same finding.
+  #    That is `co-located`: recorded for the operator, never merged and never
+  #    auto-raised, because nothing here can tell one bug described twice from
+  #    two bugs in one function.
+  # 3. An independent-only finding is minted, not privileged. It enters the
+  #    gate as an ordinary finding and, at S1/S2, meets the same
+  #    `quorum_triggers` critic as any other — so a third-party vendor's
+  #    unshared opinion still has to survive a refute pass before it blocks.
+  enabled: false     # ships off: this is the one judge call that costs a diff
+  mode: shadow       # reconciliations are recorded and gate nothing; flip to `active` only after a calibration pass (docs/runbooks/providers.md)
+  # No code default: crosscheck.ts falls back to an EMPTY list, so this line is
+  # the only place a vendor is ever chosen. Delete it and the finder refuses by
+  # name rather than picking one for you.
+  providers: [codex] # must be external and must not be the native provider — a "second opinion" from the same model is one opinion billed twice
+  # THE OPERATOR MANDATE. A critic judges a CLAIM, so quorum.ts can send the
+  # summary and the failure scenario and never the source. A finder cannot: it
+  # has nothing to read but the diff. Shipping worktree source to a third-party
+  # API is a decision no code in this repo has standing to make quietly, so it
+  # is a switch, it ships false, and `smith crossfind run` REFUSES rather than
+  # falling back to a diffless "find bugs" prompt that would invent findings.
+  send_diff: false
+  max_diff_bytes: 120000 # refuse rather than truncate: half a diff produces confident findings about code that is not there
+  # How a fingerprint both sides raised resolves when they disagree on how bad
+  # it is. `highest-wins` takes the worse of the two; `native-wins` keeps the
+  # native severity and records the disagreement without acting on it.
+  severity_resolution: highest-wins
+
+mechanical_oracles_first: >
+  wherever a deterministic check exists (schema validation, mutation
+  testing, coverage, type checks), it runs first and its verdict is final —
+  LLM judgment, cross-provider or not, is reserved for what machines can't
+  decide.
+
+trust_boundary: >
+  external providers judge; they never gain write access to worktrees or the
+  factory. Their findings are data, not commands. All external calls go
+  through the same event log and budget accounting as native dispatches.

package/factory/policies/delegation.yml

@@ -0,0 +1,44 @@
+# Blacksmith — who may hold `Agent` (dispatch topology, architecture §4)
+#
+# Every other policy here tunes how work is judged. This one decides who may
+# create work at all, so it lives in its own file: an operator widening a
+# provider list in crosscheck.yml should not be one keystroke away from
+# widening a dispatch grant.
+#
+# The rule the factory has always run on is "the dispatching node owns the
+# event log for what it dispatches" (docs/standards/agent-constraints.md).
+# Until D13 step 3 that was enforced by granting `Agent` to nobody, which also
+# capped an epic at one operator session. A grantee that opens its own session
+# with `smith session start <id> --continues <dispatch-event-id>` is a real
+# dispatching node with a real log, so the cap can lift without the rule
+# bending.
+#
+# What a grant may not do — asserted by `smith delegation check` and by
+# delegation.test.ts against the shipped files, so a widened grant fails CI:
+#
+#   - dispatch itself (a role that dispatches itself writes dispatches about
+#     itself, and `smith tester check` reads a second dispatch as proof of a
+#     second turn),
+#   - dispatch its own auditor from crosscheck.yml `role_isolation.pairs`
+#     (a coder that picks and prompts its own tester grades itself), or
+#   - dispatch its own critic from crosscheck.yml `asymmetric_roles.pairs`
+#     (a finder that picks its critic's model closes the tunnel-vision hole
+#     crosscheck.yml exists to open).
+#
+# `wave-runner` satisfies all three by construction: it is nobody's worker and
+# nobody's finder. It is the only grant, and it is meant to stay the only one
+# until a second role has an epic-shaped reason to outlive a window.
+
+version: 1
+
+grants:
+  wave-runner:
+    # One wave of `.claude/skills/bs/wave.md`, steps 2-10. Not planner and not
+    # spec-reviewer: planning is the epic tier's, and a wave that could re-plan
+    # itself could plan its way out of the plan it was admitted under.
+    may_dispatch: [coder, tester, grader, reviewer, verifier,
+                   security-reviewer, uiux, researcher, merger, scribe]
+    # The whole point. A wave-runner that dispatches without opening a log
+    # writes its wave's dispatches into the epic's log under its own name, and
+    # every check that reads a dispatch as a separate turn starts lying.
+    must_open_session: true