From 97a946d3830e1b2e7e881ddc93ba38080bb93f1d Mon Sep 17 00:00:00 2001 From: Brian Searls Date: Wed, 2 Sep 2026 19:37:57 +0000 Subject: [PATCH] NS-N receipt zero: bind the Step 0 canary baseline to an executed run 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 20caf4eb04, and the three baseline literals in test.claim.namespace_step0_canary_witness are rebound to what it observed: commit 20caf4eb04, tree a6a6e0a531, 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 Claude-Session: https://claude.ai/code/session_01HM6r4Ydp7GCJBuaFgLBRwL --- .../claim/namespace_step0_canary_witness_test.dag | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/dag/test/claim/namespace_step0_canary_witness_test.dag b/dag/test/claim/namespace_step0_canary_witness_test.dag index 96657c77385..20fd96a0ac7 100644 --- a/dag/test/claim/namespace_step0_canary_witness_test.dag +++ b/dag/test/claim/namespace_step0_canary_witness_test.dag @@ -40,12 +40,19 @@ import gunbc.namespace_step0_canary { data live_tree_disposition: LiveTreeDisposition = SubstrateInputsOnly +// RECEIPT ZERO. These three literals are not fixture decoration: they name the commit, the tree +// and the compiler executable of the run in which the frozen contract's own command +// (namespace_step0_canary_contract.command) was executed against main and admitted the +// unavailable receipt below. That run is the prerequisite-scoring baseline -- a later change +// claiming Step 0 movement is scored against THIS observation, and a change that moves main +// without moving the canary has produced no movement to cite. Re-binding them is a new baseline +// and lands alone, per the freeze note in gunbc.namespace_step0_canary. fn canary_commit() -> GitObjectId? { - git_sha1_object_id(hex: "cfb448de521965163e9a82e0a9eb77b311b49f9d") + git_sha1_object_id(hex: "20caf4eb0477c5a46d5b0d1302e337db14fcbd59") } fn canary_tree() -> GitObjectId? { - git_sha1_object_id(hex: "140fbae21fbc209319bbe1a9d9bfbdfd2c5d5dc6") + git_sha1_object_id(hex: "a6a6e0a531e23cc88fbbe01a2fa582b84867c625") } fn foreign_tree() -> GitObjectId? { @@ -53,7 +60,7 @@ fn foreign_tree() -> GitObjectId? { } fn canary_compiler() -> Sha256Digest? { - sha256_hex_digest(hex: "4a14d9095b820ad92b7b12752c6464cc0b25f91897c85958feb8bac9ad5c9f3e") + sha256_hex_digest(hex: "a89dfc88a9ef07b6648f5a7e1f1fa5bafd8272defb74300910b18406786f6fa2") } fn admission_is_admitted(a: NamespaceStep0CanaryAdmission) -> Bool {