Written while the catalogue was on an unmerged branch, so three citations were
replaced with the reasoning stated directly. It landed on mantra during the
build and the merge brought it in, so `DialectScaffold`, `AfricanLanguages` and
docs/african-dialect-catalogue.md are all here.
The restated reasoning stays rather than turning back into links -- a plan that
explains its own rule survives the file it borrowed it from being moved -- but
two cross-references are worth having. `DialectScaffold` is the closest thing in
the tree to `SubgroupOrigin`, and `DialectScaffold.pendingIn` is Phase 7's
`ceremoniesFor` solving the same race one layer up: read what is already in
flight, so two admins looking at the same screen do not propose the same thing
twice. Eighty dialects there, two rooms for one project here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
