docs(design): project types, slug-only identity, initial_state + unreviewed flag (§22 draft)

Extends the §22 multi-project draft along four axes decided this session:

- Project type — each project declares document | specification | bdd
  (immutable, registry-set). One shared propose→branch→PR→graduate engine;
  type only layers entry schema, terminology, and type-specific surfaces
  (spec release-planning, BDD scenarios/coverage). §22.4a.
- Slug-only identity — an entry is (project_id, slug); the per-project
  RFC-NNNN numbering and its allocator are retired. §22.4, §2.3/§13 amended.
- initial_state — per-project landing state for a new entry: super-draft
  (document/spec default) or active (bdd default). §22.4b.
- unreviewed flag — entries that skip straight to active land unreviewed;
  graduation implies review so the normal path is never flagged. Owner
  mark-reviewed clears it; §7 catalog gains an unreviewed filter; mirrored
  into cached_rfcs. §22.4c.

Slicing plan re-sliced six→seven: type/initial_state/unreviewed config ride
M3, type surfaces become M5, membership→M6, hardening→M7.

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

docs/design/multi-project.md

@@ -15,13 +15,15 @@ plainly: "this single repository is its content repository."
 
 This change makes it **deployment : project = 1 : N**, where *today's entire
 deployment becomes the N=1 case*. A **project** is what a corpus is now: a
-content repo, its own slug/`RFC-NNNN` namespace, its own catalog, philosophy,
-branding, member roster, and enabled-models universe. The **deployment** (the
-subdomain — e.g. Wiggleverse) becomes a thin shell hosting a directory of
-projects plus a shared account/notification layer.
+content repo, its own slug namespace, a declared **type** (§ "Project types"
+below), its own catalog, philosophy, branding, member roster, and
+enabled-models universe. The **deployment** (the subdomain — e.g. Wiggleverse)
+becomes a thin shell hosting a directory of projects plus a shared
+account/notification layer.
 
-OHM becomes one project among several (specs, vision docs, …) under one
-deployment.
+OHM — a *document* project — becomes one project among several: specs
+(*specification* projects), behavior suites (*BDD* projects), vision docs, …
+all under one deployment.
 
 The value of this framing: the migration stays mechanical. Everything
 deployment-scoped today splits cleanly into:
@@ -40,15 +42,89 @@ deployment-scoped today splits cleanly into:
    not see a private project exists. `visibility` is still a per-project field
    with `public` and `unlisted` escape hatches (see §3) — gated is the default,
    not the only mode.
-3. **RFC numbering is per-project.** Each project has its own `RFC-0001`,
-   `RFC-0002`… computed as `max(existing IDs in this project) + 1`.
+3. **Entries are identified by slug, scoped to the project.** A fully
+   qualified reference is `(project_id, slug)`. There is *no* type prefix and
+   *no* per-project numeric ID: inside a project the slug alone is
+   unambiguous, and the project (its URL prefix, its chrome) supplies all the
+   surrounding context. This **supersedes** the earlier per-project `RFC-NNNN`
+   allocation idea — graduation (§13) still flips an entry's status, but no
+   longer mints a number.
+4. **Each project declares a `type`** — `document`, `specification`, or `bdd`.
+   Type is chosen when the project is created (in the registry), is immutable,
+   and selects the project's entry frontmatter schema, its terminology/labels,
+   and any type-specific surfaces (e.g. release planning for specifications).
+   All types ride the *same* propose→branch→PR→graduate engine, threads,
+   flags, and chat; type layers on top — it does not fork the lifecycle.
+
+## Project types
+
+A project's `type` is a registry field, fixed at creation. It does **not**
+change the engine — every type uses the same content repo, the same
+propose→branch→PR→discuss→graduate lifecycle, the same threads/flags/chat. It
+selects three things: the **entry frontmatter schema** the project validates
+against, the **terminology** the chrome uses for an entry, and the set of
+**type-specific surfaces** the project exposes on top of the shared catalog.
+The engine treats every entry as markdown + frontmatter regardless of type;
+type-specific behavior is a layer, implemented as a per-type module the
+framework selects on `project.type`.
+
+> These three definitions — especially the specification release-planning
+> surface and the BDD scenario model — are first drafts. The schema/surface
+> details below are proposals to refine, not yet locked.
+
+- **`document`** — long-form normative prose (OHM is the archetype: a model
+  of principles and definitions). Frontmatter is today's entry schema
+  (title, status, owners/arbiters, tags). **No** type-specific surfaces; this
+  is the baseline, and the N=1 default project (§7) is a `document` project.
+- **`specification`** — a versioned technical specification (this app's own
+  `SPEC.md`, with numbered normative sections and upgrade steps, is the
+  archetype). Frontmatter adds spec metadata (e.g. `version`, lifecycle
+  `status` of draft/active/superseded, `supersedes`). Type-specific surface:
+  **release planning** — group entries/changes into versioned releases, track
+  the changelog + upgrade-steps for each, and show "what's in the next
+  release." (This mirrors how rfc-app itself runs VERSION + CHANGELOG +
+  §20 upgrade steps.)
+- **`bdd`** — behavior-driven feature specs: each entry describes a feature
+  as scenarios in Given/When/Then form with acceptance criteria. Frontmatter
+  adds feature metadata and an optional link to the `specification` entries a
+  feature verifies. Type-specific surface: a scenario/acceptance view, and
+  (where a deployment pairs a BDD project with a specification project) a
+  coverage view linking features back to the spec sections they exercise.
+
+Types are an **open set** in shape — a new type is a new module plus a new
+allowed `type` value; it needs no schema migration beyond the enum. Document,
+specification, and BDD are the three defined now.
+
+**Landing state (`initial_state`).** A project also sets what state a new
+entry lands in when its idea-PR merges — `super-draft` (the normal
+propose→review→graduate flow) or `active` (graduated on submission). The
+default comes from the type: `document` and `specification` default to
+`super-draft`; **`bdd` defaults to `active`** — a behavior spec is captured
+fact, not a proposal under deliberation, so it skips the review-then-promote
+gate. It's an independent registry knob, so a deployment can override the
+default per project. This changes only the landing state and whether
+graduation is required; the propose→branch→PR engine is unchanged.
+
+**The `unreviewed` flag.** Skipping straight to `active` means nothing vetted
+the entry, so it lands with an **`unreviewed`** flag set. An entry that reaches
+`active` the normal way — super-draft → graduate — is never flagged, because
+graduation *is* the review. A project owner clears the flag with a
+**mark-reviewed** action (same authority as graduate), and the catalog has an
+**unreviewed filter** so owners can find the entries still awaiting review. The
+flag is an entry property (frontmatter, git-truth like `state`), orthogonal to
+the `active` state and only meaningful on `active` entries.
+
+The separation-of-concerns rule (CLAUDE.md) is satisfied: the *type names*
+and their behavior are framework concepts (like role names), not
+deployment-specific content. A deployment chooses *which* type each of its
+projects is; it does not define new types or rename them.
 
 ## 1. Git topology — one content repo per project
 
 One Gitea org for the deployment, **N content repos** (`ohm-content`,
 `specs-content`, `vision-content`, …). The bot already operates org-wide; it
