docs(adr): point ADR-006 at the in-repo ADR index (docs/adr/README.md)

Resolves the reviewer finding: ADR-006 referenced "ADR index (section 70)"
but no index file existed in the repository. The References line, the
Decision match sentence and the Revisit trigger §68 reference now name
docs/adr/README.md, so every "ADR index (section N)" claim resolves
inside the repository.

docs/adr/ADR-006-kysely-contained-inside-db-adapter.md

@@ -0,0 +1,122 @@
+# ADR-006: Kysely contained inside DB adapter
+
+- Status: Accepted
+- Date: 2026-08-31
+- Deciders: platform stream
+- References: ADR index (docs/adr/README.md, section 70), ADR-001, ADR-005,
+  Architecture wiki (sections 1, 4, 9), Engineering-Standards wiki
+  (sections 24, 25, 57)
+
+## Context
+
+EPPP is a modular monolith (ADR-001) that keeps every module boundary
+explicit, versioned and CI-enforced. ADR-005 already records the database
+choice — PostgreSQL 18 as the sole canonical database — and with it the rule
+that the `pg` driver and the Kysely query builder are isolated to
+`packages/database-postgres`, the adapter boundary every database access
+passes through. This ADR is the focused record of where the query builder
+itself may live: the containment decision.
+
+Kysely is a type-safe SQL query builder, not an ORM. It gives typed queries
+and composable expressions on top of `pg`, but it still speaks SQL and a
+dialect, and every package that imports it is coupled to that dialect and to
+the adapter's implementation choices. The workspace already depends on the
+containment: `packages/database-postgres` declares `kysely` 0.29.4 and `pg`
+8.22.0 as its exact-pinned runtime dependencies (its only ones), imports them
+in its source and re-exports the pieces the adapter is built on (E00-S03-T02),
+and is the single workspace package whose source may import the driver — a
+rule locked in by `tests/database-postgres-imports.test.mjs` in the
+`database-postgres-imports` CI job and by the architecture fitness tests
+FIT-010 (browser bundles cannot import server/DB packages) and FIT-011 (UI
+cannot import Kysely/pg).
+
+The dependency direction is already fixed: `database-postgres → core ports →
+Kysely/pg` (Architecture wiki §9.1, Engineering-Standards §24). Domain and
+extension packages talk to the database through core repository/port
+interfaces, never through the query builder. What remains to be recorded is
+that this is a standing architectural decision, not a temporary arrangement:
+Kysely stays inside the adapter, and no other package may grow a Kysely or
+`pg` import surface.
+
+## Decision
+
+EPPP keeps **Kysely contained inside DB adapter**. Kysely is an
+implementation detail of `packages/database-postgres` — the single workspace
+package allowed to import `pg`/Kysely (E00-S03-T02) — and the rest of the
+workspace reaches the database exclusively through the adapter's and core
+ports' APIs. No other workspace package may declare `kysely` or `pg` in its
+manifest or import them directly in its source; the `database-postgres-imports`
+CI gate plus FIT-010/FIT-011 enforce this on every PR. Kysely exists only
+where the adapter lives — it is contained, not distributed, and the containment
+is a package-level rule, not a type-level one.
+
+The decision text — **Kysely contained inside DB adapter** — matches the ADR
+index entry (ADR-006, section 70 of `docs/adr/README.md`).
+
+## Alternatives
+
+- **Kysely imported directly by domain/extension packages** — rejected: it
+  would leak SQL-dialect and query-builder concerns into domain and extension
+  code, defeat the single-owner boundary (E00-S03-T02), make FIT-011
+  impossible to honour, and couple business logic to the adapter's
+  implementation.
+- **A dedicated shared query-layer package** — rejected: it would create a
+  second import surface for the driver stack, split ownership of the dialect,
+  and add a package whose only purpose is to widen the boundary; the adapter
+  already owns the typed surface callers need.
+- **Full ORM (e.g. Prisma/Drizzle) instead of a query builder** — rejected:
+  schema is owned by the adapter's migration chains (ADR-005,
+  Engineering-Standards §25), and an ORM adds code generation and a schema
+  file that would couple domain models to storage; Kysely's typed builder is
+  sufficient and stays contained.
+- **Raw `pg` everywhere / no query builder** — rejected: hand-written SQL
+  loses type safety and composability while still requiring the driver;
+  containing a query builder is strictly better than containing SQL strings.
+- **Adapter re-exports Kysely for other packages to build queries** — rejected
+  (variant of the first alternative): even when routed through the adapter,
+  letting other packages compose Kysely queries would leak the dialect and
+  bypass the port/repository API that keeps domain code storage-agnostic.
+
+## Consequences
+
+- Positive: one owner for the whole driver/query-builder stack — upgrade,
+  dialect and typing decisions live in `packages/database-postgres` and are
+  exact-pinned single-manifest changes (ADR-026 lane); domain and extension
+  code stays driver-free, so FIT-010/FIT-011 hold; replacing Kysely or the
+  dialect later is a contained change behind the adapter boundary (consistent
+  with the ADR-005 encapsulation).
+- Negative: the adapter's port/repository API must be designed well enough
+  that domain code never needs the query builder — the port API is mandatory,
+  not optional; Kysely conveniences (expression builders, plugin features) are
+  not available to callers outside the adapter; the adapter package grows as
+  the query surface grows.
+- Neutral: Kysely remains a dependency of the adapter package only; contracts
+  between core ports and the adapter are plain TypeScript interfaces, so the
+  containment stays a package-level rule and never becomes a type-level one.
+
+## Operational impact
+
+- `kysely` and `pg` appear in exactly one manifest
+  (`packages/database-postgres/package.json`) and in exactly one package's
+  source; a static scan in `tests/database-postgres-imports.test.mjs`
+  (`database-postgres-imports` CI job) proves it on every PR, including a
+  mutation probe that fails when a driver import is injected elsewhere.
+- Upgrading Kysely or `pg` is a single-manifest change inside the adapter,
+  reviewed under the dependency/upgrade lane (ADR-026); no other package's
+  manifest or code moves.
+- No new runtime services, no schema changes, no deployment or configuration
+  impact: this ADR is documentation of an already-enforced boundary.
+
+## Revisit trigger
+
+- Revisit this ADR when a non-adapter package demonstrably needs
+  query-builder features that cannot be expressed through the adapter/port
+  API, and there is evidence (per the architecture review gates, ADR index
+  §68 of `docs/adr/README.md`) that the boundary costs more than containment
+  saves.
+- Revisit if the platform grows additional data stores or engines (shared with
+  the ADR-005 revisit trigger): a second engine may need its own contained
+  adapter, and the query-builder containment rule would extend per adapter.
+- Revisit if the dependency-boundary enforcement changes — for example if
+  FIT-010/FIT-011 or the `database-postgres-imports` gate are relaxed or
+  re-scoped.

