A dialect, an artifact, a translation and a project already carry the three
facts a subgroup needs -- the room they live in, a name, and an id -- so
`SubgroupOrigin.of` reads them and hands back a candidate. That is the whole of
the convenience, and it is deliberately only that: no ceremony is opened, no
refusal is re-decided, and the admins and the threshold are still settled in the
picker and nowhere else.
`SubgroupOriginEntity` is an interface rather than four overloads so that
"which things can a subgroup be made for" is a question the compiler answers. A
fifth entity gains the capability by implementing it. The three fields are the
ones already on the rows; the only new one is the kind, as a computed property
so Room never sees it -- a kind is a fact about the type, and a stored copy could
disagree with the event the row came from.
The kind is carried because an id alone would have to be looked up in four
tables to be understood, and a reader without it cannot tell "a project this
device does not hold" from "not a project at all". `Ref` holds both or neither
for the same reason.
Two things the tests are really for. The name comes back bare, because
`MarmotGroupName.of` adds the `#` where the name is used -- into the certificate
the parent signs and onto the room -- and a third place that has to agree is a
third place that can disagree, most easily with the field the user is typing in.
And a blank name stays blank: the picker already refuses to confirm without one,
and inventing a name here would route around a refusal whose job is to be hit.
Phase 1 of docs/subgroups-for-entities.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
153e92f558