Phase 9 of docs/subgroups.md. Most of the plan's test work landed with the phase
it guarded -- 13 pure cases in Phase 1, 10 more in Phase 3, 21 over a real
database in Phases 2, 5 and 8. What was left is the one thing none of them can
reach.
`GroupKeyStateTest` settles Phase 3's rules purely and exhaustively, and
`SubgroupDaoJvmTest` settles that schema 17 holds four columns. Neither can settle
the **join**: that a parentage put on a proposal survives a real signing session,
a real FROST aggregate and a real `record`, and lands on the *row* on every device
rather than only in the event. That is a schema question wearing a protocol
question's clothes, and it is exactly the sort of thing that breaks without
failing -- `record` could drop both fields and every existing test would still
pass.
Three cases on the existing two-device harness in `SignedGroupKeyStateTest`, which
already runs a whole session across two databases with nothing shared but what is
ferried:
- a quorum signing a subgroup's state puts the parent and the whole certificate on
both devices, neither of which was sent a row -- each derived the event from its
own items, re-ran `certifies` against the parent's id, and wrote the same two
columns;
- a real certificate really signed by the parent but naming another room is
refused by `propose` before anything is published, and neither device ends up
with a state;
- a state signed with no parentage keeps both columns null, which is how every
group made before subgroups reads and every top-level group made after.
The parent is a second `KeyMaterial` and its signature is a real FROST aggregate
assembled by hand. Standing up three more databases to get one would have tested
the harness rather than the join.
397 common tests, 708 jvm tests, `m3Audit` meets every budget. All nine phases of
docs/subgroups.md are built.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3ae49bd338