docs(skill): a change notice is a hint, the fetch is the reading - #3024
Merged
Conversation
Section 453. Two measurements about the instrument rather than the page, taken while publishing the loop dashboard. A background change notice named the live artifact version as 1788433537-8a6c. The prefix is a unix timestamp: 11:05:37Z. The version actually live was 1788438525-553a, 12:28:45Z, established by the fetch and confirmed against a refusal message that had printed the same stamp earlier. The notice named a version 83 minutes older than the one it was announcing as current; merging onto it would have discarded the newer page. And the sequence that works: fetch, then every check and edit in one shell call, then an unbroken read of the fetched file, then publish. Whether the intervening shell call or the earlier failed publish spent the read credit is NOT established -- both were true in the failing attempt and were not separated -- so the recipe is written to be safe under either. Cost of guessing, measured: three full reads of a 2,886-line file in one session, two of them on refusals. Refs #3023
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
…e gate it is about Two corrections to section 453, both from evidence that arrived after it was written. A second change notice named 1788435789-8f03 (11:43:09Z) while the live version was 1788439613-732b (12:46:53Z). Two notices, both behind live, and ascending between themselves: 11:05, then 11:43. The ids are not wrong and the stream is not noise -- it replays real past publishes in order, lagging by over an hour. "The notice is wrong" would mean distrust it; "the notice is late" means it is reliable about the past and silent about the present. One data point could not tell those apart and the first version stopped there. And the entry this commit adds is the one the first commit did not: the PR failed `check` and `check-now-freshness`, the two required contexts that read docs/now/, because it carried no entry. A section about making a precondition the immediately preceding step, shipped without the precondition. Recorded rather than quietly fixed. Refs #3023
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-03 12:58:05 UTC
Summary
Seal Status
|
A third change notice arrived, naming 1788437269-721d (12:07:49Z) while live stayed 1788439613-732b (12:46:53Z). The three notices lag live by 101, 63 and 39 minutes -- ascending among themselves and CLOSING, which is what draining a backlog looks like and is stronger evidence for the mechanism than two points were. It also falsifies this section's own first correction, which said "lagging by over an hour" on the strength of those two points. Corrected in place with the series printed, so the next reader can disagree with the data rather than with a summary of it. Not changed: the 83 minutes in the paragraph above. That compares the first notice against the version live AT THAT MOMENT; the 101 compares the same notice against the version live NOW. Two readings of two different questions, and the smaller is not a correction of the larger. Refs #3023
Contributor
PR DashboardGenerated at: 2026-09-03 12:59:36 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Master took 453/454/455 while this branch was open -- the fourth section-number collision with the parallel session this session. Rebuilt from origin/master's copy with mine appended as 456, rather than resolving the conflict by hand: the first 11685 lines are byte-identical to master by sha256, so nothing of theirs moved. And the finding this pass is worth having. With four notices in hand I wrote down what the fifth would be: 1788439613-732b, my own publish, the last unannounced version -- then silence. It named 1788440807-d39e, 13:06:47Z: later than my own publish, and a version I had never seen. Wrong in its specific, and the reason makes the model cleaner. You are not notified of your own publish -- my 12:46:53Z was skipped by a stream that reported 12:28:45Z before it and 13:06:47Z after. Nothing was replaying my writes; the stream reports other writers and had caught up. The rule that falls out is the actionable half, and the section did not have it: a notice is worth acting on exactly when its stamp is LATER than your own last publish; an earlier stamp is backlog. Four notices here were backlog. The fifth was the first that meant the copy was really stale. Which also corrects this section's own earlier claim that a notice never means that -- written when every notice seen was backlog. Refs #3023
Contributor
PR DashboardGenerated at: 2026-09-03 13:09:31 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
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.
Section 453 of the ci-gates skill. Two measurements about the instrument
rather than about the page, taken while publishing the loop dashboard.
The notice was 83 minutes stale. A background change notification named
the live artifact version as
1788433537-8a6c. The prefix is a unixtimestamp:
11:05:37Z. The version actually live was1788438525-553a,12:28:45Z-- established by the fetch, and confirmed against a refusalmessage that had printed the same stamp earlier. Merging onto the version
the notice named would have discarded the newer page.
The read must be the last thing before the write. fetch, then every
check and edit in ONE shell call, then an unbroken read of the fetched
file, then publish.
Stated as not established: whether the intervening shell call invalidated
the read, or whether the failed publish before it had already spent the
credit. Both were true in the failing attempt and I did not separate them,
so the mechanism is unknown and the recipe is written to be safe under
either.
Cost of guessing, measured: three full reads of a 2,886-line file in one
session, two of them spent on refusals.
Section number checked against master (452 was the highest) rather than
against my own tree -- the previous three passes each collided with the
parallel session on exactly this.
No code changes;
compiler.rsuntouched, so the freeze hash is unaffected.Refs #3023
🤖 Generated with Claude Code