Appends to 775d7ba, which is left untouched.
That amendment put the non-empty check in a constructor and in Deserialize,
and left `Inherited { provider: String }` public. So the struct-literal path
bypassed both -- and the very first caller took it: C1's adapter rows were
written as `IntegrationOwnership::Inherited { provider: "...".to_string() }`,
never touching the constructor that was supposed to be guarding them. A
checked constructor sitting beside a public field is a suggestion. The field
is the API.
Provider is now a newtype whose inner String is private, so every route in
-- Provider::new, Deserialize -- runs the same check, and an empty provider
cannot be constructed on any path outside this module. The compiler proved
it during the change: converting the field turned my own struct-literal
test sites into type errors, which is exactly the class of site that had
been slipping through. I also compiled a deliberate bypass from outside the
module to confirm it is rejected rather than assume it:
error[E0308]: mismatched types
provider: String::new(),
^^^^^^^^^^^^^ expected `Provider`, found `String`
and reverted that probe byte-identically.
Two new tests beyond the constructor and wire cases already present. One
pins the serialization consequence a type error cannot express: every
Provider that exists has been checked, so no serialized row can carry an
empty one. The other round-trips a whole adapter row and asserts the
provider survives intact, since the shape a real report carries this in is
the row, not the enum alone.
C1's two construction sites are converted to the checked constructor. No
report values change -- both candidates already named real providers.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RSX4zSLgKvtiXaPjnMqLGz
Appends to d76287c, which is left untouched.
That amendment justified IntegrationOwnership::Inherited's provider field
as a claim "a reader can check against the dependency graph rather than
take on trust" -- and then accepted "" and " " for it, in Rust and
through serde alike. An unnamed provider is not a weaker claim of
inheritance. It is the same claim with its evidence removed, and it renders
as Inherited in every table it reaches.
Fixed the way this crate already fixed the identical hole in CheckOutcome's
reason strings: a checked constructor, plus a hand-written Deserialize over
a private wire shadow so the JSON path runs the same check. A hand-edited
report is exactly where an unnamed provider would arrive from, so guarding
only the Rust constructor would have guarded the path nobody takes.
Seven tests. Six fail when the check is reverted to `if false`, verified by
doing it and restoring: the constructor on empty and on whitespace-only,
the deserialize path on both, the same empty provider nested inside a whole
adapter row (the shape a real report carries it in, not just the enum
alone), and the accepting case for a real provider. CandidateOwned keeps
deserializing unchanged.
No candidate report changes: both candidates already name real providers,
so this closes a hole rather than correcting a value.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RSX4zSLgKvtiXaPjnMqLGz
Append-only amendment to 694d135. The oracle, the verifier, the scoring
rule, the PASS results and eligibility are all untouched; this changes only
what a cost row is able to say.
The first pair of real candidate reports proved the schema could not carry
what Packet 2B was chartered to record. Both candidates reached AT-SPI
through AccessKit -- C1 via the integration bundled with eframe, C2 via
wiring it wrote by hand -- and they reported that as opposite rows:
C1: NotBuilt accesskit-0.24 "no separate AccessKit-native readback was built"
C2: Implemented accesskit-0.24 "the in-process tree this binary constructs by hand"
C1's row was false as written. The AccessKit path was present and
exercised; every one of its five check-5 readbacks travelled it. NotBuilt
means uncovered scope, and that scope was covered.
Relabelling it Implemented would have fixed the falsehood and still lost
the measurement, because "inherited or candidate-owned?" would have
survived only as prose in notes -- which is precisely how the two
candidates diverged in the first place. So AdapterStatus::Implemented now
requires a typed integration_ownership: Inherited { provider } or
CandidateOwned. Inherited names its provider so the claim can be checked
against the dependency graph instead of taken on trust. NotBuilt keeps no
ownership field at all: a platform reached by any route is Implemented.
Inheriting an integration is not inheriting the semantics drawn on top of
it. A candidate that inherits a bridge still writes the accessible nodes
for whatever it painted itself, and that work is counted under
ReportPart::AccessibilityTreeConstruction, not here -- which is what makes
the two rows comparable rather than a single "has accessibility" flag.
Five tests, each of which fails if its guard is removed: the two-candidate
comparison the old schema could not express, Inherited carrying a
checkable provider, an Implemented row missing integration_ownership
refused at deserialize, NotBuilt refusing an ownership field, and a
round trip that must not alter a row.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RSX4zSLgKvtiXaPjnMqLGz
Pin 13 requires an oracle committed and reviewed before any candidate is
scored against it. Both halves land here, before C1 or C2 exists, so
neither candidate can shape what it will be measured by.
round2-candidatekit is the only code the two candidates share. It loads
and validates Packet 2A's fixtures, probe table, reference rasters and
regions; it renders nothing, resolves no hit test, and builds no
accessibility node -- a dependency deny-list test reads its own manifest
at test time to keep it that way, including the dotted-subtable and
target-cfg forms a line scanner would otherwise miss. Check 3 is pinned
NOT RUN by the recipe's 1.2 ruling: a report claiming Pass or Fail for it
is refused, and the supplementary F-D field is one the scoring function
never reads, so it cannot reach the criterion cell by construction rather
than by convention. A check-5 NOT RUN now requires typed evidence that the
platform bus was unreachable, because Round 0 already proved it reachable
for both candidates -- "we did not build it" is scope, and scope is not
environmental.
round2-a11y-oracle derives every byte string a live AT-SPI readback must
compare against, from the digest-validated fixtures alone: the expected
name three ways, the at-spi2 role sets, a precommitted alternative form
per prohibited outcome, the visual-order form, and the per-segment source
atoms. The fixtures digest is unchanged at acc13c0d, so Packet 2A stays
frozen.
verify.py gains a check-5 mode whose classifier is a pure function, unit
tested without a bus, and which fails closed on platform, digest, fixture
completeness, the name/hex/length triple, atom concatenation, and any
string that would classify as two different outcomes.
The scoring policy, settled over eight review rounds and worth stating
because most of it was won by finding the opposite in the code first:
- An accepted-role exact match wins from anywhere in the forest. It used
to be first-match, so tree order decided a disqualifying check.
- Composition is scoped to one run subtree and outranks any per-node
diagnosis. Application-wide concatenation both passed a run half-drawn
as a canvas and failed a correct split run because the window carried
a label.
- Contributor order stays significant, since 8.1 requires logical order;
only non-contributor order is required not to matter.
- name-empty means an attempted static-text exposure without a name.
absent-from-tree means a drawing-only or unrelated tree, and nothing
else -- it is the outcome 8.3 says this check will most likely catch,
and it was nearly unreachable while gated on role presence.
- A byte-exact PASS outranks an alternative-form match. F-C's
"drops unresolved codepoints" form is its own first segment, so a
legitimate per-run split was being failed on a check that eliminates.
That collision is structural for any two-segment fixture with one
unresolved segment, not an F-C accident.
Recorded as a finding, not fixed: the recipe's claim that visual-order
assembly diverges for F-D "and only there" is false -- F-B diverges too,
and any non-palindromic RTL run of two or more graphemes will. F-D's real
distinguishing property is an interior RTL run. The same stale wording is
compiled into fixtures.json and covered by its frozen digest, so
correcting it would move acc13c0d out from under Packet 2A.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RSX4zSLgKvtiXaPjnMqLGz
Levi Neuwirth