Repository navigation
docs(skill): keeping the branch fresh is what kept it from landing - #3166
Merged
Merged
Conversation
The landing loop merged the base whenever it was no longer an ancestor. Pushing restarts every check, and neighbouring sessions land pull requests faster than the checks finish, so the catch-up reset the very progress it was performed to protect. Observed one iteration apart: waiting on 2, caught up, waiting on 22. Being behind costs nothing until the moment of merge. Merge the base only when the checks are green AND mergeStateStatus is BEHIND -- when being behind is the sole remaining blocker. With that rule the same pull request landed on iteration 24, having caught up zero times; the previous rule had burned twelve iterations catching up. Refs #2994
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Sep 4, 2026
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
As written the section claimed the narrow rule landed #3160 with zero catch-ups, which is true and misleading: merging requires being up to date, and bringing the branch up to date restarts the checks, so a reset is unavoidable whenever master moves inside the final green window. What the rule changes is how many. The eager rule paid one reset per move of master at any time; the narrow rule pays at most one per green window. #3160's zero was luck -- master happened not to move in its last window. The next pull request, under the same rule, went BEHIND waiting:0, caught up, and came back BLOCKED waiting:22. Zero was luck. At most one is the guarantee. Refs #2994
Contributor
PR DashboardGenerated at: 2026-09-04 11:25:14 UTC
Summary
Seal Status
|
1 similar comment
Contributor
PR DashboardGenerated at: 2026-09-04 11:25:14 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-04 11:32:46 UTC
Summary
Seal Status
|
This was referenced Sep 4, 2026
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Section 508 states that `tri skill check` detects a duplicate section number, prints PROBLEMS, and exits 0. Measured today by planting a duplicate: it prints PROBLEMS and exits 1. skillnum.rs has carried std::process::exit(1) since #2789. The error was mine and it arrived with a number attached: I read the exit code of an invocation made after I had already removed the duplicate. That is the clean case reported as the duplicate case. When an exit code is the finding, the run that produced it must be the run that contained the defect, and the cheapest proof is to plant the defect and watch it fail. The other half stands: grep for "skill check" across workflows, scripts and tools returned nothing. A checker that exits 1 correctly and is called by nobody fails as silently as one that exits 0. A neighbouring session wired it into cli-tri.yml in #3165 after checking the half I got wrong. Two failures, not three, and the surviving one was enough on its own. Refs #2994
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-04 11:38:30 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-04 11:48:33 UTC
Summary
Seal Status
|
Contributor
PR DashboardGenerated at: 2026-09-04 11:54:48 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 4, 2026
gHashTag
added a commit
that referenced
this pull request
Sep 4, 2026
…3134) (#3189) tri pr-cost counted update-branch merges by SUBJECT PREFIX. The loop then began passing its own -m "Merge origin/master into <branch>", matching none of the three prefixes, so the command printed "update-branch merges 0" and "cost of the rule 0 minutes" -- pricing the up-to-date rule as free while it was charging. Nothing moved but my own commit-message habit. Measured on four PRs: by prefix 0/0/4/0, by parent count 1/1/4/3. It agreed only on the one PR that used git's default message and missed another session's #3178 entirely. A merge commit has two parents; the prefix list is gone rather than widened, because a longer list of spellings is the same defect with more rope. Same window: content 18 -> 12, merges 0 -> 6, cost 0 -> 176 minutes. Over 20 PRs: 43 commits, 15 merges, 307 minutes. And the corrected number argues AGAINST the merge queue #3134 proposes. Every pull_request commit fires 23 workflow runs (median over 200 recent runs grouped by head_sha and event; min 20, max 23), so in runs: today 43 commits x 23 = 989 queued 28 content x 23 + 20 builds x 23 = 1104 (+115, +12%) A queue charges one build per PR whether or not it ever caught up, and 10 of 20 merged with ZERO catch-ups. Average 0.75; break-even batch 1.33; only one loop/ PR is open at a time, so batching is ~1. The cause is a fix already merged here: #3166's narrow rule drove the average below the queue's break-even. The remedy #3134 proposes was made unprofitable by a remedy already shipped, and nothing noticed because the two were never priced in the same unit. pr-cost now prints that arithmetic itself, and states what it does not establish: a queue wins at batch >= 1.33, which is about arrival rate, and it does nothing for the waiting that --required-only already removes. SKILL.md 530-531. Posted to #3134. Refs #3134 Co-authored-by: Claude Opus 5 <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 loop that lands a pull request also kept the branch current: fetch each pass, and merge the base if it was no longer an ancestor. That reads like hygiene.
It is a livelock. Pushing restarts every check, and neighbouring sessions land pull requests faster than checks finish. Observed one iteration apart:
The catch-up reset the very progress it was performed to protect, and the loop could have run forever without once reaching zero.
Being behind costs nothing until the moment of merge. Merge the base only when the checks are green and
mergeStateStatusisBEHIND— when being behind is the sole remaining blocker. With that rule the same pull request (#3160) landed on iteration 24 having caught up zero times; the previous rule had burned twelve iterations catching up.Wider shape: an action taken "to stay current" is paid for in the currency of the thing it protects. Before refreshing anything on a timer, ask what one refresh costs and at what moment staleness actually blocks — often only at the end, and only once.
Refs #2994