Observation, filed unassigned while re-pointing PR #4639 (#4636). The block is correctly
pinned today; this is about one direction in which two of its assertions cannot fail.
The weakness
scripts/__tests__/quick-reference-current-release-4143.test.ts pins QUICK_REFERENCE.md's
"Current Release" rows to the manifests. Two of them compare by string containment:
:212 — expect(row('Spec'), ...).toContain(fromRoot as string)
:227 — expect(row('Client'), ...).toContain(fromConsole as string)
So a doc row is accepted whenever it contains the manifest range as a substring. That is
one-directional: it catches a doc that is stale in a shorter direction, and is blind to a doc
that states a longer, more specific string.
Measured instance
This is not hypothetical — it is what the GA pin bump just walked into. With the manifests
raised to ^17.0.0 and the doc still saying ^17.0.0-rc.6:
'^17.0.0-rc.6'.includes('^17.0.0') === true
Both range-row tests therefore passed against a doc that was plainly wrong. The drift was
caught only by the catch-all sweep in the same file (:335, "contains only version literals
this test derives from a manifest"), which reported:
QUICK_REFERENCE.md's "Current Release" block states ["^17.0.0-rc.6","^17.0.0-rc.6"], which no
manifest in this tree produced.
So the file as a whole held — but the two assertions whose stated job is to pin those exact two
rows did not, and a reader of a green run would reasonably conclude they had.
Note the asymmetry this creates against :166, the Version row, which the same file asserts
with toContain too but where the failure mode landed the other way — #4642 caught 17.4.0
vs 17.5.0 because neither string contains the other. The containment style only becomes
invisible when one value is a prefix of the other, which is precisely the shape of a
prerelease suffix (X.Y.Z vs X.Y.Z-rc.N).
Options
- A — leave it. The catch-all sweep already covers the gap, so the file's overall verdict
is sound. Costs nothing now; keeps two assertions that read stronger than they are.
- B — assert the row's version token by equality. Extract the version literal from the row
and compare it to the manifest range exactly, rather than asking whether the row contains it.
Makes each row test able to fail for its own reason, which is what its failure message
already claims ("must state the spec range as ...").
B is the honest shape, and it is small. Filing rather than doing it because PR #4639's surface
is the pin bump, and because A is a defensible answer once the redundancy is stated out loud —
the catch-all is genuinely doing the work.
Context: the containment blindness is why the pin bump's first farm run had an unexplained
failure. See #4636 for that accounting.
Generated by Claude Code
Observation, filed unassigned while re-pointing PR #4639 (#4636). The block is correctly
pinned today; this is about one direction in which two of its assertions cannot fail.
The weakness
scripts/__tests__/quick-reference-current-release-4143.test.tspins QUICK_REFERENCE.md's"Current Release" rows to the manifests. Two of them compare by string containment:
:212—expect(row('Spec'), ...).toContain(fromRoot as string):227—expect(row('Client'), ...).toContain(fromConsole as string)So a doc row is accepted whenever it contains the manifest range as a substring. That is
one-directional: it catches a doc that is stale in a shorter direction, and is blind to a doc
that states a longer, more specific string.
Measured instance
This is not hypothetical — it is what the GA pin bump just walked into. With the manifests
raised to
^17.0.0and the doc still saying^17.0.0-rc.6:Both range-row tests therefore passed against a doc that was plainly wrong. The drift was
caught only by the catch-all sweep in the same file (
:335, "contains only version literalsthis test derives from a manifest"), which reported:
So the file as a whole held — but the two assertions whose stated job is to pin those exact two
rows did not, and a reader of a green run would reasonably conclude they had.
Note the asymmetry this creates against
:166, the Version row, which the same file assertswith
toContaintoo but where the failure mode landed the other way — #4642 caught17.4.0vs
17.5.0because neither string contains the other. The containment style only becomesinvisible when one value is a prefix of the other, which is precisely the shape of a
prerelease suffix (
X.Y.ZvsX.Y.Z-rc.N).Options
is sound. Costs nothing now; keeps two assertions that read stronger than they are.
and compare it to the manifest range exactly, rather than asking whether the row contains it.
Makes each row test able to fail for its own reason, which is what its failure message
already claims ("must state the spec range as ...").
B is the honest shape, and it is small. Filing rather than doing it because PR #4639's surface
is the pin bump, and because A is a defensible answer once the redundancy is stated out loud —
the catch-all is genuinely doing the work.
Context: the containment blindness is why the pin bump's first farm run had an unexplained
failure. See #4636 for that accounting.
Generated by Claude Code