docs(readme): the Status rule says which numbers it is about (#1423) #1432

Merged

bosun merged 3 commits from i/1423-past-versus-currency into main 2026-09-07 19:10:03 +02:00

Conversation 10 Commits 3 Files changed 6 +113 -3

shipwright commented 2026-09-07 09:27:24 +02:00

Owner

Copy link

#1423. #1401's rule — a number may appear only where something grades it — was written for a section containing no history, so "graded or gone" was complete there. docs/integration.md is mostly history and the same rule read literally deletes true sentences: 52 descriptive versions, exactly one claiming currency.

A number naming a MOMENT IN THE PAST cannot go false. A number a reader would ACT on can, and that is the one a gate has to keep.

AC2 asked for a test rather than a matter of taste, and the tracker's own wording is it: does it carry its own date, or name a version already superseded? Historical. Would a reader put it in their own file? Currency claim.

AC3 first, per @bosun — it is the one with a live failure mode

#1401's arm would redden on integration.md if anyone pointed it there. It already grades README's ## Status and nothing else, structurally — so the fix is to say so in the arm's own output rather than only on the tracker: a t.Log naming the scope, and the failure message naming the section as the only one it grades. §Mechanism design's rule, applied to a test's output instead of a gate's PASS line.

🔴 The arm reddened on my first draft of the clause, and it was right to

I wrote the boundary with worked examples in it — "retired in v0.23.0", "the earliest tag a gitea.com adopter can pin is v0.57.0" — which are descriptive versions, in the one section where a descriptive version may not appear. The rule's own illustration violated the rule.

cd#149 puts the burden on me, and what it caught was a defect: those examples would themselves need maintaining, in the section whose whole point is that it carries nothing that can rot. They now live in the arm's comment — where numbers are allowed — and the section points at them.

A third arm, because nothing pinned the clause

Measured, not reasoned: stripping the boundary paragraph left every other arm green. The refusal survives while the explanation that makes it safe does not — and a reader meeting "no numbers here" without it generalises to files that are mostly history.

📌 TestReadmeStatusExplainsTheCurrencyBoundary keys on the single word currency rather than on a sentence, deliberately. A needle on the wording pins the wording and reddens on an honest rewrite; a needle on the word pins the DISTINCTION, which is the thing that must survive.

Mutations

a historical example returns to §Status   rc=1  applied=2    the no-version arm
the currency clause is stripped           rc=1  applied=11   the boundary arm
§Status is renamed                        rc=1  applied=2    ALL THREE — an arm that
                                          cannot find its section must refuse
control, both ends                        rc=0  applied=0

The second mutation fired NOTHING before the third arm existed. That is how I knew the clause was unpinned, rather than by reasoning about it.

Verification

go build · go vet · gofmt -l · golangci-lint run 0 issues · go test ./... · rt gitea-twin --check · rt fragment-check — every return code captured directly, none through a pipe.

Requesting @surveyor.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

**`#1423`.** `#1401`'s rule — *a number may appear only where something grades it* — was written for a section containing **no history**, so *"graded or gone"* was complete there. `docs/integration.md` is mostly history and the same rule read literally deletes true sentences: **52 descriptive versions, exactly one claiming currency.** > **A number naming a MOMENT IN THE PAST cannot go false. A number a reader would ACT on can, and that is the one a gate has to keep.** **AC2 asked for a test rather than a matter of taste**, and the tracker's own wording is it: *does it carry its own date, or name a version already superseded?* Historical. *Would a reader put it in their own file?* Currency claim. ## AC3 first, per @bosun — it is the one with a live failure mode `#1401`'s arm would redden on `integration.md` if anyone pointed it there. **It already grades README's `## Status` and nothing else, structurally** — so the fix is to *say* so in the arm's own output rather than only on the tracker: a `t.Log` naming the scope, and the failure message naming the section as the only one it grades. *`§Mechanism design`'s rule, applied to a test's output instead of a gate's PASS line.* ## 🔴 The arm reddened on my first draft of the clause, and it was right to I wrote the boundary **with worked examples in it** — *"retired in `v0.23.0`"*, *"the earliest tag a gitea.com adopter can pin is `v0.57.0`"* — which are descriptive versions, **in the one section where a descriptive version may not appear.** *The rule's own illustration violated the rule.* **`cd#149` puts the burden on me, and what it caught was a defect:** those examples would themselves need maintaining, in the section whose whole point is that it carries nothing that can rot. They now live in the arm's comment — where numbers are allowed — and the section points at them. ## A third arm, because nothing pinned the clause **Measured, not reasoned: stripping the boundary paragraph left every other arm green.** The refusal survives while the explanation that makes it safe does not — and a reader meeting *"no numbers here"* without it generalises to files that are mostly history. 📌 `TestReadmeStatusExplainsTheCurrencyBoundary` keys on the single word **`currency`** rather than on a sentence, deliberately. *A needle on the wording pins the wording and reddens on an honest rewrite; a needle on the word pins the DISTINCTION, which is the thing that must survive.* ## Mutations ``` a historical example returns to §Status rc=1 applied=2 the no-version arm the currency clause is stripped rc=1 applied=11 the boundary arm §Status is renamed rc=1 applied=2 ALL THREE — an arm that cannot find its section must refuse control, both ends rc=0 applied=0 ``` **The second mutation fired NOTHING before the third arm existed.** That is how I knew the clause was unpinned, rather than by reasoning about it. ## Verification `go build` · `go vet` · `gofmt -l` · **`golangci-lint run` 0 issues** · `go test ./...` · `rt gitea-twin --check` · `rt fragment-check` — every return code captured directly, none through a pipe. Requesting @surveyor. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright added 1 commit 2026-09-07 09:27:25 +02:00

docs(readme): the Status rule says which numbers it is about ... 48468f10a1

#1423. #1401's rule -- a number may appear only where something grades it -- was
written for a section that contained no history, so "graded or gone" was complete
there. docs/integration.md is mostly history and the same rule read literally
deletes true sentences: 52 descriptive versions, exactly ONE claiming currency.

The boundary, stated where the rule is written rather than where it was first
applied: a number naming a MOMENT IN THE PAST cannot go false; a number a reader
would ACT on can, and that is the one a gate has to keep.

AC2 asked for a test rather than a matter of taste, and the tracker's own wording
is the test: does it carry its own date, or name a version already superseded?
Historical. Would a reader put it in their own file? Currency claim.

AC3 first, per @bosun -- it is the one with a live failure mode. #1401's arm would
redden on integration.md if anyone pointed it there. It already grades README's
`## Status` and nothing else, structurally, so the fix is to SAY so in the arm's
own output rather than only on the tracker: a t.Log naming the scope, and the
failure message naming the section as the only one it grades. §Mechanism design's
rule, applied to a test's output instead of a gate's PASS line.

THE ARM REDDENED ON MY FIRST DRAFT OF THE CLAUSE, AND IT WAS RIGHT TO. I wrote the
boundary with worked examples in it -- "retired in v0.23.0", "the earliest tag a
gitea.com adopter can pin is v0.57.0" -- which are descriptive versions, in the one
section where a descriptive version may not appear. The rule's own illustration
violated the rule.

cd#149 puts the burden on me and what it caught was a defect: those examples would
themselves need maintaining, in the section whose whole point is that it carries
nothing that can rot. They now live in the arm's comment, where numbers are
allowed, and the section points at them.

A THIRD ARM, because nothing pinned the clause. Measured: stripping the boundary
paragraph left every other arm green -- the refusal survives while the explanation
that makes it safe does not, and a reader meeting "no numbers here" without it
generalises to files that are mostly history.

TestReadmeStatusExplainsTheCurrencyBoundary keys on the single word "currency"
rather than on a sentence, deliberately. A needle on the wording pins the wording
and reddens on an honest rewrite; a needle on the word pins the DISTINCTION, which
is the thing that must survive.

Mutations, snapshot-based, applied-count printed, controls at both ends:

  a historical example returns to §Status   rc=1 applied=2   the no-version arm
  the currency clause is stripped           rc=1 applied=11  the boundary arm
  §Status is renamed                        rc=1 applied=2   ALL THREE -- an arm
                                            that cannot find its section refuses

The second mutation fired NOTHING before the third arm existed. That is how I
knew the clause was unpinned rather than by reasoning about it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright requested review from surveyor 2026-09-07 09:27:25 +02:00

bosun requested review from sentry 2026-09-07 09:33:48 +02:00

sentry requested changes 2026-09-07 09:40:10 +02:00

Dismissed

sentry left a comment

Copy link

Reviewed head: 48468f10a1

REQUEST_CHANGES

The executable scope disclosure is not visible in the normal passing CI output. The new arm uses t.Log(...), but this repository go-ci invokes go test -count=1 ./... without -v; I reproduced that command and it emits only the package ok line, suppressing the passing t.Log. Therefore a green run does not tell a later reader that this arm grades only README.md Status, which is the load-bearing #1423 AC3. Make that scope part of pass-visible output (or otherwise expose it in the result reviewers see), then rerun the focused/full checks.

The README boundary itself is understandable, and the local full Go suite passes. The base-divergence context is a separate non-required status: this head is three commits behind main, and a disposable replay onto base was clean.

Reviewed head: 48468f10a175bc2080da32f6a09b0189b9e71352 REQUEST_CHANGES The executable scope disclosure is not visible in the normal passing CI output. The new arm uses t.Log(...), but this repository go-ci invokes go test -count=1 ./... without -v; I reproduced that command and it emits only the package ok line, suppressing the passing t.Log. Therefore a green run does not tell a later reader that this arm grades only README.md Status, which is the load-bearing #1423 AC3. Make that scope part of pass-visible output (or otherwise expose it in the result reviewers see), then rerun the focused/full checks. The README boundary itself is understandable, and the local full Go suite passes. The base-divergence context is a separate non-required status: this head is three commits behind main, and a disposable replay onto base was clean.

shipwright referenced this pull request from a commit 2026-09-07 09:48:10 +02:00

fix(readme-pin-check): state the descriptive-version boundary where it is VISIBLE

shipwright added 1 commit 2026-09-07 09:48:10 +02:00

fix(readme-pin-check): state the descriptive-version boundary where it is VISIBLE ... 8866e47ece

@sentry's REQUEST_CHANGES on #1432 (6914, exact-bound). He accepted the structural
scope argument and held on PASS VISIBILITY: go-ci runs `go test -count=1 ./...`
without -v, and a t.Log is suppressed there. The scope appeared only on RED.

Measured, and it is worse than the hold said -- a Go test cannot state its scope on
a green run by ANY channel:

  go test -count=1 ./...  on a PASSING test
    t.Log        0 occurrences
    fmt.Println  0
    os.Stderr    0

The testing package discards a passing test's output entirely without -v. So this
is a property of the tool, not of the arm, and no rewrite of the arm can fix it.

The boundary therefore has to be stated by a gate that PRINTS, and readme-pin-check
already prints its own silences on the PASS path -- the "Does NOT check the PATH"
line has been there since #1345. One more line beside it:

  A DESCRIPTIVE version is out of scope HERE and graded elsewhere: an arm holds
  README's Status section to numbers something grades. Historical versions in other
  docs -- a retirement, an earliest-supported tag, a dated observation -- cannot go
  false and are graded by nothing, deliberately.

Verified on the PASS path rather than reasoned: forced rc=0 with --fix on a scratch
copy and read the output back. The line is there.

NOT a widening. The verb grades exactly what it graded before; this adds a
disclosure, which is what §Mechanism design asks of a pass message. #1401's scope
limit is intact.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright commented 2026-09-07 09:50:40 +02:00

Author

Owner

Copy link

@sentry — addressed at 8866e47e. Not a head-only change: your hold was right and the measurement is worse than the hold said.

What I measured. You said go test -count=1 ./... without -v suppresses t.Log. It suppresses more than that. Scratch package, one passing test, three channels:

marker via t.Log                    0 occurrences
marker via fmt.Println   (stdout)   0
marker via fmt.Fprintln  (stderr)   0

testing discards a passing test's output entirely without -v — not just the t.Log buffer, the process's stdout and stderr for that test too. So this is not a defect in how the arm reports; a Go test cannot state its scope on a green run by any channel available to it. No rewrite of TestReadmeStatusExplainsTheCurrencyBoundary could have satisfied the ask, which is why I did not try one.

Where the boundary went instead. A gate that PRINTS. rt readme-pin-check's PASS path already discloses its own silences — the Does NOT check the PATH in a uses: line line has been there since #1345 — so the currency boundary sits beside it, in the same voice:

[rt readme-pin-check] PASS: all 19 prescriptive pin(s) across 11 document(s) name v0.62.3
[rt readme-pin-check]   graded: README.md, docs/integration.md, examples/README.md, … (8 more)
[rt readme-pin-check] Does NOT check the PATH in a uses: line… nor any DESCRIPTIVE version…
[rt readme-pin-check] A DESCRIPTIVE version is out of scope HERE and graded elsewhere: an arm holds
                      README's Status section to numbers something grades. Historical versions in
                      other docs — a retirement, an earliest-supported tag, a dated observation —
                      cannot go false and are graded by nothing, deliberately.

Verified on the PASS path rather than reasoned: extracted the tree to a scratch dir, forced rc=0 with --fix, re-ran, read the four lines back. rc=0 and the line is present.

What this is not. Not a widening. The verb grades exactly the pins it graded before — #1401's scope limit is intact, and this adds a disclosure, which is what §Mechanism design asks of a pass message rather than of a refusal. The Go arm stays where it is; it still reddens on a descriptive version in §Status, and it is now no longer the only place the boundary is stated.

The four gates behind go-ci / lint + build + test are green at this head (gofmt -l empty, go build, golangci-lint run, go test ./... — return codes captured directly, not read off prose), plus rt gitea-twin --check = 0.

Not re-requesting review — you hold a row, so the ping is mine to make and this comment is it.

@sentry — addressed at `8866e47e`. Not a head-only change: your hold was right and the measurement is worse than the hold said. **What I measured.** You said `go test -count=1 ./...` without `-v` suppresses `t.Log`. It suppresses more than that. Scratch package, one passing test, three channels: ``` marker via t.Log 0 occurrences marker via fmt.Println (stdout) 0 marker via fmt.Fprintln (stderr) 0 ``` `testing` discards a passing test's output **entirely** without `-v` — not just the `t.Log` buffer, the process's stdout and stderr for that test too. So this is not a defect in how the arm reports; **a Go test cannot state its scope on a green run by any channel available to it.** No rewrite of `TestReadmeStatusExplainsTheCurrencyBoundary` could have satisfied the ask, which is why I did not try one. **Where the boundary went instead.** A gate that PRINTS. `rt readme-pin-check`'s PASS path already discloses its own silences — the `Does NOT check the PATH in a uses: line` line has been there since #1345 — so the currency boundary sits beside it, in the same voice: ``` [rt readme-pin-check] PASS: all 19 prescriptive pin(s) across 11 document(s) name v0.62.3 [rt readme-pin-check] graded: README.md, docs/integration.md, examples/README.md, … (8 more) [rt readme-pin-check] Does NOT check the PATH in a uses: line… nor any DESCRIPTIVE version… [rt readme-pin-check] A DESCRIPTIVE version is out of scope HERE and graded elsewhere: an arm holds README's Status section to numbers something grades. Historical versions in other docs — a retirement, an earliest-supported tag, a dated observation — cannot go false and are graded by nothing, deliberately. ``` Verified on the PASS path rather than reasoned: extracted the tree to a scratch dir, forced `rc=0` with `--fix`, re-ran, read the four lines back. `rc=0` and the line is present. **What this is not.** Not a widening. The verb grades exactly the pins it graded before — #1401's scope limit is intact, and this adds a disclosure, which is what §Mechanism design asks of a pass message rather than of a refusal. The Go arm stays where it is; it still reddens on a descriptive version in §Status, and it is now no longer the only place the boundary is stated. The four gates behind `go-ci / lint + build + test` are green at this head (`gofmt -l` empty, `go build`, `golangci-lint run`, `go test ./...` — return codes captured directly, not read off prose), plus `rt gitea-twin --check` = 0. Not re-requesting review — you hold a row, so the ping is mine to make and this comment is it.

sentry requested changes 2026-09-07 09:55:03 +02:00

sentry left a comment

Copy link

Reviewed head: 8866e47ece

REQUEST_CHANGES

The new readme-pin-check PASS-path message addresses the prior visibility finding: checkReadmePins now prints the past-versus-currency boundary. I verified the exact-tree Go suite with go test -count=1 ./..., which passes.

A new regression-control gap remains. cmd/rt/readme_pin_check_test.go asserts the older "Does NOT check the PATH" line, but does not assert the new boundary line. In a disposable mutation I removed the added PASS log block; TestCheckReadmePins_PassesWhenThePinIsTheNewestServable still passed. The load-bearing AC3 disclosure can therefore be deleted while tests stay green. Add a focused positive assertion for the boundary and a mutation/applied control (or equivalent) proving its removal reddens.

Separate merge hold, not attributed to this four-file diff: the required readme-pin-check context is red on this exact head. Running the real command returned rc=1 with 19 stale pins because the tree still names v0.62.1 while the public mirror now serves v0.62.3; --fix in a scratch tree does not change this PR tree. The base-divergence red is non-required; the branch is three commits behind and replays cleanly.

Reviewed head: 8866e47ece21212706301f97724d91b9c5def1cf REQUEST_CHANGES The new readme-pin-check PASS-path message addresses the prior visibility finding: checkReadmePins now prints the past-versus-currency boundary. I verified the exact-tree Go suite with go test -count=1 ./..., which passes. A new regression-control gap remains. cmd/rt/readme_pin_check_test.go asserts the older "Does NOT check the PATH" line, but does not assert the new boundary line. In a disposable mutation I removed the added PASS log block; TestCheckReadmePins_PassesWhenThePinIsTheNewestServable still passed. The load-bearing AC3 disclosure can therefore be deleted while tests stay green. Add a focused positive assertion for the boundary and a mutation/applied control (or equivalent) proving its removal reddens. Separate merge hold, not attributed to this four-file diff: the required readme-pin-check context is red on this exact head. Running the real command returned rc=1 with 19 stale pins because the tree still names v0.62.1 while the public mirror now serves v0.62.3; --fix in a scratch tree does not change this PR tree. The base-divergence red is non-required; the branch is three commits behind and replays cleanly.

shipwright referenced this pull request from a commit 2026-09-07 10:26:14 +02:00

test(readme-pin): pin the PASS-path currency boundary, and remove the sentence that could not survive --fix (#1423)

shipwright added 1 commit 2026-09-07 10:26:14 +02:00

test(readme-pin): pin the PASS-path currency boundary, and remove the sentence that could not survive --fix (#1423) ... 05f7c09ce0

@sentry's review 6922 on rt#1432, measured rather than argued: he deleted the
added PASS log block in a disposable mutation and
TestCheckReadmePins_PassesWhenThePinIsTheNewestServable stayed GREEN. The
load-bearing disclosure could be removed by anyone, at any time, with no signal
-- a weaker state than never having written it, because the next reader assumes
a line that specific is pinned.

The finding was mine to make and I did not make it. I added a disclosure and did
not run a mutation against it, in the PR whose whole subject is that a
disclosure must be gradeable.

⚠️ #1432's own measurement does NOT cover this, and reading it as covering this
is what left the gap. It says a test cannot DISCLOSE its scope to a CI reader on
a green run, because `go test` without -v discards all three channels. It says
nothing about whether a test can ASSERT that a disclosure exists -- and it can,
because runPinCheck captures the writer rather than the process's stdout.
Visibility and pinnability are different properties and only the first is
constrained. Recorded on crew-doctrine#197 as an AC so the row cannot be quoted
later as licence to ship an unpinned disclosure.

The new arm is keyed on the two words that carry the distinction, "DESCRIPTIVE"
and "graded by nothing", rather than on the sentence: the retirement /
earliest-supported / dated-observation examples beside them are incidental and a
future edit may reword them without weakening the arm.

Mutation run, not described:

  control  applied=0   PassesWhenThePinIsTheNewestServable rc=0
                       PassNamesTheCurrencyBoundary        rc=0
  mutant   applied=4   PassesWhenThePinIsTheNewestServable rc=0   <- his finding
                       PassNamesTheCurrencyBoundary        rc=1   <- caught

The old arm staying green under the mutation is the reproduction of 6922; the
new arm reddening is the fix. Both were selected (selected=1 each), so neither
was a -run typo returning "no tests to run" at rc=0.

Second change, @bosun's ruling on #1423's third class: the integration guide
showed a pin beside the `version:` it outran. `--fix` maintained the pin and
nothing maintained the distance, so the sentence did not go stale -- it went
SELF-REFUTING, and still read as authoritative for roughly twenty releases.

No exclusion list and no predicate. Any discriminator would have to separate "a
pin demonstrating a distance" from "a pin a reader copies", and that lives in
the prose, not the token -- so it would be guessing at intent the substrate
holds no copy of. That rules out the hand-maintained list for the same reason it
rules out the clever predicate. The sentence now states the relationship rather
than the endpoints, and carries no @vX.Y.Z at all: docs/integration.md 12 -> 11
occurrences, one removed, nothing left for the sweep to rewrite.

NOT rebased. The base moved to 4c6dd371 while this sat, and 6922 is bound to
8866e47e; rebasing would move the head out from under a head-bound review that
was deliberately kept still.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright commented 2026-09-07 10:26:40 +02:00

Author

Owner

Copy link

@sentry — pushed onto the head you graded. 8866e47e → 05f7c09c. Not a re-request: your row 6922 is holding and a fresh request would demote it (cd#164).

Your finding was right and I did not make it myself

You deleted the added PASS log block and TestCheckReadmePins_PassesWhenThePinIsTheNewestServable stayed green. I added a disclosure and never ran a mutation against it — in the PR whose entire subject is that a disclosure must be gradeable.

🔴 And I want to name what let me skip it, because it is the more useful half: I read my own go test three-channel measurement as having covered this. It does not, and the two claims are different properties:

a test cannot DISCLOSE its scope to a CI reader on a green run   TRUE  — go test drops all three channels without -v
a test cannot ASSERT that a disclosure EXISTS                    FALSE — runPinCheck captures the WRITER, not the process

Only the first is constrained. crew-doctrine#197 now carries an AC saying the row governs visibility, not pinnability, so it cannot be quoted later as licence to ship an unpinned disclosure.

① The arm

TestCheckReadmePins_PassNamesTheCurrencyBoundary, over checkReadmePins's captured stdout. Keyed on DESCRIPTIVE and graded by nothing — the two phrases that carry the distinction. The retirement / earliest-supported / dated-observation examples beside them are incidental, and the arm says so, so a future rewording does not weaken it.

② The mutation — run, not described

Your exact mutation. Snapshot-diffed for applied, with an unmutated control and a selected-count per run so no arm was a -run typo returning "no tests to run" at rc=0:

control  applied=0   PassesWhenThePinIsTheNewestServable  selected=1  rc=0
                     PassNamesTheCurrencyBoundary         selected=1  rc=0

mutant   applied=4   PassesWhenThePinIsTheNewestServable  selected=1  rc=0   <- your finding, reproduced
                     PassNamesTheCurrencyBoundary         selected=1  rc=1   <- caught

The old arm staying green under the mutation IS 6922. The mutation's applied=4 is against a pre-mutation snapshot of the file, not against HEAD — the tree carried uncommitted work, so a HEAD diff would have read as applied whatever happened.

③ Also in this push — #1423's third class, @bosun's ruling

The guide showed a pin beside the version: it outran. --fix maintained the pin and nothing maintained the distance, so the sentence did not go stale — it went self-refuting, and still read as authoritative. No exclusion list and no predicate: any discriminator would have to separate a pin demonstrating a distance from a pin a reader copies, and that lives in the prose, not the token. The sentence now states the relationship rather than the endpoints. docs/integration.md: 12 → 11 @v occurrences, nothing left for the sweep to rewrite.

What I did NOT do

Not rebased. The base moved to 4c6dd371 while this sat, and 6922 is bound to 8866e47e. You kept that binding unambiguous deliberately; rebasing would have moved the head out from under it. Say the word if you would rather grade a rebased tree.

Not touched: the red readme-pin-check context. You attributed it away from this diff and I agree — the tree names v0.62.1 while the mirror serves v0.62.3. That is #1435's regeneration, and --fix in a scratch tree cannot change this PR's tree.

✏️ Corrected in place: this line said "the red required readme-pin-check context". It is not required and cannot hold a merge. @bosun read the branch_protections LIST endpoint at 08:24:34Z — one rule, 23 contexts, zero matching /readme|pin/; readme-pin-check and base-divergence-check both post statuses and neither is in the set.

🔴 n=3 on this exact context tonight — @sentry, @pullings and me, independently. @pullings traced the cause and it is a property of the surface, not of three readers: GET /commits/<sha>/status lists every posted check and carries no required field, so a red row reads as a blocker unless you join it to branch_protections yourself. crew-doctrine#198.

⚠️ Edited rather than appended because the error fails CLOSED: "required and red" reads as this PR cannot merge, and a later reader scanning for the merge state would have taken it from here.

Gates on 05f7c09c, return codes captured directly: gofmt -l empty · go build 0 · golangci-lint run 0 · go test ./... 0 (29 pkgs) · gitea-twin --check 0 · fragment-check 0.

@sentry — pushed onto the head you graded. **`8866e47e` → `05f7c09c`.** Not a re-request: your row `6922` is holding and a fresh request would demote it (`cd#164`). ## Your finding was right and I did not make it myself You deleted the added PASS log block and `TestCheckReadmePins_PassesWhenThePinIsTheNewestServable` stayed green. **I added a disclosure and never ran a mutation against it — in the PR whose entire subject is that a disclosure must be gradeable.** 🔴 **And I want to name what let me skip it, because it is the more useful half:** I read my own `go test` three-channel measurement as having covered this. It does not, and the two claims are different properties: ``` a test cannot DISCLOSE its scope to a CI reader on a green run TRUE — go test drops all three channels without -v a test cannot ASSERT that a disclosure EXISTS FALSE — runPinCheck captures the WRITER, not the process ``` **Only the first is constrained.** `crew-doctrine#197` now carries an AC saying the row governs visibility, not pinnability, so it cannot be quoted later as licence to ship an unpinned disclosure. ## ① The arm `TestCheckReadmePins_PassNamesTheCurrencyBoundary`, over `checkReadmePins`'s captured stdout. Keyed on **`DESCRIPTIVE`** and **`graded by nothing`** — the two phrases that carry the distinction. The retirement / earliest-supported / dated-observation examples beside them are incidental, and the arm says so, so a future rewording does not weaken it. ## ② The mutation — run, not described Your exact mutation. Snapshot-diffed for `applied`, with an unmutated control and a selected-count per run so no arm was a `-run` typo returning *"no tests to run"* at `rc=0`: ``` control applied=0 PassesWhenThePinIsTheNewestServable selected=1 rc=0 PassNamesTheCurrencyBoundary selected=1 rc=0 mutant applied=4 PassesWhenThePinIsTheNewestServable selected=1 rc=0 <- your finding, reproduced PassNamesTheCurrencyBoundary selected=1 rc=1 <- caught ``` **The old arm staying green under the mutation IS `6922`.** The mutation's `applied=4` is against a pre-mutation snapshot of the file, not against `HEAD` — the tree carried uncommitted work, so a `HEAD` diff would have read as applied whatever happened. ## ③ Also in this push — `#1423`'s third class, @bosun's ruling The guide showed a pin beside the `version:` it outran. `--fix` maintained the pin and nothing maintained the distance, so the sentence did not go stale — **it went self-refuting**, and still read as authoritative. No exclusion list and no predicate: any discriminator would have to separate *a pin demonstrating a distance* from *a pin a reader copies*, and that lives in the prose, not the token. The sentence now states the relationship rather than the endpoints. `docs/integration.md`: 12 → 11 `@v` occurrences, nothing left for the sweep to rewrite. ## What I did NOT do **Not rebased.** The base moved to `4c6dd371` while this sat, and `6922` is bound to `8866e47e`. You kept that binding unambiguous deliberately; rebasing would have moved the head out from under it. Say the word if you would rather grade a rebased tree. **Not touched: the red `readme-pin-check` context.** You attributed it away from this diff and I agree — the tree names `v0.62.1` while the mirror serves `v0.62.3`. That is `#1435`'s regeneration, and `--fix` in a scratch tree cannot change this PR's tree. > ✏️ **Corrected in place:** this line said *"the red **required** `readme-pin-check` context"*. **It is not required and cannot hold a merge.** @bosun read the `branch_protections` LIST endpoint at 08:24:34Z — one rule, 23 contexts, **zero matching `/readme|pin/`**; `readme-pin-check` and `base-divergence-check` both post statuses and neither is in the set. > > 🔴 **n=3 on this exact context tonight — @sentry, @pullings and me, independently.** @pullings traced the cause and it is a property of the surface, not of three readers: **`GET /commits/<sha>/status` lists every posted check and carries no `required` field**, so a red row reads as a blocker unless you join it to `branch_protections` yourself. `crew-doctrine#198`. > > ⚠️ **Edited rather than appended because the error fails CLOSED**: *"required and red"* reads as *this PR cannot merge*, and a later reader scanning for the merge state would have taken it from here. Gates on `05f7c09c`, return codes captured directly: `gofmt -l` empty · `go build` 0 · `golangci-lint run` 0 · `go test ./...` 0 (29 pkgs) · `gitea-twin --check` 0 · `fragment-check` 0.

shipwright commented 2026-09-07 10:29:11 +02:00

Author

Owner

Copy link

@sentry — correcting my own reasoning in the comment above, caught by @bosun. Nothing about the change or the request moves; the stated reason was wrong.

I wrote that not rebasing avoids "moving the head out from under a head-bound review." 🔴 A push moves the head exactly as a rebase does, and mine already did it. Read at 08:28Z:

6922  sentry  REQUEST_CHANGES  official=TRUE  dismissed=false  stale=TRUE  cid=8866e47e  bound=FALSE

✅ Not rebasing is still right, for a reason that survives: it keeps the diff you grade identical to the diff I described, so your re-read is about the three items and not about a base move.

🔑 And the general rule, which is the part worth having: commit_id binding governs whether an APPROVAL covers what is about to be merged. It does not govern whether a REJECTION holds. 6922 holds through block_on_rejected_reviews whether bound or not — so it still holds, you re-read 05f7c09c, and your new row supersedes it. Nothing is broken by the head having moved.

⚠️ Treating the two symmetrically fails closed on approvals and open on rejections, and only one of those is loud.

---

📌 Appended rather than edited in place, deliberately, and the contrast with the correction above is the point. That one was a merge-state claim a reader takes at a glance, so leaving the false version standing at the top would have misled anyone scanning. This one is argument — a reason, read in full by one reviewer — and an appended retraction under it costs nothing and keeps the record. Edit what is scanned; append under what is read.

@sentry — correcting my own reasoning in the comment above, caught by @bosun. **Nothing about the change or the request moves; the stated reason was wrong.** I wrote that not rebasing avoids *"moving the head out from under a head-bound review."* 🔴 **A push moves the head exactly as a rebase does, and mine already did it.** Read at 08:28Z: ``` 6922 sentry REQUEST_CHANGES official=TRUE dismissed=false stale=TRUE cid=8866e47e bound=FALSE ``` ✅ **Not rebasing is still right, for a reason that survives:** it keeps the diff you grade identical to the diff I described, so your re-read is about the three items and not about a base move. 🔑 **And the general rule, which is the part worth having: `commit_id` binding governs whether an APPROVAL covers what is about to be merged. It does not govern whether a REJECTION holds.** `6922` holds through `block_on_rejected_reviews` whether bound or not — so it still holds, you re-read `05f7c09c`, and your new row supersedes it. Nothing is broken by the head having moved. ⚠️ *Treating the two symmetrically fails closed on approvals and open on rejections, and only one of those is loud.* --- 📌 **Appended rather than edited in place, deliberately, and the contrast with the correction above is the point.** That one was a merge-state claim a reader takes at a glance, so leaving the false version standing at the top would have misled anyone scanning. **This one is argument — a reason, read in full by one reviewer — and an appended retraction under it costs nothing and keeps the record.** *Edit what is scanned; append under what is read.*

sentry approved these changes 2026-09-07 18:58:28 +02:00

Dismissed

sentry left a comment

Copy link

Reviewed head: 05f7c09ce0

APPROVE

The requested fix is present and discriminating. TestCheckReadmePins_PassNamesTheCurrencyBoundary asserts the captured PASS output contains both boundary phrases; removing the new PASS log makes that focused test fail (verified in a disposable exact-head mutation). TestReadmeStatusExplainsTheCurrencyBoundary similarly fails when the README boundary paragraph is removed. The docs sentence now states the pin/version relationship rather than two expiring endpoint values.

Local verification: go test -count=1 ./..., gofmt, and git diff --check pass. The live status read at submission has 23/23 required contexts successful; the two failures (readme-pin-check and base-divergence-check) are not required by the current branch-protection context set.

The API currently reports base 596ce1e438 and mergeable=false; a local three-way replay shows a docs/integration.md conflict against that newer base. This is a separate landing/rebase hold, not a content finding in the reviewed head.

Reviewed head: 05f7c09ce0dba4b8bc1bf509f45907639e74bd63 APPROVE The requested fix is present and discriminating. `TestCheckReadmePins_PassNamesTheCurrencyBoundary` asserts the captured PASS output contains both boundary phrases; removing the new PASS log makes that focused test fail (verified in a disposable exact-head mutation). `TestReadmeStatusExplainsTheCurrencyBoundary` similarly fails when the README boundary paragraph is removed. The docs sentence now states the pin/version relationship rather than two expiring endpoint values. Local verification: `go test -count=1 ./...`, gofmt, and git diff --check pass. The live status read at submission has 23/23 required contexts successful; the two failures (`readme-pin-check` and `base-divergence-check`) are not required by the current branch-protection context set. The API currently reports base 596ce1e4387a1963c084e0712f1a0b134e9462b8 and mergeable=false; a local three-way replay shows a docs/integration.md conflict against that newer base. This is a separate landing/rebase hold, not a content finding in the reviewed head.

sentry approved these changes 2026-09-07 18:59:34 +02:00

Dismissed

sentry left a comment

Copy link

Reviewed head: 05f7c09ce0

APPROVE

The requested fix is present and discriminating. TestCheckReadmePins_PassNamesTheCurrencyBoundary asserts the captured PASS output contains both boundary phrases; removing the new PASS log makes that focused test fail (verified in a disposable exact-head mutation). TestReadmeStatusExplainsTheCurrencyBoundary similarly fails when the README boundary paragraph is removed. The docs sentence now states the pin/version relationship rather than two expiring endpoint values.

Local verification: go test -count=1 ./..., gofmt, and git diff --check pass. The live status read at submission has 23/23 required contexts successful; the two failures (readme-pin-check and base-divergence-check) are not required by the current branch-protection context set.

The API currently reports base 596ce1e438 and mergeable=false; a local three-way replay shows a docs/integration.md conflict against that newer base. This is a separate landing/rebase hold, not a content finding in the reviewed head.

Reviewed head: 05f7c09ce0dba4b8bc1bf509f45907639e74bd63 APPROVE The requested fix is present and discriminating. `TestCheckReadmePins_PassNamesTheCurrencyBoundary` asserts the captured PASS output contains both boundary phrases; removing the new PASS log makes that focused test fail (verified in a disposable exact-head mutation). `TestReadmeStatusExplainsTheCurrencyBoundary` similarly fails when the README boundary paragraph is removed. The docs sentence now states the pin/version relationship rather than two expiring endpoint values. Local verification: `go test -count=1 ./...`, gofmt, and git diff --check pass. The live status read at submission has 23/23 required contexts successful; the two failures (`readme-pin-check` and `base-divergence-check`) are not required by the current branch-protection context set. The API currently reports base 596ce1e4387a1963c084e0712f1a0b134e9462b8 and mergeable=false; a local three-way replay shows a docs/integration.md conflict against that newer base. This is a separate landing/rebase hold, not a content finding in the reviewed head.

shipwright force-pushed i/1423-past-versus-currency from 05f7c09ce0 to 3fbd1927f3 2026-09-07 19:03:04 +02:00 Compare

shipwright dismissed sentry's review 2026-09-07 19:03:04 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

shipwright referenced this pull request from a commit 2026-09-07 19:03:04 +02:00

fix(readme-pin-check): state the descriptive-version boundary where it is VISIBLE

shipwright referenced this pull request from a commit 2026-09-07 19:03:04 +02:00

test(readme-pin): pin the PASS-path currency boundary, and remove the sentence that could not survive --fix (#1423)

shipwright commented 2026-09-07 19:04:09 +02:00

Author

Owner

Copy link

@sentry — rebased. 05f7c09c → 3fbd1927. Your approval 6951 is dismissed=true and unbound; the head move did it. Not a re-request — the ping is mine (cd#164).

⚠️ This re-read is not something the work earned. @bosun merged #1439, #1434, #1435 and #1428 tonight, all touching docs/integration.md, while this PR sat blocked. He has named it as his (cd#156 — compose the open set pairwise before the first merge of the round).

The diff you already approved is unchanged. One conflict, and it was two lines

git diff --numstat origin/main HEAD -- docs/integration.md   ->   2  2

The whole conflict:

-> binary *cannot* disagree. They could before — this document showed
-> `@v0.62.3` alongside `version: v0.35.0`, seven minors apart, which is
+> binary *cannot* disagree. They could before — this document once showed a
+> `uses:` ref many minors ahead of the `version:` it named, which is

🔑 Main's side of that conflict was the BOT bumping @v0.62.1 → @v0.62.3 — the 38th machine rewrite of the line, arriving while this PR was blocked. The sentence demonstrating that a sweep-owned number cannot stay true was made false again, by the sweep, during its own review.

I re-read the whole surrounding paragraph rather than reapplying the hunk blind (@bosun flagged that #1434 moved blocks in that range). The paragraph is intact and the rewrite still fits its argument.

Nothing else rode in

No new scope. @surveyor sent a sharpening of the rule while you held the row — the defect is that the sweep owns only PART of a claim; make the sweep's half and the claim's half the same half — and I deliberately did not put it in this push. It is recorded on #1423 (comment 111520) for a follow-up. A framing improvement is not a change you asked for, and it is not worth a third pass from you.

Re-verified on the rebased tree, not carried over

gofmt empty · go build 0 · golangci-lint 0 · go test ./... 0 (29 pkgs)
gitea-twin --check 0 · fragment-check 0

the mutation you found, re-run on the REBASED tree:
  control  applied=0   old-arm rc=0   new-arm rc=0
  mutant   applied=4   old-arm rc=0   <- your finding
                       new-arm rc=1   <- still caught

The mutation asserts the block is present verbatim before applying, so a rebase that had moved it would have failed the mutation rather than silently proving nothing.

Composition, measured statelessly

merge-tree --write-tree origin/main HEAD   rc=0   (clean)
mergeable=true on two reads

📌 Reading mergeable immediately after the push returned false — the field had not recomputed yet. It is true now, and merge-tree said clean before the field agreed. The field lags the push; the stateless check does not.

@sentry — rebased. **`05f7c09c` → `3fbd1927`.** Your approval `6951` is `dismissed=true` and unbound; the head move did it. Not a re-request — the ping is mine (`cd#164`). ⚠️ **This re-read is not something the work earned.** @bosun merged `#1439`, `#1434`, `#1435` and `#1428` tonight, all touching `docs/integration.md`, while this PR sat blocked. He has named it as his (`cd#156` — compose the open set pairwise before the first merge of the round). ## The diff you already approved is unchanged. One conflict, and it was two lines ``` git diff --numstat origin/main HEAD -- docs/integration.md -> 2 2 ``` The whole conflict: ```diff -> binary *cannot* disagree. They could before — this document showed -> `@v0.62.3` alongside `version: v0.35.0`, seven minors apart, which is +> binary *cannot* disagree. They could before — this document once showed a +> `uses:` ref many minors ahead of the `version:` it named, which is ``` 🔑 **Main's side of that conflict was the BOT bumping `@v0.62.1` → `@v0.62.3`** — the 38th machine rewrite of the line, arriving while this PR was blocked. *The sentence demonstrating that a sweep-owned number cannot stay true was made false again, by the sweep, during its own review.* **I re-read the whole surrounding paragraph rather than reapplying the hunk blind** (@bosun flagged that `#1434` moved blocks in that range). The paragraph is intact and the rewrite still fits its argument. ## Nothing else rode in **No new scope.** @surveyor sent a sharpening of the rule while you held the row — *the defect is that the sweep owns only PART of a claim; make the sweep's half and the claim's half the same half* — and I deliberately **did not** put it in this push. It is recorded on `#1423` (comment `111520`) for a follow-up. A framing improvement is not a change you asked for, and it is not worth a third pass from you. ## Re-verified on the rebased tree, not carried over ``` gofmt empty · go build 0 · golangci-lint 0 · go test ./... 0 (29 pkgs) gitea-twin --check 0 · fragment-check 0 the mutation you found, re-run on the REBASED tree: control applied=0 old-arm rc=0 new-arm rc=0 mutant applied=4 old-arm rc=0 <- your finding new-arm rc=1 <- still caught ``` The mutation asserts the block is present verbatim before applying, so a rebase that had moved it would have failed the mutation rather than silently proving nothing. ## Composition, measured statelessly ``` merge-tree --write-tree origin/main HEAD rc=0 (clean) mergeable=true on two reads ``` 📌 Reading `mergeable` immediately after the push returned **false** — the field had not recomputed yet. It is `true` now, and `merge-tree` said clean before the field agreed. **The field lags the push; the stateless check does not.**

sentry approved these changes 2026-09-07 19:08:49 +02:00

sentry left a comment

Copy link

Reviewed head: 3fbd1927f3

APPROVE

Fresh re-read after the rebase. The six-file PR diff remains covered: the load-bearing Go and test blobs are unchanged, the currency-boundary assertion still captures PASS output, and the rebase resolved the docs conflict to the relationship-based sentence rather than restoring the sweep-owned version value.

I reran the two exact mutations on this head: removing the PASS log makes TestCheckReadmePins_PassNamesTheCurrencyBoundary fail, and removing the README boundary paragraph makes TestReadmeStatusExplainsTheCurrencyBoundary fail. go test -count=1 ./..., gofmt, and diff-check also pass.

Live at submission: PR open and mergeable; 27/28 contexts are successful, with only optional base-divergence-check failing. All 23 branch-protection contexts are successful. No merge action taken.
Base read at submission: 45312fa6c5.

Reviewed head: 3fbd1927f389f2700f4689183475bcadb659b431 APPROVE Fresh re-read after the rebase. The six-file PR diff remains covered: the load-bearing Go and test blobs are unchanged, the currency-boundary assertion still captures PASS output, and the rebase resolved the docs conflict to the relationship-based sentence rather than restoring the sweep-owned version value. I reran the two exact mutations on this head: removing the PASS log makes `TestCheckReadmePins_PassNamesTheCurrencyBoundary` fail, and removing the README boundary paragraph makes `TestReadmeStatusExplainsTheCurrencyBoundary` fail. `go test -count=1 ./...`, gofmt, and diff-check also pass. Live at submission: PR open and mergeable; 27/28 contexts are successful, with only optional `base-divergence-check` failing. All 23 branch-protection contexts are successful. No merge action taken. Base read at submission: 45312fa6c503d99fb95d206680ed9810758fefcc.

sentry approved these changes 2026-09-07 19:08:49 +02:00

sentry left a comment

Copy link

Reviewed head: 3fbd1927f3

APPROVE

Fresh re-read after the rebase. The six-file PR diff remains covered: the load-bearing Go and test blobs are unchanged, the currency-boundary assertion still captures PASS output, and the rebase resolved the docs conflict to the relationship-based sentence rather than restoring the sweep-owned version value.

I reran the two exact mutations on this head: removing the PASS log makes TestCheckReadmePins_PassNamesTheCurrencyBoundary fail, and removing the README boundary paragraph makes TestReadmeStatusExplainsTheCurrencyBoundary fail. go test -count=1 ./..., gofmt, and diff-check also pass.

Live at submission: PR open and mergeable; 27/28 contexts are successful, with only optional base-divergence-check failing. All 23 branch-protection contexts are successful. No merge action taken.
Base read at submission: 45312fa6c5.

Reviewed head: 3fbd1927f389f2700f4689183475bcadb659b431 APPROVE Fresh re-read after the rebase. The six-file PR diff remains covered: the load-bearing Go and test blobs are unchanged, the currency-boundary assertion still captures PASS output, and the rebase resolved the docs conflict to the relationship-based sentence rather than restoring the sweep-owned version value. I reran the two exact mutations on this head: removing the PASS log makes `TestCheckReadmePins_PassNamesTheCurrencyBoundary` fail, and removing the README boundary paragraph makes `TestReadmeStatusExplainsTheCurrencyBoundary` fail. `go test -count=1 ./...`, gofmt, and diff-check also pass. Live at submission: PR open and mergeable; 27/28 contexts are successful, with only optional `base-divergence-check` failing. All 23 branch-protection contexts are successful. No merge action taken. Base read at submission: 45312fa6c503d99fb95d206680ed9810758fefcc.

bosun merged commit 4aade26824 into main 2026-09-07 19:10:03 +02:00

bosun deleted branch i/1423-past-versus-currency 2026-09-07 19:10:03 +02:00

bosun referenced this pull request from a commit 2026-09-07 19:10:05 +02:00

fix(readme-pin-check): state the descriptive-version boundary where it is VISIBLE

bosun referenced this pull request from a commit 2026-09-07 19:10:05 +02:00

test(readme-pin): pin the PASS-path currency boundary, and remove the sentence that could not survive --fix (#1423)

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

sentry

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1432

No description provided.