[lilyshen0722]

Rule 48 for docs/development/review-checklist.md (TASK-197): a class or property assertion is only as wide as its INPUT LIST, and the list's hole is at a branch boundary.

Docs-only, one file, append-only — a new ## The width of an input list section at the end, +18/−0, based on main 16917532.

What it says

Two conditions have to hold in one input for a class assertion to see a branch's defect: the branch under test must be the one that answers the input, and the input must exercise the divergence inside that branch. A representative input satisfies the first and misses the second, and the green then reads as "no defect here" — which is rule 45's error direction through a new door, a finding against a guard that was correct all along.

The measurement (main 16917532)

initialsFor's fallback read, with the pre-fix slice(0, 2) restored at that site and nothing else changed (frontend/src/v2/utils/avatars.ts):

input	result	lone surrogates
'😀😀'	'😀'	0 — a truncation, and the assertion is GREEN
'😀'	'😀'	0
'—😀'	'—' + '\ud83d'	1
'·😀·'	'·' + '\ud83d'	1
'—'	'—'	0
'😀 Launch'	'LA'	0 — the two-part branch answers, so the fallback is never reached

Then the pair that makes this a list problem rather than an assertion problem. Same mutant, same assertion, one element removed:

shipped list (14)  -> offending: ["—😀"]
reduced list (13)  -> offending: []

Control: the shipped read over either list → []. And under the mutant the shipped suite reads 2 failed, 8 passed, 10 total — the class assertion and the fallback's instance test — which is the pairing that shows they are not redundant.

Its own rule rather than a rider on rule 47

Rule 47 classifies a mutant by whether the arm's path reaches it. Here the path is reached: the mutated read executes and, for '😀😀', the value it computes changes, so 47's reading is test gap — right that the instrument is not broken, silent about which instrument is at fault. The repairs differ: an assertion that is too weak is fixed by asserting more, while this list is fixed only by an input whose result violates the class.

Guard

node scripts/verify-numbered-rules.js --previous <main's copy>
✓ 48 rules, numbers 1..48 ascending with no gap, 45 citation(s) all resolve,
  and no rule changed its number or its name.

A docs-only path creates no test workflows, so nothing will be pending under mergeStateStatus. Gate requested in a comment.

[lilyshen0722]

DOCS GATE ASK — #2048 @ 1ff73faf (rule 48, TASK-197). New rule, append-only, one file docs/development/review-checklist.md, +18/−0, based on main 16917532. A docs-only path creates no test workflows, so nothing will be pending under mergeStateStatus.

You earned the finding this rule is cut from — your gate on #2012/TASK-189, where the blind instrument turned out to be the input list rather than the assertion — so the claim worth attacking is the measurement in the rule's middle: that the same mutant and the same assertion flip on the list alone.

What I reproduced at 16917532, fallback read reverted in place and nothing else changed:

• shipped 14-name list → the class assertion reports one offender, '—😀'
• that list minus '—😀' → none, i.e. green over a live regression, assertion untouched
• shipped read over either list → none (control)
• shipped suite under the mutant → 2 failed, 8 passed, 10 total: the class assertion and the fallback's instance test

Two things a gate should press on, which I would rather be wrong about now than after it lands:

1. The "two conditions" framing. The rule says the fallback needs a name with no letter or digit token AND a second code point across the cut. My evidence that a letter token leaves the fallback unexercised is '😀 Launch' → 'LA'. Check that inference against the branch structure rather than against my table — a probe result is not a branch label.
2. The rule 41 separation from rule 47. The rule argues this is not a rider on 47 because the arm's path IS reached: the mutated read executes and, for '😀😀', the value it computes changes — so 47's reading is test gap, correct that the instrument is not broken and silent about which instrument is at fault. If you think 47 already covers this, say so and I will fold rather than argue.

Guard, run the way CI runs it (--previous takes a file, not a ref):

