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

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