[finding] Two plugin-detail spec-parity tests still narrate rc.6 strip-mode as fact — stale prose that survives the GA pin because no assertion depends on it

[os-steve]

Found while doing #4910's ruled widening scan (the strip → strict flip in
@objectstack/spec@17.0.0 GA). Filed unassigned; not fixed on that branch, because
#4910's claim bounds its file surface to parity tests that assert a green safeParse
carrying an undeclared key, and neither of these does.

What the scan found

GA closed the props schemas under objectstack#4001 batch A: an undeclared key used to
parse green and vanish from data, and now fails with unrecognized_keys naming the key.
#4910 fixed the two probes that asserted the old behaviour. These two files carry the same
falsified premise in prose only — a load-bearing explanatory comment stating strip mode
as a present-tense fact about the installed spec:

file	line	the comment
packages/plugin-detail/src/__tests__/recordRelatedListInputs.spec-parity.test.ts	~100	"RecordRelatedListProps is a strip-mode z.object: an UNDECLARED key also parses green, it is just silently gone from data afterwards"
packages/plugin-detail/src/__tests__/recordDetailsInputs.spec-parity.test.ts	~278	"These props schemas are strip-mode z.objects: an undeclared key is dropped from data with no error at all"

Both sit above a hideFields / relationshipValueField key-reachability assertion and
exist to justify why the criterion is key survival rather than success === true. The
justification is still correct; the mechanism it cites is not, on GA.

Why it is invisible to every gate

Both blocks parse payloads carrying only declared keys, so nothing they assert changes
across the flip. Measured: under a GA overlay both files are green.

Test Files  1 failed | 219 passed (220)      # 220 = every test file importing @objectstack/spec
                                             # the 1 is #4911, unrelated

That is precisely what makes this worth a card rather than nothing: a comment that no
assertion depends on cannot be caught by running anything. It will read as current to the
next agent, and the repo has already been bitten by exactly this shape — see #4611
("a comment claim that is false against the installed pin, and it nearly made a seat
implement a no-op").

Note on the sibling that is already correct

packages/plugin-detail/src/__tests__/recordHighlightsInputs.spec-parity.test.ts in the
same directory took the pin-aware disposition in PR #4671 and states the two-mode contract
properly. It is the model for what these two want — and recordDetailsInputs is a
half-converted case: its section-key block at ~234 is already pin-aware and asserts
unrecognized_keys, while its top-level block at ~278 still narrates strip mode. So one
file disagrees with itself, forty lines apart.

Suggested disposition

Prose-only edit in both files: state the verdict (an undeclared key is never authoring
surface) and note that the contract says it two ways depending on the installed pin,
pointing at specRefusesUnknownTopLevelKeys in the sibling files as the behavioural probe.
No assertion needs to change; no gate is affected. Worth confirming whether the
recordDetails top-level block should also grow the pin-aware probe rather than only
losing the stale sentence — that is the judgement call this card wants.

---

Generated by Claude Code