A correction can point at a document, not only a page - #101
Open
pip-robot[bot] wants to merge 1 commit into
Open
A correction can point at a document, not only a page#101pip-robot[bot] wants to merge 1 commit into
pip-robot[bot] wants to merge 1 commit into
Conversation
The registry could only guard claims that served on a route. It resolved every `where` entry to `src/app<path>/page.tsx` and walked only `src` for banned fragments, so a false claim on /privacy was listed, dated and guarded, and the identical false claim in ROADMAP.md was fixed silently. ROADMAP.md is linked from the blog and from the launch copy. A page titled "everything we have published that was wrong" that exempts it is describing our tooling rather than the reader. Two changes: - `where` also takes a GitHub blob URL pinned to a full commit SHA. A branch link is rejected on purpose: `blob/main/ROADMAP.md` shows the corrected text, so it would be evidence against the row it sits under. A pinned URL is checkable by anybody, forever, which a site path is not once the page is fixed and which a repo-relative path never was. - the `gone` walk covers ROADMAP.md and README.md as well as `src`, so a fragment is guarded in the file it was actually in. `resolveWhere` is unit-tested on all three forms rather than only through the live rows, because no row uses the document form yet: the two ROADMAP rows get backfilled alongside the next real correction rather than as a PR of their own. Nothing renders differently today. Every current row is a site path, its label is the path itself, and the pinned-evidence line only appears on a row that has a document in it. Verified against the built page.
Deploying pip-web with
|
| Latest commit: |
ff7c929
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://14f83928.pip-web-9oj.pages.dev |
| Branch Preview URL: | https://feat-corrections-where-can-b.pip-web-9oj.pages.dev |
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
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.
The corrections registry could only guard claims that served on a route.
corrections.test.tsresolved everywhereentry tosrc/app<path>/page.tsx, and thegonewalk read onlysrc. So a false claim on/privacyis listed, dated and guarded, and the identical false claim inROADMAP.mdgets fixed silently.ROADMAP.mdis linked from the blog and from the launch copy. A page titled everything we have published that was wrong that exempts it is a rule about our tooling rather than about the reader. Raised by the CMO on technology#75, sequenced behind #92 because it touches the same file.What changed
wherealso takes a GitHub blob URL pinned to a full commit SHA.The CMO proposed a repo-relative path. A URL is strictly better and it is why this is a
featrather than the smaller change asked for: a repo path is a thing only we can resolve, and a blob URL pinned to the commit that carried the wrong words is checkable by anybody, forever. A site path cannot do that, because by the time the row is fixed the page shows the correction. It also collapses thePERMALINKSask from technology#71 into the same mechanism instead of two.A branch link is rejected on purpose.
blob/main/ROADMAP.mdrenders the file as it is today, which for a fixed row is the correction, so it would quietly be evidence against the row it sits under.resolveWherereturnsnullfor it,nullfor another repository, andnullfor a short SHA, and the test turns each into a named failure.The
gonewalk coversROADMAP.mdandREADME.mdas well assrc, so a banned fragment is guarded in the file it was actually in. A separate test asserts those two files are still where the walk looks, because a rename would otherwise drop them from the walk without failing anything, which is the quiet way a guard stops guarding.Nothing renders differently today
No row uses the document form yet. Every current row is a site path, its label is the path itself, and the pinned-evidence line only appears on a row that has a document in it. Checked against the built page: the eight
<h2>headings on/blog/what-we-got-wrongare identical to what is live, and the string "The words as they served" appears zero times.That does mean the new branch would be dead code until somebody needed it, so
resolveWhereis unit-tested directly on all three forms rather than only through the live rows.The two ROADMAP rows are not in this PR. They get backfilled alongside the next real correction rather than as a PR made out of a backfill, which is how the CMO proposed it and I agree.
Gate
pnpm test:allgreen (552 tests) andpnpm buildgreen. No UI verification: there is no browser here. The evidence above is the built HTML, not a rendered page, and the pinned-link line has never been rendered by anything because no row triggers it.