Residuals from #1127's QA: a surviving test fake, dead delegate types, an unfalsifiable null claim, and connect.id typing

[borisno2]

Found by the QA acceptance pass on #1127 (sign-off). All non-blocking — #1127 passed — and grouped here so a fix can be reviewed as one small diff.

1. Story 22 is PARTIAL — one hand-fake of the secured read surface survives

packages/ui/tests/components/RelationshipTableLinkEdge.test.ts:60-77 still hand-fakes the secured read surface. #1354 extended that file rather than converting it, so it was missed by the sweep.

Story 22 asks that UI and MCP tests run on the Test context so no test hand-fakes the data surface. (Pure-render component tests faking at the prop level remain legitimate — this is not one of those.)

• RelationshipTableLinkEdge.test.ts drives the Test context instead of faking the secured read surface
• A sweep confirms no other hand-fake of that surface survives in packages/ui/tests

2. Dead public exports

FindManyArgs, FindUniqueArgs and CountArgs are still exported after #1370 removed the delegates they described. They name a surface that no longer exists, so an editor still offers them to a consumer.

• The three types are removed, or documented as intentionally retained
• No published entry point re-exports them

3. Story 19's | null claim is not falsifiable

Story 19 — "a relationship cell renders an unreadable related row gracefully" — is pinned by tests, but CellComponentProps.value is typed unknown, so the | null compile guarantee the story claims cannot actually fail at the type level. The runtime behaviour is covered; the type claim is not.

• CellComponentProps.value is typed so a | null to-one is a compile-time guarantee, not only a runtime one
• Removing the null handling becomes a type error

Note the house rule: unknown must not appear in an exported type, which this is.

4. MCP advertises connect.id as string for every list

Story 9 asks that the update/delete tools' where.id be typed per list, which #1366 delivered via parseListId. But connect.id inside a data payload is still advertised as string regardless of the list's id type — so an integer-keyed list advertises the wrong type on the write side while the read side is correct.

• connect.id is advertised with the related list's own id type
• An integer-keyed list validates an integer there, as where.id already does

5. Stories 6 and 8 rest on the diff rather than a test

Story 6 (the fields wire shape is unchanged) and story 8 (where is the Where vocabulary, with a description saying so) were accepted on inspection — no test pins either. Both are contract claims about a public surface and should be pinned.

• A test pins the fields wire shape against a fixture request
• A test pins that where's advertised schema description names the Where vocabulary

Not a defect, recorded so a story is not read as stronger than it is

orders:>5 still parses but now silently degrades to free text, so a saved view using it returns different rows than before. This is intended per ADR-0055 and story 13, but story 11 ("the filter builder keeps parsing my bookmarked URLs") should not be read as promising the same results. See also #1356, which covers the case where such a degrade widens an AND chain.

---

Generated by Claude Code