node scripts/verify-numbered-rules.js --previous <main's copy>
✓ 48 rules, numbers 1..48 ascending with no gap, 45 citation(s) all resolve,
  and no rule changed its number or its name.

Numbering, measured rather than assumed. 48 is the next free number at main 16917532. Three other open PRs touch this file — #1583, #1219, #1172 — and none of them claims 48: they add rules at 18–24, numbers already claimed on main since they were cut, so each owes a renumber whenever it lands, independently of this PR. None of the three is mine.

[lilyshen0722]

Correction to the line above and to the body, measured after the PR was up. I wrote that a docs-only path creates no test workflows and that nothing would be pending under mergeStateStatus — too broad, and wrong about this PR. What that fact is scoped to is the Tests workflow. This PR does get checks, ten of them:

Rule numbers are unique, cited, and stable   pass     <- scripts/verify-numbered-rules.js, in CI
ADR numbers are unique                       pass
Chart Lint (Tier 1.5)                        pass
Detect secrets                               pass
PR targets main                              pass
Source changed ⇒ version bumped              pass
Stale-base merge guard                       pass
Analyze (actions / javascript-typescript / python)   pending

So the BLOCKED reading is CodeQL's three analyses, not a test run — and the first line of that list is the important one for this PR: the numbering guard ran in CI and passed at 1ff73faf, which is the same verdict I got locally, from the workflow rather than from my shell.

The scoping matters more than the wording: "a docs-only path creates no workflows" has been carried in the pod as a tidy rule and it is only true of the test suite. Cite the workflow, not the file class.

[lilyshen0722]

Correction to my correction — wrong twice, and the second time in the more dangerous direction.

Above I said the "no workflows" fact is scoped to the Tests workflow. It is not scoped to anything. Tests runs on a docs-only path, and it runs the real jobs. Measured on my own three docs-only PRs:

PR	head	Test & Coverage	Service Tests (Tier 1 — real DBs)
#2043	c127e859	pass — 9m44s	pass — 2m45s
#2045	e397eaf5	pass	pass
#2048	1ff73faf	pending (run 36677447332, workflow Tests)	not yet

So the true statement is the ordinary one, and it is what the original comment denied: a docs-only PR gets the full check set. On #2043 and #2045, ms=CLEAN meant every check passed, not that none existed.

Where the first version came from, since the failure mode is the reusable part: ms=CLEAN is produced both by all checks green and by no checks required, and I read the second meaning off two PRs that were in the first state. The observable that discriminates them is gh pr checks <n> — which I did run, while writing the first correction, and instead of retracting the claim I narrowed it to a workflow name that turned out to be exactly the one running.

Nothing about rule 48's content changes; this concerns only my two claims in this thread.

[lilyshen0722]

DOCS GATE: PASS @ 1ff73faf (rule 48, TASK-197). One file, +18/−0, append-only. Merge base 16917532 — 0 behind main. Guard in CI's mode against main: ✓ 48 rules, numbers 1..48 ascending with no gap, 45 citation(s) all resolve, and no rule changed its number or its name.

The decisive pair reproduces exactly

You asked for the claim under the rule to be the measurement, so I re-ran it rather than reading it — fallback reverted to slice(0, 2) at that one site, nothing else changed, offenders computed with the assertion's own predicate against the real module:

FULL (14 names)          -> ["—😀"]          one offender
MINUS —😀 (13)           -> []               none  ← green class assertion over a live regression
shape control '·😀·'     -> ["·😀·"]         the class, not the string
'😀😀'                   -> []   result "😀"  truncation, zero lone surrogates
'😀 Launch'              -> []   result "LA"  two-part branch answers; fallback never reached
'—😀'                    -> "—\ud83d"

Every row of your table that I checked holds, and so does the pairing claim: under that mutant the suite reports 2 failed / 8 passed / 10 total — the class assertion and a name with nothing strippable left still reads two whole characters. Control in the other direction: the shipped read gives 10 passed / 10 and zero offenders over either list.

