[Chat v1 P2 Gate] Canonical reads verified

[CompleteDotTech]

Bead cave-8ywi2 · Phase 2 · owner Cross-repo · surface shared

This is a phase gate, not an implementation task. It closes on verified evidence, not on code.

Current state (verified 2026-08-22)

Cannot pass. No Phase 2 implementation exists.

Work

Phase 2 gate. Blocked by every Phase 2 implementation and conformance bead; unblocks the Phase 3 implementation lane.

Next

Blocked on cave-mfcsz, cave-g9d49, cave-3yax4, cave-ff3j6, cave-hjy2f.

---

Register: OpenCoven/chat → docs/superpowers/plans/2026-08-15-opencoven-chat-program-tracking.md (root epic cave-k0aqq).
Phase plan: docs/superpowers/plans/2026-08-15-phase-2-*.md.
Filed because the program bead graph is not reachable from the Windows checkout; this issue is the working record until it is.

[CompleteDotTech]

Gate executed — verdict: does NOT pass. Cave's half does.

Executed as cave-ma00l (this issue's own bead cave-8ywi2 does not resolve from the
Windows checkout; the parent record is untouched). PR #4951. Full record:
docs/workflows/chat-v1-phase-2-canonical-reads-gate.md.

The failing criterion is not a Cave one

Bead	Issue	Owner	State, 2026-08-23
cave-mfcsz	#4834	Cave	Closed — routes shipped (#4856), referenced (#4850)
cave-g9d49	#4835	Coven	Closed — OpenCoven/coven#783, 83443a55
cave-3yax4	#4836	SDK	Open. Pull-only on OpenCoven/sdk; needs a fork PR
cave-ff3j6	#4837	Chat	Open
cave-hjy2f	#4838	Cross-repo	Open — Cave third recorded, SDK and Chat thirds outstanding

The prerequisite #4841 is closed, and CLIENT_V1_AUTHENTICATED_PATHS now lists exactly
the five paths that have a route.ts calling requireScope.

"All Phase 2 beads are closed" is therefore false, and two of the three open beads live in
repositories this one does not own. No Cave evidence closes them.

What Cave's half now rests on

Forty-three mutations applied to shipped canonical-read behaviour, each run against every
suite that plausibly covered it. 36 caught, 7 survived, zero code defects. Two no-op
controls survived throughout, so a caught verdict is not the harness failing everything.

All seven survivors were correct behaviour that nothing proved:

• Five of the same shape — a shared helper being covered is not the claim that a route
  calls it. /projects and /conversations/:id/messages could swallow a malformed query
  and serve the default page instead of a 400; /projects, /familiars and
  /conversations/:id could let an unprojectable row or a throwing store escape as a
  non-envelope Next error page. The conversations list route had all of these tests; its
  four siblings had none.
• The cursor budget-boundary case asserted <= 512 against a ~180-character token, so its
  own comment ("the budget boundary itself is admissible") was a claim it did not make —
  the ceiling could be wrong by 200 characters with nothing failing.
• authenticated-route-refusal.test.ts derives its tripwire count from factory.length,
  which stops counting at the first defaulted parameter. Giving a route's sources a
  default installs zero tripwires and makes every "nothing was consulted before the
  credential settled" assertion pass against an empty list.

All seven are now caught. No source file changed.

Real-authority conformance, release build over a real socket, --include-ttl:
105 assertions, 105 passed, 0 failed, 0 skipped, recorded at
docs/client-v1-conformance-results/2026-08-23-v0.3.9-win32-cave-ma00l.json.

Two things the record says that this issue should carry forward

• Criterion 2 ("no second conversation database or browser canonical storage") holds
  for this surface. Group chat is a partial exception: reply and prompt text are written
  to <caveHome>/conversations/ via /api/chat/send, but the coven definition and the
  group's turn-graph are localStorage-only, capped at 200 turns, and persisted by no
  route. An index loss rather than a content loss — recorded, not decided.
• Criterion 3 ("real Cave and Coven read journeys pass") is met for Cave only. This run
  serves /familiars from a loopback fixture daemon, not the production Coven daemon —
  the first entry in the record's own notCovered.

What would close this gate

#4836, #4837, and the SDK and Chat halves of #4838. Cave-side, nothing is outstanding.

[CompleteDotTech]

Post-merge verification of the gate that landed for this issue (PR #4951, squash dbf90753f), by independent mutation testing rather than by re-reading the PR.

Verdict: the gate is sound, with one named hole. 19 mutants applied to shipped source, run, reverted; 18 caught, 1 survived, plus two no-op controls that correctly survived — so a CAUGHT verdict is the gate firing, not the harness failing everything.

Ten of those mutants were ones the gate was never tuned on, and all ten fired — including a raw-registry-row field leak, a loopback-trust bypass, an unbounded transcript page, and a route echoing the URL id instead of the canonical sessionId. It drives real handlers and asserts on responses, so this is behavioural, not a source-regex check. It also fails closed: giving a route factory's sources a default parameter would undercount factory.length and install zero tripwires — the textbook fail-open — and assertTrustworthyArity refuses the factory outright instead.

The one hole, so nobody reads this issue's title as broader than it is.

PR #4951's description states the gate now catches "a spurious next on a continuation page that is both full and final". That holds for paginateClientV1Keyset and not for paginateClientV1Sequence. Both carry byte-identical logic on main:

src/lib/server/client-v1/pagination.ts
  :255  keyset    const next = window.length > limit && items.length > 0
  :295  sequence  const next = window.length > limit && items.length > 0

Mutating the sequence paginator the same way is behaviour-changing (4 rows, limit 2 — shipped: page2 ['c','d'] hasMore=false; mutant: hasMore=true plus a next leading to an empty page) and survives all 32 client-v1 api test files. The identical mutation in the keyset paginator is caught immediately.

It matters because /conversations/:id/messages uses the sequence paginator — the read PR #4951 itself calls "the single canonical read whose page cost scales with how much was said". A walk-to-exhaustion test structurally cannot see it, which is the same argument the PR gave for adding the keyset assertion. The reasoning transferred; the test did not.

Nothing is broken. The shipped code is correct; this is an assurance gap, not a defect. Remedy is one test arm, no source change. Tracked as bead cave-z9h59 (P1).

One further scope note on the gate's self-sufficiency: dropping a live route from CLIENT_V1_AUTHENTICATED_PATHS is caught, but by auth.test.ts and api-contracts.test.ts rather than by this gate's own files — authenticated-route-refusal.test.ts derives its route set from that list, so alone it would simply test fewer routes and stay green. The backstop is real; it just lives elsewhere in the api suite.

The PR's own self-disclosed limitations were checked and are accurate: checkRecordValues covers project / conversation / message and not familiar / credential / pairingRequest / pairingStatus, exactly as stated. It did not overclaim anywhere else.