Skip to content

Freeze the Step 0 strip-entry canary and bind its first observation - #10090

Merged
gunbai-bot[bot] merged 3 commits into
mainfrom
session/gentle-ibex-25
Sep 2, 2026
Merged

gunbai-bot[bot] merged 3 commits into
mainfrom
session/gentle-ibex-25

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

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, tree 140fbae21fbc209319bbe1a9d9bfbdfd2c5d5dc6, and the exact target/release/gunbc executable built from that revision (SHA-256 4a14d9095b820ad92b7b12752c6464cc0b25f91897c85958feb8bac9ad5c9f3e).

Completed prefix:

  1. canary contract frozen
  2. source tree pinned
  3. compiler executable pinned
  4. input/subject manifest pinned

First stop: ApplyTypedImportStrip / TypedSourceRewriteAndStripObservationProducerUnavailable.

The receipt keeps Step0SubjectNotEntered separate from Step0ObservationIncomplete. 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_admitted

Controls

The witness also refuses:

  • a receipt relabelled onto a foreign source tree;
  • an unavailable/empty observation from a foreign canary contract.

Verification

  • pinned gunbc release build completed remotely and produced the recorded executable digest;
  • first remote claim run reached resolution and exposed a one-variant transition declaration defect; fixed by making the transition vocabulary closed over both strip and containment-compile transitions;
  • follow-up local invocation used an older host compiler and was non-evidentiary;
  • required CI is the current-compiler execution.

@gunbai-bot

gunbai-bot Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

Addressed review 58793 across the two subsequent commits.

The admission is no longer a Boolean self-comparison: it returns NamespaceStep0ReceiptRefused { field, cause }, and independently-authored controls now discriminate stale commit, foreign tree, foreign manifest, inconsistent subject entry, empty planted observation, and foreign-tree planted observation at their exact fields. The pinned positive row is deliberately a versioned historical receipt, not a live-tree oracle or a claim that Step 0 executed; its ObservationIncomplete / SubjectNotEntered outcome records the capability audit requested by the stopping ruling.

The receipt is now sole_constructor. The immediate-successor constructor is caller-sealed to test.claim.namespace_step0_canary_witness frontier_receipt; production cannot mint SubjectEntered by writing a receipt. The annotation states that the fixture proves a longer frontier is inhabitable and that the eventual strip producer must own a separate constructor whose inputs are the executed rewrite and observation. Thus the successor remains authorable at the fixture boundary without becoming the section-5 escape hatch.

— sent from gentle-ibex-25

@gunbai-bot
gunbai-bot Bot merged commit f363242 into main Sep 2, 2026
6 checks passed
@gunbai-bot
gunbai-bot Bot deleted the session/gentle-ibex-25 branch September 2, 2026 17:48
@briansrls
briansrls restored the session/gentle-ibex-25 branch September 2, 2026 17:49
gunbai-bot Bot pushed a commit that referenced this pull request Sep 2, 2026
… 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
gunbai-bot Bot added a commit that referenced this pull request Sep 2, 2026
… 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>
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.

0 participants