One landing: the pin moves to rc.21 and section 02 says what is now true - #104
Merged
Conversation
/verify section 02 says one thing while npm's latest sits inside the resolutionPayload withdrawal band and the opposite once it moves past. The marker on those sentences is latest-does-not-export. There was no predicate for the other side, so the swap on the day would have been a hand edit to a claim nobody could check until after it was made. Safe to add before the move: it is unused until a marker names it, and adding it changes no verdict. NOT DEFINED AS THE NEGATION OF THE OTHER, deliberately. latest-does-not-export returns false when the version is unmeasured, because an unevaluable claim is not true. So does this one. A predicate written as `!other` would turn that refusal into a pass in one direction, which is the failure mode the pair exists to prevent.
Committed alone, ahead of the copy change, because npmLatest is compared by several markers and mixing the two makes the copy commit unreviewable. npmLatest 1.0.0-rc.12 -> 1.0.0-rc.21 npmLatestExports now includes resolutionPayload The withdrawal band is unchanged: resolutionPayload is still absent from rc.9 through rc.12. What changed is that latest no longer points inside it.
…he page tells you to install
All six parts in one commit, because no ordering buys anything and part 4
without parts 1-3 is green and wrong. No check reads the words, so writing them
together is the only thing that makes the set atomic.
1 heading "You cannot check a resolution record with the
version this page tells you to install" becomes
"A resolution record now checks ... It did not, for
four releases."
2 consequence sentence 1 "The version npm install serves does not export it"
becomes "serves exports it. For four releases it
did not."
3 consequence sentence 2 the reader-cannot-check sentence becomes the record
of who could and who could not: the 122 signed
resolution records were always rebuildable by
someone who installed @rc, and were not by someone
who followed the instruction on this page.
4 marker, both sites latest-does-not-export -> latest-exports
5 "What to do about it" it told a reader to accept the gap and said the gap
closes when latest moves past the band. It has. The
paragraph now says nothing needs doing and why the
page stays pinned to latest regardless.
6 npmLatest spans 1.0.0-rc.12 -> 1.0.0-rc.21, both
THE FOUR-RELEASE GAP IS RECORDED, NOT DELETED. The section stays because a
section that vanishes when a defect clears leaves a reader unable to tell a page
that was always right from a page that was corrected. resolutionPayload was
still absent from rc.9 through rc.12 and the withdrawal still appears in no
changelog; what changed is which release a reader receives.
Verified in the INDEX before committing, per CONVENTIONS 18: all six present in
the staged bytes, the old heading gone, and zero occurrences of the old marker
or the old span value.
…ation
The held plan enumerated six parts and named the two dependents that must change
with them. IT MISSED TWO SENTENCES, ON TWO PAGES, AND ONE OF THEM WAS INSIDE THE
SECTION BEING SWAPPED.
verify.html "We hold 122 signed resolution records that a reader on
1.0.0-rc.21 has no route to."
That is the failure the whole mechanism was built to prevent, in the one place
it was supposed to be watched: the data-measured SPAN inside the sentence
updated itself to rc.21 while the SENTENCE inverted in meaning and did not.
Part 6 moved the span. Nothing moved the words around it.
index.html "A further 122 resolution records are rebuildable at some
published version but not at the one npm install serves."
Both rewritten. The count is now 0 and both pages say so in the past tense, with
the four-release history kept rather than deleted.
RE-MEASURED signed-record-coverage against the stores, which are reachable:
resolution.rebuildableAtNpmLatest false -> true
notRebuildableAtNpmLatest kinds [resolution] count 122
-> kinds [] count 0
neverRebuildable UNCHANGED, instructed and report, 3089,
27.0%. No route at ANY version, so the tag
move cannot touch it.
AND THE CHECK CAUGHT ME DROPPING A DECLARED FIGURE. Rewriting index.html removed
the kinds span, and check-measured-figures refused: "Dropping a measured claim
must not be something an edit does quietly." Correct. The kinds list is now empty
because the count is 0, so there is no class name to show and the declaration's
own reason -- a count with no class name cannot be acted on -- no longer has a
subject. Removed in this commit with that reason recorded, which is what the
check's message asks for.
The count declaration is KEPT AT ZERO rather than dropped: a page that stops
citing a figure when it clears cannot show a reader that it ever was not zero.
…85 BOTH FOUND BY THE NEW INSTRUMENT, not by reading. sentences-at-risk.mjs, run against the pre-move baseline, enumerated three sentences containing a span whose value the tag move changed. Two were the ones already fixed. The third was live on this branch and false: "npm's latest tag SITS INSIDE THAT BAND, at 1.0.0-rc.21" rc.21 is not inside rc.9 through rc.12. The span updated itself to rc.21 and the sentence around it did not, which is the exact class this branch already corrected twice and missed a third time. Now reads "no longer points inside that band". THE INSTRUMENT FOUND IN ONE RUN WHAT THREE READINGS OF THE SAME SECTION DID NOT. AND A MALFORMED TAG, ON MASTER, SINCE #85: <p data-derived-claim="...latest-does-not-export(resolutionPayload)" <strong> The closing angle bracket is missing. #85 added the marker by replacing '<p>' with '<p ' + attribute + ' ', which drops the '>'. The sibling <h4> marker was added by a different substitution and is well formed, which is why one is broken and one is not. It has been on the served page since #85 merged. NOTHING CAUGHT IT: no check in this repository parses HTML, so a broken tag is invisible to all fourteen. A browser recovers from it, which is why it is invisible to a reader too. Found only because the sentence beside it was being read for a different reason. That is not a method.
ONE COMMIT, because they cannot land separately. Measured, not assumed: with the
expectations changed and the lockfile still at rc.12, verify-published-credentials
returns 1, because rc.12 cannot verify the four. An expectation is a statement
about the version being run, so it moves when the version does.
THE FOUR
verify-samples/ppp-verdict-released.json
verify-samples/ppp-verdict-denied-ceiling.json
verify-samples/ppp-probe-a-verdict-release-above-escalation.json
verify-samples/ppp-probe-b-verdict-release-above-ceiling.json
before allow: false
reasonContains "(op.evaluation.verdict.v3); the record states
construction op.evaluation.verdict.v4"
knownIssue VERDICT-PAYLOAD-VERSION-PIN
after allow: true
reasonContains "signature verifies over the payload this build
rebuilds (op.evaluation.verdict.v4)"
knownIssue removed
THE EXPECTATIONS CHANGED BECAUSE THE VERSION AT latest CHANGED, NOT BECAUSE THE
ENGINE CHANGED. The records are signed under op.evaluation.verdict.v4 and were
always sound. rc.12 rebuilds v3 and cannot verify them; rc.21 rebuilds v4 and
does. Nothing about the artifacts moved.
The reasonContains strings named both version tokens deliberately so the pin
could not move in either direction without turning this check red. It moved, the
check went red, and this is the answer to it: the control working, not a finding
about the engine.
POPULATION SEARCHED: every tracked file with dist/ excluded, grepped for the
package name adjacent to a semver, plus every data-engine-version="current" span
in tracked HTML.
scripts/package.json 1.0.0-rc.12 -> 1.0.0-rc.21
scripts/package-lock.json 1.0.0-rc.12 -> 1.0.0-rc.21
eight "current" spans verify.html 3, index.html 2, docs.html 2,
check.html 1
EIGHT, NOT THE FIVE THE EARLIER SURVEY FOUND. That survey excluded verify.html's
three as parked; they are on master now, so the population grew by exactly those
three. The difference is not a correction to the earlier count, it is the same
method over a population that changed underneath it.
A NINTH THING, WHICH NO INSTRUMENT FOUND. verify-samples/README.md said "What the
pin does, and what it does not: scripts/package.json still pins 1.0.0-rc.12 ...
and credential-expectations.json still records the four allow:false outcomes."
This commit falsifies that paragraph. Rewritten here.
sentences-at-risk.mjs was run before committing and found NOTHING, correctly and
uselessly: it keys off results/ values and this change moves a pin and eight
spans, touching no results/ file. The population it derives is not the population
this change touches, and the README paragraph is in Markdown, which it does not
read at all. Its scope is one class of change, and this is a different one.
verify.html, index.html, docs.html and check.html all moved their git date with the version spans. make-sitemap.py is one commit behind by construction, so this follows rather than rides with them. Caught by tools/hooks/pre-push, which refused the push. First time that hook has stopped a real one rather than a probe.
…land/rc21-pin-and-section-02
✅ Deploy Preview for observerprotocol ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
This was referenced Aug 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #101 and #103. Ruling from Boyd: they are combined because they are one change to the world, and a repository state with one landed and not the other is a state that should not exist. The branch protection is correct and is not relaxed.
Why they are one landing
Each is red for the other's reasons. Measured by running the combinations, not predicted:
Figures in copy match results/: stalenpmLatest, two section-02 markerssync-engine-version: the pin driftnpmLatest#101 needs the pin, which is in #103. #103 needs the re-measurement and the marker swap, which are in #101. Neither can go green first, so neither can merge first.
What it contains
latestmoved to 1.0.0-rc.21, soresults/engine-payload-exports.jsonis re-measured against the registry./verifyswapped: heading, both consequence sentences, the marker (latest-does-not-export→latest-exports), the "What to do about it" paragraph, and thenpmLatestspans.<p data-derived-claim="…" <strong>, live on master since A marker whose subject is a claim, and a verdict before the echo #85 — the closing>was missing. No check parses HTML, so nothing saw it.scripts/package.json, its lockfile, and eightdata-engine-version="current"spans acrossverify.html,index.html,docs.html,check.html.allow: true, because the version atlatestchanged, not because the engine changed.verify-samples/README.md's pin paragraph, which this change falsified.One thing carried in that belongs to #102
scripts/sentences-at-risk.mjsis here, byte-identical to #102's copy. It arrived inb3752febecause I ran it from that working tree and staged it. If this lands, #102's diff is empty. Flagging it rather than leaving it to be discovered at merge.Verification
13/13 checks green locally on this branch.