Merge remote-tracking branch 'origin/main' into feat/for-each-item-injection

# Conflicts:
#	apps/fabro-web/app/components/stage-renderers/parallel-children.tsx

.chisel/calibration/calibration.md

@@ -0,0 +1,144 @@
+# Chisel Quality Calibration
+
+Calibration v1 · cartography v1 · revision `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c` · 2026-07-27T15:55:07Z
+Sample: `fabro-workflow`, `fabro-http`, `fabro-web-app`, `repository-ci` · Control: `fabro-checkpoint` at `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+Evaluators: GPT-5 (Codex primary and independent reviewers)
+
+## How to Use This Calibration
+
+Judge each mapped component against its purpose and direct repository evidence.
+Do not grade on a curve. Apply one score per lens, and count a finding under
+only its primary lens.
+
+**Isolated** means contained at an edge; normal callers and routine changes do
+not encounter it. **Central** means part of a mapped entry point, common path,
+or recurring change. A **routine change** is an ordinary extension or
+maintenance task implied by the component's mapped purpose.
+
+Infer routine work from the mapped purpose and traced common paths; a public
+method alone does not establish frequency. A directly evidenced central concern
+caps the component's lens score rather than being averaged against healthier
+sub-responsibilities. Necessary delegation inside a clear owner is not pressure,
+and size or internal busyness alone does not lower ownership.
+
+Use **N/E** when evidence is insufficient. Never convert missing evidence into
+a numeric score, and do not penalize a missing lifecycle path without evidence
+that the mapped purpose requires it. Score 4 requires a positive production
+mechanism and no material friction; tests may corroborate that mechanism but
+cannot create it or become a second authority merely by asserting its contract.
+
+## Lenses
+
+### `ownership-boundaries` — Ownership and boundaries
+
+**Does each responsibility and lifecycle have a clear home, with dependencies
+pointing in the intended direction?** Includes responsibility, state, resource,
+dependency, and lifecycle placement; excludes local control flow, naming,
+types, API meaning, and repeated policy alone.
+
+### `simplicity` — Simplicity
+
+**Is the implementation no more complex, indirect, or general than necessary?**
+Includes common-path traceability, control flow, indirection, abstraction, and
+configuration burden; excludes placement, domain meaning, and independently
+repeated knowledge.
+
+### `domain-model` — Domain model
+
+**Does each domain concept have one clear meaning and valid shape?** Includes
+types, terminology, legal states, conversions, validation, and API semantics;
+excludes module placement, lifecycle ownership, and repetition preserving one
+meaning.
+
+### `duplication-knowledge` — Duplication of knowledge
+
+**Are policies, invariants, decisions, and transformations authoritative rather
+than repeated?** Includes semantic repetition and manual synchronization;
+excludes harmless syntax, coincidental similarity, and unification that would
+create a parameterized mega-abstraction.
+
+## Observable Anchors
+
+| Score | Ownership and boundaries | Simplicity | Domain model | Duplication of knowledge |
+|---:|---|---|---|---|
+| 4 | One owner contains the mapped responsibility's state and complete lifecycle. | A production mechanism makes the necessary common path directly traceable. | Canonical types reject invalid states before every common-path interpretation. | One authoritative mechanism enforces each recurring policy, invariant, or transformation. |
+| 3 | Ownership friction is isolated outside routine changes. | Unnecessary indirection is isolated outside routine changes. | Meaning or validation friction is isolated outside routine changes. | Repeated knowledge is isolated outside routine changes. |
+| 2 | Routine changes coordinate competing owners or reverse the mapped dependency direction. | Routine changes repeatedly navigate competing paths, avoidable layers, or configuration machinery. | Routine changes reconcile recurring meanings, conversions, or invalid intermediate states. | Routine changes manually synchronize the same policy, invariant, or transformation across recurring locations. |
+| 1 | No stable owner or dependency direction can be identified for the responsibility. | No stable common path can be traced through the implementation. | No stable meaning or legal shape can be identified for a core concept. | No stable authority can be identified for recurring domain knowledge. |
+
+## Decision Rules
+
+1. A directly evidenced central concern caps the component's lens score; do not average it against healthier sub-responsibilities.
+2. Judge ownership against the map, not type names; when routine callers reconstruct a mapped lifecycle from low-level primitives, ownership fits 2.
+3. A check owns trigger coverage for every path it scans; non-triggering routine targets are ownership pressure, while nonexistent selector values are domain-model pressure.
+4. An unused production dependency or parallel entry layer is isolated simplicity friction, capping 4 at 3 when the common path remains direct.
+5. Caller validation or a typed destination does not isolate an invalid-capable mapped entry; routine common-path use of that shape fits 2.
+6. Concrete second semantic representations cap 4 at 3; score 2 only when an ordinary mapped change must synchronize them, not merely because call sites repeat.
+
+## Confidence
+
+Confidence describes evidence quality, not severity. **High** requires direct
+evidence across relevant common and boundary paths; final High also requires
+independent readings to converge. **Medium** has a material ambiguity or
+coverage gap. **Low** is partial or substantially inferential.
+
+## Classifying a Finding
+
+- Where should this responsibility or lifecycle live? → `ownership-boundaries`
+- Why is this much machinery necessary? → `simplicity`
+- What does this name, type, state, or API value mean? → `domain-model`
+- Why is this knowledge authoritative in several places? → `duplication-knowledge`
+
+Tags are diagnostic metadata, not additional scores:
+
+```text
+abstraction-burden   boundary-leakage      configuration-sprawl
+control-flow         conversion-sprawl     dependency-direction
+generality           indirection           invalid-states
+lifecycle            misplaced-responsibility
+ownership            repeated-invariant    repeated-policy
+repeated-test-knowledge                    repeated-transformation
+state-coupling       type-sprawl           vocabulary-drift
+```
+
+## Repository Examples
+
+### `ownership-boundaries`
+
+- `lib/components/fabro-workflow/src/lifecycle/mod.rs:WorkflowLifecycle` shows a central orchestrator can own callback order through focused delegates; reviewers must still inspect terminal paths before calling lifecycle ownership contained.
+- `apps/fabro-web/app/lib/api-client.ts:apiData` and `apps/fabro-web/app/lib/queries.ts:useRun` keep shared transport and read lifecycles out of route composition; a busy route alone is not boundary leakage.
+
+### `simplicity`
+
+- `lib/foundation/fabro-http/src/lib.rs:define_builder!` makes async and blocking construction traceable through one necessary mechanism; local macro indirection can reinforce simplicity.
+- `lib/components/fabro-workflow/src/operations/start.rs:RunSession::run` exposes a linear phase sequence, while service reshaping across phase inputs shows that a stable path can still carry recurring machinery.
+
+### `domain-model`
+
+- `lib/components/fabro-workflow/src/event/events.rs:Event::StageCompleted` uses string status before `lib/components/fabro-workflow/src/event/convert.rs:stage_status_from_string` reparses it; a typed durable result does not isolate this common-path intermediate.
+- `lib/foundation/fabro-http/src/lib.rs:ProxyPolicy` and `ProxyPolicy::resolve_with_env_value` demonstrate a closed policy vocabulary whose invalid boundary values are rejected.
+
+### `duplication-knowledge`
+
+- `lib/components/fabro-workflow/src/event/names.rs:event_name` and `lib/components/fabro-workflow/src/event/convert.rs:event_body_from_event` show manual mappings that a routine event extension must synchronize, even when exhaustive matches detect omissions.
+- `.github/workflows/rust.yml:on.push.paths` and `.github/workflows/rust.yml:on.pull_request.paths` demonstrate duplicated trigger knowledge: one source-area change requires two manual policy edits.
+
+## Control Baseline
+
+`fabro-checkpoint` at `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`:
+
+| Lens | Score | Confidence |
+|---|---:|---|
+| Ownership and boundaries | 2 | High |
+| Simplicity | 3 | High |
+| Domain model | 2 | Medium |
+| Duplication of knowledge | 3 | Medium |
+
+## Recalibration Triggers
+
+Recalibrate only for a rubric change, a material cartography change, a model
+change with demonstrated drift, or inconsistent scores on the control sample.
+
+## Open Questions
+
+None.

.chisel/calibration/work/adjudication.md

@@ -0,0 +1,249 @@
+# Calibration Adjudication
+
+Revision: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+
+Cartography: v1 at `2bcf94fed8a9b429f18d9196fa824711d6f4cb0a`.
+The only later commit adds cartography artifacts, so the mapped code paths are
+unchanged at the assessed revision.
+
+Sample: `fabro-workflow`, `fabro-http`, `fabro-web-app`, `repository-ci`.
+Control: `fabro-checkpoint`.
+
+## Independent Score Matrix
+
+Cells list reviewer 1 / reviewer 2 / reviewer 3.
+
+| Component | Ownership and boundaries | Simplicity | Domain model | Duplication of knowledge |
+|---|---:|---:|---:|---:|
+| `fabro-workflow` | 2 / 3 / 4 | 2 / 2 / 2 | 2 / 3 / 2 | 2 / 2 / 2 |
+| `fabro-http` | 4 / 4 / 4 | 4 / 4 / 4 | 4 / 3 / 4 | 3 / 4 / 4 |
+| `fabro-web-app` | 4 / 4 / 3 | 2 / 2 / 2 | 2 / 2 / 2 | 2 / 2 / 2 |
+| `repository-ci` | 4 / 4 / 3 | 3 / 3 / 3 | 2 / 3 / 2 | 2 / 2 / 2 |
+
+Unanimous pairs establish that central machinery may still have a stable path:
+`fabro-workflow` is 2 for simplicity and duplication; `fabro-web-app` is 2 for
+simplicity, domain model, and duplication; and `repository-ci` is 3 for
+simplicity and 2 for duplication. `fabro-http` is unanimously 4 for ownership
+and simplicity.
+
+## Material Disagreements
+
+### `fabro-workflow` × ownership and boundaries — 2 / 3 / 4
+
+- **Evidence:** `pipeline/mod.rs` and `pipeline/types.rs` give the normal run
+  explicit phase owners; `lifecycle/mod.rs:WorkflowLifecycle` owns callback
+  ordering through focused delegates.
+- **Counterevidence:** terminal completion and failure are also constructed in
+  `pipeline/finalize.rs:build_terminal_event`,
+  `operations/start.rs:emit_workflow_run_failed`,
+  `operations/start.rs:persist_terminal_engine_failure`, completion/drop
+  guards, retry, and archive operations.
+- **Ambiguous rule:** two reviewers judged the clear normal path; one judged
+  whether the same lifecycle has one home across normal and exceptional paths.
+- **Discriminator:** inspect every recurring terminal path. A routine
+  terminal-contract change crossing several operation owners is score-2
+  ownership pressure even when the success path is well partitioned.
+- **Draft adjudication:** 2.
+
+### `fabro-workflow` × domain model — 2 / 3 / 2
+
+- **Evidence:** `pipeline/types.rs` encodes phase states and canonical product
+  records are reused.
+- **Counterevidence:** `event/events.rs:Event::StageCompleted` carries a string
+  status; `lifecycle/event.rs:EventLifecycle::after_node` serializes a typed
+  outcome and `event/convert.rs:stage_status_from_string` reparses it with an
+  unknown-value fallback.
+- **Ambiguous rule:** whether a typed durable event isolates an invalid
+  intermediate representation on the common producer path.
+- **Discriminator:** common-path invalid intermediate states are central even
+  when the durable result is typed.
+- **Draft adjudication:** 2.
+
+### `fabro-http` × domain model — 4 / 3 / 4
+
+- **Evidence:** `ProxyPolicy`, `resolve_with_env_value`, and
+  `HttpClientBuildError` form a closed policy with explicit precedence and
+  rejection.
+- **Counterevidence:** public builders expose both
+  `proxy_policy(ProxyPolicy::Disabled)` and lower-level `no_proxy()`.
+- **Ambiguous rule:** whether a lower-level transport control creates a second
+  meaning for the repository policy.
+- **Discriminator:** an escape hatch does not split the canonical concept when
+  the typed policy remains closed and its precedence is enforced.
+- **Draft adjudication:** 4.
+
+### `fabro-http` × duplication of knowledge — 3 / 4 / 4
+
+- **Evidence:** `define_builder!` is the shared async/blocking authority and
+  `ProxyPolicy::resolve` owns precedence.
+- **Counterevidence:** adding a policy variant synchronizes the enum, parser,
+  expected-value error text, behavior match, and tests.
+- **Ambiguous rule:** whether co-location and exhaustive matching make all
+  policy vocabulary authoritative.
+- **Discriminator:** hypothetical variants do not establish routine
+  recurrence; exhaustive compiler-checked behavior remains one authority
+  unless direct evidence shows recurring manual synchronization.
+- **Draft adjudication:** 4.
+
+### `fabro-web-app` × ownership and boundaries — 4 / 4 / 3
+
+- **Evidence:** `entry.tsx`, route graphs, `lib/api-client.ts`, queries,
+  mutations, effect hooks, and the build script give shared responsibilities
+  visible homes.
+- **Counterevidence:** `install-app.tsx` and `routes/run-stages.tsx` contain
+  several central transformations and presentation concerns.
+- **Ambiguous rule:** whether a busy but clearly identified route owner is
+  boundary pressure or simplicity pressure.
+- **Discriminator:** do not lower ownership for internal complexity unless
+  routine changes cross another owner or reverse the mapped dependency
+  direction.
+- **Draft adjudication:** 4.
+
+### `repository-ci` × ownership and boundaries — 4 / 4 / 3
+
+- **Evidence:** Rust and TypeScript workflows have distinct validation jobs,
+  narrow permissions, and delegate build procedures to repository commands.
+- **Counterevidence:** the Rust clippy job embeds the repository's legacy-auth
+  vocabulary check.
+- **Ambiguous rule:** whether enforcement of a product migration invariant is
+  misplaced when CI owns validation but not the underlying vocabulary.
+- **Discriminator:** a named invariant check may live in CI, but its product
+  vocabulary must remain authoritative elsewhere; this isolated boundary
+  friction fits 3.
+- **Draft adjudication:** 3.
+
+### `repository-ci` × domain model — 2 / 3 / 2
+
+- **Evidence:** job, runner, permission, and test-mode vocabulary is otherwise
+  coherent.
+- **Counterevidence:** `rust.yml:on.*.paths` names nonexistent `openapi/**`
+  rather than `docs/public/api-reference/fabro-api.yaml`, and
+  `zizmor.yml:rules.stale-action-refs.ignore` identifies exceptions by stale
+  line positions.
+- **Ambiguous rule:** whether configuration references are domain vocabulary
+  or only duplicated operational data.
+- **Discriminator:** identifiers that control central behavior are domain
+  vocabulary; missing or stale referents create score-2 pressure.
+- **Draft adjudication:** 2.
+
+## Draft Anchor Decisions
+
+- Anchor score 4 on a positive enforcing mechanism, never absence of a defect.
+- Separate owner clarity from the amount of machinery inside that owner.
+- Treat invalid common-path intermediate states as domain-model pressure.
+- Treat repeated semantic decisions as duplication only when routine changes
+  require manual synchronization.
+- Treat mapped configuration identifiers as domain vocabulary.
+- Reserve N/E for a lens without direct evidence; no sampled pair required it.
+
+## Consistency Review
+
+The fresh reviewer applied only the written draft to `fabro-checkpoint` and
+reported:
+
+| Lens | Score | Evidence confidence |
+|---|---:|---|
+| Ownership and boundaries | 2 | Medium |
+| Simplicity | 3 | High |
+| Domain model | 2 | High |
+| Duplication of knowledge | 2 | High |
+
+The control exposed four material wording problems:
+
+1. The draft did not say how a component-level score combines several
+   responsibilities, or whether positive mechanisms and friction can coexist
+   at score 4.
+2. Necessary layered delegation could satisfy the original ownership and
+   simplicity score-2 wording.
+3. The domain rules did not say when a public low-level API is an escape hatch
+   or what score a common invalid intermediate implies.
+4. Decision rule 5 contradicted the duplication anchor by assigning routine
+   string synchronization to score 3.
+
+The revision now says that a central concern caps rather than averages, score 4
+requires a positive production mechanism without material friction, public
+surface alone does not establish routine work, and missing paths are not
+negative without mapped-purpose evidence. The anchors now distinguish competing
+owners from necessary delegation and maintainer navigation from runtime
+layering. Decision rules 2–6 resolve scoped lifecycle handoff, necessary
+delegation, common-path invalid states, direct evidence of recurring
+synchronization, and configuration identifiers. Tests corroborate production
+authorities but are not second authorities merely because they restate a
+contract.
+
+All 16 wording observations in `consistency-review.md` are covered by those
+changes or by the existing primary-lens and confidence sections. No consistency
+objection remains open before validation.
+
+## Validation
+
+### Round 1
+
+| Assignment | Validator 1 | Validator 2 | Validator 3 | Result |
+|---|---:|---:|---:|---|
+| `fabro-workflow` × ownership | 2 | 2 | 2 | Resolved |
+| `fabro-workflow` × domain | 2 | 2 | 2 | Resolved |
+| `fabro-http` × domain | 4 | 4 | 4 | Resolved |
+| `fabro-http` × duplication | 4 | 4 | 3 | Repeated adjacent split |
+| `fabro-web-app` × ownership | 4 | 4 | 4 | Resolved |
+| `repository-ci` × ownership | 4 | 2 | 4 | Non-adjacent split |
+| `repository-ci` × domain | 2 | 2 | 2 | Resolved |
+| Control × ownership | 2 | 4 | 2 | Non-adjacent split |
+| Control × simplicity | 4 | 4 | 3 | Adjacent split |
+| Control × domain | 2 | 3 | 2 | Adjacent split |
+| Control × duplication | 3 | 2 | 3 | Adjacent split |
+
+The sample's workflow lifecycle, event status, HTTP policy model, web
+composition, and CI identifier anchors now converge. Six assignments require
+the permitted final simplification:
+
+- HTTP diagnostic allowed-value text is a concrete second semantic
+  representation, even though the macro is the behavioral authority.
+- A CI check owns trigger coverage for every path its embedded policy scans;
+  this is distinct from the domain meaning of a nonexistent selector.
+- Control ownership is judged against the mapped metadata-branch purpose, not
+  against narrower names on `Store` and `BranchStore`.
+- The control's unused dependency and unused parallel entry layer are isolated
+  simplicity friction rather than evidence-free public breadth.
+- Validation in an external caller does not make an invalid-capable mapped
+  entry type enforce its own legal shape.
+- Repeated fixed Git protocol syntax is a concrete second representation, but
+  multiple current call sites alone do not make changing that protocol an
+  ordinary mapped change.
+
+Decision rules 2–6 now state those discriminators directly. Round 2 will
+re-score only the six unresolved assignments.
+
+### Round 2
+
+| Assignment | Validator 1 | Validator 2 | Validator 3 | Result |
+|---|---:|---:|---:|---|
+| `fabro-http` × duplication | 3 | 3 | 3 | Resolved |
+| `repository-ci` × ownership | 2 | 2 | 2 | Resolved |
+| Control × ownership | 2 | 2 | 2 | Resolved |
+| Control × simplicity | 3 | 3 | 3 | Resolved |
+| Control × domain | 2 | 2 | 2 | Resolved |
+| Control × duplication | 3 | 3 | 3 | Resolved |
+
+All round-2 scores converge. The final control baseline is ownership 2
+(High), simplicity 3 (High), domain model 2 (Medium), and duplication of
+knowledge 3 (Medium). Domain confidence remains Medium because one validator
+found a material ambiguity over whether low-level Git path validation belongs
+inside the component. Duplication confidence remains Medium because stable
+protocol syntax is concrete repetition but has limited demonstrated change
+burden.
+
+Across both validation rounds, the final disputed sample scores are:
+
+| Component | Ownership and boundaries | Domain model | Duplication of knowledge |
+|---|---:|---:|---:|
+| `fabro-workflow` | 2 | 2 | — |
+| `fabro-http` | — | 4 | 3 |
+| `fabro-web-app` | 4 | — | — |
+| `repository-ci` | 2 | 2 | — |
+
+No non-adjacent or repeated adjacent split remains.
+
+## Open Questions
+
+None.

.chisel/calibration/work/consistency-review.md

@@ -0,0 +1,112 @@
+# Chisel Consistency Review: `fabro-checkpoint`
+
+Revision: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+
+Scope: `lib/components/fabro-checkpoint/**` only. The scored evidence is the manifest, production source, and unit tests at the pinned revision. I did not inspect callers, sample reviews, adjudication, or any other file under `.chisel/calibration/work/`.
+
+## Scores
+
+| Lens | Score | Confidence |
+|---|---:|---|
+| `ownership-boundaries` | 2 | Medium |
+| `simplicity` | 3 | High |
+| `domain-model` | 2 | High |
+| `duplication-knowledge` | 2 | High |
+
+Confidence here describes this reading's evidence quality. The rubric's additional requirement that a final High confidence needs independent convergence can only be decided during adjudication.
+
+## `ownership-boundaries`: 2
+
+The central branch lifecycle crosses two public owners. `BranchStore` stores the branch name and owns bootstrap plus normal branch reads and writes (`branch.rs:20-209`), but branch cleanup is exposed only as `Store::delete_ref(branch)` (`git.rs:215-226`). `BranchStore` keeps both its `Store` reference and branch name private and has no cleanup/archive operation. A caller therefore has to retain the same raw branch identity and leave the branch-scoped interface for cleanup. Bootstrap sequencing is also caller-owned: `BranchStore::new` does not establish the branch, writes fail when it is absent, and every writable test explicitly calls `ensure_branch` first (`branch.rs:26-81, 282-343`). This is recurring lifecycle work rather than an isolated edge, especially under decision rule 1. Primary tags: `lifecycle`, `ownership`.
+
+Strongest counterevidence: once initialized, `BranchStore::write_with` keeps the read-modify-write sequence together and delegates only Git object/ref primitives to `Store` (`branch.rs:56-82`). The dependency direction is stable: branch storage depends on the lower-level Git store, not vice versa.
+
+Why adjacent scores do not fit:
+
+- **1 does not fit:** `BranchStore` is a stable, identifiable owner for the common branch-scoped read/write responsibility, and `Store` is a coherent lower-level Git owner.
+- **3 does not fit:** the split includes explicit bootstrap and cleanup paths. Decision rule 1 says recurring terminal ownership cannot be treated as isolated merely because the success path is clear.
+
+Confidence is Medium because the split is direct, but the scoped evidence cannot show whether archive, retry, and cleanup are deliberately owned by a higher-level caller.
+
+## `simplicity`: 3
+
+The common write path is directly traceable: `write_entry`/`write_entries` prepare blobs, `write_with` reads the tip tree, applies one mutation, writes one commit, and advances one ref (`branch.rs:56-109`). `Store::read_tree` and `Store::write_tree` use a single flat `TreeEntries` representation with private recursive helpers (`git.rs:39-99, 141-159, 229-310`). These are positive reinforcing mechanisms, not just an absence of complexity.
+
+The remaining simplicity pressure is isolated configuration burden. The manifest declares `fabro-store`, `serde`, and the dev dependency `chrono` (`Cargo.toml:16-28`), but none is referenced anywhere in the component source or tests at this revision. The public `Store::repo` escape hatch (`git.rs:112-114`) and the lower-level object API also add surface area, but normal branch writes do not have to choose among competing implementations. Primary tag: `configuration-sprawl`.
+
+Strongest counterevidence to lowering the score: the component has one linear common mutation path, and its indirection corresponds directly to Git's blob/tree/commit/ref structure.
+
+Why adjacent scores do not fit:
+
+- **2 does not fit:** ordinary reads and writes do not repeatedly traverse competing orchestration paths or configuration machinery; the `BranchStore` to `Store` layering is stable and direct.
+- **4 does not fit:** the centralized mutation path is a qualifying positive mechanism, but the unused manifest dependencies are concrete unnecessary configuration rather than necessary machinery.
+
+Confidence is High because all component files are in scope, so the dependency non-use and the full common write path are directly observable.
+
+## `domain-model`: 2
+
+The common tree-entry producer accepts invalid intermediate path states. `TreeEntries` hides its map, but its public `set` accepts any `Into<String>` without validating a relative Git path (`git.rs:46-61`). Both `BranchStore::write_entry` and `write_entries` feed caller-provided `&str` paths directly into it (`branch.rs:84-109`), and `build_dir_node` later assigns meaning by splitting the strings on `/` (`git.rs:270-294`). Empty components, leading/trailing separators, and file/directory prefix collisions are therefore representable in the canonical intermediate type and reach late Git-tree construction rather than being rejected at the common boundary. Branch identity is likewise an arbitrary `String` until `git2` receives the synthesized ref name (`branch.rs:20-38`, `git.rs:182-197`). This is central invalid-state pressure under decision rule 3, not an isolated low-level escape hatch. Primary tag: `invalid-states`.
+
+The small helper `sharded_path` is corroborating boundary evidence: its contract says the input is a hex ID, but its public signature accepts any `&str` and slices at a caller-provided byte offset (`branch.rs:211-220`), so a non-ASCII input can panic rather than be rejected as invalid input.
+
+Strongest counterevidence: `FileMode` is a closed enum and `TreeEntries` keeps ordering and representation private (`git.rs:13-99`). `Error` also distinguishes a missing branch from generic Git failures (`error.rs:5-18`). The component therefore has stable concepts even though common constructors do not preserve all their invariants.
+
+Why adjacent scores do not fit:
+
+- **1 does not fit:** branch storage, tree entries, file modes, authors, and trailers all have recognizable, stable meanings.
+- **3 does not fit:** raw paths and branch names enter the common public read/write boundary, so validation friction is not isolated outside routine use.
+
+Confidence is High because the accepting producers and their downstream interpretation are both visible within the scoped common path.
+
+## `duplication-knowledge`: 2
+
+The transformation “find a path in a commit tree, treat only `NotFound` as absence, load the entry as a blob, and copy its bytes” is independently implemented by `BranchStore::read_entry`, `BranchStore::read_entries`, and `Store::read_blob_at` (`branch.rs:119-158`, `git.rs:200-213`). An ordinary maintenance change to missing-entry or entry-kind behavior must synchronize all three common read locations. Ref qualification is also repeated in `update_ref`, `resolve_ref`, and `delete_ref` (`git.rs:182-226`).
+
+Trailer grammar supplies independent corroboration at the commit-message edge: `": "` formatting/detection is separately encoded by `append`, `parse`, `format_message`, and `has_trailing_trailer_block` (`trailer.rs:9-25, 28-42, 45-65, 68-87`). Primary tags: `repeated-transformation`, `repeated-policy`.
+
+Strongest counterevidence: important write knowledge is authoritative. `BranchStore::write_with` centralizes tip loading, parent linkage, commit creation, and ref advancement, while `GitAuthor::default` centralizes the fallback identity (`branch.rs:56-82`, `author.rs:13-35`).
+
+Why adjacent scores do not fit:
+
+- **1 does not fit:** the repeated implementations currently agree, and stable authorities exist for branch mutation, author defaults, and file-mode conversion.
+- **3 does not fit:** the repeated blob-read transformation appears on the public latest-entry and multi-entry common paths, so a routine storage-policy change encounters it centrally rather than only at an edge.
+
+Confidence is High because the repeated transformations and the mechanisms that are already centralized can both be enumerated completely inside the scoped component.
+
+## Rubric wording audit
+
+The following rules or anchors were ambiguous or non-discriminating in this application. I resolved each explicitly rather than silently choosing an interpretation.
+
+1. **One component score across several responsibilities.** The instruction says to judge “each mapped component,” while the anchors use singular phrases such as “a mapped responsibility” and “a core concept.” It does not say whether to average sub-responsibilities, take the worst concern, or weight by centrality. I scored the mapped checkpoint-storage responsibility and let a directly evidenced central concern cap the lens; isolated author/trailer helpers could affect a score only at 3 versus 4.
+
+2. **How to establish “routine” and “central” with component-only evidence.** A public method may be a mapped entry point without being frequent, and scoped evidence cannot establish caller frequency. I treated bootstrap, latest reads/writes, and cleanup as routine because they are ordinary lifecycle operations implied by branch storage. I did not infer frequency for unrelated external call sites.
+
+3. **N/E threshold versus an absent lifecycle path.** “Use N/E when evidence is insufficient” does not say whether a missing archive/retry API is negative evidence, out of scope, or grounds for N/E. I scored paths that are directly present (bootstrap, normal operation, cleanup), did not penalize an unobserved archive/retry design, and lowered ownership confidence for the coverage gap.
+
+4. **Score 3 and score 4 overlap in every lens.** A positive reinforcing mechanism can coexist with isolated friction, so the score-4 requirement and score-3 anchor can both be true. I treated any evidenced unnecessary/frictional mechanism as a cap at 3; score 4 requires both a positive mechanism and no material friction in the mapped responsibility. This is why the unused manifest dependencies keep simplicity at 3 despite `write_with`.
+
+5. **What qualifies as a “positive reinforcing mechanism.”** The rubric does not say whether tests, encapsulation alone, or a production authority qualifies. I required an operative production mechanism that funnels behavior or rejects invalid construction. Tests alone did not qualify.
+
+6. **Ownership score 2 versus ordinary delegation.** “Cross recurring owners or dependency boundaries” could penalize every layered implementation. Decision rule 2 partly resolves this, but “same responsibility” remains subjective. I treated `BranchStore` calling `Store` during a write as ordinary delegation; I counted cleanup only because the caller must leave the branch-scoped owner and supply its identity again.
+
+7. **Decision rule 1 when terminal operations live at a lower abstraction.** The rule says not to isolate recurring terminal owners but does not define whether a lower-level deletion primitive is a second owner or a delegate. Because `BranchStore` offers no cleanup interface and keeps the needed state private, I treated `Store::delete_ref` as a lifecycle-owner crossing, not merely internal machinery.
+
+8. **Simplicity score 2’s “repeatedly traverse.”** It is unclear whether this means runtime calls passing through multiple necessary layers, or maintainers choosing among competing paths repeatedly. I used the latter interpretation, consistent with the lens question and decision rule 2; necessary Git layers did not lower the score.
+
+9. **Decision rule 2’s “simplicity pressure.”** The rule labels machinery inside an owner as pressure even though the lens expressly permits necessary complexity and gives no score consequence for “pressure.” I treated machinery as evidence to test for necessity, not as an automatic deduction.
+
+10. **Domain score 4 versus decision rule 4’s escape hatch.** “Every common boundary” is not defined, and a public low-level API can be called common or an escape hatch depending on external usage. I treated `TreeEntries::set` as common because `BranchStore::write_with`, `write_entry`, and `write_entries` use it directly; `Store::repo` was treated as an escape hatch.
+
+11. **Decision rule 3 does not identify a score boundary.** It says a typed durable value does not “repair domain pressure,” but does not say whether a common invalid intermediate means 2 or merely prevents 4. I mapped common-path invalid intermediates to the score-2 anchor (“routine changes reconcile ... invalid intermediate states”); isolated invalid intermediates would map to 3.
+
+12. **Duplication score 2 versus decision rule 5.** Rule 5 says to score 3 when a routine vocabulary change requires synchronization, while the score-2 anchor says routine synchronization of the same policy/invariant/transformation is score 2. Those statements conflict unless “vocabulary” is an unstated special case. I treated rule 5 narrowly as an exception for localized, string-only vocabulary at an edge. The score-2 finding here rests instead on repeated behavioral blob-read transformations on common paths.
+
+13. **What test repetition counts as knowledge duplication.** The `repeated-test-knowledge` tag suggests tests can count, but the anchors do not distinguish duplicated policy from assertions that intentionally restate expected behavior. I did not count an assertion of a production contract as a second authority. Repeated test fixture setup was only isolated counterevidence and did not drive a numeric score.
+
+14. **Decision rule 6 lacks a lens and defines neither “current referent” nor “line selector.”** Its opening phrase points toward `domain-model`, while duplicated CI selectors could point toward `duplication-knowledge`; its mandatory score 2 also bypasses centrality analysis. It had no referent in this component, so I did not apply it. If applicable, I would classify a single invalid identifier under domain model and synchronized copies under duplication.
+
+15. **The “primary lens only” rule does not explain multi-causal facts.** Raw strings can simultaneously expose invalid states, repeat vocabulary, and force lifecycle handoffs. I assigned each negative fact once by its primary question: lifecycle handoff to ownership, unused dependencies to simplicity, raw path legality to domain, and repeated lookup/ref/trailer behavior to duplication.
+
+16. **Confidence High cannot be finalized by one reviewer.** “Final High also requires independent readings to converge” is not decidable during an independent review. I reported evidence-quality confidence now and left final convergence to adjudication.
+
+All other score-1 versus score-2 distinctions were discriminating here: the component consistently has identifiable owners, paths, concepts, and intended policies, so none of the “no stable ... can be identified” anchors fit.

.chisel/calibration/work/reviewer-1.md

@@ -0,0 +1,182 @@
+# Calibration review — reviewer 1
+
+Revision reviewed: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+
+Scope: `fabro-workflow`, `fabro-http`, `fabro-web-app`, and `repository-ci` as routed by `.chisel/cartography/codebase-map.md`. I excluded `apps/fabro-web/app/components/playground/**` from `fabro-web-app`, and limited `repository-ci` to `.github/workflows/rust.yml`, `.github/workflows/typescript.yml`, and `.github/zizmor.yml`. The routed paths have no changes between the map revision and the reviewed revision.
+
+## Provisional ratings
+
+| Component | Ownership boundaries | Simplicity | Domain model | Duplication of knowledge |
+| --- | --- | --- | --- | --- |
+| `fabro-workflow` | **2 — High** | **2 — High** | **2 — High** | **2 — High** |
+| `fabro-http` | **4 — High** | **4 — High** | **4 — High** | **3 — High** |
+| `fabro-web-app` | **4 — High** | **2 — High** | **2 — High** | **2 — High** |
+| `repository-ci` | **4 — High** | **3 — High** | **2 — High** | **2 — High** |
+
+## `fabro-workflow`
+
+### Ownership boundaries — 2, High confidence
+
+The component has a clear top-level phase boundary: `pipeline/mod.rs` orders parse, transform, validate, initialize, execute, finalize, and pull-request processing; `pipeline/types.rs` gives those phases distinct result types. `pipeline/execute.rs:execute`, `graph.rs:WorkflowGraph`, and `node_handler.rs:WorkflowNodeHandler` also make the boundary with the generic `fabro-core` executor explicit. `lifecycle/mod.rs:WorkflowLifecycle` composes named lifecycle owners instead of placing every callback in the executor.
+
+The pressure appears in terminal-run ownership. The normal path is owned by `pipeline/finalize.rs:finalize` and `pipeline/finalize.rs:build_terminal_event`, while engine/bootstrap failures are handled by `operations/start.rs:emit_workflow_run_failed`, `operations/start.rs:persist_terminal_engine_failure`, and the completion/drop guards in `operations/start.rs`. Retry and archive operations also synthesize terminal events in `operations/retry.rs` and `operations/archive.rs`. These paths are understandable individually, but terminal state, persistence, and event emission do not have one stable lifecycle home.
+
+A representative routine change is adding terminal metadata that must be present for every failed or concluded run. It would require checking or changing `pipeline/finalize.rs:build_terminal_event`, `pipeline/finalize.rs:finalize`, `operations/start.rs:emit_workflow_run_failed`, `operations/start.rs:persist_terminal_engine_failure`, the start-operation guards, and the corresponding terminal paths in `operations/retry.rs` and `operations/archive.rs`.
+
+Strongest counterevidence: the main successful-run path is explicit and strongly partitioned, and `WorkflowLifecycle` plus `RunServices` give many responsibilities named owners.
+
+Why adjacent scores do not fit: 3 understates the issue because terminal completion is a central lifecycle concern, not an edge-only exception; an ordinary terminal-contract change must inspect several authorities. 1 does not fit because the normal path and the exceptional paths are still traceable and deliberately named.
+
+### Simplicity — 2, High confidence
+
+The top-level flow is readable, but routine run startup crosses a large amount of central wiring. `operations/start.rs:start` enters `execute_persisted_run`, constructs `RunSession`, and then `RunSession::run` coordinates logging, SHA listeners, initialization, cleanup/drain guards, execution, finalization, and pull-request handling. `pipeline/types.rs:InitOptions` carries a large set of run inputs, and `operations/start.rs:RunSession::run` assembles them before handing control to `pipeline/initialize.rs`. The resulting services are then repartitioned through `services.rs:RunServices`, `services.rs:EngineServices`, and `pipeline/execute.rs:execute`.
+
+A representative routine change is adding a run-scoped service needed by node handlers. It would pass through `operations/start.rs:StartServices` or `RunSession`, `pipeline/types.rs:InitOptions`, `pipeline/initialize.rs:initialize`, `pipeline/types.rs:Initialized`, `services.rs:RunServices`, `services.rs:EngineServices`, and the destructuring/building in `pipeline/execute.rs:execute`.
+
+Strongest counterevidence: the phase result types in `pipeline/types.rs` and the extracted executor/lifecycle adapters make the long path navigable; the complexity is structured rather than accidental.
+
+Why adjacent scores do not fit: 3 does not fit because the pressure is on the common startup and execution path, and a small run-scoped dependency change propagates through several central handoff types. 1 does not fit because the ordered pipeline and named handoffs still provide a stable path through the component.
+
+### Domain model — 2, High confidence
+
+The strongest positive mechanism is the phase model in `pipeline/types.rs`: `Parsed`, `Transformed`, `Validated`, `Persisted`, `Initialized`, `Executed`, `Concluded`, and `Finalized` constrain which data exists at each stage. Canonical run records are reused from `fabro-types`, and `services.rs:RunServices` documents cancellation ownership.
+
+However, the core event path weakens those guarantees. `event/events.rs:Event::StageCompleted` carries `status: String`; lifecycle code such as `lifecycle/event.rs` converts `StageOutcome` to a string, and `event/convert.rs:stage_status_from_string` parses it back when creating the durable event. An unknown value is not rejected: it is warned about and converted to `StageOutcome::Failed`. The durable model in `fabro-types` is typed, but the internal central event model permits invalid status values and gives them a lossy fallback meaning. `WorkflowRunCompleted` similarly carries a string status internally.
+
+Strongest counterevidence: the durable event body and most run/pipeline records use named enums and phase-specific types, so this is not a component with generally unmodeled state.
+
+Why adjacent scores do not fit: 3 does not fit because stage and run outcomes are central workflow vocabulary used on every execution, and the internal-to-durable boundary permits and silently reinterprets invalid values. 1 does not fit because canonical typed outcomes exist and dominate downstream storage; the break is concentrated at the internal event boundary.
+
+### Duplication of knowledge — 2, High confidence
+
+Adding an event requires coordinated knowledge in several central authorities. The internal variant lives in `event/events.rs:Event`; its wire name is separately selected by `event/names.rs:event_name`; durable fields are declared in `fabro-types::EventBody`; conversion is implemented in `event/convert.rs:event_body_from_event`; stored-field behavior is selected in `event/stored_fields.rs:stored_event_fields_for_variant`; and tracing behavior is implemented on `Event`. `docs/internal/events-strategy.md` documents this multi-site procedure, confirming that this is the expected recurring event-evolution path rather than a one-off remnant.
+
+A representative routine change is adding a persisted workflow event. It touches `event/events.rs:Event`, `event/names.rs:event_name`, the `Event` tracing method, `fabro_types::EventBody`, `event/convert.rs:event_body_from_event`, `event/stored_fields.rs:stored_event_fields_for_variant`, emitters, and any event consumers.
+
+Strongest counterevidence: `event/emitter.rs:Emitter::emit_with_scope` constructs the canonical run event once before dispatch, exhaustive matches make omissions visible to the compiler, and the strategy document gives maintainers one checklist.
+
+Why adjacent scores do not fit: 3 does not fit because event evolution is frequent, central workflow work and requires synchronized changes across representations and crates. 1 does not fit because each representation has a stated role and there is a single canonicalization point before dispatch.
+
+Lens-boundary note: the internal `Event`/durable `EventBody` split could be described as a domain-model issue or duplication. I treated the repeated declarations and conversion sites as duplication of knowledge; the separate `String`-to-`StageOutcome` loss of meaning is the domain-model issue. Likewise, repeated terminal constructors are secondary duplication, but I classified the primary problem as ownership because the key question is which operation owns terminal lifecycle completion.
+
+## `fabro-http`
+
+### Ownership boundaries — 4, High confidence
+
+`lib/foundation/fabro-http/src/lib.rs` is a small, focused owner for HTTP client construction and proxy policy. Callers get approved async or blocking builders and convenience clients from this crate. Repository lint policy in `clippy.toml` disallows direct `reqwest` constructors and points callers to `fabro-http`, so the boundary is reinforced rather than merely conventional. `ProxyPolicy::resolve` also owns the environment-variable authority through `fabro_static::EnvVars::FABRO_HTTP_PROXY_POLICY`.
+
+Strongest counterevidence: the crate deliberately re-exports several `reqwest` types and carries lint exceptions for those facade exports, so callers are not isolated from every transport detail.
+
+Why adjacent scores do not fit: 3 does not fit because construction policy, environment precedence, test defaults, and transport facade all have one enforced home with no observed competing builder authority.
+
+### Simplicity — 4, High confidence
+
+The common path is short: choose `HttpClientBuilder` or `BlockingHttpClientBuilder`, optionally configure it, resolve `ProxyPolicy`, and build the underlying client. `define_builder!` generates the shared async/blocking surface once, while the async-only `read_timeout` extension remains plainly visible next to the macro invocation. Convenience functions such as `http_client`, `blocking_http_client`, `test_http_client`, and `blocking_test_http_client` expose the common cases directly.
+
+Strongest counterevidence: macro generation means the two concrete builder implementations are not visible as ordinary source, and async-only options must be added outside the shared definition.
+
+Why adjacent scores do not fit: 3 does not fit because the macro removes rather than creates routine common-option work: a shared builder option is added in one readable location, while the generated types remain thin wrappers.
+
+### Domain model — 4, High confidence
+
+`ProxyPolicy` names the only supported policies, `ProxyPolicy::parse` rejects unknown values, and `ProxyPolicy::resolve_with_env_value` makes precedence explicit: a caller override wins, then the environment value, then the system default. Test helpers force `Disabled`, making local test semantics deliberate. `HttpClientBuildError` distinguishes policy configuration failure from transport construction failure.
+
+Strongest counterevidence: callers can express no-proxy behavior through both `proxy_policy(ProxyPolicy::Disabled)` and the lower-level `no_proxy()` builder method, and the facade re-exports lower-level proxy types.
+
+Why adjacent scores do not fit: 3 does not fit because the overlapping entry points do not introduce an ambiguous stored state or silent fallback: the policy values and their precedence are explicit, and invalid environment vocabulary fails closed.
+
+### Duplication of knowledge — 3, High confidence
+
+The builder macro is a strong anti-duplication mechanism for async and blocking clients. The remaining policy vocabulary is manually repeated: `ProxyPolicy` variants, `ProxyPolicy::parse`, the expected-value text in `HttpClientBuildError::InvalidProxyPolicy`, and the policy match in the generated `build` method must agree.
+
+A representative routine change is adding another supported proxy policy. It would touch `ProxyPolicy`, `ProxyPolicy::parse`, the expected-value message on `HttpClientBuildError::InvalidProxyPolicy`, the `define_builder!` build-time match, and policy tests in the same source file.
+
+Strongest counterevidence: every repeated policy decision is co-located in one small file, and the exhaustive build match makes a missing behavioral branch a compile error.
+
+Why adjacent scores do not fit: 4 does not fit because the accepted vocabulary and error vocabulary are independently maintained strings. 2 does not fit because the synchronization is confined to one authority and does not force routine callers or neighboring components to change.
+
+Lens-boundary note: macro use could be counted as simplicity indirection, but its primary effect here is eliminating async/blocking duplication. The generated control flow is small enough that I did not lower simplicity for it.
+
+## `fabro-web-app`
+
+### Ownership boundaries — 4, High confidence
+
+The app has explicit composition points. `app/entry.tsx` selects normal or install mode and installs shared providers; `app/router.tsx` and `app/install-router.tsx` own the two route trees. `app/lib/api-client.ts` owns generated-client construction and uniform API errors, `app/lib/query-keys.ts` owns cache keys, and `app/lib/queries.ts` owns shared reads. The React effects policy is embodied by approved wrappers in `app/hooks/effects.ts`; direct effect usage is concentrated in hooks and live-event libraries rather than route/component bodies. `scripts/build.ts` separately owns deterministic asset building and atomic publication.
+
+Strongest counterevidence: some cache mutation and API-write coordination remains in route handlers, particularly in the large run and installation screens, so not every server interaction passes through a single application-service layer.
+
+Why adjacent scores do not fit: 3 does not fit because routing, reads, client configuration, effects, and build publication each have a visible and consistently used owner; route-local writes are appropriate UI orchestration rather than a competing global authority.
+
+### Simplicity — 2, High confidence
+
+The normal routing shell is simple, but two central screens concentrate substantial policy and presentation. `app/routes/run-stages.tsx` combines event-to-turn reduction, event filtering, grouping, stage/activity interpretation, row and panel rendering, stage renderer selection, and the route page. `app/install-app.tsx` similarly combines installation state transitions, controller behavior, forms, and view composition. Cross-tab stream coordination in `app/lib/cross-tab-sse.ts` is another large central mechanism.
+
+A representative routine change is showing a new kind of stage activity in the run timeline. It requires following `app/lib/run-events.ts:STAGE_ACTIVITY_EVENT_TYPES`, `app/routes/run-stages.tsx:STAGE_ACTIVITY_EVENT_SET`, `app/routes/run-stages.tsx:buildStageActivity`, the route's turn/activity types, and the corresponding render helpers in the same large route module.
+
+Strongest counterevidence: shared event lists, query keys, generated API types, and route helpers provide landmarks, and the activity reducer is deterministic rather than dispersed among many components.
+
+Why adjacent scores do not fit: 3 does not fit because run-stage interpretation is a common product path and small presentation changes require navigating large modules that mix reduction and rendering concerns. 1 does not fit because the route and install flows remain typed, testable, and traceable from explicit entry points.
+
+### Domain model — 2, High confidence
+
+Generated API types provide a strong canonical model for ordinary request/response queries, and several local models use discriminated unions. The live-event boundary is weaker. `app/lib/sse.ts:EventPayload` permits an optional event name plus arbitrary fields. `app/lib/run-events.ts:RunEventPayload` and `app/lib/live-events.ts:LiveEventPayload` repeat mostly optional envelope fields with `properties: unknown`. `app/lib/sse.ts:subscribeToSharedEventSource` parses JSON and casts it to the requested payload type without runtime validation. Common live UI behavior therefore accepts payloads that lack the fields implied by their event names.
+
+There is additional vocabulary translation in `app/data/runs.ts:RunStatus`, which locally reproduces API run-state kinds and adds presentation state, and compatibility shape probing in `app/lib/run-sandbox-lifecycle.ts:sandboxLifecycleKind` and `sandboxInstance`.
+
+Strongest counterevidence: generated types remain the authority for normal API calls, `session-stream.ts` and query paths use generated event-envelope types where possible, and the local run status adds a genuine presentation concept rather than merely renaming every API state.
+
+Why adjacent scores do not fit: 3 does not fit because SSE drives common live run behavior and its central payload model makes invalid event/field combinations representable and unchecked. 1 does not fit because static generated models are sound and the weak representation is concentrated at live and compatibility boundaries.
+
+### Duplication of knowledge — 2, High confidence
+
+Live refresh policy is repeated in separate manually curated authorities. `app/lib/run-events.ts:RUN_SUMMARY_EVENTS` lists events that invalidate run summaries, while `app/lib/board-events.ts:BOARD_STATUS_EVENTS` independently lists many of the same run, interview, and pull-request lifecycle events for board refresh. The duplicated payload interfaces in `run-events.ts` and `live-events.ts` add another synchronization surface.
+
+A representative routine change is adding a lifecycle event that changes both a run summary and its board status. It requires updating `app/lib/run-events.ts:RUN_SUMMARY_EVENTS` and `app/lib/board-events.ts:BOARD_STATUS_EVENTS`, then checking phase derivation in `app/lib/run-phases.ts:deriveRunPhases` and live consumers if the event also changes the visible run phase.
+
+Strongest counterevidence: stage activity vocabulary is centralized in `app/lib/run-events.ts:STAGE_ACTIVITY_EVENT_TYPES` and imported by the run-stages route; query keys and server contract types are also centralized or generated.
+
+Why adjacent scores do not fit: 3 does not fit because the repeated invalidation lists govern common live behavior, and a missing update produces stale UI rather than a compile-time failure. 1 does not fit because each list has a clear local purpose and several other high-change vocabularies already have a single authority.
+
+Lens-boundary note: the repeated loose live-event interfaces are both duplicate declarations and a weak model. I treated representable invalid payloads and unchecked casts as the domain-model finding; I used independently maintained event-invalidation sets as the primary duplication finding. The size of `run-stages.tsx` is primarily simplicity pressure, not evidence that its route ownership is unclear.
+
+## `repository-ci`
+
+### Ownership boundaries — 4, High confidence
+
+`.github/workflows/rust.yml` and `.github/workflows/typescript.yml` have an explicit language split and named jobs for formatting, linting, generated documentation, tests, type checking, and builds. Each workflow sets narrow permissions, concurrency behavior is visible, and toolchain/action versions are pinned. The TypeScript build job's Rust build step has a clear purpose: verify the embedded production SPA through the repository's actual build command.
+
+Strongest counterevidence: the Rust clippy job contains a repository-specific legacy-auth `git grep` policy check, rather than delegating that policy to a named script or dedicated job.
+
+Why adjacent scores do not fit: 3 does not fit because the special check is still plainly owned by repository validation, while language-level checks, permissions, and production build validation have unambiguous homes and no competing workflow was observed.
+
+### Simplicity — 3, High confidence
+
+The workflows are short and linear, with direct commands corresponding to local development commands. Friction is isolated: setup steps are repeated across jobs, the clippy job embeds a multi-pattern shell assertion for legacy auth identity removal, and the ignored twin E2E selection is encoded directly in a long `nextest` expression. These cost attention but do not obscure the overall validation flow.
+
+A representative routine change is adding a new TypeScript validation job. It would repeat the checkout, Bun setup, and dependency-install sequence already present in `.github/workflows/typescript.yml:jobs.typecheck`, `jobs.test`, and `jobs.build`, then add the new command.
+
+Strongest counterevidence: each job can be understood independently, commands are explicit, and there is no multi-layer reusable-workflow indirection.
+
+Why adjacent scores do not fit: 4 does not fit because repeated setup and inline special policies add avoidable local friction. 2 does not fit because ordinary check changes still have a direct path through one small workflow and do not cross a complex control structure.
+
+### Domain model — 2, High confidence
+
+Some configuration identifiers no longer denote repository reality. Both push and pull-request triggers in `.github/workflows/rust.yml` refer to `openapi/**`, but that path does not exist; the actual API contract is `docs/public/api-reference/fabro-api.yaml`, which the same workflow's legacy-auth check names directly. `.github/workflows/typescript.yml` also omits that contract path even though the TypeScript API client is generated from it. A contract-only change can therefore fall outside the configured validation vocabulary.
+
+`.github/zizmor.yml:rules.stale-action-refs.ignore` identifies three exceptions by `rust.yml` source line. History shows those locations originally denoted Rust toolchain actions, while the current line numbers point elsewhere after workflow edits. The exception's identity is coupled to incidental layout rather than the action it is meant to describe.
+
+Strongest counterevidence: jobs, test modes, toolchain versions, permissions, and build profiles are otherwise named explicitly and line up with repository commands.
+
+Why adjacent scores do not fit: 3 does not fit because the stale/nonexistent identifiers affect whether central source-of-truth changes are validated and whether static-validation exceptions retain their intended meaning. 1 does not fit because most CI vocabulary remains stable and the affected values can be corrected from clear repository authorities.
+
+### Duplication of knowledge — 2, High confidence
+
+Trigger-path knowledge is repeated in every workflow and twice within each workflow: `.github/workflows/rust.yml:on.push.paths` duplicates `on.pull_request.paths`, and `.github/workflows/typescript.yml` does the same. Cross-language contract inputs then require synchronized edits in both files. The stale `openapi/**` entry and omission of `docs/public/api-reference/fabro-api.yaml` are direct evidence that this repeated knowledge has drifted.
+
+A representative routine change is moving or adding a source-of-truth file that must trigger all relevant CI. It requires updating `rust.yml:on.push.paths`, `rust.yml:on.pull_request.paths`, `typescript.yml:on.push.paths`, and `typescript.yml:on.pull_request.paths`; there is no shared authority that makes one update cover the four consumers.
+
+Strongest counterevidence: commands and action versions are local to their jobs, so much of the visible repetition is deliberate job isolation, and each language workflow is small.
+
+Why adjacent scores do not fit: 3 does not fit because trigger selection is central to CI's purpose, the synchronization crosses both event sections and language workflows, and actual drift is present. 1 does not fit because the duplicated lists are easy to locate and most entries still agree.
+
+Lens-boundary note: the stale OpenAPI trigger could be scored only as duplicate path knowledge. I used the repeated four-list maintenance burden for duplication, while treating the fact that `openapi/**` currently has no referent—and that line-based Zizmor identities no longer name the intended actions—as domain vocabulary drift.

.chisel/calibration/work/reviewer-2.md

@@ -0,0 +1,176 @@
+# Calibration Sample Review — Reviewer 2
+
+Revision: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+
+This review uses the component boundaries in `.chisel/cartography/codebase-map.md`. In particular, `fabro-web-app` excludes `apps/fabro-web/app/components/playground/**`, and `repository-ci` contains only `.github/workflows/rust.yml`, `.github/workflows/typescript.yml`, and `.github/zizmor.yml`.
+
+## Score summary
+
+| Component | Ownership and boundaries | Simplicity | Domain model | Duplication of knowledge |
+|---|---:|---:|---:|---:|
+| `fabro-workflow` | 3 (Medium) | 2 (High) | 3 (Medium) | 2 (High) |
+| `fabro-http` | 4 (High) | 4 (High) | 3 (High) | 4 (High) |
+| `fabro-web-app` | 4 (Medium) | 2 (Medium) | 2 (Medium) | 2 (Medium) |
+| `repository-ci` | 4 (High) | 3 (High) | 3 (High) | 2 (High) |
+
+## `fabro-workflow`
+
+### `ownership-boundaries` — 3, Medium confidence
+
+The component has a recognizable high-level owner and intended dependency direction. `lib/components/fabro-workflow/src/operations/mod.rs` owns run-level operations, while `lib/components/fabro-workflow/src/pipeline/mod.rs` owns the ordered phase API. `lib/components/fabro-workflow/src/pipeline/types.rs:Parsed`, `Transformed`, `Validated`, `Persisted`, `Initialized`, `Executed`, `Concluded`, and `Finalized` make phase ownership explicit. `lib/components/fabro-workflow/src/services.rs:RunServices` and `EngineServices` distinguish run-lifetime services from node-execution services, and `lib/components/fabro-workflow/src/node_handler.rs:WorkflowNodeHandler` is a visible adapter to `fabro-core`.
+
+The friction is at the public edge: `lib/components/fabro-workflow/src/lib.rs` exposes operations, pipeline phases, handlers, records, services, runtime storage, and several `#[doc(hidden)]` modules. Callers can therefore enter below the complete lifecycle as well as through `lib/components/fabro-workflow/src/operations/start.rs:start`. This weakens containment, but it does not create a competing production owner.
+
+**Strongest counterevidence:** The typed phase outputs and the `RunServices`/`EngineServices` split strongly reinforce one workflow lifecycle.
+
+**Why adjacent scores do not fit:** A 4 does not fit because the broad facade exposes enough lifecycle internals to make the boundary porous. A 2 does not fit because the normal `start` path and each phase owner remain identifiable and dependencies are delegated to dedicated crates.
+
+### `simplicity` — 2, High confidence
+
+The stable common path is traceable, but routine work crosses substantial central machinery: `lib/components/fabro-workflow/src/operations/start.rs:start` → `execute_persisted_run` → `RunSession::new` → `RunSession::run` → `pipeline::initialize` → `pipeline::execute` → `pipeline::finalize` → `pipeline::pull_request`. Along that path, `StartServices`, `RunSession`, and `lib/components/fabro-workflow/src/pipeline/types.rs:InitOptions` each carry many run concerns, while bootstrap, completion, cleanup, steering-drain, sandbox, and event-flush guards add multiple exit paths. `lib/components/fabro-workflow/src/pipeline/initialize.rs:initialize` also coordinates sandbox creation/reconnection, hooks, credentials, Git setup, handler construction, and resume state.
+
+**Representative routine change:** Adding one run-scoped execution service would normally thread through `operations/start.rs:StartServices`, `RunSession`, and `RunSession::new`; `pipeline/types.rs:InitOptions`; `pipeline/initialize.rs:initialize`; and `services.rs:RunServices` or `EngineServices`.
+
+**Strongest counterevidence:** `operations/start.rs:RunSession::run` presents the main phases in a linear order, and the phase-specific types preserve that order despite the setup machinery.
+
+**Why adjacent scores do not fit:** A 3 does not fit because the pressure is on the main run path rather than at an edge. A 1 does not fit because there is a stable phase sequence and named service bundles to follow.
+
+### `domain-model` — 3, Medium confidence
+
+The strongest mechanism is the phase-state model in `lib/components/fabro-workflow/src/pipeline/types.rs`; private fields on `Validated` and `Persisted` and opaque `ResumeState` prevent several invalid transitions. `lib/components/fabro-workflow/src/pipeline/finalize.rs:classify_engine_result` is also a clear authority for translating an engine result into `StageOutcome`, failure detail, and `RunStatus`.
+
+The main friction is the extensible, string-valued handler vocabulary on the common graph path. `lib/components/fabro-workflow/src/handler/mod.rs:HandlerRegistry::resolve` works with type strings and falls back to the default handler, while `default_registry` registers the built-in strings. Validation in `fabro-validate` protects normal runs, but execution itself does not carry a closed built-in handler type.
+
+**Strongest counterevidence:** `pipeline/types.rs:ResumeState::from_projection`, the phase output types, and `pipeline/finalize.rs:classify_engine_result` give important workflow concepts one enforced shape.
+
+**Why adjacent scores do not fit:** A 4 does not fit because handler identity remains string-valued and default-resolved through a central execution boundary. A 2 does not fit because validation and typed phase states canonicalize the normal run before execution.
+
+### `duplication-knowledge` — 2, High confidence
+
+Event knowledge is repeated across central authorities. `lib/components/fabro-workflow/src/event/events.rs:Event` defines the emitter-facing shape, `lib/components/fabro-workflow/src/event/convert.rs:event_body_from_event` translates it to the stored `fabro_types::EventBody`, `lib/components/fabro-workflow/src/event/names.rs:event_name` separately assigns wire names, and `lib/components/fabro-workflow/src/event/stored_fields.rs:stored_event_fields_for_variant` separately assigns envelope metadata. These exhaustive matches help detect omissions, but every ordinary event extension still requires synchronized semantic decisions.
+
+**Representative routine change:** Adding a stored workflow event can touch `event/events.rs:Event`, `event/convert.rs:event_body_from_event`, `event/names.rs:event_name`, `event/stored_fields.rs:stored_event_fields_for_variant`, and the canonical `lib/foundation/fabro-types/src/run_event/mod.rs:EventBody` authority.
+
+**Strongest counterevidence:** `event/convert.rs:to_run_event_at` is the single assembly point, and Rust's exhaustive matches turn many missed updates into compile failures.
+
+**Why adjacent scores do not fit:** A 3 does not fit because event emission and persistence are central, recurring behavior. A 1 does not fit because the authorities are explicit and compiler-checked rather than unidentifiable.
+
+## `fabro-http`
+
+### `ownership-boundaries` — 4, High confidence
+
+`lib/foundation/fabro-http/src/lib.rs` has one focused transport-construction boundary. `HttpClientBuilder`, `BlockingHttpClientBuilder`, `ProxyPolicy`, the client aliases, and the production/test constructors all live there; the crate depends only on `fabro-static`, `reqwest`, and `thiserror`. Repository policy reinforces the boundary through `clippy.toml:disallowed-methods`, which directs raw reqwest construction to this facade.
+
+**Strongest counterevidence:** The public reqwest aliases and re-exports make the abstraction intentionally permeable, so it does not own higher-level request behavior.
+
+**Why the adjacent score does not fit:** A 3 does not fit because exposing reqwest types is part of the mapped purpose, while construction policy and proxy resolution still have one clear owner.
+
+### `simplicity` — 4, High confidence
+
+`lib/foundation/fabro-http/src/lib.rs:define_builder` expresses shared async/blocking forwarding once. Both builders end at the same short `ProxyPolicy::resolve` and `build` path, and `http_client`, `test_http_client`, `blocking_http_client`, and `blocking_test_http_client` are thin named entry points. A shared reqwest builder option is normally added once to the macro.
+
+**Strongest counterevidence:** The macro hides generated methods, and async-only `HttpClientBuilder::read_timeout` must sit outside it.
+
+**Why the adjacent score does not fit:** A 3 does not fit because this indirection directly removes twin implementations and leaves callers with a single conventional builder path.
+
+### `domain-model` — 3, High confidence
+
+`lib/foundation/fabro-http/src/lib.rs:ProxyPolicy` gives the repository policy two named states, `ProxyPolicy::resolve_with_env_value` defines explicit-over-environment precedence, and `HttpClientBuildError::InvalidProxyPolicy` rejects unknown values. The tests cover default, environment, invalid, and explicit-override cases.
+
+The isolated ambiguity is that `HttpClientBuilder::no_proxy` and `HttpClientBuilder::proxy_policy(ProxyPolicy::Disabled)` both publicly express disabled proxy behavior, but `no_proxy` mutates the inner builder without updating the policy field. Their relationship is not represented or documented in the type.
+
+**Strongest counterevidence:** The closed enum, typed error, and resolver tests make the environment-facing policy meaning unusually explicit.
+
+**Why adjacent scores do not fit:** A 4 does not fit because two public controls overlap without an encoded relationship. A 2 does not fit because the overlap is local and every normal constructor still passes through one two-state resolver.
+
+### `duplication-knowledge` — 4, High confidence
+
+The builder macro is the authority for behavior shared by synchronous and asynchronous clients, and every constructor delegates to those builders. The production/test and async/blocking helper names repeat syntax, not policy: test behavior is expressed once as `ProxyPolicy::Disabled`.
+
+**Strongest counterevidence:** Four constructor helpers and the separate async-only impl are superficially repetitive.
+
+**Why the adjacent score does not fit:** A 3 does not fit because changing proxy precedence or disabled behavior has one authority; the remaining repetition does not require synchronized policy decisions.
+
+## `fabro-web-app`
+
+### `ownership-boundaries` — 4, Medium confidence
+
+The main browser lifecycle has clear homes. `apps/fabro-web/app/entry.tsx` selects install or normal routing and owns root providers; `app/router.tsx:routes` owns the product route graph; `app/install-router.tsx:installRoutes` owns first-run routing; `app/lib/api-client.ts` owns HTTP normalization; `app/lib/queries.ts` and `app/lib/mutations.ts` own shared server access; and `app/hooks/effects.ts` contains reusable browser-effect lifecycles. Route modules own page-specific composition. The separately mapped playground enters through `app/router.tsx` without its excluded implementation being absorbed into this assessment.
+
+**Strongest counterevidence:** `app/routes/run-stages.tsx` and `app/install-app.tsx` each combine page state, domain projection, and rendering in one route-owned file.
+
+**Why the adjacent score does not fit:** A 3 does not fit because those combinations create local complexity, but no competing owner or reversed dependency was identified; shared cross-route responsibilities still have clear modules.
+
+### `simplicity` — 2, Medium confidence
+
+Two common product paths carry central transformation machinery. `apps/fabro-web/app/routes/run-stages.tsx` turns event envelopes into `TurnType` values in `buildStageActivity`, then separately groups, filters, timelines, labels, summarizes, and renders them through `buildChatItems`, `groupConsecutiveTools`, `filterDisplayItems`, `buildThreadDnaItems`, and the route's view components. `apps/fabro-web/app/install-app.tsx` similarly contains the install reducer, session hydration, controller, step forms, review, finishing, payload construction, and supporting controls in one flow.
+
+**Representative routine change:** Changing how a tool event appears on the stage page requires tracing `run-stages.tsx:buildStageActivity`, `buildChatItems`/`groupConsecutiveTools`, `buildThreadDnaItems`, `turnLabel`, `turnSummary`, `EventDetails`, and `StageChatView`.
+
+**Strongest counterevidence:** The stage path uses discriminated unions and mostly pure exported transformations with focused tests, so each individual step can be reasoned about.
+
+**Why adjacent scores do not fit:** A 3 does not fit because the long transformation chains are central to major routes. A 1 does not fit because the named pure functions provide a stable trace through both flows.
+
+### `domain-model` — 2, Medium confidence
+
+Generated API types provide a useful boundary, but the central event path accepts several simultaneous shapes. `apps/fabro-web/app/lib/run-events.ts:RunEventPayload` makes event identity and metadata optional and `stageIdFromPayload` falls back from `stage_id` to `node_id` to `properties.node_id`. `app/routes/run-stages.tsx:activityEventStageId` repeats that shape tolerance for stored `EventEnvelope`s, while `buildStageActivity` reads tool, text, argument, and output values from both `properties` and legacy top-level fields via `app/lib/unknown.ts`.
+
+**Representative routine change:** Moving one stage-event field to its canonical envelope location can require coordinated interpretation changes in `lib/run-events.ts:RunEventPayload` and `stageIdFromPayload`, plus `routes/run-stages.tsx:activityEventStageId` and `buildStageActivity`.
+
+**Strongest counterevidence:** Once parsed, `run-stages.tsx:TurnType`, `StageRenderer`, and generated `StageHandler`/`StageState` types give the UI clear closed shapes.
+
+**Why adjacent scores do not fit:** A 3 does not fit because the multi-shape event interpretation is on live invalidation and the main stage view, not an edge. A 1 does not fit because generated types and discriminated UI projections establish a stable canonical shape after parsing.
+
+### `duplication-knowledge` — 2, Medium confidence
+
+Stage-state presentation policy is authoritative in several common views. `apps/fabro-web/app/lib/stage-sidebar.ts:ACTIVE_STAGE_STATES`, `IN_FLIGHT_STAGE_STATES`, `SUCCEEDED_STAGE_STATES`, `STAGE_STATUS_TONE`, and `STAGE_STATUS_LABEL` define classifications and visuals, while `app/components/stage-sidebar.tsx:statusConfig`, `app/components/run-waterfall.tsx:stageBarClass` and `isStageInFlight`, and `app/components/stage-popover.tsx:StatusPill` make parallel state decisions.
+
+**Representative routine change:** Adding a generated `StageState` requires reviewing or changing all of those authorities so the sidebar, waterfall, and popover agree on activity, success, label, and tone.
+
+**Strongest counterevidence:** Generated `StageState` plus exhaustive `Record<StageState, ...>` mappings catch many omissions, and `lib/stage-sidebar.ts` already centralizes several shared classifications.
+
+**Why adjacent scores do not fit:** A 3 does not fit because stage status is central to multiple routine run views and synchronization is recurring. A 1 does not fit because the generated enum is a clear semantic authority and TypeScript catches many missing cases.
+
+## `repository-ci`
+
+### `ownership-boundaries` — 4, High confidence
+
+The two workflows divide validation by ecosystem: `.github/workflows/rust.yml:jobs` owns Rust format, lint, generated-doc, workspace test, twin-mode ignored tests, and manual macOS validation; `.github/workflows/typescript.yml:jobs` owns web/client typecheck, web tests, and the embedded-SPA production build. Both use top-level empty permissions and job-local read permission. The cross-language Cargo build in the TypeScript build job validates the mapped embedded-SPA integration rather than creating a second build owner.
+
+**Strongest counterevidence:** The Rust clippy job contains a repository-wide legacy-auth guard that also scans TypeScript and API paths.
+
+**Why the adjacent score does not fit:** A 3 does not fit because that cross-language invariant remains an explicitly named CI check, while job and workflow lifecycle ownership stays clear.
+
+### `simplicity` — 3, High confidence
+
+The main flow is explicit: named jobs perform checkout, tool setup, and one or two direct repository commands. The isolated friction is `.github/workflows/rust.yml:jobs.clippy.steps.Verify legacy auth identity removal`, where a long regular expression and shell exit-status protocol are embedded in a lint job. The twin-mode test semantics also need a substantial comment and package expression in `jobs.test`.
+
+**Strongest counterevidence:** Separate jobs, direct commands, pinned tools, and no reusable-workflow indirection make routine CI behavior easy to locate.
+
+**Why adjacent scores do not fit:** A 4 does not fit because the legacy guard and twin-mode selection require non-obvious local interpretation. A 2 does not fit because that machinery is isolated and ordinary check changes still follow a direct job structure.
+
+### `domain-model` — 3, High confidence
+
+Job names, triggers, permissions, platforms, and commands have consistent meanings in the GitHub Actions structure. Exact action SHAs and named modes such as `--profile ci` reduce ambiguity. The main gap is that `.github/workflows/rust.yml:jobs.test` relies on the external default meaning of `FABRO_TEST_MODE` for its twin run rather than setting the mode in the workflow; the comment is the only local declaration of that state.
+
+**Strongest counterevidence:** The command, package selector, and explanation tightly describe the intended twin-only behavior, and every job has an explicit runner and permission set.
+
+**Why adjacent scores do not fit:** A 4 does not fit because a central test mode is implicit in an external default. A 2 does not fit because the rest of the workflow vocabulary is coherent and the implicit state is limited to one documented test step.
+
+### `duplication-knowledge` — 2, High confidence
+
+Trigger policy is repeated verbatim between `on.push.paths` and `on.pull_request.paths` in both workflow files. Action versions and bootstrap steps are also copied across every job. `.github/zizmor.yml:rules.stale-action-refs.ignore` adds line-number references to `rust.yml`, creating another manually synchronized representation; at this revision its listed lines 37, 49, and 62 are respectively a blank line, the `fmt` job key, and a Cargo command rather than action references.
+
+**Representative routine change:** Adding a new Rust-owned source area requires matching edits to `.github/workflows/rust.yml:on.push.paths` and `on.pull_request.paths`; upgrading checkout requires synchronized edits in `jobs.fmt`, `clippy`, `generated-docs`, `test`, and `test-macos`, followed by review of `.github/zizmor.yml:rules.stale-action-refs.ignore`.
+
+**Strongest counterevidence:** The duplication is explicit and small enough to inspect, and each actual validation command appears once in its intended job.
+
+**Why adjacent scores do not fit:** A 3 does not fit because triggers and action versions are central, recurring maintenance knowledge and the stale line selectors demonstrate drift. A 1 does not fit because the canonical workflows and intended checks remain identifiable.
+
+## Lens-boundary confusion
+
+- The `fabro-workflow` `Event`/`EventBody` split could be described as two domain shapes. I assigned its score effect to `duplication-knowledge` because the discriminating problem is the synchronized event name, conversion, and envelope-field decisions, not an inability to identify either type's meaning.
+- The size and mixed contents of `fabro-web-app` route files could look like misplaced responsibility. I assigned the main effect to `simplicity` because the route remains the clear owner; the problem is tracing the amount of local machinery.
+- Repeated `StageState` maps could be treated as domain drift. I assigned them to `duplication-knowledge` because the generated enum preserves meaning and the observed burden is repeating presentation/classification policy across views.
+- The `.github/zizmor.yml` line selectors could be treated as invalid configuration meaning. I assigned their main effect to `duplication-knowledge` because the failure mechanism is manual synchronization with line positions; `repository-ci` domain scoring instead uses the implicit twin-mode default.
+- `fabro-http`'s macro could be treated as simplicity indirection, while its two proxy-disable controls could be treated as duplicate policy. I treated the macro as a positive simplicity/duplication mechanism and the overlapping controls as `domain-model` friction because the unresolved question is what each public control means.

.chisel/calibration/work/reviewer-3.md

@@ -0,0 +1,490 @@
+# Calibration Sample Review — Reviewer 3
+
+Revision: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+
+Scope follows `.chisel/cartography/codebase-map.md`: `fabro-workflow`,
+`fabro-http`, `fabro-web-app`, and `repository-ci`. The `fabro-web-app`
+reading excludes `apps/fabro-web/app/components/playground/**`;
+`repository-ci` includes only `.github/workflows/rust.yml`,
+`.github/workflows/typescript.yml`, and `.github/zizmor.yml`.
+
+## Provisional Matrix
+
+| Component | Ownership and boundaries | Simplicity | Domain model | Duplication of knowledge |
+|---|---:|---:|---:|---:|
+| `fabro-workflow` | 4 / High | 2 / High | 2 / High | 2 / High |
+| `fabro-http` | 4 / High | 4 / High | 4 / High | 4 / High |
+| `fabro-web-app` | 3 / High | 2 / High | 2 / High | 2 / High |
+| `repository-ci` | 3 / High | 3 / High | 2 / High | 2 / High |
+
+## `fabro-workflow`
+
+### `ownership-boundaries` — 4, High confidence
+
+Evidence:
+
+- `lib/components/fabro-workflow/src/pipeline/mod.rs` exposes an ordered phase
+  facade, while `pipeline/types.rs:Parsed`, `Transformed`, `Validated`,
+  `Persisted`, `Initialized`, `Executed`, `Concluded`, and `Finalized` give each
+  phase an explicit handoff.
+- `lib/components/fabro-workflow/src/handler/mod.rs:Handler` and
+  `HandlerRegistry` own workflow-specific dispatch;
+  `src/node_handler.rs:WorkflowNodeHandler` is the narrow adapter to
+  `fabro_core::handler::NodeHandler`.
+- `lib/components/fabro-workflow/src/lifecycle/mod.rs:WorkflowLifecycle` states
+  that it owns callback ordering and delegates event, hook, fidelity,
+  auto-status, circuit-breaker, Git, and artifact work to focused lifecycle
+  objects.
+- `lib/components/fabro-workflow/Cargo.toml:[dependencies]` points from the
+  orchestrator to parsing, validation, sandbox, persistence, model, and generic
+  execution crates; generic traversal remains in `fabro-core`.
+
+Strongest counterevidence: startup state is carried through
+`operations/start.rs:StartServices`, `RunSession`,
+`pipeline/types.rs:InitOptions`, and `services.rs:RunServices` /
+`EngineServices`, so the lifecycle boundary has substantial wiring.
+
+Why adjacent scores do not fit: 3 would treat that wiring as unclear ownership,
+but the common path consistently identifies phase, handler, lifecycle, and
+generic-executor owners. The counterevidence is primarily machinery inside the
+intended orchestration owner, not a competing dependency direction or lifecycle
+home.
+
+### `simplicity` — 2, High confidence
+
+Evidence:
+
+- The normal start path crosses
+  `operations/start.rs:start` → `execute_persisted_run` →
+  `RunSession::new` → `RunSession::run` →
+  `pipeline::initialize` → `pipeline::execute` →
+  `pipeline::finalize` → `pipeline::pull_request`.
+- The same run-scoped collaborators are reshaped across
+  `operations/start.rs:StartServices`, `RunSession`,
+  `pipeline/types.rs:InitOptions`, `services.rs:RunServices`, and
+  `EngineServices`.
+- `lifecycle/mod.rs:WorkflowLifecycle::new` takes the full set of lifecycle
+  collaborators and has an explicit `too_many_arguments` exception before
+  constructing seven sub-lifecycles with shared coordination state.
+
+Strongest counterevidence: the phase-state types in
+`pipeline/types.rs` and the focused handler/lifecycle modules make this
+machinery traceable; the common path is not hidden.
+
+Why adjacent scores do not fit: 3 does not fit because every ordinary run
+traverses the service reshaping and multi-stage cleanup/finalization path; this
+is central rather than edge friction. 1 does not fit because the named phase
+sequence and handoff types provide a stable path through the machinery.
+
+Representative routine change: adding a run-scoped execution-audit sink for
+handlers would require threading it through
+`operations/start.rs:StartServices`, `RunSession`,
+`RunSession::new`, `RunSession::run`,
+`pipeline/types.rs:InitOptions`, `pipeline/initialize.rs:initialize`, and
+`services.rs:RunServices` or `EngineServices`.
+
+### `domain-model` — 2, High confidence
+
+Evidence:
+
+- Positive mechanisms are substantial:
+  `pipeline/types.rs:Validated` hides its graph and exposes validation
+  operations, `ResumeState::from_projection` creates opaque resume state, and
+  `run_status.rs` plus `outcome.rs` reuse canonical types from `fabro-types` and
+  `fabro-core`.
+- A central exception remains:
+  `event/events.rs:Event::StageCompleted` represents `status` as `String`, while
+  execution uses typed `outcome.rs:StageOutcome`.
+  `event/convert.rs:stage_status_from_string` reparses the string and maps every
+  unknown value to a failed outcome.
+- The common producer
+  `lifecycle/event.rs:EventLifecycle::after_node` converts the typed outcome to
+  a string before the canonical event conversion converts it back.
+
+Strongest counterevidence: the pipeline phase types, `RunStatus`,
+`StageOutcome`, `StageId`, and the durable `fabro_types::EventBody` otherwise
+give the main workflow concepts canonical typed shapes.
+
+Why adjacent scores do not fit: 3 does not fit because stage completion is on
+the execution hot path and accepts states the canonical outcome enum rejects.
+1 does not fit because the canonical types and phase states still give the
+workflow a coherent vocabulary overall.
+
+Representative routine change: adding or changing a stage outcome would touch
+the canonical `lib/foundation/fabro-core/src/outcome.rs:StageOutcome`, string
+construction in `lifecycle/event.rs:EventLifecycle::after_node`,
+`event/events.rs:Event::StageCompleted`,
+`event/convert.rs:stage_status_from_string`, and terminal interpretation in
+`pipeline/finalize.rs:classify_engine_result`.
+
+### `duplication-knowledge` — 2, High confidence
+
+Evidence:
+
+- `event/events.rs:Event` defines the internal event shape,
+  `event/names.rs:event_name` independently maps every variant to its external
+  name, `event/stored_fields.rs:stored_event_fields` independently selects
+  envelope fields, and `event/convert.rs:event_body_from_event` constructs the
+  canonical `fabro_types::EventBody`.
+- `docs/internal/events-strategy.md:Adding A New Event` explicitly requires
+  synchronized edits to the internal event, tracing, external name,
+  `EventBody`, stored fields, conversion, and consumers.
+- Exhaustive matches make omissions visible, but they do not make one of those
+  mappings authoritative for the others.
+
+Strongest counterevidence: `event/emitter.rs:Emitter` canonicalizes each emitted
+event once, all listeners receive the same `RunEvent`, and exhaustive matching
+plus conversion tests detect much of the synchronization drift.
+
+Why adjacent scores do not fit: 3 does not fit because adding an event is a
+routine extension to this component and centrally requires several independent
+authorities. 1 does not fit because the events strategy clearly identifies all
+authorities and the compiler/test suite gives a stable update path.
+
+Representative routine change: adding `run.suspended` would touch
+`event/events.rs:Event`, `events.rs:Event::trace`,
+`event/names.rs:event_name`,
+`lib/foundation/fabro-types/src/run_event/mod.rs:EventBody`,
+`event/stored_fields.rs:stored_event_fields`,
+`event/convert.rs:event_body_from_event`, and relevant store/UI consumers.
+
+## `fabro-http`
+
+### `ownership-boundaries` — 4, High confidence
+
+Evidence:
+
+- The component is one focused source module:
+  `lib/foundation/fabro-http/src/lib.rs` owns the reqwest facade,
+  `ProxyPolicy`, client builders, build errors, and deterministic test clients.
+- `src/lib.rs:HttpClientBuilder::build` and
+  `BlockingHttpClientBuilder::build` are the construction boundary where the
+  process proxy policy is applied.
+- `clippy.toml:disallowed-methods` denies direct reqwest client constructors and
+  points callers to this component; `fabro_static::EnvVars` supplies the one
+  environment-variable name without introducing higher-level configuration.
+
+Strongest counterevidence: the facade deliberately re-exports many reqwest
+types, and exceptional consumers still carry direct reqwest dependencies for
+generated clients or incompatible dependency versions.
+
+Why adjacent scores do not fit: 3 does not fit because the normal async,
+blocking, production, and test construction paths all converge on the same
+owned policy, with a repository lint reinforcing that boundary.
+
+### `simplicity` — 4, High confidence
+
+Evidence:
+
+- `src/lib.rs:define_builder!` expresses the common async/blocking builder once;
+  the four convenience constructors are thin calls to the same builders.
+- The common flow is direct:
+  `HttpClientBuilder::new` → optional reqwest options →
+  `HttpClientBuilder::build` → `ProxyPolicy::resolve` → reqwest build.
+- The only async-only option is visibly isolated in
+  `HttpClientBuilder::read_timeout`.
+
+Strongest counterevidence: the macro hides the two generated impls and every
+new exposed reqwest option requires another forwarding method.
+
+Why adjacent scores do not fit: 3 does not fit because the macro removes a real
+parallel API synchronization burden while leaving the common client-building
+path locally readable; its indirection is not encountered beyond this file.
+
+### `domain-model` — 4, High confidence
+
+Evidence:
+
+- `src/lib.rs:ProxyPolicy` has exactly the two supported states,
+  `ProxyPolicy::resolve_with_env_value` makes explicit configuration override
+  environment fallback, and invalid/non-Unicode values become
+  `HttpClientBuildError`.
+- `src/lib.rs:HttpClientBuildError` distinguishes invalid policy from underlying
+  reqwest construction failure.
+- `test_http_client` and `blocking_test_http_client` select the typed
+  `ProxyPolicy::Disabled` rather than relying on ambient test environment state.
+
+Strongest counterevidence: the environment boundary is necessarily stringly,
+and `ProxyPolicy::parse` accepts case variants before producing the enum.
+
+Why adjacent scores do not fit: 3 does not fit because invalid strings are
+rejected at the boundary, precedence is explicit, and all downstream paths use
+the closed enum.
+
+### `duplication-knowledge` — 4, High confidence
+
+Evidence:
+
+- `src/lib.rs:define_builder!` is the single authority for shared async and
+  blocking options and policy application.
+- `ProxyPolicy::resolve` is the single production authority for explicit/env/
+  default precedence.
+- `clippy.toml:disallowed-methods` prevents ordinary callers from silently
+  recreating client-construction policy outside the component.
+
+Strongest counterevidence: async and blocking convenience constructors remain
+as four syntactically similar functions, and `read_timeout` cannot live in the
+shared macro surface.
+
+Why adjacent scores do not fit: 3 does not fit because the remaining repetition
+does not duplicate a policy or require independent decisions; it exposes
+parallel entry points backed by the same authority.
+
+## `fabro-web-app`
+
+### `ownership-boundaries` — 3, High confidence
+
+Evidence:
+
+- `apps/fabro-web/app/entry.tsx:AppRuntime` owns browser bootstrap and global
+  runtime providers; `router.tsx:routes` and
+  `install-router.tsx:installRoutes` own the two route graphs.
+- `app/lib/queries.ts` and `app/lib/mutations.ts` own server reads and writes;
+  `app/lib/api-client.ts` owns transport/error normalization.
+- `app/hooks/effects.ts` and purpose-named hooks such as
+  `useRunEvents` and `useInstallRestartHealthPolling` contain browser resource
+  lifecycles rather than leaving them in route rendering.
+- `routes/run-detail.tsx:RunDetail` delegates its header, actions, model,
+  lifecycle-toast, tab-shell, and docked-control responsibilities to the
+  `routes/run-detail/**` modules.
+
+Strongest counterevidence: two mapped common paths still concentrate several
+responsibilities:
+`install-app.tsx:InstallApp` / `useInstallController` contains state,
+hydration, submission, step routing, payload construction, and rendering, while
+`routes/run-stages.tsx:RunStages` / `buildStageActivity` contains event
+interpretation and a large part of stage presentation.
+
+Why adjacent scores do not fit: 4 does not fit because those central route
+modules are not merely edge exceptions. 2 does not fit because routes, API
+access, queries, mutations, browser effects, and build lifecycle still have
+stable homes and dependencies generally point through those homes.
+
+### `simplicity` — 2, High confidence
+
+Evidence:
+
+- The first-run common path is concentrated in
+  `install-app.tsx:installReducer`, `useInstallController`, `InstallApp`,
+  `LlmStep`, `ObjectStoreStep`, `SandboxStep`, `GithubStep`,
+  `buildObjectStorePayload`, and `buildSandboxPayload`.
+- The run-stage common path combines
+  `routes/run-stages.tsx:selectStageRenderer`,
+  `buildStageActivity`, filtering, debug views, waterfall construction, and
+  `RunStages`.
+- Cross-tab event sharing introduces a second substantial state machine at
+  `app/lib/cross-tab-sse.ts:CrossTabSseCoordinator`, beneath the already
+  separate shared-event-source logic in `app/lib/sse.ts:subscribeToSharedEventSource`.
+
+Strongest counterevidence: reducers, discriminated unions, shared query hooks,
+purpose-named integration hooks, and extracted run-detail modules make many
+individual flows explicit and testable.
+
+Why adjacent scores do not fit: 3 does not fit because installation, run-stage
+inspection, and live refresh are mapped common paths, not optional edge
+machinery. 1 does not fit because each path still has identifiable entry
+points, state machines, and tests.
+
+Representative routine change: adding an installation step for telemetry would
+touch `install-app.tsx:INSTALL_STEPS`, `InstallState`, `InstallAction`,
+`installReducer`, `useInstallController`, `InstallApp`, a new step component,
+review-summary helpers, `install-api.ts`, and the generated install API
+authority in `docs/public/api-reference/fabro-api.yaml`.
+
+### `domain-model` — 2, High confidence
+
+Evidence:
+
+- Positive mechanisms include generated API types throughout the query and
+  route layers, `mode.ts:FabroMode`, and exhaustive display maps such as
+  `lib/sandbox-state.ts:SANDBOX_STATE_DISPLAY`.
+- The central SSE boundary instead uses
+  `lib/sse.ts:EventPayload`, where `event` is optional and all other fields are
+  unknown, then extends it as
+  `lib/run-events.ts:RunEventPayload` with optional string identifiers and
+  another untyped `properties` map.
+- `lib/run-events.ts:stageIdFromPayload` accepts `stage_id`, `node_id`, or
+  `properties.node_id` as the stage identity.
+- `lib/run-sandbox-lifecycle.ts:sandboxLifecycleKind` and `sandboxInstance`
+  cast generated values into compatibility shapes and infer lifecycle from
+  either `kind`, `instance`, or legacy `runtime` / `provider` fields.
+
+Strongest counterevidence: normal HTTP reads and writes use
+`@qltysh/fabro-api-client` types, and `Record<GeneratedEnum, ...>` display maps
+make many API vocabulary changes compile-visible.
+
+Why adjacent scores do not fit: 3 does not fit because SSE drives normal run
+refresh and stage views while permitting absent event and identity fields with
+multiple meanings. 1 does not fit because generated HTTP types and local
+discriminated unions still provide a coherent model for most operations.
+
+Representative routine change: making stage identity canonical across live
+events would touch the wire authority
+`docs/public/api-reference/fabro-api.yaml`,
+`lib/sse.ts:EventPayload`, `lib/run-events.ts:RunEventPayload`,
+`stageIdFromPayload`, and consumers such as
+`routes/run-stages.tsx:buildStageActivity`.
+
+### `duplication-knowledge` — 2, High confidence
+
+Evidence:
+
+- `lib/board-events.ts:BOARD_STATUS_EVENTS` independently decides which run
+  events refresh lists, while `lib/run-events.ts:RUN_SUMMARY_EVENTS`,
+  `TERMINAL_EVENTS`, and other sets decide detail invalidations.
+- `lib/run-phases.ts:deriveRunPhases` independently matches the same lifecycle
+  event vocabulary to build the pre-stage timeline.
+- `lib/run-events.ts:STAGE_ACTIVITY_EVENT_TYPES` is a positive local authority
+  shared with `routes/run-stages.tsx:buildStageActivity`, but it covers only one
+  slice of the broader manual event policy.
+
+Strongest counterevidence: list and detail invalidation are genuinely different
+consumer decisions, `query-keys.ts:queryKeys` centralizes cache identities, and
+the stage-activity list is deliberately shared with its reducer.
+
+Why adjacent scores do not fit: 3 does not fit because a normal lifecycle-event
+extension that affects board and run detail requires synchronized policy edits
+in separate common subscriptions. 1 does not fit because each consumer's
+authority is named, localized, and covered by focused tests.
+
+Representative routine change: adding a `run.suspended` transition that should
+refresh both list and detail views would touch
+`board-events.ts:BOARD_STATUS_EVENTS`,
+`run-events.ts:RUN_SUMMARY_EVENTS` (and possibly `TERMINAL_EVENTS` if its
+semantics require it), `board-events.test.tsx`, `run-events.test.tsx`, and the
+upstream event/OpenAPI authorities.
+
+## `repository-ci`
+
+### `ownership-boundaries` — 3, High confidence
+
+Evidence:
+
+- `.github/workflows/rust.yml:jobs` owns Rust formatting, lint, generated-doc,
+  Linux test, twin-E2E, and manual macOS validation.
+- `.github/workflows/typescript.yml:jobs` owns browser/client typecheck, web
+  tests, and the embedded-SPA release build.
+- Both workflows set top-level empty permissions and grant only
+  `contents: read` per job; all third-party actions are commit-pinned.
+- Generated-document and embedded-SPA behavior is delegated to
+  `cargo dev docs check` and `cargo dev build`, leaving those build procedures
+  in `fabro-build-tooling`.
+
+Strongest counterevidence:
+`.github/workflows/rust.yml:jobs.clippy.steps[name="Verify legacy auth identity removal"]`
+contains an authentication-migration vocabulary grep inside the general CI
+workflow, so an auth-domain transition also has a policy home here.
+
+Why adjacent scores do not fit: 4 does not fit because that product-domain
+policy crosses into the CI owner and the trigger boundary has drift discussed
+under domain model. 2 does not fit because the normal validation jobs and their
+delegated build/test authorities remain clearly owned and directional.
+
+Representative routine change: renaming or restoring an authentication identity
+would require changing the product types and also the legacy-name authority in
+`.github/workflows/rust.yml:jobs.clippy.steps[name="Verify legacy auth identity removal"]`.
+
+### `simplicity` — 3, High confidence
+
+Evidence:
+
+- Each job is a short checkout/setup/command sequence, and the two workflows
+  split by the repository's Rust and Bun validation surfaces.
+- `.github/workflows/rust.yml:jobs.test` explains the non-obvious twin-mode
+  expression and why it must not use the strict E2E profile.
+- `.github/workflows/typescript.yml:jobs.build` delegates the mixed Rust/SPA
+  build to one repository command rather than reproducing its internals.
+
+Strongest counterevidence: checkout, tool setup, install, permissions, runner,
+and cache declarations are repeated across every job; the inline legacy-auth
+shell condition is more elaborate than the surrounding declarative checks.
+
+Why adjacent scores do not fit: 4 does not fit because routine maintenance must
+scan repeated job scaffolding and one bespoke shell policy. 2 does not fit
+because a contributor can still trace each common validation path directly
+from one named job to one repository command.
+
+### `domain-model` — 2, High confidence
+
+Evidence:
+
+- `.github/workflows/rust.yml:on.push.paths` and `on.pull_request.paths` contain
+  `openapi/**`, but that directory does not exist at the assessed revision.
+- The actual contract authority is
+  `docs/public/api-reference/fabro-api.yaml`, as named by
+  `AGENTS.md:API workflow`,
+  `lib/foundation/fabro-api/build.rs:main`, and
+  `lib/packages/fabro-api-client/package.json:scripts.generate`.
+- Neither `.github/workflows/rust.yml:on.*.paths` nor
+  `.github/workflows/typescript.yml:on.*.paths` names that actual contract
+  path, even though both generated clients depend on it.
+
+Strongest counterevidence: job names, Rust versus TypeScript scope, twin versus
+live test meaning, and toolchain versions are otherwise explicit; the commands
+the jobs run correspond to checked-in project commands.
+
+Why adjacent scores do not fit: 3 does not fit because an ordinary edit to the
+HTTP source of truth falls outside both central validation trigger models. 1
+does not fit because the workflows still have a stable and mostly accurate
+vocabulary for jobs, branches, tools, and commands.
+
+Representative routine change: editing only
+`docs/public/api-reference/fabro-api.yaml` should exercise Rust generation and
+TypeScript typecheck/build, but its meaning would have to be repaired in
+`.github/workflows/rust.yml:on.push.paths`,
+`.github/workflows/rust.yml:on.pull_request.paths`,
+`.github/workflows/typescript.yml:on.push.paths`, and
+`.github/workflows/typescript.yml:on.pull_request.paths`.
+
+### `duplication-knowledge` — 2, High confidence
+
+Evidence:
+
+- Each workflow repeats its path set under both `on.push.paths` and
+  `on.pull_request.paths`; a new CI-relevant repository path has two authorities
+  per language.
+- `.github/workflows/rust.yml:jobs.fmt`, `jobs.clippy`,
+  `jobs.generated-docs`, `jobs.test`, and `jobs.test-macos` independently repeat
+  checkout pins, credential policy, runner/toolchain setup, and often cache
+  setup.
+- `.github/workflows/typescript.yml:jobs.typecheck`, `jobs.test`, and
+  `jobs.build` independently repeat checkout, Bun setup, and frozen install.
+
+Strongest counterevidence: independent jobs preserve failure isolation and
+least-privilege permissions, while the substantive docs/build procedures are
+delegated to repository commands rather than copied into YAML.
+
+Why adjacent scores do not fit: 3 does not fit because path and tool-bootstrap
+knowledge is repeated on every routine trigger or tool-version update. 1 does
+not fit because all copies remain confined to two small workflow files and the
+substantive check authorities are still identifiable.
+
+Representative routine change: adding a new Rust-relevant `tools/**` tree would
+require synchronized edits to
+`.github/workflows/rust.yml:on.push.paths` and
+`on.pull_request.paths`; updating the Rust checkout/toolchain baseline requires
+reviewing the pins in every `rust.yml:jobs.*.steps` copy.
+
+## Lens-Boundary Notes
+
+- The repeated startup carriers in `fabro-workflow` could be labeled ownership
+  or simplicity. I counted their unclear amount of machinery under simplicity;
+  ownership was judged from whether each phase, resource lifecycle, and
+  dependency direction has a named home.
+- The workflow's internal `Event` and durable `EventBody` have documented
+  distinct meanings. I therefore counted the many synchronized mappings under
+  duplication, not domain model. The separate `StageCompleted.status: String`
+  finding drives the domain-model score because it admits invalid states.
+- Large web route files are not ownership findings merely because they are
+  large. They lower simplicity where common behavior is difficult to trace; the
+  ownership score moves only where several responsibilities remain concentrated
+  despite otherwise clear route/data/effect homes.
+- In the web event layer, optional/untyped payload shape is a domain-model
+  finding. Repeating lifecycle-event policy across list, detail, and phase
+  consumers is a duplication finding.
+- In CI, the stale `openapi/**` referent is a domain-model finding because the
+  path no longer means the API authority it purports to cover. Repeating trigger
+  and setup lists is separately a duplication finding.
+- The `fabro-http` builder macro adds local indirection, but its primary effect
+  is to make shared async/blocking policy authoritative. I treated it as a
+  positive duplication mechanism rather than simplicity friction.

.chisel/calibration/work/validation-1.md

@@ -0,0 +1,424 @@
+# Chisel calibration validation 1
+
+Revision: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+
+This is an independent reading of only the requested assignments. Scores use the
+mapped purposes and the final calibration rubric. Boundary evidence is included
+where it establishes whether a scoped mechanism is on a production common path.
+
+## Summary
+
+| Component | Lens | Score | Evidence confidence |
+|---|---|---:|---|
+| `fabro-workflow` | `ownership-boundaries` | 2 | High |
+| `fabro-workflow` | `domain-model` | 2 | High |
+| `fabro-http` | `domain-model` | 4 | High |
+| `fabro-http` | `duplication-knowledge` | 4 | High |
+| `fabro-web-app` | `ownership-boundaries` | 4 | Medium |
+| `repository-ci` | `ownership-boundaries` | 4 | Medium |
+| `repository-ci` | `domain-model` | 2 | High |
+| `fabro-checkpoint` | `ownership-boundaries` | 2 | High |
+| `fabro-checkpoint` | `simplicity` | 4 | Medium |
+| `fabro-checkpoint` | `domain-model` | 2 | High |
+| `fabro-checkpoint` | `duplication-knowledge` | 3 | Medium |
+
+## `fabro-workflow`
+
+### `ownership-boundaries`: 2
+
+- **Evidence:** `lifecycle/mod.rs:53-80` presents `WorkflowLifecycle` as the
+  callback owner, and `lifecycle/git.rs:77-93, 397-401` gives `GitLifecycle`
+  its own `last_git_sha` state. The normal `RunSession::run` path nevertheless
+  creates a second `last_git_sha`, reconstructs it by listening to emitted
+  checkpoint, terminal, and Git events, then passes it back into finalization
+  (`operations/start.rs:821-856, 914-923`). Terminal responsibility is split
+  again: engine outcomes become terminal events in
+  `pipeline/finalize.rs:524-596`, while bootstrap, initialization, and
+  finalization errors become `run.failed` through the outer operation in
+  `operations/start.rs:176-285, 288-346`. These crossings occur on the normal
+  run and error paths, not at an optional edge.
+- **Strongest counterevidence:** `operations/start.rs:796-953` is a recognizable
+  top-level owner for the initialize → execute → finalize → pull-request
+  sequence, and `WorkflowLifecycle` explicitly orders focused delegates for
+  each executor callback (`lifecycle/mod.rs:221-469`).
+- **Why adjacent scores do not fit:** 3 does not fit because the caller always
+  mirrors and resupplies Git identity on the common run path, and terminal
+  failure handling routinely selects between two owners. 1 does not fit because
+  both the executor callback owner and the outer run-session owner are stable
+  and traceable; the problem is their competition, not the absence of owners.
+- **Rule discrimination:** Decision rule 2 is decisive for the mirrored
+  `last_git_sha`. The phrase “complete lifecycle” is otherwise ambiguous about
+  whether an executor lifecycle may end before durability finalization; the
+  explicit state round-trip makes the result 2 without relying on that
+  ambiguity.
+
+### `domain-model`: 2
+
+- **Evidence:** The internal durable event shape stores
+  `Event::StageCompleted.status` as `String`
+  (`event/events.rs:264-272`). Both synthetic terminal-stage completion and
+  ordinary successful stage completion stringify the canonical
+  `StageOutcome` (`lifecycle/event.rs:215-240, 355-366`), after which the
+  mandatory event conversion reparses it and converts an unknown value to
+  `Failed` (`event/convert.rs:14-24, 309-333`). This typed → string → typed path
+  is part of every successful stage-completion event.
+- **Strongest counterevidence:** `fabro_types::StageOutcome` is a stable
+  canonical type, most event fields are typed, and the fallback prevents an
+  unrecognized string from escaping into the stored projection.
+- **Why adjacent scores do not fit:** 3 does not fit because common production
+  completion events depend on the invalid intermediate rather than using it as
+  a compatibility edge. 1 does not fit because the canonical status meaning is
+  clear and the conversion point is explicit.
+- **Rule discrimination:** Decision rule 4 and the rubric's repository example
+  make this assignment unambiguous.
+
+## `fabro-http`
+
+### `domain-model`: 4
+
+- **Evidence:** `ProxyPolicy` is a closed `System | Disabled` vocabulary;
+  parsing rejects every other boundary value
+  (`src/lib.rs:23-35`). Resolution gives explicit configuration precedence over
+  the environment, defaults absence to `System`, and rejects non-Unicode input
+  (`src/lib.rs:38-60`). Every async and blocking builder reaches that resolver
+  before construction (`src/lib.rs:160-166, 172-193`), while the deterministic
+  test helpers select the typed `Disabled` value
+  (`src/lib.rs:195-213`).
+- **Strongest counterevidence:** The builder also exposes raw `no_proxy()` and
+  `proxy()` operations (`src/lib.rs:96-106`), so callers can combine an
+  underlying reqwest choice with `ProxyPolicy`; Unix-socket production callers
+  do use `no_proxy()` (`lib/foundation/fabro-client/src/client.rs:2123-2134`).
+- **Why adjacent scores do not fit:** 3 does not fit because the common
+  policy-controlled constructors never interpret an invalid policy: they
+  return `HttpClientBuildError`. The raw builder operations represent valid
+  per-client transport configuration, not a second string vocabulary. 2 and 1
+  do not fit because no common-path conversion or unstable meaning is present.
+- **Rule discrimination:** Decision rule 4 is potentially non-discriminating
+  if every forwarded low-level builder method is called an “escape hatch.”
+  Here `no_proxy()` carries no invalid intermediate and does not weaken
+  `ProxyPolicy::resolve`, so treating it as ordinary typed builder
+  configuration preserves the rule's distinction.
+
+### `duplication-knowledge`: 4
+
+- **Evidence:** `define_builder!` holds the complete shared async/blocking
+  builder policy once, including proxy resolution and construction
+  (`src/lib.rs:72-170`), and is instantiated for the two reqwest client kinds
+  (`src/lib.rs:172-193`). The four convenience constructors delegate to those
+  builders rather than reproducing policy (`src/lib.rs:195-213`).
+- **Strongest counterevidence:** The generated facade necessarily lists each
+  forwarded reqwest method, and the test and non-test convenience constructors
+  have similar bodies.
+- **Why adjacent scores do not fit:** 3 does not fit because the similar
+  forwarding and wrappers are syntax over one policy authority, not separately
+  maintained transport knowledge. 2 does not fit because a proxy-policy change
+  is made once in the macro/resolver, not synchronized across async and
+  blocking implementations. 1 does not fit because the authority is explicit.
+- **Rule discrimination:** The rubric's `define_builder!` example directly
+  distinguishes shared macro expansion from semantic duplication; no material
+  ambiguity remains.
+
+## `fabro-web-app`
+
+### `ownership-boundaries`: 4
+
+- **Evidence:** `entry.tsx:17-49` owns browser startup, chooses the normal or
+  installation route graph once, and installs shared SWR runtime policy.
+  `router.tsx:97-184` owns normal route composition. Shared transport and error
+  handling live in `lib/api-client.ts:64-160, 213-310`; shared reads such as
+  `useRun` and `useRunState` live in `lib/queries.ts:182-193`; run mutations and
+  their cache lifecycle live in `lib/mutations.ts:65-132`; and run-scoped SSE
+  subscription, invalidation, resync, and cleanup live in
+  `lib/run-events.ts:129-309`. The representative busy route composes those
+  owners rather than reimplementing them
+  (`routes/run-detail.tsx:79-145, 313-379`).
+- **Strongest counterevidence:** Some route-local CRUD actions call the shared
+  API facade directly, and `run-detail.tsx:193-205` coordinates delete state,
+  cache invalidation, toast, and navigation in the route.
+- **Why adjacent scores do not fit:** 3 does not fit because the counterevidence
+  is local page UX ownership; it does not split a shared transport, read,
+  mutation, or subscription lifecycle. 2 does not fit because routine run-page
+  changes use the established owners rather than coordinating competing ones.
+  1 does not fit because startup, routing, transport, caching, and streaming
+  each have readily identifiable homes.
+- **Rule discrimination:** “One owner” is mildly non-discriminating for a large
+  browser application unless responsibility is evaluated at lifecycle
+  granularity. Using the rubric's `apiData`/`useRun` example, route composition
+  is not itself a second owner. Confidence is Medium because this is the
+  largest sampled scope.
+
+## `repository-ci`
+
+### `ownership-boundaries`: 4
+
+- **Evidence:** `rust.yml:3-40` owns Rust branch/PR/manual triggers and
+  concurrency, while its jobs contain format, lint, generated-doc, Linux test,
+  twin E2E, and manual macOS lifecycles (`rust.yml:48-147`).
+  `typescript.yml:3-34` owns the corresponding TypeScript triggers and
+  concurrency, and its jobs contain typecheck, test, and integrated SPA/Rust
+  build lifecycles (`typescript.yml:36-77`). Delegation to `cargo dev` is the
+  mapped dependency on build tooling, not reverse ownership.
+- **Strongest counterevidence:** The TypeScript build invokes a Rust build
+  (`typescript.yml:75-77`), and invalid path selectors mean some intended
+  changes do not start the declared workflows.
+- **Why adjacent scores do not fit:** 3 does not fit because the cross-language
+  build is the intentional embedded-SPA integration boundary, not friction, and
+  selector validity is classified under domain model by decision rule 6. 2
+  does not fit because no routine job requires coordination between competing
+  CI owners. 1 does not fit because the two language validation homes and their
+  dependency direction are explicit.
+- **Rule discrimination:** The score-4 phrase “complete lifecycle” is
+  non-discriminating for hosted CI if it is read to require repository
+  ownership of GitHub's runner lifecycle. This score treats the checked-in
+  trigger/job lifecycle as the mapped responsibility and the platform as an
+  intended boundary.
+
+### `domain-model`: 2
+
+- **Evidence:** Both Rust trigger selectors name `openapi/**`
+  (`rust.yml:18,34`), but that revision has no tracked target there; the actual
+  API contract is `docs/public/api-reference/fabro-api.yaml`, which the
+  TypeScript client generation command consumes
+  (`lib/packages/fabro-api-client/package.json:7`). The real contract path is
+  absent from both workflow path filters. In addition, all three zizmor
+  `stale-action-refs` identifiers target `rust.yml:37`, `:49`, and `:62`
+  (`zizmor.yml:1-6`), which are respectively the end of trigger setup, the
+  `fmt` job key, and a `run` command—not action references at this revision.
+  These invalid identifiers sit directly in trigger and static-validation
+  configuration.
+- **Strongest counterevidence:** The workflow/job vocabulary itself is stable,
+  all jobs and action pins have clear meanings, and changes under the large
+  valid Rust and TypeScript source selectors do trigger their expected suites.
+- **Why adjacent scores do not fit:** 3 does not fit because the dead OpenAPI
+  selector is present in both routine branch and PR paths, while every scoped
+  zizmor exception lacks a current target. 1 does not fit because the overall
+  workflow and job model remains stable; the defect is a recurring set of
+  invalid identifiers.
+- **Rule discrimination:** Decision rule 6 is decisive that these are domain
+  pressure rather than ownership or duplication. It does not state when one or
+  more dead selectors move from 3 to 2; centrality in both trigger modes and
+  total staleness of the scoped zizmor selectors supply that discrimination
+  here.
+
+## Control: `fabro-checkpoint`
+
+### `ownership-boundaries`: 2
+
+- **Evidence:** The mapped component claims metadata branches, but its
+  production boundary consumer owns the metadata writer's branch, parent OID,
+  discovery, remote, and push lifecycle
+  (`fabro-workflow/src/run_metadata.rs:272-282, 313-439`). On every snapshot,
+  that caller validates entries, individually drives `Store` through blobs,
+  tree, commit, and ref update, and retains the parent identity for the next
+  write (`run_metadata.rs:313-350`). `BranchStore` provides a contained
+  read-modify-write owner (`branch.rs:17-24, 42-81`) but has no production
+  caller at this revision.
+- **Strongest counterevidence:** The dependency direction is intended
+  (`fabro-workflow` depends on `fabro-checkpoint`), and the low-level `Store`
+  consistently owns Git object/ref operations (`git.rs:101-227`).
+- **Why adjacent scores do not fit:** 3 does not fit because the lifecycle
+  crossing occurs on every metadata snapshot, not in an isolated adapter. 1
+  does not fit because low-level Git ownership and the caller's higher-level
+  writer ownership are both stable; the problem is the split between them.
+- **Rule discrimination:** Decision rule 2 applies because the caller retains
+  and resupplies branch/parent identity to complete successive writes. The
+  rubric does not say whether a deliberately low-level `Store` narrows the
+  mapped ownership claim; the explicit mapped claim to metadata branches makes
+  this crossing discriminating.
+
+### `simplicity`: 4
+
+- **Evidence:** The production `Store` has direct blob, tree, commit, and ref
+  operations (`git.rs:123-226`). Tree conversion is a single read recursion and
+  a single bottom-up write path (`git.rs:229-310`). At the higher level,
+  `BranchStore::write_with` is a linear resolve → read → mutate → write → commit
+  → update sequence (`branch.rs:56-81`), and entry operations are small
+  delegates (`branch.rs:84-117`). Necessary Git layering is visible rather than
+  hidden behind competing configuration machinery.
+- **Strongest counterevidence:** There are two entry levels, and the production
+  metadata writer uses the lower-level `Store` instead of `BranchStore`.
+- **Why adjacent scores do not fit:** 3 does not fit because choosing the
+  low-level entry is required for replace-whole-tree and remote-parent behavior,
+  not unnecessary indirection. 2 does not fit because the scoped common
+  operations do not navigate competing implementations or configuration. 1
+  does not fit because both paths are directly traceable.
+- **Rule discrimination:** Ownership rule 2 could otherwise cause the
+  out-of-scope metadata writer's machinery to be counted again as simplicity
+  friction. The lens exclusions make that non-discriminating evidence here;
+  within the scoped implementation, the production primitives are direct.
+
+### `domain-model`: 2
+
+- **Evidence:** `TreeEntries::set` accepts any `String` path without validation
+  (`git.rs:46-60`), and `write_tree` later interprets it by splitting on `/`
+  (`git.rs:149-153, 270-293`). The common metadata caller must therefore define
+  and apply `validate_metadata_path` outside this component before every
+  `TreeEntries` construction
+  (`fabro-workflow/src/run_metadata.rs:313-332, 471-480`). The component also
+  maps every unrecognized Git file mode to `Blob`
+  (`git.rs:21-35, 229-250`) rather than rejecting an unsupported state.
+- **Strongest counterevidence:** `FileMode` is otherwise a closed enum, Git
+  object IDs use `git2::Oid`, and the current production metadata caller does
+  reject empty, absolute, dot-segment, and empty-segment paths before writing.
+- **Why adjacent scores do not fit:** 3 does not fit because external path
+  validation is mandatory on every common metadata snapshot and the canonical
+  `TreeEntries` shape can always hold an invalid path. 1 does not fit because
+  the intended path and mode meanings remain clear and production does have a
+  validation step.
+- **Rule discrimination:** Decision rule 4 clearly places the caller-validated
+  `TreeEntries` intermediate at 2. Whether unknown Git modes are a compatibility
+  escape hatch is ambiguous by itself, but it is not needed to choose the
+  score.
+
+### `duplication-knowledge`: 3
+
+- **Evidence:** Branch-to-full-ref formatting is repeated in `Store::update_ref`,
+  `resolve_ref`, and `delete_ref` (`git.rs:182-225`), and the boundary metadata
+  writer has another `full_ref` transformation
+  (`fabro-workflow/src/run_metadata.rs:364-439`). `BranchStore::read_entry`,
+  `read_entries`, `list_entries`, and `tip_tree` also repeat parts of branch-tip
+  resolution (`branch.rs:119-184`). These repetitions are local and stable, but
+  there is no single helper enforcing them.
+- **Strongest counterevidence:** Mutation sequencing is authoritative in
+  `BranchStore::write_with` (`branch.rs:56-81`), metadata branch naming has one
+  `META_BRANCH_PREFIX` constant (`lib.rs:7`), Git-author defaults have one
+  `Default` implementation (`author.rs:13-20`), and the repeated ref syntax is a
+  fixed Git protocol form rather than frequently changing Fabro policy.
+- **Why adjacent scores do not fit:** 4 does not fit because ref normalization
+  and branch-tip traversal are still represented in several places. 2 does not
+  fit because there is no direct evidence that a routine checkpoint change
+  must alter those stable protocol transformations in sync; the repetitions are
+  isolated implementation knowledge. 1 does not fit because each policy has an
+  identifiable local authority even where a helper is absent.
+- **Rule discrimination:** Decision rule 5 leaves a real 3-versus-4 ambiguity:
+  repeated `refs/heads/` can be classified as harmless protocol syntax. I score
+  3 because the same branch-to-ref transformation crosses the component
+  boundary, but do not score 2 without evidence of routine synchronization.
+
+## Overall rubric observations
+
+- Decision rule 2 successfully distinguishes focused delegates from a lifecycle
+  that sends identity back through an event/caller round trip.
+- Decision rule 6 prevents dead CI selectors from being double-counted as
+  ownership defects, but needs centrality/recurrence evidence to distinguish 2
+  from 3.
+- “One owner” and “complete lifecycle” need responsibility-sized interpretation
+  for route trees and hosted CI; otherwise healthy composition cannot reach 4.
+- Decision rule 5 correctly keeps stable protocol repetition from automatically
+  becoming score 2, but the line between harmless syntax and a repeated
+  transformation remains the least discriminating part of this sample.
+
+## Round 2 revalidation
+
+| Component | Lens | Score | Confidence |
+|---|---|---:|---|
+| `fabro-http` | `duplication-knowledge` | 3 | Medium |
+| `repository-ci` | `ownership-boundaries` | 2 | High |
+| `fabro-checkpoint` | `ownership-boundaries` | 2 | High |
+| `fabro-checkpoint` | `simplicity` | 3 | High |
+| `fabro-checkpoint` | `domain-model` | 2 | High |
+| `fabro-checkpoint` | `duplication-knowledge` | 3 | Medium |
+
+### `fabro-http` × `duplication-knowledge`: 3
+
+- **Decisive evidence:** Proxy disabling has two concrete semantic
+  representations in the mapped entry layer: callers may set
+  `ProxyPolicy::Disabled` (`src/lib.rs:23-27, 90-94`), or call the separately
+  exposed `no_proxy()` builder operation (`src/lib.rs:96-100`). The former is
+  interpreted by calling the same underlying `inner.no_proxy()` transformation
+  during `build` (`src/lib.rs:160-165`). Both forms are used on direct boundary
+  paths: test constructors select the enum (`src/lib.rs:199-213`), while the
+  Unix-socket transport selects `no_proxy()`
+  (`lib/foundation/fabro-client/src/client.rs:2123-2134`).
+- **Adjacent scores:** 4 does not fit revised rule 6 because there is a concrete
+  second representation of the same no-proxy decision. 2 does not fit because
+  an ordinary proxy-policy extension does not require manually synchronizing
+  those call sites; async and blocking policy construction still share the one
+  `define_builder!` mechanism (`src/lib.rs:72-193`). 1 does not fit because the
+  resolver remains a stable authority.
+- **Remaining ambiguity:** `no_proxy()` can reasonably be viewed as a lower-level
+  reqwest operation rather than a second Fabro policy. Revised rule 6 makes 3
+  the conservative result because `ProxyPolicy::Disabled` is implemented by
+  that exact operation, but this classification keeps confidence at Medium.
+
+### `repository-ci` × `ownership-boundaries`: 2
+
+- **Decisive evidence:** The Rust check explicitly scans
+  `docs/public/api-reference/fabro-api.yaml` in its legacy-identity guard
+  (`rust.yml:80-92`), but neither push nor pull-request triggers include that
+  real path (`rust.yml:3-35`); they include the nonexistent `openapi/**`
+  selector instead (`rust.yml:18,34`). A routine API-contract change can
+  therefore change a scanned target without starting its owning check.
+- **Adjacent scores:** 3 does not fit because the non-triggering target is on a
+  routine branch/PR check path, not an isolated manual edge. 1 does not fit
+  because the workflow, jobs, and intended trigger owner remain identifiable.
+  4 is directly excluded by revised rule 3's trigger-coverage requirement.
+- **Remaining ambiguity:** `typescript.yml:76` also invokes a Rust build from a
+  narrower trigger set, but that broader interpretation is unnecessary; the
+  explicitly scanned, non-triggering API contract is sufficient for 2.
+
+### `fabro-checkpoint` × `ownership-boundaries`: 2
+
+- **Decisive evidence:** The mapped owner exposes low-level `Store` primitives,
+  while the routine metadata caller reconstructs the mapped branch lifecycle:
+  `RunMetadataWriter` owns branch, parent, and discovery state
+  (`fabro-workflow/src/run_metadata.rs:272-282`), then validates entries and
+  sequences blob, tree, commit, ref update, and retained parent state on every
+  snapshot (`run_metadata.rs:313-350`). No production boundary uses the
+  component's higher-level `BranchStore`.
+- **Adjacent scores:** 3 does not fit because every metadata snapshot traverses
+  the split. 1 does not fit because the low-level Git owner and caller-side
+  lifecycle are both stable. 4 is directly excluded by revised rule 2: the
+  routine caller reconstructs a lifecycle the map assigns to this component.
+- **Remaining ambiguity:** A narrower map that assigned only Git object
+  primitives to `fabro-checkpoint` could make this healthy delegation, but the
+  actual map explicitly assigns metadata branches and checkpoint commits.
+
+### `fabro-checkpoint` × `simplicity`: 3
+
+- **Decisive evidence:** `Cargo.toml:16-24` carries `fabro-store` as a production
+  dependency, but scoped production code does not use it. The component also
+  exposes `BranchStore` as a parallel entry layer (`branch.rs:17-24`) that has
+  no production caller at this revision; the common metadata path uses `Store`
+  directly. The active `Store` path itself remains linear and direct
+  (`git.rs:123-226`).
+- **Adjacent scores:** 4 is explicitly capped at 3 by revised rule 4 for the
+  unused production dependency and parallel unused entry layer. 2 does not fit
+  because routine production work does not repeatedly navigate those unused
+  elements; its `Store` path is direct. 1 does not fit because a stable common
+  path is easy to trace.
+- **Remaining ambiguity:** Either isolated fact independently supplies the
+  revised rule's cap, so there is no material score ambiguity.
+
+### `fabro-checkpoint` × `domain-model`: 2
+
+- **Decisive evidence:** `TreeEntries::set` accepts arbitrary string paths
+  (`git.rs:46-60`) before `write_tree` interprets them structurally
+  (`git.rs:149-153, 270-293`). Every common metadata snapshot must validate
+  those paths outside the mapped entry before constructing `TreeEntries`
+  (`fabro-workflow/src/run_metadata.rs:313-332, 471-480`).
+- **Adjacent scores:** 3 does not fit revised rule 5 because caller validation
+  does not isolate an invalid-capable mapped entry used on every snapshot. 1
+  does not fit because path meaning is stable and the caller does enforce it.
+  4 is excluded because the canonical entry type itself admits invalid states.
+- **Remaining ambiguity:** Unknown Git modes also collapse to `Blob`
+  (`git.rs:21-35`), but that compatibility question is not needed for the
+  score; the routine path shape is decisive.
+
+### `fabro-checkpoint` × `duplication-knowledge`: 3
+
+- **Decisive evidence:** The short branch name is converted to
+  `refs/heads/{branch}` independently in `Store::update_ref`, `resolve_ref`, and
+  `delete_ref` (`git.rs:182-225`), while the routine boundary writer carries a
+  second `full_ref` conversion
+  (`fabro-workflow/src/run_metadata.rs:364-439`). These are concrete repeated
+  representations, but of stable Git protocol knowledge.
+- **Adjacent scores:** 4 does not fit revised rule 6 because the
+  branch-to-full-ref transformation has a concrete second representation. 2
+  does not fit because no ordinary mapped change is shown to require
+  synchronizing the stable Git namespace transformations; repeated call sites
+  alone are insufficient. 1 does not fit because the transformation and its
+  local authorities are clear.
+- **Remaining ambiguity:** The literal can also be classified as harmless Git
+  syntax, which the lens excludes. Its repetition across the mapped boundary
+  supports 3, but the harmless-syntax distinction keeps confidence at Medium.

.chisel/calibration/work/validation-2.md

@@ -0,0 +1,450 @@
+# Chisel calibration validation 2
+
+Revision reviewed: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`
+
+This is an independent reading of the final rubric. I did not seek or infer
+earlier scores.
+
+## Scores
+
+| Component | Lens | Score | Evidence confidence |
+|---|---|---:|---|
+| `fabro-workflow` | `ownership-boundaries` | 2 | High |
+| `fabro-workflow` | `domain-model` | 2 | High |
+| `fabro-http` | `domain-model` | 4 | High |
+| `fabro-http` | `duplication-knowledge` | 4 | Medium |
+| `fabro-web-app` | `ownership-boundaries` | 4 | Medium |
+| `repository-ci` | `ownership-boundaries` | 2 | High |
+| `repository-ci` | `domain-model` | 2 | High |
+| `fabro-checkpoint` | `ownership-boundaries` | 4 | Medium |
+| `fabro-checkpoint` | `simplicity` | 4 | Medium |
+| `fabro-checkpoint` | `domain-model` | 3 | Medium |
+| `fabro-checkpoint` | `duplication-knowledge` | 2 | Medium |
+
+## Disputed assignments
+
+### `fabro-workflow` × `ownership-boundaries` — 2
+
+**Direct evidence.** `WorkflowLifecycle` is a real central owner for engine
+callback ordering: it contains the event, hook, fidelity, status, circuit
+breaker, git, and artifact delegates and orders them in every callback
+(`src/lifecycle/mod.rs:53-80`, `223-470`). The full run lifecycle nevertheless
+crosses that owner on normal paths. `WorkflowLifecycle::on_run_end` only runs
+the hook (`src/lifecycle/mod.rs:467-469`); `pipeline::finalize` separately builds
+and emits the terminal event and stops the sandbox
+(`src/pipeline/finalize.rs:524-635`); `RunSession::run` separately owns
+initialize/execute/finalize, progress flushing, steering drain, and a second
+sandbox cleanup guard (`src/operations/start.rs:796-953`); detached bootstrap
+and completion guards own additional terminal-failure paths
+(`src/operations/start.rs:956-1139`). A routine change to terminal ordering or
+cleanup must account for these owners.
+
+**Strongest counterevidence.** The split is deliberate. In particular,
+`finalize` documents why the terminal event must follow metadata flushing, and
+the scope guards cover panic/interruption paths that an async lifecycle callback
+cannot reliably cover.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because the split is on
+every ordinary terminal path, not an isolated compatibility path. Score 1 does
+not fit because the owners and dependency direction are identifiable:
+`RunSession` is the outer orchestrator and `WorkflowLifecycle` consistently owns
+engine callbacks.
+
+**Rule discrimination.** Decision rule 2 is useful here, but “complete routine
+lifecycle operations” must include terminal emission and resource cleanup, not
+only engine callbacks. Without that reading, the positive orchestrator example
+could make 3 and 2 hard to distinguish.
+
+### `fabro-workflow` × `domain-model` — 2
+
+**Direct evidence.** The canonical execution result is the typed
+`StageOutcome`, re-exported in `src/outcome.rs:1-12`. The common stage-completion
+event instead stores `status: String` (`src/event/events.rs:264-293`).
+`EventLifecycle::after_node` converts the typed value to a string for every
+successful completion (`src/lifecycle/event.rs:319-378`), and
+`event_body_from_event` reparses it into `StageOutcome`
+(`src/event/convert.rs:309-348`). Unknown strings are silently reinterpreted as
+a non-retryable failure (`src/event/convert.rs:14-24`). The same string
+intermediate is used for synthetic terminal stages
+(`src/lifecycle/event.rs:183-242`).
+
+**Strongest counterevidence.** Durable `fabro_types::StageCompletedProps` is
+typed, and ordinary producers derive the string from a typed value rather than
+accepting arbitrary user text.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because the conversion
+and invalid intermediate occur on the common event path for every completed
+stage. Score 1 does not fit because `StageOutcome` supplies a stable canonical
+meaning and most execution code uses it directly.
+
+**Rule discrimination.** Decision rule 4 and the repository example are
+decisive. The rule would be non-discriminating if “compatibility escape hatch”
+were allowed to describe the central `Event` type merely because the durable
+type is healthier.
+
+### `fabro-http` × `domain-model` — 4
+
+**Direct evidence.** `ProxyPolicy` is a closed two-variant vocabulary
+(`src/lib.rs:23-27`). The environment boundary parses case-insensitively and
+rejects every other value with a typed `HttpClientBuildError`
+(`src/lib.rs:29-70`). Explicit policy has a documented precedence in
+`resolve_with_env_value`, and both async and blocking builders resolve the
+policy immediately before applying it (`src/lib.rs:38-59`, `160-166`,
+`172-193`). The common production and test constructors all pass through those
+builders (`src/lib.rs:195-213`).
+
+**Strongest counterevidence.** The builders also expose the lower-level
+`no_proxy()` and `proxy()` methods (`src/lib.rs:96-106`), so callers can express
+transport configuration outside the high-level enum.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because the lower-level
+methods are intentional reqwest-facade escape hatches; the common constructors
+and environment boundary do not rely on an invalid or ambiguous policy value.
+There is positive production enforcement rather than a test-only contract.
+
+**Rule discrimination.** Decision rule 4 discriminates well if “low-level
+escape hatch” is read literally. If any alternate builder method were treated
+as a second domain meaning, scores 3 and 4 would become difficult to distinguish
+for facades.
+
+### `fabro-http` × `duplication-knowledge` — 4
+
+**Direct evidence.** `define_builder!` is one production mechanism for all
+shared async/blocking builder methods and for applying proxy policy
+(`src/lib.rs:72-170`); the two concrete builders are declarations of that
+mechanism (`src/lib.rs:172-193`). `ProxyPolicy::resolve` is the single authority
+for explicit-versus-environment precedence (`src/lib.rs:38-59`), and the four
+convenience constructors delegate to the builders (`src/lib.rs:195-213`).
+Workspace boundary evidence reinforces this authority: `clippy.toml` disallows
+raw reqwest client constructors in favor of these functions/builders.
+
+**Strongest counterevidence.** The tokens `system` and `disabled` also appear in
+the human-readable error text, and the async/blocking test constructors repeat
+the choice of `ProxyPolicy::Disabled`.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because the repeated
+tokens and two one-line convenience constructors do not form independent
+authorities for a recurring transformation. The macro and resolver are what
+enforce behavior.
+
+**Rule discrimination.** Decision rule 5 is useful but leaves a small judgment
+gap around repeated diagnostic vocabulary. Here that repetition is
+non-discriminating: adding a variant would make the exhaustive application
+match fail to compile, while one diagnostic sentence is not a second policy
+engine. This is why confidence is Medium rather than High.
+
+### `fabro-web-app` × `ownership-boundaries` — 4
+
+**Direct evidence.** Shared HTTP configuration, authentication redirect, and
+error normalization live in `app/lib/api-client.ts:64-160,213-309`. Read state
+and cache keys live in `app/lib/queries.ts` and
+`app/lib/query-keys.ts`; for example, `useRun` owns the run-detail fetch/cache
+lifecycle (`queries.ts:182-187`). Shared run mutations and their cache updates
+live in `app/lib/mutations.ts:42-208`. Run SSE connection sharing, cleanup, and
+cache invalidation live in `app/lib/sse.ts:42-189` and
+`app/lib/run-events.ts:129-308`. Browser resources with more specialized
+lifecycles are likewise contained: terminal WebSocket/xterm/listener cleanup is
+in `app/hooks/use-terminal-session.ts:62-229`, and install polling owns its
+timer, interval, and abort controller in
+`app/hooks/use-install-effects.ts:72-127`.
+
+`RunDetail` composes these owners and retains view-local state and interaction
+ordering (`app/routes/run-detail.tsx:79-145,148-379`). Its size does not make it
+the owner of transport or resource cleanup.
+
+**Strongest counterevidence.** Several feature routes perform feature-local
+create/edit/delete calls and SWR invalidation directly, and `RunDetail` owns the
+delete dialog, pending state, toast, list invalidation, and navigation
+(`run-detail.tsx:193-205`) rather than using a single mutation hook for that
+entire interaction.
+
+**Why adjacent scores do not fit.** Score 3 does not fit without a concrete
+isolated lifecycle that has competing owners. The direct route mutations keep
+their feature interaction lifecycle local and still use the shared transport;
+they are not evidence that ordinary reads, SSE, or browser resources leak into
+route composition.
+
+**Rule discrimination.** The final repository example is discriminating:
+“busy route” must not itself count as boundary leakage. Confidence remains
+Medium because the application scope is broad, although the representative
+read, mutation, live-update, terminal, install, and route boundaries converge.
+
+### `repository-ci` × `ownership-boundaries` — 2
+
+**Direct evidence.** The Rust workflow’s Clippy job owns a repository-wide
+“legacy auth identity removal” guard that scans `lib/apps`, `lib/components`,
+`lib/foundation`, `apps`, `lib/packages`, and the OpenAPI document
+(`.github/workflows/rust.yml:80-91`). The workflow’s path filters do not include
+`apps/**`, `lib/packages/**`, or
+`docs/public/api-reference/fabro-api.yaml`
+(`rust.yml:3-35`). A routine change in a scanned TypeScript/package/API path can
+therefore introduce a forbidden identity without starting the job that owns the
+guard. The policy lifecycle is placed under a narrower Rust trigger than the
+responsibility it claims.
+
+**Strongest counterevidence.** The primary Rust and TypeScript build/test
+responsibilities otherwise have clear workflow homes, read-only permissions,
+and stable concurrency ownership (`rust.yml:38-147`;
+`typescript.yml:30-77`). The TypeScript production build’s Rust step is a
+legitimate composition point because it builds the Rust binary with the
+embedded SPA.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because the trigger
+mismatch affects ordinary changes in multiple scanned source areas, not an
+isolated maintenance path. Score 1 does not fit because the two main language
+workflows and their jobs still have stable owners and dependency direction.
+
+**Rule discrimination.** No final rule explicitly says how to classify a check
+whose declared scan scope exceeds its trigger scope. The ownership lens’s
+“complete lifecycle” language is sufficient, but an explicit trigger/target
+coverage rule would make 2 versus 3 less ambiguous.
+
+### `repository-ci` × `domain-model` — 2
+
+**Direct evidence.** Every value in `.github/zizmor.yml` is a line-addressed
+identifier: `rust.yml:37`, `rust.yml:49`, and `rust.yml:62`
+(`.github/zizmor.yml:1-6`). At this revision those lines are respectively a
+blank separator, the `fmt` job key, and a `run:` step—not action references.
+Thus none is a current target for the configured `stale-action-refs` ignores.
+Routine edits to `rust.yml` can change the accidental referents again without
+changing the selectors.
+
+**Strongest counterevidence.** The syntax still communicates an intended
+workflow-and-line selector, and the main workflow job/status vocabulary is
+otherwise stable.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because all three
+values in the entire scoped zizmor configuration lack their intended current
+referent; this is not one isolated compatibility value. Score 1 does not fit
+because the selector format and intended concept remain identifiable even
+though the instances are stale.
+
+**Rule discrimination.** Decision rule 6 is decisive and correctly keeps this
+under domain model rather than ownership. It would not by itself distinguish 2
+from 3; the fact that every configured identifier is stale and line edits make
+the condition recur supplies that distinction.
+
+## Control: `fabro-checkpoint`
+
+### `fabro-checkpoint` × `ownership-boundaries` — 4
+
+**Direct evidence.** `git::Store` owns the `git2::Repository` and the low-level
+blob/tree/commit/ref operations (`src/git.rs:101-227`).
+`branch::BranchStore` owns branch identity, author identity, and the complete
+local read-modify-write lifecycle, including parent resolution, tree read,
+commit, and ref update (`src/branch.rs:17-82`). Author and trailer concerns are
+focused modules rather than state hidden in callers (`src/author.rs`;
+`src/trailer.rs`). Boundary evidence points in the intended direction:
+`fabro-workflow` depends on these primitives, while its
+`RunMetadataWriter` owns the additional temp repository, remote discovery,
+credentials, push, and degradation lifecycle. That is a higher-level owner
+using a lower-level delegate, not a reverse dependency.
+
+**Strongest counterevidence.** The production metadata writer uses `Store`
+directly and manually sequences blob, tree, commit, and ref operations
+(`fabro-workflow/src/run_metadata.rs:313-361`) instead of using `BranchStore`.
+The crate name/description can make that look like the mapped checkpoint
+lifecycle has escaped the component.
+
+**Why adjacent scores do not fit.** Score 3 does not fit if responsibilities are
+classified by their actual state: `Store` owns local Git mechanics,
+`BranchStore` owns local branch writes, and `RunMetadataWriter` owns remote run
+metadata. No concrete resource is acquired by one of those owners and released
+by another.
+
+**Rule discrimination.** Decision rule 2 is ambiguous for intentionally
+low-level facades. Passing a branch to `Store::update_ref` should not alone mean
+“resupplying identity” when the caller owns the higher-level remote branch
+lifecycle and `Store` never claimed it. If the mapped purpose is instead read
+as all run-checkpoint lifecycle, this assignment could become 2; that purpose
+boundary should be fixed before using the control for strict agreement.
+
+### `fabro-checkpoint` × `simplicity` — 4
+
+**Direct evidence.** The local branch write path is linear in
+`BranchStore::write_with`: resolve parent, read tree, apply one caller mutation,
+write tree, commit, update ref (`src/branch.rs:56-81`). Single-file,
+multi-file, and delete operations are thin delegates to that path
+(`src/branch.rs:84-117`). The lower-level tree conversion is one direct
+flat-to-nested algorithm (`src/git.rs:229-309`), and trailer formatting/parsing
+uses straightforward local control flow (`src/trailer.rs:9-87`).
+
+**Strongest counterevidence.** `BranchStore` has no external production caller
+at this revision; the actual metadata path uses the lower-level `Store` API.
+There is also some unused-looking surface such as `MetadataError` and generic
+branch read/list/log helpers.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because no direct
+production evidence shows routine changes navigating the unused surface or
+competing implementations. The production `Store` call sequence is itself
+linear. The rubric explicitly says a public method alone does not establish
+frequency, so unused API breadth cannot by itself create common-path
+indirection.
+
+**Rule discrimination.** The score-4 requirement for a “production mechanism”
+is mildly ambiguous when the clearest high-level mechanism has no production
+caller but its lower-level mechanism does. Treating compiled non-test code as
+sufficient would make the rule non-discriminating; this score instead relies on
+the directly used `Store` path also being traceable.
+
+### `fabro-checkpoint` × `domain-model` — 3
+
+**Direct evidence.** The common metadata boundary validates every path before
+putting it into `TreeEntries`
+(`fabro-workflow/src/run_metadata.rs:319-336,471-481`), explicitly selects
+`FileMode::Blob`, and converts author strings with the fallible
+`git2::Signature::now` before committing (`run_metadata.rs:337-345`). Within the
+control, `FileMode` and `TreeEntries` give Git tree entries a stable meaning
+(`src/git.rs:13-99`), and Git failures stay typed (`src/error.rs:3-32`).
+
+There is nevertheless isolated model friction. `TreeEntries::set` accepts any
+string path with no invariant-bearing path type (`src/git.rs:59-61`);
+`FileMode::from_i32` maps every unrecognized Git mode to `Blob`
+(`src/git.rs:30-35`); `GitAuthor` has public raw string fields
+(`src/author.rs:6-11`); and `BranchStore` says trees grow monotonically while
+also exposing `delete_entry` (`src/branch.rs:17-19,111-117`).
+
+**Strongest counterevidence.** These are not merely hypothetical invalid
+shapes: low-level public callers can bypass the production metadata-path
+validation, and Git supports meaningful modes omitted by `FileMode`.
+
+**Why adjacent scores do not fit.** Score 4 does not fit because the low-level
+types themselves do not reject invalid paths/authors or preserve every Git
+mode. Score 2 does not fit because the directly traced production metadata path
+validates before interpretation and does not depend on the fallback
+`from_i32`; the friction is in lower-level escape paths and the currently
+unused `BranchStore`, not every common snapshot.
+
+**Rule discrimination.** Decision rule 4 is useful but ambiguous about whether
+a common caller validating raw values before a low-level API counts as a
+“common-path invalid intermediate.” The rule should distinguish an actually
+reparsed/ambiguous value from a raw value that has already passed one boundary
+check but lacks an invariant-bearing Rust type.
+
+### `fabro-checkpoint` × `duplication-knowledge` — 2
+
+**Direct evidence.** The branch-name-to-full-ref transformation
+`refs/heads/{branch}` is repeated independently in `Store::update_ref`,
+`Store::resolve_ref`, and `Store::delete_ref`
+(`src/git.rs:182-225`). The direct production boundary repeats it again in
+`RunMetadataWriter::full_ref`
+(`fabro-workflow/src/run_metadata.rs:425-439`). A routine addition or change to
+branch ref handling must preserve the same transformation in each location.
+The trailer grammar has a second, smaller recurrence: `": "` is independently
+formatted, parsed, and detected in `append`, `parse`, `format_message`, and
+`has_trailing_trailer_block` (`src/trailer.rs:11-12,28-40,45-59,68-86`).
+
+**Strongest counterevidence.** Both grammars are tiny and stable, tests cover
+the trailer forms, and the three Store methods currently agree. A helper could
+look like cosmetic deduplication rather than a material abstraction.
+
+**Why adjacent scores do not fit.** Score 3 does not fit because branch
+resolution/update/deletion are ordinary Store operations and direct boundary
+code already supplies a fourth recurrence; this is not only a hypothetical
+future variant. Score 1 does not fit because the repeated transformations are
+stable and readily identifiable even though they lack a single authority.
+
+**Rule discrimination.** Decision rule 5 is decisive only if “direct evidence
+of routine recurrence” includes several current operations applying the same
+transformation. If it instead requires historical change evidence, the final
+rule would be non-discriminating for a revision-only review and this assignment
+would move toward 3.
+
+## Round 2 revalidation
+
+These scores supersede the corresponding Round 1 scores.
+
+### `fabro-http` × `duplication-knowledge` — 3 (Medium)
+
+**Decisive evidence.** `ProxyPolicy::parse` is the behavioral authority for the
+external `system`/`disabled` vocabulary, while
+`HttpClientBuildError::InvalidProxyPolicy` separately enumerates those values
+in its diagnostic (`src/lib.rs:29-35,63-66`). The builder macro remains one
+authority for applying the policy to both client kinds (`src/lib.rs:72-193`).
+
+**Adjacent scores and ambiguity.** Score 4 does not fit because the diagnostic
+is a concrete second representation that can drift. Score 2 does not fit
+because proxy behavior is not independently reimplemented: the shared
+resolver and macro enforce it, and the two no-proxy convenience constructors
+are call sites rather than separate authorities (`src/lib.rs:195-213`). The
+remaining ambiguity is whether changing the closed proxy vocabulary is routine
+enough to make the diagnostic synchronization central; I treat it as isolated.
+
+### `repository-ci` × `ownership-boundaries` — 2 (High)
+
+**Decisive evidence.** The Rust workflow's legacy-auth check scans `apps`,
+`lib/packages`, and `docs/public/api-reference/fabro-api.yaml`
+(`rust.yml:80-91`), but its push and pull-request path filters omit all three
+(`rust.yml:3-35`). Under decision rule 3, that check owns trigger coverage for
+every path it scans, so routine changes in those targets bypass its lifecycle.
+
+**Adjacent scores and ambiguity.** Score 3 does not fit because the missing
+triggers affect several routine source and contract paths, not an isolated
+edge. Score 1 does not fit because the Rust and TypeScript workflow owners and
+dependency direction remain stable. No material ambiguity remains under the
+new trigger-coverage rule.
+
+### `fabro-checkpoint` × `ownership-boundaries` — 2 (High)
+
+**Decisive evidence.** The map assigns checkpoint commits, trees, metadata
+branches, authorship, and trailers to this component. The routine
+`RunMetadataWriter` caller reconstructs that mapped lifecycle from `Store`
+primitives: it writes blobs and a tree, creates the commit and author/message,
+updates the ref, and pushes
+(`fabro-workflow/src/run_metadata.rs:313-361`). Decision rule 2 therefore
+places ownership at 2 even though the crate dependency points toward
+`fabro-checkpoint`.
+
+**Adjacent scores and ambiguity.** Score 3 does not fit because this is the
+common metadata snapshot path, not an edge case. Score 1 does not fit because
+the dependency direction and the low-level `Store` role are stable, and
+`BranchStore::write_with` demonstrates a coherent lifecycle owner inside the
+crate (`src/branch.rs:56-81`). The only remaining ambiguity is how specialized
+the metadata commit is, but the map explicitly includes metadata branches.
+
+### `fabro-checkpoint` × `simplicity` — 3 (High)
+
+**Decisive evidence.** `fabro-store` and `serde` are production dependencies
+with no source use (`Cargo.toml:16-24`), and `BranchStore` is a parallel
+high-level entry layer with no production caller outside this crate. Decision
+rule 4 makes those isolated simplicity frictions and caps 4 at 3.
+
+**Adjacent scores and ambiguity.** Score 4 does not fit because the unused
+production edges and parallel layer are concrete. Score 2 does not fit because
+the production `Store` path remains direct; normal callers do not navigate the
+unused dependencies or `BranchStore`. Whether `BranchStore` is retained for a
+future caller is ambiguous, but the unused dependencies alone sustain 3.
+
+### `fabro-checkpoint` × `domain-model` — 2 (Medium)
+
+**Decisive evidence.** The mapped Git-tree entry accepts any `String` path
+through `TreeEntries::set` (`src/git.rs:44-61`), while the routine metadata
+writer must validate paths before constructing those entries
+(`fabro-workflow/src/run_metadata.rs:319-336,471-481`). Decision rule 5 says
+caller validation does not isolate an invalid-capable mapped entry.
+`FileMode::from_i32` also collapses every unrecognized mode to `Blob`
+(`src/git.rs:29-35`).
+
+**Adjacent scores and ambiguity.** Score 3 does not fit because raw paths cross
+the common write boundary. Score 1 does not fit because tree entries, modes,
+and authors retain stable meanings and the caller does validate its input.
+Confidence is Medium because a deliberately low-level Git store can reasonably
+leave some path constraints to higher-level schemas, although the revised rule
+weighs against that interpretation.
+
+### `fabro-checkpoint` × `duplication-knowledge` — 3 (Medium)
+
+**Decisive evidence.** The `refs/heads/{branch}` transformation is repeated in
+three `Store` operations and once at the workflow boundary
+(`src/git.rs:182-225`; `fabro-workflow/src/run_metadata.rs:425-439`).
+Trailer formatting, parsing, and block detection also encode the `": "`
+convention separately (`src/trailer.rs:11-12,28-40,45-59,68-86`). These are
+concrete second representations, so decision rule 6 caps 4 at 3.
+
+**Adjacent scores and ambiguity.** Score 2 does not fit on the current evidence:
+adding a Store operation or trailer key may repeat a call-site convention, but
+does not require an ordinary mapped change to modify all existing locations.
+Score 4 does not fit because the representations are nevertheless concrete and
+can drift. The remaining ambiguity is whether broader trailer-syntax support
+would be routine maintenance; if so, its formatter/parser/detector
+synchronization would support 2.

.chisel/calibration/work/validation-3.md

@@ -0,0 +1,447 @@
+# Chisel calibration validation 3
+
+Revision reviewed: `6bb6b5efcc0e36b52e3c097f532d9f2c00914c6c`.
+
+This is an independent reading of the final rubric and the assigned component
+scopes. I traced representative production entry points and direct boundary
+callers. I did not inspect prior calibration scores or any other file in
+`.chisel/calibration/work/`.
+
+## Score summary
+
+| Component | Lens | Score | Evidence confidence |
+| --- | --- | ---: | --- |
+| `fabro-workflow` | ownership-boundaries | 2 | High |
+| `fabro-workflow` | domain-model | 2 | High |
+| `fabro-http` | domain-model | 4 | High |
+| `fabro-http` | duplication-knowledge | 3 | Medium |
+| `fabro-web-app` | ownership-boundaries | 4 | Medium |
+| `repository-ci` | ownership-boundaries | 4 | Medium |
+| `repository-ci` | domain-model | 2 | High |
+| `fabro-checkpoint` | ownership-boundaries | 2 | High |
+| `fabro-checkpoint` | simplicity | 3 | Medium |
+| `fabro-checkpoint` | domain-model | 2 | High |
+| `fabro-checkpoint` | duplication-knowledge | 3 | Medium |
+
+## `fabro-workflow`
+
+### `ownership-boundaries`: 2 (High)
+
+- **Evidence:** `src/lifecycle/mod.rs:53-80,221-469` provides a real central
+  `WorkflowLifecycle` and explicitly orders focused event, hook, fidelity, Git,
+  artifact, status, and circuit-breaker delegates. Its terminal callback,
+  however, only forwards `on_run_end` to the hook. Normal terminal persistence,
+  metadata completion, terminal event emission, and sandbox stopping instead
+  live in `src/pipeline/finalize.rs:524-635`. Bootstrap and execution failures
+  take another terminal path in `src/operations/start.rs:176-345`, while
+  `RunSession::run` also installs cleanup and drain guards at
+  `src/operations/start.rs:889-947`. A routine terminal-lifecycle change must
+  therefore coordinate the lifecycle orchestrator, finalizer, and detached
+  failure/guard paths.
+- **Strongest counterevidence:** The normal phase sequence is plainly owned by
+  `RunSession::run` (`initialize -> execute -> finalize -> pull_request`), and
+  callback ordering inside graph execution has one obvious owner,
+  `WorkflowLifecycle`.
+- **Why 3 does not fit:** Terminal completion, failure, persistence, and cleanup
+  are common paths, not isolated edge compatibility. The split therefore
+  remains central even though each individual phase is understandable.
+- **Why 1 does not fit:** Stable phase owners and a stable dependency direction
+  are readily identifiable; the problem is coordination among them, not the
+  absence of ownership.
+- **Rule discrimination:** The repository example correctly requires terminal
+  inspection and rule 1 makes the common terminal split score-capping. Decision
+  rule 2 is less literal here because no single identity is resupplied across
+  every split, but the score does not depend on that rule.
+
+### `domain-model`: 2 (High)
+
+- **Evidence:** `src/lifecycle/event.rs:319-390` starts with the typed
+  `StageOutcome` on an `Outcome`, serializes it with
+  `outcome.status.to_string()`, and stores the result in the
+  `Event::StageCompleted.status: String` field declared at
+  `src/event/events.rs:264-293`. Every successful stage then passes through
+  `src/event/convert.rs:14-24,309-348`, which reparses the string and silently
+  converts an unknown value into a non-retryable failure. This is the ordinary
+  durable-event path, not an import-only compatibility path.
+- **Strongest counterevidence:** The destination event model already has the
+  canonical `fabro_types::StageOutcome`, parallel-branch completion carries it
+  directly, and other core run concepts use typed IDs, reasons, timings, and an
+  opaque `ResumeState` (`src/pipeline/types.rs:252-285`).
+- **Why 3 does not fit:** The invalid intermediate occurs for each ordinary
+  successful stage before durable interpretation, so it is central rather than
+  an isolated escape hatch.
+- **Why 1 does not fit:** `StageOutcome` itself has a stable, typed meaning; the
+  defect is the recurring string round trip between two typed points.
+- **Rule discrimination:** Decision rule 4 is directly discriminating here:
+  this is exactly a common-path invalid intermediate.
+
+## `fabro-http`
+
+### `domain-model`: 4 (High)
+
+- **Evidence:** `src/lib.rs:23-61` gives proxy behavior a closed
+  `ProxyPolicy::{System, Disabled}` vocabulary. The environment boundary
+  accepts case-insensitive valid names, rejects every other value with a typed
+  `HttpClientBuildError`, handles non-Unicode values explicitly, gives explicit
+  policy precedence over the environment, and resolves absence to `System`.
+  Both generated builders invoke this resolver before constructing a client
+  (`src/lib.rs:72-193`), and the test-client entry points select
+  `ProxyPolicy::Disabled` rather than passing an unchecked string
+  (`src/lib.rs:195-213`).
+- **Strongest counterevidence:** The facade deliberately exposes reqwest's
+  lower-level `Proxy` and `.no_proxy()` operations, so callers can compose
+  transport details outside the two-value environment policy.
+- **Why 3 does not fit:** Those operations are typed builder choices, not
+  unvalidated representations of the `FABRO_HTTP_PROXY_POLICY` value. Every
+  common construction path still validates that boundary before use; I found no
+  material meaning or validation friction.
+- **Why 1-2 do not fit:** There is one stable meaning, one resolver, and no
+  recurring conversion through an invalid intermediate.
+- **Rule discrimination:** Decision rule 4 could be read ambiguously if every
+  low-level builder method is called a policy escape hatch. The rubric's own
+  `ProxyPolicy` example resolves that ambiguity in favor of the closed,
+  validated environment-policy model.
+
+### `duplication-knowledge`: 3 (Medium)
+
+- **Evidence:** `define_builder!` at `src/lib.rs:72-193` is one authoritative
+  production mechanism for the shared async/blocking builder surface and for
+  applying the resolved proxy policy. The four convenience constructors route
+  through those builders. The remaining repeated knowledge is narrow:
+  `"system"` and `"disabled"` appear both in the parser and in the manually
+  maintained `InvalidProxyPolicy` expectation text
+  (`src/lib.rs:29-35,63-69`).
+- **Strongest counterevidence:** The macro removes the materially risky
+  async/blocking synchronization, and the compiler forces the policy-application
+  match to cover every enum variant. The two test helpers' use of
+  `ProxyPolicy::Disabled` is ordinary reuse, not a second policy authority.
+- **Why 4 does not fit:** The user-facing valid-value list is a small second
+  representation that can drift from the parser, so there is some isolated
+  repeated domain knowledge.
+- **Why 2 does not fit:** There is no direct evidence that routine changes
+  repeatedly synchronize separate async/blocking implementations. A future
+  enum variant is hypothetical, and rule 5 specifically says exhaustive
+  compiler-checked branches and hypothetical variants do not establish
+  competing authorities.
+- **Rule discrimination:** Rule 5 cleanly rules out 2 but is non-discriminating
+  between 3 and 4 for a duplicated allowed-value error message. I treat that
+  message as real but isolated maintenance friction, hence 3.
+
+## `fabro-web-app`
+
+### `ownership-boundaries`: 4 (Medium)
+
+- **Evidence:** `app/entry.tsx:17-48` owns root creation, global SWR policy,
+  build-version guarding, toast mounting, and the single normal/install router
+  choice. `app/router.tsx:97-184` owns normal route composition, while
+  `app/install-router.tsx:6-22` owns the install graph. Shared HTTP translation
+  and unauthorized handling live in `app/lib/api-client.ts:213-309`; shared
+  reads such as `useRun` live in `app/lib/queries.ts:182-187`; recurring run
+  mutations and cache follow-up live in
+  `app/lib/mutations.ts:65-149`. Route components compose these owners.
+  Separately, `scripts/build.ts:183-249,289-368` contains the complete
+  app-local build, atomic publication, and old-build pruning lifecycle and
+  publishes only `apps/fabro-web/dist`; boundary tooling mirrors that output
+  into the Rust SPA rather than the web build writing across the boundary.
+- **Strongest counterevidence:** Some route-specific CRUD mutations import
+  `apiData` and generated API objects directly, and the install feature spans
+  `install-app.tsx`, `install-api.ts`, `install-query.ts`, and effect hooks.
+  `run-detail.tsx` is also a busy composition point.
+- **Why 3 does not fit:** The direct calls remain at the route-specific UX
+  owner and still use the shared transport/error boundary; shared read and
+  recurring run-lifecycle responsibilities are not reimplemented there.
+  Install state, transport, query, and browser effects have distinct homes.
+  I found no isolated lifecycle that must leave its owner and resupply identity.
+- **Why 1-2 do not fit:** Runtime, routing, transport, queries, route UX, and
+  build publication all have stable owners with dependencies pointing from
+  composition toward shared services.
+- **Rule discrimination:** The final repository example is useful and
+  discriminating: a large route is not by itself boundary leakage. The score
+  would change if direct routes reimplemented shared transport or cache
+  lifecycles, but representative boundary checks did not show that.
+
+## `repository-ci`
+
+### `ownership-boundaries`: 4 (Medium)
+
+- **Evidence:** `.github/workflows/rust.yml:48-147` owns Rust formatting,
+  lint/architecture checks, generated docs, Linux tests, twin E2E selection,
+  and manual macOS tests. `.github/workflows/typescript.yml:36-77` owns web and
+  generated-client typechecks, web tests, and the production embedded-SPA
+  integration build. Each workflow owns its concurrency and least-privilege job
+  permissions. The TypeScript workflow's `cargo dev build` is the intentional
+  integration boundary that consumes the web bundle; it does not create a
+  competing implementation of the web build.
+- **Strongest counterevidence:** The TypeScript build job invokes Rust build
+  tooling, path scopes overlap around `lib/apps/fabro-spa/**`, and
+  `.github/zizmor.yml` is configuration whose consumer is not shown in these
+  files.
+- **Why 3 does not fit:** Cross-language integration is part of the mapped CI
+  purpose and has one concrete home. The stale configuration values discussed
+  below are domain-model findings, while duplicated push/pull selectors are
+  duplication findings; counting either again as ownership friction would
+  violate the rubric's primary-lens rule.
+- **Why 1-2 do not fit:** The Rust and TypeScript responsibilities and their
+  dependency direction are stable. Routine validation changes have an obvious
+  workflow owner rather than requiring competing lifecycle owners.
+- **Rule discrimination:** The instruction not to penalize an unevidenced
+  missing lifecycle matters for the unseen zizmor consumer. The rubric is
+  otherwise discriminating once repeated selector policy is kept out of the
+  ownership lens.
+
+### `domain-model`: 2 (High)
+
+- **Evidence:** Both Rust trigger selectors name `openapi/**`
+  (`.github/workflows/rust.yml:6-19,22-35`), but that revision has no tracked
+  `openapi/` target. The actual Rust generator and TypeScript generator consume
+  `docs/public/api-reference/fabro-api.yaml`
+  (`lib/foundation/fabro-api/build.rs:159` and
+  `lib/packages/fabro-api-client/package.json:7`), a path omitted from both
+  workflow trigger models. This makes a core API-spec change invisible to the
+  intended CI trigger. In addition, all three
+  `.github/zizmor.yml:4-6` line selectors target
+  `.github/workflows/rust.yml` lines 37, 49, and 62, which are respectively
+  `workflow_dispatch`, the `fmt` job key, and a shell `run`, not action
+  references for `stale-action-refs`.
+- **Strongest counterevidence:** Most configured branches, paths, action SHAs,
+  runner labels, job names, and commands have clear current targets, and both
+  workflow documents have a stable overall schema.
+- **Why 3 does not fit:** The dead OpenAPI selector sits in both central Rust
+  push and pull-request triggers and omits the actual source of truth. It is not
+  merely an isolated stale lint suppression.
+- **Why 1 does not fit:** The CI configuration language and almost all values
+  remain interpretable; the problem is recurring invalid/no-target identifiers,
+  not the absence of a stable configuration model.
+- **Rule discrimination:** Decision rule 6 correctly classifies the no-target
+  identifiers as domain pressure, but it does not itself distinguish 2 from 3.
+  The centrality of the API source-of-truth trigger is what selects 2.
+
+## Control: `fabro-checkpoint`
+
+### `ownership-boundaries`: 2 (High)
+
+- **Evidence:** Inside the component, `BranchStore` owns a branch string and
+  author and delegates Git objects to `Store`
+  (`src/branch.rs:17-82`), which is a sensible direction. At the production
+  boundary, however, no production caller constructs `BranchStore`.
+  `fabro-workflow/src/run_metadata.rs:272-451` instead keeps `Store`, branch,
+  author, `parent_oid`, and discovery state as separate fields, manually writes
+  blobs and trees, supplies parents to `Store::write_commit`, resupplies the
+  branch to `Store::update_ref`, and owns fetch/push discovery. Other checkpoint
+  commit and trailer lifecycle work also remains in `fabro-workflow`. Thus the
+  mapped checkpoint/metadata-branch lifecycle crosses the scoped owner on the
+  normal production path.
+- **Strongest counterevidence:** `Store` is itself a mapped public entry point,
+  the dependency direction remains `fabro-workflow -> fabro-checkpoint`, and
+  remote authentication/push orchestration reasonably belongs near a workflow
+  run rather than in a low-level Git object store.
+- **Why 3 does not fit:** The caller-held branch and parent identity are used on
+  every metadata snapshot, not only in an isolated migration or uncommon
+  fallback.
+- **Why 1 does not fit:** Low-level Git ownership and the higher workflow
+  orchestration are both stable and understandable; they simply split one
+  routine persistence lifecycle.
+- **Rule discrimination:** Decision rule 2 is directly discriminating:
+  `RunMetadataWriter` retains and repeatedly resupplies the identity needed to
+  complete operations on `Store`. The mapped breadth of “metadata branches”
+  makes this more than ordinary parameter passing.
+
+### `simplicity`: 3 (Medium)
+
+- **Evidence:** The production low-level path is traceable:
+  `Store::write_blob -> TreeEntries::set -> Store::write_tree ->
+  Store::write_commit -> Store::update_ref`
+  (`src/git.rs:123-188`). `BranchStore::write_with` also gives branch-oriented
+  writes one linear read/modify/write implementation
+  (`src/branch.rs:56-117`). The recursive flat-tree conversion is justified by
+  Git's nested tree representation. The friction is isolated: `BranchStore` is
+  a sizeable second entry layer with tests but no production caller at this
+  revision, and `Cargo.toml:18` declares `fabro-store` although scoped
+  production code does not reference it.
+- **Strongest counterevidence:** The two entry points represent legitimate
+  abstraction levels, and the mapped cartography names both. None of the normal
+  `Store` operations requires navigating configuration machinery or dynamic
+  dispatch.
+- **Why 4 does not fit:** The unused higher layer/dependency is concrete,
+  avoidable surface and configuration burden, even though it is off the current
+  production common path.
+- **Why 2 does not fit:** Routine production writes do not repeatedly choose
+  between `Store` and `BranchStore`; the observed caller consistently uses
+  `Store`, and that path is direct.
+- **Rule discrimination:** The “public method alone does not establish
+  frequency” rule prevents treating `BranchStore` as a competing common path.
+  It is less discriminating between 3 and 4; the concrete unused dependency and
+  unused entry layer are why I select 3.
+
+### `domain-model`: 2 (High)
+
+- **Evidence:** `GitAuthor::from_options` accepts arbitrary name/email strings
+  (`src/author.rs:22-30`), while `BranchStore::new` only interprets them by
+  calling `Signature::now(...).expect(...)`
+  (`src/branch.rs:26-39`). `TreeEntries` stores paths as unrestricted `String`
+  and `BranchStore::write_entry/write_entries` put caller strings into it
+  without validation (`src/git.rs:46-90`,
+  `src/branch.rs:84-109`); interpretation and possible rejection occur later
+  while rebuilding Git trees. `FileMode::from_i32` also maps every unknown Git
+  mode to `Blob` (`src/git.rs:21-36`) rather than preserving or rejecting an
+  unknown shape. These invalid-capable intermediates sit on the mapped storage
+  entry paths.
+- **Strongest counterevidence:** `FileMode` is closed for values the component
+  writes, normal metadata callers validate paths before constructing
+  `TreeEntries`, Git itself rejects malformed signatures/trees, and object IDs
+  use git2's typed `Oid`.
+- **Why 3 does not fit:** Raw author and path values are carried by the ordinary
+  entry-point types and interpreted later; they are not confined to a separate
+  compatibility importer.
+- **Why 1 does not fit:** Authors, tree entries, modes, branches, and commits all
+  have stable intended meanings. The issue is delayed validation and lossy
+  fallback, not an unidentifiable core concept.
+- **Rule discrimination:** Decision rule 4 is discriminating here: these are
+  common-path invalid-capable intermediate shapes rather than a low-level
+  escape hatch unused by the entry path.
+
+### `duplication-knowledge`: 3 (Medium)
+
+- **Evidence:** Important transformations are mostly authoritative:
+  `FileMode::{as_i32,from_i32}` contains the mode mapping,
+  `BranchStore::write_with` contains branch read/modify/write, and
+  `GitAuthor::default` contains the default identity. The narrow repeated
+  knowledge is the bare-branch to full-ref transformation
+  `format!("refs/heads/{branch}")` in each of
+  `Store::{update_ref,resolve_ref,delete_ref}`
+  (`src/git.rs:182-225`), with another full-ref rendering at the direct
+  workflow metadata boundary. Trailer rendering also spells
+  `"{}: {}"` in both `append` and `format_message`
+  (`src/trailer.rs:9-65`).
+- **Strongest counterevidence:** The repeated ref syntax is stable low-level Git
+  syntax, the three ref methods implement different operations, and the
+  apparent duplication in single-entry/multi-entry or tip/commit reads has
+  intentionally different result shapes. Unifying those operations would risk
+  a parameterized mega-helper.
+- **Why 4 does not fit:** Full-ref and trailer-line rendering have small but real
+  second representations rather than one helper/type enforcing each
+  transformation.
+- **Why 2 does not fit:** There is no direct evidence of routine changes
+  repeatedly synchronizing those stable renderings, and hypothetical future ref
+  methods do not satisfy decision rule 5. The repeated knowledge is isolated
+  from ordinary checkpoint-format extension.
+- **Rule discrimination:** Rule 5 usefully rules out 2 but is
+  non-discriminating between 3 and 4 for repeated, stable protocol syntax. I
+  score 3 because the repetitions are concrete, while keeping confidence
+  Medium because their maintenance materiality is limited.
+
+## Round 2 revalidation
+
+I independently reapplied the simplified decision rules to only the requested
+assignments. Scores below supersede the corresponding Round 1 judgments for
+this revalidation.
+
+| Component | Lens | Round 2 score | Confidence |
+| --- | --- | ---: | --- |
+| `fabro-http` | duplication-knowledge | 3 | High |
+| `repository-ci` | ownership-boundaries | 2 | High |
+| `fabro-checkpoint` | ownership-boundaries | 2 | High |
+| `fabro-checkpoint` | simplicity | 3 | High |
+| `fabro-checkpoint` | domain-model | 2 | High |
+| `fabro-checkpoint` | duplication-knowledge | 3 | Medium |
+
+### `fabro-http` × `duplication-knowledge`: 3 (High)
+
+- **Decisive evidence:** `define_builder!` remains the one mechanism for the
+  materially recurring async/blocking builder policy
+  (`src/lib.rs:72-193`). The parser and `InvalidProxyPolicy` message still hold
+  a concrete second representation of the allowed `"system"`/`"disabled"`
+  vocabulary (`src/lib.rs:29-35,63-69`).
+- **Adjacent scores:** 4 does not fit because revised rule 6 explicitly caps a
+  concrete second semantic representation at 3. Score 2 does not fit because an
+  ordinary mapped change does not currently synchronize separate async and
+  blocking implementations; adding a future policy variant is not direct
+  recurrence evidence.
+- **Remaining ambiguity:** None material. Revised rule 6 now resolves the prior
+  3-versus-4 uncertainty.
+
+### `repository-ci` × `ownership-boundaries`: 2 (High)
+
+- **Decisive evidence:** The Rust workflow's architecture check scans
+  `apps`, `lib/packages`, and
+  `docs/public/api-reference/fabro-api.yaml`
+  (`.github/workflows/rust.yml:80-91`), but its push and pull-request triggers
+  omit all three routine target paths (`rust.yml:6-19,22-35`). Its Cargo jobs
+  also consume the real API specification through
+  `lib/foundation/fabro-api/build.rs`, yet that specification does not trigger
+  the workflow. The TypeScript workflow likewise consumes the generated API
+  client and performs the embedded integration build without making the source
+  specification a trigger. Under revised rule 3, each check owns this coverage;
+  the omitted routine targets are therefore central ownership pressure.
+- **Adjacent scores:** 3 does not fit because API, app, and package changes are
+  routine targets of checks the workflow actually runs, not isolated edge
+  inputs. Score 1 does not fit because Rust and TypeScript job ownership and
+  dependency direction otherwise remain stable.
+- **Remaining ambiguity:** None material. The nonexistent `openapi/**` value is
+  still a separate domain-model finding; the ownership finding rests on the
+  real scanned/consumed paths that fail to trigger.
+
+### `fabro-checkpoint` × `ownership-boundaries`: 2 (High)
+
+- **Decisive evidence:** The mapped higher owner is `BranchStore`, but the
+  routine production metadata caller instead retains `Store`, branch, author,
+  parent, and discovery state and reconstructs blob/tree/commit/ref lifecycle
+  from `Store` primitives in
+  `fabro-workflow/src/run_metadata.rs:272-451`. Revised rule 2 names this shape
+  directly.
+- **Adjacent scores:** 3 does not fit because reconstruction occurs on every
+  metadata snapshot, not at an isolated edge. Score 1 does not fit because the
+  low-level `Store` and workflow-level caller are stable, identifiable owners;
+  the concern is the lifecycle split between them.
+- **Remaining ambiguity:** The workflow reasonably owns remote authentication,
+  but that does not remove its reconstruction of the mapped checkpoint and
+  metadata-branch persistence lifecycle.
+
+### `fabro-checkpoint` × `simplicity`: 3 (High)
+
+- **Decisive evidence:** The current production `Store` write sequence is
+  linear and direct (`src/git.rs:123-188`). `BranchStore` is a parallel mapped
+  entry layer with no production caller at this revision, and `Cargo.toml:18`
+  declares the unused production dependency `fabro-store`. Revised rule 4
+  classifies exactly this as isolated simplicity friction that caps 4 at 3.
+- **Adjacent scores:** 4 does not fit because the parallel unused layer and
+  dependency are concrete. Score 2 does not fit because routine callers do not
+  navigate competing paths or machinery; they consistently follow the direct
+  `Store` path.
+- **Remaining ambiguity:** None material after rule 4. `BranchStore` being a
+  mapped entry does not make it frequent when the boundary search finds no
+  production caller.
+
+### `fabro-checkpoint` × `domain-model`: 2 (High)
+
+- **Decisive evidence:** Mapped entry shapes accept unrestricted author and path
+  strings: `GitAuthor::from_options` stores raw values before
+  `BranchStore::new` interprets them with `Signature::now(...).expect(...)`
+  (`src/author.rs:22-30`, `src/branch.rs:26-39`), and
+  `TreeEntries`/`write_entry` carry unchecked string paths until Git-tree
+  construction (`src/git.rs:46-90`, `src/branch.rs:84-109`). Revised rule 5
+  says caller validation and a typed destination do not isolate this
+  invalid-capable mapped entry.
+- **Adjacent scores:** 3 does not fit because the invalid-capable shapes are on
+  mapped entry paths, not a compatibility-only edge. Score 1 does not fit
+  because the intended meanings of authors, paths, modes, and commits remain
+  stable.
+- **Remaining ambiguity:** None material. Normal callers supplying valid values
+  does not make the entry type canonical by construction.
+
+### `fabro-checkpoint` × `duplication-knowledge`: 3 (Medium)
+
+- **Decisive evidence:** Bare branch names are independently rendered as
+  `refs/heads/{branch}` in `Store::update_ref`, `resolve_ref`, and `delete_ref`
+  (`src/git.rs:182-225`), and trailer lines are independently rendered in
+  `trailer::append` and `format_message` (`src/trailer.rs:9-65`). These are
+  concrete second semantic representations, so revised rule 6 excludes 4.
+- **Adjacent scores:** 4 does not fit because the second renderings are real.
+  Score 2 does not fit because no evidenced ordinary mapped change must
+  synchronize the stable Git ref or trailer syntax across those locations;
+  future ref operations are hypothetical, while the existing operations have
+  distinct behavior.
+- **Remaining ambiguity:** Limited ambiguity remains over whether stable
+  protocol syntax is material enough to count as semantic repetition at all.
+  Rule 6 does not define that threshold, so confidence remains Medium; if it
+  counts, 3 is the rule-directed score.

.config/nextest.toml

@@ -11,10 +11,6 @@ leak-timeout = "500ms"
     filter = "package(fabro-server)"
     slow-timeout = { period = "5s", terminate-after = 4 }
 
-    [[profile.default.overrides]]
-    filter = "package(fabro-server) & test(all_spec_routes_are_routable)"
-    slow-timeout = { period = "15s", terminate-after = 4 }
-
     [[profile.default.overrides]]
     filter = "package(fabro-workflow)"
     slow-timeout = { period = "2s", terminate-after = 3 }

.env.example

@@ -6,6 +6,9 @@ GEMINI_API_KEY=
 INCEPTION_API_KEY=
 KIMI_API_KEY=
 MINIMAX_API_KEY=
+MODAL_KIMI_K3_BASE_URL=
+MODAL_TOKEN_ID=
+MODAL_TOKEN_SECRET=
 OPENAI_API_KEY=
 OPENROUTER_API_KEY=
 POOLSIDE_API_KEY=

Cargo.lock

@@ -2239,7 +2239,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-acp"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "agent-client-protocol",
  "agent-client-protocol-tokio",
@@ -2258,7 +2258,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-agent"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -2304,7 +2304,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-api"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "chrono",
  "fabro-automation",
@@ -2327,7 +2327,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-auth"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -2352,7 +2352,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-automation"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "chrono",
@@ -2371,11 +2371,11 @@ dependencies = [
 
 [[package]]
 name = "fabro-build-support"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 
 [[package]]
 name = "fabro-checkpoint"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "chrono",
  "fabro-config",
@@ -2391,7 +2391,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-cli"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "assert_cmd",
@@ -2493,7 +2493,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-client"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "bytes",
@@ -2522,7 +2522,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-config"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "chrono",
@@ -2552,7 +2552,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-core"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "async-trait",
  "fabro-types",
@@ -2567,7 +2567,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-db"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "chrono",
@@ -2579,7 +2579,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-dev"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "assert_cmd",
@@ -2598,7 +2598,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-dump"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "bytes",
@@ -2612,7 +2612,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-environment"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "chrono",
@@ -2634,7 +2634,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-github"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "base64",
@@ -2656,7 +2656,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-graphviz"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "fabro-types",
@@ -2671,7 +2671,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-hooks"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "async-trait",
  "fabro-agent",
@@ -2694,7 +2694,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-http"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "fabro-static",
  "http 1.4.0",
@@ -2704,7 +2704,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-install"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "base64",
@@ -2723,7 +2723,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-interview"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "async-trait",
  "dialoguer",
@@ -2738,7 +2738,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-llm"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -2779,7 +2779,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-macros"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "clap",
  "fabro-options-metadata",
@@ -2790,7 +2790,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-manifest"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "fabro-api",
@@ -2808,7 +2808,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-mcp"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "axum",
@@ -2828,7 +2828,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-mcp-server"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "chrono",
@@ -2855,7 +2855,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-mcp-store"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "chrono",
  "fabro-db",
@@ -2873,7 +2873,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-model"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "fabro-static",
  "http 1.4.0",
@@ -2889,7 +2889,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-oauth"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "axum",
@@ -2911,7 +2911,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-options-metadata"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "serde",
  "serde_json",
@@ -2919,7 +2919,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-proc"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "cc",
  "libc",
@@ -2928,7 +2928,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-redact"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "aho-corasick",
  "ref-cast",
@@ -2944,7 +2944,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-sandbox"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -2988,7 +2988,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-server"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -3028,6 +3028,7 @@ dependencies = [
  "fabro-spa",
  "fabro-static",
  "fabro-store",
+ "fabro-template",
  "fabro-test",
  "fabro-tool",
  "fabro-types",
@@ -3080,7 +3081,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-slack"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "fabro-http",
  "fabro-interview",
@@ -3102,18 +3103,18 @@ dependencies = [
 
 [[package]]
 name = "fabro-spa"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "rust-embed",
 ]
 
 [[package]]
 name = "fabro-static"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 
 [[package]]
 name = "fabro-store"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "async-trait",
  "bytes",
@@ -3143,7 +3144,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-telemetry"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "base64",
@@ -3169,7 +3170,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-template"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "fabro-types",
@@ -3183,7 +3184,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-test"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "assert_cmd",
@@ -3208,7 +3209,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-tool"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -3229,7 +3230,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-tracker"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-trait",
@@ -3243,7 +3244,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-types"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "chrono",
  "clap",
@@ -3258,6 +3259,7 @@ dependencies = [
  "shlex",
  "strum 0.28.0",
  "tempfile",
+ "thiserror 2.0.18",
  "toml 0.8.23",
  "ulid",
  "url",
@@ -3265,7 +3267,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-util"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "console 0.15.11",
@@ -3288,7 +3290,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-validate"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "fabro-acp",
  "fabro-graphviz",
@@ -3301,7 +3303,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-variable"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "chrono",
@@ -3318,7 +3320,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-vault"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "chrono",
@@ -3337,7 +3339,7 @@ dependencies = [
 
 [[package]]
 name = "fabro-workflow"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "assert_cmd",
@@ -3393,6 +3395,7 @@ dependencies = [
  "serde_json",
  "sha2 0.10.9",
  "shlex",
+ "strum 0.28.0",
  "tempfile",
  "thiserror 2.0.18",
  "tokio",
@@ -8501,7 +8504,7 @@ dependencies = [
 
 [[package]]
 name = "twin-github"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "axum",
  "base64",
@@ -8520,7 +8523,7 @@ dependencies = [
 
 [[package]]
 name = "twin-openai"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 dependencies = [
  "anyhow",
  "async-stream",

Cargo.toml

@@ -11,7 +11,7 @@ resolver = "2"
 
 [workspace.package]
 edition = "2021"
-version = "0.305.0-nightly.3"
+version = "0.308.0-nightly.1"
 license = "MIT"
 
 [workspace.dependencies]

apps/fabro-web/app/components/interview-dock.test.tsx

@@ -4,9 +4,14 @@ import { SWRConfig } from "swr";
 import {
   type ApiQuestion,
   QuestionType,
+  ReviewTargetKind,
 } from "@qltysh/fabro-api-client";
 
-import { InterviewDock } from "./interview-dock";
+import {
+  contextPreview,
+  InterviewDock,
+  shouldStackOptions,
+} from "./interview-dock";
 import { displayLabel } from "./interview-label";
 import { generatedAxios } from "../lib/api-client";
 
@@ -74,6 +79,58 @@ describe("InterviewDock", () => {
     expect(text).toContain("Awaiting input");
   });
 
+  test("renders the review target as the link in the question", () => {
+    const url =
+      "https://quarry.lithos.computer/tmp/0123456789abcdef0123456789abcdef";
+    const tree = render(
+      <InterviewDock
+        runId="run-1"
+        questions={[
+          makeQuestion({
+            text: "Review the Quarry review exercise document, then choose the next action.",
+            review_target: {
+              label: "Quarry review exercise",
+              url,
+              kind: ReviewTargetKind.DOCUMENT,
+            },
+          }),
+        ]}
+      />,
+    );
+
+    expect(textContent(tree.toJSON())).toContain(
+      "Review the Quarry review exercise document, then choose the next action.",
+    );
+    const links = tree.root.findAllByType("a");
+    expect(links).toHaveLength(1);
+    expect(links[0].props.href).toBe(url);
+    expect(links[0].props.target).toBe("_blank");
+    expect(links[0].props.rel).toBe("noopener noreferrer");
+    expect(links[0].props.referrerPolicy).toBe("no-referrer");
+  });
+
+  test("does not link an unsafe review target received from the API", () => {
+    const fallback = "Review the document, then choose the next action.";
+    const tree = render(
+      <InterviewDock
+        runId="run-1"
+        questions={[
+          makeQuestion({
+            text: fallback,
+            review_target: {
+              label: "Unsafe target",
+              url: "javascript:alert(1)",
+              kind: ReviewTargetKind.DOCUMENT,
+            },
+          }),
+        ]}
+      />,
+    );
+
+    expect(textContent(tree.toJSON())).toContain(fallback);
+    expect(tree.root.findAllByType("a")).toHaveLength(0);
+  });
+
   test("yes/no question shows two buttons", () => {
     const tree = render(
       <InterviewDock runId="run-1" questions={[makeQuestion()]} />,
@@ -236,6 +293,112 @@ describe("InterviewDock", () => {
     expect(text).toContain("Context from preceding stage");
     expect(text).toContain("1. Deploy");
   });
+
+  test("context starts closed so it costs one line, not a standing panel", () => {
+    const question = makeQuestion({
+      context_display: "Plan:\n1. Deploy\n2. Verify",
+    });
+    const tree = render(
+      <InterviewDock runId="run-1" questions={[question]} />,
+    );
+    const details = tree.root.findAllByType("details");
+    expect(details).toHaveLength(1);
+    expect(details[0]!.props.open).toBeFalsy();
+  });
+
+  test("omits the question type subtitle that the answer buttons already state", () => {
+    const question = makeQuestion({
+      question_type: QuestionType.MULTIPLE_CHOICE,
+      options: [{ key: "A", label: "[A] Approve" }],
+    });
+    const tree = render(
+      <InterviewDock runId="run-1" questions={[question]} />,
+    );
+    expect(textContent(tree.toJSON())).not.toContain("Pick one");
+  });
+
+  test("collapsing hides the answer controls but keeps the header", () => {
+    const tree = render(
+      <InterviewDock runId="run-1" questions={[makeQuestion()]} />,
+    );
+    const toggle = tree.root.findByProps({ "aria-label": "Collapse Interview question" });
+
+    act(() => {
+      toggle.props.onClick();
+    });
+
+    const expanded = tree.root.findByProps({
+      "aria-label": "Expand Interview question",
+    });
+    expect(expanded.props["aria-expanded"]).toBe(false);
+    expect(textContent(tree.toJSON())).toContain("Awaiting input");
+  });
+
+  test("a queued question arrives expanded even after the panel was collapsed", () => {
+    const questions = [
+      makeQuestion({ id: "q-1", stage: "stage-a" }),
+      makeQuestion({ id: "q-2", stage: "stage-b" }),
+    ];
+    const tree = render(<InterviewDock runId="run-1" questions={questions} />);
+
+    act(() => {
+      tree.root
+        .findByProps({ "aria-label": "Collapse Interview question" })
+        .props.onClick();
+    });
+    act(() => {
+      buttonsByText(tree)["1 more pending"]!.props.onClick();
+    });
+
+    const toggle = tree.root.findByProps({
+      "aria-label": "Collapse Interview question",
+    });
+    expect(toggle.props["aria-expanded"]).toBe(true);
+  });
+});
+
+describe("shouldStackOptions", () => {
+  test("keeps short labels as a wrapping row", () => {
+    expect(
+      shouldStackOptions([
+        { key: "a", label: "Approve" },
+        { key: "b", label: "Revise" },
+      ]),
+    ).toBe(false);
+  });
+
+  test("stacks once a label is too long to sit in a pill", () => {
+    expect(
+      shouldStackOptions([
+        { key: "a", label: "Approve" },
+        { key: "b", label: "Review complete; sync the current Markdown document" },
+      ]),
+    ).toBe(true);
+  });
+
+  test("stacks when any option carries a description", () => {
+    expect(
+      shouldStackOptions([
+        { key: "a", label: "Approve", description: "Deploy the current patch" },
+      ]),
+    ).toBe(true);
+  });
+});
+
+describe("contextPreview", () => {
+  test("uses the first non-empty line", () => {
+    expect(contextPreview("\n\nPlan is ready\nSecond line")).toBe("Plan is ready");
+  });
+
+  test("truncates a long first line", () => {
+    const preview = contextPreview("x".repeat(200));
+    expect(preview).toHaveLength(61);
+    expect(preview.endsWith("…")).toBe(true);
+  });
+
+  test("returns an empty string for blank context", () => {
+    expect(contextPreview("   \n  ")).toBe("");
+  });
 });
 
 describe("displayLabel", () => {

apps/fabro-web/app/components/interview-dock.tsx

@@ -1,14 +1,8 @@
+import { useCallback, useState } from "react";
 import {
-  useCallback,
-  useState,
-  type FormEvent,
-  type KeyboardEvent,
-} from "react";
-import {
-  ArrowPathIcon,
   ArrowRightIcon,
-  ArrowUturnLeftIcon,
   CheckIcon,
+  ChevronRightIcon,
 } from "@heroicons/react/20/solid";
 import { QuestionType } from "@qltysh/fabro-api-client";
 import type {
@@ -22,16 +16,31 @@ import {
 } from "../lib/mutations";
 import { ApiError } from "../lib/api-client";
 import { displayLabel } from "./interview-label";
-import { ErrorMessage } from "./ui";
+import {
+  ReviewTargetQuestion,
+  safeReviewTarget,
+} from "./review-target-question";
+import {
+  DockComposer,
+  RunDockShell,
+  DOCK_CHOICE_BUTTON,
+  DOCK_CHOICE_BUTTON_SELECTED,
+  DOCK_HEADER_BUTTON,
+} from "./run-dock";
+import { Spinner } from "./state";
+import {
+  ErrorMessage,
+  PRIMARY_BUTTON_CLASS,
+} from "./ui";
 
-const PRIMARY_BUTTON =
-  "inline-flex items-center justify-center gap-1.5 rounded-lg bg-teal-500 px-3.5 py-2 text-sm font-medium text-on-primary transition-colors hover:bg-teal-300 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-teal-500 disabled:cursor-not-allowed disabled:opacity-60 disabled:hover:bg-teal-500";
+/**
+ * Options stack into a list once a label is long enough that a row of pills
+ * would wrap mid-sentence.
+ */
+const STACK_LABEL_LENGTH = 40;
 
-const CHOICE_BUTTON =
-  "inline-flex items-center justify-center gap-1.5 rounded-lg bg-overlay px-3.5 py-2 text-sm font-medium text-fg-2 outline-1 -outline-offset-1 outline-line-strong transition-colors hover:bg-overlay-strong hover:text-fg focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500 disabled:cursor-not-allowed disabled:opacity-60";
-
-const CHOICE_BUTTON_SELECTED =
-  "inline-flex items-center justify-center gap-1.5 rounded-lg bg-teal-500/15 px-3.5 py-2 text-sm font-medium text-fg outline-1 -outline-offset-1 outline-teal-500/60 transition-colors hover:bg-teal-500/20 focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500";
+/** Shared by the plain question text and the review target rendering. */
+const QUESTION_TEXT = "max-w-[78ch] text-base/6 font-medium text-pretty text-fg";
 
 type SubmitInterviewAnswer = SubmitInterviewAnswerArg["answer"];
 
@@ -51,6 +60,8 @@ export function InterviewDock({ runId, questions }: InterviewDockProps) {
   const moreCount = questions.length - 1;
 
   return (
+    // Keyed by question id, so a new question always arrives expanded with an
+    // empty composer. A collapsed panel can never silently block a run.
     <InterviewQuestionDock
       key={question.id}
       runId={runId}
@@ -76,112 +87,115 @@ function InterviewQuestionDock({
 }) {
   const submitMutation = useSubmitInterviewAnswer(runId);
   const [error, setError] = useState<string | null>(null);
+  const [collapsed, setCollapsed] = useState(false);
   const submitting = submitMutation.isMutating;
+  const reviewTarget = safeReviewTarget(question.review_target);
 
   const submit = useCallback(
     async (answer: SubmitInterviewAnswer) => {
       setError(null);
       try {
         await submitMutation.trigger({ questionId: question.id, answer });
+        return true;
       } catch (caught) {
         setError(interviewSubmitErrorMessage(caught));
+        return false;
       }
     },
     [question.id, submitMutation],
   );
 
   return (
-    <section aria-label="Interview question">
-      <DockHeader
-        stage={question.stage}
-        moreCount={moreCount}
-        onCycle={onCycle}
-      />
-      <div className="space-y-5 px-5 py-4 sm:px-6">
-        <div>
-          <p className="text-pretty text-base/6 font-medium text-fg">
-            {question.text}
-          </p>
-          <p className="mt-1 text-xs/5 text-fg-muted">
-            {questionTypeLabel(question.question_type)}
-          </p>
-        </div>
-
-        {question.context_display && (
-          <ContextPanel text={question.context_display} />
-        )}
-
-        <QuestionBody
-          question={question}
-          submitting={submitting}
-          onSubmit={submit}
-        />
-
-        {error && <ErrorMessage message={error} />}
-      </div>
-    </section>
-  );
-}
-
-function DockHeader({
-  stage,
-  moreCount,
-  onCycle,
-}: {
-  stage: string;
-  moreCount: number;
-  onCycle: () => void;
-}) {
-  return (
-    <div className="flex items-center justify-between gap-3 border-b border-line px-5 py-2.5">
-      <div className="flex min-w-0 items-center gap-2 text-sm">
-        <PulseDot />
-        <span className="font-medium text-fg-2">Awaiting input</span>
-        {stage && (
-          <>
-            <span className="text-fg-muted" aria-hidden="true">
-              ·
-            </span>
-            <span className="truncate font-mono text-xs text-fg-3">{stage}</span>
-          </>
-        )}
-      </div>
-      {moreCount > 0 && (
-        <button
-          type="button"
-          onClick={onCycle}
-          className="inline-flex shrink-0 items-center gap-1 rounded-md bg-overlay px-2 py-1 text-xs font-medium text-fg-2 outline-1 -outline-offset-1 outline-line-strong hover:bg-overlay-strong hover:text-fg focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-teal-500"
-        >
-          <span className="tabular-nums">{moreCount}</span> more pending
-          <ArrowRightIcon className="size-3" aria-hidden="true" />
-        </button>
-      )}
-    </div>
-  );
-}
-
-function PulseDot() {
-  return (
-    <span className="relative flex size-2 items-center justify-center" aria-hidden="true">
-      <span className="absolute inline-flex size-full animate-ping rounded-full bg-amber/60" />
-      <span className="relative inline-flex size-2 rounded-full bg-amber" />
-    </span>
+    <RunDockShell
+      label="Interview question"
+      tone="waiting"
+      status="Awaiting input"
+      stage={question.stage}
+      peek={question.text}
+      collapsed={collapsed}
+      onCollapsedChange={setCollapsed}
+      headerActions={
+        moreCount > 0 && (
+          <button
+            type="button"
+            onClick={onCycle}
+            className={DOCK_HEADER_BUTTON}
+          >
+            <span className="tabular-nums">{moreCount}</span> more pending
+            <ArrowRightIcon className="size-3" aria-hidden="true" />
+          </button>
+        )
+      }
+      body={
+        <>
+          {reviewTarget ? (
+            <ReviewTargetQuestion
+              target={reviewTarget}
+              className={QUESTION_TEXT}
+            />
+          ) : (
+            <p className={QUESTION_TEXT}>{question.text}</p>
+          )}
+          {question.context_display && (
+            <ContextPanel text={question.context_display} />
+          )}
+        </>
+      }
+      actions={
+        <>
+          <QuestionBody
+            question={question}
+            submitting={submitting}
+            onSubmit={submit}
+          />
+          {error && <ErrorMessage message={error} />}
+        </>
+      }
+    />
   );
 }
 
+/**
+ * Context arrives collapsed. It repeats material the operator has usually
+ * already read in the stage stream above, so it earns a line rather than a
+ * standing panel.
+ */
 function ContextPanel({ text }: { text: string }) {
   return (
-    <div className="rounded-lg bg-panel-alt p-4 outline-1 -outline-offset-1 outline-line">
-      <p className="mb-1.5 font-mono text-[0.6875rem] tracking-wide text-fg-muted uppercase">
+    <details className="group rounded-lg bg-panel-alt outline-1 -outline-offset-1 outline-line">
+      <summary className="flex cursor-pointer list-none items-center gap-1.5 rounded-lg px-3 py-1.5 font-mono text-[0.6875rem] tracking-wide text-fg-muted uppercase transition-colors hover:text-fg-3 focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500 [&::-webkit-details-marker]:hidden">
+        <ChevronRightIcon
+          className="size-3 shrink-0 transition-transform group-open:rotate-90"
+          aria-hidden="true"
+        />
         Context from preceding stage
-      </p>
-      <div className="max-h-40 overflow-y-auto text-sm/6 text-fg-2">
+        <span className="ml-auto truncate pl-3 font-sans text-xs tracking-normal normal-case group-open:hidden">
+          {contextPreview(text)}
+        </span>
+      </summary>
+      <div className="px-3 pb-2.5 text-sm/6 text-fg-2">
         <pre className="font-sans whitespace-pre-wrap">{text}</pre>
       </div>
-    </div>
+    </details>
   );
 }
 
+/** First line of the context, for the collapsed summary. */
+export function contextPreview(text: string): string {
+  let lineStart = 0;
+  while (lineStart < text.length) {
+    const newline = text.indexOf("\n", lineStart);
+    const lineEnd = newline === -1 ? text.length : newline;
+    const line = text.slice(lineStart, lineEnd).trim();
+    if (line) {
+      return line.length > 60 ? `${line.slice(0, 60).trimEnd()}…` : line;
+    }
+    if (newline === -1) break;
+    lineStart = newline + 1;
+  }
+  return "";
+}
+
 function QuestionBody({
   question,
   submitting,
@@ -189,7 +203,7 @@ function QuestionBody({
 }: {
   question: ApiQuestion;
   submitting: boolean;
-  onSubmit: (answer: SubmitInterviewAnswer) => Promise<void>;
+  onSubmit: (answer: SubmitInterviewAnswer) => Promise<boolean>;
 }) {
   switch (question.question_type) {
     case QuestionType.YES_NO:
@@ -215,11 +229,10 @@ function QuestionBody({
       );
     case QuestionType.FREEFORM:
       return (
-        <FreeformBody
+        <FreeformAnswer
           submitting={submitting}
           onSubmit={onSubmit}
           placeholder="Write your response…"
-          submitLabel="Send"
         />
       );
     default:
@@ -232,7 +245,7 @@ function YesNoBody({
   onSubmit,
 }: {
   submitting: boolean;
-  onSubmit: (answer: SubmitInterviewAnswer) => Promise<void>;
+  onSubmit: (answer: SubmitInterviewAnswer) => Promise<boolean>;
 }) {
   return (
     <div className="flex flex-wrap items-center gap-2">
@@ -242,7 +255,7 @@ function YesNoBody({
         aria-label="Answer no"
         disabled={submitting}
         onClick={() => void onSubmit({ kind: "no" })}
-        className={CHOICE_BUTTON}
+        className={DOCK_CHOICE_BUTTON}
       >
         No
       </button>
@@ -251,9 +264,13 @@ function YesNoBody({
         aria-label="Answer yes"
         disabled={submitting}
         onClick={() => void onSubmit({ kind: "yes" })}
-        className={PRIMARY_BUTTON}
+        className={PRIMARY_BUTTON_CLASS}
       >
-        {submitting ? <Spinner /> : <CheckIcon className="size-4" aria-hidden="true" />}
+        {submitting ? (
+          <Spinner className="size-4" />
+        ) : (
+          <CheckIcon className="size-4" aria-hidden="true" />
+        )}
         Yes
       </button>
     </div>
@@ -265,7 +282,7 @@ function ConfirmationBody({
   onSubmit,
 }: {
   submitting: boolean;
-  onSubmit: (answer: SubmitInterviewAnswer) => Promise<void>;
+  onSubmit: (answer: SubmitInterviewAnswer) => Promise<boolean>;
 }) {
   return (
     <div className="flex flex-wrap items-center gap-2">
@@ -273,15 +290,35 @@ function ConfirmationBody({
         type="button"
         disabled={submitting}
         onClick={() => void onSubmit({ kind: "yes" })}
-        className={PRIMARY_BUTTON}
+        className={PRIMARY_BUTTON_CLASS}
       >
-        {submitting ? <Spinner /> : <CheckIcon className="size-4" aria-hidden="true" />}
+        {submitting ? (
+          <Spinner className="size-4" />
+        ) : (
+          <CheckIcon className="size-4" aria-hidden="true" />
+        )}
         Confirm
       </button>
     </div>
   );
 }
 
+/**
+ * Long labels wrap badly as pills, so they become a stacked list instead.
+ */
+export function shouldStackOptions(options: InterviewOption[]): boolean {
+  return options.some(
+    (option) =>
+      option.label.length > STACK_LABEL_LENGTH || Boolean(option.description),
+  );
+}
+
+function optionListClass(stacked: boolean): string {
+  return stacked
+    ? "flex flex-col items-stretch gap-2"
+    : "flex flex-wrap items-center gap-2";
+}
+
 function ChoiceBody({
   options,
   allowFreeform,
@@ -291,19 +328,23 @@ function ChoiceBody({
   options: InterviewOption[];
   allowFreeform: boolean;
   submitting: boolean;
-  onSubmit: (answer: SubmitInterviewAnswer) => Promise<void>;
+  onSubmit: (answer: SubmitInterviewAnswer) => Promise<boolean>;
 }) {
+  const stacked = shouldStackOptions(options);
+
   return (
-    <div className="space-y-4">
+    <div className="space-y-2.5">
       {options.length > 0 && (
-        <div className="flex flex-wrap items-center gap-2">
+        <div className={optionListClass(stacked)}>
           {options.map((option) => (
             <button
               key={option.key}
               type="button"
               disabled={submitting}
               onClick={() => void onSubmit({ kind: "selected", option_key: option.key })}
-              className={CHOICE_BUTTON}
+              className={
+                stacked ? `${DOCK_CHOICE_BUTTON} justify-start` : DOCK_CHOICE_BUTTON
+              }
             >
               <OptionLabel option={option} />
             </button>
@@ -311,7 +352,7 @@ function ChoiceBody({
         </div>
       )}
       {allowFreeform && (
-        <FreeformBody
+        <FreeformAnswer
           submitting={submitting}
           onSubmit={onSubmit}
           placeholder={
@@ -319,8 +360,6 @@ function ChoiceBody({
               ? "Or write a custom response…"
               : "Write your response…"
           }
-          submitLabel="Send"
-          divider={options.length > 0}
         />
       )}
     </div>
@@ -334,7 +373,7 @@ function MultiSelectBody({
 }: {
   options: InterviewOption[];
   submitting: boolean;
-  onSubmit: (answer: SubmitInterviewAnswer) => Promise<void>;
+  onSubmit: (answer: SubmitInterviewAnswer) => Promise<boolean>;
 }) {
   const [selected, setSelected] = useState<Set<string>>(new Set());
 
@@ -352,11 +391,14 @@ function MultiSelectBody({
     if (selected.has(option.key)) selectedKeys.push(option.key);
   }
 
+  const stacked = shouldStackOptions(options);
+
   return (
-    <div className="space-y-3">
-      <div className="flex flex-wrap items-center gap-2">
+    <div className="space-y-2.5">
+      <div className={optionListClass(stacked)}>
         {options.map((option) => {
           const isSelected = selected.has(option.key);
+          const base = isSelected ? DOCK_CHOICE_BUTTON_SELECTED : DOCK_CHOICE_BUTTON;
           return (
             <button
               key={option.key}
@@ -364,7 +406,7 @@ function MultiSelectBody({
               disabled={submitting}
               aria-pressed={isSelected}
               onClick={() => toggle(option.key)}
-              className={isSelected ? CHOICE_BUTTON_SELECTED : CHOICE_BUTTON}
+              className={stacked ? `${base} justify-start` : base}
             >
               {isSelected && <CheckIcon className="size-3.5" aria-hidden="true" />}
               <OptionLabel option={option} />
@@ -380,9 +422,13 @@ function MultiSelectBody({
           type="button"
           disabled={submitting || selectedKeys.length === 0}
           onClick={() => void onSubmit({ kind: "multi_selected", option_keys: selectedKeys })}
-          className={PRIMARY_BUTTON}
+          className={PRIMARY_BUTTON_CLASS}
         >
-          {submitting ? <Spinner /> : <CheckIcon className="size-4" aria-hidden="true" />}
+          {submitting ? (
+            <Spinner className="size-4" />
+          ) : (
+            <CheckIcon className="size-4" aria-hidden="true" />
+          )}
           Submit selection
         </button>
       </div>
@@ -390,82 +436,23 @@ function MultiSelectBody({
   );
 }
 
-function FreeformBody({
+function FreeformAnswer({
   submitting,
   onSubmit,
   placeholder,
-  submitLabel,
-  divider = false,
 }: {
   submitting: boolean;
-  onSubmit: (answer: SubmitInterviewAnswer) => Promise<void>;
+  onSubmit: (answer: SubmitInterviewAnswer) => Promise<boolean>;
   placeholder: string;
-  submitLabel: string;
-  divider?: boolean;
 }) {
-  const [value, setValue] = useState("");
-
-  async function handleSubmit(event: FormEvent<HTMLFormElement>) {
-    event.preventDefault();
-    const trimmed = value.trim();
-    if (!trimmed || submitting) return;
-    await onSubmit({ kind: "text", text: trimmed });
-    setValue("");
-  }
-
-  function handleKeyDown(event: KeyboardEvent<HTMLTextAreaElement>) {
-    if (event.key === "Enter" && !event.shiftKey) {
-      event.preventDefault();
-      const form = event.currentTarget.form;
-      if (form) form.requestSubmit();
-    }
-  }
-
-  const disabled = submitting || value.trim().length === 0;
-
   return (
-    <form onSubmit={handleSubmit} className="space-y-2">
-      {divider && (
-        <div className="flex items-center gap-3" aria-hidden="true">
-          <span className="h-px flex-1 bg-line" />
-          <span className="text-xs text-fg-muted">or</span>
-          <span className="h-px flex-1 bg-line" />
-        </div>
-      )}
-      <div className="flex items-end gap-2">
-        <label className="sr-only" htmlFor="interview-freeform-answer">
-          Your response
-        </label>
-        <textarea
-          id="interview-freeform-answer"
-          name="answer"
-          aria-label="Interview answer"
-          rows={1}
-          value={value}
-          onChange={(event) => setValue(event.target.value)}
-          onKeyDown={handleKeyDown}
-          placeholder={placeholder}
-          disabled={submitting}
-          className="block w-full resize-none rounded-lg bg-panel-alt px-3.5 py-2.5 text-base/6 text-fg outline-1 -outline-offset-1 outline-line-strong placeholder:text-fg-muted focus:outline-2 focus:-outline-offset-1 focus:outline-teal-500 disabled:opacity-60 sm:text-sm/5"
-        />
-        <button type="submit" disabled={disabled} className={PRIMARY_BUTTON}>
-          {submitting ? (
-            <Spinner />
-          ) : (
-            <ArrowUturnLeftIcon
-              className="size-3.5 -scale-x-100"
-              aria-hidden="true"
-            />
-          )}
-          {submitLabel}
-        </button>
-      </div>
-      <p className="text-xs text-fg-muted">
-        Press <kbd className="rounded bg-overlay px-1 font-mono text-[0.6875rem]">Enter</kbd> to
-        send · <kbd className="rounded bg-overlay px-1 font-mono text-[0.6875rem]">Shift</kbd>+
-        <kbd className="rounded bg-overlay px-1 font-mono text-[0.6875rem]">Enter</kbd> for a new line
-      </p>
-    </form>
+    <DockComposer
+      onSubmit={(text) => onSubmit({ kind: "text", text })}
+      placeholder={placeholder}
+      submitLabel="Send"
+      submitting={submitting}
+      ariaLabel="Interview answer"
+    />
   );
 }
 
@@ -482,27 +469,6 @@ function OptionLabel({ option }: { option: InterviewOption }) {
   );
 }
 
-function Spinner() {
-  return <ArrowPathIcon className="size-4 animate-spin" aria-hidden="true" />;
-}
-
-function questionTypeLabel(type: QuestionType): string {
-  switch (type) {
-    case QuestionType.YES_NO:
-      return "Yes or no";
-    case QuestionType.CONFIRMATION:
-      return "Confirmation required";
-    case QuestionType.MULTIPLE_CHOICE:
-      return "Pick one";
-    case QuestionType.MULTI_SELECT:
-      return "Pick one or more";
-    case QuestionType.FREEFORM:
-      return "Freeform response";
-    default:
-      return "";
-  }
-}
-
 function interviewSubmitErrorMessage(error: unknown): string {
   if (error instanceof ApiError) {
     return error.requestId

apps/fabro-web/app/components/review-target-question.tsx

@@ -0,0 +1,59 @@
+import { ArrowTopRightOnSquareIcon } from "@heroicons/react/20/solid";
+import type { ReviewTarget } from "@qltysh/fabro-api-client";
+
+/**
+ * Re-check the URL before putting it in an `href`. The server already rejects
+ * unsafe targets (see `ReviewTarget::new` in
+ * `lib/foundation/fabro-types/src/interview.rs`), but React does not sanitize
+ * `href`, so a `javascript:` URL reaching this component would execute. Length
+ * and control-character limits stay server-side; they cannot affect the DOM.
+ */
+export function safeReviewTarget(
+  target: ReviewTarget | null | undefined,
+): ReviewTarget | null {
+  if (!target?.url || !target.label) return null;
+  try {
+    const parsed = new URL(target.url);
+    const safe =
+      (parsed.protocol === "http:" || parsed.protocol === "https:") &&
+      Boolean(parsed.host) &&
+      !parsed.username &&
+      !parsed.password;
+    return safe ? target : null;
+  } catch {
+    return null;
+  }
+}
+
+/**
+ * The review question sentence, with the target label as an external link.
+ * Mirrors `ReviewTarget::question_text_with_link` in
+ * `lib/foundation/fabro-types/src/interview.rs`.
+ */
+export function ReviewTargetQuestion({
+  target,
+  className,
+}: {
+  target: ReviewTarget;
+  className?: string;
+}) {
+  return (
+    <p className={className}>
+      Review the{" "}
+      <a
+        href={target.url}
+        target="_blank"
+        rel="noopener noreferrer"
+        referrerPolicy="no-referrer"
+        className="inline-flex items-baseline gap-1 font-semibold text-teal-300 underline decoration-teal-500/50 underline-offset-2 transition-colors hover:text-fg focus-visible:rounded-sm focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-teal-500"
+      >
+        <span>{target.label}</span>
+        <ArrowTopRightOnSquareIcon
+          className="size-3 shrink-0 self-center"
+          aria-hidden="true"
+        />
+      </a>{" "}
+      {target.kind}, then choose the next action.
+    </p>
+  );
+}

apps/fabro-web/app/components/run-dock.test.tsx

@@ -0,0 +1,118 @@
+import {
+  afterEach,
+  beforeEach,
+  describe,
+  expect,
+  mock,
+  test,
+} from "bun:test";
+import TestRenderer, { act } from "react-test-renderer";
+
+import { setupReactTestEnv } from "../lib/test-utils";
+import { DockComposer } from "./run-dock";
+
+const mountedRenderers: TestRenderer.ReactTestRenderer[] = [];
+let teardownReactEnv: (() => void) | undefined;
+
+beforeEach(() => {
+  teardownReactEnv = setupReactTestEnv();
+});
+
+afterEach(() => {
+  for (const renderer of mountedRenderers.splice(0)) {
+    act(() => renderer.unmount());
+  }
+  teardownReactEnv?.();
+  teardownReactEnv = undefined;
+});
+
+describe("DockComposer", () => {
+  test("describes its keyboard behavior to assistive technology", () => {
+    let renderer!: TestRenderer.ReactTestRenderer;
+    act(() => {
+      renderer = TestRenderer.create(
+        <DockComposer
+          onSubmit={() => Promise.resolve(true)}
+          placeholder="Write a message"
+          submitLabel="Send"
+          submitting={false}
+          ariaLabel="Message"
+        />,
+      );
+    });
+    mountedRenderers.push(renderer);
+
+    const textarea = renderer.root.findByType("textarea");
+    const instruction = renderer.root.findByProps({
+      id: textarea.props["aria-describedby"],
+    });
+    expect(instruction.children.join("")).toBe(
+      "Press Enter to send. Press Shift+Enter for a new line.",
+    );
+    expect(textarea.props.name).toBeUndefined();
+  });
+
+  test("does not submit Enter while an IME composition is active", async () => {
+    const onSubmit = mock(() => Promise.resolve(true));
+    const preventDefault = mock(() => undefined);
+    let renderer!: TestRenderer.ReactTestRenderer;
+    act(() => {
+      renderer = TestRenderer.create(
+        <DockComposer
+          onSubmit={onSubmit}
+          placeholder="Write a message"
+          submitLabel="Send"
+          submitting={false}
+          ariaLabel="Message"
+        />,
+      );
+    });
+    mountedRenderers.push(renderer);
+    const textarea = renderer.root.findByType("textarea");
+
+    act(() => textarea.props.onChange({ target: { value: "draft" } }));
+    await act(async () => {
+      textarea.props.onKeyDown({
+        key: "Enter",
+        shiftKey: false,
+        nativeEvent: { isComposing: true },
+        preventDefault,
+      });
+    });
+
+    expect(preventDefault).not.toHaveBeenCalled();
+    expect(onSubmit).not.toHaveBeenCalled();
+  });
+
+  test("submits Enter after composition ends", async () => {
+    const onSubmit = mock(() => Promise.resolve(true));
+    const preventDefault = mock(() => undefined);
+    let renderer!: TestRenderer.ReactTestRenderer;
+    act(() => {
+      renderer = TestRenderer.create(
+        <DockComposer
+          onSubmit={onSubmit}
+          placeholder="Write a message"
+          submitLabel="Send"
+          submitting={false}
+          ariaLabel="Message"
+        />,
+      );
+    });
+    mountedRenderers.push(renderer);
+    const textarea = renderer.root.findByType("textarea");
+
+    act(() => textarea.props.onChange({ target: { value: "  ready  " } }));
+    await act(async () => {
+      textarea.props.onKeyDown({
+        key: "Enter",
+        shiftKey: false,
+        nativeEvent: { isComposing: false },
+        preventDefault,
+      });
+    });
+
+    expect(preventDefault).toHaveBeenCalledTimes(1);
+    expect(onSubmit).toHaveBeenCalledWith("ready");
+  });
+});

apps/fabro-web/app/components/run-dock.tsx

@@ -0,0 +1,317 @@
+import {
+  useId,
+  useState,
+  type FormEvent,
+  type KeyboardEvent,
+  type ReactNode,
+  type Ref,
+} from "react";
+import {
+  ArrowUturnLeftIcon,
+  ChevronUpIcon,
+} from "@heroicons/react/20/solid";
+
+import { classNames } from "../lib/class-names";
+import { Spinner } from "./state";
+import {
+  INPUT_CLASS,
+  PRIMARY_BUTTON_CLASS,
+} from "./ui";
+
+/**
+ * Shared chrome for the two controls docked at the bottom of the run detail
+ * route: the interview question panel and the steering composer.
+ *
+ * The shell is three zones. The header is always visible and doubles as the
+ * collapsed bar. The body scrolls. The actions stay pinned, so the controls
+ * needed to answer or send never scroll out of reach.
+ *
+ * Collapsed state is owned by the caller. Each dock has its own rule for when
+ * a collapsed panel must reopen — a new question for the interview, a run
+ * waiting for steering for the composer — and those rules are clearer next to
+ * the state they depend on.
+ */
+
+/** Ceiling on the expanded dock, so a long body cannot take the page. */
+const DOCK_MAX_HEIGHT = "max-h-[60vh]";
+
+export const DOCK_HEADER_BUTTON =
+  "inline-flex shrink-0 items-center gap-1.5 rounded-md bg-overlay px-2 py-1 text-xs font-medium text-fg-2 outline-1 -outline-offset-1 outline-line-strong transition-colors hover:bg-overlay-strong hover:text-fg focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-teal-500 disabled:cursor-not-allowed disabled:opacity-50 disabled:hover:bg-overlay disabled:hover:text-fg-2";
+
+export const DOCK_CHOICE_BUTTON =
+  "inline-flex items-center justify-center gap-1.5 rounded-lg bg-overlay px-3.5 py-2 text-left text-sm font-medium text-fg-2 outline-1 -outline-offset-1 outline-line-strong transition-colors hover:bg-overlay-strong hover:text-fg focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500 disabled:cursor-not-allowed disabled:opacity-60";
+
+export const DOCK_CHOICE_BUTTON_SELECTED =
+  "inline-flex items-center justify-center gap-1.5 rounded-lg bg-teal-500/15 px-3.5 py-2 text-left text-sm font-medium text-fg outline-1 -outline-offset-1 outline-teal-500/60 transition-colors hover:bg-teal-500/20 focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500";
+
+/**
+ * How the dock signals its state.
+ *
+ * - `waiting` pulses amber: the run is blocked on the operator, as expected.
+ * - `alert` pulses amber and colors the label too, for a run that went off
+ *   its normal path and is stuck until someone acts.
+ * - `idle` is a resting control with no pending demand.
+ */
+export type DockTone = "waiting" | "alert" | "idle";
+
+export interface RunDockShellProps {
+  /** Accessible name for the docked region. */
+  label: string;
+  className?: string;
+  tone: DockTone;
+  /** Short state phrase, e.g. "Awaiting input". */
+  status: string;
+  /** Stage name shown in mono beside the status. */
+  stage?: string | null;
+  /** One-line summary shown only while collapsed. */
+  peek?: string | null;
+  /** Run-level controls, rendered beside the collapse toggle. */
+  headerActions?: ReactNode;
+  /** Scrolling zone. Omit when there is nothing to scroll. */
+  body?: ReactNode;
+  /** Pinned zone. */
+  actions: ReactNode;
+  collapsed: boolean;
+  onCollapsedChange: (collapsed: boolean) => void;
+}
+
+export function RunDockShell({
+  label,
+  className,
+  tone,
+  status,
+  stage,
+  peek,
+  headerActions,
+  body,
+  actions,
+  collapsed,
+  onCollapsedChange,
+}: RunDockShellProps) {
+  const contentId = useId();
+
+  return (
+    <section
+      aria-label={label}
+      className={classNames(
+        "flex flex-col",
+        !collapsed && DOCK_MAX_HEIGHT,
+        className,
+      )}
+    >
+      <div className="flex shrink-0 items-center gap-2.5 px-5 py-2 sm:px-6">
+        <StatusDot tone={tone} />
+        {/* A live region: the dock changing to a state that needs the
+            operator has to reach assistive tech, not only the eye. */}
+        <span
+          role="status"
+          className={`shrink-0 text-sm font-medium ${
+            tone === "alert" ? "text-amber" : "text-fg-2"
+          }`}
+        >
+          {status}
+        </span>
+        {stage && (
+          <>
+            <span className="shrink-0 text-fg-muted" aria-hidden="true">
+              ·
+            </span>
+            <span className="min-w-0 truncate font-mono text-xs text-fg-3">
+              {stage}
+            </span>
+          </>
+        )}
+        {collapsed && peek ? (
+          <span className="min-w-0 flex-1 truncate text-sm text-fg-3">
+            · {peek}
+          </span>
+        ) : (
+          <span className="flex-1" />
+        )}
+        {headerActions}
+        <button
+          type="button"
+          onClick={() => onCollapsedChange(!collapsed)}
+          aria-expanded={!collapsed}
+          aria-controls={contentId}
+          aria-label={collapsed ? `Expand ${label}` : `Collapse ${label}`}
+          className="inline-flex size-6.5 shrink-0 items-center justify-center rounded-md text-fg-3 transition-colors hover:bg-overlay hover:text-fg focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-teal-500"
+        >
+          <ChevronUpIcon
+            className={`size-4 transition-transform duration-200 ease-[cubic-bezier(0.16,1,0.3,1)] ${
+              collapsed ? "rotate-180" : ""
+            }`}
+            aria-hidden="true"
+          />
+        </button>
+      </div>
+
+      {/* Hidden rather than unmounted, so a half-written message survives a
+          collapse. The display utility is swapped rather than layered, so two
+          display classes cannot collide in the cascade. */}
+      <div
+        id={contentId}
+        className={collapsed ? "hidden" : "flex min-h-0 flex-1 flex-col"}
+      >
+        {body && (
+          <div className="min-h-0 flex-1 space-y-3 overflow-y-auto border-t border-line px-5 pt-3.5 pb-1 sm:px-6">
+            {body}
+          </div>
+        )}
+        <div
+          className={classNames(
+            "flex max-h-[50%] shrink-0 flex-col gap-2.5 overflow-y-auto px-5 pt-2.5 pb-3.5 sm:px-6",
+            !body && "border-t border-line",
+          )}
+        >
+          {actions}
+        </div>
+      </div>
+    </section>
+  );
+}
+
+function StatusDot({ tone }: { tone: DockTone }) {
+  if (tone === "idle") {
+    return (
+      <span
+        className="size-2 shrink-0 rounded-full bg-fg-muted"
+        aria-hidden="true"
+      />
+    );
+  }
+  return (
+    <span
+      className="relative flex size-2 shrink-0 items-center justify-center"
+      aria-hidden="true"
+    >
+      <span className="absolute inline-flex size-full animate-ping rounded-full bg-amber/60" />
+      <span className="relative inline-flex size-2 rounded-full bg-amber" />
+    </span>
+  );
+}
+
+export interface DockComposerProps {
+  /**
+   * Sends the trimmed text. Resolve `true` to clear the box; resolve `false`
+   * to keep what the operator typed, so a failed send is not lost.
+   */
+  onSubmit: (text: string) => Promise<boolean>;
+  placeholder: string;
+  submitLabel: string;
+  pendingLabel?: string;
+  submitting: boolean;
+  disabled?: boolean;
+  ariaLabel: string;
+  className?: string;
+  maxLength?: number;
+  textareaRef?: Ref<HTMLTextAreaElement>;
+}
+
+/**
+ * The single composer used by both docks: the interview's freeform answer and
+ * the steering message. Enter sends, Shift+Enter breaks the line, and the
+ * hint for that only appears on focus — inside the row, so revealing it does
+ * not shift the layout.
+ */
+export function DockComposer({
+  onSubmit,
+  placeholder,
+  submitLabel,
+  pendingLabel,
+  submitting,
+  disabled = false,
+  ariaLabel,
+  className,
+  maxLength,
+  textareaRef,
+}: DockComposerProps) {
+  const [value, setValue] = useState("");
+  const fieldId = useId();
+  const instructionId = `${fieldId}-instruction`;
+  const trimmed = value.trim();
+  const composerDisabled = disabled || submitting;
+  const canSend = trimmed.length > 0 && !composerDisabled;
+
+  async function send() {
+    if (!canSend) return;
+    const cleared = await onSubmit(trimmed);
+    if (cleared) setValue("");
+  }
+
+  function handleSubmit(event: FormEvent<HTMLFormElement>) {
+    event.preventDefault();
+    void send();
+  }
+
+  function handleKeyDown(event: KeyboardEvent<HTMLTextAreaElement>) {
+    if (
+      event.key === "Enter" &&
+      !event.shiftKey &&
+      !event.nativeEvent.isComposing
+    ) {
+      event.preventDefault();
+      void send();
+    }
+  }
+
+  return (
+    <form
+      onSubmit={handleSubmit}
+      className={classNames("group flex items-end gap-2", className)}
+    >
+      <label className="sr-only" htmlFor={fieldId}>
+        {ariaLabel}
+      </label>
+      <p id={instructionId} className="sr-only">
+        Press Enter to send. Press Shift+Enter for a new line.
+      </p>
+      <textarea
+        id={fieldId}
+        ref={textareaRef}
+        aria-label={ariaLabel}
+        aria-describedby={instructionId}
+        rows={1}
+        value={value}
+        maxLength={maxLength}
+        onChange={(event) => setValue(event.target.value)}
+        onKeyDown={handleKeyDown}
+        placeholder={placeholder}
+        disabled={composerDisabled}
+        className={`${INPUT_CLASS} min-w-0 flex-1 resize-none disabled:opacity-60`}
+      />
+      <p
+        aria-hidden="true"
+        className="pointer-events-none hidden shrink-0 items-center gap-1 pb-2.5 text-xs whitespace-nowrap text-fg-muted opacity-0 transition-opacity group-focus-within:opacity-100 md:flex"
+      >
+        <kbd className="rounded bg-overlay px-1 font-mono text-[0.6875rem]">
+          Enter
+        </kbd>
+        send
+        <kbd className="rounded bg-overlay px-1 font-mono text-[0.6875rem]">
+          Shift
+        </kbd>
+        +
+        <kbd className="rounded bg-overlay px-1 font-mono text-[0.6875rem]">
+          Enter
+        </kbd>
+        newline
+      </p>
+      <button
+        type="submit"
+        disabled={!canSend}
+        className={PRIMARY_BUTTON_CLASS}
+      >
+        {submitting ? (
+          <Spinner className="size-4" />
+        ) : (
+          <ArrowUturnLeftIcon
+            className="size-3.5 -scale-x-100"
+            aria-hidden="true"
+          />
+        )}
+        {submitting && pendingLabel ? pendingLabel : submitLabel}
+      </button>
+    </form>
+  );
+}

apps/fabro-web/app/components/runs-list/run-table-row.tsx

@@ -115,8 +115,10 @@ export function RunTableRow({
         </td>
       )}
       {show("size") && (
-        <td className="whitespace-nowrap px-3 py-2.5 text-center">
-          {run.size != null && <SizeChip size={run.size} />}
+        <td className="relative z-10 px-3 py-2.5 text-center whitespace-nowrap">
+          {run.size != null && (
+            <SizeChip size={run.size} totalUsdMicros={run.totalUsdMicros} />
+          )}
         </td>
       )}
       {show("changes") && (

apps/fabro-web/app/components/size-chip.test.tsx

@@ -0,0 +1,58 @@
+import { afterEach, beforeEach, describe, expect, test } from "bun:test";
+import TestRenderer, { act } from "react-test-renderer";
+
+import { setupReactTestEnv } from "../lib/test-utils";
+import { SizeChip } from "./size-chip";
+import { Tooltip } from "./ui";
+
+let teardownReactTestEnv: (() => void) | undefined;
+const mountedRenderers: TestRenderer.ReactTestRenderer[] = [];
+
+function render(element: React.ReactElement): TestRenderer.ReactTestRenderer {
+  let renderer: TestRenderer.ReactTestRenderer | undefined;
+  act(() => {
+    renderer = TestRenderer.create(element);
+  });
+  mountedRenderers.push(renderer!);
+  return renderer!;
+}
+
+function tooltipLabel(element: React.ReactElement): string {
+  return render(element).root.findByType(Tooltip).props.label as string;
+}
+
+describe("SizeChip", () => {
+  beforeEach(() => {
+    teardownReactTestEnv = setupReactTestEnv();
+  });
+
+  afterEach(() => {
+    act(() => {
+      for (const renderer of mountedRenderers.splice(0)) {
+        renderer.unmount();
+      }
+    });
+    teardownReactTestEnv?.();
+    teardownReactTestEnv = undefined;
+  });
+
+  test("renders the size letter", () => {
+    expect(JSON.stringify(render(<SizeChip size="M" />).toJSON())).toContain("M");
+  });
+
+  test("appends the cost to the tooltip", () => {
+    expect(tooltipLabel(<SizeChip size="M" totalUsdMicros={12_340_000} />))
+      .toBe("Size M · $12.34");
+  });
+
+  test("omits the cost when the run has no billing yet", () => {
+    expect(tooltipLabel(<SizeChip size="M" />)).toBe("Size M");
+    expect(tooltipLabel(<SizeChip size="M" totalUsdMicros={null} />)).toBe("Size M");
+  });
+
+  test("calls out the tiers that warrant attention", () => {
+    expect(tooltipLabel(<SizeChip size="L" totalUsdMicros={150_000_000} />))
+      .toBe("Size L (risky) · $150.00");
+    expect(tooltipLabel(<SizeChip size="XL" />)).toBe("Size XL (unhealthy)");
+  });
+});

apps/fabro-web/app/components/size-chip.tsx

@@ -1,3 +1,4 @@
+import { memo } from "react";
 import type { RunSize } from "@qltysh/fabro-api-client";
 
 import { formatUsdMicros } from "../lib/format";
@@ -11,7 +12,7 @@ const SIZE_TONE: Record<RunSize, { className: string; note: string | null }> = {
   XL: { className: "bg-coral/15 text-coral",     note: "unhealthy" },
 };
 
-export function SizeChip({
+export const SizeChip = memo(function SizeChip({
   size,
   totalUsdMicros,
 }: {
@@ -19,10 +20,10 @@ export function SizeChip({
   totalUsdMicros?: number | null;
 }) {
   const tone = SIZE_TONE[size];
-  const billed = totalUsdMicros != null ? ` · ${formatUsdMicros(totalUsdMicros)} billed` : "";
+  const amount = totalUsdMicros != null ? ` · ${formatUsdMicros(totalUsdMicros)}` : "";
   const tooltip = tone.note != null
-    ? `Size ${size} (${tone.note})${billed}`
-    : `Size ${size}${billed}`;
+    ? `Size ${size} (${tone.note})${amount}`
+    : `Size ${size}${amount}`;
   return (
     <Tooltip label={tooltip}>
       <span className={`rounded px-1.5 py-0.5 font-mono text-xs font-bold tabular-nums ${tone.className}`}>
@@ -30,4 +31,4 @@ export function SizeChip({
       </span>
     </Tooltip>
   );
-}
+});

apps/fabro-web/app/components/stage-popover.test.tsx

@@ -9,6 +9,7 @@ import { StagePopover } from "./stage-popover";
 import { deriveStageSummary } from "./stage-popover-summary";
 import type { Stage } from "../lib/stage-sidebar";
 import { generatedAxios } from "../lib/api-client";
+import { makeStage as baseMakeStage } from "../lib/test-utils";
 
 function makeEvent(overrides: Partial<EventEnvelope>): EventEnvelope {
   return {
@@ -22,20 +23,13 @@ function makeEvent(overrides: Partial<EventEnvelope>): EventEnvelope {
 }
 
 function makeStage(overrides: Partial<Stage> = {}): Stage {
-  return {
-    id:                 "implement@1",
-    name:               "implement",
-    handler:            "agent",
-    nodeId:             "implement",
-    visit:              1,
-    graphVisit:         null,
-    resumedFromStageId: null,
-    status:             "succeeded",
-    duration:           "1m 30s",
-    startedAt:          "2026-05-24T11:58:30Z",
-    providerUsed:       { mode: "policy", model: "claude-opus-4-7", reasoning_effort: "high" },
+  return baseMakeStage({
+    status:       "succeeded",
+    duration:     "1m 30s",
+    startedAt:    "2026-05-24T11:58:30Z",
+    providerUsed: { mode: "policy", model: "claude-opus-4-7", reasoning_effort: "high" },
     ...overrides,
-  };
+  });
 }
 
 describe("deriveStageSummary", () => {

apps/fabro-web/app/components/stage-renderers/fan-in-results.test.tsx

@@ -3,6 +3,7 @@ import type { EventEnvelope } from "@qltysh/fabro-api-client";
 import TestRenderer, { act } from "react-test-renderer";
 
 import { makeEventEnvelope, setupReactTestEnv } from "../../lib/test-utils";
+import { makeBilledTokenCounts } from "../../lib/test-fixtures";
 import type { Stage } from "../stage-sidebar";
 import { FanInResults } from "./fan-in-results";
 
@@ -22,6 +23,7 @@ const fanInStage: Stage = {
   visit: 1,
   startedAt: "2026-04-09T12:00:00Z",
   providerUsed: null,
+  billing: makeBilledTokenCounts(),
 };
 
 function event(seq: number, partial: Partial<EventEnvelope>): EventEnvelope {

apps/fabro-web/app/components/stage-renderers/helpers.test.ts

@@ -98,6 +98,33 @@ describe("parseHumanInterviewPairs", () => {
     });
   });
 
+  test("preserves a typed review target from started events", () => {
+    const events: EventEnvelope[] = [
+      makeEventEnvelope(1, {
+        event: "interview.started",
+        properties: {
+          question_id: "q-1",
+          question:
+            "Review the Quarry review exercise document, then choose the next action.",
+          question_type: "multiple_choice",
+          review_target: {
+            label: "Quarry review exercise",
+            url: "https://quarry.lithos.computer/tmp/0123456789abcdef0123456789abcdef",
+            kind: "document",
+          },
+        },
+      }),
+    ];
+
+    const pairs = parseHumanInterviewPairs(events);
+
+    expect(pairs[0].question.reviewTarget).toEqual({
+      label: "Quarry review exercise",
+      url: "https://quarry.lithos.computer/tmp/0123456789abcdef0123456789abcdef",
+      kind: "document",
+    });
+  });
+
   test("captures timeout and interrupted resolutions", () => {
     const events: EventEnvelope[] = [
       makeEventEnvelope(1, {

apps/fabro-web/app/components/stage-renderers/helpers.ts

@@ -1,7 +1,14 @@
-import { StageOutcome } from "@qltysh/fabro-api-client";
-import type { EventEnvelope } from "@qltysh/fabro-api-client";
+import { ReviewTargetKind, StageOutcome } from "@qltysh/fabro-api-client";
+import type { EventEnvelope, ReviewTarget } from "@qltysh/fabro-api-client";
 
-import { getArray, getNumber, getObject, getString, type UnknownRecord } from "../../lib/unknown";
+import {
+  getArray,
+  getNumber,
+  getObject,
+  getString,
+  isRecord,
+  type UnknownRecord,
+} from "../../lib/unknown";
 
 const STAGE_OUTCOMES: ReadonlySet<string> = new Set(Object.values(StageOutcome));
 
@@ -25,6 +32,7 @@ export interface HumanQuestion {
   allowFreeform: boolean;
   timeoutSeconds: number | null;
   contextDisplay: string | null;
+  reviewTarget: ReviewTarget | null;
 }
 
 export type HumanResolution =
@@ -75,6 +83,15 @@ function parseInterviewOptions(value: unknown): InterviewOption[] {
   return out;
 }
 
+function parseReviewTarget(value: unknown): ReviewTarget | null {
+  if (!isRecord(value)) return null;
+  const label = getString(value, "label");
+  const url = getString(value, "url");
+  const kind = getString(value, "kind");
+  if (!label || !url || kind !== ReviewTargetKind.DOCUMENT) return null;
+  return { label, url, kind };
+}
+
 /**
  * Pair `interview.started` events with the matching `interview.completed`,
  * `.timeout`, or `.interrupted` resolution by `question_id`. Unanswered
@@ -98,6 +115,7 @@ export function parseHumanInterviewPairs(events: EventEnvelope[]): HumanIntervie
           allowFreeform: props.allow_freeform === true,
           timeoutSeconds: getNumber(props, "timeout_seconds") ?? null,
           contextDisplay: getString(props, "context_display") ?? null,
+          reviewTarget: parseReviewTarget(props.review_target),
         },
         resolution: null,
       });

apps/fabro-web/app/components/stage-renderers/human-qa.tsx

@@ -10,6 +10,10 @@ import {
 import type { EventEnvelope } from "@qltysh/fabro-api-client";
 
 import type { Stage } from "../stage-sidebar";
+import {
+  ReviewTargetQuestion,
+  safeReviewTarget,
+} from "../review-target-question";
 import { Tooltip } from "../ui";
 import { formatAbsoluteTs, formatDurationMs } from "../../lib/format";
 import { ACTIVE_STAGE_STATES } from "../../lib/stage-sidebar";
@@ -148,6 +152,7 @@ function QuestionBlock({
   stageActive: boolean;
 }) {
   const { question, resolution } = pair;
+  const reviewTarget = safeReviewTarget(question.reviewTarget);
   return (
     <article className="space-y-3">
       <header className="flex flex-wrap items-baseline gap-x-3 gap-y-1">
@@ -168,7 +173,14 @@ function QuestionBlock({
       </header>
 
       <div className="rounded-lg bg-panel p-4 outline-1 -outline-offset-1 outline-line">
-        <Markdown content={question.question} />
+        {reviewTarget ? (
+          <ReviewTargetQuestion
+            target={reviewTarget}
+            className="text-sm/6 text-fg-2"
+          />
+        ) : (
+          <Markdown content={question.question} />
+        )}
         {question.contextDisplay && (
           <div className="mt-3 border-t border-line pt-3 text-xs text-fg-muted">
             <Markdown content={question.contextDisplay} />

apps/fabro-web/app/components/stage-renderers/parallel-children.test.tsx

@@ -1,9 +1,15 @@
 import { afterEach, beforeEach, describe, expect, test } from "bun:test";
+import { StageOutcome, StageState } from "@qltysh/fabro-api-client";
 import type { EventEnvelope } from "@qltysh/fabro-api-client";
 import TestRenderer, { act } from "react-test-renderer";
 import { MemoryRouter } from "react-router";
 
-import { makeEventEnvelope, setupReactTestEnv } from "../../lib/test-utils";
+import {
+  makeEventEnvelope,
+  makeStage as baseMakeStage,
+  setupReactTestEnv,
+  textContent,
+} from "../../lib/test-utils";
 import type { Stage } from "../stage-sidebar";
 import { ParallelChildren } from "./parallel-children";
 
@@ -13,35 +19,88 @@ beforeEach(() => {
 });
 afterEach(() => teardown());
 
-const parallelStage: Stage = {
+function makeStage(overrides: Partial<Stage> = {}): Stage {
+  return baseMakeStage({
+    id: "stage@1",
+    name: "stage",
+    nodeId: "stage",
+    graphVisit: 1,
+    startedAt: "2026-04-09T12:00:00Z",
+    ...overrides,
+  });
+}
+
+const parallelStage = makeStage({
   id: "fork@1",
   name: "fork",
   handler: "parallel",
-  status: "succeeded",
+  status: StageState.RUNNING,
   duration: "12s",
   nodeId: "fork",
-  visit: 1,
-  startedAt: "2026-04-09T12:00:00Z",
-  providerUsed: null,
-};
+});
 
-function event(partial: Partial<EventEnvelope>): EventEnvelope {
-  return makeEventEnvelope(partial.seq ?? 1, { event: "parallel.completed", ...partial });
+function branchStage(
+  name: string,
+  index: number,
+  status: StageState,
+  groupId = "fork@1",
+  visit = 1,
+): Stage {
+  return makeStage({
+    id: `${name}@${visit}`,
+    name,
+    nodeId: name,
+    visit,
+    status,
+    parallelGroupId: groupId,
+    parallelBranchIndex: index,
+  });
 }
 
-function renderParallel(events: EventEnvelope[]): TestRenderer.ReactTestRenderer {
+function event(partial: Partial<EventEnvelope>): EventEnvelope {
+  return makeEventEnvelope(partial.seq ?? 1, {
+    event: "parallel.completed",
+    stage_id: "fork@1",
+    ...partial,
+  });
+}
+
+function startedEvent(branchCount: number): EventEnvelope {
+  return event({
+    event: "parallel.started",
+    properties: { branch_count: branchCount },
+  });
+}
+
+function completedEvent(results: Array<{ id: string; status: StageOutcome }>): EventEnvelope {
+  const countOf = (status: StageOutcome) =>
+    results.filter((result) => result.status === status).length;
+  return event({
+    seq: 2,
+    event: "parallel.completed",
+    properties: {
+      duration_ms: 12000,
+      success_count: countOf(StageOutcome.SUCCEEDED),
+      failure_count: countOf(StageOutcome.FAILED),
+      results: results.map((result) => ({ ...result, context_updates: {} })),
+    },
+  });
+}
+
+function renderParallel(
+  events: EventEnvelope[],
+  allStages: Stage[],
+  stage = parallelStage,
+): TestRenderer.ReactTestRenderer {
   let renderer!: TestRenderer.ReactTestRenderer;
   act(() => {
     renderer = TestRenderer.create(
       <MemoryRouter>
         <ParallelChildren
-          stage={parallelStage}
+          stage={stage}
           events={events}
           runId="run-1"
-          allStages={[
-            { ...parallelStage, id: "branch-a@1", name: "branch-a", nodeId: "branch-a", handler: "agent" },
-            { ...parallelStage, id: "branch-b@1", name: "branch-b", nodeId: "branch-b", handler: "agent", status: "failed" },
-          ]}
+          allStages={allStages}
         />
       </MemoryRouter>,
     );
@@ -49,38 +108,149 @@ function renderParallel(events: EventEnvelope[]): TestRenderer.ReactTestRenderer
   return renderer;
 }
 
-describe("ParallelChildren", () => {
-  test("renders branch status and stage links without checkout metadata", () => {
-    const renderer = renderParallel([
-      event({
-        event: "parallel.started",
-        properties: { branch_count: 2 },
-      }),
-      event({
-        seq: 2,
-        event: "parallel.completed",
-        properties: {
-          duration_ms: 12000,
-          success_count: 1,
-          failure_count: 1,
-          results: [
-            { id: "branch-a", status: "succeeded", context_updates: {} },
-            { id: "branch-b", status: "failed", context_updates: {} },
-          ],
-        },
-      }),
-    ]);
+function branchRowText(renderer: TestRenderer.ReactTestRenderer): string[] {
+  return renderer.root.findAllByType("li").map(textContent);
+}
 
-    const rendered = JSON.stringify(renderer.toJSON());
-    expect(rendered).toContain("branch-a");
-    expect(rendered).toContain("Succeeded");
-    expect(rendered).toContain("branch-b");
-    expect(rendered).toContain("Failed");
-    const hrefs = renderer.root.findAllByType("a").map((link) => link.props.href);
-    expect(hrefs).toEqual([
-      "/runs/run-1/stages/branch-a@1",
-      "/runs/run-1/stages/branch-b@1",
+function hrefs(renderer: TestRenderer.ReactTestRenderer): string[] {
+  return renderer.root.findAllByType("a").map((link) => link.props.href);
+}
+
+function statValue(renderer: TestRenderer.ReactTestRenderer, label: string): string {
+  return textContent(renderer.root.findByProps({ "data-stat": label }));
+}
+
+describe("ParallelChildren", () => {
+  test("renders live branch names, statuses, counts, and stage links", () => {
+    const renderer = renderParallel(
+      [startedEvent(2)],
+      [
+        branchStage("review_glm", 0, StageState.SUCCEEDED),
+        branchStage("review_opus", 1, StageState.RUNNING),
+      ],
+    );
+
+    const rows = branchRowText(renderer);
+    expect(rows).toHaveLength(2);
+    expect(rows[0]).toContain("Succeeded");
+    expect(rows[0]).toContain("review_glm");
+    expect(rows[1]).toContain("Running");
+    expect(rows[1]).toContain("review_opus");
+    expect(hrefs(renderer)).toEqual([
+      "/runs/run-1/stages/review_glm@1",
+      "/runs/run-1/stages/review_opus@1",
     ]);
+    expect(statValue(renderer, "Succeeded")).toBe("1");
+    expect(statValue(renderer, "Failed")).toBe("0");
+  });
+
+  test("keeps looped fork links scoped to the selected fork visit", () => {
+    const renderer = renderParallel(
+      [startedEvent(1)],
+      [
+        branchStage("review_glm", 0, StageState.SUCCEEDED, "fork@1", 1),
+        branchStage("review_glm", 0, StageState.RUNNING, "fork@2", 2),
+      ],
+    );
+
+    expect(hrefs(renderer)).toEqual(["/runs/run-1/stages/review_glm@1"]);
+  });
+
+  test("shows a late-starting branch when lower indexes have no stage yet", () => {
+    // Branches queued behind `max_parallel` reserve no stage identity, so the
+    // observed indexes are sparse. Sizing the list by entry count would drop
+    // the only running branch.
+    const renderer = renderParallel([], [branchStage("review_opus", 2, StageState.RUNNING)]);
+
+    expect(branchRowText(renderer)).toEqual([
+      "PendingBranch 1",
+      "PendingBranch 2",
+      "Runningreview_opus",
+    ]);
+    expect(hrefs(renderer)).toEqual(["/runs/run-1/stages/review_opus@1"]);
+    expect(statValue(renderer, "Branches")).toBe("3");
+  });
+
+  test("renders branches with no stage or result yet as pending placeholders", () => {
+    const renderer = renderParallel([startedEvent(3)], [branchStage("review_glm", 0, StageState.RUNNING)]);
+
+    expect(branchRowText(renderer)).toEqual([
+      "Runningreview_glm",
+      "PendingBranch 2",
+      "PendingBranch 3",
+    ]);
+    expect(statValue(renderer, "Succeeded")).toBe("0");
+    expect(statValue(renderer, "Failed")).toBe("0");
+  });
+
+  test("labels a re-entered branch with its visit, matching the sidebar", () => {
+    const renderer = renderParallel(
+      [startedEvent(1)],
+      [branchStage("review_glm", 0, StageState.RUNNING, "fork@2", 2)],
+      makeStage({ id: "fork@2", name: "fork", handler: "parallel", visit: 2 }),
+    );
+
+    expect(branchRowText(renderer)).toEqual(["Runningreview_glm@2"]);
+    expect(hrefs(renderer)).toEqual(["/runs/run-1/stages/review_glm@2"]);
+  });
+
+  test("keeps duplicate branch targets in index order and only links recorded stages", () => {
+    const renderer = renderParallel(
+      [
+        startedEvent(2),
+        completedEvent([
+          { id: "review", status: StageOutcome.FAILED },
+          { id: "review", status: StageOutcome.FAILED },
+        ]),
+      ],
+      [branchStage("review", 0, StageState.SUCCEEDED)],
+    );
+
+    const rows = branchRowText(renderer);
+    expect(rows).toHaveLength(2);
+    expect(rows[0]).toContain("Succeeded");
+    expect(rows[1]).toContain("Failed");
+    expect(hrefs(renderer)).toEqual(["/runs/run-1/stages/review@1"]);
+  });
+
+  test("renders a completed result without a matching stage as an unlinked row", () => {
+    const renderer = renderParallel(
+      [
+        startedEvent(1),
+        completedEvent([{ id: "legacy_branch", status: StageOutcome.SUCCEEDED }]),
+      ],
+      [],
+    );
+
+    expect(branchRowText(renderer)).toEqual(["Succeededlegacy_branch"]);
+    expect(hrefs(renderer)).toEqual([]);
+  });
+
+  test("counts partial and skipped branches as neither succeeded nor failed", () => {
+    const allStages = [
+      branchStage("partial", 0, StageState.PARTIALLY_SUCCEEDED),
+      branchStage("skipped", 1, StageState.SKIPPED),
+    ];
+    const running = renderParallel([startedEvent(2)], allStages);
+    const completed = renderParallel(
+      [
+        startedEvent(2),
+        completedEvent([
+          { id: "partial", status: StageOutcome.PARTIALLY_SUCCEEDED },
+          { id: "skipped", status: StageOutcome.SKIPPED },
+        ]),
+      ],
+      allStages,
+    );
+
+    expect([
+      statValue(running, "Succeeded"),
+      statValue(running, "Failed"),
+    ]).toEqual(["0", "0"]);
+    expect([
+      statValue(completed, "Succeeded"),
+      statValue(completed, "Failed"),
+    ]).toEqual(["0", "0"]);
   });
 
   test("uses item labels and avoids ambiguous id-only links", () => {

apps/fabro-web/app/components/stage-renderers/parallel-children.tsx

@@ -5,15 +5,24 @@ import { StageState } from "@qltysh/fabro-api-client";
 import type { EventEnvelope } from "@qltysh/fabro-api-client";
 
 import type { Stage } from "../stage-sidebar";
-import { stageStatusLabel, stageStatusTone } from "../../lib/stage-sidebar";
+import { formatStageLabel, stageStatusLabel, stageStatusTone } from "../../lib/stage-sidebar";
 import { formatDurationMs } from "../../lib/format";
 import { StageMetaBar } from "./meta-bar";
 import { parseParallelOverview } from "./helpers";
 import type { ParallelBranchSummary } from "./helpers";
 
-/** Branch row view state: completed outcomes plus a synthesized in-flight row. */
-interface BranchRow extends Omit<ParallelBranchSummary, "status"> {
+/** Branch row view state sourced from a live branch stage or completed result. */
+interface BranchRow {
+  label: string;
+  /**
+   * Secondary text, set only when `label` is a `for_each` item name. Every
+   * branch of one fan-out runs the same template node, so the node name is
+   * context rather than identity.
+   */
+  detail: string | null;
   status: StageState;
+  /** Null when no stage backs this branch yet, which also means it is unlinkable. */
+  stageId: string | null;
 }
 
 function StatItem({
@@ -32,38 +41,38 @@ function StatItem({
       <span className="text-[10px] font-medium uppercase tracking-[0.16em] text-fg-muted">
         {label}
       </span>
-      <span className={`font-mono text-xl tabular-nums ${toneClass}`}>{value}</span>
+      <span data-stat={label} className={`font-mono text-xl tabular-nums ${toneClass}`}>
+        {value}
+      </span>
     </div>
   );
 }
 
 function ChildRow({
-  result,
-  stageHref,
+  row,
+  runId,
 }: {
-  result: BranchRow;
-  stageHref: string | null;
+  row: BranchRow;
+  runId: string;
 }) {
-  const tone = stageStatusTone(result.status);
+  const tone = stageStatusTone(row.status);
 
   const inner = (
     <>
       <span
         className={`inline-flex w-24 shrink-0 justify-center rounded-full px-2 py-0.5 text-[10px] font-medium uppercase tracking-wider ${tone}`}
       >
-        {stageStatusLabel(result.status)}
+        {stageStatusLabel(row.status)}
       </span>
       <span className="min-w-0 flex flex-1 items-baseline gap-2">
-        <span className="truncate font-mono text-sm text-fg-3">
-          {result.itemLabel ?? result.id}
-        </span>
-        {result.itemLabel && (
+        <span className="truncate font-mono text-sm text-fg-3">{row.label}</span>
+        {row.detail && (
           <span className="shrink-0 font-mono text-[11px] text-fg-muted">
-            {result.id}
+            {row.detail}
           </span>
         )}
       </span>
-      {stageHref && (
+      {row.stageId && (
         <ArrowTopRightOnSquareIcon
           className="size-3.5 shrink-0 text-fg-muted transition-colors group-hover:text-fg-2"
           aria-hidden="true"
@@ -74,9 +83,9 @@ function ChildRow({
 
   return (
     <li className="flex items-center gap-3 px-4 py-2.5">
-      {stageHref ? (
+      {row.stageId ? (
         <Link
-          to={stageHref}
+          to={`/runs/${runId}/stages/${row.stageId}`}
           className="group flex flex-1 items-center gap-3 rounded -m-1 p-1 transition-colors hover:bg-overlay focus-visible:bg-overlay focus-visible:outline-2 focus-visible:-outline-offset-2 focus-visible:outline-teal-500"
         >
           {inner}
@@ -101,50 +110,93 @@ export function ParallelChildren({
 }) {
   const overview = useMemo(() => parseParallelOverview(events), [events]);
 
-  // Map node_id -> latest stage_id so we can deep-link branches.
-  const latestStageByNode = useMemo(() => {
-    const latest = new Map<string, Stage>();
-    for (const s of allStages) {
-      const prev = latest.get(s.nodeId);
-      if (!prev || s.visit > prev.visit) latest.set(s.nodeId, s);
+  const stagesByBranchIndex = useMemo(() => {
+    const byIndex = new Map<number, Stage>();
+    for (const candidate of allStages) {
+      if (
+        candidate.parallelGroupId === stage.id
+        && candidate.parallelBranchIndex != null
+      ) {
+        byIndex.set(candidate.parallelBranchIndex, candidate);
+      }
     }
-    return new Map(Array.from(latest.entries()).map(([nodeId, s]) => [nodeId, s.id]));
-  }, [allStages]);
+    return byIndex;
+  }, [allStages, stage.id]);
 
-  const resultCountByNode = useMemo(() => {
-    const counts = new Map<string, number>();
-    for (const result of overview.results) {
-      counts.set(result.id, (counts.get(result.id) ?? 0) + 1);
-    }
-    return counts;
+  // Key results by their own `index` rather than array position, so a row
+  // lines up with the branch stage carrying the same index.
+  const resultsByIndex = useMemo(() => {
+    const byIndex = new Map<number, ParallelBranchSummary>();
+    overview.results.forEach((result, position) => {
+      byIndex.set(result.index ?? position, result);
+    });
+    return byIndex;
   }, [overview.results]);
 
-  const items: BranchRow[] = overview.results.length > 0
-    ? overview.results
-    : overview.branchCount && overview.branchCount > 0
-      ? Array.from({ length: overview.branchCount }, (_, i) => ({
-          id: `branch ${i + 1}`,
-          index: i,
-          itemLabel: null,
-          status: StageState.RUNNING,
-        }))
-      : [];
+  // Branch indexes are sparse: a branch queued behind `max_parallel` has no
+  // stage identity yet, and one cancelled while queued never gets one. Size the
+  // list from the highest index seen so a late-starting branch is never hidden.
+  const branchCount = Math.max(
+    overview.branchCount ?? 0,
+    ...Array.from(resultsByIndex.keys(), (index) => index + 1),
+    ...Array.from(stagesByBranchIndex.keys(), (index) => index + 1),
+  );
+  const rows = Array.from({ length: branchCount }, (_, index): BranchRow => {
+    // A `for_each` branch is named by its item. Without that name every row of
+    // one fan-out would read as the same template node.
+    const result = resultsByIndex.get(index);
+    const itemLabel = result?.itemLabel ?? null;
+    // A live branch stage is the freshest source; fall back to the completed
+    // event's result for runs whose branches predate parallel identity.
+    const branchStage = stagesByBranchIndex.get(index);
+    if (branchStage) {
+      const stageLabel = formatStageLabel(branchStage);
+      return {
+        label: itemLabel ?? stageLabel,
+        detail: itemLabel ? stageLabel : null,
+        status: branchStage.status,
+        stageId: branchStage.id,
+      };
+    }
+    if (result) {
+      return {
+        label: itemLabel ?? result.id,
+        detail: itemLabel ? result.id : null,
+        status: result.status,
+        stageId: null,
+      };
+    }
+    return {
+      label: `Branch ${index + 1}`,
+      detail: null,
+      status: StageState.PENDING,
+      stageId: null,
+    };
+  });
+
+  // Count what is on screen, so the tiles can never contradict the rows.
+  let successCount = 0;
+  let failureCount = 0;
+  for (const row of rows) {
+    if (row.status === StageState.SUCCEEDED) successCount += 1;
+    else if (row.status === StageState.FAILED) failureCount += 1;
+  }
 
   return (
     <div className="space-y-6 pl-3 pr-4 sm:pr-6 lg:pr-8">
       <StageMetaBar stage={stage} />
 
       <section className="grid grid-cols-2 gap-x-6 gap-y-4 rounded-lg bg-panel p-5 outline-1 -outline-offset-1 outline-line sm:grid-cols-4">
-        <StatItem label="Branches" value={overview.branchCount ?? "—"} />
+        <StatItem label="Branches" value={branchCount || "—"} />
         <StatItem
           label="Succeeded"
-          value={overview.successCount ?? (overview.isComplete ? 0 : "—")}
+          value={successCount}
           tone="success"
         />
         <StatItem
           label="Failed"
-          value={overview.failureCount ?? (overview.isComplete ? 0 : "—")}
-          tone={overview.failureCount && overview.failureCount > 0 ? "danger" : "default"}
+          value={failureCount}
+          tone={failureCount > 0 ? "danger" : "default"}
         />
         <StatItem
           label="Duration"
@@ -156,26 +208,13 @@ export function ParallelChildren({
         <h3 className="mb-2 text-xs font-medium uppercase tracking-wider text-fg-muted">
           Branches
         </h3>
-        {items.length === 0 ? (
+        {rows.length === 0 ? (
           <p className="text-sm text-fg-muted">No branches recorded yet.</p>
         ) : (
           <ul className="divide-y divide-line rounded-lg bg-panel outline-1 -outline-offset-1 outline-line">
-            {items.map((result, i) => {
-              // A node id alone cannot identify one dynamic item when several
-              // results share the template target. Avoid linking every row to
-              // whichever execution happened to finish last.
-              const stageId = resultCountByNode.get(result.id) === 1
-                ? latestStageByNode.get(result.id)
-                : null;
-              const href = stageId ? `/runs/${runId}/stages/${stageId}` : null;
-              return (
-                <ChildRow
-                  key={`${result.id}-${result.index ?? i}`}
-                  result={result}
-                  stageHref={href}
-                />
-              );
-            })}
+            {rows.map((row, index) => (
+              <ChildRow key={index} row={row} runId={runId} />
+            ))}
           </ul>
         )}
       </section>

apps/fabro-web/app/components/stage-sidebar.test.tsx

@@ -2,24 +2,9 @@ import { describe, expect, test } from "bun:test";
 import TestRenderer, { act } from "react-test-renderer";
 import { MemoryRouter } from "react-router";
 
+import { makeStage } from "../lib/test-utils";
 import { StageSidebar, type Stage } from "./stage-sidebar";
 
-function makeStage(overrides: Partial<Stage> = {}): Stage {
-  return {
-    id:        "implement@1",
-    name:      "implement",
-    handler:   "agent",
-    nodeId:    "implement",
-    visit:     1,
-    graphVisit: null,
-    resumedFromStageId: null,
-    status:    "running",
-    duration:  "--",
-    startedAt: null,
-    providerUsed: null,
-    ...overrides,
-  };
-}
 
 function renderSidebar(stages: Stage[]): string {
   (globalThis as { IS_REACT_ACT_ENVIRONMENT?: boolean }).IS_REACT_ACT_ENVIRONMENT = true;

apps/fabro-web/app/components/steer-bar.test.tsx

@@ -1,22 +1,146 @@
-import { describe, expect, test } from "bun:test";
-import { createElement } from "react";
-import { renderToStaticMarkup } from "react-dom/server";
-
 import {
+  afterEach,
+  beforeEach,
+  describe,
+  expect,
+  mock,
+  test,
+} from "bun:test";
+import { createRef } from "react";
+import TestRenderer, { act } from "react-test-renderer";
+
+import { setupReactTestEnv } from "../lib/test-utils";
+
+let steerPending = false;
+let interruptPending = false;
+const steerTrigger = mock(() => Promise.resolve(undefined));
+const interruptTrigger = mock(() => Promise.resolve(undefined));
+
+mock.module("../lib/mutations", () => ({
+  useSteerRun: () => ({
+    isMutating: steerPending,
+    trigger: steerTrigger,
+  }),
+  useInterruptRun: () => ({
+    isMutating: interruptPending,
+    trigger: interruptTrigger,
+  }),
+}));
+
+const {
   isInterruptDisabled,
-  SteerWaitingStatus,
-} from "./steer-bar";
+  isSteerDockCollapsed,
+  SteerBar,
+  steerStatusLabel,
+} = await import("./steer-bar");
+type SteerBarHandle = import("./steer-bar").SteerBarHandle;
+mock.restore();
+
+const mountedRenderers: TestRenderer.ReactTestRenderer[] = [];
+let teardownReactEnv: (() => void) | undefined;
+
+function textFromNode(node: TestRenderer.ReactTestInstance): string {
+  return node.children
+    .map((child) =>
+      typeof child === "string" ? child : textFromNode(child),
+    )
+    .join("");
+}
+
+beforeEach(() => {
+  teardownReactEnv = setupReactTestEnv();
+  steerPending = false;
+  interruptPending = false;
+  steerTrigger.mockClear();
+  interruptTrigger.mockClear();
+});
+
+afterEach(() => {
+  for (const renderer of mountedRenderers.splice(0)) {
+    act(() => renderer.unmount());
+  }
+  teardownReactEnv?.();
+  teardownReactEnv = undefined;
+});
 
 describe("SteerBar", () => {
-  test("shows durable waiting state and prevents a second interrupt", () => {
+  test("prevents a second interrupt while one is in flight or already settled", () => {
     expect(isInterruptDisabled(true, false)).toBe(true);
     expect(isInterruptDisabled(false, true)).toBe(true);
     expect(isInterruptDisabled(false, false)).toBe(false);
+  });
 
-    const html = renderToStaticMarkup(
-      createElement(SteerWaitingStatus, { waitingForSteer: true }),
+  test("names the durable waiting state in the dock header", () => {
+    expect(steerStatusLabel(true)).toBe("Interrupted — waiting for steering");
+    expect(steerStatusLabel(false)).toBe("Steering");
+  });
+
+  test("reopens the dock while the run waits for steering", () => {
+    expect(isSteerDockCollapsed(true, false)).toBe(true);
+    expect(isSteerDockCollapsed(false, false)).toBe(false);
+    // Collapsing cannot hide a run that is blocked on the operator.
+    expect(isSteerDockCollapsed(true, true)).toBe(false);
+    expect(isSteerDockCollapsed(false, true)).toBe(false);
+  });
+
+  test("the focus handle expands a collapsed dock before focusing", async () => {
+    const focus = mock(() => undefined);
+    const ref = createRef<SteerBarHandle>();
+    let renderer!: TestRenderer.ReactTestRenderer;
+    await act(async () => {
+      renderer = TestRenderer.create(
+        <SteerBar ref={ref} runId="run-1" />,
+        {
+          createNodeMock: (element) =>
+            element.type === "textarea" ? { focus } : null,
+        },
+      );
+    });
+    mountedRenderers.push(renderer);
+
+    act(() => {
+      renderer.root
+        .findByProps({ "aria-label": "Collapse Steer running agent" })
+        .props.onClick();
+    });
+    expect(
+      renderer.root.findByProps({
+        "aria-label": "Expand Steer running agent",
+      }),
+    ).toBeDefined();
+
+    act(() => ref.current?.focus());
+    expect(
+      renderer.root.findByProps({
+        "aria-label": "Collapse Steer running agent",
+      }),
+    ).toBeDefined();
+    expect(focus).not.toHaveBeenCalled();
+
+    await act(
+      async () =>
+        await new Promise((resolve) => {
+          setTimeout(resolve, 0);
+        }),
     );
-    expect(html).toContain('role="status"');
-    expect(html).toContain("Interrupted — waiting for steering");
+    expect(focus).toHaveBeenCalledTimes(1);
+  });
+
+  test("interrupt progress disables the composer without calling it sending", async () => {
+    interruptPending = true;
+    let renderer!: TestRenderer.ReactTestRenderer;
+    await act(async () => {
+      renderer = TestRenderer.create(<SteerBar runId="run-1" />);
+    });
+    mountedRenderers.push(renderer);
+
+    const submit = renderer.root.findByProps({ type: "submit" });
+    expect(submit.props.disabled).toBe(true);
+    expect(textFromNode(submit)).toBe("Send");
+    expect(
+      renderer.root
+        .findAllByType("button")
+        .map(textFromNode),
+    ).toContain("Interrupting…");
   });
 });

apps/fabro-web/app/components/steer-bar.tsx

@@ -2,15 +2,22 @@ import {
   useImperativeHandle,
   useRef,
   useState,
-  type FormEvent,
-  type KeyboardEvent,
   type Ref,
 } from "react";
+import { StopIcon } from "@heroicons/react/20/solid";
 
 import { ApiError } from "../lib/api-client";
+import { classNames } from "../lib/class-names";
 import { useInterruptRun, useSteerRun } from "../lib/mutations";
+import {
+  DockComposer,
+  RunDockShell,
+  DOCK_HEADER_BUTTON,
+} from "./run-dock";
 import { ErrorMessage } from "./ui";
 
+const STEER_MAX_LENGTH = 8192;
+
 export interface SteerBarProps {
   runId: string;
   waitingForSteer?: boolean;
@@ -28,17 +35,20 @@ export function isInterruptDisabled(
   return waitingForSteer || mutationPending;
 }
 
-export function SteerWaitingStatus({
-  waitingForSteer,
-}: {
-  waitingForSteer: boolean;
-}) {
-  if (!waitingForSteer) return null;
-  return (
-    <p role="status" className="mt-2 text-xs text-amber">
-      Interrupted — waiting for steering
-    </p>
-  );
+/**
+ * A run that is waiting for steering needs the operator, so the dock reopens
+ * itself and stays open until the wait clears. Derived rather than stored, so
+ * collapsing during the wait cannot hide the prompt.
+ */
+export function isSteerDockCollapsed(
+  collapsePreferred: boolean,
+  waitingForSteer: boolean,
+): boolean {
+  return collapsePreferred && !waitingForSteer;
+}
+
+export function steerStatusLabel(waitingForSteer: boolean): string {
+  return waitingForSteer ? "Interrupted — waiting for steering" : "Steering";
 }
 
 export function SteerBar({
@@ -46,31 +56,38 @@ export function SteerBar({
   waitingForSteer = false,
   ref,
 }: SteerBarProps) {
-  const [text, setText] = useState("");
   const [errorMessage, setErrorMessage] = useState<string | null>(null);
+  const [collapsePreferred, setCollapsePreferred] = useState(false);
   const textareaRef = useRef<HTMLTextAreaElement | null>(null);
   const steer = useSteerRun(runId);
   const interrupt = useInterruptRun(runId);
   const pending = steer.isMutating || interrupt.isMutating;
   const interruptDisabled = isInterruptDisabled(waitingForSteer, pending);
+  const collapsed = isSteerDockCollapsed(collapsePreferred, waitingForSteer);
 
-  useImperativeHandle(ref, () => ({
-    focus() {
-      textareaRef.current?.focus();
-    },
-  }));
+  useImperativeHandle(
+    ref,
+    () => ({
+      focus() {
+        if (!collapsed) {
+          textareaRef.current?.focus();
+          return;
+        }
+        setCollapsePreferred(false);
+        setTimeout(() => textareaRef.current?.focus(), 0);
+      },
+    }),
+    [collapsed],
+  );
 
-  const trimmed = text.trim();
-  const canSend = trimmed.length > 0 && !pending;
-
-  async function sendSteering() {
-    if (!canSend) return;
+  async function sendSteering(text: string) {
     setErrorMessage(null);
     try {
-      await steer.trigger({ text: trimmed, interrupt: false });
-      setText("");
+      await steer.trigger({ text, interrupt: false });
+      return true;
     } catch (err) {
       setErrorMessage(formatSteerError(err));
+      return false;
     }
   }
 
@@ -84,59 +101,47 @@ export function SteerBar({
     }
   }
 
-  function handleSubmit(e: FormEvent) {
-    e.preventDefault();
-    void sendSteering();
-  }
-
-  function handleKeyDown(e: KeyboardEvent<HTMLTextAreaElement>) {
-    if (e.key === "Enter" && !e.shiftKey) {
-      e.preventDefault();
-      void sendSteering();
-    }
-  }
-
   return (
-    <form
-      onSubmit={handleSubmit}
-      aria-label="Steer running agent"
-      className="mx-auto max-w-4xl px-4 py-3 sm:px-6 lg:px-8"
-    >
-      <div className="flex items-end gap-2">
-        <textarea
-          ref={textareaRef}
-          value={text}
-          onChange={(e) => setText(e.target.value)}
-          onKeyDown={handleKeyDown}
-          placeholder="Steer the agent…"
-          rows={1}
-          maxLength={8192}
-          aria-label="Steering message"
-          className="flex-1 resize-none rounded-md bg-overlay px-3 py-2 text-sm text-fg outline-1 -outline-offset-1 outline-line-strong placeholder:text-fg-muted focus:outline-2 focus:-outline-offset-1 focus:outline-teal-500"
-        />
+    <RunDockShell
+      label="Steer running agent"
+      tone={waitingForSteer ? "alert" : "idle"}
+      status={steerStatusLabel(waitingForSteer)}
+      peek="Send a message to the running agent"
+      collapsed={collapsed}
+      onCollapsedChange={setCollapsePreferred}
+      headerActions={
+        // Interrupt acts on the run, not on the message being composed, so it
+        // sits with the other run-level controls instead of in the composer.
         <button
           type="button"
           onClick={() => void fireInterrupt()}
           disabled={interruptDisabled}
-          className="inline-flex shrink-0 items-center gap-2 rounded-md bg-overlay px-3 py-2 text-sm font-medium text-amber outline-1 -outline-offset-1 outline-amber/40 transition-colors hover:bg-amber/15 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-amber disabled:cursor-not-allowed disabled:opacity-60"
+          className={classNames(
+            DOCK_HEADER_BUTTON,
+            "text-amber outline-amber/40 hover:bg-amber/15 hover:text-amber focus-visible:outline-amber disabled:hover:bg-overlay disabled:hover:text-amber",
+          )}
         >
+          <StopIcon className="size-3" aria-hidden="true" />
           {interrupt.isMutating ? "Interrupting…" : "Interrupt"}
         </button>
-        <button
-          type="submit"
-          disabled={!canSend}
-          className="inline-flex shrink-0 items-center justify-center rounded-md bg-teal-500 px-4 py-2 text-sm font-medium text-on-primary transition-colors hover:bg-teal-300 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-teal-500 disabled:cursor-not-allowed disabled:opacity-60 disabled:hover:bg-teal-500"
-        >
-          {steer.isMutating ? "Sending…" : "Send"}
-        </button>
-      </div>
-      {errorMessage && (
-        <div className="mt-2">
-          <ErrorMessage message={errorMessage} />
-        </div>
-      )}
-      <SteerWaitingStatus waitingForSteer={waitingForSteer} />
-    </form>
+      }
+      actions={
+        <>
+          <DockComposer
+            onSubmit={sendSteering}
+            placeholder="Steer the agent…"
+            submitLabel="Send"
+            pendingLabel="Sending…"
+            submitting={steer.isMutating}
+            disabled={pending}
+            ariaLabel="Steering message"
+            maxLength={STEER_MAX_LENGTH}
+            textareaRef={textareaRef}
+          />
+          {errorMessage && <ErrorMessage message={errorMessage} />}
+        </>
+      }
+    />
   );
 }
 

apps/fabro-web/app/data/runs.test.ts

@@ -103,6 +103,17 @@ describe("mapRunListItem", () => {
 
     expect(mapRunListItem(summary).title).toBe("Untitled run");
   });
+
+  test("carries the billed total so the size chip can show it on hover", () => {
+    expect(mapRunListItem(makeRun()).totalUsdMicros).toBe(500000);
+  });
+
+  test("leaves the billed total undefined for runs without terminal billing", () => {
+    expect(mapRunListItem(makeRun({ billing: null })).totalUsdMicros).toBeUndefined();
+    expect(
+      mapRunListItem(makeRun({ billing: { total_usd_micros: null } })).totalUsdMicros,
+    ).toBeUndefined();
+  });
 });
 
 describe("mapRunToRunItem", () => {

apps/fabro-web/app/data/runs.ts

@@ -46,6 +46,7 @@ export interface RunItem {
   createdBy: Principal;
   lastEventAt?: string;
   size?: RunSize;
+  totalUsdMicros?: number;
 }
 
 export const columnStatuses = [
@@ -119,6 +120,7 @@ export function mapRunListItem(item: Run): RunItem {
     additions: item.diff?.additions,
     deletions: item.diff?.deletions,
     size: item.size,
+    totalUsdMicros: item.billing?.total_usd_micros ?? undefined,
   };
 }
 

apps/fabro-web/app/lib/billing.ts

@@ -0,0 +1,28 @@
+import type { BilledTokenCounts } from "@qltysh/fabro-api-client";
+
+export interface BillingTokenBucket {
+  label: string;
+  value: number;
+}
+
+export function billableOutputTokens(billing: BilledTokenCounts): number {
+  return billing.output_tokens + billing.reasoning_tokens;
+}
+
+/** The disjoint token buckets shown in every billing breakdown. */
+export function billingTokenBuckets(billing: BilledTokenCounts): BillingTokenBucket[] {
+  return [
+    { label: "Cache read", value: billing.cache_read_tokens },
+    { label: "Cache creation", value: billing.cache_write_tokens },
+    { label: "Uncached", value: billing.input_tokens },
+    { label: "Output", value: billableOutputTokens(billing) },
+  ];
+}
+
+export function hasBillingUsage(billing: BilledTokenCounts): boolean {
+  return (
+    billing.total_tokens !== 0 ||
+    (billing.total_usd_micros ?? 0) !== 0 ||
+    billingTokenBuckets(billing).some((bucket) => bucket.value !== 0)
+  );
+}

apps/fabro-web/app/lib/class-names.ts

@@ -0,0 +1,5 @@
+export function classNames(
+  ...classes: Array<string | false | null | undefined>
+): string {
+  return classes.filter(Boolean).join(" ");
+}

apps/fabro-web/app/lib/queries.ts

@@ -1,3 +1,4 @@
+import { useCallback } from "react";
 import useSWR, { type SWRConfiguration } from "swr";
 import type {
   ApiQuestion,
@@ -73,6 +74,7 @@ import {
   type RunFileSelection,
   type RunGraphDirection,
 } from "./query-keys";
+import { isTerminalRunStatus } from "./run-actions";
 
 const immutableOptions: SWRConfiguration = {
   revalidateIfStale: false,
@@ -179,10 +181,21 @@ export function useRunsPage(opts: RunsPageOptions = {}, enabled = true) {
   );
 }
 
-export function useRun(id: string | undefined) {
+export function useRun(id: string | undefined, refreshInterval?: number) {
+  const pollingInterval = useCallback(
+    (run: Run | null | undefined) =>
+      refreshInterval &&
+      run?.timestamps.started_at &&
+      !isTerminalRunStatus(run.lifecycle.status.kind)
+        ? refreshInterval
+        : 0,
+    [refreshInterval],
+  );
+
   return useSWR<Run | null>(
     id ? queryKeys.runs.detail(id) : null,
     () => apiNullableData(() => runsApi.retrieveRun(id!)),
+    refreshInterval ? { refreshInterval: pollingInterval } : undefined,
   );
 }
 

apps/fabro-web/app/lib/query-keys.test.ts

@@ -1,7 +1,6 @@
 import { describe, expect, test } from "bun:test";
 
 import { queryKeys } from "./query-keys";
-import { queryKeysForRunEvent } from "./run-events";
 
 describe("queryKeys", () => {
   test("uses semantic tuples as stable SWR keys and keeps SSE URLs explicit", () => {
@@ -61,52 +60,4 @@ describe("queryKeys", () => {
     expect(queryKeys.runs.attachUrl("run 1")).toBe("/api/v1/runs/run%201/attach");
   });
 
-  test("event-mapped keys match query hook resources", () => {
-    expect(queryKeysForRunEvent("run-1", "checkpoint.completed")).toEqual(
-      [
-        ...queryKeys.runs.filesAllScopes("run-1"),
-        queryKeys.runs.commits("run-1"),
-      ],
-    );
-    expect(queryKeysForRunEvent("run-1", "stage.completed", "stage-1")).toEqual([
-      queryKeys.runs.stages("run-1"),
-      queryKeys.runs.billing("run-1"),
-      queryKeys.runs.events("run-1", 1000),
-      queryKeys.runs.graph("run-1", "LR"),
-      queryKeys.runs.graph("run-1", "TB"),
-      queryKeys.runs.detail("run-1"),
-      queryKeys.runs.state("run-1"),
-      queryKeys.runs.stageEvents("run-1", "stage-1"),
-      queryKeys.runs.stageContextWindow("run-1", "stage-1"),
-    ]);
-    expect(queryKeysForRunEvent("run-1", "run.title.updated")).toEqual([
-      queryKeys.runs.detail("run-1"),
-    ]);
-  });
-
-  test("agent activity events invalidate per-stage resources", () => {
-    for (const event of [
-      "stage.prompt",
-      "agent.tool.started",
-      "agent.tool.completed",
-      "command.started",
-      "command.completed",
-    ]) {
-      expect(queryKeysForRunEvent("run-1", event, "stage-1")).toEqual([
-        queryKeys.runs.stageEvents("run-1", "stage-1"),
-        queryKeys.runs.stageContextWindow("run-1", "stage-1"),
-      ]);
-    }
-    expect(queryKeysForRunEvent("run-1", "agent.message", "stage-1")).toEqual([
-      queryKeys.runs.state("run-1"),
-      queryKeys.runs.stageEvents("run-1", "stage-1"),
-      queryKeys.runs.stageContextWindow("run-1", "stage-1"),
-    ]);
-  });
-
-  test("agent message without a node_id still invalidates projected state", () => {
-    expect(queryKeysForRunEvent("run-1", "agent.message")).toEqual([
-      queryKeys.runs.state("run-1"),
-    ]);
-  });
 });

apps/fabro-web/app/lib/run-actions.ts

@@ -111,10 +111,7 @@ export async function deleteRuns(
   request?: Request,
 ): Promise<BatchDeleteRunsResponse> {
   try {
-    // See `batchRunLifecycleAction` for the `as unknown as` rationale:
-    // openapi-generator types `uniqueItems` arrays as `Set<T>` while the wire
-    // contract is a JSON array.
-    const body = { run_ids: runIds, force } as unknown as BatchDeleteRunsRequest;
+    const body: BatchDeleteRunsRequest = { run_ids: runIds, force };
     return await apiData(() => runsApi.batchDeleteRuns(body, requestSignalOptions(request)));
   } catch (error) {
     throw lifecycleActionErrorFromError(error);
@@ -284,10 +281,7 @@ async function batchRunLifecycleAction(
   request?: Request,
 ): Promise<BatchRunLifecycleResponse> {
   try {
-    // openapi-generator's TypeScript client represents `uniqueItems` arrays as
-    // Set<T>, but the HTTP wire contract is still a JSON array. Keep an array
-    // here so Axios serializes the request body correctly.
-    const body = { run_ids: runIds } as unknown as BatchRunLifecycleRequest;
+    const body: BatchRunLifecycleRequest = { run_ids: runIds };
     switch (action) {
       case "archive":
         return await apiData(() => runsApi.batchArchiveRuns(body, requestSignalOptions(request)));

apps/fabro-web/app/lib/run-events.test.tsx

@@ -85,6 +85,8 @@ describe("queryKeysForRunEvent", () => {
 
   test("interrupt settlement invalidates projected control state and stage activity", () => {
     expect(queryKeysForRunEvent("run-1", "agent.round.interrupted", "nap@1")).toEqual([
+      queryKeys.runs.detail("run-1"),
+      queryKeys.runs.billing("run-1"),
       queryKeys.runs.state("run-1"),
       queryKeys.runs.events("run-1", 1000),
       queryKeys.runs.stageEvents("run-1", "nap@1"),
@@ -92,6 +94,36 @@ describe("queryKeysForRunEvent", () => {
     ]);
   });
 
+  test("parallel branch lifecycle invalidates the stages list backing live branch rows", () => {
+    // Branches bypass stage.started/stage.completed, so these events are the
+    // only signal that a branch row's status changed.
+    expect(queryKeysForRunEvent("run-1", "parallel.branch.started", "review_glm@1")).toEqual([
+      queryKeys.runs.stages("run-1"),
+      queryKeys.runs.events("run-1", 1000),
+      queryKeys.runs.graph("run-1", "LR"),
+      queryKeys.runs.graph("run-1", "TB"),
+      queryKeys.runs.stageEvents("run-1", "review_glm@1"),
+    ]);
+    expect(queryKeysForRunEvent("run-1", "parallel.branch.completed", "review_glm@1")).toEqual([
+      queryKeys.runs.stages("run-1"),
+      queryKeys.runs.events("run-1", 1000),
+      queryKeys.runs.graph("run-1", "LR"),
+      queryKeys.runs.graph("run-1", "TB"),
+      queryKeys.runs.stageEvents("run-1", "review_glm@1"),
+    ]);
+  });
+
+  test("fork lifecycle invalidates run-scoped resources without a stage id", () => {
+    for (const event of ["parallel.started", "parallel.completed"]) {
+      expect(queryKeysForRunEvent("run-1", event)).toEqual([
+        queryKeys.runs.stages("run-1"),
+        queryKeys.runs.events("run-1", 1000),
+        queryKeys.runs.graph("run-1", "LR"),
+        queryKeys.runs.graph("run-1", "TB"),
+      ]);
+    }
+  });
+
   test("cancel requests invalidate the durable run summary", () => {
     expect(queryKeysForRunEvent("run-1", "run.cancel.requested")).toEqual([
       queryKeys.runs.detail("run-1"),
@@ -129,10 +161,16 @@ describe("queryKeysForRunEvent", () => {
   test("every inference projection transition invalidates live run state", () => {
     for (const event of [
       "agent.llm.started",
-      "agent.llm.first_output",
-      "agent.llm.retry",
       "agent.error",
     ]) {
+      expect(queryKeysForRunEvent("run-1", event, "code@1")).toEqual([
+        queryKeys.runs.detail("run-1"),
+        queryKeys.runs.state("run-1"),
+        queryKeys.runs.billing("run-1"),
+        queryKeys.runs.stageEvents("run-1", "code@1"),
+      ]);
+    }
+    for (const event of ["agent.llm.first_output", "agent.llm.retry"]) {
       expect(queryKeysForRunEvent("run-1", event, "code@1")).toEqual([
         queryKeys.runs.state("run-1"),
         queryKeys.runs.stageEvents("run-1", "code@1"),
@@ -141,15 +179,47 @@ describe("queryKeysForRunEvent", () => {
     expect(
       queryKeysForRunEvent("run-1", "agent.message", "code@1"),
     ).toEqual([
+      queryKeys.runs.detail("run-1"),
       queryKeys.runs.state("run-1"),
+      queryKeys.runs.billing("run-1"),
       queryKeys.runs.stageEvents("run-1", "code@1"),
       queryKeys.runs.stageContextWindow("run-1", "code@1"),
     ]);
     expect(queryKeysForRunEvent("run-1", "agent.session.ended")).toEqual([
+      queryKeys.runs.detail("run-1"),
       queryKeys.runs.state("run-1"),
+      queryKeys.runs.billing("run-1"),
     ]);
   });
 
+  test("ACP timing events invalidate live summaries and stage events", () => {
+    for (const event of [
+      "agent.acp.started",
+      "agent.acp.completed",
+      "agent.acp.cancelled",
+      "agent.acp.timed_out",
+    ]) {
+      expect(queryKeysForRunEvent("run-1", event, "code@1")).toEqual([
+        queryKeys.runs.detail("run-1"),
+        queryKeys.runs.state("run-1"),
+        queryKeys.runs.billing("run-1"),
+        queryKeys.runs.stageEvents("run-1", "code@1"),
+      ]);
+    }
+  });
+
+  test("tool timing events invalidate live summaries and stage resources", () => {
+    for (const event of ["agent.tool.started", "agent.tool.completed"]) {
+      expect(queryKeysForRunEvent("run-1", event, "code@1")).toEqual([
+        queryKeys.runs.detail("run-1"),
+        queryKeys.runs.state("run-1"),
+        queryKeys.runs.billing("run-1"),
+        queryKeys.runs.stageEvents("run-1", "code@1"),
+        queryKeys.runs.stageContextWindow("run-1", "code@1"),
+      ]);
+    }
+  });
+
   test("watchdog timeout refreshes the stage events for that stage", () => {
     expect(
       queryKeysForRunEvent("run-1", "watchdog.timeout", "code@1"),

apps/fabro-web/app/lib/run-events.ts

@@ -88,6 +88,17 @@ export const STAGE_ACTIVITY_EVENT_TYPES = [
 ] as const;
 export type StageActivityEventType = (typeof STAGE_ACTIVITY_EVENT_TYPES)[number];
 const STAGE_ACTIVITY_EVENTS = new Set<string>(STAGE_ACTIVITY_EVENT_TYPES);
+// Parallel branches bypass the engine's `stage.started` / `stage.completed`
+// lifecycle (the parallel handler dispatches each branch directly), so
+// `STAGE_EVENTS` never fires for them. Without this set the stages list never
+// refetches while a fork runs and branch rows stay frozen at their first
+// observed state.
+const PARALLEL_EVENTS = new Set([
+  "parallel.started",
+  "parallel.branch.started",
+  "parallel.branch.completed",
+  "parallel.completed",
+]);
 const INTERVIEW_EVENTS = new Set([
   "interview.started",
   "interview.completed",
@@ -118,6 +129,22 @@ const INFERENCE_EVENTS = new Set([
   "agent.error",
   "agent.session.ended",
 ]);
+const INFERENCE_TIMING_EVENTS = new Set([
+  "agent.llm.started",
+  "agent.message",
+  "agent.error",
+  "agent.session.ended",
+]);
+const TOOL_TIMING_EVENTS = new Set([
+  "agent.tool.started",
+  "agent.tool.completed",
+]);
+const ACP_TIMING_EVENTS = new Set([
+  "agent.acp.started",
+  "agent.acp.completed",
+  "agent.acp.cancelled",
+  "agent.acp.timed_out",
+]);
 // Todo / task mutation events refresh `getRunState` consumers (so per-stage
 // todo projections update live) and the run events list.
 const TODO_EVENTS = new Set([
@@ -126,6 +153,14 @@ const TODO_EVENTS = new Set([
   "todo.deleted",
 ]);
 
+function liveTimingKeys(runId: string): Key[] {
+  return [
+    queryKeys.runs.detail(runId),
+    queryKeys.runs.state(runId),
+    queryKeys.runs.billing(runId),
+  ];
+}
+
 export function queryKeysForRunEvent(
   runId: string,
   event: string,
@@ -179,11 +214,30 @@ export function queryKeysForRunEvent(
     return keys;
   }
 
+  if (PARALLEL_EVENTS.has(event)) {
+    const keys: Key[] = [
+      queryKeys.runs.stages(runId),
+      queryKeys.runs.events(runId, 1000),
+      queryKeys.runs.graph(runId, "LR"),
+      queryKeys.runs.graph(runId, "TB"),
+    ];
+    if (stageId) {
+      keys.push(queryKeys.runs.stageEvents(runId, stageId));
+    }
+    return keys;
+  }
+
   if (STEERING_EVENTS.has(event)) {
     const keys: Key[] = [queryKeys.runs.events(runId, 1000)];
     if (AGENT_CONTROL_STATE_EVENTS.has(event)) {
       keys.unshift(queryKeys.runs.state(runId));
     }
+    if (event === "agent.round.interrupted") {
+      keys.unshift(
+        queryKeys.runs.detail(runId),
+        queryKeys.runs.billing(runId),
+      );
+    }
     if (stageId) {
       keys.push(queryKeys.runs.stageEvents(runId, stageId));
       keys.push(queryKeys.runs.stageContextWindow(runId, stageId));
@@ -192,7 +246,9 @@ export function queryKeysForRunEvent(
   }
 
   if (INFERENCE_EVENTS.has(event)) {
-    const keys: Key[] = [queryKeys.runs.state(runId)];
+    const keys = INFERENCE_TIMING_EVENTS.has(event)
+      ? liveTimingKeys(runId)
+      : [queryKeys.runs.state(runId)];
     if (stageId) {
       keys.push(queryKeys.runs.stageEvents(runId, stageId));
       if (event === "agent.message") {
@@ -202,6 +258,23 @@ export function queryKeysForRunEvent(
     return keys;
   }
 
+  if (TOOL_TIMING_EVENTS.has(event)) {
+    const keys = liveTimingKeys(runId);
+    if (stageId) {
+      keys.push(queryKeys.runs.stageEvents(runId, stageId));
+      keys.push(queryKeys.runs.stageContextWindow(runId, stageId));
+    }
+    return keys;
+  }
+
+  if (ACP_TIMING_EVENTS.has(event)) {
+    const keys = liveTimingKeys(runId);
+    if (stageId) {
+      keys.push(queryKeys.runs.stageEvents(runId, stageId));
+    }
+    return keys;
+  }
+
   if (event === "watchdog.timeout") {
     return stageId ? [queryKeys.runs.stageEvents(runId, stageId)] : [];
   }

apps/fabro-web/app/lib/stage-sidebar.test.ts

@@ -3,21 +3,11 @@ import type { PaginatedRunStageList, StageHandler, StageState } from "@qltysh/fa
 
 import type { Stage } from "../components/stage-sidebar";
 import { aggregateGraphNodeStatus, formatStageLabel, mapRunStagesToSidebarStages } from "./stage-sidebar";
+import { makeBilledTokenCounts } from "./test-fixtures";
+import { makeStage as baseMakeStage } from "./test-utils";
 
 function makeStage(nodeId: string, visit: number, status: StageState): Stage {
-  return {
-    id: `${nodeId}@${visit}`,
-    name: nodeId,
-    handler: "agent",
-    nodeId,
-    visit,
-    graphVisit: null,
-    resumedFromStageId: null,
-    status,
-    duration: "--",
-    startedAt: null,
-    providerUsed: null,
-  };
+  return baseMakeStage({ id: `${nodeId}@${visit}`, name: nodeId, nodeId, visit, status });
 }
 
 describe("mapRunStagesToSidebarStages", () => {
@@ -38,6 +28,15 @@ describe("mapRunStagesToSidebarStages", () => {
             model: "gpt-5.5",
             reasoning_effort: "high",
           },
+          billing: makeBilledTokenCounts({
+            input_tokens: 28_640,
+            output_tokens: 7_550,
+            total_tokens: 43_690,
+            reasoning_tokens: 1_200,
+            cache_read_tokens: 4_800,
+            cache_write_tokens: 1_500,
+            total_usd_micros: 720_000,
+          }),
         },
         {
           id: "apply-changes@2",
@@ -46,6 +45,7 @@ describe("mapRunStagesToSidebarStages", () => {
           status: "running",
           node_id: "apply",
           visit: 2,
+          billing: makeBilledTokenCounts(),
         },
       ],
       meta: { has_more: false },
@@ -64,6 +64,10 @@ describe("mapRunStagesToSidebarStages", () => {
       model: "gpt-5.5",
       reasoning_effort: "high",
     });
+    // Each visit keeps its own tokens and cost, so the stage popover never
+    // shows a sibling visit's usage.
+    expect(result[0].billing.total_usd_micros).toBe(720_000);
+    expect(result[1].billing.total_usd_micros).toBeUndefined();
     expect(formatStageLabel(result[0])).toBe("Apply Changes");
 
     expect(result[1].id).toBe("apply-changes@2");
@@ -83,6 +87,7 @@ describe("mapRunStagesToSidebarStages", () => {
           status: "succeeded",
           node_id: "start",
           visit: 1,
+          billing: makeBilledTokenCounts(),
         },
         {
           id: "verify@1",
@@ -91,6 +96,7 @@ describe("mapRunStagesToSidebarStages", () => {
           status: "succeeded",
           node_id: "verify",
           visit: 1,
+          billing: makeBilledTokenCounts(),
         },
         {
           id: "exit@1",
@@ -99,6 +105,7 @@ describe("mapRunStagesToSidebarStages", () => {
           status: "succeeded",
           node_id: "exit",
           visit: 1,
+          billing: makeBilledTokenCounts(),
         },
       ],
       meta: { has_more: false },
@@ -118,6 +125,7 @@ describe("mapRunStagesToSidebarStages", () => {
           status: "running",
           node_id: "verify",
           visit: 1,
+          billing: makeBilledTokenCounts(),
         },
       ],
       meta: { has_more: false },
@@ -137,6 +145,7 @@ describe("mapRunStagesToSidebarStages", () => {
           node_id: "work",
           visit: 1,
           graph_visit: 1,
+          billing: makeBilledTokenCounts(),
         },
         {
           id: "work@2",
@@ -147,6 +156,7 @@ describe("mapRunStagesToSidebarStages", () => {
           visit: 2,
           graph_visit: 1,
           resumed_from_stage_id: "work@1",
+          billing: makeBilledTokenCounts(),
         },
       ],
       meta: { has_more: false },
@@ -172,6 +182,7 @@ describe("mapRunStagesToSidebarStages", () => {
           status: "succeeded",
           node_id: "verify",
           visit: 1,
+          billing: makeBilledTokenCounts(),
         },
       ],
       meta: { has_more: false },
@@ -182,6 +193,28 @@ describe("mapRunStagesToSidebarStages", () => {
     expect(result[0].resumedFromStageId).toBeNull();
   });
 
+  test("maps parallel branch identity without parsing it in the client", () => {
+    const stages: PaginatedRunStageList = {
+      data: [
+        {
+          id: "review_opus@2",
+          name: "review_opus",
+          handler: "agent",
+          status: "running",
+          node_id: "review_opus",
+          visit: 2,
+          parallel_group_id: "review_fork@1",
+          parallel_branch_index: 3,
+        },
+      ],
+      meta: { has_more: false },
+    };
+
+    const result = mapRunStagesToSidebarStages(stages);
+    expect(result[0].parallelGroupId).toBe("review_fork@1");
+    expect(result[0].parallelBranchIndex).toBe(3);
+  });
+
   test("preserves the authoritative handler for renderer dispatch", () => {
     const stages: PaginatedRunStageList = {
       data: [
@@ -192,6 +225,7 @@ describe("mapRunStagesToSidebarStages", () => {
           status: "pending",
           node_id: "approval",
           visit: 1,
+          billing: makeBilledTokenCounts(),
         },
       ],
       meta: { has_more: false },

apps/fabro-web/app/lib/stage-sidebar.ts

@@ -1,5 +1,6 @@
 import { StageState } from "@qltysh/fabro-api-client";
 import type {
+  BilledTokenCounts,
   PaginatedRunStageList,
   StageHandler,
   StageModelUsage,
@@ -25,8 +26,17 @@ export interface Stage {
   graphVisit: number | null;
   /** StageId of the prior execution superseded by this resumed replay, if any. */
   resumedFromStageId: string | null;
+  /** Exact StageId of the parent parallel execution, if this is a branch. */
+  parallelGroupId: string | null;
+  /** Zero-based outgoing-edge index within the parent parallel execution. */
+  parallelBranchIndex: number | null;
   startedAt: string | null;
   providerUsed: StageModelUsage | null;
+  /**
+   * Tokens and cost for this visit alone, priced the same way the Billing tab
+   * prices its per-node rows. All-zero counts mean the stage called no model.
+   */
+  billing: BilledTokenCounts;
 }
 
 export const ACTIVE_STAGE_STATES: ReadonlySet<StageState> = new Set([
@@ -96,12 +106,15 @@ export function mapRunStagesToSidebarStages(
       visit: stage.visit,
       graphVisit: stage.graph_visit ?? null,
       resumedFromStageId: stage.resumed_from_stage_id ?? null,
+      parallelGroupId: stage.parallel_group_id ?? null,
+      parallelBranchIndex: stage.parallel_branch_index ?? null,
       status: stage.status,
       duration: stage.wall_time_ms != null
         ? formatDurationMs(stage.wall_time_ms)
         : "--",
       startedAt: stage.started_at ?? null,
       providerUsed: stage.provider_used ?? null,
+      billing: stage.billing,
     });
   }
   return stages;

apps/fabro-web/app/lib/test-fixtures.ts

@@ -1,4 +1,4 @@
-import type { Principal } from "@qltysh/fabro-api-client";
+import type { BilledTokenCounts, Principal } from "@qltysh/fabro-api-client";
 
 export const TEST_PRINCIPAL: Principal = {
   kind:        "user",
@@ -6,3 +6,17 @@ export const TEST_PRINCIPAL: Principal = {
   login:       "test",
   auth_method: "dev_token",
 };
+
+export function makeBilledTokenCounts(
+  overrides: Partial<BilledTokenCounts> = {},
+): BilledTokenCounts {
+  return {
+    cache_read_tokens: 0,
+    cache_write_tokens: 0,
+    input_tokens: 0,
+    output_tokens: 0,
+    reasoning_tokens: 0,
+    total_tokens: 0,
+    ...overrides,
+  };
+}

apps/fabro-web/app/lib/test-utils.tsx

@@ -2,6 +2,9 @@ import { createElement, type ReactNode } from "react";
 import type { EventEnvelope } from "@qltysh/fabro-api-client";
 import TestRenderer, { act } from "react-test-renderer";
 
+import type { Stage } from "./stage-sidebar";
+import { makeBilledTokenCounts } from "./test-fixtures";
+
 const IS_REACT_ACT_ENV = "IS_REACT_ACT_ENVIRONMENT" as const;
 
 /**
@@ -55,6 +58,38 @@ export function makeEventEnvelope(
   } as EventEnvelope;
 }
 
+/** Flatten a rendered subtree to its visible text. */
+export function textContent(node: TestRenderer.ReactTestInstance): string {
+  return node.children
+    .map((child) => (typeof child === "string" ? child : textContent(child)))
+    .join("");
+}
+
+/**
+ * Build a sidebar `Stage` fixture; override any field via `overrides`. Kept
+ * here so widening `Stage` updates every fixture at once — test files are
+ * excluded from typecheck, so a per-file copy silently goes stale instead.
+ */
+export function makeStage(overrides: Partial<Stage> = {}): Stage {
+  return {
+    id: "implement@1",
+    name: "implement",
+    handler: "agent",
+    nodeId: "implement",
+    visit: 1,
+    graphVisit: null,
+    resumedFromStageId: null,
+    parallelGroupId: null,
+    parallelBranchIndex: null,
+    status: "running",
+    duration: "--",
+    startedAt: null,
+    providerUsed: null,
+    billing: makeBilledTokenCounts(),
+    ...overrides,
+  };
+}
+
 export function renderHook<T>(
   hook: () => T,
   options: { wrapper: React.ComponentType<{ children: ReactNode }> },

apps/fabro-web/app/routes/run-artifacts.tsx

@@ -1,14 +1,18 @@
 import { useMemo } from "react";
 import { useParams } from "react-router";
-import { ArrowDownTrayIcon, PaperClipIcon } from "@heroicons/react/24/outline";
+import { Disclosure, DisclosureButton, DisclosurePanel } from "@headlessui/react";
+import { ArrowDownTrayIcon, ChevronRightIcon, PaperClipIcon } from "@heroicons/react/24/outline";
 import type { RunArtifactEntry } from "@qltysh/fabro-api-client";
 
 import { EmptyState, ErrorState, LoadingState } from "../components/state";
 import { StageSidebar } from "../components/stage-sidebar";
 import { stageArtifactDownloadUrl } from "../lib/api-client";
 import { formatBytes } from "../lib/format";
+import { plural } from "../lib/plural";
 import { useRunArtifacts, useRunStages } from "../lib/queries";
-import { formatStageLabel, mapRunStagesToSidebarStages } from "../lib/stage-sidebar";
+import { mapRunStagesToSidebarStages } from "../lib/stage-sidebar";
+import type { ArtifactFile, ArtifactVersion } from "./run-artifacts/group";
+import { groupArtifactsByFile } from "./run-artifacts/group";
 
 export const handle = { wide: true };
 
@@ -25,7 +29,12 @@ export default function RunArtifacts() {
     <div className="flex gap-6">
       <StageSidebar stages={stages} runId={id!} activeLink="artifacts" />
       <div className="min-w-0 flex-1">
-        <RunArtifactsBody runId={id!} artifactsQuery={artifactsQuery} stages={stages} />
+        <RunArtifactsBody
+          runId={id!}
+          artifactsQuery={artifactsQuery}
+          stagesQuery={stagesQuery}
+          stages={stages}
+        />
       </div>
     </div>
   );
@@ -34,86 +43,40 @@ export default function RunArtifacts() {
 function RunArtifactsBody({
   runId,
   artifactsQuery,
+  stagesQuery,
   stages,
 }: {
   runId: string;
   artifactsQuery: ReturnType<typeof useRunArtifacts>;
+  stagesQuery: ReturnType<typeof useRunStages>;
   stages: ReturnType<typeof mapRunStagesToSidebarStages>;
 }) {
-  if (artifactsQuery.error) {
+  const error = artifactsQuery.error ?? stagesQuery.error;
+  if (error) {
     return (
       <ErrorState
         title="Couldn't load artifacts"
-        description={errorMessage(artifactsQuery.error)}
-        onRetry={() => void artifactsQuery.mutate()}
+        description={errorMessage(error)}
+        onRetry={() => {
+          if (artifactsQuery.error) void artifactsQuery.mutate();
+          if (stagesQuery.error) void stagesQuery.mutate();
+        }}
       />
     );
   }
-  if (artifactsQuery.data === undefined) {
+  if (artifactsQuery.data === undefined || stagesQuery.data === undefined) {
     return <LoadingState label="Loading artifacts…" />;
   }
-  const entries = artifactsQuery.data?.data ?? [];
-  if (entries.length === 0) {
-    return (
-      <EmptyState
-        icon={PaperClipIcon}
-        title="No artifacts captured"
-        description="No stage in this run produced any artifacts."
-      />
-    );
-  }
-  return <ArtifactList runId={runId} entries={entries} stages={stages} />;
+  return (
+    <ArtifactFiles
+      runId={runId}
+      entries={artifactsQuery.data?.data ?? []}
+      stages={stages}
+    />
+  );
 }
 
-interface StageGroup {
-  key: string;
-  stageId: string;
-  retry: number;
-  label: string;
-  entries: RunArtifactEntry[];
-  totalBytes: number;
-}
-
-function groupArtifacts(
-  entries: readonly RunArtifactEntry[],
-  stages: ReturnType<typeof mapRunStagesToSidebarStages>,
-): StageGroup[] {
-  const stageLabels = new Map<string, string>();
-  for (const stage of stages) {
-    stageLabels.set(stage.id, formatStageLabel(stage));
-  }
-
-  const groups = new Map<string, StageGroup>();
-  for (const entry of entries) {
-    const key = `${entry.stage_id}#${entry.retry}`;
-    const existing = groups.get(key);
-    if (existing) {
-      existing.entries.push(entry);
-      existing.totalBytes += entry.size;
-    } else {
-      groups.set(key, {
-        key,
-        stageId: entry.stage_id,
-        retry: entry.retry,
-        label: stageLabels.get(entry.stage_id) ?? entry.node_slug,
-        entries: [entry],
-        totalBytes: entry.size,
-      });
-    }
-  }
-
-  for (const group of groups.values()) {
-    group.entries.sort((a, b) => a.relative_path.localeCompare(b.relative_path));
-  }
-  const sortedGroups = Array.from(groups.values());
-  sortedGroups.sort((a, b) => {
-    const labelCmp = a.label.localeCompare(b.label);
-    return labelCmp !== 0 ? labelCmp : a.retry - b.retry;
-  });
-  return sortedGroups;
-}
-
-function ArtifactList({
+function ArtifactFiles({
   runId,
   entries,
   stages,
@@ -122,97 +85,209 @@ function ArtifactList({
   entries: readonly RunArtifactEntry[];
   stages: ReturnType<typeof mapRunStagesToSidebarStages>;
 }) {
-  const groups = useMemo(() => groupArtifacts(entries, stages), [entries, stages]);
-  const totalBytes = useMemo(
-    () => entries.reduce((sum, entry) => sum + entry.size, 0),
-    [entries],
-  );
+  const files = useMemo(() => groupArtifactsByFile(entries, stages), [entries, stages]);
+
+  if (files.length === 0) {
+    return (
+      <EmptyState
+        icon={PaperClipIcon}
+        title="No artifacts captured"
+        description="No stage in this run produced any artifacts."
+      />
+    );
+  }
+  return <ArtifactList runId={runId} files={files} />;
+}
+
+function ArtifactList({ runId, files }: { runId: string; files: readonly ArtifactFile[] }) {
+  const { captures, latestBytes, storedBytes } = useMemo(() => {
+    let captures = 0;
+    let latestBytes = 0;
+    let storedBytes = 0;
+    for (const file of files) {
+      captures += file.versions.length;
+      latestBytes += file.versions[0].size;
+      for (const version of file.versions) storedBytes += version.size;
+    }
+    return { captures, latestBytes, storedBytes };
+  }, [files]);
+
+  // Only mention versions once some file actually has more than one.
+  const versioned = captures > files.length;
 
   return (
     <div className="space-y-4">
-      <div className="flex items-baseline justify-between">
+      <div className="flex flex-wrap items-baseline justify-between gap-4">
         <h2 className="text-sm font-medium text-fg">
-          {entries.length} {entries.length === 1 ? "artifact" : "artifacts"}
+          {files.length} {plural(files.length, "file", "files")}
+          {versioned && (
+            <span className="font-normal text-fg-muted">
+              {" "}
+              · {captures} {plural(captures, "version", "versions")}
+            </span>
+          )}
         </h2>
-        <span className="text-xs tabular-nums text-fg-muted">
-          {formatBytes(totalBytes)} total
+        <span className="text-xs text-fg-muted tabular-nums">
+          {versioned
+            ? `${formatBytes(latestBytes)} latest · ${formatBytes(storedBytes)} stored`
+            : `${formatBytes(latestBytes)} total`}
         </span>
       </div>
 
-      {groups.map((group) => (
-        <StageGroupCard key={group.key} runId={runId} group={group} />
-      ))}
+      <section className="overflow-hidden rounded-md border border-line bg-panel-alt">
+        {files.map((file) => (
+          <ArtifactFileRow key={file.path} runId={runId} file={file} />
+        ))}
+      </section>
     </div>
   );
 }
 
-function StageGroupCard({ runId, group }: { runId: string; group: StageGroup }) {
+function ArtifactFileRow({ runId, file }: { runId: string; file: ArtifactFile }) {
+  const hasEarlier = file.versions.length > 1;
+  const latest = file.versions[0];
+
   return (
-    <section className="overflow-hidden rounded-md border border-line bg-panel-alt">
-      <header className="flex items-baseline justify-between border-b border-line px-4 py-2.5">
-        <div className="flex items-baseline gap-2">
-          <h3 className="text-sm font-medium text-fg">{group.label}</h3>
-          {group.retry > 0 && (
-            <span className="rounded bg-overlay px-1.5 py-0.5 text-[11px] font-medium text-fg-3">
-              retry {group.retry}
+    <Disclosure as="div" className="border-t border-line first:border-t-0">
+      {({ open }) => (
+        <>
+          <div className="flex items-center gap-2 px-3 py-2.5 sm:gap-4 sm:px-4">
+            {hasEarlier ? (
+              <DisclosureButton className="group shrink-0 rounded-md p-1 text-fg-3 transition-colors hover:bg-overlay hover:text-fg-2 focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500">
+                <span className="sr-only">
+                  {open ? "Hide" : "Show"} earlier versions of {file.name}
+                </span>
+                <ChevronRightIcon
+                  className="size-3.5 transition-transform group-data-open:rotate-90"
+                  aria-hidden="true"
+                />
+              </DisclosureButton>
+            ) : (
+              <span className="size-5 shrink-0" aria-hidden="true" />
+            )}
+
+            <span className="min-w-0 flex-1" title={file.path}>
+              <span className="block truncate font-mono text-xs">
+                <span className="text-fg-muted">{file.dir}</span>
+                <span className="text-fg-2">{file.name}</span>
+              </span>
+              <span className="mt-0.5 block truncate text-[11px] text-fg-3 md:hidden">
+                <VersionLabel version={latest} />
+              </span>
             </span>
+
+            {hasEarlier && (
+              <span className="hidden shrink-0 rounded-full bg-overlay-strong px-2 py-0.5 text-[11px] text-fg-3 lg:inline">
+                {file.versions.length}{" "}
+                {plural(file.versions.length, "version", "versions")}
+              </span>
+            )}
+
+            <span className="hidden max-w-48 shrink-0 truncate text-xs text-fg-3 md:inline">
+              <VersionLabel version={latest} />
+            </span>
+            <span className="shrink-0 text-xs text-fg-muted tabular-nums">
+              {formatBytes(latest.size)}
+            </span>
+            <DownloadLink runId={runId} file={file} version={latest} />
+          </div>
+
+          {hasEarlier && (
+            <DisclosurePanel
+              as="ul"
+              className="border-t border-line bg-black/15 py-1"
+            >
+              <EarlierVersions runId={runId} file={file} />
+            </DisclosurePanel>
           )}
-        </div>
-        <span className="text-xs tabular-nums text-fg-muted">
-          {group.entries.length} {group.entries.length === 1 ? "file" : "files"}
-          {" · "}
-          {formatBytes(group.totalBytes)}
-        </span>
-      </header>
-      <ul className="divide-y divide-line">
-        {group.entries.map((entry) => (
-          <ArtifactRow
-            key={`${group.key}#${entry.relative_path}`}
-            runId={runId}
-            entry={entry}
-          />
-        ))}
-      </ul>
-    </section>
+        </>
+      )}
+    </Disclosure>
   );
 }
 
-function ArtifactRow({ runId, entry }: { runId: string; entry: RunArtifactEntry }) {
+function EarlierVersions({ runId, file }: { runId: string; file: ArtifactFile }) {
+  return (
+    <>
+      {file.versions.map((version, index) =>
+        index === 0 ? null : (
+          <li
+            key={`${version.stageId}#${version.retry}`}
+            className="flex items-center gap-2 py-1.5 pr-3 pl-10 hover:bg-overlay sm:gap-4 sm:pr-4 sm:pl-14"
+          >
+            <span className="min-w-0 flex-1 truncate text-xs text-fg-3">
+              <VersionLabel version={version} />
+            </span>
+            <span className="shrink-0 text-xs text-fg-muted tabular-nums">
+              {formatBytes(version.size)}
+            </span>
+            <SizeDelta delta={version.delta} />
+            <DownloadLink runId={runId} file={file} version={version} />
+          </li>
+        ),
+      )}
+    </>
+  );
+}
+
+function VersionLabel({ version }: { version: ArtifactVersion }) {
+  const attempt = attemptLabel(version);
+  return (
+    <>
+      {version.stageLabel}
+      {attempt && <span className="ml-2 text-fg-muted">{attempt}</span>}
+    </>
+  );
+}
+
+function attemptLabel(version: ArtifactVersion): string | null {
+  return version.retry > 1 ? `attempt ${version.retry}` : null;
+}
+
+function SizeDelta({ delta }: { delta: number | null }) {
+  if (delta === null) {
+    return <span className="shrink-0 text-[11px] text-fg-muted tabular-nums">first</span>;
+  }
+  const tone = delta < 0 ? "text-amber" : "text-mint";
+  const sign = delta < 0 ? "−" : "+";
+  return (
+    <span className={`shrink-0 text-[11px] ${tone} tabular-nums`}>
+      {sign}
+      {formatBytes(Math.abs(delta))}
+    </span>
+  );
+}
+
+function DownloadLink({
+  runId,
+  file,
+  version,
+}: {
+  runId: string;
+  file: ArtifactFile;
+  version: ArtifactVersion;
+}) {
   const href = stageArtifactDownloadUrl(
     runId,
-    entry.stage_id,
-    entry.relative_path,
-    entry.retry,
+    version.stageId,
+    file.path,
+    version.retry,
   );
-
+  const attempt = attemptLabel(version);
+  const source = attempt ? `${version.stageLabel}, ${attempt}` : version.stageLabel;
   return (
-    <li className="flex items-center gap-4 px-4 py-2">
-      <span
-        className="flex-1 truncate font-mono text-xs text-fg-2"
-        title={entry.relative_path}
-      >
-        {entry.relative_path}
-      </span>
-      <span className="shrink-0 tabular-nums text-xs text-fg-muted">
-        {formatBytes(entry.size)}
-      </span>
-      <a
-        href={href}
-        download={basename(entry.relative_path)}
-        className="inline-flex shrink-0 items-center gap-1 rounded-md px-2 py-1 text-xs text-fg-3 transition-colors hover:bg-overlay hover:text-fg focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500"
-      >
-        <ArrowDownTrayIcon className="size-3.5" aria-hidden="true" />
-        Download
-      </a>
-    </li>
+    <a
+      href={href}
+      download={file.name}
+      aria-label={`Download ${file.name} from ${source}`}
+      className="inline-flex shrink-0 items-center gap-1 rounded-md px-2 py-1 text-xs text-fg-3 transition-colors hover:bg-overlay hover:text-fg focus-visible:outline-2 focus-visible:-outline-offset-1 focus-visible:outline-teal-500"
+    >
+      <ArrowDownTrayIcon className="size-3.5" aria-hidden="true" />
+      <span className="hidden sm:inline">Download</span>
+    </a>
   );
 }
 
-function basename(path: string): string {
-  const idx = path.lastIndexOf("/");
-  return idx >= 0 ? path.slice(idx + 1) : path;
-}
-
 function errorMessage(error: unknown): string | undefined {
   return error instanceof Error ? error.message : undefined;
 }

apps/fabro-web/app/routes/run-artifacts/group.test.ts

@@ -0,0 +1,192 @@
+import { describe, expect, test } from "bun:test";
+import { StageHandler, StageState } from "@qltysh/fabro-api-client";
+import type { RunArtifactEntry } from "@qltysh/fabro-api-client";
+
+import type { Stage } from "../../lib/stage-sidebar";
+import { groupArtifactsByFile, splitArtifactPath } from "./group";
+
+function stage(nodeId: string, startedAt: string | null, visit = 1): Stage {
+  return {
+    id: `${nodeId}@${visit}`,
+    name: nodeId,
+    handler: StageHandler.AGENT,
+    nodeId,
+    visit,
+    graphVisit: null,
+    resumedFromStageId: null,
+    status: StageState.SUCCEEDED,
+    duration: "1s",
+    startedAt,
+    providerUsed: null,
+  };
+}
+
+function artifact(
+  nodeSlug: string,
+  path: string,
+  size: number,
+  retry = 1,
+  visit = 1,
+): RunArtifactEntry {
+  return {
+    stage_id: `${nodeSlug}@${visit}`,
+    node_slug: nodeSlug,
+    retry,
+    relative_path: path,
+    size,
+  };
+}
+
+/** Mirrors run 01KYJ8ZR0N: one report rewritten by four stages. */
+const REPORT = ".ai/reports/2026-07-27-wrk-002-instance-lifecycle.md";
+
+const STAGES: Stage[] = [
+  stage("start", "2026-07-27T17:12:08Z"),
+  stage("plan", "2026-07-27T17:21:44Z"),
+  stage("implement_plan", "2026-07-27T17:44:18Z"),
+  stage("simplify", "2026-07-27T18:43:11Z"),
+  stage("consolidate_reviews", "2026-07-27T19:44:26Z"),
+  stage("fix_review_findings", "2026-07-27T19:49:22Z"),
+];
+
+describe("splitArtifactPath", () => {
+  test("splits a nested path into directory prefix and filename", () => {
+    expect(splitArtifactPath(".ai/reports/run.md")).toEqual({
+      dir: ".ai/reports/",
+      name: "run.md",
+    });
+  });
+
+  test("leaves a root-level path without a directory", () => {
+    expect(splitArtifactPath("README.md")).toEqual({ dir: "", name: "README.md" });
+  });
+});
+
+describe("groupArtifactsByFile", () => {
+  test("collapses repeated captures of one path into a single file", () => {
+    const files = groupArtifactsByFile(
+      [
+        artifact("consolidate_reviews", REPORT, 14323),
+        artifact("fix_review_findings", REPORT, 17483),
+        artifact("implement_plan", REPORT, 8422),
+        artifact("simplify", REPORT, 13162),
+      ],
+      STAGES,
+    );
+
+    expect(files).toHaveLength(1);
+    expect(files[0].path).toBe(REPORT);
+    expect(files[0].dir).toBe(".ai/reports/");
+    expect(files[0].name).toBe("2026-07-27-wrk-002-instance-lifecycle.md");
+    expect(files[0].versions).toHaveLength(4);
+  });
+
+  test("orders versions newest first using the API stage order", () => {
+    const stages = [
+      stage("implement_plan", "2026-07-27T20:00:00Z"),
+      stage("simplify", "2026-07-27T18:43:11Z"),
+    ];
+    const files = groupArtifactsByFile(
+      [
+        artifact("implement_plan", REPORT, 8422),
+        artifact("simplify", REPORT, 13162),
+      ],
+      stages,
+    );
+
+    expect(files[0].versions.map((v) => v.stageLabel)).toEqual([
+      "simplify",
+      "implement_plan",
+    ]);
+    expect(files[0].versions[0].size).toBe(13162);
+  });
+
+  test.each([
+    ["equal", "2026-07-27T18:43:11Z", "2026-07-27T18:43:11Z"],
+    ["missing", null, null],
+  ])("preserves API order when stage timestamps are %s", (_case, firstAt, secondAt) => {
+    const stages = [
+      stage("implement_plan", firstAt),
+      stage("simplify", secondAt),
+    ];
+    const files = groupArtifactsByFile(
+      [
+        artifact("simplify", REPORT, 13162),
+        artifact("implement_plan", REPORT, 8422),
+      ],
+      stages,
+    );
+
+    expect(files[0].versions.map((v) => v.stageLabel)).toEqual([
+      "simplify",
+      "implement_plan",
+    ]);
+  });
+
+  test("reports the byte change each capture introduced, oldest capture first", () => {
+    const files = groupArtifactsByFile(
+      [
+        artifact("implement_plan", REPORT, 8422),
+        artifact("simplify", REPORT, 13162),
+        artifact("consolidate_reviews", REPORT, 14323),
+        artifact("fix_review_findings", REPORT, 17483),
+      ],
+      STAGES,
+    );
+
+    // versions are newest-first, so deltas read 17483-14323, 14323-13162, ...
+    expect(files[0].versions.map((v) => v.delta)).toEqual([3160, 1161, 4740, null]);
+  });
+
+  test("drops captures from graph control nodes", () => {
+    const files = groupArtifactsByFile(
+      [
+        artifact("start", ".ai/reports/pre-existing.md", 12402),
+        artifact("plan", ".ai/plans/plan.md", 21749),
+      ],
+      STAGES,
+    );
+
+    expect(files.map((file) => file.path)).toEqual([".ai/plans/plan.md"]);
+  });
+
+  test("sorts files by their most recent capture", () => {
+    const files = groupArtifactsByFile(
+      [
+        artifact("plan", ".ai/plans/plan.md", 21749),
+        artifact("fix_review_findings", REPORT, 17483),
+        artifact("simplify", ".ai/reviews/bugs.xml", 5231),
+      ],
+      STAGES,
+    );
+
+    expect(files.map((file) => file.path)).toEqual([
+      REPORT,
+      ".ai/reviews/bugs.xml",
+      ".ai/plans/plan.md",
+    ]);
+  });
+
+  test("keeps retries of one stage as separate ordered versions", () => {
+    const files = groupArtifactsByFile(
+      [
+        artifact("simplify", REPORT, 13162, 2),
+        artifact("simplify", REPORT, 9000, 1),
+      ],
+      STAGES,
+    );
+
+    expect(files[0].versions.map((v) => v.retry)).toEqual([2, 1]);
+    expect(files[0].versions[0].size).toBe(13162);
+    expect(files[0].versions.map((v) => v.delta)).toEqual([4162, null]);
+  });
+
+  test("returns no files when every capture came from a control node", () => {
+    const files = groupArtifactsByFile(
+      [artifact("start", ".ai/reports/pre-existing.md", 12402)],
+      STAGES,
+    );
+
+    expect(files).toEqual([]);
+  });
+});

apps/fabro-web/app/routes/run-artifacts/group.ts

@@ -0,0 +1,104 @@
+import type { RunArtifactEntry } from "@qltysh/fabro-api-client";
+
+import { isVisibleStage } from "../../data/runs";
+import type { Stage } from "../../lib/stage-sidebar";
+import { formatStageLabel } from "../../lib/stage-sidebar";
+
+/** One capture of a file, written by a single stage attempt. */
+export interface ArtifactVersion {
+  stageId: string;
+  stageLabel: string;
+  retry: number;
+  size: number;
+  /** Byte change this capture introduced; null for the first capture. */
+  delta: number | null;
+}
+
+/** One artifact path together with its capture history, newest first. */
+export interface ArtifactFile {
+  path: string;
+  /** Directory prefix including the trailing slash, or "" at the root. */
+  dir: string;
+  name: string;
+  versions: readonly [ArtifactVersion, ...ArtifactVersion[]];
+}
+
+export function splitArtifactPath(path: string): { dir: string; name: string } {
+  const idx = path.lastIndexOf("/");
+  return idx >= 0
+    ? { dir: path.slice(0, idx + 1), name: path.slice(idx + 1) }
+    : { dir: "", name: path };
+}
+
+interface StageInfo {
+  label: string;
+  order: number;
+}
+
+/** Stage display data keyed by ID, preserving the API's event order. */
+function stageInfoById(stages: readonly Stage[]): Map<string, StageInfo> {
+  const info = new Map<string, StageInfo>();
+  stages.forEach((stage, order) => {
+    info.set(stage.id, { label: formatStageLabel(stage), order });
+  });
+  return info;
+}
+
+/**
+ * Collapse raw `(stage, retry, path)` capture keys into one entry per file,
+ * carrying the ordered history of every capture of that path.
+ *
+ * Captures from graph control nodes (`start`, `exit`) are dropped: those nodes
+ * run no work, so anything they match is a pre-existing workspace file rather
+ * than something the run produced.
+ */
+export function groupArtifactsByFile(
+  entries: readonly RunArtifactEntry[],
+  stages: readonly Stage[],
+): ArtifactFile[] {
+  const stageInfo = stageInfoById(stages);
+  const byPath = new Map<string, [ArtifactVersion, ...ArtifactVersion[]]>();
+
+  for (const entry of entries) {
+    if (!isVisibleStage(entry.node_slug)) continue;
+
+    const info = stageInfo.get(entry.stage_id);
+    const version: ArtifactVersion = {
+      stageId: entry.stage_id,
+      stageLabel: info?.label ?? entry.node_slug,
+      retry: entry.retry,
+      size: entry.size,
+      delta: null,
+    };
+    const bucket = byPath.get(entry.relative_path);
+    if (bucket) bucket.push(version);
+    else byPath.set(entry.relative_path, [version]);
+  }
+
+  const files: Array<{ file: ArtifactFile; order: number }> = [];
+  for (const [path, versions] of byPath) {
+    // Oldest first, so each version's delta is the change that capture introduced.
+    versions.sort(
+      (a, b) =>
+        (stageInfo.get(a.stageId)?.order ?? -1) -
+          (stageInfo.get(b.stageId)?.order ?? -1) ||
+        a.retry - b.retry ||
+        a.stageId.localeCompare(b.stageId),
+    );
+    versions.forEach((version, index) => {
+      version.delta = index === 0 ? null : version.size - versions[index - 1].size;
+    });
+
+    versions.reverse();
+    const latest = versions[0];
+    const { dir, name } = splitArtifactPath(path);
+    files.push({
+      file: { path, dir, name, versions },
+      order: stageInfo.get(latest.stageId)?.order ?? -1,
+    });
+  }
+
+  // Most recently written file first — the page answers "what just happened?".
+  files.sort((a, b) => b.order - a.order || a.file.path.localeCompare(b.file.path));
+  return files.map((entry) => entry.file);
+}

apps/fabro-web/app/routes/run-billing.test.tsx

@@ -2,11 +2,12 @@ import { afterEach, describe, expect, mock, test } from "bun:test";
 import TestRenderer from "react-test-renderer";
 
 import type {
-  BilledTokenCounts,
   RunBilling,
   StageTiming,
 } from "@qltysh/fabro-api-client";
 
+import { makeBilledTokenCounts } from "../lib/test-fixtures";
+
 function stageTiming(wall_time_ms = 0, inference_time_ms = 0, tool_time_ms = 0): StageTiming {
   return {
     wall_time_ms,
@@ -24,25 +25,12 @@ mock.module("../lib/queries", () => ({
 
 const { default: RunBillingRoute } = await import("./run-billing");
 
-function zeroBilling(overrides: Partial<BilledTokenCounts> = {}): BilledTokenCounts {
-  return {
-    cache_read_tokens: 0,
-    cache_write_tokens: 0,
-    input_tokens: 0,
-    output_tokens: 0,
-    reasoning_tokens: 0,
-    total_tokens: 0,
-    total_usd_micros: null,
-    ...overrides,
-  };
-}
-
 function billing(overrides: Partial<RunBilling> = {}): RunBilling {
   return {
     stages: [],
     totals: {
       timing: stageTiming(),
-      ...zeroBilling(),
+      ...makeBilledTokenCounts(),
     },
     by_model: [],
     ...overrides,
@@ -86,21 +74,21 @@ describe("RunBilling", () => {
           {
             stage: { id: "start", name: "start" },
             model: null,
-            billing: zeroBilling(),
+            billing: makeBilledTokenCounts(),
             timing: stageTiming(),
             state: "succeeded",
           },
           {
             stage: { id: "command", name: "command" },
             model: null,
-            billing: zeroBilling(),
+            billing: makeBilledTokenCounts(),
             timing: stageTiming(61000),
             state: "succeeded",
           },
         ],
         totals: {
           timing: stageTiming(61000),
-          ...zeroBilling(),
+          ...makeBilledTokenCounts(),
         },
       }),
     );
@@ -121,7 +109,7 @@ describe("RunBilling", () => {
           {
             stage: { id: "start", name: "start" },
             model: null,
-            billing: zeroBilling(),
+            billing: makeBilledTokenCounts(),
             timing: stageTiming(),
             state: "succeeded",
           },
@@ -131,7 +119,7 @@ describe("RunBilling", () => {
               provider: "anthropic",
               model_id: "claude-sonnet-4-5",
             },
-            billing: zeroBilling({
+            billing: makeBilledTokenCounts({
               input_tokens: 1200,
               output_tokens: 300,
               total_tokens: 1500,
@@ -143,7 +131,7 @@ describe("RunBilling", () => {
         ],
         totals: {
           timing: stageTiming(42000),
-          ...zeroBilling({
+          ...makeBilledTokenCounts({
             input_tokens: 1200,
             output_tokens: 300,
             total_tokens: 1500,
@@ -157,7 +145,7 @@ describe("RunBilling", () => {
               model_id: "claude-sonnet-4-5",
             },
             stages: 1,
-            billing: zeroBilling({
+            billing: makeBilledTokenCounts({
               input_tokens: 1200,
               output_tokens: 300,
               total_tokens: 1500,
@@ -204,7 +192,7 @@ describe("RunBilling", () => {
                 model_id: "claude-opus-4-6",
                 speed: "fast",
               },
-              billing: zeroBilling({
+              billing: makeBilledTokenCounts({
                 input_tokens: 1200,
                 output_tokens: 300,
                 total_tokens: 1500,
@@ -217,7 +205,7 @@ describe("RunBilling", () => {
           ],
           totals: {
             timing: stageTiming(),
-            ...zeroBilling({
+            ...makeBilledTokenCounts({
               input_tokens: 1200,
               output_tokens: 300,
               total_tokens: 1500,
@@ -232,7 +220,7 @@ describe("RunBilling", () => {
                 speed: "fast",
               },
               stages: 1,
-              billing: zeroBilling({
+              billing: makeBilledTokenCounts({
                 input_tokens: 1200,
                 output_tokens: 300,
                 total_tokens: 1500,
@@ -268,4 +256,4 @@ describe("RunBilling", () => {
       Date.now = originalNow;
     }
   });
-});
+});

apps/fabro-web/app/routes/run-billing.tsx

@@ -2,6 +2,11 @@ import { Fragment, useMemo } from "react";
 
 import { EmptyState } from "../components/state";
 import { Tooltip } from "../components/ui";
+import {
+  billableOutputTokens,
+  billingTokenBuckets,
+  hasBillingUsage,
+} from "../lib/billing";
 import {
   formatDurationMs,
   formatTokenCount,
@@ -11,6 +16,7 @@ import { useRunBilling } from "../lib/queries";
 import { IN_FLIGHT_STAGE_STATES } from "../lib/stage-sidebar";
 import { useTickingNow } from "../lib/time";
 import type {
+  BilledTokenCounts,
   BillingModelRef,
   RunBilling,
   RunBillingStage,
@@ -39,23 +45,15 @@ function isInFlight(stage: RunBillingStage): boolean {
 
 function isVisibleRow(row: MappedStageRow): boolean {
   if (row.inFlight) return true;
-  return (
-    (row.inputTokens ?? 0) > 0 ||
-    (row.outputTokens ?? 0) > 0 ||
-    (row.totalUsdMicros ?? 0) > 0
-  );
+  return row.billing != null && hasBillingUsage(row.billing);
 }
 
 interface MappedStageRow {
-  stage:            string;
-  model:            string | null;
-  inputTokens:      number | null;
-  outputTokens:     number | null;
-  cacheReadTokens:  number | null;
-  cacheWriteTokens: number | null;
-  wallTimeMs:       number;
-  totalUsdMicros:   number | null | undefined;
-  inFlight:         boolean;
+  stage:      string;
+  model:      string | null;
+  billing:    BilledTokenCounts | null;
+  wallTimeMs: number;
+  inFlight:   boolean;
 }
 
 function liveWallTimeMs(stage: RunBillingStage, now: number): number {
@@ -73,49 +71,28 @@ export const handle = { wide: true };
 function mapStageRow(stage: RunBillingStage, wallTimeMs: number): MappedStageRow {
   const hasModel = stage.model != null;
   return {
-    stage:            stage.stage.name,
-    model:            formatModelRef(stage.model),
-    inputTokens:      hasModel ? stage.billing.input_tokens : null,
-    outputTokens:     hasModel
-      ? stage.billing.output_tokens + stage.billing.reasoning_tokens
-      : null,
-    cacheReadTokens:  hasModel ? stage.billing.cache_read_tokens : null,
-    cacheWriteTokens: hasModel ? stage.billing.cache_write_tokens : null,
+    stage: stage.stage.name,
+    model: formatModelRef(stage.model),
+    billing: hasModel ? stage.billing : null,
     wallTimeMs,
-    totalUsdMicros:   stage.billing.total_usd_micros,
-    inFlight:         isInFlight(stage),
+    inFlight: isInFlight(stage),
   };
 }
 
 /** Hover breakdown of the disjoint token buckets behind an `in / out` count. */
-function TokenBreakdown({
-  cacheReadTokens,
-  cacheWriteTokens,
-  inputTokens,
-  outputTokens,
-}: {
-  cacheReadTokens:  number;
-  cacheWriteTokens: number;
-  inputTokens:      number;
-  outputTokens:     number;
-}) {
-  const rows = [
-    { label: "Cache read", value: cacheReadTokens },
-    { label: "Cache creation", value: cacheWriteTokens },
-    { label: "Uncached", value: inputTokens },
-    { label: "Output", value: outputTokens },
-  ];
+function TokenBreakdown({ billing }: { billing: BilledTokenCounts }) {
+  const buckets = billingTokenBuckets(billing);
   return (
     <div className="min-w-44 py-0.5">
-      <div className="mb-1.5 border-b border-line pb-1 font-medium text-fg-2">
+      <div className="border-line text-fg-2 mb-1.5 border-b pb-1 font-medium">
         Tokens in / out
       </div>
       <dl className="grid grid-cols-[1fr_auto] gap-x-6 gap-y-1">
-        {rows.map((row) => (
-          <Fragment key={row.label}>
-            <dt className="text-fg-3">{row.label}</dt>
-            <dd className="text-right font-mono tabular-nums text-fg">
-              {formatTokens(row.value)}
+        {buckets.map((bucket) => (
+          <Fragment key={bucket.label}>
+            <dt className="text-fg-3">{bucket.label}</dt>
+            <dd className="text-fg text-right font-mono tabular-nums">
+              {formatTokens(bucket.value)}
             </dd>
           </Fragment>
         ))}
@@ -128,42 +105,16 @@ function TokenBreakdown({
  * Renders an `input / output` token count. When the row has model usage,
  * hovering the count reveals the cache breakdown.
  */
-function TokensCell({
-  inputTokens,
-  outputTokens,
-  cacheReadTokens,
-  cacheWriteTokens,
-}: {
-  inputTokens:      number | null;
-  outputTokens:     number | null;
-  cacheReadTokens:  number | null;
-  cacheWriteTokens: number | null;
-}) {
+function TokensCell({ billing }: { billing: BilledTokenCounts | null }) {
   const display = (
     <>
-      {formatTokens(inputTokens)} <span className="text-fg-muted">/</span>{" "}
-      {formatTokens(outputTokens)}
+      {formatTokens(billing?.input_tokens)} <span className="text-fg-muted">/</span>{" "}
+      {formatTokens(billing ? billableOutputTokens(billing) : null)}
     </>
   );
-  if (
-    inputTokens == null ||
-    outputTokens == null ||
-    cacheReadTokens == null ||
-    cacheWriteTokens == null
-  ) {
-    return display;
-  }
+  if (!billing) return display;
   return (
-    <Tooltip
-      label={
-        <TokenBreakdown
-          cacheReadTokens={cacheReadTokens}
-          cacheWriteTokens={cacheWriteTokens}
-          inputTokens={inputTokens}
-          outputTokens={outputTokens}
-        />
-      }
-    >
+    <Tooltip label={<TokenBreakdown billing={billing} />}>
       <span>{display}</span>
     </Tooltip>
   );
@@ -189,15 +140,14 @@ export default function RunBilling({ params }: { params: { id: string } }) {
     if (!billing) return [];
     return billing.by_model
       .map((entry) => ({
-        model:            formatModelRef(entry.model) ?? EMPTY_VALUE,
-        stages:           entry.stages,
-        inputTokens:      entry.billing.input_tokens,
-        outputTokens:     entry.billing.output_tokens + entry.billing.reasoning_tokens,
-        cacheReadTokens:  entry.billing.cache_read_tokens,
-        cacheWriteTokens: entry.billing.cache_write_tokens,
-        totalUsdMicros:   entry.billing.total_usd_micros,
+        model:   formatModelRef(entry.model) ?? EMPTY_VALUE,
+        stages:  entry.stages,
+        billing: entry.billing,
       }))
-      .sort((a, b) => (b.totalUsdMicros ?? -1) - (a.totalUsdMicros ?? -1));
+      .sort(
+        (a, b) =>
+          (b.billing.total_usd_micros ?? -1) - (a.billing.total_usd_micros ?? -1),
+      );
   }, [billing]);
 
   // Re-derive only the in-flight rows on each tick; everything else stays put.
@@ -218,16 +168,7 @@ export default function RunBilling({ params }: { params: { id: string } }) {
     : (billing?.totals.timing.wall_time_ms ?? 0);
 
   const hasLlmStages = (billing?.by_model.length ?? 0) > 0;
-  const totalInput = hasLlmStages ? (billing?.totals.input_tokens ?? null) : null;
-  const totalOutput = hasLlmStages && billing
-    ? billing.totals.output_tokens + billing.totals.reasoning_tokens
-    : null;
-  const totalCacheRead = hasLlmStages
-    ? (billing?.totals.cache_read_tokens ?? null)
-    : null;
-  const totalCacheWrite = hasLlmStages
-    ? (billing?.totals.cache_write_tokens ?? null)
-    : null;
+  const totalBilling = hasLlmStages && billing ? billing.totals : null;
   const totalUsdMicros = billing?.totals.total_usd_micros;
   const modelStageCount = modelBreakdown.reduce((sum, row) => sum + row.stages, 0);
   const visibleRows = rows.filter(isVisibleRow);
@@ -268,18 +209,13 @@ export default function RunBilling({ params }: { params: { id: string } }) {
                   {row.model ?? EMPTY_VALUE}
                 </td>
                 <td className="px-4 py-3 text-right font-mono text-xs tabular-nums text-fg-3">
-                  <TokensCell
-                    inputTokens={row.inputTokens}
-                    outputTokens={row.outputTokens}
-                    cacheReadTokens={row.cacheReadTokens}
-                    cacheWriteTokens={row.cacheWriteTokens}
-                  />
+                  <TokensCell billing={row.billing} />
                 </td>
                 <td className="px-4 py-3 text-right font-mono text-xs text-fg-3">
                   {formatDurationMs(row.wallTimeMs)}
                 </td>
                 <td className="px-4 py-3 text-right font-mono text-xs text-fg-3">
-                  {formatUsdMicrosOrDash(row.totalUsdMicros)}
+                  {formatUsdMicrosOrDash(row.billing?.total_usd_micros)}
                 </td>
               </tr>
             ))}
@@ -289,12 +225,7 @@ export default function RunBilling({ params }: { params: { id: string } }) {
               <td className="px-4 py-3 font-medium text-fg">Total</td>
               <td className="px-4 py-3 text-xs text-fg-muted">All models</td>
               <td className="px-4 py-3 text-right font-mono text-xs tabular-nums font-medium text-fg">
-                <TokensCell
-                  inputTokens={totalInput}
-                  outputTokens={totalOutput}
-                  cacheReadTokens={totalCacheRead}
-                  cacheWriteTokens={totalCacheWrite}
-                />
+                <TokensCell billing={totalBilling} />
               </td>
               <td className="px-4 py-3 text-right font-mono text-xs font-medium text-fg">
                 {formatDurationMs(totalWallTimeMs)}
@@ -328,15 +259,10 @@ export default function RunBilling({ params }: { params: { id: string } }) {
                       {row.stages}
                     </td>
                     <td className="px-4 py-3 text-right font-mono text-xs tabular-nums text-fg-3">
-                      <TokensCell
-                        inputTokens={row.inputTokens}
-                        outputTokens={row.outputTokens}
-                        cacheReadTokens={row.cacheReadTokens}
-                        cacheWriteTokens={row.cacheWriteTokens}
-                      />
+                      <TokensCell billing={row.billing} />
                     </td>
                     <td className="px-4 py-3 text-right font-mono text-xs text-fg-3">
-                      {formatUsdMicrosOrDash(row.totalUsdMicros)}
+                      {formatUsdMicrosOrDash(row.billing.total_usd_micros)}
                     </td>
                   </tr>
                 ))}
@@ -348,12 +274,7 @@ export default function RunBilling({ params }: { params: { id: string } }) {
                     {modelStageCount}
                   </td>
                   <td className="px-4 py-3 text-right font-mono text-xs tabular-nums font-medium text-fg">
-                    <TokensCell
-                      inputTokens={totalInput}
-                      outputTokens={totalOutput}
-                      cacheReadTokens={totalCacheRead}
-                      cacheWriteTokens={totalCacheWrite}
-                    />
+                    <TokensCell billing={totalBilling} />
                   </td>
                   <td className="px-4 py-3 text-right font-mono text-xs font-medium text-fg">
                     {formatUsdMicrosOrDash(totalUsdMicros)}

apps/fabro-web/app/routes/run-detail.test.ts

@@ -183,13 +183,33 @@ import {
   lifecycleActionVisibility,
 } from "./run-detail/lifecycle-toasts";
 
-const { default: RunDetail } = await import("./run-detail");
+const {
+  default: RunDetail,
+  resolveDockClearance,
+} = await import("./run-detail");
 mock.restore();
 type LifecycleToastState = import("./run-detail/lifecycle-toasts").LifecycleToastState;
 type RunDetailActionResult = import("./run-detail/lifecycle-toasts").RunDetailActionResult;
 
 const h = createElement;
 
+describe("resolveDockClearance", () => {
+  test("uses only a current dock measurement", () => {
+    const measurement = { identity: "run_1:steer", height: 108 };
+
+    expect(resolveDockClearance(null, measurement, false)).toBe("0px");
+    expect(
+      resolveDockClearance("run_1:interview", measurement, true),
+    ).toBe("18rem");
+    expect(resolveDockClearance("run_2:steer", measurement, false)).toBe(
+      "5rem",
+    );
+    expect(resolveDockClearance("run_1:steer", measurement, false)).toBe(
+      "108px",
+    );
+  });
+});
+
 function makeRunSummary({
   status = "succeeded",
   diffSummary = null as any,
@@ -841,7 +861,7 @@ describe("RunDetail full-height child routes", () => {
     });
 
     const statuses = renderer.root.findAll(
-      (node) => node.type === "p" && node.props.role === "status",
+      (node) => node.props.role === "status",
     );
     expect(statuses.map(textFromTestNode)).toContain(
       "Interrupted — waiting for steering",

apps/fabro-web/app/routes/run-detail.tsx

@@ -19,6 +19,7 @@ import {
 } from "../components/ui";
 import { mutateRunListCaches } from "../lib/board-cache";
 import { useDemoMode } from "../lib/demo-mode";
+import { useTickingNow } from "../lib/time";
 import { useSWRConfig } from "swr";
 import {
   useArchiveRun,
@@ -56,10 +57,7 @@ import {
   lifecycleActionVisibility,
   updateLifecycleToastState,
 } from "./run-detail/lifecycle-toasts";
-import {
-  buildRunDetailRun,
-  useTickingNow,
-} from "./run-detail/model";
+import { buildRunDetailRun } from "./run-detail/model";
 import {
   buildRunDetailTabs,
   childRouteLayoutFlags,
@@ -69,8 +67,27 @@ import {
 
 export const handle = { hideHeader: true };
 
+const RUN_TIMING_REFRESH_INTERVAL_MS = 30_000;
+
 type LifecycleTrigger = () => Promise<LifecycleMutationResult | undefined>;
 
+export interface DockMeasurement {
+  identity: string;
+  height: number;
+}
+
+export function resolveDockClearance(
+  dockIdentity: string | null,
+  measurement: DockMeasurement | null,
+  hasPendingQuestions: boolean,
+): string {
+  if (dockIdentity === null) return "0px";
+  if (measurement?.identity === dockIdentity) {
+    return `${measurement.height}px`;
+  }
+  return hasPendingQuestions ? "18rem" : "5rem";
+}
+
 export function meta({ data }: any) {
   const run = data?.run;
   return [{ title: run ? `${run.title} — Fabro` : "Run — Fabro" }];
@@ -78,7 +95,7 @@ export function meta({ data }: any) {
 
 export default function RunDetail({ params }: { params: { id: string } }) {
   const demoMode = useDemoMode();
-  const runQuery = useRun(params.id);
+  const runQuery = useRun(params.id, RUN_TIMING_REFRESH_INTERVAL_MS);
   const runStateQuery = useRunState(params.id);
   const summary = runQuery.data;
   const run = summary ? buildRunDetailRun(summary) : null;
@@ -102,6 +119,8 @@ export default function RunDetail({ params }: { params: { id: string } }) {
   const { mutate } = useSWRConfig();
   const [deleteDialogOpen, setDeleteDialogOpen] = useState(false);
   const [deletePending, setDeletePending] = useState(false);
+  const [dockMeasurement, setDockMeasurement] =
+    useState<DockMeasurement | null>(null);
   const { push, dismiss } = useToast();
   const lifecycleToastStateRef = useRef(createLifecycleToastState());
   const filesCount = runQuery.data?.diff?.files_changed ?? null;
@@ -116,7 +135,10 @@ export default function RunDetail({ params }: { params: { id: string } }) {
     childrenCount,
   });
   const steerBarRef = useRef<SteerBarHandle | null>(null);
-  const now = useTickingNow(30_000);
+  const now = useTickingNow(
+    summary != null && summary.timestamps.completed_at == null,
+    RUN_TIMING_REFRESH_INTERVAL_MS,
+  );
   const { fullHeight, hideSteerBar } = childRouteLayoutFlags(matches);
 
   useRunEvents(params.id);
@@ -144,6 +166,15 @@ export default function RunDetail({ params }: { params: { id: string } }) {
     },
     [handleLifecycleMutationResult],
   );
+  const handleDockHeightChange = useCallback(
+    (identity: string, height: number | null) => {
+      setDockMeasurement((current) => {
+        if (height !== null) return { identity, height };
+        return current?.identity === identity ? null : current;
+      });
+    },
+    [],
+  );
 
   if (runQuery.isLoading && !run) {
     return <div className="py-12" />;
@@ -305,7 +336,19 @@ export default function RunDetail({ params }: { params: { id: string } }) {
         : []),
     ],
   };
-  const dockClearance = hasPendingQuestions ? "18rem" : "5rem";
+  // Reserve exactly the dock's rendered height. The constants are only the
+  // first frame, before the dock has been measured; a fixed reservation lets
+  // a tall question panel cover the content it is asking about.
+  const dockIdentity = hasPendingQuestions
+    ? `${params.id}:interview`
+    : hideSteerBar
+      ? null
+      : `${params.id}:steer`;
+  const dockClearance = resolveDockClearance(
+    dockIdentity,
+    dockMeasurement,
+    hasPendingQuestions,
+  );
   const rootStyle = {
     "--fabro-interview-dock-clearance": dockClearance,
   } as CSSProperties;
@@ -364,14 +407,16 @@ export default function RunDetail({ params }: { params: { id: string } }) {
           />
 
           <RunDetailDockedControls
+            key={dockIdentity ?? "hidden"}
             runId={params.id}
-            hideSteerBar={hideSteerBar}
+            dockIdentity={dockIdentity}
             hasPendingQuestions={hasPendingQuestions}
             pendingQuestions={pendingQuestions}
             sidebarWidth={sidebarWidth}
             isResizing={isResizing}
             steerBarRef={steerBarRef}
             waitingForSteer={waitingForSteer}
+            onHeightChange={handleDockHeightChange}
           />
         </div>
       )}

apps/fabro-web/app/routes/run-detail/docked-controls.test.tsx

@@ -0,0 +1,158 @@
+import {
+  afterEach,
+  beforeEach,
+  describe,
+  expect,
+  mock,
+  test,
+} from "bun:test";
+import { createElement, createRef } from "react";
+import TestRenderer, { act } from "react-test-renderer";
+
+import { setupReactTestEnv } from "../../lib/test-utils";
+
+mock.module("../../components/interview-dock", () => ({
+  InterviewDock: () => createElement("div", null, "Interview"),
+}));
+mock.module("../../components/steer-bar", () => ({
+  SteerBar: () => createElement("div", null, "Steer"),
+}));
+
+const { RunDetailDockedControls } = await import("./docked-controls");
+mock.restore();
+
+const mountedRenderers: TestRenderer.ReactTestRenderer[] = [];
+const observerCallbacks: ResizeObserverCallback[] = [];
+const dockNode = { offsetHeight: 999 };
+let originalResizeObserver: typeof ResizeObserver | undefined;
+let teardownReactEnv: (() => void) | undefined;
+
+function resizeEntry(blockSize: number): ResizeObserverEntry {
+  return {
+    borderBoxSize: [{ blockSize, inlineSize: 600 }],
+  } as unknown as ResizeObserverEntry;
+}
+
+function renderDock({
+  identity,
+  hasPendingQuestions = false,
+  onHeightChange,
+}: {
+  identity: string | null;
+  hasPendingQuestions?: boolean;
+  onHeightChange: (identity: string, height: number | null) => void;
+}) {
+  return (
+    <RunDetailDockedControls
+      key={identity ?? "hidden"}
+      runId="run-1"
+      dockIdentity={identity}
+      hasPendingQuestions={hasPendingQuestions}
+      pendingQuestions={[]}
+      sidebarWidth={0}
+      isResizing={false}
+      steerBarRef={createRef()}
+      waitingForSteer={false}
+      onHeightChange={onHeightChange}
+    />
+  );
+}
+
+beforeEach(() => {
+  teardownReactEnv = setupReactTestEnv();
+  observerCallbacks.length = 0;
+  originalResizeObserver = globalThis.ResizeObserver;
+  globalThis.ResizeObserver = class ResizeObserver {
+    constructor(callback: ResizeObserverCallback) {
+      observerCallbacks.push(callback);
+    }
+    observe() {}
+    unobserve() {}
+    disconnect() {}
+  } as typeof ResizeObserver;
+});
+
+afterEach(() => {
+  for (const renderer of mountedRenderers.splice(0)) {
+    act(() => renderer.unmount());
+  }
+  if (originalResizeObserver) {
+    globalThis.ResizeObserver = originalResizeObserver;
+  } else {
+    delete (globalThis as { ResizeObserver?: typeof ResizeObserver })
+      .ResizeObserver;
+  }
+  teardownReactEnv?.();
+  teardownReactEnv = undefined;
+});
+
+describe("RunDetailDockedControls", () => {
+  test("reports border-box height only when the height changes", () => {
+    const onHeightChange = mock(
+      (_identity: string, _height: number | null) => undefined,
+    );
+    let renderer!: TestRenderer.ReactTestRenderer;
+    act(() => {
+      renderer = TestRenderer.create(
+        renderDock({ identity: "run-1:steer", onHeightChange }),
+        {
+          createNodeMock: () => dockNode,
+        },
+      );
+    });
+    mountedRenderers.push(renderer);
+    const callback = observerCallbacks[0]!;
+
+    act(() => callback([resizeEntry(108)], {} as ResizeObserver));
+    act(() => callback([resizeEntry(108)], {} as ResizeObserver));
+    act(() => callback([resizeEntry(120)], {} as ResizeObserver));
+
+    expect(onHeightChange).toHaveBeenCalledTimes(2);
+    expect(onHeightChange.mock.calls).toEqual([
+      ["run-1:steer", 108],
+      ["run-1:steer", 120],
+    ]);
+  });
+
+  test("clears the old identity when the dock changes or hides", () => {
+    const onHeightChange = mock(
+      (_identity: string, _height: number | null) => undefined,
+    );
+    let renderer!: TestRenderer.ReactTestRenderer;
+    act(() => {
+      renderer = TestRenderer.create(
+        renderDock({ identity: "run-1:steer", onHeightChange }),
+        {
+          createNodeMock: () => dockNode,
+        },
+      );
+    });
+    mountedRenderers.push(renderer);
+    act(() =>
+      observerCallbacks[0]!([resizeEntry(108)], {} as ResizeObserver),
+    );
+
+    act(() => {
+      renderer.update(
+        renderDock({
+          identity: "run-1:interview",
+          hasPendingQuestions: true,
+          onHeightChange,
+        }),
+      );
+    });
+    act(() =>
+      observerCallbacks[1]!([resizeEntry(220)], {} as ResizeObserver),
+    );
+    act(() => {
+      renderer.update(renderDock({ identity: null, onHeightChange }));
+    });
+
+    expect(onHeightChange.mock.calls).toEqual([
+      ["run-1:steer", 108],
+      ["run-1:steer", null],
+      ["run-1:interview", 220],
+      ["run-1:interview", null],
+    ]);
+  });
+});

apps/fabro-web/app/routes/run-detail/docked-controls.tsx

@@ -1,10 +1,14 @@
 import {
+  useCallback,
+  useRef,
   useState,
   type ReactNode,
   type RefObject,
 } from "react";
 import { SparklesIcon } from "@heroicons/react/20/solid";
 
+import { useResizeObserver } from "../../hooks/effects";
+
 import AskFabroSidebar, {
   SIDEBAR_WIDTH,
 } from "../../components/chats/ask-fabro-sidebar";
@@ -14,12 +18,12 @@ import {
   SECONDARY_BUTTON_CLASS,
   Tooltip,
 } from "../../components/ui";
+import { classNames } from "../../lib/class-names";
 import {
   AskFabroUnavailableReasonEnum,
   type ApiQuestion,
   type AskFabro,
 } from "@qltysh/fabro-api-client";
-import { classNames } from "./model";
 
 const ASK_FABRO_UNAVAILABLE_TOOLTIPS: Record<
   AskFabroUnavailableReasonEnum,
@@ -127,32 +131,73 @@ function AskFabroTriggerButton({
 
 export function RunDetailDockedControls({
   runId,
-  hideSteerBar,
+  dockIdentity,
   hasPendingQuestions,
   pendingQuestions,
   sidebarWidth,
   isResizing,
   steerBarRef,
   waitingForSteer,
+  onHeightChange,
 }: {
   runId: string;
-  hideSteerBar: boolean;
+  dockIdentity: string | null;
   hasPendingQuestions: boolean;
   pendingQuestions: ApiQuestion[];
   sidebarWidth: number;
   isResizing: boolean;
   steerBarRef: RefObject<SteerBarHandle | null>;
   waitingForSteer: boolean;
+  /**
+   * Reports the dock's rendered height so the page can reserve exactly that
+   * much room beneath the scrolling content.
+   */
+  onHeightChange: (identity: string, height: number | null) => void;
 }) {
-  if (hideSteerBar && !hasPendingQuestions) return null;
+  const dockRef = useRef<HTMLDivElement | null>(null);
+  const reportedHeightRef = useRef<number | null>(null);
+  const visible = dockIdentity !== null;
+  const reportHeight = useCallback(
+    (height: number | null) => {
+      if (dockIdentity === null || reportedHeightRef.current === height) return;
+      reportedHeightRef.current = height;
+      onHeightChange(dockIdentity, height);
+    },
+    [dockIdentity, onHeightChange],
+  );
+  const setDockRef = useCallback(
+    (node: HTMLDivElement | null) => {
+      dockRef.current = node;
+      if (node === null) reportHeight(null);
+    },
+    [reportHeight],
+  );
+
+  useResizeObserver(
+    dockRef,
+    (entries) => {
+      const entry = entries[0];
+      if (!entry) return;
+      const borderBoxSize = Array.isArray(entry.borderBoxSize)
+        ? entry.borderBoxSize[0]
+        : (entry.borderBoxSize as unknown as ResizeObserverSize);
+      reportHeight(
+        borderBoxSize?.blockSize ?? dockRef.current?.offsetHeight ?? null,
+      );
+    },
+    visible,
+  );
+
+  if (!visible) return null;
 
   return (
     <div
-      className={`fixed bottom-0 left-0 z-30 border-t border-line bg-page ${
-        isResizing
-          ? ""
-          : "transition-[right] duration-300 ease-[cubic-bezier(0.16,1,0.3,1)]"
-      }`}
+      ref={setDockRef}
+      className={classNames(
+        "fixed bottom-0 left-0 z-30 border-t border-line bg-page",
+        !isResizing &&
+          "transition-[right] duration-300 ease-[cubic-bezier(0.16,1,0.3,1)]",
+      )}
       style={{ right: sidebarWidth }}
     >
       {hasPendingQuestions ? (

apps/fabro-web/app/routes/run-detail/header.tsx

@@ -35,10 +35,11 @@ import {
   formatDurationMs,
   formatRelativeTime,
 } from "../../lib/format";
+import { classNames } from "../../lib/class-names";
 import { useRunPullRequest } from "../../lib/queries";
 import { sandboxRuntime } from "../../lib/run-sandbox-lifecycle";
 import { ActionsMenu, type ActionsMenuProps } from "./actions";
-import { classNames, type RunDetailRun } from "./model";
+import type { RunDetailRun } from "./model";
 
 export interface RunDetailHeaderActions {
   approval: {
@@ -326,6 +327,7 @@ function DurationPopover({
 }) {
   const endMs = completedAt != null ? Date.parse(completedAt) : now;
   const sinceCreatedMs = Math.max(0, endMs - Date.parse(createdAt));
+  const isRunning = completedAt == null;
   return (
     <>
       <PopoverHeader>Duration</PopoverHeader>
@@ -335,8 +337,14 @@ function DurationPopover({
           <dd className="mt-0.5 font-mono text-fg">{formatDurationMs(sinceCreatedMs)}</dd>
         </div>
         <div>
-          <dt className="text-fg-3">Active (inference + tools)</dt>
+          <dt className="text-fg-3">
+            Active (inference + tools){isRunning ? " — estimated" : ""}
+          </dt>
           <dd className="mt-0.5 font-mono text-fg">{formatDurationMs(timing.active_time_ms)}</dd>
+          <dd className="mt-0.5 text-fg-3">
+            {formatDurationMs(timing.inference_time_ms)} inference ·{" "}
+            {formatDurationMs(timing.tool_time_ms)} tools
+          </dd>
         </div>
       </dl>
     </>

apps/fabro-web/app/routes/run-detail/model.ts

@@ -1,6 +1,3 @@
-import { useState } from "react";
-
-import { useInterval } from "../../hooks/effects";
 import {
   isRunStatus,
   mapRunToRunItem,
@@ -8,16 +5,6 @@ import {
   type Run,
 } from "../../data/runs";
 
-export function classNames(...classes: Array<string | false | null | undefined>) {
-  return classes.filter(Boolean).join(" ");
-}
-
-export function useTickingNow(intervalMs: number): number {
-  const [now, setNow] = useState(() => Date.now());
-  useInterval(() => setNow(Date.now()), intervalMs);
-  return now;
-}
-
 export type RunDetailRun = ReturnType<typeof mapRunToRunItem> & {
   statusLabel: string;
   statusDot: string;

apps/fabro-web/app/routes/run-detail/tabs-shell.tsx

@@ -1,7 +1,7 @@
 import { Link, Outlet, type UIMatch } from "react-router";
 
+import { classNames } from "../../lib/class-names";
 import { sandboxTabVisible, type MaybeSandbox } from "../../lib/run-sandbox-lifecycle";
-import { classNames } from "./model";
 
 interface RunDetailTabDefinition {
   name: string;

apps/fabro-web/app/routes/run-stages-chat.test.tsx

@@ -3,6 +3,7 @@ import { renderToStaticMarkup } from "react-dom/server";
 import { StageState } from "@qltysh/fabro-api-client";
 
 import type { Stage } from "../lib/stage-sidebar";
+import { makeBilledTokenCounts } from "../lib/test-fixtures";
 import { StageChatView } from "./run-stages";
 
 function stage(overrides: Partial<Stage> = {}): Stage {
@@ -18,6 +19,7 @@ function stage(overrides: Partial<Stage> = {}): Stage {
     resumedFromStageId: null,
     startedAt: "2026-04-09T12:00:00Z",
     providerUsed: null,
+    billing: makeBilledTokenCounts(),
     ...overrides,
   };
 }

apps/fabro-web/app/routes/run-stages-details.test.tsx

@@ -1,9 +1,14 @@
 import { describe, expect, test } from "bun:test";
 import { renderToStaticMarkup } from "react-dom/server";
 
-import type { ReasoningOutput } from "@qltysh/fabro-api-client";
+import type {
+  BilledTokenCounts,
+  ReasoningOutput,
+  StageModelUsage,
+} from "@qltysh/fabro-api-client";
 
-import { EventDetails } from "./run-stages";
+import { makeBilledTokenCounts } from "../lib/test-fixtures";
+import { EventDetails, ModelUsagePopover } from "./run-stages";
 
 const RUN_START = "2026-04-09T12:00:00Z";
 
@@ -72,3 +77,77 @@ describe("EventDetails reasoning", () => {
     expect(html).toContain(`${"x".repeat(280)}…`);
   });
 });
+
+const PROVIDER_USED: StageModelUsage = {
+  mode: "agent",
+  provider: "moonshot",
+  model: "kimi-k3",
+  reasoning_effort: "max",
+};
+
+function popoverMarkup(counts: BilledTokenCounts): string {
+  return renderToStaticMarkup(
+    <ModelUsagePopover providerUsed={PROVIDER_USED} billing={counts} />,
+  );
+}
+
+describe("ModelUsagePopover billing", () => {
+  test("shows the visit's token buckets and cost next to the model", () => {
+    const html = popoverMarkup(
+      makeBilledTokenCounts({
+        input_tokens: 28_640,
+        output_tokens: 7_550,
+        reasoning_tokens: 1_200,
+        cache_read_tokens: 4_800,
+        cache_write_tokens: 1_500,
+        total_tokens: 43_690,
+        total_usd_micros: 720_000,
+      }),
+    );
+
+    expect(html).toContain("kimi-k3");
+    expect(html).toContain("Cache read");
+    expect(html).toContain("4.8k");
+    expect(html).toContain("Cache creation");
+    expect(html).toContain("1.5k");
+    expect(html).toContain("Uncached");
+    expect(html).toContain("28.6k");
+    // Output folds in reasoning tokens, matching the Billing tab.
+    expect(html).toContain("Output");
+    expect(html).toContain("8.8k");
+    expect(html).toContain("Cost");
+    expect(html).toContain("$0.72");
+  });
+
+  test("omits the token section for a stage that called no model", () => {
+    const html = popoverMarkup(makeBilledTokenCounts());
+
+    expect(html).toContain("kimi-k3");
+    expect(html).not.toContain("Tokens");
+    expect(html).not.toContain("Cost");
+  });
+
+  test("still shows tokens when nothing priced the stage", () => {
+    const html = popoverMarkup(
+      makeBilledTokenCounts({
+        input_tokens: 1_000,
+        output_tokens: 500,
+        total_tokens: 1_500,
+      }),
+    );
+
+    expect(html).toContain("Uncached");
+    expect(html).toContain("1.0k");
+    expect(html).not.toContain("Cost");
+  });
+
+  test("shows a provider-reported cost when token counts are unavailable", () => {
+    const html = popoverMarkup(
+      makeBilledTokenCounts({ total_usd_micros: 720_000 }),
+    );
+
+    expect(html).toContain("kimi-k3");
+    expect(html).toContain("Cost");
+    expect(html).toContain("$0.72");
+  });
+});

apps/fabro-web/app/routes/run-stages.tsx

@@ -67,7 +67,9 @@ import {
   formatBytes,
   formatDurationMs,
   formatTokenCount,
+  formatUsdMicros,
 } from "../lib/format";
+import { billingTokenBuckets, hasBillingUsage } from "../lib/billing";
 import { plural } from "../lib/plural";
 import {
   useRun,
@@ -93,6 +95,7 @@ import {
   type UnknownRecord,
 } from "../lib/unknown";
 import type {
+  BilledTokenCounts,
   EventEnvelope,
   ReasoningOutput,
   StageHandler,
@@ -866,10 +869,42 @@ export function formatStageModelUsageLabel(
   return effort ? `${model}[${effort}]` : model;
 }
 
-function ModelUsagePopover({
+const POPOVER_NUMBER = "block text-right font-mono tabular-nums";
+
+/** Tokens and cost for this stage visit alone. */
+function StageBillingRows({ billing }: { billing: BilledTokenCounts }) {
+  if (!hasBillingUsage(billing)) return null;
+  const buckets = billingTokenBuckets(billing);
+  const cost = formatUsdMicros(billing.total_usd_micros);
+  return (
+    <div className="mt-3">
+      <PopoverHeader>Tokens</PopoverHeader>
+      <PopoverRows>
+        {buckets.map((bucket) => (
+          <PopoverRow key={bucket.label} label={bucket.label}>
+            <span className={POPOVER_NUMBER}>
+              {bucket.value === 0
+                ? "0"
+                : formatTokenCount(bucket.value, { compactDecimal: true })}
+            </span>
+          </PopoverRow>
+        ))}
+        {cost && (
+          <PopoverRow label="Cost">
+            <span className={POPOVER_NUMBER}>{cost}</span>
+          </PopoverRow>
+        )}
+      </PopoverRows>
+    </div>
+  );
+}
+
+export function ModelUsagePopover({
   providerUsed,
+  billing,
 }: {
   providerUsed: StageModelUsage;
+  billing: BilledTokenCounts;
 }) {
   return (
     <>
@@ -892,6 +927,7 @@ function ModelUsagePopover({
           <PopoverRow label="Speed">{providerUsed.speed}</PopoverRow>
         )}
       </PopoverRows>
+      <StageBillingRows billing={billing} />
     </>
   );
 }
@@ -1905,6 +1941,7 @@ function EventsToolbar({
   filteredCount,
   totalCount,
   providerUsed,
+  billing,
   events,
   runId,
   stageId,
@@ -1924,6 +1961,7 @@ function EventsToolbar({
   filteredCount: number;
   totalCount: number;
   providerUsed: StageModelUsage | null;
+  billing: BilledTokenCounts;
   events: EventEnvelope[];
   runId: string;
   stageId: string;
@@ -2004,7 +2042,9 @@ function EventsToolbar({
           className={`inline-flex items-center gap-1.5 text-xs text-fg-muted ${
             showFilters ? "" : "ml-auto"
           }`}
-          content={<ModelUsagePopover providerUsed={providerUsed} />}
+          content={
+            <ModelUsagePopover providerUsed={providerUsed} billing={billing} />
+          }
         >
           <CpuChipIcon className="size-3.5" aria-hidden="true" />
           <span className="font-mono">{modelUsageLabel}</span>
@@ -2359,6 +2399,7 @@ function RunStageActivityStage({
                 effectiveTab === "primary" ? turns.length : debugEvents.length
               }
               providerUsed={selectedStage.providerUsed}
+              billing={selectedStage.billing}
               events={stageEventsQuery.data ?? []}
               runId={runId}
               stageId={selectedStageId}

apps/fabro-web/app/routes/runs.tsx

@@ -26,6 +26,7 @@ import { ciConfig, columnForRun, columnStatusDisplay, columnStatuses, deriveCiSt
 import type { CiStatus, CheckRun, CheckStatus, RunItem } from "../data/runs";
 import { EmptyState } from "../components/state";
 import { PullRequestChip } from "../components/pull-request-chip";
+import { SizeChip } from "../components/size-chip";
 import {
   summarizeBatchLifecycleAction,
 } from "../components/runs-list/batch-lifecycle";
@@ -345,7 +346,7 @@ function PrCard({
 
 // All inline footer metadata on PrCard belongs in this one row. Adding a new
 // piece as a sibling `<div>` below the card body recreates a recurring bug
-// where stats stack onto separate lines instead of sitting next to elapsed/actions.
+// where stats stack onto separate lines instead of sitting next to size/actions.
 function PrCardFooter({ pr, actions }: { pr: RunItem; actions?: string[] }) {
   const hasActions = actions != null && actions.length > 0;
   const hasStats =
@@ -354,7 +355,7 @@ function PrCardFooter({ pr, actions }: { pr: RunItem; actions?: string[] }) {
     (pr.additions != null && pr.additions !== 0) ||
     (pr.deletions != null && pr.deletions !== 0);
 
-  if (!hasStats && !hasActions && pr.elapsed == null) return null;
+  if (!hasStats && !hasActions && pr.size == null) return null;
 
   return (
     <div className="mt-3 flex items-center gap-3 font-mono text-xs">
@@ -416,9 +417,9 @@ function PrCardFooter({ pr, actions }: { pr: RunItem; actions?: string[] }) {
           ))}
         </div>
       )}
-      {pr.elapsed != null && (
-        <span className={`text-fg-muted ${hasActions ? "" : "ml-auto"}`}>
-          {pr.elapsed}
+      {pr.size != null && (
+        <span className={hasActions ? "inline-flex" : "ml-auto inline-flex"}>
+          <SizeChip size={pr.size} totalUsdMicros={pr.totalUsdMicros} />
         </span>
       )}
     </div>

apps/fabro-web/public/images/providers/modal.svg

@@ -0,0 +1,3 @@
+<svg width="24" height="24" viewBox="0 0 300 300" xmlns="http://www.w3.org/2000/svg">
+<path d="M121.683 75.25L149.997 124L91.4816 224.75C90.3128 226.757 88.155 228 85.8174 228H32.9664C31.7976 228 30.6778 227.691 29.697 227.131C28.7161 226.57 27.8906 225.758 27.3021 224.75L0.876625 179.25C-0.292208 177.243 -0.292208 174.765 0.876625 172.75L57.512 75.25C58.0923 74.2425 58.9259 73.43 59.9068 72.8694C60.8876 72.3088 62.0074 72 63.1762 72H116.027C118.365 72 120.523 73.2431 121.692 75.25H121.683ZM299.125 172.75L242.49 75.25C241.91 74.2425 241.076 73.43 240.095 72.8694C239.114 72.3088 237.995 72 236.826 72H183.975C181.637 72 179.479 73.2431 178.311 75.25L149.997 124L208.512 224.75C209.681 226.757 211.839 228 214.177 228H267.027C268.196 228 269.316 227.691 270.297 227.131C271.278 226.57 272.103 225.758 272.692 224.75L299.117 179.25C300.286 177.243 300.286 174.765 299.117 172.75H299.125Z" fill="#62DE61"/>
+</svg>

docs/internal/events.md

@@ -2116,6 +2116,7 @@ These legacy events may appear in older run logs. Current CLI backend runs do no
   "properties": {
     "pr_url": "https://github.com/org/repo/pull/42",
     "pr_number": 42,
+    "head_sha": "d34db33f",
     "draft": true
   }
 }
@@ -2125,6 +2126,7 @@ These legacy events may appear in older run logs. Current CLI backend runs do no
 |----------|------|-------------|
 | `pr_url` | string | Pull request URL |
 | `pr_number` | number | Pull request number |
+| `head_sha` | string (optional) | Verified commit SHA at the remote PR head; absent on older events |
 | `draft` | boolean | Whether the PR is a draft |
 
 ### `pull_request.linked`

docs/plans/2026-05-21-wall-and-active-time-metrics-plan.md

@@ -155,9 +155,16 @@ git diff --check
 
 - Inference time is Fabro-observed LLM request/stream elapsed time, not
   provider-reported model-only compute time.
-- LLM retry backoff, queueing outside a request/stream, human waits, steering
-  waits, and scheduler gaps are wall time but not active time.
-- Active timing is finalized-event based in v1; live active-time ticking can be
-  added later if it becomes necessary.
+- Queueing outside a request/stream, human waits, steering waits, and scheduler
+  gaps are wall time but not active time. Retry delay inside an open LLM request
+  bracket follows the executor stopwatch and counts as inference time.
+- ~~Active timing is finalized-event based in v1; live active-time ticking can
+  be added later if it becomes necessary.~~ **Superseded 2026-07-25.** It became
+  necessary: a run parked in one long agent stage reported ~12% of its wall time
+  as active, because in-flight stages contributed nothing. Stage projections now
+  accumulate inference and tool brackets from the event log and expose
+  `StageProjection::live_timing(now)`, the active-time twin of
+  `live_wall_time_ms`. Finalized values remain authoritative and still replace
+  the live estimate at terminal events. Implemented in PR #647.
 - No compatibility layer is required for existing API clients or stored run
   event data.

docs/public/administration/server-configuration.mdx

@@ -218,7 +218,7 @@ provider = "s3"
 disk_cache = true
 
 [server.slatedb.s3]
-bucket = "{{ env.SLATEDB_BUCKET }}"
+bucket = "fabro-production"
 region = "us-east-1"
 ```
 
@@ -387,8 +387,11 @@ fabro secret set GEMINI_API_KEY AI...
 | `INCEPTION_API_KEY` | Inception (Mercury) |
 | `POOLSIDE_API_KEY` | Poolside (Laguna) |
 | `OPENROUTER_API_KEY` | OpenRouter (when enabled) |
+| `MODAL_TOKEN_ID` and `MODAL_TOKEN_SECRET` | Modal (when enabled) |
 | `FIREWORKS_API_KEY` | Fireworks AI (when enabled) |
 
+Modal requires both vault tokens. Its provider definition resolves them into the `Modal-Key` and `Modal-Secret` request headers.
+
 ### Sandbox and tools
 
 These optional server integrations are vault-only:
@@ -463,7 +466,7 @@ GitHub App mode stores these secrets in the vault. `fabro install` writes them a
 
 ### Slack integration (optional)
 
-Slack credentials are server-level secrets. Add `[server.integrations.slack]` to enable one Slack connection that is shared by human interview prompts and run lifecycle notifications. `server.integrations.slack.default_channel` is an optional literal channel name used only as the default destination for interview prompts; it does not interpolate `{{ env.* }}`. Lifecycle notifications use `[run.notifications.<name>.slack].channel` in run or workflow configuration.
+Slack credentials are server-level secrets. Add `[server.integrations.slack]` to enable one Slack connection that is shared by human interview prompts and run lifecycle notifications. `server.integrations.slack.default_channel` is an optional literal channel name used only as the default destination for interview prompts; it does not interpolate. Lifecycle notifications use `[run.notifications.<name>.slack].channel` in run or workflow configuration.
 
 Fabro resolves these from the vault only. When `[server.integrations.slack]` is present and both credentials are present, startup logs `Slack integration enabled` and then the Slack Socket Mode connection status. If the Slack config table is absent or `enabled = false`, startup logs `Slack integration disabled by server configuration`. If the table is present but either credential is missing or empty, startup logs `Slack integration disabled; missing credentials` with the missing variable names.
 

docs/public/agents/hooks.mdx

@@ -28,19 +28,19 @@ POST the event context as JSON to an HTTP endpoint. Useful for webhooks, externa
 event = "run_complete"
 type = "http"
 url = "https://hooks.example.com/done"
-allowed_env_vars = ["API_KEY"]
 
 [hooks.headers]
-Authorization = "Bearer {{ env.API_KEY }}"
+X-Deployment-Environment = "{{ vars.DEPLOY_ENV }}"
 ```
 
 | Field | Description |
 |---|---|
-| `url` | The endpoint to POST to. Must use `https://` unless `tls = "off"`. Supports `{{ env.NAME }}` interpolation. |
-| `headers` | Optional HTTP headers. Values support `{{ env.NAME }}` interpolation, scoped to the names in `allowed_env_vars`. A token for any other env var fails to resolve and the hook blocks (fail-closed). |
-| `allowed_env_vars` | Allowlist of environment variable names a header may read via `{{ env.NAME }}`. Empty (the default) means no env vars may be interpolated into headers. |
+| `url` | The endpoint to POST to. Must use `https://` unless `tls = "off"`. Supports `{{ vars.NAME }}` interpolation. |
+| `headers` | Optional HTTP headers. Values support `{{ vars.NAME }}` interpolation. A token that is still unresolved when the hook fires blocks it (fail-closed), so a header is never sent half-rendered. |
 | `tls` | TLS mode: `"verify"` (default), `"no_verify"`, or `"off"`. |
 
+`{{ vars.NAME }}` is substituted when the run is created. Use variables only for non-sensitive metadata. Do not store tokens, API keys, or other credentials in variables or literal hook configuration. `{{ env.NAME }}` and `{{ secrets.NAME }}` are not available in hooks.
+
 ### Prompt
 
 A single-turn LLM call that evaluates the event context and returns an `ok`/`block` decision. The model responds with structured JSON.

docs/public/agents/mcp.mdx

@@ -149,12 +149,11 @@ Inline transport fields can interpolate values at the run boundary:
 | Syntax | Resolution time |
 |---|---|
 | `{{ vars.NAME }}` | When the server creates the run, using that run's variable snapshot |
-| `{{ env.NAME }}` | When the worker launches the MCP transport |
 | `{{ secrets.NAME }}` | When the worker launches the MCP transport, using a token secret from the server vault |
 
-Interpolation applies to stdio and sandbox commands and env values, plus HTTP URLs and headers. Variable tokens are replaced in the created run configuration. Worker-time environment and secret expressions remain in persisted configuration, while resolved secret values do not. A missing environment variable, missing secret, or non-token secret fails MCP startup instead of passing an unresolved token to the transport.
+Interpolation applies to stdio and sandbox commands and env values, plus HTTP URLs and headers. Variable tokens are replaced in the created run configuration. Secret expressions remain in persisted configuration, while resolved secret values do not. A missing or non-token secret fails MCP startup instead of passing an unresolved token to the transport. `{{ env.* }}` is unsupported and also fails before launch.
 
-Standalone `fabro exec` can resolve `{{ env.* }}` from its process environment, but it has no server vault. A `{{ secrets.* }}` reference therefore fails with an explicit error in standalone execution.
+Standalone `fabro exec` has no server vault, so a `{{ secrets.* }}` reference fails with an explicit error in standalone execution.
 
 ## Transports
 

docs/public/api-reference/fabro-api.yaml

@@ -7941,8 +7941,13 @@ components:
         model:
           type: string
           description: |
-            Catalog model ID or alias. The server selects among ready
-            providers and stores the canonical model ID.
+            Catalog model ID or alias, optionally qualified as
+            `provider:selector`. A provider-qualified selector may be a
+            canonical model ID, alias, or provider API ID. A value counts as
+            qualified only when the text before the first `:` names a known
+            provider, so model IDs containing a colon stay whole. Legacy
+            `provider/model` references remain accepted. The server stores the
+            canonical model ID.
         provider:
           $ref: "#/components/schemas/ProviderId"
           description: Optional provider pin. Provider-qualified model references remain accepted for compatibility.
@@ -8894,6 +8899,7 @@ components:
       type: string
       enum:
         - workflow_error
+        - publish_failed
         - cancelled
         - approval_denied
         - terminated
@@ -9597,6 +9603,11 @@ components:
           type: ["string", "null"]
           description: Optional contextual text shown alongside the question.
           example: Latest draft
+        review_target:
+          description: Optional validated external resource that is the primary subject of this review question.
+          oneOf:
+            - $ref: "#/components/schemas/ReviewTarget"
+            - type: "null"
 
     QuestionType:
       description: The interaction type of a human-in-the-loop question.
@@ -9951,10 +9962,9 @@ components:
             Durable identity of one execution of a parallel node, formatted as
             "{node_id}@{visit}".
         parallel_branch_id:
-          type: ["string", "null"]
-          description: >
-            Durable identity of one branch within a parallel execution,
-            formatted as "{parallel_group_id}:{index}".
+          oneOf:
+            - $ref: "#/components/schemas/ParallelBranchId"
+            - type: "null"
         session_id:
           type: ["string", "null"]
         parent_session_id:
@@ -10663,6 +10673,10 @@ components:
           items:
             $ref: "#/components/schemas/ParallelBranchResult"
           description: Ordered per-branch results produced by a parallel stage.
+        parallel_branch_id:
+          oneOf:
+            - $ref: "#/components/schemas/ParallelBranchId"
+            - type: "null"
         output:
           type: ["string", "null"]
         output_bytes:
@@ -10684,7 +10698,38 @@ components:
             - type: "null"
           description: |
             Per-attempt timing breakdown for the latest terminal attempt:
-            wall time plus the active inference/tool breakdown.
+            wall time plus the active inference/tool breakdown. Null while the
+            stage is still in flight; the live estimate is derived from
+            `live_inference_ms`, `live_tool_ms`, and any open bracket.
+        live_inference_ms:
+          type: integer
+          format: uint64
+          minimum: 0
+          default: 0
+          description: |
+            Inference time accumulated from closed brackets during the current
+            attempt. Live estimate only — the authoritative value arrives with
+            the terminal event and lands in `timing`. Excludes the currently
+            open bracket, whose span is measured from `inference.started_at`.
+          example: 78230
+        live_tool_ms:
+          type: integer
+          format: uint64
+          minimum: 0
+          default: 0
+          description: |
+            Tool time accumulated from closed tool batches during the current
+            attempt. A batch spans the first dispatched call through the
+            completion that drains the last outstanding one, so tools running
+            concurrently within a turn are counted once.
+          example: 7588
+        tool_batch:
+          oneOf:
+            - $ref: "#/components/schemas/StageToolBatchProjection"
+            - type: "null"
+          description: |
+            Open tool batch: when the batch started and which calls have not
+            yet reported completion.
         usage:
           $ref: "#/components/schemas/BilledTokenCounts"
         model:
@@ -10738,6 +10783,13 @@ components:
             Open inference bracket, if the event log contains one. Present means
             a model request was dispatched and no closing event has been seen —
             not that the model is computing right now.
+        acp_started_at:
+          type: ["string", "null"]
+          format: date-time
+          description: >
+            Start of an external ACP agent process, if one is running. ACP
+            agents do not expose Fabro's internal LLM brackets, so the process
+            lifetime supplies their live inference estimate.
         agent_control:
           $ref: "#/components/schemas/AgentControlState"
           description: Whether the agent is executing normally or waiting for steering after an interrupt.
@@ -10745,6 +10797,37 @@ components:
           $ref: "#/components/schemas/StageState"
           description: Lifecycle state of the stage projection.
 
+    StageToolBatchProjection:
+      description: >
+        One open tool batch: tool calls dispatched together that have not all
+        reported completion. `open_call_ids` is a set rather than a count so a
+        duplicated completion in a replayed log cannot drain the batch early.
+      type: object
+      required:
+        - session_id
+        - started_at
+        - open_call_ids
+      properties:
+        session_id:
+          type: string
+          description: >
+            Root agent session that dispatched the batch. Transitions are
+            gated on it so delayed events from a replaced session cannot
+            mutate the current batch.
+        started_at:
+          type: string
+          format: date-time
+          description: >
+            When the batch opened — the first dispatched call observed while no
+            other calls were outstanding.
+        open_call_ids:
+          type: array
+          minItems: 1
+          uniqueItems: true
+          items:
+            type: string
+          description: Calls dispatched but not yet completed, by tool call id.
+
     StageInferenceProjection:
       description: >
         One open inference bracket: a dispatched LLM request that has not yet
@@ -11113,6 +11196,36 @@ components:
           type: ["string", "null"]
           description: Optional untrusted model-authored option preview captured for clients.
 
+    ReviewTargetKind:
+      description: The type of resource presented for human review.
+      type: string
+      enum:
+        - document
+
+    ReviewTarget:
+      description: A validated external resource presented as the primary subject of a human review question.
+      type: object
+      required:
+        - label
+        - url
+        - kind
+      properties:
+        label:
+          type: string
+          minLength: 1
+          maxLength: 200
+          description: Human-readable link label.
+          example: Quarry review exercise
+        url:
+          type: string
+          format: uri
+          minLength: 1
+          maxLength: 2048
+          description: Absolute HTTP or HTTPS URL opened by the reviewer.
+          example: https://quarry.lithos.computer/tmp/0123456789abcdef0123456789abcdef
+        kind:
+          $ref: "#/components/schemas/ReviewTargetKind"
+
     InterviewQuestionRecord:
       description: Storage shape of an interview question recorded in the event log.
       type: object
@@ -11142,6 +11255,10 @@ components:
           format: double
         context_display:
           type: ["string", "null"]
+        review_target:
+          oneOf:
+            - $ref: "#/components/schemas/ReviewTarget"
+            - type: "null"
 
     PendingInterviewRecord:
       description: Pending interview question plus the time it entered the unresolved set.
@@ -12255,9 +12372,17 @@ components:
         observed LLM request/stream elapsed time; `tool_time_ms` is tool or
         command execution elapsed time; `active_time_ms` equals
         `inference_time_ms + tool_time_ms`.
+
+        For a terminal stage these come from the worker's own stopwatch and are
+        authoritative. For a stage still in flight they are a live estimate
+        reconstructed from the event log, and `active_time_ms` is clamped to
+        `wall_time_ms`. The estimate is replaced by the authoritative
+        breakdown when the stage reaches a terminal event.
       type: object
       required:
         - wall_time_ms
+        - inference_time_ms
+        - tool_time_ms
         - active_time_ms
       properties:
         wall_time_ms:
@@ -12289,9 +12414,16 @@ components:
         Timing rollup for an entire run. Active fields sum work across stage
         visits, so `active_time_ms` can exceed `wall_time_ms` when parallel
         branches run concurrently.
+
+        For a running run, stages still in flight contribute a live estimate
+        rather than nothing, so wall and active both advance continuously.
+        Unlike `StageTiming`, active is not clamped to wall here — concurrent
+        branches can legitimately sum past run wall time.
       type: object
       required:
         - wall_time_ms
+        - inference_time_ms
+        - tool_time_ms
         - active_time_ms
       properties:
         wall_time_ms:
@@ -12581,6 +12713,13 @@ components:
       type: string
       example: verify@2
 
+    ParallelBranchId:
+      description: >-
+        Durable identity of one branch within a parallel execution, in
+        `{parallel_group_id}:{index}` form.
+      type: string
+      example: review_fork@3:1
+
     StageState:
       description: Lifecycle projection state of a workflow stage.
       type: string
@@ -12620,6 +12759,7 @@ components:
         - status
         - node_id
         - visit
+        - billing
       properties:
         id:
           $ref: "#/components/schemas/StageId"
@@ -12669,6 +12809,22 @@ components:
             StageId of the prior post-checkpoint execution superseded by this
             replay after the run was resumed.
           example: verify@1
+        parallel_group_id:
+          allOf:
+            - $ref: "#/components/schemas/StageId"
+          description: >-
+            Exact StageId of the parent parallel execution. Clients can compare
+            this directly with the `id` of a parallel stage. Omitted for stages
+            that are not parallel branches.
+          example: review_fork@1
+        parallel_branch_index:
+          type: integer
+          format: uint32
+          minimum: 0
+          description: >-
+            Zero-based outgoing-edge index within the parent parallel
+            execution. Omitted for stages that are not parallel branches.
+          example: 1
         provider_used:
           oneOf:
             - $ref: "#/components/schemas/StageModelUsage"
@@ -12679,6 +12835,15 @@ components:
           format: date-time
           description: Wall-clock time the latest attempt of this stage started, if known.
           example: "2026-04-29T12:34:56Z"
+        billing:
+          $ref: "#/components/schemas/BilledTokenCounts"
+          description: >-
+            Token counts for this stage execution alone. `total_usd_micros` is
+            the provider-reported cost when there is one, otherwise the server
+            catalog's price for these tokens — the same pricing the
+            `/runs/{id}/billing` rows use. All-zero counts mean the stage made
+            no model calls. Unlike the billing rows, which sum every visit of a
+            node, this covers only this visit.
 
     # ── File Diff Schemas ──────────────────────────────────────────────
 
@@ -13972,7 +14137,7 @@ components:
           $ref: "#/components/schemas/RunNamespace"
 
     InterpString:
-      description: Resolved config string that may contain env interpolation tokens.
+      description: Config string that can contain typed interpolation tokens.
       type: string
 
     StringMap:
@@ -14130,6 +14295,16 @@ components:
 
     ModelRef:
       type: string
+      description: |
+        A fallback model reference. Bare values name a provider, canonical
+        model ID, or alias. Provider-qualified values use
+        `provider:selector`; the selector may be a canonical model ID, alias,
+        or provider API ID and may contain `/` or additional colons. A value
+        is treated as qualified only when the text before the first `:` names
+        a known provider, so model IDs that contain a colon — ollama
+        `name:tag` values, Bedrock inference-profile IDs — stay whole. Legacy
+        `provider/model` references remain accepted.
+      example: openrouter:moonshotai/kimi-k3
 
     RunModelSettings:
       type: object
@@ -14180,7 +14355,7 @@ components:
         script-vs-argv distinction via the `type` discriminator: a `script`
         is a raw shell snippet kept verbatim, while a `command` is an argv
         whose elements are shell-quoted and joined at the run boundary (after
-        `{{ env.* }}` resolution) so an interpolated value cannot inject shell
+        `{{ secrets.* }}` resolution) so an interpolated value cannot inject shell
         syntax. Optional per-step `env` is shared by both shapes.
       type: object
       required: [type]
@@ -14585,17 +14760,9 @@ components:
             - type: "null"
           description: >-
             Optional HTTP headers for an http hook. Values support
-            `{{ env.NAME }}` interpolation, scoped to the names listed in
-            `allowed_env_vars`; a token for any other env var fails to resolve
-            and the hook blocks (fail-closed).
-        allowed_env_vars:
-          type: array
-          items:
-            type: string
-          description: >-
-            Allowlist of environment variable names that an http hook header may
-            read via `{{ env.NAME }}`. An empty list (the default) permits no env
-            vars in headers.
+            `{{ vars.NAME }}` interpolation, substituted when the run is
+            created; a token left unresolved at fire time blocks the hook
+            (fail-closed).
         tls:
           $ref: "#/components/schemas/TlsMode"
         prompt:

docs/public/core-concepts/models.mdx

@@ -84,7 +84,7 @@ aliases = ["gateway"]
 credentials = ["env:ACME_GATEWAY_API_KEY", "vault:ACME_GATEWAY_API_KEY"]
 
 [llm.providers.proxy.extra_headers]
-x-portkey-api-key = "{{ env.PORTKEY_API_KEY }}"
+x-portkey-api-key = "{{ secrets.PORTKEY_API_KEY }}"
 x-portkey-config = "@bedrock-prod"
 
 [llm.providers.proxy.models."team-code-large"]
@@ -153,7 +153,7 @@ Historical built-in catalog keys that exposed provider API IDs remain accepted a
 
 Model roles are separate: `default = true` controls normal model selection for workflow execution, while `small_default = true` marks the provider's small/cheap utility model for metadata tasks such as generated run titles. If a provider has no small default, Fabro falls back to that provider's normal default.
 
-Provider auth is declared in `[llm.providers.<id>.auth]` with ordered `env:<NAME>` or `vault:<NAME>` refs. The primary auth header defaults to `bearer`; override with `header = { custom = "Header-Name" }` for providers like Anthropic that use `x-api-key`. Omit the `[llm.providers.<id>.auth]` block entirely for providers that need no API key (e.g. Ollama). Custom headers for any provider — including providers that need only interpolation headers and no API-key auth — go in `extra_headers` as literal text, `{{ env.NAME }}` tokens, or `{{ secrets.NAME }}` tokens. Put credentials in secrets and reference them with `{{ secrets.NAME }}` instead of a bare literal.
+Provider auth is declared in `[llm.providers.<id>.auth]` with ordered `env:<NAME>` or `vault:<NAME>` refs. The primary auth header defaults to `bearer`; override with `header = { custom = "Header-Name" }` for providers like Anthropic that use `x-api-key`. Omit the `[llm.providers.<id>.auth]` block entirely for providers that need no API key (e.g. Ollama). Custom headers for any provider — including providers that need only interpolation headers and no API-key auth — go in `extra_headers` as literal text or `{{ secrets.NAME }}` tokens. Put credentials in secrets and reference them with `{{ secrets.NAME }}` instead of a bare literal.
 
 Workflow runs also add `x-session-id: <run-id>` to every LLM request so compatible gateways can group requests from the same run. An explicitly configured `x-session-id` in provider `extra_headers` takes precedence.
 
@@ -180,6 +180,23 @@ Fabro ships an [OpenRouter](/integrations/openrouter) provider definition with a
 enabled = true
 ```
 
+### Modal
+
+Fabro ships a [Modal](/integrations/modal) provider definition for Kimi K3, disabled by default. Modal assigns the endpoint URL and authenticates requests with a two-part proxy token:
+
+```toml title="settings.toml"
+[llm.providers.modal]
+enabled = true
+base_url = "https://your-endpoint.modal.run/v1"
+```
+
+Store both token values in the Fabro server vault:
+
+```bash
+fabro secret set MODAL_TOKEN_ID wk-...
+fabro secret set MODAL_TOKEN_SECRET ws-...
+```
+
 ### Amazon Bedrock
 
 Fabro ships an [Amazon Bedrock](/integrations/bedrock) provider definition with a curated multi-vendor catalog over Bedrock's Converse API, disabled by default. Enable it and authenticate with a Bedrock API key or AWS SigV4 credentials:
@@ -277,7 +294,7 @@ Then launch with:
 fabro run run.toml
 ```
 
-The `fallbacks` array is optional. Each entry may be a bare provider token (like `"gemini"`), a bare model alias (like `"gpt-5.4"`), or a qualified `"provider/model"` reference. Fabro tries them in order when the primary provider is unavailable. In this field, qualified references keep their established provider-pin meaning: `"openai/gpt-5.6-sol"` selects the direct OpenAI offering.
+The `fallbacks` array is optional. Each entry may be a bare provider token (like `"gemini"`), a bare model ID or alias (like `"gpt-terra"`), or a qualified `"provider:selector"` reference. A qualified selector may be the provider's canonical model ID, alias, or API ID, including API IDs with slashes such as `"openrouter:moonshotai/kimi-k3"`. Fabro tries entries in order when the primary provider is unavailable, and qualified references remain provider pins. Legacy `provider/model` references remain accepted for compatibility.
 
 <Note>
 The precedence order is: node-level stylesheet > run config TOML > CLI flags > server defaults. More specific settings always win.

docs/public/docs.json

@@ -98,6 +98,7 @@
               "integrations/bedrock",
               "integrations/poolside",
               "integrations/openrouter",
+              "integrations/modal",
               "integrations/fireworks",
               "integrations/slack",
               "integrations/brave-search"

docs/public/execution/context.mdx

@@ -40,6 +40,11 @@ Each handler type writes specific keys into the context after execution:
 
 Agents can also emit arbitrary context updates by including a JSON object with a `context_updates` field in their response. See [Transitions](/workflows/transitions#agent-transitions).
 
+The `review_target` key has an optional typed convention for human review
+workflows. A human gate with `review_target=true` reads this exact flat key and
+presents its document URL as the primary question link. See
+[Review targets](/workflows/human-in-the-loop#review-targets).
+
 ### Command nodes
 
 | Key | Value |

docs/public/execution/environments.mdx

@@ -152,16 +152,16 @@ preserve = true
 
 ## Environment value interpolation
 
-Environment `env` values can mix literal text with `{{ vars.NAME }}`, `{{ env.NAME }}`, and `{{ secrets.NAME }}` tokens:
+Environment `env` values can mix literal text with `{{ vars.NAME }}` and `{{ secrets.NAME }}` tokens:
 
 ```toml title="workflow.toml"
 [environments.fabro-dev.env]
 DEPLOY_ENV = "{{ vars.DEPLOY_ENV }}"
-SERVICE_URL = "https://api.{{ env.REGION }}.example.com"
+SERVICE_URL = "https://api.{{ vars.REGION }}.example.com"
 SERVICE_TOKEN = "{{ secrets.SERVICE_TOKEN }}"
 ```
 
-Server-managed variables resolve when the run is created. Worker environment variables and token secrets resolve immediately before the sandbox starts, so resolved secret values are not persisted in the run definition. A missing or non-token secret fails closed. For backward compatibility, a value containing only missing `{{ env.* }}` references is passed through in source form.
+Server-managed variables resolve when the run is created. Token secrets resolve immediately before the sandbox starts, so resolved secret values are not persisted in the run definition. A missing or non-token secret fails closed, as does any `{{ env.* }}` reference: the process environment is not a configuration source.
 
 ## Selecting an environment from the CLI
 

docs/public/execution/failures.mdx

@@ -124,10 +124,10 @@ fallbacks = ["gemini", "openai"]
 When Anthropic fails, Fabro tries Gemini first, then OpenAI. Fallback resolution is provider-aware:
 
 - A bare provider token such as `"gemini"` selects that provider's closest compatible model.
-- A qualified selector such as `"openrouter/gpt-56-sol"` resolves only within that provider.
+- A qualified selector such as `"openrouter:gpt-56-sol"` resolves only within that provider. The selector may be a canonical model ID, alias, or provider API ID such as `"openrouter:moonshotai/kimi-k3"`.
 - A bare model slug or alias considers ready providers and uses provider priority.
 
-Qualified fallback references always remain provider pins, including strings that were historical built-in API IDs. For example, `"openai/gpt-5.6-sol"` pins the direct OpenAI offering.
+Qualified fallback references always remain provider pins. For example, `"openai:gpt-5.6-sol"` pins the direct OpenAI offering. Legacy `provider/model` fallback references remain accepted for compatibility.
 
 The primary provider and model were already resolved and persisted when the run was created; resuming does not re-run primary selection. Fallbacks are only considered after an eligible runtime failure.
 

docs/public/execution/run-configuration.mdx

@@ -79,7 +79,7 @@ memory = "8GB"
 disk = "20GB"
 
 [environments.cloud.env]
-API_KEY = "{{ env.MY_API_KEY }}"
+API_KEY = "{{ secrets.MY_API_KEY }}"
 NODE_ENV = "production"
 
 [run.integrations.github.permissions]
@@ -140,10 +140,24 @@ name = "claude-sonnet-4-5"
 |---|---|
 | `name` | Canonical model slug or alias (e.g. `claude-sonnet-4-5`, `opus`, `gemini-pro`). See [Models](/core-concepts/models). |
 | `provider` | Optional provider pin. When omitted, Fabro selects among ready offerings by provider priority. When present, an unavailable provider is an error rather than permission to switch. |
-| `fallbacks` | Ordered list of model references to try when the primary is unavailable. Entries can be bare provider tokens (`"openai"`), bare model aliases, or qualified `"provider/model"` references. |
+| `fallbacks` | Ordered list of model references to try when the primary is unavailable. Entries can be bare provider tokens (`"openai"`), bare model IDs or aliases, or qualified `"provider:selector"` references. |
 
 Provider values are catalog provider ID strings. Built-in IDs like `anthropic` and `openai` work, and settings-defined IDs like `proxy` work after they are added under `[llm.providers.<id>]`.
 
+For a qualified fallback, the selector may be that provider's canonical model ID, alias, or API ID. Fabro splits on the first `:` when the part before it names a known provider, so provider API IDs may contain `/` or additional colons:
+
+```toml title="run.toml"
+[run.model]
+fallbacks = [
+  "openrouter:kimi-k3",
+  "gpt-terra",
+]
+```
+
+The first entry could equivalently be written as `"openrouter:moonshotai/kimi-k3"` using OpenRouter's API ID; both forms resolve to its canonical `kimi-k3` offering. The unqualified `gpt-terra` alias uses normal ready-provider priority selection. Legacy `provider/model` fallback references remain accepted but are normalized to `provider:model`.
+
+A colon alone does not make a reference qualified. Many model IDs contain one — ollama `name:tag` values, Bedrock inference-profile IDs and ARNs — so Fabro treats the reference as qualified only when the text before the first `:` names a known provider. `"llama3:8b"` stays a single model ID, while `"ollama:llama3:8b"` pins the `ollama` provider and passes `llama3:8b` as the selector.
+
 At run creation, Fabro resolves the primary selector and every node selector against the ready-provider snapshot. It persists the selected canonical model slug and provider, so resuming the run does not choose a different provider just because credentials or priorities changed. The configured fallback chain remains available for failures that occur while the materialized run is executing.
 
 Historical built-in provider API IDs are accepted for compatibility and normalize before this selection. For example, `name = "openai/gpt-5.6-sol"` is treated as the canonical `gpt-5.6-sol` selector; omit `provider` to use readiness and priority, or set `provider` separately to pin an offering.
@@ -192,13 +206,13 @@ env = { NPM_TOKEN = "{{ secrets.NPM_TOKEN }}" }
 
 | Field | Description |
 |---|---|
-| `script` | Bash source, evaluated by the sandbox's non-login Bash (`bash -c`). Supports `{{ vars.* }}`, `{{ env.* }}`, and `{{ secrets.* }}` interpolation. |
+| `script` | Bash source, evaluated by the sandbox's non-login Bash (`bash -c`). Supports `{{ vars.* }}` and `{{ secrets.* }}` interpolation. |
 | `command` | Argv-style command, mutually exclusive with `script`. Each resolved element is shell-quoted as one argument. |
 | `env` | Additional environment variables for this step. Values support the same interpolation as `script` and `command`. |
 
 Each step must exit with status 0. If any step fails, the run aborts before the workflow starts. Prepare steps replace across layers — the higher-precedence layer wins wholesale.
 
-Fabro substitutes `{{ vars.* }}` when the server creates the run, then resolves `{{ env.* }}` from the worker process and `{{ secrets.* }}` from token entries in the server vault immediately before the worker executes the steps. Worker-time environment and secret expressions remain in the persisted run definition; resolved secret values are not persisted. A missing environment variable, missing secret, or non-token secret aborts startup with the affected step and token named in the error.
+Fabro substitutes `{{ vars.* }}` when the server creates the run, then resolves `{{ secrets.* }}` from token entries in the server vault immediately before the worker executes the steps. Secret expressions remain in the persisted run definition; resolved secret values are not persisted. A missing or non-token secret aborts startup with the affected step and token named in the error.
 
 ### `[run.clone]`
 
@@ -295,13 +309,13 @@ When `provider = "local"`, Fabro runs directly in the resolved working
 directory. If you want local isolation, create or enter a separate clone or Git
 worktree yourself.
 
-Environment variable values can combine literal text with server variables, worker environment variables, and token secrets:
+Environment variable values can combine literal text with server variables and token secrets:
 
 ```toml title="run.toml"
 [environments.ci.env]
 API_KEY = "{{ secrets.SERVICE_API_KEY }}"
 NODE_ENV = "production"
-SERVICE_URL = "https://api.{{ env.REGION }}.example.com"
+SERVICE_URL = "https://api.{{ vars.REGION }}.example.com"
 RELEASE_CHANNEL = "{{ vars.RELEASE_CHANNEL }}"
 ```
 
@@ -309,11 +323,10 @@ RELEASE_CHANNEL = "{{ vars.RELEASE_CHANNEL }}"
 |---|---|
 | `"literal"` | Static value passed as-is |
 | `"{{ vars.NAME }}"` | Server-managed variable substituted when the run is created |
-| `"{{ env.VARNAME }}"` | Worker process environment value resolved when the run starts |
 | `"{{ secrets.NAME }}"` | Token secret resolved from the server vault when the run starts |
-| `"prefix-{{ env.X }}-suffix"` | Substring interpolation; multiple supported tokens per string are allowed |
+| `"prefix-{{ vars.X }}-suffix"` | Substring interpolation; multiple supported tokens per string are allowed |
 
-Missing or non-token secret references fail closed before sandbox startup. For backward compatibility, an environment value that references only a missing `{{ env.* }}` value is passed through in source form; use preflight or prepare-step interpolation when an absent worker variable must be a hard error.
+Missing or non-token secret references fail closed before sandbox startup. `{{ env.* }}` is not supported: the process environment is not a configuration source. Use `{{ vars.NAME }}` for a non-sensitive value or `{{ secrets.NAME }}` for a credential.
 
 ### `[run.integrations.github.permissions]`
 
@@ -349,13 +362,13 @@ channel = "#deploys"
 | `enabled` | Enables this route. Defaults to `false`. |
 | `provider` | Notification provider. Use `"slack"` for Slack lifecycle notifications. Other provider names may be parsed but are not delivered by the server yet. |
 | `events` | Raw Fabro event names that trigger this route, such as `run.started`, `run.completed`, and `run.failed`. |
-| `[run.notifications.<name>.slack].channel` | Required for Slack lifecycle notifications. Literal channel names and `{{ env.VAR }}` interpolation are supported. |
+| `[run.notifications.<name>.slack].channel` | Required for Slack lifecycle notifications. Literal channel names and `{{ vars.NAME }}` interpolation are supported. |
 
 Each enabled Slack route posts once for each matching lifecycle event. Messages include the run ID, an Open in Fabro link when available, workflow label, terminal result, duration, and pull request details when those are already present in the run event stream.
 
 `run.failed` is emitted only when the run terminally fails. A failed stage that routes onward to a normal completion path produces `run.completed`, not `run.failed`.
 
-If a Slack route's channel is missing, empty, or references an unresolved environment variable, Fabro logs a warning and skips that route. Delivery failures are logged and never fail or alter the run.
+If a Slack route's channel is missing, empty, or contains an unsupported interpolation token, Fabro logs a warning and skips that route. Delivery failures are logged and never fail or alter the run.
 
 ### `[run.checkpoint]`
 
@@ -489,7 +502,7 @@ id = "sentry"
 | `startup_timeout` | Max duration for server startup + MCP handshake (e.g. `"10s"`, `"1m"`). | `"10s"` |
 | `tool_timeout` | Max duration for a single tool call. | `"60s"` |
 
-Inline transport commands, URLs, env values, and headers support `{{ vars.* }}`, `{{ env.* }}`, and `{{ secrets.* }}` interpolation. As with prepare steps, server variables resolve at run creation and worker env/token secrets resolve at launch; missing values fail closed. See [MCP runtime interpolation](/agents/mcp#runtime-interpolation) for the standalone `fabro exec` difference.
+Inline transport commands, URLs, env values, and headers support `{{ vars.* }}` and `{{ secrets.* }}` interpolation. As with prepare steps, server variables resolve at run creation and token secrets resolve at launch; missing values fail closed. See [MCP runtime interpolation](/agents/mcp#runtime-interpolation) for the standalone `fabro exec` difference.
 
 The `sandbox` transport runs the MCP server inside the workflow's sandbox. This is useful for tools that need access to the sandbox environment, such as browser automation with Playwright. See [MCP](/agents/mcp#sandbox) for details.
 

docs/public/integrations/github.mdx

@@ -55,6 +55,7 @@ When you choose the GitHub App strategy, the CLI opens GitHub with a pre-filled
    | Permission | Level | Purpose |
    |---|---|---|
    | Contents | Write | Clone repos, push run branches and checkpoints |
+   | Workflows | Write | Push changes under `.github/workflows/` |
    | Metadata | Read | Look up repository installation status |
    | Pull requests | Write | Create and update PRs from workflows |
    | Checks | Write | Report workflow status on commits |
@@ -219,7 +220,7 @@ When a workflow runs in a remote sandbox (Daytona or Docker), Fabro clones the c
 2. SSH URLs (e.g. `git@github.com:owner/repo.git`) are converted to HTTPS
 3. Fabro signs a short-lived JWT using the App ID and private key (RS256, 10-minute validity)
 4. Using the JWT, Fabro looks up the GitHub App installation for the repository (`GET /repos/\{owner\}/\{repo\}/installation`)
-5. Fabro requests a scoped Installation Access Token with `contents: write` permission on the specific repository
+5. Fabro requests a scoped Installation Access Token with `contents: write` and `workflows: write` permissions on the specific repository
 6. The sandbox clones via HTTPS using `x-access-token` as the username and the token as the password
 
 For public repositories, the clone works without credentials. The token is still generated because it's needed for pushing checkpoints.
@@ -248,7 +249,9 @@ The upper bound on what Fabro will mint is whatever permissions the GitHub App i
 
 ### Checkpoint pushing
 
-After each workflow stage, Fabro [checkpoints](/execution/checkpoints) by pushing the run branch and metadata branch to origin. Inside remote sandboxes, the git remote URL is configured with the Installation Access Token for authenticated pushing.
+After each workflow stage, Fabro [checkpoints](/execution/checkpoints) by pushing the run branch and metadata branch to origin. Before a successful run becomes terminal, the publish stage pushes the final commit again and treats failure as a run failure. Inside remote sandboxes, the git remote URL is configured with the Installation Access Token for authenticated pushing.
+
+When pull request creation is enabled, Fabro then checks that GitHub reports the run branch at the exact final commit before opening the PR. A failed final push, branch check, or PR creation marks the run as failed with `publish_failed`; the terminal run event is emitted only after this step finishes.
 
 For long-running workflows, Fabro refreshes the token before each push since Installation Access Tokens are short-lived (typically 1 hour).
 

docs/public/integrations/modal.mdx

@@ -0,0 +1,173 @@
+---
+title: "Modal"
+description: "Run Kimi K3 through Modal's OpenAI-compatible inference endpoints"
+---
+
+[Modal](https://modal.com/) serves Kimi K3 through an OpenAI-compatible Shared API and through dedicated Auto Endpoints. Fabro ships a disabled `modal` provider entry for Kimi K3. Enable it after Modal gives you an endpoint URL.
+
+## Prerequisites
+
+- A [Modal account](https://modal.com/signup)
+- A [Kimi K3 Shared API or Auto Endpoint](https://modal.com/library/moonshot/kimi-k3)
+- A Modal proxy-token pair
+
+## Create or select an endpoint
+
+Use the Kimi K3 Shared API from the Modal model library, or create a dedicated Auto Endpoint:
+
+```bash
+modal endpoint create --model moonshotai/Kimi-K3
+```
+
+Find the endpoint URL in the Modal dashboard or with `modal endpoint list`. Modal serves its OpenAI-compatible API under `/v1`.
+
+## Create a proxy token
+
+Modal endpoints are authenticated with two headers. Create a proxy-token pair:
+
+```bash
+modal workspace proxy-tokens create
+```
+
+The command prints a token ID that starts with `wk-` and a secret that starts with `ws-`. Modal shows the secret only once, so save both values immediately.
+
+If your Modal workspace uses RBAC, allow the token in the endpoint's environment:
+
+```bash
+modal workspace proxy-tokens allow wk-... main
+```
+
+## Enable the provider
+
+Add the provider override to the settings file used by the Fabro server. Include `/v1` in the endpoint URL and omit a trailing slash.
+
+```toml title="settings.toml"
+_version = 1
+
+[llm.providers.modal]
+enabled = true
+base_url = "https://your-endpoint.modal.run/v1"
+```
+
+The endpoint URL is not built into Fabro because Modal assigns it to your Shared API or Auto Endpoint.
+
+## Configure credentials
+
+Store both proxy-token values in the target Fabro server vault:
+
+```bash
+fabro secret set MODAL_TOKEN_ID wk-...
+fabro secret set MODAL_TOKEN_SECRET ws-...
+
+# For a non-default remote server:
+fabro secret --server https://your-fabro.example set MODAL_TOKEN_ID wk-...
+fabro secret --server https://your-fabro.example set MODAL_TOKEN_SECRET ws-...
+```
+
+<Note>
+  `fabro provider login --provider modal` is not supported in this release because that command accepts one credential value. Use the two `fabro secret set` commands above.
+</Note>
+
+Modal does not use a bearer API key for these endpoints. Fabro sends the vault values as `Modal-Key` and `Modal-Secret` headers and does not send an `Authorization` header.
+
+## Included model
+
+| Fabro model slug | Modal API ID | Context | Input / cached input / output | Estimated speed |
+| --- | --- | --- | --- | --- |
+| `kimi-k3` | `moonshotai/Kimi-K3` | 1M tokens | $3.00 / $0.30 / $15.00 per MTok | 460 tok/s |
+
+The catalog marks Kimi K3 as supporting tools, vision, reasoning, and prompt caching. Modal's model ID is case-sensitive.
+
+## Use Kimi K3
+
+```bash
+fabro model list --provider modal
+fabro model test --provider modal --model kimi-k3
+fabro run workflow.fabro --provider modal --model kimi-k3
+```
+
+When targeting a non-default remote server, pass the same `--server` value:
+
+```bash
+fabro model list --server https://your-fabro.example --provider modal
+fabro model test --server https://your-fabro.example --provider modal --model kimi-k3
+```
+
+In workflow stylesheets:
+
+```dot title="workflow.fabro"
+digraph Example {
+    graph [
+        model_stylesheet="
+            * { model: modal/kimi-k3; }
+        "
+    ]
+
+    start [shape=Mdiamond, label="Start"]
+    work  [label="Work", prompt="Use Kimi K3 through Modal."]
+    exit  [shape=Msquare, label="Exit"]
+
+    start -> work -> exit
+}
+```
+
+## Direct SDK environment credentials
+
+The built-in Modal provider reads its two headers from the Fabro vault. `EnvCredentialSource` does not configure Modal automatically because Modal uses two headers instead of one API-key reference.
+
+For direct SDK use, enable Modal and set its endpoint URL in the catalog:
+
+```toml title="settings.toml"
+[llm.providers.modal]
+enabled = true
+base_url = "https://your-endpoint.modal.run/v1"
+```
+
+Then read both environment variables explicitly and create a typed credential after constructing `catalog` from those settings:
+
+```rust
+use fabro_auth::ApiCredential;
+use fabro_llm::client::Client;
+use std::collections::HashMap;
+
+let credential = ApiCredential::with_extra_headers(
+    "modal",
+    HashMap::from([
+        ("Modal-Key".to_string(), std::env::var("MODAL_TOKEN_ID")?),
+        (
+            "Modal-Secret".to_string(),
+            std::env::var("MODAL_TOKEN_SECRET")?,
+        ),
+    ]),
+);
+let client = Client::from_credentials(vec![credential], catalog).await?;
+```
+
+## Costs
+
+Fabro estimates Shared API costs from Modal's published Kimi K3 prices. Completion and reasoning tokens use the output rate. Modal responses do not include an authoritative charge, so Fabro reports `cost_source = "estimated"`.
+
+Dedicated Auto Endpoints use Modal compute billing instead of the Shared API token prices. The Fabro estimate does not represent that compute bill.
+
+## Troubleshooting
+
+**"provider 'modal' uses openai_compatible adapter but does not configure base_url"** — Add the Modal endpoint URL under `[llm.providers.modal]`. Include `/v1`.
+
+**Modal is not configured** — Set both `MODAL_TOKEN_ID` and `MODAL_TOKEN_SECRET` in the target server vault. One value is not sufficient.
+
+**401 or 403** — Confirm that the token pair belongs to the correct Modal workspace and environment. If the workspace uses RBAC, allow the token in that environment.
+
+**404** — Confirm that the base URL is the endpoint URL followed by `/v1`, with no trailing slash.
+
+**Unknown model** — The built-in API ID is exactly `moonshotai/Kimi-K3`. Run `fabro model test --provider modal --model kimi-k3` to test the configured offering.
+
+## Further reading
+
+<Columns cols={2}>
+  <Card title="Modal Kimi K3" icon="microchip" href="https://modal.com/library/moonshot/kimi-k3">
+    Shared API prices, model specifications, and Auto Endpoint setup.
+  </Card>
+  <Card title="Modal endpoint authentication" icon="key" href="https://modal.com/docs/guide/endpoints#proxy-tokens">
+    Proxy-token headers and endpoint calling conventions.
+  </Card>
+</Columns>

docs/public/integrations/slack.mdx

@@ -117,7 +117,7 @@ enabled = true
 default_channel = "#fabro-reviews"
 ```
 
-`default_channel` is a literal channel name used only for human-in-the-loop interview prompts. Fabro does not interpolate `{{ env.* }}` in this server setting. Run lifecycle notifications use per-run or per-workflow `[run.notifications]` routes instead, whose channel values can use environment interpolation.
+`default_channel` is a literal channel name used only for human-in-the-loop interview prompts; Fabro does not interpolate it. Run lifecycle notifications use per-run or per-workflow `[run.notifications]` routes instead, whose channel values support `{{ vars.NAME }}` interpolation.
 
 ### 8. Invite the bot
 
@@ -182,7 +182,7 @@ Each enabled route posts one message when a matching event is emitted. Lifecycle
 
 `run.failed` is a terminal run event. A stage can fail and still be followed by another graph edge that lets the run complete; in that case a route listening for `run.completed` fires, not `run.failed`.
 
-The route-level Slack channel is required for lifecycle notifications. The channel may be a literal (`"#deploys"`) or an environment interpolation (`"{{ env.DEPLOYS_SLACK_CHANNEL }}"`). If the channel is missing, empty, or cannot be resolved, Fabro logs a warning and skips that route without affecting the run or other notification routes.
+The route-level Slack channel is required for lifecycle notifications. The channel may be a literal (`"#deploys"`) or a server variable (`"{{ vars.DEPLOYS_SLACK_CHANNEL }}"`). If the channel is missing, empty, or cannot be resolved, Fabro logs a warning and skips that route without affecting the run or other notification routes.
 
 Lifecycle notifications are one-way and fire-and-forget. They never accept answers, register reply threads, update prior messages, or interact with interview state.
 

docs/public/reference/dot-language.mdx

@@ -113,7 +113,7 @@ plan [label="Plan", prompt="Create an implementation plan."]
 
 **Node identifiers** must start with a letter or underscore, followed by letters, digits, or underscores (e.g. `run_tests`, `gate_1`, `_private`).
 
-Nodes referenced in edges are auto-created if not explicitly declared.
+Every node used by an edge needs its own declaration. Validation fails when an edge names a node the workflow never declares, because that is nearly always a typo or a rename that missed an edge. The declaration can come before or after the edges that use it, and it can live in a subgraph.
 
 ### Edge declarations
 
@@ -285,6 +285,7 @@ the target's fan-in node without executing the unparameterized target.
 | Attribute | Type | Description |
 |---|---|---|
 | `question_type` | String | Optional interview question type override: `yes_no`, `confirmation`, `multiple_choice`, `multi_select`, or `freeform`. Defaults to `freeform` when the gate only has a freeform edge; otherwise defaults to `multiple_choice`. |
+| `review_target` | Boolean | When `true`, read and validate the typed `review_target` context value, then present it as the primary link in the question. Fabro generates the question text, so the node's `label` is not used. See [Review targets](/workflows/human-in-the-loop#review-targets). |
 | `human.default_choice` | String | Target node to use when the question times out. |
 
 ### Manager loop (sub-workflow) nodes

docs/public/reference/sdk.mdx

@@ -375,6 +375,34 @@ For env-backed usage, `EnvCredentialSource` checks for API key environment varia
 
 The first provider registered becomes the default. Provider base URLs come from the model catalog. For vault-backed usage inside Fabro, use `fabro_auth::VaultCredentialSource` instead.
 
+The built-in Modal definition reads two proxy-token headers from the vault, so `EnvCredentialSource` does not configure it automatically. For direct SDK use, enable Modal and set its endpoint URL in the catalog:
+
+```toml
+[llm.providers.modal]
+enabled = true
+base_url = "https://your-endpoint.modal.run/v1"
+```
+
+Then read the two environment variables explicitly and create a typed credential after constructing `catalog` from those settings:
+
+```rust
+use fabro_auth::ApiCredential;
+use fabro_llm::client::Client;
+use std::collections::HashMap;
+
+let credential = ApiCredential::with_extra_headers(
+    "modal",
+    HashMap::from([
+        ("Modal-Key".to_string(), std::env::var("MODAL_TOKEN_ID")?),
+        (
+            "Modal-Secret".to_string(),
+            std::env::var("MODAL_TOKEN_SECRET")?,
+        ),
+    ]),
+);
+let client = Client::from_credentials(vec![credential], catalog).await?;
+```
+
 #### Creating manually
 
 ```rust

docs/public/reference/user-configuration.mdx

@@ -94,7 +94,7 @@ aliases = ["gateway"]
 credentials = ["env:ACME_GATEWAY_API_KEY", "vault:ACME_GATEWAY_API_KEY"]
 
 [llm.providers.proxy.extra_headers]
-x-portkey-api-key = "{{ env.PORTKEY_API_KEY }}"
+x-portkey-api-key = "{{ secrets.PORTKEY_API_KEY }}"
 x-portkey-config = "@bedrock-prod"
 
 [llm.providers.proxy.models."team-code-large"]
@@ -184,7 +184,7 @@ aliases = ["gateway"]
 credentials = ["env:ACME_GATEWAY_API_KEY", "vault:ACME_GATEWAY_API_KEY"]
 
 [llm.providers.proxy.extra_headers]
-x-portkey-api-key = "{{ env.PORTKEY_API_KEY }}"
+x-portkey-api-key = "{{ secrets.portkey_api_key }}"
 x-portkey-config = "@bedrock-prod"
 x-team-secret = "{{ secrets.gateway_team_secret }}"
 ```
@@ -199,7 +199,7 @@ x-team-secret = "{{ secrets.gateway_team_secret }}"
 | `auth` | table | omitted | API-key auth config. Omit the table entirely for providers that need no API key; any `extra_headers` are still attached. |
 | `auth.credentials` | array<string> | required when `auth` present | Ordered credential refs. Accepted forms are `vault:<NAME>`, `env:<NAME>`, and `aws_sigv4` (sign requests from the AWS default credential chain — Bedrock). Literal secret strings are rejected. |
 | `auth.header` | `"bearer"` or `{ custom = "Header-Name" }` | `"bearer"` | Primary API-key header policy. Omit when the provider uses a standard bearer token. |
-| `extra_headers` | table | `{}` | Additional headers attached to provider requests. Values are interpolation strings: literal text, an `{{ env.NAME }}` token, or a `{{ secrets.NAME }}` token. Put credentials in a secret and reference them with a `{{ secrets.NAME }}` token, not a bare literal. |
+| `extra_headers` | table | `{}` | Additional headers attached to provider requests. Values are literal text or `{{ secrets.NAME }}` interpolation strings. Put credentials in a secret and reference them with a token, not a bare literal. |
 | `priority` | integer | `0` | Higher-priority ready providers win unqualified model and default selection; ties use canonical provider ID. |
 | `enabled` | boolean | `true` | Set `false` to disable a provider after lower-precedence layers define it. |
 | `aliases` | array<string> | `[]` | Additional provider names accepted by model routing and fallback config. |
@@ -381,12 +381,12 @@ permissions = "read-write"
 [run.model]
 provider = "anthropic"
 name = "claude-sonnet-4-5"
-fallbacks = ["openai", "gpt-5.4"]
+fallbacks = ["openrouter:kimi-k3", "gpt-terra"]
 ```
 
 | Key | Type / values | Default | Description |
 |---|---|---|---|
-| `fallbacks` | array<string> | [] | Ordered list of fallback model references. Supports `...` splice marker<br />at layering time — see [`super::splice_array`]. |
+| `fallbacks` | array<string> | [] | Ordered fallback references: bare providers, bare model IDs or aliases,<br />or provider-qualified `provider:selector` values. A qualified selector<br />may be a model ID, alias, or provider API ID. Legacy `provider/model`<br />values remain accepted. Supports the `...` splice marker at layering<br />time — see [`super::splice_array`]. |
 | `name` | string | None | Model name for workflow runs. |
 | `provider` | string | None | Provider name for workflow model selection. |
 

docs/public/workflows/human-in-the-loop.mdx

@@ -60,6 +60,68 @@ confirm -> exit [label="[N] No"]
 
 Supported values are `yes_no`, `confirmation`, `multiple_choice`, `multi_select`, and `freeform`.
 
+### Review targets
+
+A human gate can present one external document as the primary review link. Set
+`review_target=true` on the gate:
+
+```dot
+review [
+  shape=hexagon,
+  review_target=true
+]
+
+review -> sync     [label="[S] Review complete; sync the current Markdown"]
+review -> address  [label="[A] Ask the agent to address human feedback"]
+review -> review   [label="[C] Continue reviewing"]
+```
+
+Before the workflow reaches the gate, an agent, prompt, or command node must set
+the flat `review_target` context key. A routing response can do this directly:
+
+```json
+{
+  "outcome": "succeeded",
+  "context_updates": {
+    "review_target": {
+      "label": "Quarry review exercise",
+      "url": "https://quarry.lithos.computer/tmp/0123456789abcdef0123456789abcdef",
+      "kind": "document"
+    }
+  }
+}
+```
+
+Fabro then presents this question:
+
+> Review the [Quarry review exercise](https://quarry.lithos.computer/tmp/0123456789abcdef0123456789abcdef) document, then choose the next action.
+
+The link uses the target URL from context. The example uses a placeholder
+secret, not a live Quarry document.
+
+Fabro generates this question text from the target. A `label` on the gate is
+not used while `review_target=true`.
+
+The target object has three required fields:
+
+| Field | Meaning |
+|---|---|
+| `label` | The link text. It must contain 1 to 200 characters and no control characters. |
+| `url` | An absolute HTTP or HTTPS URL. It must contain a host, must not contain URL credentials, and must be at most 2048 characters. |
+| `kind` | The resource type. The supported value is `document`. |
+
+Fabro validates the target before it starts the interview. A missing or invalid
+target fails the gate deterministically. A gate without `review_target=true`
+ignores this context key and keeps its normal label.
+
+The context value remains available after the human answers. A feedback loop
+can return to the same gate without recreating the target. A later stage can
+replace the target by writing a new value to the same context key.
+
+Fabro does not fetch the URL. Web and Slack clients open it as an external link.
+Treat bearer-capability links as secrets and only provide them to people who
+can access the run.
+
 ### Default choice on timeout
 
 If a human gate has a timeout configured, you can specify a default choice using the `human.default_choice` attribute:

docs/public/workflows/stages-and-nodes.mdx

@@ -104,7 +104,7 @@ test [label="Run Tests", shape=parallelogram, script="cargo test 2>&1 || true"]
 
 | Attribute | Description |
 |---|---|
-| `script` | The shell command to execute |
+| `script` | The shell command to execute. Substitutes `{{ goal }}`, `{{ inputs.NAME }}`, and `{{ vars.NAME }}` — see [command node scripts](/workflows/variables#command-node-scripts) |
 | `language` | `"shell"` (default) or `"python"` |
 
 ### Human

docs/public/workflows/variables.mdx

@@ -3,7 +3,7 @@ title: "Variables"
 description: "Using templates in workflows"
 ---
 
-Fabro renders `{{ ... }}` templates in exactly two workflow attributes: the graph `goal` and node `prompt`s. Every other attribute is literal text.
+Fabro renders `{{ ... }}` templates in exactly two workflow attributes: the graph `goal` and node `prompt`s. A command node's `script` gets narrower treatment — [simple value substitution](#command-node-scripts), not templating. Every other attribute is literal text.
 
 ## Template context
 
@@ -15,7 +15,7 @@ Goal templates can reference inputs and server-managed variables. Prompt templat
 | `{{ inputs.name }}` | A value from `[run.inputs]`, optionally overridden by CLI input flags |
 | `{{ vars.NAME }}` | A server-managed variable snapshotted when the run is created |
 
-Environment variables and secrets are **not** available in goal or prompt templates. Use `{{ env.NAME }}` and `{{ secrets.NAME }}` only in the configuration fields that support run-boundary interpolation.
+Secrets are **not** available in goal or prompt templates. Use `{{ secrets.NAME }}` only in the configuration fields that support run-boundary interpolation.
 
 ## Run config inputs
 
@@ -51,7 +51,7 @@ digraph Check {
 }
 ```
 
-Other attributes — `script`, `label`, `model`, `provider`, `condition`, and all edge attributes — do not render templates. If one of them contains `{{ … }}` or `{% … %}`, the syntax is treated as literal text and Fabro records a `detemplated_attribute` warning suggesting you move the dynamic value into a `prompt` or `goal`.
+Other attributes — `label`, `model`, `provider`, `condition`, and all edge attributes — do not render templates. If one of them contains `{{ … }}` or `{% … %}`, the syntax is treated as literal text and Fabro records a `detemplated_attribute` warning suggesting you move the dynamic value into a `prompt` or `goal`.
 
 Override individual inputs at run time with repeatable `-I` / `--input` flags:
 
@@ -61,6 +61,62 @@ fabro run .fabro/workflows/check/workflow.toml -I repo_name=fabro-2 --input lang
 
 CLI input values use TOML scalar parsing when possible. Quoted strings, booleans, integers, and floats keep their typed values; unquoted bare text falls back to a string. Empty values such as `foo=` are accepted as empty strings. Arrays, inline tables, and datetimes are rejected.
 
+## Command node scripts
+
+A [command node](/workflows/stages-and-nodes#command) `script` substitutes `{{ goal }}`, `{{ inputs.NAME }}`, and `{{ vars.NAME }}`:
+
+```dot title="check.fabro"
+digraph Check {
+    test [shape=parallelogram, script="cargo test -p {{ inputs.crate }} --profile {{ vars.PROFILE }}"]
+    pr   [shape=parallelogram, script="gh pr create --title {{ goal }}"]
+}
+```
+
+This is value substitution, not templating. Only those three forms are recognized; every other brace sequence reaches the shell untouched, so `jq` filters, `awk` programs, Go templates, and brace expansion all keep working:
+
+```dot
+report [shape=parallelogram, script="kubectl get pod -o go-template='{{ .status.phase }}' | jq '{phase: .}'"]
+```
+
+There is no `{% if %}`, no filters, and no loops, and `{{ goal }}` has no dotted form — `{{ goal.title }}` stays literal. Put branching in a [conditional node](/workflows/stages-and-nodes#conditional) or in the shell itself.
+
+In a shell script, Fabro quotes each substituted value as one shell argument. Put the token where one shell word is valid. Do not add quotes around the token, and do not use a token to inject multiple flags or shell syntax:
+
+```dot
+build [shape=parallelogram, script="docker build -t {{ inputs.image }} ."]
+```
+
+For `language="python"`, Fabro inserts each value as a quoted string literal. Put the token where a Python expression is valid:
+
+```dot
+report [shape=parallelogram, language="python", script="print({{ goal }})"]
+```
+
+Substituted text is never scanned again, so a goal or input containing `{{ ... }}` reaches the command as literal characters rather than being interpolated a second time.
+
+### `env` and `secrets` are not substituted
+
+`{{ env.NAME }}` and `{{ secrets.NAME }}` are rejected in a `script` with a validation error. Read environment variables with `$NAME` in a shell script:
+
+```dot
+deploy [shape=parallelogram, script="deploy --token $DEPLOY_TOKEN"]
+```
+
+In a Python script, read them with `os.environ["NAME"]`.
+
+To make a secret available that way, put it in the [environment's env map](/execution/run-configuration#run-environment-and-environments-slug), where `{{ secrets.* }}` does resolve — at run start, into the sandbox environment rather than into the script text:
+
+```toml title="run.toml"
+[environments.ci.env]
+DEPLOY_TOKEN = "{{ secrets.DEPLOY_TOKEN }}"
+```
+
+This keeps secret values out of the `command.started` event, which records the script verbatim.
+
+### When values resolve
+
+Inputs and variables are substituted when the run is created, at the same time as goals and prompts — the persisted workflow already contains the final script. An unbound input or variable is a warning from `fabro validate` and an error at run creation, so a run never executes a partially substituted command.
+
 ## Server-managed run config variables
 
 Use server-managed variables for non-sensitive values that should be shared across runs, such as deployment environments, default branches, regions, or image tags:
@@ -115,8 +171,9 @@ Fabro keeps workflow structure static and renders workflow templates once:
 2. Literal `import`, `@file`, graph-goal file, and child-workflow references are resolved.
 3. The graph `goal` is rendered with the `{ inputs, vars }` context.
 4. Node `prompt` attributes are rendered with the `{ goal, inputs, vars }` context.
+5. Node `script` attributes have their `{{ goal }}`, `{{ inputs.* }}`, and `{{ vars.* }}` values substituted.
 
-Templates are not supported in graph syntax, node IDs, edge structure, `import` paths, `@file` paths, child workflow paths, other file references, or any attribute besides `prompt` and `goal`.
+Templates are not supported in graph syntax, node IDs, edge structure, `import` paths, `@file` paths, child workflow paths, other file references, or any attribute besides `prompt` and `goal` — and `script`, which takes value substitution rather than templates.
 
 Fabro renders the graph `goal` first and stores the rendered value back onto the graph. Prompts that use `{{ goal }}` receive that rendered value.
 
@@ -124,6 +181,8 @@ Fabro renders the graph `goal` first and stores the rendered value back onto the
 
 Fabro renders undefined workflow variables as empty text and records a `template_undefined_variable` diagnostic. `fabro validate` reports that diagnostic as a warning so you can validate workflow structure before all inputs are known. Offline validation does not read a server's variable store, so `{{ vars.* }}` references also warn there. Run-style commands such as `fabro run`, `fabro create`, and preflight use the server snapshot and promote any still-undefined reference to an error before proceeding.
 
+In a `script`, an undefined value records the same diagnostic but leaves the token in place rather than emptying it, so validation output shows what is unbound.
+
 ## Template includes
 
 Prompt and goal templates support static MiniJinja loader dependencies such as `{% include "partial.md" %}`. Includes are resolved relative to the template file being rendered and can be nested.

lib/apps/fabro-cli/src/args.rs

@@ -1036,7 +1036,7 @@ pub(crate) struct RunWorkerArgs {
 
     /// Fabro storage directory for loading worker-visible secrets
     #[arg(long, hide = true)]
-    pub(crate) storage_dir: Option<PathBuf>,
+    pub(crate) storage_dir: PathBuf,
 
     /// Run scratch directory
     #[arg(long)]

lib/apps/fabro-cli/src/commands/exec.rs

@@ -282,14 +282,6 @@ impl ProviderAdapter for AuthenticatedFabroServerAdapter {
     }
 }
 
-#[expect(
-    clippy::disallowed_methods,
-    reason = "exec-boundary MCP transport InterpString resolution facade for {{ env.* }} values."
-)]
-fn process_env_var(name: &str) -> Option<String> {
-    std::env::var(name).ok()
-}
-
 fn run_mcp_servers_for_exec(
     mcps: &HashMap<String, ResolvedMcpEntry>,
 ) -> AnyResult<Vec<McpServerSettings>> {
@@ -341,17 +333,14 @@ pub(crate) async fn execute(mut args: ExecArgs, ctx: &CommandContext) -> AnyResu
             .transpose()?
             .unwrap_or_default(),
     };
-    // Resolve `{{ env.* }}` in MCP transport config at the exec boundary,
-    // against the CLI process env — the mirror of the `fabro run` worker
-    // boundary in `fabro_workflow::operations::start::runtime_mcp_server`.
-    // Both consumers read the same source-form settings; missing env is a hard
-    // error. `fabro exec` has no server vault, so secrets/inputs tokens surface
-    // loudly rather than leaking.
+    // Fully validate MCP transport config at the exec boundary. `fabro exec`
+    // has no server vault, so secret and unsupported tokens fail instead of
+    // reaching the transport.
     let mcp_servers = mcp_servers
         .into_iter()
         .map(|settings| {
             settings
-                .resolve_transport_env(process_env_var, |_| None)
+                .resolve_transport_secrets(|_| None)
                 .with_context(|| format!("failed to resolve MCP server {:?}", settings.name))
         })
         .collect::<AnyResult<Vec<_>>>()?;

lib/apps/fabro-cli/src/commands/run/attach.rs

@@ -438,6 +438,7 @@ fn api_question_to_question(question: &types::ApiQuestion) -> Question {
     converted
         .context_display
         .clone_from(&question.context_display);
+    converted.review_target.clone_from(&question.review_target);
     converted
 }
 
@@ -451,6 +452,9 @@ async fn ask_attach_question(question: Question, styles: &'static Styles) -> Ans
         let rendered = styles.render_markdown(context_text);
         eprint!("{rendered}");
     }
+    if let Some(line) = fabro_interview::review_target_line(&question) {
+        eprintln!("{line}");
+    }
     eprintln!("{} {}", styles.bold_cyan.apply_to("?"), question.text);
 
     match question.question_type {

lib/apps/fabro-cli/src/commands/run/create.rs

@@ -61,11 +61,8 @@ pub(crate) async fn create_run(
         None
     };
 
-    let mut validation = manifest_validation::validate_manifest(
-        &RunLayer::default(),
-        &built.manifest,
-        ctx.catalog()?,
-    )?;
+    let mut validation =
+        manifest_validation::validate_manifest(&RunLayer::default(), &built.manifest)?;
     manifest_validation::promote_template_undefined_variables_to_errors(&mut validation);
     let diagnostics = api_diagnostics_to_local(&validation.workflow.diagnostics);
     if !quiet {

lib/apps/fabro-cli/src/commands/run/run_progress/event.rs

@@ -657,6 +657,7 @@ mod tests {
             repo:        "widgets".into(),
             base_branch: "main".into(),
             head_branch: "fabro/run/42".into(),
+            head_sha:    Some("final-sha".to_string()),
             title:       "Ship the server-side PR".into(),
             draft:       true,
         };

lib/apps/fabro-cli/src/commands/run/run_progress/mod.rs

@@ -1386,6 +1386,7 @@ mod tests {
             repo:        "fabro".into(),
             base_branch: "main".into(),
             head_branch: "fabro/run/42".into(),
+            head_sha:    Some("final-sha".to_string()),
             title:       "Ship the change".into(),
             draft:       true,
         });

lib/apps/fabro-cli/src/commands/run/runner.rs

@@ -76,7 +76,7 @@ enum WorkerTitlePhase {
 pub(crate) async fn execute(
     run_id: RunId,
     server: String,
-    storage_dir: Option<PathBuf>,
+    storage_dir: PathBuf,
     run_dir: PathBuf,
     mode: RunWorkerMode,
     worker_token: &str,
@@ -110,7 +110,6 @@ pub(crate) async fn execute(
             run_id,
             run_spec.source_directory.as_deref(),
             &run_dir,
-            Arc::clone(&catalog),
         )
     } else {
         None
@@ -137,13 +136,10 @@ pub(crate) async fn execute(
     if let Some(control_manager) = &mut control_manager {
         control_manager.wait_for_first_connection().await?;
     }
-    let vault = load_worker_vault(storage_dir.as_deref()).await?;
+    let vault = load_worker_vault(&storage_dir).await?;
     let github_app = {
-        let vault_guard = match &vault {
-            Some(arc) => Some(arc.read().await),
-            None => None,
-        };
-        maybe_build_github_credentials(&run_spec.settings, vault_guard.as_deref())?
+        let vault_guard = vault.read().await;
+        maybe_build_github_credentials(&run_spec.settings, &vault_guard)?
     };
     let services = StartServices {
         run_id,
@@ -170,7 +166,8 @@ pub(crate) async fn execute(
             .run
             .integrations
             .github
-            .resolve_permissions(process_env_var),
+            .resolve_permissions()
+            .context("failed to resolve github permissions")?,
         vault,
         catalog,
         on_node: None,
@@ -237,13 +234,12 @@ fn build_fabro_run_tool_services(
     current_run_id: RunId,
     source_directory: Option<&str>,
     run_dir: &Path,
-    catalog: Arc<Catalog>,
 ) -> Option<FabroRunToolServices> {
     if worker_token.trim().is_empty() {
         return None;
     }
     let backend = ClientBackend::new(Arc::new(client))
-        .with_manifest_builder(Arc::new(WorkerRunManifestBuilder { catalog }));
+        .with_manifest_builder(Arc::new(WorkerRunManifestBuilder));
     Some(FabroRunToolServices {
         backend: Arc::new(backend),
         current_run_id,
@@ -252,9 +248,7 @@ fn build_fabro_run_tool_services(
     })
 }
 
-struct WorkerRunManifestBuilder {
-    catalog: Arc<Catalog>,
-}
+struct WorkerRunManifestBuilder;
 
 impl fabro_tool::RunManifestBuilder for WorkerRunManifestBuilder {
     fn build_run_manifest(
@@ -263,20 +257,15 @@ impl fabro_tool::RunManifestBuilder for WorkerRunManifestBuilder {
         cwd: &Path,
         user_settings_path: &Path,
     ) -> fabro_tool::ToolResult<RunManifest> {
-        run_tool_manifest::build_run_tool_manifest(
-            spec,
-            cwd,
-            user_settings_path,
-            Arc::clone(&self.catalog),
-        )
+        run_tool_manifest::build_run_tool_manifest(spec, cwd, user_settings_path)
     }
 }
 
-async fn load_worker_vault(storage_dir: Option<&Path>) -> Result<Option<Arc<AsyncRwLock<Vault>>>> {
-    let Some(storage_dir) = storage_dir else {
-        return Ok(None);
-    };
-
+/// Load the worker's secret vault from the run's storage root.
+///
+/// A worker always receives the server storage root so it can load the same
+/// secret vault as the server.
+async fn load_worker_vault(storage_dir: &Path) -> Result<Arc<AsyncRwLock<Vault>>> {
     let storage = Storage::new(storage_dir);
     let vault = SecretStore::open_snapshot(storage.sqlite_path(), storage.secrets_path())
         .await
@@ -287,7 +276,7 @@ async fn load_worker_vault(storage_dir: Option<&Path>) -> Result<Option<Arc<Asyn
             )
         })?
         .into_vault();
-    Ok(Some(Arc::new(AsyncRwLock::new(vault))))
+    Ok(Arc::new(AsyncRwLock::new(vault)))
 }
 
 const WORKER_CONTROL_RECONNECT_INITIAL_BACKOFF: Duration = Duration::from_millis(100);
@@ -1112,7 +1101,7 @@ fn stamp_system_worker(mut event: RunEvent) -> RunEvent {
 
 fn maybe_build_github_credentials(
     settings: &WorkflowSettings,
-    vault: Option<&fabro_vault::Vault>,
+    vault: &fabro_vault::Vault,
 ) -> Result<Option<fabro_github::GitHubCredentials>> {
     let resolved_run = &settings.run;
     let resolved_server = ServerSettingsBuilder::load_default().ok();
@@ -1143,14 +1132,6 @@ fn maybe_build_github_credentials(
     Ok(None)
 }
 
-#[expect(
-    clippy::disallowed_methods,
-    reason = "CLI worker InterpString resolution facade for {{ env.* }} values."
-)]
-fn process_env_var(name: &str) -> Option<String> {
-    std::env::var(name).ok()
-}
-
 /// Hard-gate for the CLI worker path: a run-level token is requested, or
 /// a clone-based sandbox in non-dry-run mode will need credentials to
 /// pull the repository. Pull-request-driven credential acquisition is
@@ -1361,6 +1342,7 @@ mod tests {
                 allow_freeform:  false,
                 timeout_seconds: None,
                 context_display: None,
+                review_target:   None,
             })),
             Some(WorkerTitlePhase::Waiting)
         );
@@ -1747,7 +1729,7 @@ mod tests {
             .set("ANTHROPIC_API_KEY", "vault-key", SecretType::Token, None)
             .unwrap();
 
-        let loaded = load_worker_vault(Some(temp.path())).await.unwrap().unwrap();
+        let loaded = load_worker_vault(temp.path()).await.unwrap();
         let guard = loaded.read().await;
         let credential = guard.get("ANTHROPIC_API_KEY").unwrap();
 

lib/apps/fabro-cli/src/commands/validate.rs

@@ -23,11 +23,7 @@ pub(crate) fn run(
         user_settings_path: Some(active_settings_path(None)),
         ..Default::default()
     })?;
-    let response = manifest_validation::validate_manifest(
-        &RunLayer::default(),
-        &built.manifest,
-        base_ctx.catalog()?,
-    )?;
+    let response = manifest_validation::validate_manifest(&RunLayer::default(), &built.manifest)?;
     let diagnostics = api_diagnostics_to_local(&response.workflow.diagnostics);
 
     if base_ctx.json_output() {

lib/apps/fabro-cli/src/main.rs

@@ -496,7 +496,7 @@ async fn pre_tracing_bootstrap(command: &Commands) -> Result<PreTracingBootstrap
             .await
         }
         Commands::RunCmd(RunCommands::RunWorker(args)) => {
-            prepare_run_worker_bootstrap(args.storage_dir.as_deref(), &args.run_dir)
+            prepare_run_worker_bootstrap(&args.storage_dir, &args.run_dir)
         }
         _ => Ok(PreTracingBootstrap::cli()),
     }
@@ -541,10 +541,10 @@ async fn prepare_server_bootstrap(
 }
 
 fn prepare_run_worker_bootstrap(
-    storage_dir: Option<&std::path::Path>,
+    storage_dir: &std::path::Path,
     run_dir: &std::path::Path,
 ) -> Result<PreTracingBootstrap> {
-    let local_config = local_server::LocalServerConfig::load_with_storage_dir(storage_dir)?;
+    let local_config = local_server::LocalServerConfig::load_with_storage_dir(Some(storage_dir))?;
     let runtime_directory = fabro_config::RuntimeDirectory::new(local_config.storage_dir());
     let log_destination = fabro_config::resolve_log_destination(
         local_config.config_log_destination().unwrap_or_default(),
@@ -1515,6 +1515,8 @@ destination = "{destination}"
             "__run-worker",
             "--server",
             "/tmp/fabro.sock",
+            "--storage-dir",
+            "/tmp/storage",
             "--run-dir",
             "/tmp/run",
             "--run-id",
@@ -1526,6 +1528,7 @@ destination = "{destination}"
         match *cli.command.unwrap() {
             Commands::RunCmd(RunCommands::RunWorker(args)) => {
                 assert_eq!(args.server, "/tmp/fabro.sock");
+                assert_eq!(args.storage_dir, std::path::PathBuf::from("/tmp/storage"));
                 assert_eq!(args.run_dir, std::path::PathBuf::from("/tmp/run"));
                 assert_eq!(args.run_id, "01ARZ3NDEKTSV4RRFFQ69G5FAV".parse().unwrap());
                 assert!(matches!(args.mode, args::RunWorkerMode::Start));
@@ -1541,6 +1544,8 @@ destination = "{destination}"
             "__run-worker",
             "--server",
             "http://127.0.0.1:3000",
+            "--storage-dir",
+            "/tmp/storage",
             "--run-dir",
             "/tmp/run",
             "--run-id",
@@ -1552,6 +1557,7 @@ destination = "{destination}"
         match *cli.command.unwrap() {
             Commands::RunCmd(RunCommands::RunWorker(args)) => {
                 assert_eq!(args.server, "http://127.0.0.1:3000");
+                assert_eq!(args.storage_dir, std::path::PathBuf::from("/tmp/storage"));
                 assert_eq!(args.run_dir, std::path::PathBuf::from("/tmp/run"));
                 assert_eq!(args.run_id, "01ARZ3NDEKTSV4RRFFQ69G5FAV".parse().unwrap());
                 assert!(matches!(args.mode, args::RunWorkerMode::Resume));

lib/apps/fabro-cli/src/shared/github.rs

@@ -8,7 +8,7 @@ pub(crate) fn build_github_credentials(
     strategy: GithubIntegrationStrategy,
     app_id: Option<&str>,
     app_slug: Option<&str>,
-    vault: Option<&Vault>,
+    vault: &Vault,
 ) -> anyhow::Result<Option<GitHubCredentials>> {
     match strategy {
         GithubIntegrationStrategy::App => {
@@ -31,7 +31,7 @@ pub(crate) fn build_github_credentials(
 
 /// Look up GitHub token: GITHUB_TOKEN env -> vault GITHUB_TOKEN -> GH_TOKEN env
 /// -> vault GH_TOKEN
-fn lookup_github_token(vault: Option<&Vault>) -> Option<String> {
+fn lookup_github_token(vault: &Vault) -> Option<String> {
     lookup_env_or_vault(EnvVars::GITHUB_TOKEN, vault)
         .or_else(|| lookup_env_or_vault(EnvVars::GH_TOKEN, vault))
 }
@@ -40,10 +40,10 @@ fn lookup_github_token(vault: Option<&Vault>) -> Option<String> {
     clippy::disallowed_methods,
     reason = "GitHub credential resolution intentionally falls back from vault to documented process-env names."
 )]
-fn lookup_env_or_vault(name: &str, vault: Option<&Vault>) -> Option<String> {
+fn lookup_env_or_vault(name: &str, vault: &Vault) -> Option<String> {
     std::env::var(name)
         .ok()
-        .or_else(|| vault.and_then(|v| v.get(name).map(str::to_string)))
+        .or_else(|| vault.get(name).map(str::to_string))
         .map(|t| t.trim().to_string())
         .filter(|t| !t.is_empty())
 }

lib/apps/fabro-cli/src/shared/utilities.rs

@@ -49,54 +49,49 @@ where
 
 pub(crate) fn print_diagnostics(diagnostics: &[Diagnostic], styles: &Styles, printer: Printer) {
     for d in diagnostics {
-        let location = match (&d.node_id, &d.edge) {
-            (Some(node), _) => format!(" [node: {node}]"),
-            (_, Some((from, to))) => format!(" [edge: {from} -> {to}]"),
-            _ => String::new(),
-        };
-        let source_prefix = source_prefix(d);
-        match d.severity {
-            Severity::Error if source_prefix.is_empty() => fabro_util::printerr!(
-                printer,
-                "{}{location}: {} ({})",
-                styles.red.apply_to("error"),
-                d.message,
-                styles.dim.apply_to(&d.rule),
-            ),
-            Severity::Error => fabro_util::printerr!(
-                printer,
-                "{}: {source_prefix}{}{location} ({})",
-                styles.red.apply_to("error"),
-                d.message,
-                styles.dim.apply_to(&d.rule),
-            ),
-            Severity::Warning if source_prefix.is_empty() => fabro_util::printerr!(
-                printer,
-                "{}{location}: {} ({})",
-                styles.yellow.apply_to("warning"),
-                d.message,
-                styles.dim.apply_to(&d.rule),
-            ),
-            Severity::Warning => fabro_util::printerr!(
-                printer,
-                "{}: {source_prefix}{}{location} ({})",
-                styles.yellow.apply_to("warning"),
-                d.message,
-                styles.dim.apply_to(&d.rule),
-            ),
-            Severity::Info => fabro_util::printerr!(
-                printer,
-                "{}",
-                styles.dim.apply_to(if source_prefix.is_empty() {
-                    format!("info{location}: {} ({})", d.message, d.rule)
-                } else {
-                    format!("info: {source_prefix}{}{location} ({})", d.message, d.rule)
-                }),
-            ),
+        print_diagnostic(d, styles, printer);
+        // The fix is the actionable half of a diagnostic, so it follows every
+        // severity rather than hiding behind --verbose. Rules that have nothing
+        // useful to suggest leave it unset.
+        if let Some(fix) = &d.fix {
+            fabro_util::printerr!(printer, "  {} {fix}", styles.dim.apply_to("fix:"));
         }
     }
 }
 
+fn print_diagnostic(d: &Diagnostic, styles: &Styles, printer: Printer) {
+    let location = match (&d.node_id, &d.edge) {
+        (Some(node), _) => format!(" [node: {node}]"),
+        (_, Some((from, to))) => format!(" [edge: {from} -> {to}]"),
+        _ => String::new(),
+    };
+    let source_prefix = source_prefix(d);
+    let body = if source_prefix.is_empty() {
+        format!("{location}: {}", d.message)
+    } else {
+        format!(": {source_prefix}{}{location}", d.message)
+    };
+    match d.severity {
+        Severity::Error => fabro_util::printerr!(
+            printer,
+            "{}{body} ({})",
+            styles.red.apply_to("error"),
+            styles.dim.apply_to(&d.rule),
+        ),
+        Severity::Warning => fabro_util::printerr!(
+            printer,
+            "{}{body} ({})",
+            styles.yellow.apply_to("warning"),
+            styles.dim.apply_to(&d.rule),
+        ),
+        Severity::Info => fabro_util::printerr!(
+            printer,
+            "{}",
+            styles.dim.apply_to(format!("info{body} ({})", d.rule)),
+        ),
+    }
+}
+
 fn source_prefix(diagnostic: &Diagnostic) -> String {
     match (
         diagnostic.source_path.as_deref(),

lib/apps/fabro-cli/tests/it/cmd/create.rs

@@ -101,6 +101,40 @@ fn create_uses_explicit_server_target_and_prints_remote_run_id() {
     assert_eq!(output_stdout(&output).trim(), run_id.as_str());
 }
 
+#[test]
+fn create_defers_provider_validation_to_the_server() {
+    let context = test_context!();
+    let server = MockServer::start();
+    let run_id = unique_run_id();
+    let mock = server.mock(|when, then| {
+        when.method("POST")
+            .path("/api/v1/runs")
+            .body_includes(r#"provider=\"server-only\""#);
+        then.status(201)
+            .header("Content-Type", "application/json")
+            .body(run_status_response(run_id.as_str(), "submitted").to_string());
+    });
+    let output = context
+        .create_cmd()
+        .args([
+            "--server",
+            &format!("{}/api/v1", server.base_url()),
+            "--dry-run",
+            fixture("server-model.fabro").to_str().unwrap(),
+        ])
+        .output()
+        .expect("command should execute");
+
+    assert!(
+        output.status.success(),
+        "local validation should not reject a server-owned provider\nstdout:\n{}\nstderr:\n{}",
+        String::from_utf8_lossy(&output.stdout),
+        String::from_utf8_lossy(&output.stderr)
+    );
+    mock.assert();
+    assert_eq!(output_stdout(&output).trim(), run_id.as_str());
+}
+
 #[test]
 fn create_uses_configured_server_target_without_server_flag() {
     let context = test_context!();

lib/apps/fabro-cli/tests/it/cmd/graph.rs

@@ -95,7 +95,9 @@ fn graph_allow_invalid_renders_after_diagnostics() {
     ----- stdout -----
     ----- stderr -----
     error: Pipeline must have exactly one start node (shape=Mdiamond or id start/Start) (start_node)
+      fix: Add a node with shape=Mdiamond or id 'start'
     error [node: exit]: Exit node 'exit' has 1 outgoing edge(s) but must have none (exit_no_outgoing)
+      fix: Remove outgoing edges from the exit node
     ");
 
     let svg = read_text(&output_path);
@@ -119,7 +121,9 @@ fn graph_invalid_workflow_fails_after_diagnostics() {
     ----- stdout -----
     ----- stderr -----
     error: Pipeline must have exactly one start node (shape=Mdiamond or id start/Start) (start_node)
+      fix: Add a node with shape=Mdiamond or id 'start'
     error [node: exit]: Exit node 'exit' has 1 outgoing edge(s) but must have none (exit_no_outgoing)
+      fix: Remove outgoing edges from the exit node
       × Validation failed
     ");
 }

lib/apps/fabro-cli/tests/it/cmd/pr_view.rs

@@ -85,6 +85,7 @@ fn pr_view_reads_pull_request_from_store_without_pull_request_json() {
                 repo:        "fabro".to_string(),
                 base_branch: "main".to_string(),
                 head_branch: "fabro/run/demo".to_string(),
+                head_sha:    Some("final-sha".to_string()),
                 title:       "Map the constellations".to_string(),
                 draft:       false,
             }),

lib/apps/fabro-cli/tests/it/cmd/preflight.rs

@@ -52,7 +52,9 @@ fn preflight_invalid_workflow_fails_with_validation_output() {
     Workflow: Invalid (2 nodes, 1 edges)
     Graph: [FIXTURES]/invalid.fabro
     error: Pipeline must have exactly one start node (shape=Mdiamond or id start/Start) (start_node)
+      fix: Add a node with shape=Mdiamond or id 'start'
     error [node: exit]: Exit node 'exit' has 1 outgoing edge(s) but must have none (exit_no_outgoing)
+      fix: Remove outgoing edges from the exit node
       × Validation failed
     ");
 }
@@ -74,7 +76,9 @@ fn preflight_rejects_unbound_template_inputs() {
     Goal: Demo
 
     error: [FIXTURES]/templated_unbound.fabro:2:26: undefined template variable `inputs.app_dir` in graph attribute `goal` (template_undefined_variable)
+      fix: bind `inputs.app_dir` via `[run.inputs]` in workflow.toml, or pass `--input inputs.app_dir=<value>`
     error: [FIXTURES]/templated_unbound.fabro:7:44: undefined template variable `inputs.app_dir` in node `work` attribute `prompt` [node: work] (template_undefined_variable)
+      fix: bind `inputs.app_dir` via `[run.inputs]` in workflow.toml, or pass `--input inputs.app_dir=<value>`
       × Validation failed
     ");
 }

lib/apps/fabro-cli/tests/it/cmd/runner.rs

@@ -69,19 +69,17 @@ fn spawn_worker_process(
         "FABRO_WORKER_TOKEN",
         issue_test_worker_jwt(&context.storage_dir, run_id),
     );
-    cmd.args([
-        "__run-worker",
-        "--server",
-        server,
-        "--run-dir",
-        run_dir
-            .to_str()
-            .expect("run directory path should be valid UTF-8"),
-        "--run-id",
-        run_id,
-        "--mode",
-        mode,
-    ]);
+    cmd.arg("__run-worker")
+        .arg("--storage-dir")
+        .arg(&context.storage_dir)
+        .arg("--server")
+        .arg(server)
+        .arg("--run-dir")
+        .arg(run_dir)
+        .arg("--run-id")
+        .arg(run_id)
+        .arg("--mode")
+        .arg(mode);
     cmd.stdin(Stdio::piped());
     cmd.stdout(Stdio::piped());
     cmd.stderr(Stdio::piped());
@@ -124,8 +122,16 @@ fn child_output(mut child: Child, status: ExitStatus) -> Output {
     }
 }
 
-fn worker_command(context: &fabro_test::TestContext, run_id: &str) -> assert_cmd::Command {
+fn worker_base_command(context: &fabro_test::TestContext) -> assert_cmd::Command {
     let mut cmd = context.command();
+    cmd.arg("__run-worker")
+        .arg("--storage-dir")
+        .arg(&context.storage_dir);
+    cmd
+}
+
+fn worker_command(context: &fabro_test::TestContext, run_id: &str) -> assert_cmd::Command {
+    let mut cmd = worker_base_command(context);
     cmd.env(
         "FABRO_WORKER_TOKEN",
         issue_test_worker_jwt(&context.storage_dir, run_id),
@@ -189,7 +195,7 @@ fn help() {
     ----- stdout -----
     Internal: execute a single workflow run locally
 
-    Usage: fabro __run-worker [OPTIONS] --server <SERVER> --run-dir <RUN_DIR> --run-id <RUN_ID> --mode <MODE>
+    Usage: fabro __run-worker [OPTIONS] --server <SERVER> --storage-dir <STORAGE_DIR> --run-dir <RUN_DIR> --run-id <RUN_ID> --mode <MODE>
 
     Options:
           --json               Output as JSON [env: FABRO_JSON=]
@@ -211,10 +217,8 @@ fn worker_requires_fabro_worker_token_env() {
     let context = auth_context();
     let run_dir = tempfile::tempdir().unwrap();
     let run_id = unique_run_id();
-    let output = context
-        .command()
+    let output = worker_base_command(&context)
         .args([
-            "__run-worker",
             "--server",
             "http://127.0.0.1:32276",
             "--run-dir",
@@ -272,7 +276,6 @@ digraph CachedGraph {
 
     let output = worker_command(&context, run_id.as_str())
         .args([
-            "__run-worker",
             "--server",
             server.as_str(),
             "--run-dir",
@@ -341,7 +344,6 @@ digraph GitHubApp {
     let mut cmd = worker_command(&context, run_id.as_str());
     cmd.env("GITHUB_APP_PRIVATE_KEY", "%%%not-base64%%%");
     cmd.args([
-        "__run-worker",
         "--server",
         server.as_str(),
         "--run-dir",
@@ -390,7 +392,6 @@ digraph DetachedStoreOnly {
     let server = server_target(&context.storage_dir);
     let output = worker_command(&context, run_id.as_str())
         .args([
-            "__run-worker",
             "--server",
             server.as_str(),
             "--run-dir",
@@ -608,7 +609,6 @@ digraph Test {
 
     let mut cmd = worker_command(&context, &run_id);
     cmd.args([
-        "__run-worker",
         "--server",
         &server,
         "--run-dir",
@@ -673,7 +673,6 @@ fn runner_reports_malformed_run_state_without_prefetching_events() {
 
     let output = worker_command(&context, &run_id)
         .args([
-            "__run-worker",
             "--server",
             &format!("{}/api/v1", server.base_url()),
             "--run-dir",

lib/apps/fabro-cli/tests/it/cmd/validate.rs

@@ -69,6 +69,24 @@ fn simple_does_not_connect_to_configured_server() {
     );
 }
 
+/// Offline validation has no model catalog, so a model or provider the server
+/// owns must pass rather than be reported as unknown.
+#[test]
+fn server_owned_provider_is_not_rejected_by_offline_validation() {
+    let context = test_context!();
+    let mut cmd = context.validate();
+    cmd.arg(fixture("server-model.fabro"));
+    fabro_snapshot!(context.filters(), cmd, @"
+    success: true
+    exit_code: 0
+    ----- stdout -----
+    ----- stderr -----
+    Workflow: ServerModel (3 nodes, 2 edges)
+    Graph: [FIXTURES]/server-model.fabro
+    Validation: OK
+    ");
+}
+
 #[test]
 fn branching() {
     let context = test_context!();
@@ -82,6 +100,7 @@ fn branching() {
     Workflow: Branch (6 nodes, 6 edges)
     Graph: [FIXTURES]/branching.fabro
     warning [node: implement]: Node 'implement' has goal_gate=true but no retry_target or fallback_retry_target (goal_gate_has_retry)
+      fix: Add retry_target or fallback_retry_target attribute
     Validation: OK
     ");
 }
@@ -163,7 +182,9 @@ fn bare_fabro_with_unbound_inputs_validates_structurally_with_warning() {
     Workflow: TemplatedUnbound (3 nodes, 2 edges)
     Graph: [FIXTURES]/templated_unbound.fabro
     warning: [FIXTURES]/templated_unbound.fabro:2:26: undefined template variable `inputs.app_dir` in graph attribute `goal` (template_undefined_variable)
+      fix: bind `inputs.app_dir` via `[run.inputs]` in workflow.toml, or pass `--input inputs.app_dir=<value>`
     warning: [FIXTURES]/templated_unbound.fabro:7:44: undefined template variable `inputs.app_dir` in node `work` attribute `prompt` [node: work] (template_undefined_variable)
+      fix: bind `inputs.app_dir` via `[run.inputs]` in workflow.toml, or pass `--input inputs.app_dir=<value>`
     Validation: OK
     ");
 }
@@ -186,6 +207,7 @@ fn bare_fabro_with_unbound_inputs_in_imported_prompt_validates_structurally_with
     Workflow: TemplatedUnboundImported (3 nodes, 2 edges)
     Graph: [FIXTURES]/templated_unbound_imported/workflow.fabro
     warning: [FIXTURES]/templated_unbound_imported/work.md:1:12: undefined template variable `inputs.app_dir` in node `work` attribute `prompt` [node: work] (template_undefined_variable)
+      fix: bind `inputs.app_dir` via `[run.inputs]` in workflow.toml, or pass `--input inputs.app_dir=<value>`
     Validation: OK
     ");
 }
@@ -207,6 +229,7 @@ fn bare_fabro_with_unbound_inputs_in_template_partial_validates_structurally_wit
     Workflow: TemplatedUnboundPartial (3 nodes, 2 edges)
     Graph: [FIXTURES]/templated_unbound_partial/workflow.fabro
     warning: [FIXTURES]/templated_unbound_partial/test-include.partial.md:1:4: undefined template variable `inputs.hello` in node `test_imported_include` attribute `prompt` [node: test_imported_include] (template_undefined_variable)
+      fix: bind `inputs.hello` via `[run.inputs]` in workflow.toml, or pass `--input inputs.hello=<value>`
     Validation: OK
     ");
 }
@@ -278,6 +301,26 @@ fn validate_reports_missing_template_dependency() {
     ");
 }
 
+/// A node named only by an edge is almost always a typo, so validation must
+/// fail instead of quietly running it as a default agent stage.
+#[test]
+fn edge_only_node() {
+    let context = test_context!();
+    let mut cmd = context.validate();
+    cmd.arg(fixture("edge_only_node.fabro"));
+    fabro_snapshot!(context.filters(), cmd, @"
+    success: false
+    exit_code: 1
+    ----- stdout -----
+    ----- stderr -----
+    Workflow: EdgeOnlyNode (2 nodes, 2 edges)
+    Graph: [FIXTURES]/edge_only_node.fabro
+    error [node: misspelled_node]: Node 'misspelled_node' is referenced by edge 'start -> misspelled_node' but has no node declaration (edge_target_exists)
+      fix: Declare node 'misspelled_node' or correct the edge endpoint
+      × Validation failed
+    ");
+}
+
 #[test]
 fn invalid() {
     let context = test_context!();
@@ -291,7 +334,9 @@ fn invalid() {
     Workflow: Invalid (2 nodes, 1 edges)
     Graph: [FIXTURES]/invalid.fabro
     error: Pipeline must have exactly one start node (shape=Mdiamond or id start/Start) (start_node)
+      fix: Add a node with shape=Mdiamond or id 'start'
     error [node: exit]: Exit node 'exit' has 1 outgoing edge(s) but must have none (exit_no_outgoing)
+      fix: Remove outgoing edges from the exit node
       × Validation failed
     ");
 }

lib/apps/fabro-cli/tests/it/cmd/worker_auth.rs

@@ -393,17 +393,17 @@ fn runner_rejects_bogus_worker_token_against_github_only_server() {
         cmd.env("FABRO_HOME", &worker_home);
         cmd.env("FABRO_AUTH_FILE", &auth_file);
         cmd.env("FABRO_WORKER_TOKEN", bogus_token);
-        cmd.args([
-            "__run-worker",
-            "--server",
-            &target,
-            "--run-dir",
-            run_dir.to_str().unwrap(),
-            "--run-id",
-            &run_id,
-            "--mode",
-            "start",
-        ]);
+        cmd.arg("__run-worker")
+            .arg("--server")
+            .arg(&target)
+            .arg("--storage-dir")
+            .arg(&server.storage_dir)
+            .arg("--run-dir")
+            .arg(&run_dir)
+            .arg("--run-id")
+            .arg(&run_id)
+            .arg("--mode")
+            .arg("start");
         cmd.stdin(Stdio::null());
         cmd.stdout(Stdio::piped());
         cmd.stderr(Stdio::piped());