The Door/Domain Surface Is Served by a Dedicated `dominios` Content-Kind, Not the Reused `projects` Kind
Accepted
Context
ADR-057 built the difusión vestibule as doors projected from `spine.ncl`, and ADR-064 re-architected the funnel to four doors over five domains plus the content-vehicle-convergence membrane. The SITE that renders this (`outreach/site`, a rustelo-framework SSR app) does not yet carry that model.
The site mounts the doors on the rustelo framework's `projects` content-kind: `scripts/build/gen-spine-pages.nu` emits each door as a post of the EXISTING `projects` kind, served at `/projects/<key>` · `/proyectos/<key>`. Its own header (lines 6–8) documents WHY: "Mounting on an already-compiled kind" avoids the ContentKind codegen boundary. That was a deliberate shortcut to ship without a rustelo rebuild.
The shortcut leaves a permanent name↔thing drift. In ontoref these are NOT projects — they are DOMAINS (the `code/domains/` axis, ADR-012). Yet the surface is structurally `projects` end-to-end: route `/projects`, `content_type: "projects"` in the generated index, directory `content/projects/`, view `ProjectsCTAView`, the `projects-*` i18n strings (whose default copy is "Open source projects and platforms"). The framework's own demo portfolio (kogral, stratumiops, vapora…) shares the kind, conflating ontoref's domains with an author portfolio.
Three concrete drifts follow: the site renders three doors (the fourth, authoring, is missing since ADR-064), names the surface "projects", and surfaces the membrane nowhere.
The cost is known and verified: routing a new/renamed kind crosses rustelo's build-time codegen (`rustelo_tools/src/build/build_tasks/` consumes `content-kinds.toml` + `routes.ncl`, baked into `rustelo-htmx-server`). The content registry is dynamic (`ContentKindRegistry { kinds: HashMap }`) but routing is not. A vestigial `doors` kind already exists in `content-kinds.ncl` reusing `ProjectsCTAView`, so no new Rust view is required — only the boundary crossing (a rustelo rebuild + reinstall of the `~/.local/bin` binaries).
Decision
The door/domain surface is served by a dedicated `dominios` content-kind, replacing the reused `projects` kind. This reverses the gen-spine-pages.nu "reuse the already-compiled projects kind" shortcut, accepting the rustelo rebuild as the cost of an honest surface.
Kind key: `dominios` (the project's settled vocabulary). Route `/dominios` for both languages (a brand term, not localized; `/domains` as an EN route is a deferred sub-choice). The kind reuses `ProjectsCTAView` (no new Rust view); it is registered in `content-kinds.{toml,ncl}`, `content.ncl`, and `routes.ncl`, then activated by a rustelo rebuild + reinstall.
The `dominios` content is PROJECTED from `spine.ncl` by `gen-spine-pages.nu` — all FOUR doors (developer, infrastructure, personal, authoring) into `content/dominios/<lang>/`, served at `/dominios/<key>`; the spine hrefs (`/projects/*` → `/dominios/*`) update in `spine.ncl`, `home_spine.ftl`, `home.j2`.
The membrane (content-vehicle-convergence, ADR-064: librosys↔rustelo) is surfaced on `/dominios` as a NON-door block — five domains, four doors, one membrane — so the asymmetry is visible, never flattened into a fifth door card.
The framework `projects` kind is decoupled from ontoref's domains. Whether the legacy portfolio (kogral, stratumiops…) is removed or kept as a separate author-portfolio surface is a follow-on decision, not part of this ADR.
This touches the rustelo framework (a separate vehicle codebase), NOT ontoref's shipped protocol surface (code/ontology/schemas, install/templates) — no ontoref migration.
Constraints
- Hard The door/domain diffusion surface MUST be served by a dedicated `dominios` content-kind (route `/dominios`), not the reused `projects` kind. The generated content MUST NOT carry `content_type: "projects"` for the doors.
- Hard The `dominios` content MUST be projected from `spine.ncl` by gen-spine-pages.nu (all four doors), never hand-authored. The generated files MUST carry the GENERATED banner so drift checks catch hand edits.
- Soft The content-vehicle-convergence membrane (librosys↔rustelo) SHOULD be surfaced on `/dominios` as a non-door block. The site MUST NOT render rustelo as a fifth door nor merge developer and authoring into one door — preserving four doors over five domains.
Alternatives considered
- Relabel only — reuse the `projects` kind, rename the visible strings to Dominios/Domains — rejected: Restart-cheap but dishonest: route, content_type, directory and view stay `projects`. The name↔thing drift the decision exists to remove would persist in the structure a consumer actually reads.
- Keep reusing `projects` as-is (the status quo shortcut) — rejected: The shortcut's own rationale was 'avoid the rebuild', not 'projects is the right model'. With the domain model now settled (ADR-064), the structural lie is no longer acceptable.
- Rename the kind key `dominios` but localize the route as en=`/domains`, es=`/dominios` — rejected: Defensible for bilingual consistency, but `dominios` is the project's chosen brand term for the surface; a single canonical route avoids a split. Kept as a deferred sub-choice, not a blocker.
- Author the `dominios` content by hand instead of projecting it from spine.ncl — rejected: Re-creates the exact hand-maintained drift this plan was opened to fix (Layer 1). The generator already projects the doors; it must point at the new kind, not be bypassed.
Anti-patterns
- Relabeling the Strings While the Structure Stays `projects` — The visible i18n is renamed to Dominios while the route, content_type, directory and view stay `projects`. The surface reads 'Dominios' but every machine-facing layer still says projects — the drift is hidden, not removed.
- Hand-Authoring the Dominios Content — The dominios door pages are written by hand instead of projected from spine.ncl, re-creating the Layer-1 hand-maintained drift the plan was opened to fix.
- Flattening the Membrane into a Fifth Card — The site renders five domain cards (rustelo among them) or merges developer and authoring, collapsing the 4-doors/5-domains asymmetry and re-modeling the synergy on the audience axis — the ADR-064 anti-pattern, now on the site.