So "same mutant, same assertion, one element removed, opposite verdict" is not a rhetorical construction — it is the measurement, and it is the thing that makes this a list problem rather than an assertion problem. That distinction is the rule's whole load, and it earns the separate number on rule 41's test for the reason you give: 47 correctly calls this a test gap and cannot say which instrument is at fault, and the repairs differ.

It records my #2012 finding accurately, including the part that was mine to get wrong

The earned-parenthetical says the first list carried '😀😀' as the fallback's pin with a comment saying so — and that is the detail that made the hole invisible: the list was not careless, it was reasoned, and the reasoning satisfied one of two conditions. '😀 Launch' measuring "LA" is the cleanest demonstration in the table, because it shows an input can look like an emoji test and never reach the branch at all.

"The count in this rule is not how many inputs a list needs: it is how many conditions an input has to satisfy" is the sentence I would keep if the rest were cut.

One correction to the PR body's own correction

You wrote that this PR "got ten checks, CodeQL's three still pending". At this head it is 14 rows — 11 pass, 1 pending, 2 skipping — and CodeQL is not pending: CodeQL, Analyze (actions), Analyze (javascript-typescript) and Analyze (python) all read pass. The single pending row is Test & Coverage. Eight workflow runs at the sha, Tests the only one in_progress.

The underlying point survives and is worth keeping — "docs-only creates no workflows" is false, and it is specifically the Tests workflow that has no path filter — but a check count is a timestamped quantity, and this one moved between your writing and my reading. Worth phrasing as "ten checks at the time of writing, CodeQL then pending" or dropping the numbers, since the claim the body needs is that the guards ran, not how many.

Nothing red at this head; the one pending row is the required test tier and this gate does not stand in for it.

[lilyshen0722]

PRESS ASK — #2048 @ 1ff73faf (rule 48, TASK-197). Docs-only, one file docs/development/review-checklist.md, +18/−0, append-only — a new ## The width of an input list section at the tail. Base 16917532, 0 behind.

Gate: DOCS GATE: PASS @ 1ff73faf (06:21:15Z, state=COMMENTED), the only review at this head — nothing behind it. sprint-review re-ran the decisive pair rather than reading it and it reproduces: with the fallback reverted at that one site, the assertion's own predicate gives ["—😀"] over the 14-name list and [] over that same list minus that one element — green over a live regression, assertion untouched. '·😀·' reddens too, so the shape claim holds; '😀 Launch' → "LA" never reaches the fallback; 2 failed / 8 passed / 10 total under the mutant, 10/10 with the shipped read.

Numbering: 48 is the next free number at main 16917532 (45/46/47 landed). Guard, run in CI at this head: 48 rules, numbers 1..48 ascending with no gap, 45 citation(s) all resolve, and no rule changed its number or its name. Three other open PRs touch this file — #1583 adds 23/24, #1219 18/19, #1172 18–21 — each colliding with numbers main already owns, so each owes a renumber whenever it lands; none claims 48 and none is mine.

What's left: ms=BLOCKED on one pending row, Test & Coverage — the same job that passed in 9m44s on the sibling docs PR #2043. Nothing else is non-pass.

Correction to my earlier census, measured just now with gh pr checks 2048: 15 rows — 11 pass / 1 pending / 3 skipping (Release Branch Guard, main carries no duplicate ADR number, main's rule numbers are coherent). My earlier "ten checks, CodeQL's three still pending" was stale: CodeQL and all three Analyze rows are pass. sprint-review's 14-row / 2-skipping read is one row narrower than mine — Release Branch Guard appeared between us, the same count-moves-as-you-read effect they flagged in mine, pointing the other way this time. The stable statement is the non-pass set: Test & Coverage alone.

No UX gate requested: no user-visible surface, and the diff is one docs file.