Both pins take core 0.17.0, and the ledger check stops racing the fetch - #168
Merged
Conversation
The profile's tagline is the claim now rather than a description of the person, which core 0.17.0 makes room for and the instance took, so the model page and every page drawing the profile show it. Both pins move together because both point at the same release: the commit in source.json and the tag the parser comes by. The kinds check was reading the page before it had one. The ledger has been built from a fetched model.json since design v0.55.0, so a goto resolves before there is anything to read, and the check written for that parameter this morning asserted against the page as it was a moment earlier. It passed on the run that shipped it and failed on the run after this re-pin, which is what a race looks like from the outside. Both of its gotos now wait for a row to exist. Verified: npm run verify passes three times running against a served copy, where it failed once before the wait; model:check, pages:check, design:check, pin:check, og:check after npm run og, test:og, test:build, test:dupes, conventions-check and conventions-sync check all pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
The profile's tagline is the claim now rather than a description of the person. Core 0.17.0 makes room for a tagline that states the claim the work makes, on the condition that the model holds that claim elsewhere, and the instance took it — so the model page and every page drawing the profile show
Building fast is solved. Deciding well is not.in place of the previous description. Both pins move together because both point at the same release: the commit insource.jsonand the tag the parser comes by.A check written this morning was racing and this re-pin is what caught it. The timeline's ledger has been built from a fetched
model.jsonsince design v0.55.0 rather than from a block the page carries, so agotoresolves before there is anything to read. The?kinds=assertions added in #166 read the page as it was a moment earlier and passed on the run that shipped them; the first run after this re-pin failed with the filter reading "All kinds". Both of that check'sgotocalls now wait for a row to exist before reading.Worth naming because the class is not obvious: every assertion in that block reads state the page writes after the fetch lands, and nothing in the check said so. The failure looks like a broken feature rather than a broken test.
Verified: npm run verify passes three times running against a served copy, where it failed once before the wait was added; model:check, pages:check, design:check, pin:check, og:check after npm run og, test:og, test:build, test:dupes, conventions-check and conventions-sync check all pass. Two cards re-rendered and only their stamps moved.
🤖 Generated with Claude Code