Phase 7c of docs/project-feature.md, and the last of the phases this plan
builds. 8 and 9 -- removal, and projects that span rooms -- stay deferred.
The resolver comes first because the screen depends on it. A membership event
carries two 64-character ids and nothing else, so proposing one on its own
means every other member is shown "sign a4f1be55d0c3" and asked to agree. That
is not a question anybody can answer, and the plan said not to ship this screen
without the fix.
So `FrostSigningViewModel` resolves what the proposed events refer to -- the
profile behind a creator or an owner, the artifact and label behind a version,
the name behind a project -- and hands `summarize` a lookup. Synchronous, because
two of the four call sites are composables and cannot await a database;
pre-resolved in the view model for the same reason. Only what this device
already holds: a key with no profile and an id with no row are left out and fall
back to a short hash, which is truthful rather than a gap.
A project's own id still resolves to nothing while it is being proposed, since
nothing has applied it yet. That is why a membership's summary says the version
first.
`AddToProjectScreen` is the simpler half of founding a project: the project
exists, so its id is known and there is no lead and no batch -- one event, one
session. Candidates are filtered to what the project does not already hold
rather than shown and refused, because a duplicate membership is a second event
with its own id and nothing downstream would stop it; it would just cost a
quorum to say what the group has already said.
One at a time, by radio button rather than checkboxes. A quorum per thing added
is the grain this app signs at, and a multi-select here would quietly be a batch
whose items a member has to weigh separately anyway.
M3 budgets met. 1403 tests, no failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3668b39575