# 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.