Repository navigation
docs: the 09-25 stranger walk of GitHub, Slack and Telegram, and the rule the Slack defect earned - #1877
Merged
Conversation
…rule the Slack defect earned The readiness matrix gains the walk's per-cell results and corrects two rows it had wrong: Slack was recorded as stable while every new install was refused at Authorize in Slack (fixed in #1875), and GitHub was recorded as disabled while it has been live on our own repository since 09-18. Review-checklist rule 34 is rule 24's inverse: a hand-built fixture also lies about absence, because a nested schema path hydrates as {} on every document. Checked on mongoose 7.8.6: schema.path() is undefined for the nested path, schema.nested[] is true, the hydrated value is {} and truthy, and toJSON drops it, which is why no API response ever showed it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RUTWqLu6zhFPraoPHZcjQP
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RUTWqLu6zhFPraoPHZcjQP
samxu01
pushed a commit
that referenced
this pull request
Sep 25, 2026
…ion bump The version guard's own comments explain why it exists, and they live in .github/workflows/package-version-guard.yml — a file nobody editing commonly-mcp/src/tools.js opens. The rule cost a red CI run on #1876 today, so it goes where an author and a reviewer actually read: rule 35 of the incident-derived checklist, with the three ways it can fail (no bump, a bump below base, a version an older open PR already claimed) and the things it deliberately permits (tests, docs, anything outside $pkg/src). Numbered 35, not 34: #1877 landed its own rule 34 on main while this was open, and the two additions conflict in the same file. Renumbered rather than inserted above it, so the file's numbering stays ascending.
This was referenced Sep 25, 2026
Merged
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75962) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets: four branches that merged main into themselves carry one extra commit and one fewer bullet (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). Census over 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates for the subject can be told apart: one non-merge commit landed the commit's subject 32 of 32; two or more landed the PR title 50 of 50. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Corrections this revision carries, both of them mine. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the subject box and generalised a rule from it; with the setting read, #2031 is the one-commit default. The second draft then reported "50 of 51" with #1964 as an unexplained residual: that was a classifier artifact, `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The doc's classifier, its recipe and its census are all stated as non-merge counts now, and it says plainly that an editable box which has never been seen being edited is not evidence that a given landing was one. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749): #1645 matches NEITHER the PR title nor the commit's subject (a hand-typed hybrid, 0 title renames); #1644 landed the FIRST COMMIT's subject on a branch of 2 non-merge commits, where the count says the title; #1623 landed the PR TITLE where the count of 1 non-merge commit says the commit's subject (its body carries 0 bullets). Zero overrides in the 297 PRs measured below (#1696-#2053). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 32 of 32; two or more landed the PR title 50 of 50. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Three corrections this revision carries, all mine. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third is this revision: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The doc now carries the override as a measured finding with its signatures, and every claim it makes names the window it was measured in. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749): #1645 matches NEITHER the PR title nor the commit's subject (a hand-typed hybrid, 0 title renames); #1644 landed the FIRST COMMIT's subject on a branch of 2 non-merge commits, where the count says the title; #1623 landed the PR TITLE where the count of 1 non-merge commit says the commit's subject (its body carries 0 bullets). Zero overrides in the 297 PRs measured below (#1696-#2053). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 194 landings took the commit's subject, 32 of them on a one-commit branch, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 32 of 32; two or more landed the PR title 50 of 50. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Three corrections this revision carries, all mine. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third is this revision: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The doc now carries the override as a measured finding with its signatures, and every claim it makes names the window it was measured in. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749). #1645 matches NEITHER the PR title nor the commit's subject (0 rename events) and is the only one of the three an edit is needed to explain; #1623 landed the PR TITLE and #1644 landed commit 1's subject, each BYTE-EXACT, where the count predicts the other candidate - so a box seeded when the dialog rendered explains those two without an edit (#1644's timings: commit 1 at 20:24:15Z, commit 2 at 20:29:26Z, the press at 20:52:58Z). They establish that the prediction can fail; only #1645 establishes why. Zero overrides in the 297 PRs measured below (#1696-#2053). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 194 landings took the commit's subject, 32 of them on a one-commit branch, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 32 of 32; two or more landed the PR title 50 of 50. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Three corrections this revision carries, all mine. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third is this revision: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The doc now carries the override as a measured finding with its signatures, and every claim it makes names the window it was measured in. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749). #1645 matches NEITHER the PR title nor the commit's subject (0 rename events); #1623 landed the PR TITLE and #1644 landed commit 1's subject, each BYTE-EXACT, where the count predicts the other candidate. A stale prefill - the dialog populates its subject field when it RENDERS, not when it is pressed - accounts for #1644 (commit 1 at 20:24:15Z, commit 2 at 20:29:26Z, the press at 20:52:58Z, so a box opened in that window carried commit 1's subject) and for NEITHER of the other two: #1623's branch held one non-merge commit for its whole life with 0 force-push events, so no render of it could have offered the title. Five branches in the same window carrying main-merges landed the commit's subject where counting every commit would predict the title (#1678 1+1, #1647 1+2, #1574 1+1, #1558 1+2, #1539 1+1) - which is what makes #1623 an override and not a conforming multi-commit landing. Zero overrides in the 297 merged PRs measured below (#1750-#2053, contiguity-checked). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 96 discriminating landings took the commit's subject, 32 of them on a branch holding one non-merge commit, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 33 of 33; two or more landed the PR title 49 of 49. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Four corrections this revision carries, all mine. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The fourth, also ux-lead's: this revision claimed only #1645 needed an edit, treating a stale prefill as an explanation for #1623 - whose one non-merge commit never grew, so no prefill could have offered its title - and mislabelled the census window #1696-#2053 when the fetch, capped at 300 rows sorted by UPDATED, spanned #1750-#2053 and missed three merged rows inside it (#1752, #1753, #1765, since read and conforming). Both fixed; every claim the doc makes now names the window it was measured in. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749). #1645 matches NEITHER the PR title nor the commit's subject (0 rename events); #1623 landed the PR TITLE and #1644 landed commit 1's subject, each BYTE-EXACT, where the count predicts the other candidate. A stale prefill - the dialog populates its subject field when it RENDERS, not when it is pressed - accounts for #1644 (commit 1 at 20:24:15Z, commit 2 at 20:29:26Z, the press at 20:52:58Z, so a box opened in that window carried commit 1's subject) and for NEITHER of the other two: #1623's branch held one non-merge commit for its whole life with 0 force-push events, so no render of it could have offered the title. Five branches in the same window carrying main-merges landed the commit's subject where counting every commit would predict the title (#1678 1+1, #1647 1+2, #1574 1+1, #1558 1+2, #1539 1+1) - which is what makes #1623 an override and not a conforming multi-commit landing. Zero overrides in the 297 merged PRs measured below (#1750-#2053, contiguity-checked). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 96 discriminating landings took the commit's subject, 32 of them on a branch holding one non-merge commit, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 33 of 33; two or more landed the PR title 49 of 49. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Four corrections this revision carries, all mine. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The fourth, also ux-lead's: this revision claimed only #1645 needed an edit, treating a stale prefill as an explanation for #1623 - whose one non-merge commit never grew, so no prefill could have offered its title - and mislabelled the census window #1696-#2053 when the fetch, capped at 300 rows sorted by UPDATED, spanned #1750-#2053 and missed three merged rows inside it (#1752, #1753, #1765, since read and conforming). Both fixed; every claim the doc makes now names the window it was measured in. (5) An addition rather than a correction: `git log --no-merges -1 <branch>` means "newest non-merge commit REACHABLE", so on a merge-tipped branch it hands back another PR's commit on main (#1623 -> "...(#1626)", #1574 -> "...(#1576)"); the recipe now ranges from the merge base and carries #1964 (tip not a merge) as the control. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749). #1645 matches NEITHER the PR title nor the commit's subject (0 rename events); #1623 landed the PR TITLE and #1644 landed commit 1's subject, each BYTE-EXACT, where the count predicts the other candidate. A stale prefill - the dialog populates its subject field when it RENDERS, not when it is pressed - accounts for #1644 (commit 1 at 20:24:15Z, commit 2 at 20:29:26Z, the press at 20:52:58Z, so a box opened in that window carried commit 1's subject) and for NEITHER of the other two: #1623's branch held one non-merge commit for its whole life with 0 force-push events, so no render of it could have offered the title. Five branches in the same window carrying main-merges landed the commit's subject where counting every commit would predict the title (#1678 1+1, #1647 1+2, #1574 1+1, #1558 1+2, #1539 1+1) - which is what makes #1623 an override and not a conforming multi-commit landing. Zero overrides in the 297 merged PRs measured below (#1750-#2053, contiguity-checked). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 96 discriminating landings took the commit's subject, 32 of them on a branch holding one non-merge commit, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 33 of 33; two or more landed the PR title 49 of 49. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Four corrections this revision carries, all mine - plus an addition at (5) and a correction to it at (6), and that one is sprint-review's catch. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The fourth, also ux-lead's: this revision claimed only #1645 needed an edit, treating a stale prefill as an explanation for #1623 - whose one non-merge commit never grew, so no prefill could have offered its title - and mislabelled the census window #1696-#2053 when the fetch, capped at 300 rows sorted by UPDATED, spanned #1750-#2053 and missed three merged rows inside it (#1752, #1753, #1765, since read and conforming). Both fixed; every claim the doc makes now names the window it was measured in. (5) An addition rather than a correction: `git log --no-merges -1 <branch>` means "newest non-merge commit REACHABLE", so on a merge-tipped branch it hands back another PR's commit on main (#1623 -> "...(#1626)", #1574 -> "...(#1576)"); the recipe now ranges from the merge base. (6) A correction to (5) itself, and it is sprint-review's: the control half of (5) was wrong. #1964's tip IS a merge (3e7ce46, parents 3a65832 own + ff8de0f merged-in), so merge-tip is NECESSARY AND NOT SUFFICIENT for the trap. What spares #1964 is DATE ORDER, by 40 seconds - its own commit at 11:17:28Z against the merged-in 11:16:48Z - while #1623 loses the same race by 30 minutes (own a9c6cb2 at 06:55:46Z against main's 9f75906, #1626, at 07:25:57Z), which is why #1623's unranged read returns the SEO guide. #1964 is therefore a NEAR MISS, not a clean control, and the clean control is a tip that is not a merge at all, where main is unreachable: #2051, #2053, #1752, #1753, #1765, #1645, #2031, each with one parent, each reading its own commit unranged. The doc carries the corrected condition in both the recipe and the habits bullet. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749). #1645 matches NEITHER the PR title nor the commit's subject (0 rename events); #1623 landed the PR TITLE and #1644 landed commit 1's subject, each BYTE-EXACT, where the count predicts the other candidate. A stale prefill - the dialog populates its subject field when it RENDERS, not when it is pressed - accounts for #1644 (commit 1 at 20:24:15Z, commit 2 at 20:29:26Z, the press at 20:52:58Z, so a box opened in that window carried commit 1's subject) and for NEITHER of the other two: #1623's branch held one non-merge commit for its whole life with 0 force-push events, so no render of it could have offered the title. Five branches in the same window carrying main-merges landed the commit's subject where counting every commit would predict the title (#1678 1+1, #1647 1+2, #1574 1+1, #1558 1+2, #1539 1+1) - which is what makes #1623 an override and not a conforming multi-commit landing. Zero overrides in the 297 merged PRs measured below (#1750-#2053, contiguity-checked). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 96 discriminating landings took the commit's subject, 32 of them on a branch holding one non-merge commit, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 33 of 33; two or more landed the PR title 49 of 49. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Six corrections this revision carries, four of them mine and two sprint-review's, plus an addition at (5) that both of theirs correct. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The fourth, also ux-lead's: this revision claimed only #1645 needed an edit, treating a stale prefill as an explanation for #1623 - whose one non-merge commit never grew, so no prefill could have offered its title - and mislabelled the census window #1696-#2053 when the fetch, capped at 300 rows sorted by UPDATED, spanned #1750-#2053 and missed three merged rows inside it (#1752, #1753, #1765, since read and conforming). Both fixed; every claim the doc makes now names the window it was measured in. (5) An addition rather than a correction: `git log --no-merges -1 <branch>` means "newest non-merge commit REACHABLE", so on a merge-tipped branch it hands back another PR's commit on main (#1623 -> "...(#1626)", #1574 -> "...(#1576)"); the recipe now ranges from the merge base. (6) A correction to (5) itself, and it is sprint-review's: the control half of (5) was wrong. #1964's tip IS a merge (3e7ce46, parents 3a65832 own + ff8de0f merged-in), so merge-tip is NECESSARY AND NOT SUFFICIENT for the trap. What spares #1964 is DATE ORDER, by 40 seconds - its own commit at 11:17:28Z against the merged-in 11:16:48Z - while #1623 loses the same race by 30 minutes (own a9c6cb2 at 06:55:46Z against main's 9f75906, #1626, at 07:25:57Z), which is why #1623's unranged read returns the SEO guide. #1964 is therefore a NEAR MISS, not a clean control, and the clean control is a tip that is not a merge at all, where main is unreachable: #2051, #2053, #1752, #1753, #1765, #1645, #2031, each with one parent, each reading its own commit unranged. The doc carries the corrected condition in both the recipe and the habits bullet. (7) Also sprint-review's, and again about (5): the doc measured the trap "on the seven merge-tipped branches in this population, six returned a different PR's commit". That population - every merge-carrying row of #1534-#1749 holding one non-merge commit - contains 22 such branches, all 22 merge-tipped, and 21 of them return a different commit, so 6-of-7 understated the hazard 3.5x; "this population" also had no stated boundary in the doc. The one quiet row is #1651, and it is quiet for the same reason #1964 survives: its own 1270011 (05:26:06-07:00) is newer than the tip it merged in, f3ae379 (00:49:19-07:00), so the date-ordered walk never leaves the branch. Coincident candidates do not make a row quiet - 15 of the 16 rows in that population whose title equals their first commit subject are among the 21 that fire. The doc now states the window, the ratio, and #1651's measured reason. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
samxu01
pushed a commit
that referenced
this pull request
Sep 30, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (#1965 7+1 -> 7, #1901 6+1 -> 6, #1905 5+1 -> 5, #1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (#1534-#1749). #1645 matches NEITHER the PR title nor the commit's subject (0 rename events); #1623 landed the PR TITLE and #1644 landed commit 1's subject, each BYTE-EXACT, where the count predicts the other candidate. A stale prefill - the dialog seeding its subject field when it RENDERS, so a box opened earlier is pressed carrying an older subject; INFERRED, never read, since no API field records the client or the box - accounts for #1644 (commit 1 at 20:24:15Z, commit 2 at 20:29:26Z, the press at 20:52:58Z, so a box opened in that window carried commit 1's subject) and for NEITHER of the other two unless that inference holds: #1623's branch held one non-merge commit for its whole life with 0 force-push events, so no render of it could have offered the title if the dialog prefills by the count the landings follow. Five branches in the same window carrying main-merges landed the commit's subject where counting every commit would predict the title (#1678 1+1, #1647 1+2, #1574 1+1, #1558 1+2, #1539 1+1) - which is what makes #1623 an override and not a conforming multi-commit landing. Zero overrides in the 297 merged PRs measured below (#1750-#2053, contiguity-checked). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 96 discriminating landings took the commit's subject, 32 of them on a branch holding one non-merge commit, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 33 of 33; two or more landed the PR title 49 of 49. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (#2024, #2031, #2049) follow the setting. Eight corrections this revision carries: four of them mine, two sprint-review's and two ux-lead's, plus an addition at (5) that the later ones correct. The first draft read #2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, #2031 is the one-commit default. The second reported "50 of 51" with #1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and #1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with #1644 and #1645. The fourth, also ux-lead's: this revision claimed only #1645 needed an edit, treating a stale prefill as an explanation for #1623 - whose one non-merge commit never grew, so no prefill following the landings' count could have offered its title - and mislabelled the census window #1696-#2053 when the fetch, capped at 300 rows sorted by UPDATED, spanned #1750-#2053 and missed three merged rows inside it (#1752, #1753, #1765, since read and conforming). Both fixed; every claim the doc makes now names the window it was measured in. (5) An addition rather than a correction: `git log --no-merges -1 <branch>` means "newest non-merge commit REACHABLE", so on a merge-tipped branch it hands back another PR's commit on main (#1623 -> "...(#1626)", #1574 -> "...(#1576)"); the recipe now ranges from the merge base. (6) A correction to (5) itself, and it is sprint-review's: the control half of (5) was wrong. #1964's tip IS a merge (3e7ce46, parents 3a65832 own + ff8de0f merged-in), so merge-tip is NECESSARY AND NOT SUFFICIENT for the trap. What spares #1964 is DATE ORDER, by 40 seconds - its own commit at 11:17:28Z against the merged-in 11:16:48Z - while #1623 loses the same race by 30 minutes (own a9c6cb2 at 06:55:46Z against main's 9f75906, #1626, at 07:25:57Z), which is why #1623's unranged read returns the SEO guide. #1964 is therefore a NEAR MISS, not a clean control, and the clean control is a tip that is not a merge, where the branch's own commit is the newest thing reachable: #2051, #2053, #1752, #1753, #1765, #1645, #2031, one parent each and origin/main an ancestor of none of those tips, each reading its own commit unranged. The doc carries the corrected condition in both the recipe and the habits bullet. (7) Also sprint-review's, and again about (5): the doc measured the trap "on the seven merge-tipped branches in this population, six returned a different PR's commit". That population - every merge-carrying row of #1534-#1749 holding one non-merge commit - contains 22 such branches, all 22 merge-tipped, and 21 of them return a different commit, so 6-of-7 understated the hazard 3.5x; "this population" also had no stated boundary in the doc. The one quiet row is #1651, and it is quiet for the same reason #1964 survives: its own 1270011 (05:26:06-07:00) is newer than the tip it merged in, f3ae379 (00:49:19-07:00), so the date-ordered walk never leaves the branch. Coincident candidates do not make a row quiet - 15 of the 16 rows in that population whose title equals their first commit subject are among the 21 that fire. The doc now states the window, the ratio, and #1651's measured reason. (8) Both of ux-lead's. (a) The contiguity split was wrong: two of the range's 304 numbers are ISSUES, not PRs (#1821 closed, #1959 open), so the split is 302 pull requests - 297 merged, 3 closed unmerged (#1784, #1903, #1967), 2 open (#1751, #1768) - and 2 issues, checked one at a time with the `pull_request` key on `gh api .../issues/N`, not "297 merged, 3 unmerged, 4 open" of 304 PR numbers. (b) The doc and this message stated the prefill as measured while the PR ask called it an inference, and the ask was the honest one: no prefill was ever read, because the measured rule is about what LANDS. #1623's exclusion is therefore conditional on the dialog prefilling by the same count, and if it counts merges instead then #1623 needed no edit and the merge-carrying landings that took a one-commit-predicted subject are the ones to explain. Every surface now says inferred; ux-lead notes their own 75d82be wording was where the overclaim entered. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (#1677 returned de5fc4d, actual f8ad3bd; #1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — #2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
lilyshen0722
added a commit
to thantiklermcirony/commonly
that referenced
this pull request
Oct 9, 2026
…eds a version bump (Team-Commonly#1884) * docs(review-checklist): a published package's src change needs a version bump The version guard's own comments explain why it exists, and they live in .github/workflows/package-version-guard.yml — a file nobody editing commonly-mcp/src/tools.js opens. The rule cost a red CI run on Team-Commonly#1876 today, so it goes where an author and a reviewer actually read: rule 35 of the incident-derived checklist, with the three ways it can fail (no bump, a bump below base, a version an older open PR already claimed) and the things it deliberately permits (tests, docs, anything outside $pkg/src). Numbered 35, not 34: Team-Commonly#1877 landed its own rule 34 on main while this was open, and the two additions conflict in the same file. Renumbered rather than inserted above it, so the file's numbering stays ascending. * docs(review-checklist): rule 35 names the guard's step and what its message actually printed Two phrases wren held the rule on (73940/73941), both against the artifact: - "its second job" → the guard is a single job (`Source changed ⇒ version bumped`) and the `gh` calls are in its second check step, `No older open PR is taking this package to the same version`. - the earned note's "named the file, the count of changed src files and both versions" → Team-Commonly#1876's red run (36114019989 at `ac62996d`) printed `commonly-mcp/src changed (1 file(s)) but version is still 0.3.12`: the package, the count, and the version it was still on. A no-bump failure has only one version to name — only the below-base arm has two — and the annotation lands on `commonly-mcp/package.json`, not on the source file that moved. Docs-only, one line of prose; the re-gate covers these lines.
lilyshen0722
added a commit
to thantiklermcirony/commonly
that referenced
this pull request
Oct 9, 2026
…nd stable (Team-Commonly#1885) * guard: the reviewer checklist's rule numbers are unique, contiguous and stable The rules are cited by number from outside the file — the file's own header names three (ADR-028 rule 23, ADR-019 rule 9, REVIEW.md §7) — and the rules cite each other nine more times. A number is a name, and nothing mechanical noticed when two PRs claimed one: on 2026-09-25 main gained a rule 34 (Team-Commonly#1877) while an open PR added its own rule 34. Git caught that one as a text conflict only because both appended at the file's end; an insert mid-file conflicts less reliably, and a keep-both merge of two rule 34s would ship silently — the ADR-018 shape, where an author followed the wrong member of a duplicate pair. scripts/verify-numbered-rules.js checks four things: the numbers are unique, they ascend 1..N with no gap, every `rule N` / `rules N–M` citation inside the file resolves and a range ascends, and against a reference version no rule has changed its NUMBER or its LEAD sentence. The reference is main as it is right now, not the merge base: a merge base predates whatever landed while the PR was open, which is the only state the collision occurs in. What it deliberately does not check is in the script's header: a rule present in the reference and absent here (the normal state of a PR that predates a rule someone else merged), an edit to a rule's body, and citations from other files. Evidence: 9-case mutation campaign, each mutation asserted to apply exactly once, baseline green before and after. * guard: resolve the checked file from the working directory This guard redded on its own first CI run (36137344359): the checker is loaded from a temp dir so a PR branched before the guard landed still runs main's copy, and the default path was resolved from __dirname — /tmp/.. — so it looked for /tmp/docs/development/review-checklist.md and died with ENOENT rather than reporting anything about rule numbers. Default now comes from process.cwd(), and the workflow passes --file explicitly, so the path does not depend on where the script itself was loaded from. Same shape as adr-numbering-guard.yml's --dir, which exists for this reason. * guard: document where a rule retraction goes The guard has no bypass, so the first person who needs to withdraw a rule will try the two routes that fail. Measured, not reasoned — m9-m11 in the campaign, which reproduce sprint-review's counts: - append the withdrawal to the rule's BODY, lead intact -> green (m9), the number stays claimed and citations of it still resolve; - mark the lead "Withdrawn" -> 1 error, reported as a number claimed twice (m10), which is what the docblock already warns; - delete the rule and close the gap -> 14 errors on a 34-rule file, every rule after it moved (m11). The middle one is the interesting failure: the sentence a reader would write to say "this is gone" is the one that makes the rule look replaced.
lilyshen0722
added a commit
to thantiklermcirony/commonly
that referenced
this pull request
Oct 9, 2026
…PR takes its subject from the commit, two or more take the PR title (TASK-223) (Team-Commonly#2054) Written by sprint-impl, a Commonly agent. Pod thread: https://commonly.me/v2/pods/6a692a1be833c668acdb84cf (message 75968) Two surfaces compose a squash message and a repository setting decides which one supplies the subject. `squash_merge_commit_title: COMMIT_OR_PR_TITLE` means one non-merge commit takes the commit's subject and two or more take the PR title; `squash_merge_commit_message: COMMIT_MESSAGES` means the body is always the branch's commit messages. Both read from the repo, so the default composition is decidable before a press. The PR body is not an input. The count is of NON-MERGE commits, and merge commits are excluded from both the count and the body bullets (Team-Commonly#1965 7+1 -> 7, Team-Commonly#1901 6+1 -> 6, Team-Commonly#1905 5+1 -> 5, Team-Commonly#1906 4+1 -> 4). THE SUBJECT CAN BE OVERRIDDEN, and that is measured rather than assumed. Three landings took a subject the setting does not predict, all merged 2026-09-08, in an older window of 194 merged PRs (Team-Commonly#1534-Team-Commonly#1749). Team-Commonly#1645 matches NEITHER the PR title nor the commit's subject (0 rename events); Team-Commonly#1623 landed the PR TITLE and Team-Commonly#1644 landed commit 1's subject, each BYTE-EXACT, where the count predicts the other candidate. A stale prefill - the dialog seeding its subject field when it RENDERS, so a box opened earlier is pressed carrying an older subject; INFERRED, never read, since no API field records the client or the box - accounts for Team-Commonly#1644 (commit 1 at 20:24:15Z, commit 2 at 20:29:26Z, the press at 20:52:58Z, so a box opened in that window carried commit 1's subject) and for NEITHER of the other two unless that inference holds: Team-Commonly#1623's branch held one non-merge commit for its whole life with 0 force-push events, so no render of it could have offered the title if the dialog prefills by the count the landings follow. Five branches in the same window carrying main-merges landed the commit's subject where counting every commit would predict the title (Team-Commonly#1678 1+1, Team-Commonly#1647 1+2, Team-Commonly#1574 1+1, Team-Commonly#1558 1+2, Team-Commonly#1539 1+1) - which is what makes Team-Commonly#1623 an override and not a conforming multi-commit landing. Zero overrides in the 297 merged PRs measured below (Team-Commonly#1750-Team-Commonly#2053, contiguity-checked). So an override is detectable — a landed subject the setting and the count do not predict — and a census is a claim about its own window, not about the practice. The "the setting was different then" reading is pre-empted by the same window: 33 of its 96 discriminating landings took the commit's subject, 32 of them on a branch holding one non-merge commit, which a PR-title setting cannot produce without an override each. Census, 297 merged PRs, restricted to the discriminating set — the 82 PRs whose title and first commit subject differ, the only set where the two candidates can be told apart: one non-merge commit landed the commit's subject 33 of 33; two or more landed the PR title 49 of 49. No exceptions. Six of the nine merges of 2026-09-30 had title == first commit subject and could not discriminate at all; the three that could (Team-Commonly#2024, Team-Commonly#2031, Team-Commonly#2049) follow the setting. Eight corrections this revision carries: four of them mine, two sprint-review's and two ux-lead's, plus an addition at (5) that the later ones correct. The first draft read Team-Commonly#2031's landed subject (the commit's, not the title's) as a presser overwriting the box and generalised from it; with the setting read, Team-Commonly#2031 is the one-commit default. The second reported "50 of 51" with Team-Commonly#1964 as an unexplained residual — a classifier artifact, since `gh pr view --json commits` counts merge commits, and Team-Commonly#1964's branch is 1 non-merge + 1 merge and landed in the one-commit shape with no bullets. The third: the commit message said an editable box "has never been seen being edited", which is a claim about the whole history made from a 297-PR window, and ux-lead refuted it with Team-Commonly#1644 and Team-Commonly#1645. The fourth, also ux-lead's: this revision claimed only Team-Commonly#1645 needed an edit, treating a stale prefill as an explanation for Team-Commonly#1623 - whose one non-merge commit never grew, so no prefill following the landings' count could have offered its title - and mislabelled the census window Team-Commonly#1696-Team-Commonly#2053 when the fetch, capped at 300 rows sorted by UPDATED, spanned Team-Commonly#1750-Team-Commonly#2053 and missed three merged rows inside it (Team-Commonly#1752, Team-Commonly#1753, Team-Commonly#1765, since read and conforming). Both fixed; every claim the doc makes now names the window it was measured in. (5) An addition rather than a correction: `git log --no-merges -1 <branch>` means "newest non-merge commit REACHABLE", so on a merge-tipped branch it hands back another PR's commit on main (Team-Commonly#1623 -> "...(Team-Commonly#1626)", Team-Commonly#1574 -> "...(Team-Commonly#1576)"); the recipe now ranges from the merge base. (6) A correction to (5) itself, and it is sprint-review's: the control half of (5) was wrong. Team-Commonly#1964's tip IS a merge (3e7ce46, parents 3a65832 own + ff8de0f merged-in), so merge-tip is NECESSARY AND NOT SUFFICIENT for the trap. What spares Team-Commonly#1964 is DATE ORDER, by 40 seconds - its own commit at 11:17:28Z against the merged-in 11:16:48Z - while Team-Commonly#1623 loses the same race by 30 minutes (own a9c6cb2 at 06:55:46Z against main's 9f75906, Team-Commonly#1626, at 07:25:57Z), which is why Team-Commonly#1623's unranged read returns the SEO guide. Team-Commonly#1964 is therefore a NEAR MISS, not a clean control, and the clean control is a tip that is not a merge, where the branch's own commit is the newest thing reachable: Team-Commonly#2051, Team-Commonly#2053, Team-Commonly#1752, Team-Commonly#1753, Team-Commonly#1765, Team-Commonly#1645, Team-Commonly#2031, one parent each and origin/main an ancestor of none of those tips, each reading its own commit unranged. The doc carries the corrected condition in both the recipe and the habits bullet. (7) Also sprint-review's, and again about (5): the doc measured the trap "on the seven merge-tipped branches in this population, six returned a different PR's commit". That population - every merge-carrying row of Team-Commonly#1534-Team-Commonly#1749 holding one non-merge commit - contains 22 such branches, all 22 merge-tipped, and 21 of them return a different commit, so 6-of-7 understated the hazard 3.5x; "this population" also had no stated boundary in the doc. The one quiet row is Team-Commonly#1651, and it is quiet for the same reason Team-Commonly#1964 survives: its own 1270011 (05:26:06-07:00) is newer than the tip it merged in, f3ae379 (00:49:19-07:00), so the date-ordered walk never leaves the branch. Coincident candidates do not make a row quiet - 15 of the 16 rows in that population whose title equals their first commit subject are among the 21 that fire. The doc now states the window, the ratio, and Team-Commonly#1651's measured reason. (8) Both of ux-lead's. (a) The contiguity split was wrong: two of the range's 304 numbers are ISSUES, not PRs (Team-Commonly#1821 closed, Team-Commonly#1959 open), so the split is 302 pull requests - 297 merged, 3 closed unmerged (Team-Commonly#1784, Team-Commonly#1903, Team-Commonly#1967), 2 open (Team-Commonly#1751, Team-Commonly#1768) - and 2 issues, checked one at a time with the `pull_request` key on `gh api .../issues/N`, not "297 merged, 3 unmerged, 4 open" of 304 PR numbers. (b) The doc and this message stated the prefill as measured while the PR ask called it an inference, and the ask was the honest one: no prefill was ever read, because the measured rule is about what LANDS. Team-Commonly#1623's exclusion is therefore conditional on the dialog prefilling by the same count, and if it counts merges instead then Team-Commonly#1623 needed no edit and the merge-carrying landings that took a one-commit-predicted subject are the ones to explain. Every surface now says inferred; ux-lead notes their own 75d82be wording was where the overclaim entered. Also recorded because the doc quotes them: `git log --grep="(#N)$"` resolves the WRONG commit when a later commit on main also names that PR (Team-Commonly#1677 returned de5fc4d, actual f8ad3bd; Team-Commonly#1877 8235be3 vs e3d9550), so the recipe uses the PR's mergeCommit; `gh pr view --json commits` truncates headlines (17 of 22 in the nine-PR set, each to 69 characters plus an ellipsis, longest intact 72); and amending the tip does not amend earlier commits — Team-Commonly#2049's merge message carries commit 1's retracted framing at line 13 and its retraction at line 58. Scope: this is the message, not the tree. Fidelity of what landed to what was reviewed stays rule 32's patch-id comparison; the tree/origin check is rule 49.
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
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.
Docs only. This records the 2026-09-25 stranger walk of the three connectors we sell, and corrects two rows the matrix had wrong.
f536fa11at 1200 and 390, up to the redirect to Slack's OAuth page.Review-checklist rule 34 is the lesson #1875 earned, as the inverse of rule 24: a nested schema path hydrates as
{}on every document, so a hand-built fixture proves absence where the real document is never absent. I checked its mechanical claims on mongoose 7.8.6.C4 and C9 for GitHub are still open. The C9 expiry probe fires at the grant's lapse (11:33Z), and I'll add its result here before this merges.
Gate: Vera (docs, measurement claims).
🤖 Generated with Claude Code
https://claude.ai/code/session_01RUTWqLu6zhFPraoPHZcjQP