-gains more repos and one registry repo. Slug uniqueness and `RFC-NNNN`
-sequences become naturally per-repo = per-project.
+gains more repos and one registry repo. Slug uniqueness becomes naturally
+per-repo = per-project (and the slug is the whole identity — see Decision 3).
 
 Rejected alternatives: subdirectories in one repo (`projects/<id>/rfcs/…`)
 churns every path / branch-name / graduation code path and can't carry
@@ -67,8 +143,11 @@ deployment:
 projects:
   - id: ohm                      # url slug, stable, unique in deployment
     name: Open Human Model
+    type: document               # document | specification | bdd (immutable)
     content_repo: ohm-content    # repo under the deployment's Gitea org
     visibility: gated            # gated | public | unlisted
+    initial_state: super-draft   # super-draft | active — landing state of a
+                                 # new entry; defaults from type
     philosophy_repo_path: PHILOSOPHY.md
     enabled_models: [claude, gemini]   # optional; falls back to deployment ENABLED_MODELS
     theme: { accent: "#5b5bd6" }       # optional per-project token overrides
@@ -100,8 +179,10 @@ of them:
 - `notifications`, `actions`
 
 ~15-table migration, all backfillable to a single default project (see §7).
-`api_graduation.py`'s `RFC-NNNN` allocator scopes its `max()` query by
-`project_id`.
+With slug-only identity (Decision 3) there is no per-project number to
+allocate: `api_graduation.py`'s `RFC-NNNN` allocator is **retired**, and
+graduation reduces to the status flip + content-repo move, keyed on
+`(project_id, slug)`.
 
 New tables:
 
@@ -109,6 +190,10 @@ New tables:
 projects(
   id TEXT PRIMARY KEY,          -- 'ohm'
   name TEXT NOT NULL,
+  type TEXT NOT NULL            -- document | specification | bdd (immutable)
+    CHECK (type IN ('document','specification','bdd')),
+  initial_state TEXT NOT NULL   -- super-draft | active (landing state, §types)
+    DEFAULT 'super-draft' CHECK (initial_state IN ('super-draft','active')),
   content_repo TEXT NOT NULL,
   visibility TEXT CHECK (visibility IN ('gated','public','unlisted')),
   config_json TEXT,             -- theme, tagline, enabled_models, …
@@ -189,7 +274,9 @@ Two chrome layers result:
 - 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.
-- Breadcrumb gains a segment: `Wiggleverse / OHM / RFC-0042 · Human › main`.
+- Breadcrumb gains a segment: `Wiggleverse / OHM / Human › main` (the entry
+  is named by its slug; the entry-noun the chrome uses around it is
+  type-driven — "RFC", "Spec", "Feature").
 - The left-pane catalog (§7) becomes per-project; a project switcher lives in
   deployment chrome.
 
@@ -253,3 +340,16 @@ This confirms the registry decision and fixes how it integrates:
 - Per-project `ENABLED_MODELS` resolution vs. deployment universe (§18, §6.6,
   §6.7 funder) — confirm fallback order.
 - Slicing plan for the build (mirrors DEV.md's original slice approach).
+- **Type surfaces — depth of each.** What concretely is in the
+  `specification` *release-planning* surface (its own tables? a release =
+  a tag + a changelog entry + a set of graduated entries?), and does the
+  `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.)