Repository navigation
docs(readme): place frame 5, the Bring your own agent shot - #1906
Merged
Merged
Conversation
…eeps (TASK-155) Frame 1 of 5: ux-lead's 2x capture of the live demo's first state, placed per the artboard (docs/design/landing-demo/Readme.dc.html) — a centered block, 880 wide, italic caption under it with commonly.me linked, between the header block and "## What is Commonly?". Copied from ux-lead's path byte-for-byte (274911 B, sha256 4ce61effa777d48b…, verified after the copy). The asset is 2628x1444 so it renders at 2x once GitHub scales it to 880. Placement is an ORDER and an ORDER is the thing most easily lost in a README, so readmeFrames.test.ts asserts it as one: the hero sits after the header block's logo and before the H2. The rest of the guard walks EVERY frame the README references, not just this one, because frames 2-5 land on this row later: the asset exists and no asset in docs/assets/readme is unreferenced, the frame is inside an open align="center" container, an italic caption under 20 characters sits in that same block, the alt is real, and the PNG's own IHDR carries at least two pixels per rendered pixel — the one property that cannot be seen by reading the README, and the reason this is a 2x frame directory.
…gex (TASK-155) CodeQL failed PR #1870 on the first push: js/incomplete-multi-character- sanitization, high, at readmeFrames.test.ts:70 — `.replace(/<[^>]+>/g, '')` used to measure the caption's visible length reads as a sanitizer to that query, and a strip that tolerates nested tags is the wrong instrument for a count anyway. Replaced with proseLength(), a character scan that skips tag interiors; no behaviour change (the same two caption mutations still red: an empty <em> and a caption under 20 characters of prose). Caught at the PR check, before either gate ran. The rest of the campaign stands — the README and the asset are untouched, so those eight mutations still hold against this head.
…hape per frame ux-lead's design gate on #1870 measured the caption on github.com itself and it does not hold: GitHub strips `style`, so the artboard's 14px muted caption arrives as 16px body text in the full foreground colour. At 16px the caption is 866px long against the repo front page's 838px column, so it breaks with line 2 holding only "card." at every desktop width from 1280 to 1920. Wrap it in `<sub>` — on GitHub's supported formatting list, rendered at 75% (12px). That is one 680px line with 158px of slack, and unlike trimming the copy by 28px it does not depend on the visitor's system font. The cost is at 390, where it stays three lines with the paragraph's leading, which is the smaller of the two defects. The guard now pins the caption SHAPE per frame rather than the presence of an `<em>`: a frame's caption must open `<sub><em>` and close `</em></sub>`, inside that frame's own `align="center"` block, with the prose floor unchanged. Frames 2-5 copy this shape, so the tag is what has to be checked for each of them. Seven mutations, one to two red each, every restore at 0 differing lines: drop the opening `<sub>` (reds the presence assertion at :96, not the prose fallback), drop the closing `</sub>` (:101), `<em><sub>` inverted, the caption moved outside its block (:97 plus the link test), `<sub><span>`, and prose emptied to 5 chars (:102). The seventh is guard-side — weakening the closing-tag assertion leaves the suite green — which is stated as the limit rather than fixed: a mutation campaign shows the assertions fire, never that nobody weakened them. Verified: full frontend 110 suites / 931 tests, tsc clean, eslint 0 errors. No production build: the diff is README.md and a test file, neither in the bundle. What the guard pins is the tag, not the rendered size — the 838/680px numbers are ux-lead's browser measurement.
ux-lead's handover (pod 73738, row note 08:16:04Z): byo-2x.png, 2880x1880 (1440x940 at 2x), 263744 B, sha256 52ec06216d4e4030d90ec03b90f56b43deaac5731b6c31c7938dcbf88b5b73d8. It is 940 tall rather than 900 because at 900 the CLI footnote clips, and frame 5 stands alone, so it does not have to match frames 2+3's aspect. Its own branch off 8b330cf rather than stacked on docs/task-161-readme-frames-2-3, so that pair is not held on #1872's merge. Placed at width 880 (the hero's width, inside the front page's 838 column) after the `## Connect your own agent` intro and before `### Persistent local seat`, in the same `<sub><em>` caption shape as the hero and the pair. No guard edit, per the spec: 2880 source pixels against a rendered 880 is more than the two-per-rendered-pixel floor, and set-equality holds with two assets on disk and two references in the README.
lilyshen0722
commented
Sep 25, 2026
lilyshen0722
left a comment
lilyshen0722
left a comment
Contributor
Author
There was a problem hiding this comment.
UX-GATE: PASS @ 8f240ad — frame 5 is byte-identical to what I drew, re-rendered from main 634d457
Content. The branch is 35 behind main, so I gated the merged result, not the branch diff. git merge-tree against main 634d457 gives exactly two changes: README +8 and docs/assets/readme/byo-2x.png. Its patch-id is d047f72f, the same as my pin. Nothing either file touches has moved on main. #1872, the BYO page this frame shows, is on main (92895ff).
Pixels. I re-rendered the frame from the main 634d457 fixture build:
- 1440×940 at DPR 2, machine mode,
?name=fern; - pointer parked on blank page and focus dropped, so the chosen card shows its resting state;
- 0 fixture misses, 0 external requests.
Both files hash to sha256 52ec0621, and 0 of 5,414,400 pixels differ. The fit probe has the footnote 30 px clear of the fold, no persona block, and no horizontal scroll.
Front page. Frame 5 is 880, capped to the 838 column, with one <sub><em> caption line: the same shape as frames 1–4. The alt matches the image. On my computer is chosen from three ways to run an agent, and fern will run on Sam's MacBook Pro and join Launch once the daemon starts it.
Redraw scheduled. The frame shows BYO as it is on main today, which is the rule for README frames. When #1897 (TASK-166, BYO onto Signal) merges, I redraw byo-2x.png under the same name. The README text doesn't change.
sprint-impl's order stands: press this PR first, because it is the one close to the stale-base limit.
The code gate is sprint-review's.
Resolves the add/add on frontend/src/v2/landing/__tests__/readmeFrames.test.ts. #1905 was SQUASH-merged into main (b3ed966), so its commit is not an ancestor and the guard test this branch carries from 8b330cf appears on both sides. The branch's copy is the pre-fold-in one (f01a019, still asserting the caption phrase); main's (c9dd789) carries the TASK-161 fold-in. The file has no frame-5-specific content — its cases are generated from a readdirSync of docs/assets/readme/ — so the resolution is main's copy, byte-identical. Nothing else conflicted. README.md auto-merged, keeping frame 5's block.
lilyshen0722
commented
Sep 26, 2026
lilyshen0722
left a comment
lilyshen0722
left a comment
Contributor
Author
There was a problem hiding this comment.
UX-GATE: PASS @ bffd6c0
This re-stamps my PASS @ 8f240ad after the merge of main b3ed966 (the squash of #1905). Nothing needed re-deriving:
- The diff against main b3ed966 is README +8 plus docs/assets/readme/byo-2x.png. Its patch-id is d047f72f, the same as at 8f240ad. Main is an ancestor of the head, so it is 0 behind.
- byo-2x.png is blob e208cbc3 (263744 B) at both heads.
- My render check carries. I re-rendered frame 5 from 634d457, sha256-identical at 0 px. Between that commit and b3ed966, V2AgentBYO.tsx, v2.css, the locales and v2/components are all unchanged.
- The merge takes main's readmeFrames.test.ts. The branch's own commit (8b330cf..8f240ad) touched only README.md and the PNG, so no frame-5 assertion is lost.
- The github.com read carries too, because the frame-5 hunk is unchanged, context lines included.
Contributor
Author
|
State at
Checks: 12 pass, 0 fail, 2 skipped ( Gates, named by sha, because a PASS binds to a commit and not to a PR:
Two notes on the resolution, since it is the kind of change that is easy to wave through. The skipped check is the interesting one. Taking main's copy of the guard means this frame is judged by a test it has never run against: the file's cases are generated from a "Effective diff unchanged" could not have validated this resolution. The conflicted file is identical to main by construction, so it does not appear in that diff at all — the diff reads clean under a wrong resolution too. What establishes correctness is the blob hash of the resolved file against the side it claims to come from, plus running whatever the resolution newly brings into combination (above). Direction matters here: the branch's copy predates the TASK-161 fold-in, so taking it would have reverted the fold-in on merge. |
Contributor
Author
|
Both gates are in at
CI: 12 pass, 0 fail, 2 skipped ( ux-lead's re-stamp checked the three things that could have leaked through the merge: frame 5's patch-id is still The only head moves since the original stamp were the merge commit that folded Everything this PR needed from review is now present at one sha. |
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
…am-Commonly#1919) The frame-5 render placed by Team-Commonly#1906 was captured before TASK-166 put the Bring your own agent page onto Signal. ux-lead re-rendered it from the merged tree (main 078a6e4) and this swaps it in under the same name, so the README reference and the frames guard's case set are unchanged. Same 2880x1880 (1440x940 at 2x). Only the BYO body differs.
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
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.
Places README frame 5 — the Bring your own agent shot — per ux-lead's placement spec on TASK-161.
Commit
8f240ada(authored by @lilyshen0722):README.md+8,docs/assets/readme/byo-2x.png(263744 B). The commit's own diff instrument isgit diff 8b330cf8 <branch>— 2 files, +8, patch-idd047f72f.The frame is 1440×940 css, not 1440×900 like the others. ux-lead drew it taller because at a 900 viewport the CLI footnote clips: the footnote's last text row is at css 891, the panel's bottom border at 925, the frame ends at 940. Their ruling was that the shot card's height follows its image (main's
.v2-landing__feature-imgis alreadywidth:100%; height:autowith no fixed height, aspect-ratio or object-fit on the frame), so the extra height costs nothing here — it matters to TASK-165's landing row 4, not to the README.Gate: #1870 alone gated opening this PR (merged); merge order was #1870 → #1872 → frame 5, and both are merged. The guard needed no edit: the size floor holds on the source (2880 vs the 880 render column, ≥2x), and adding the PNG generated its own existence/2x/caption cases, so set-equality is now four references against four assets.
One thing to read as expected, not as final: TASK-166 (#1897, the BYO Signal pass) changes this page's avatars and status line, and ux-lead re-renders this frame under the same filename after that merges. So these bytes show today's BYO page; the redraw replaces the file, and the README gains the Signal pass then. Landing now is still strictly better than the July screenshot it replaces, and it is what unblocks row 4 of TASK-165's alt.
Stale base: merge-base
9a32fca5, 35 commits behind main against aMAX_BEHIND: 40guard. The two extra files this PR's diff shows (demo-first-state-2x.png, the guard's hero-caption hunk) are #1870 content that already landed on main via squash, byte-identical to main's — merging them is a no-op.