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

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.