docs(design): resolve the three M3-blocking decisions (§22 draft)

- Default project id: config-derived slug (DEFAULT_PROJECT_ID > slug of
  deployment name > 'default'); M1's 'default' bootstrap is re-stamped in M3
  before any /p/ URL is public, so it's meaningful (/p/ohm/) and never renamed
  live. §22.13.
- Entry-noun in URLs: generic /p/<project>/e/<slug> for every type; the noun
  (RFC/Spec/Feature) is a type-driven UI label, not in the path. §22.10.
- Existing RFC-NNNN: kept as a frozen, read-only legacy display label in
  frontmatter id (preserves citations); never used for lookup, never assigned
  to new entries. §22.4, §2.3 amended.

Threads through §22.4/22.10/22.13, the §2.3 amendment, and the M3 slice.

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

docs/design/multi-project.md

@@ -269,8 +269,10 @@ Two chrome layers result:
 
 ## 5. Routing & UX
 
-- RFC routes gain a project prefix: `/p/<project>/rfc/<slug>`,
-  `/p/<project>/proposals/<n>`, `/p/<project>/philosophy`, etc.
+- Entry routes gain a project prefix with a **generic `/e/` segment**:
+  `/p/<project>/e/<slug>`, `/p/<project>/proposals/<n>`,
+  `/p/<project>/philosophy`, etc. The segment is the same for every type; the
+  noun shown around the slug is a type-driven label, not part of the path.
 - Root `/` becomes the **deployment landing = project directory** (the
   Wiggleverse home). For an anonymous or non-member visitor under gated
   default, that's only public/unlisted-by-link projects.
@@ -293,10 +295,13 @@ The N=1 path keeps existing single-project deployments working:
 
 1. Migration creates one **default project** from current config (`META_REPO`
    → `content_repo`, `VITE_APP_NAME` → `name`, visibility seeded to match the
-   deployment's current open posture, likely `public`).
+   deployment's current open posture, likely `public`). Its `id` is a
+   config-derived slug (`DEFAULT_PROJECT_ID`, else slug of the deployment
+   name, else `default`); M1's `default` bootstrap id is re-stamped to it in
+   M3 before any `/p/` URL is public.
 2. Every existing row's `project_id` is stamped to that default project.
 3. An optional default-project redirect keeps old `/rfc/<slug>` URLs alive
-   (308 → `/p/<default>/rfc/<slug>`).
+   (308 → `/p/<default-id>/e/<slug>`).
 
 This is the SPEC §20 upgrade-steps block.
 
@@ -346,10 +351,15 @@ This confirms the registry decision and fixes how it integrates:
   `bdd` scenario model stay free-form markdown or get a structured
   Given/When/Then schema the app parses? Drafted shallow; pin before the
   type-surface slice.
-- **Entry-noun in URLs/labels.** Slug-only identity means no `RFC-NNNN`. Is
-  the route segment generic (`/p/<project>/e/<slug>`) with the displayed noun
-  type-driven, or does the segment itself vary by type? (Leaning: generic
-  path segment, type-driven label.)
-- **Existing graduated numbers.** OHM already has `RFC-0001…` in filenames.
-  On dropping numeric identity, do those numbers survive as a display/legacy
-  artifact, or get normalized to slugs? (Migration/back-compat detail.)
+- **Entry-noun in URLs/labels** — *resolved 2026-06-02:* generic route
+  segment `/p/<project>/e/<slug>` for every type; the displayed noun
+  ("RFC"/"Spec"/"Feature") is a type-driven label, not part of the path
+  (§22.10, §22.4a).
+- **Existing graduated numbers** — *resolved 2026-06-02:* pre-change graduated
+  entries keep their `RFC-NNNN` `id` in frontmatter as a frozen, read-only
+  legacy display label (preserves citations); never used for lookup, never
+  assigned to new entries (§22.4).
+- **Default project `id`** — *resolved 2026-06-02:* a config-derived slug
+  (`DEFAULT_PROJECT_ID`, else slug of the deployment name, else `default`);
+  M1's `default` bootstrap id is re-stamped in M3 before any `/p/` URL is
+  public, so it's meaningful (e.g. `/p/ohm/`) and never renamed live (§22.13).