The deviations table every doc in here carries, and it is the most-read part of
them. Seven entries, of which three are worth the reader's time.
`proposeBirthCertificate` was planned to take an `origin` parameter; it already
takes the whole `DkgSession`, so it reads `key.origin()` and nothing in the
repository or the ritual view model changed. A parameter would have been a
second source for one fact, and the proposer's copy of it at that.
Phase 3 put a button on four screens and Phase 7 replaced all four with one
`LazyListScope` extension, so they were written twice. The giveaway was already
in Phase 0.3, which argued the dialect's entry point had to be a screen because
a card cannot *grow* into a list -- the same argument applied to all four, and
the section should have been planned where the buttons were.
And Phase 8's own claim was wrong: the M3 adaptive floor cannot be raised by
this work. The floors count `MaterialTheme.breakpoint`, `BoxWithConstraints`,
the pane scaffolds and the navigation components; `readableContent()` and
`NavigateBackButton` are neither, so a screen that follows every rule in
CLAUDE.md adds nothing to either count. Raising a floor to the number the tree
happens to sit at would make it fail the next time something unrelated was
removed. The floors guard two-pane layout and the navigation shell, which a
detail screen is not, and they stay where phase 6 of the conformance work left
them. Recorded rather than quietly dropped, because the next plan will want to
make the same assumption.
Pointers from docs/README.md, from docs/subgroups.md beside the multiple-parents
line, and from docs/project-feature.md -- where a project's own room was the
first thing that file said it lacked, and which now says the rows stay in the
parent's tables all the same.
Phase 8 of docs/subgroups-for-entities.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Four entities, one shape: `id`, `name`, `chatRoomId` and a per-type kind. So the
convenience function the title asks for is four field reads, and recording that
is most of what this doc does -- the rest is the part that is actually missing.
Nothing in the app can say which subgroup a project's room *is*. A name
pre-filled into the picker gets a room related to its entity by a string
somebody typed once, which is the same bargain a dialect already loses: nothing
in the schema makes a dialect unique, so its identity is `(language, country)`
and never its name. So the link goes on the birth certificate -- the one artefact
in the relationship that is signed, travels, and is already read on both sides --
as an optional `subgroupFor` tag the parent's quorum signs along with the name it
already signs.
Eight phases, one commit each, one migration. Phases 1-3 are a shippable release
on their own and are exactly the cheap version of this feature; 4-7 add the tag,
the `DkgSession` columns that carry it past the ceremony, and the reverse view
that makes it worth having.
Two things Phase 0 found by doing what it says:
A dialect has no detail screen, so it is Phase 2 and not a button on a card. The
first draft said the opposite; the reversal is recorded in the doc rather than
edited out, because the argument against the card is the argument for Phase 7 --
a `ListItem` in a `LazyColumn` has nowhere to put a list of the subgroups made
for an entity, and a dialect is the entity a room is most likely to want several
rooms for.
And the schema number collided. 23, 24 and 25 are taken on an unmerged branch;
this takes 23 anyway, because a number is free relative to the merge base and
pre-allocating 26 moves the renumbering rather than avoiding it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
