[v0.1/P2] Exercise every minor-ledger row with a mixed-minor conversation #164

Open
opened 2026-09-06 14:47:16 +09:00 by natsukium · 0 comments
Owner

Problem

#50 made the minor ledger executable and put a send-side authorization gate on
FrameWriter, but left one of its acceptance criteria unfilled: "mixed-minor
golden conversations exercise every ledger row in both directions and assert
that the older peer sees only shapes it defines."

What landed instead are per-shape send-gate tests
(crates/felis-transport/src/framing.rs): one arm, one field and one
closed-enum value, each from a different minor, refused below their minor and
passing at it. That proves the mechanism. It does not prove that every row of
the ledger behaves as its "Older peer" cell says, end to end, on a real
connection with a pinned effective minor.

Why it is out of scope for #50

The accepted triage plan on #50 moved this out of the v0.1.0 scope explicitly:
the mechanism is what the freeze boundary needs, and a per-row conversation
matrix at ten rows would mostly re-test the same three shapes through ten
copies of the same harness. The decision is recorded in
docs/explanation/architecture/ipc.md "The ledger is the review gate" as the
gate the first minor added past the freeze must fill.

What the follow-up should do

  • Build a harness that drives a real daemon/client pair with the effective
    minor pinned below and at each ledger row's minor, in both directions.
  • Assert per row that the older peer receives only shapes its minor defines,
    and that the documented degrade (SPAWN_FAILED, SESSION_ENDING, an omitted
    field, an omitted status row, a local refusal) is what actually happens.
  • Wire it into just check beside the ledger-coverage test, so a new minor row
    without a conversation fails the build.

Overlaps #29 (golden conversations for the CLI and bridge JSON surfaces); the
harness there may be the right host for this, or it may need its own, which is
part of the follow-up's design.

Split from #50.

## Problem #50 made the minor ledger executable and put a send-side authorization gate on `FrameWriter`, but left one of its acceptance criteria unfilled: "mixed-minor golden conversations exercise every ledger row in both directions and assert that the older peer sees only shapes it defines." What landed instead are per-shape send-gate tests (`crates/felis-transport/src/framing.rs`): one arm, one field and one closed-enum value, each from a different minor, refused below their minor and passing at it. That proves the mechanism. It does not prove that *every* row of the ledger behaves as its "Older peer" cell says, end to end, on a real connection with a pinned effective minor. ## Why it is out of scope for #50 The accepted triage plan on #50 moved this out of the v0.1.0 scope explicitly: the mechanism is what the freeze boundary needs, and a per-row conversation matrix at ten rows would mostly re-test the same three shapes through ten copies of the same harness. The decision is recorded in `docs/explanation/architecture/ipc.md` "The ledger is the review gate" as the gate the first minor added past the freeze must fill. ## What the follow-up should do - Build a harness that drives a real daemon/client pair with the effective minor pinned below and at each ledger row's minor, in both directions. - Assert per row that the older peer receives only shapes its minor defines, and that the documented degrade (`SPAWN_FAILED`, `SESSION_ENDING`, an omitted field, an omitted status row, a local refusal) is what actually happens. - Wire it into `just check` beside the ledger-coverage test, so a new minor row without a conversation fails the build. Overlaps #29 (golden conversations for the CLI and bridge JSON surfaces); the harness there may be the right host for this, or it may need its own, which is part of the follow-up's design. Split from #50.
Sign in to join this conversation.
No description provided.