Repository navigation
Freeze the Step 0 strip-entry canary and bind its first observation - #10090
Conversation
|
Addressed review 58793 across the two subsequent commits. The admission is no longer a Boolean self-comparison: it returns The receipt is now — sent from gentle-ibex-25 |
… on main The Step-0 strip-entry canary landed in #10090 with its witness pinned to the commit, tree and compiler digest of the tree it was authored against. Those literals were never the record of a run: nothing had executed the contract's own command, so the baseline a later prerequisite claim would be scored against did not exist yet. This is that run. The frozen contract's command (gunbc.namespace_step0_canary namespace_step0_canary_contract command) was executed against a clean checkout of main 20caf4e, and the three baseline literals in test.claim.namespace_step0_canary_witness are rebound to what it observed: commit 20caf4e, tree a6a6e0a, and the sha256 of the target/release/gunbc built from that tree in the same dispatch. All nine witnesses in the entry pass against the rebound baseline. Nothing else moved. The contract, the classifier (admit_namespace_step0_canary_receipt), the subject-entry rule and the controls are untouched, which is exactly what the freeze note requires of a baseline correction: it lands alone. The receipt still reports Step0SubjectNotEntered blocked at ApplyTypedImportStrip -- no typed source-rewrite producer exists, so the canary has not moved and this change does not claim it has. It fixes the zero against which a real move would be measured. Two notes for whoever runs it next. BuildBuddy cannot execute this command: claim_batch refuses with HostBudgetUnreadable because no cgroup memory limit binds the remote runner (gunbc.host_budget_source), so the run is a local or CI one. And the digest is of an aarch64 build; a rebind from an amd64 CI runner will differ and is a new baseline, not a contradiction of this one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HM6r4Ydp7GCJBuaFgLBRwL
… on main (#10117) The Step-0 strip-entry canary landed in #10090 with its witness pinned to the commit, tree and compiler digest of the tree it was authored against. Those literals were never the record of a run: nothing had executed the contract's own command, so the baseline a later prerequisite claim would be scored against did not exist yet. This is that run. The frozen contract's command (gunbc.namespace_step0_canary namespace_step0_canary_contract command) was executed against a clean checkout of main 20caf4e, and the three baseline literals in test.claim.namespace_step0_canary_witness are rebound to what it observed: commit 20caf4e, tree a6a6e0a, and the sha256 of the target/release/gunbc built from that tree in the same dispatch. All nine witnesses in the entry pass against the rebound baseline. Nothing else moved. The contract, the classifier (admit_namespace_step0_canary_receipt), the subject-entry rule and the controls are untouched, which is exactly what the freeze note requires of a baseline correction: it lands alone. The receipt still reports Step0SubjectNotEntered blocked at ApplyTypedImportStrip -- no typed source-rewrite producer exists, so the canary has not moved and this change does not claim it has. It fixes the zero against which a real move would be measured. Two notes for whoever runs it next. BuildBuddy cannot execute this command: claim_batch refuses with HostBudgetUnreadable because no cgroup memory limit binds the remote runner (gunbc.host_budget_source), so the run is a local or CI one. And the digest is of an aarch64 build; a rebind from an amd64 CI runner will differ and is a new baseline, not a contradiction of this one. Claude-Session: https://claude.ai/code/session_01HM6r4Ydp7GCJBuaFgLBRwL Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Outcome
Freezes the NS-N Step 0 canary around one question: can the corpus-wide import strip be entered, and if not, what is the first typed stop?
The first observation is honestly ObservationUnavailable. It is revision-bound to commit
cfb448de521965163e9a82e0a9eb77b311b49f9d, tree140fbae21fbc209319bbe1a9d9bfbdfd2c5d5dc6, and the exacttarget/release/gunbcexecutable built from that revision (SHA-2564a14d9095b820ad92b7b12752c6464cc0b25f91897c85958feb8bac9ad5c9f3e).Completed prefix:
First stop:
ApplyTypedImportStrip/TypedSourceRewriteAndStripObservationProducerUnavailable.The receipt keeps
Step0SubjectNotEnteredseparate fromStep0ObservationIncomplete. It does not install #10072's one-off census counts as authority.Frozen contract
A PR claiming NS-N prerequisite credit may not edit the canary, classifier, subject-entry definition, or controls in the same change. A correction is a separate change and resets the baseline. Later prerequisite claims must show paired movement on this exact canary or remain valuable maintenance that cannot delay Step 0.
Exact command:
target/release/claim_batch --source-root dag --source-root src/v2 --entry dag/test/claim/namespace_step0_canary_witness_test.dag --functions current_main_step0_canary_receipt_is_admittedControls
The witness also refuses:
Verification
gunbcrelease build completed remotely and produced the recorded executable digest;