docs(roadmap): save point carries the session's process facts, and v2.0.0 becomes a delivery vehicle - #674
Merged
Conversation
…ust its outcomes The block a cold session reads was still the release cut. It now records what shipped (#669, #670 merged; #671, #672 filed) and three things that cost real time, written so they are not relearned. 1. Loops end when the SHAPE changes, never when the patch gets better. Two treadmills tonight. The pointer guard ran four consecutive P1 rounds and ended in deletion under #530. "This fix ends the defect class" went 0-for-3 on one guard. 2. A mutation harness that has not been proven to mutate is not evidence. Three separate harness bugs each produced a clean-looking false result before one told the truth. Assert the mutation LANDED before trusting what the suite says about it. 3. Every gate rejection on #670 was legitimate, and a rebase killing a clearance is correct behaviour, not friction. Numbers stated exactly rather than approximately, because both trees are frozen: 1360 words to 449. test-doc-consistency 137/0.
The milestone carried the work for a major release and nothing that ships one. Every issue on it changed the harness; none bumped a version, wrote a CHANGELOG entry, pushed a tag, or verified a consumer could install the result. That gap is how v1.99.0 stopped being a coherent release. No new milestone. v2.0.0 — Consumer Safety Repairs already existed, and a second major-release milestone forks the queue. #673 fills the gap and #638 and #622 are attached rather than duplicated. The terminal gate is now in the milestone description instead of a session's memory: v2.0.0 ships on PROVEN CONSUMPTION (#545), not on open_issues == 0. Everything else there is agent-drivable; #545 is the maintainer's and cannot be done for them. v1.99.3 still ships first and separately — review-leg supervision makes every 2.0 review cycle cheaper, so folding it in inverts the order. test-doc-consistency 137/0.
…rreversible tag agent-drivable Both in-card, both mine, both caught by review. P1-1. The save point said "when a reviewer returns WRONG_SHAPE twice on the same component, escalate." SKILL.md:170 already routes the FIRST WRONG_SHAPE to the design authority with "do not patch." So the sentence raised the bar to two and weakened a standing rule — as a session note, inside a block whose own scope card excludes standing-ruling changes. Rewritten to cite SKILL.md:170 and frame rounds 3-4 as what following that rule LATE costs. P1-2. "Everything else on that milestone is agent-drivable" was false. #673 ends in `git push origin v2.0.0`. release.yml publishes on that push and npm forbids returning to 1.x, so the milestone has TWO maintainer-held steps, not one. ROADMAP, the milestone description and #673 all now say so, and the standing "publish without me" authorization is named explicitly rather than leaned on in silence — it was given for routine releases, and a major that cannot be unpublished is a different scale. test-doc-consistency 137/0.
…omes out Review challenged the tag gate I invented and won on both halves. The premise was wrong. npm refuses to republish an EXACT name/version — it does not forbid a later 1.x. Publishing 1.99.4 after 2.0.0 is legal, and `npm dist-tag` can move `latest` anywhere. So 2.0.0 is unrepeatable, not a one-way door, and a bad release is recoverable by publishing forward. That premise was the entire basis for narrowing the maintainer's standing publish authorization to "routine releases." The authorization was given unqualified. Inventing a caveat on a maintainer's behalf, and then justifying it with a fact nobody checked, is worse than either mistake alone — the caveat reads as deference while quietly rewriting what they authorized. Removed on all three surfaces: ROADMAP, the milestone description, and #673. The tag is agent-drivable like the rest of the milestone; the maintainer holds it only if they say so. #545 remains the one genuine gate, because consuming the harness in other repos is something nobody can do for them. Also corrected a stored memory carrying the same false claim, which would otherwise have re-seeded it next session. test-doc-consistency 137/0.
I asked the reviewer to hunt for a fourth surviving instance of the false npm
premise, on the grounds that a half-removed caveat is worse than the original
because the removal reads as done. It found two. Sweeping for a third found
one more the reviewer had not named.
ROADMAP.md:41 "that push is the point of no return, because npm forbids
returning to 1.x" REMOVED
ROADMAP.md:43 still opened "#545 is not the only maintainer-held step",
contradicting the rest of its own sentence REMOVED
#673 "Note on numbering" repeated the whole false claim REWRITTEN
The previous commit said the premise was removed on all three surfaces. It was
removed from the three places I had put it deliberately, and survived in the
places it had leaked to. Claiming completeness is a claim like any other and
should have been grepped, not asserted.
#673's note now names the false claim rather than quietly deleting it. It was
load-bearing — it was the justification for holding the tag back from the
maintainer's standing authorization — so a silent deletion would erase the
reason the correction matters.
Swept every surface independently: ROADMAP 0, milestone 0, #672 0, PR body 0,
repo-wide 0. #673 returns 1, which is the correction sentence itself, verified
by reading the line rather than trusting the count.
test-doc-consistency 137/0.
Owner
Author
|
CROSS-MODEL-CLEARANCE Seat 1, GPT-5.6 Sol at Four rounds, four P1s, every one accepted and repaired rather than argued. {"confidence": 99, "reviewer": "gpt-5.6-sol", "sha": "97e54f77e2d0d96ee27b2cbc788bd29b96ee3700", "verdict": "YES"} |
Owner
Author
|
CROSS-MODEL-CLEARANCE Seat 2, Fable 5 at Basis: (1) four adversarial rounds, every P1 accepted and repaired rather than {"confidence": 97, "reviewer": "fable-5", "sha": "97e54f77e2d0d96ee27b2cbc788bd29b96ee3700", "verdict": "YES"} |
This was referenced Aug 18, 2026
BaseInfinity
added a commit
that referenced
this pull request
Aug 19, 2026
* docs(roadmap): leave the save point accurate for a cold session Merged tonight: #669, #670, #674. Filed: #671, #672, #673. Nothing in flight. Records the reconciled cost-review outcome (#616): ten review passes across two docs PRs produced nine real P1 findings, three or four of the passes avoidable. The reconciled recommendation is base-freshness enforcement in run-review-leg.sh — fetch the authoritative ref, resolve the PR's actual base branch rather than assuming main, refuse a stale base. Sol argued against its own competing proposal because it "still trusts callers to enumerate every surface." Records the #644 measurement: three documented rules skipped in one session, none enforced by anything mechanical. That is evidence FOR the standing no-new-rules ruling, not against it — all three already existed and a fourth would not have helped. Records three habits that each cost a round: prove a mutation LANDED before trusting the suite, grep completeness instead of asserting it, and check claims about the outside world too. Every claim here was run before this commit. One was already wrong: I had told the maintainer "eight P1s" twice; the count is nine. test-doc-consistency 137/0. * docs(roadmap): two P1s — an imprecise claim, and a framing that flattered the ruling Both were things I asked the reviewer to check. Both were right. P1-1. "Every leg it ran certified a stale base" is false. #670's rounds 1-4 returned blocking findings and certified nothing; only round 5 certified. The branch WAS stale from birth and every leg reviewed a stale base — but attributing certification to non-certifying legs overstates it, in a block whose whole job is to be accurate for a reader who cannot check. P1-2. I framed three skipped rules as evidence FOR the standing no-new-rules ruling. That is the reading most convenient to me. The maintainer ruled against new mandatory steps in SKILL.md and against a commit-hook lane; I widened that into a general position and then claimed my own measurement supported it. The honest version keeps both halves. The evidence rejects MORE duplicate prose — all three rules already existed. It equally supports MECHANICALLY ENFORCING what is already written, which is a different proposition, and is exactly what #616's reconciled recommendation proposes. "Three written rules did not fire" is an argument about enforcement, not about how many rules exist. Corrected on #644 with a follow-up comment rather than an edit, so the claim and its retraction both stay in the record. test-doc-consistency 137/0. * docs(roadmap): third pass at one sentence — round 6 reviewed the REBASED tree Round 2 caught what round 1's fix still overstated. "Every leg reviewed a stale base" is false: round 6 was the rebase-confirm and reviewed the rebased tree. That leg is the whole reason the sentence exists, and the wording excluded it by asserting the opposite. The sentence now matches the record leg by leg: rounds 1-5 reviewed a stale base, 1-4 certified nothing, 5 certified one, and 6 re-reviewed the rebased tree after the merge was refused. Recorded against myself in the handoff: this took three passes because each time I fixed the exact word the reviewer quoted instead of re-deriving the claim from the record. "Every leg certified" -> "every leg reviewed" -> the actual per-round history. Two of those three passes were avoidable by checking the leg verdicts once. test-doc-consistency 137/0. * docs(roadmap): delete the leg count instead of fixing it a fourth time Counted the record properly this time: six legs with verdicts plus one transport-failed leg is seven executions, six of them on a stale base. The reviewer's count was right and mine was wrong for the third consecutive round. "every leg certified a stale base" wrong "every leg reviewed a stale base" wrong a per-round tally still miscounted Three rounds on one number is the shape signal, not an invitation to a fourth attempt. SKILL.md:170 routes a repeated shape failure to a design decision rather than another patch, and a prose claim that has survived three fixes deserves the same treatment. So the number comes out. What stays is the fact a cold reader actually needs: the branch was born stale, every review ran on a stale base until the merge was refused, and it cost a refused merge, two clearance reposts and an extra leg. The omission is marked as deliberate so nobody helpfully restores it. Same lesson as #670's deleted guard, reached four rounds slower because the surface was prose instead of a test. test-doc-consistency 137/0.
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.
Two things, one review, because they edit the same block.
1. The save point records HOW the session went, not just what shipped
#669and#670merged;#671and#672filed. Three process facts are nowwritten where a cold session reads them:
Loops end when the SHAPE changes, never when the patch gets better. Two
treadmills. The README pointer guard ran four consecutive P1 rounds and ended
in deletion under #530, routed to #672. Rounds 1-3 were one defect at narrowing
scope — assert a link exists in a REGION, which any sibling link satisfies on
the pointer's behalf. Round 4 changed the principle to check the CONSTRUCT,
closed that class, and opened a new one: the match ended before the file
boundary, so
AI_SETUP_LANES.md.bakpassed 137/0. "This fix ends the defectclass" went 0-for-3 on one guard.
A mutation harness not proven to mutate is not evidence. Three harness bugs
each produced a clean-looking false result before one told the truth: a
double-quoted perl expression let the shell eat backticks as command
substitution;
-0piparsespias-0's octal argument so-p/-ineverran; an unanchored substitution hit an identical string 13 lines above target.
Trusting the first run would have reported a real reviewer finding as
unreproducible and shipped a vacuous guard.
Every gate rejection on #670 was legitimate — verdict token, short SHA,
stale clearance base, branch behind
main, pending CI. A rebase killing aclearance is correct behaviour, not friction.
2. v2.0.0 becomes a delivery vehicle
The milestone carried the work for a major release and nothing that ships one.
No new milestone was created — it already existed, and a second would fork
the queue. #673 fills the gap (version bump, CHANGELOG, tag push, npm and
plugin verification). #638 and #622 are attached rather than duplicated.
The terminal gate now lives in the milestone description instead of a session's
memory: v2.0.0 ships on proven consumption (#545), not on
open_issues == 0.v1.99.3 ships first and separately.
Falsification
Every quantitative claim was run before this PR opened; see
.reviews/handoff.json. Two were sharpened by it: the section is exactly1360 -> 449 words, and the milestone's "10 open" vs my "9 issues" was PR #615,
not a miscount — which is why the issue-only listing disagreed.
test-doc-consistency137/0. Prose only; no guard added or removed, so thereis no RED to write.