Phase 2 of docs/project-feature.md. Still nothing that writes a row: this is the
shape, the keys and the queries each screen will want.
A project's contents are real foreign keys into this room's own rows, with
CASCADE, like every reference in this family. That is the one-room scope
decision made load-bearing rather than documented: a membership naming a version
this device does not hold fails at insert, loudly, instead of landing as a row
pointing at nothing that every later read has to be defensive about. Projects
that span rooms take those keys away again -- Phase 9, following
`parentChatRoomId`, which is deliberately not a foreign key because a dangling
value is the normal state there -- and that is a migration rather than something
to carry unused until then. `MantraProjectDaoJvmTest` asserts the refusal, which
is also what says Room has foreign keys switched on at all.
The owners are a comma-joined sorted string with an `ownerPublicKeySet()`
accessor beside it, which is what `DkgSession.participantPublicKeys` already
does with a set of keys, sort included and for the same reason. A fourth table
would buy querying by owner, which no screen does. A set stored as text is a
shape that rots, so the accessor is tested against spacing, empty entries and
the single-entry case rather than the happy path.
`fromProjectEvent` refuses an event with no name, no creator or no owners rather
than filling the gap from local knowledge -- which is exactly the failure the
tags exist to prevent. The empty-owner refusal does double duty: an owner list
that comes back empty is what `ROLE_OWNER` missing from `KNOWN_ROLES` looks like
from here, so the guard against a malformed event is also the alarm for that
bug.
No `toProjectEvent()`. Those eight rebuilds serve rooms whose work predates
`GroupSignedEvent` at v13; projects arrive at v21, so every project this app
will ever hold is on file as a signed event. Adding three more would be adding
to a mechanism with a removal checklist already written for it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7afda9cf80