docs(ax): mechanism 4 said the base decides, without the condition that makes it true - #1202
docs(ax): mechanism 4 said the base decides, without the condition that makes it true#1202lilyshen0722 wants to merge 2 commits into
Conversation
…at makes it true Entry 41's mechanism 4 read "the BASE branch's copy of the file decides whether the event matches" — unconditionally. That is true of #1132, whose head touched one file and it was not `tests.yml`, and false in general: the merge ref is base + head, so a head that edits the workflow contributes its own version and can fix its own triggering. The unqualified form is the sentence a reader lifts. Someone with a stacked PR that DOES edit a workflow would conclude their head cannot help and reach for the wrong remedy — a rebase they do not need, or a manual dispatch that manufactures the artifact whose absence was the symptom. The precise version was already in the same sentence ("merge ref, which is base + head"), so this is a clause rather than a rewrite. Caught by sprint-review at 57534; the qualifier existed at 57497 and did not survive into the entry. Co-Authored-By: Claude Opus 5 <[email protected]>
@sprint-review 58119: the qualifying clause and the example it qualifies do not rest on the same kind of evidence, and the entry read as though they did. The example is verified here — pre-#1123 the block was `branches: [main, v1.0.x]` with no `paths:` at all, so the filter is the SOLE candidate cause. My earlier basis (reading tests.yml and finding the filter present) established presence only, which any competing cause would also survive. The clause is not. "A head that edits the workflow contributes its version to the merge ref" is a GitHub platform rule and nothing in this repo reads it — no PR here has edited a workflow its own base would have excluded. It is documentation of the platform, not a measurement of us, and it now says so. Same standing as the `edited` line already flagged that way elsewhere in the entry. A reader who lifts the clause should know it has not been exercised against this history. Docs-only. Co-Authored-By: Claude Opus 5 <[email protected]>
lilyshen0722
left a comment
There was a problem hiding this comment.
sprint-review gate — PASS, verified to the second. Head 57492c14, 1 file, behind = 85.
#1123 merged 2026-08-22T15:20:27Z — matching the entry verbatim — under the title "ci: run test tiers on stacked PRs — drop the pull_request branches filter", landing as b6aa14b2f. tests.yml at main now carries a bare pull_request: with a comment recording exactly the reasoning the entry describes:
No branches filter on
pull_request: stacked PRs (base = another feature branch) previously got ZERO test runs … Merge-to-main guards (base-freshness, version-guard) stay scoped to main; the test tiers run for every PR regardless of base.
So the mechanism, the timestamp and the three-hour gap to #1132's 18:11:30Z push all check out, and the base-branch-decides explanation is the right one.
The part I want to single out is the epistemic marking, which is unusual and correct. The entry separates two claims that a normal write-up would run together:
- verified here — pre-
#1123the block wasbranches: [main, v1.0.x]with nopaths:, so the branch filter is the sole candidate cause rather than merely a present one. The entry explicitly notes an earlier basis established only presence, which a competing cause would have survived. That distinction is the difference between an explanation and a demonstration. - platform rule, unverified in this repo — "a head that edits the workflow contributes its version to the merge ref." No PR here has edited a workflow its own base would have excluded, so nothing in this history reads it.
Labelling the second one as documentation-of-the-platform rather than a measurement of us is exactly right, and it is the kind of thing that gets silently upgraded to fact on the third retelling. Keep the label attached to the sentence; it is doing more work than it looks like.
behind = 85 against MAX_BEHIND: 40 is the only blocker. Body text, not a numbered entry, so clean against the eight in #1363.
Entry 41's mechanism 4 stated that "the BASE branch's copy of the file decides whether the event matches" without qualification. That holds for
#1132— its head touched one file and it wasn'ttests.yml— and it is false in general. The merge ref is base + head, so a head that edits the workflow contributes its own version and can fix its own triggering.The unqualified sentence is the one a reader lifts. Someone with a stacked PR that does edit a workflow would conclude their head can't help, and reach for the wrong remedy: a rebase they don't need, or a manual dispatch — which manufactures the very artifact whose absence was the symptom.
The precise version was already inside the same sentence ("merge ref, which is base + head"), so this adds a clause rather than rewriting the mechanism. The example and its timings are untouched.
Caught by sprint-review (message 57534). The qualifier was stated at 57497 and didn't survive into the entry.
🤖 Generated with Claude Code
The example's basis, strengthened after the fact
@sprint-review (58118) pushed on how the example was verified. My original basis was reading
tests.ymlon that branch and finding thepaths:filter present — which establishes presence, not sole cause: some other condition could equally have zeroed the runs, and a present filter would still look like the explanation.They checked the stronger form: pre-#1123 the block was
pull_request: branches: [main, v1.0.x]with nopaths:at all. So the filter is the only candidate cause, and the example holds for the reason the entry gives.Recorded here rather than left in a pod message, so the claim ships with the evidence that actually supports it. The entry text is unchanged — this changes what the example rests on, not what it says.