feat(tri): print the line that repeats the reading, and give dated its own --as-of - #3043
Merged
Conversation
…its own --as-of
Section 461 gave one command an --as-of flag and made the flagless case
print a sentence: "this reading is NOT anchored, pass --as-of to fix it".
A sentence is something to agree with. Every count over the live backlog
now prints two lines instead, above the numbers rather than below:
read at 2026-09-03T18:27:56Z NOT PINNED -- this count changes on every open and close
re-take: tri issues numbers --as-of 2026-09-02 --limit 3039 (the most recent day that has ended)
The second line is the point. It names the most recent day that HAS
ENDED -- the only date --as-of accepts, since today is refused for having
a future end -- so the distance between what I have and what you can
check is one paste. And it is a fixed point: run what it suggests and the
reading it produces carries the identical re-take line, checked by
running it rather than reasoned about.
--as-of now exists on `tri issues dated` too, over the same rule. Half a
symmetry is worse than none: dated printed eight figures over the same
live backlog with no way to pin any of them. Completeness is asked of the
READ, before the as-of filter removes rows -- asking afterwards would see
a short page and call a truncated read complete, which is the guard
reporting backwards in the one case it exists for.
The first version of the re-take line suggested the limit the command had
just used, and that was wrong in precisely the case the line exists for.
Without --as-of the query is --state open and 489 rows fit under 500;
with it the query is --state all and there are 1486. So the suggestion
read `--as-of 2026-09-02 --limit 500`, and running it printed 500 under a
LOWER BOUND warning and 360 open, where the true figure is 484.
A helpful line, offered as the cure for unpinned numbers, handed the
reader a wrong one -- and section 462's truncation guard, written one
pass earlier for an unrelated reason, is what said so. That is the
argument for a guard that PRINTS rather than one that returns a bool: a
predicate in an `if` protects its caller, while a predicate that puts a
line in the output protects everything downstream, including a suggestion
written later by someone who forgot it existed.
The fix does not guess a bigger number. The suggested limit is the
largest issue number seen, because GitHub numbers issues and pull
requests from one sequence starting at 1, so the count can never exceed
the largest number.
One test assertion was wrong and the failure was mine:
`!s.contains("PINNED --")` fails on correct output, because "NOT PINNED
--" contains it. Four clauses mutated, four killed.
Skill sections 466 and 467.
Refs #2994
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
Contributor
PR DashboardGenerated at: 2026-09-03 18:34:53 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 3, 2026
gHashTag
added a commit
that referenced
this pull request
Sep 3, 2026
Fifth section-number collision on .claude/skills/ci-gates/SKILL.md: master took 466 and 467 in #3043 while this branch was open. Resolved by rebuilding from origin/master and re-appending my two sections as 468 and 469 -- the master prefix is byte-identical, and the file is 433 sections, all unique and ascending. 468 is "A lesson written down four times, and the command run anyway". 469 is "The machine that could not answer, and the population nobody asked".
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.
A stamp is a command, not a warning
§461 gave one command an
--as-offlag and made the flagless case print a sentence — this reading is NOT anchored, pass--as-ofto fix it. A sentence is something to agree with. Both counts over the live backlog now print two lines instead, above the numbers rather than below:The second line is the whole point. It names the most recent day that has ended — the only date
--as-ofwill accept, since today is refused for having a future end — so the distance between what I have and what you can check is one paste. A warning tells the reader their number is unpinned; this hands them the pinned one.And it is a fixed point. Run what it suggests and the reading it produces carries the identical
re-take:line, so the suggestion converges instead of sending the reader down a chain. Checked by running it, not reasoned about.--as-ofnow exists ontri issues datedas well — half a symmetry is worse than none;datedprinted eight figures over the same live backlog with no way to pin any of them. Completeness is asked of the read, before the as-of filter removes rows: asking afterwards would see a short page and call a truncated read complete, which is the guard reporting exactly backwards in the one case it exists for.The guard from the last pass caught the suggestion from this one
The first version of that
re-take:line suggested the limit the command had just used. It was wrong, and wrong in precisely the case the line exists for.--as-of--state open--as-of--state allSo the suggestion read
--as-of 2026-09-02 --limit 500, and running it printed:The true figure is 484. A helpful line, offered as the cure for unpinned numbers, handed the reader a wrong one — and §462's truncation guard, written one pass earlier for an unrelated reason, is what said so. Two rules from two passes; the second caught the first's mistake, and neither author was a person reading carefully.
That is the argument for a guard that prints rather than one that returns a bool. A predicate consulted in an
ifprotects its caller. A predicate that puts a line in the output protects everything downstream of the output, including a suggestion written later by someone who had forgotten it existed.The fix does not guess a bigger number: the suggested limit is the largest issue number seen, because GitHub numbers issues and pull requests from one sequence starting at 1, so the count can never exceed the largest number. Derived from the rows in hand — not a round number someone will have to raise next quarter.
One test assertion was wrong, and the failure was mine
assert!(!s.contains("PINNED --"))on the unpinned stamp fails on correct output:NOT PINNED --containsPINNED --. Replaced with the pinned form's own opening,as of, which the unpinned form never prints.cargo test -p tri— 522 passed, 0 failedRefs #2994