docs: record what building projects changed about the plan

Five places the build chose differently, and one thing the plan did not
anticipate: a project reaches a chronicle only off the GroupSignedEvent record,
because the deprecated rebuild has no `toProjectEvent` and deliberately never
will. `recordSignedEvents` catches its own failure so a ceremony that succeeded
is not reported as failed, which leaves a narrow window where the row exists and
the signed event does not -- a project this device can show and can never hand
on. There is a test holding that case open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/README.md

@@ -73,10 +73,12 @@ smallest of the plans: it changes the entrance to the direct-message flow and
 nothing past it, so read it with `StartDirectMessageToNpubOrNip05Dialog` and
 `ChatRoomMessagingViewModel.initiateNewChat` open, its four decisions before its
 four phases, and its table of where the build chose differently first.
-The projects note is a phased plan that has not been built, and is the only one
+The projects note is a phased plan that has been built as far as its seventh
+phase, and is the only one
 whose starting point is outside this repository: the platform's server schema,
 `mantra-db-models`, has had the three models for years. It reads as the
 translation domain's unanswered question — the app can say what a chapter is and
 who translated it, and cannot say what any of it is for — so read it after the
 nip30303 conventions are familiar, its decisions before its phases, and its scope
-fork before either, because that one changes the shape of the rest.
+fork before either, because that one changes the shape of the rest, and its
+table of where the build chose differently first.

docs/project-feature.md

@@ -1,6 +1,28 @@
 # Projects
 
-A phased plan, not yet built.
+Phases 0 through 7 are built. Phases 8 and 9 -- removing something from a
+project, and projects that span rooms -- are not, and the reasoning for both is
+below rather than anywhere else.
+
+**Where the build chose differently**, each of which is explained in the phase
+it belongs to:
+
+| the plan said | the build did | why |
+|---|---|---|
+| a `creator` tag and an `owner` tag | a `creator` tag, and owners as `ContributorTag`s with `ROLE_OWNER` | a project has several owners, which is the cardinality `ContributorTag` is for |
+| the room's project section is new | it replaced a stub | `ChatRoomDetailScreen` already had a heading, a permanent empty line and an `ImplementationPendingRoute`, under a `// TODO: Add projects...` |
+| the `summarize` resolver is Phase 4 | the seam is Phase 4, the resolution is Phase 7c | two of its four call sites are composables and cannot await a database, so the names are pre-resolved in `FrostSigningViewModel` |
+| three chronicle tests to add | three to add and four to fix | the existing suite compares a seeded room against `CHRONICLABLE_KINDS` itself, and one test asserts every chroniclable kind can also be *rebuilt* -- which projects deliberately cannot |
+| around twenty new strings | eighteen, three of them already there | `projects`, `no_projects_exists_in_this_group` and `create_project` came with the stub |
+
+The one thing found while building that the plan did not anticipate: a project
+reaches a chronicle only off the `GroupSignedEvent` record, because there is no
+`toProjectEvent` rebuild. `recordSignedEvents` catches its own failure so that a
+ceremony that succeeded is not reported as failed, which leaves a narrow window
+where a project row exists and its signed event does not -- a project this
+device can show and can never hand on. `ChronicleAssemblyJvmTest.a project is
+only ever chronicled off the record` holds that case open rather than letting it
+be discovered later.
 
 `mantra-db-models` — the platform's server-side Sequelize schema — has had three
 models waiting for this app since before it existed: `project`, with a name and a