Skip to content

Advance the real-project-v2 candidate registry to Bifrost v0.10.8 - #192

Merged
DavidBakerEffendi merged 1 commit into
mainfrom
dave/advance-v2-registry
Sep 2, 2026
Merged

Advance the real-project-v2 candidate registry to Bifrost v0.10.8#192
DavidBakerEffendi merged 1 commit into
mainfrom
dave/advance-v2-registry

Conversation

@DavidBakerEffendi

Copy link
Copy Markdown
Collaborator

Closes #185, recast: the published v2 result understates Bifrost not because a
re-freeze is missing, but because the slice's frozen candidate registry still
pins v0.10.2 — every v2 freeze re-measures last month's analyzer by
construction (v0.3.2/v0.3.3 demonstrated exactly this). The slice's own README
states the doctrine:

Any later Bifrost run is evidence for a subsequent snapshot or release, never
a replacement for v0.3.0 evidence.

The change

candidates-v0.3.4.json — a new frozen identity set, not an edit:

  • Bifrost advances to v0.10.8 @ 8ddf1362, the same identity the active
    development registry pins.
  • Everything else is byte-identical to the v0.3.0 registry — reference-server
    identities, profiles, hashes. The corpus, protocol, selection, and reviewed
    ground truth are untouched.
  • candidates-v0.3.0.json stays byte-identical as the immutable record of what
    v0.3.0 measured.

Consumers: the freeze workflow selects the new registry for evaluation
snapshots; shard identities hash both registries and read candidate identity
from the current one; the reproduction contract asserts the superseding
registry's Bifrost matches the active pin and that no non-Bifrost identity
moved, alongside its existing guard that the historical registry is unchanged.
Tests cover the "advances only the Bifrost pin" property directly, in both the
Python and Rust suites. CITATION.cff moves to 0.3.4 for freeze preflight.

Expected effect on the next v2 freeze

From the repository-tree measurement under v0.10.8: 12 of v0.3.0's 17
failures resolve, 5 remain
(#181 ×2, #182 ×2, #183), 0 new. The freeze is
the real acceptance test — please check the aggregate's counts against this at
the release approval gate rather than taking the prediction on trust; in
particular, any reason=time_budget diagnostic means the scan-budget fix
regressed and the run should not be approved.

Depends on #191 (merged): without the capability fix, a v0.10.8 evaluation
freeze errors every usage scan.

Verification

  • cargo test --locked — 257 passed (1 new), 0 failed
  • Python suites — 44 tests OK (2 new)
  • validate-reproduction-contract.sh — exit 0

🤖 Generated with Claude Code

The v2 slice's execution identities are frozen in a versioned registry, and
the registry the freeze selected still pinned Bifrost v0.10.2 -- so every v2
freeze re-measured the analyzer of a month ago by construction. The slice's own
README states the doctrine for moving forward: a later Bifrost run is evidence
for a subsequent release, never a replacement for v0.3.0 evidence.

`candidates-v0.3.4.json` is that subsequent identity set. It advances the
measured Bifrost to v0.10.8 at `8ddf1362`, the same identity the active
development registry pins, and changes nothing else: every reference-server
identity is byte-identical to the v0.3.0 registry, and the corpus, protocol,
selection, and reviewed ground truth are untouched. `candidates-v0.3.0.json`
stays byte-identical as the immutable record of what v0.3.0 measured.

The freeze workflow selects the new registry for evaluation snapshots. Shard
identities hash both registries and read candidate identity from the current
one. The reproduction contract now asserts the superseding registry's Bifrost
matches the active development pin and that no non-Bifrost identity moved,
alongside its existing assertions that the historical registry is unchanged.

Expected effect on the next v2 freeze, from the repository-tree measurement
under v0.10.8: 12 of v0.3.0's 17 failures resolve, 5 remain (#181, #182,
#183), none appear. The freeze that publishes this is the real acceptance
test, and its aggregate counts -- not this prediction -- are what the release
approval should be checked against.

Requires the scan-budget capability fix (#191), without which a v0.10.8
evaluation freeze would error every usage scan.

Closes #185

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@DavidBakerEffendi
DavidBakerEffendi merged commit e9ffdf2 into main Sep 2, 2026
5 checks passed
@DavidBakerEffendi
DavidBakerEffendi deleted the dave/advance-v2-registry branch September 2, 2026 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Re-freeze real-project-v2: the published result understates Bifrost by 12 cases

1 participant