docs/adr/README.md

@@ -0,0 +1,65 @@
+# ADR index (§70)
+
+Repository copy of the ADR index from the wiki ADR-Index page (§70): the
+canonical list of architectural decisions, committed or planned. Every ADR
+committed to `docs/adr/` must record a decision that matches its row in
+section 70; the wiki page remains the canonical index.
+
+| ADR | Decision |
+|---|---|
+| ADR-001 | Modular monolith |
+| ADR-002 | Node.js 24 LTS runtime |
+| ADR-003 | TypeScript 6.0.3 pending TS7.1 ecosystem review |
+| ADR-004 | Fastify 5 HTTP runtime |
+| ADR-005 | PostgreSQL 18 sole canonical DB |
+| ADR-006 | Kysely contained inside DB adapter |
+| ADR-007 | React SSR for public rendering |
+| ADR-008 | React/Vite admin |
+| ADR-009 | Zero-JS public baseline |
+| ADR-010 | Client-island model for optional public interactivity |
+| ADR-011 | JSON Schema + TypeBox + Ajv validation |
+| ADR-012 | EPPP Extension API hides framework internals |
+| ADR-013 | Node/Amber is a theme extension |
+| ADR-014 | Blog is a first-party content extension |
+| ADR-015 | Versioned block documents |
+| ADR-016 | Versioned page composition |
+| ADR-017 | Extension-owned migrations/tables |
+| ADR-018 | Docker Compose primary installation |
+| ADR-019 | Opaque DB-backed admin sessions |
+| ADR-020 | Separate anonymous preference identity |
+| ADR-021 | Local media storage through storage port |
+| ADR-022 | PostgreSQL jobs before external broker |
+| ADR-023 | No Redis initially |
+| ADR-024 | No microservices initially |
+| ADR-025 | Trusted build-time executable extensions in v1 |
+| ADR-026 | Exact dependency pinning + controlled upgrade lanes |
+| ADR-027 (v1.1) | `core.markdown` block restores Markdown authoring inside the block model |
+| ADR-028 (v1.1) | Hardened outbound fetch as a core service; extensions never fetch directly |
+| ADR-029 (v1.1) | Embed provider allowlist enforced in renderer and generated CSP |
+| ADR-030 (v1.1) | Native server-side SVG charts and diagrams with an accessibility contract |
+| ADR-031 (v1.1) | Theme renaming replaces trademark references |
+| ADR-032 (v1.1) | Day-one byte budgets; latency targets from measurement |
+
+Every ADR contains: Context, Decision, Alternatives, Consequences, Operational
+impact, Revisit trigger (§46 E01-S01).
+
+## Architectural fitness tests (§71)
+
+- **Add Ledger/Paper:** create `theme-paper` extension → register
+  manifest/tokens/assets → optionally override renderer slots → tests →
+  include in build. Failure = editing Home/Post domain, core DB, auth, or
+  `if (theme === "paper")` in core.
+- **Add Reading:** create `org.eppp.reading` → migrations → public route →
+  admin contribution → Home section → settings → job(s) → content/block
+  contributions. Failure = core learning seam/half-life/bookmark/link-health
+  semantics.
+
+## Architecture review gates (§68)
+
+Gate A (end Sprint 1): publish a real post without core becoming
+blog/Amber-specific. Gate B (end Sprint 3): add a Home feature as an extension
+with no core edits. Gate C (end Sprint 4): a radically different theme runs
+without changing content/business logic. Gate D (end Sprint 5): visitor
+preference persists without coupling to auth or theme storage. Gate E (before
+public SDK): Extension API v1 proven enough to maintain. Gate F (Reading):
+Reading owns its whole domain without `if (readingEnabled)` in core.