source-control: readiness.md rule 3's carve-out lists map as element-wise, but map(f) is a per-page fold

[kyle-sexton]

Found by a post-merge verifier on #2163 (merged as 1b338d74) and reproduced directly. Unlike #2238, this one is in text #2163 added, not in surrounding context.

The claim

plugins/source-control/skills/pull-request/reference/readiness.md, rule 3:

Element-wise filters (select, map over .[]) are safe, because their results simply concatenate.

Why it is wrong

map(f) is defined as [.[] | f] — it builds an array, so it is a per-page fold, exactly what rule 3 prohibits. It is safe only when a trailing .[] re-flattens it.

Measured against a 33-comment endpoint forced to 4 pages (per_page=10):

--jq 'map(.id)'        ->  4 documents   (four separate per-page arrays)   NOT element-wise
--jq 'map(.id) | .[]'  ->  33 lines      safe, but only because of the trailing .[]
--jq '.[] | .id'       ->  33 lines      safe

A reader who takes the rule at face value and writes the natural map(f) gets four per-page arrays — the precise failure rule 3 exists to prevent, sanctioned by rule 3's own carve-out.

Severity

Lower than #2238's class: the wrong result is visibly wrong (four arrays instead of one), not a silent plausible answer. But it is a false statement in a rule published as absolute, in a document whose subject is queries that return cleanly while answering the wrong question.

Suggested fix

Drop map from the safe list, or write it unambiguously as map(f) | .[]. select alone is correct as stated.

[kyle-sexton]

Claimed and fixed in PR (branch cursor/fix-readiness-map-carveout-63e1). Rule 3 now names select and .[] | f as safe and explicitly excludes bare map(f) unless followed by | .[].