@elytracms/studio 0.0.79 → 0.0.81

package/convex/contract-parity.test.ts

@@ -225,7 +225,7 @@ describe('guard capability gates through the real functions (EC-150/EC-240c, Con
     await expect(
       viewer.cms.upsertDocument(PROJECT_ID, { collection: 'post', id: 'x', values: {} }),
     ).rejects.toThrow(/unauthorized/) // content.write denied
-    await expect(viewer.cliTokens.listTokens()).rejects.toThrow(/unauthorized/) // project.administer denied
+    await expect(viewer.users.listUsers(PROJECT_ID)).rejects.toThrow(/unauthorized/) // project.administer denied
 
     // An authenticated NON-member is rejected even on reads …
     await expect(forSubject('user_stranger').cms.listDocuments(PROJECT_ID)).rejects.toThrow(

package/convex/functions.ts

@@ -52,8 +52,18 @@ export const internalMutation = customMutation(
   internalMutationGeneric as MutationBuilder<DataModel, 'internal'>,
   customCtx(triggers.wrapDB),
 )
-/** Server-only reads (e.g. the EC-157 HTTP sync endpoints) — not callable by clients. */
+/**
+ * Server-only reads — not callable by clients. The mirror of `internalMutation`,
+ * kept as the symmetric half of the codegen-replacement builder set and as the
+ * builder a consumer reaches for when adding its own internal query.
+ * EC-481: the engine itself no longer declares one (its only user was the retired
+ * registry-sync snapshot).
+ */
 export const internalQuery = internalQueryGeneric as QueryBuilder<DataModel, 'internal'>
-/** HTTP action builder (EC-252) — used by the package's `http.ts`/`sync.ts`. Not
- * DataModel-bound: an action reaches data only through `ctx.runQuery`/`runMutation`. */
+/**
+ * HTTP action builder (EC-252). Not DataModel-bound: an action reaches data only
+ * through `ctx.runQuery`/`runMutation`.
+ * EC-481: the engine declares no HTTP action of its own any more (`http.ts` only
+ * mounts the consumer's auth routes); this stays for consumer-defined actions.
+ */
 export const httpAction = httpActionGeneric

package/convex/http-routes.test.ts

@@ -0,0 +1,143 @@
+import { describe, expect, it } from 'vitest'
+import { httpRouter } from 'convex/server'
+import type { HttpRouter, PublicHttpAction } from 'convex/server'
+import { defineStudioHttp } from './http'
+
+/**
+ * EC-481 — the studio's HTTP route table, pinned.
+ *
+ * `defineStudioHttp` used to add `GET /api/projects/*` (the EC-157 registry-sync
+ * endpoint). It was Bearer-authenticated, reachable on every deployment, and — after
+ * EC-470 deleted the `builder` CLI — had no client at all. Removing it is only half
+ * the job: the failure mode this file exists to prevent is a future edit quietly
+ * mounting a route again, or re-claiming that very broad prefix. Neither would break
+ * anything, which is exactly why nothing would catch it.
+ *
+ * The `auth` seam is injected (`{ addHttpRoutes }`), so these assertions isolate what
+ * the ENGINE contributes from what Convex Auth contributes — the real question. Every
+ * detector below is paired with a positive control (`AGENTS.md` §1.5): a recorder that
+ * observes nothing is indistinguishable from a router that registers nothing.
+ */
+
+/** An `auth` double that registers nothing — isolates the engine's own contribution. */
+const silentAuth = { addHttpRoutes: () => {} }
+
+/** A stand-in handler; the router only stores it. */
+const handler = (() => {}) as unknown as PublicHttpAction
+
+/** The route table as stable `"<METHOD> <path>"` strings, sorted. */
+function routeTable(http: HttpRouter): string[] {
+  return http
+    .getRoutes()
+    .map(([path, method]) => `${method} ${path}`)
+    .sort()
+}
+
+describe('defineStudioHttp — the engine registers no HTTP routes of its own (EC-481)', () => {
+  it('contributes an EMPTY route table beyond what the injected auth registers', () => {
+    expect(routeTable(defineStudioHttp({ auth: silentAuth }))).toEqual([])
+  })
+
+  it('control: the recorder DOES see routes, so the empty result above is real', () => {
+    const auth = {
+      addHttpRoutes: (http: HttpRouter) => {
+        http.route({ path: '/.well-known/jwks.json', method: 'GET', handler })
+        http.route({ pathPrefix: '/api/auth/callback/', method: 'POST', handler })
+      },
+    }
+    expect(routeTable(defineStudioHttp({ auth }))).toEqual([
+      'GET /.well-known/jwks.json',
+      'POST /api/auth/callback/*',
+    ])
+  })
+
+  it('passes the auth routes through untouched — nothing is added, dropped, or reordered', () => {
+    const registered: string[] = []
+    const auth = {
+      addHttpRoutes: (http: HttpRouter) => {
+        for (const path of ['/.well-known/openid-configuration', '/.well-known/jwks.json']) {
+          http.route({ path, method: 'GET', handler })
+          registered.push(`GET ${path}`)
+        }
+      },
+    }
+    expect(routeTable(defineStudioHttp({ auth }))).toEqual([...registered].sort())
+  })
+})
+
+describe('the /api/projects/ prefix is released (EC-481)', () => {
+  it('routes NOTHING under /api/projects/ — the request falls through to Convex 404', () => {
+    const http = defineStudioHttp({ auth: silentAuth })
+    // `lookup` is exactly what Convex's `runRequest` consults; `null` is the branch
+    // that answers `No HttpAction routed for <path>`.
+    expect(http.lookup('/api/projects/demo/registry-sync/snapshot', 'GET')).toBeNull()
+    expect(http.lookup('/api/projects/', 'GET')).toBeNull()
+    expect(http.lookup('/api/projects/anything-at-all', 'GET')).toBeNull()
+  })
+
+  it('control: the same lookup DOES resolve when something claims the prefix', () => {
+    const auth = {
+      addHttpRoutes: (http: HttpRouter) => {
+        http.route({ pathPrefix: '/api/projects/', method: 'GET', handler })
+      },
+    }
+    const http = defineStudioHttp({ auth })
+    expect(http.lookup('/api/projects/demo/registry-sync/snapshot', 'GET')).not.toBeNull()
+  })
+
+  it('no route the engine mounts may claim a prefix that swallows /api/projects/', () => {
+    const claims = routeTable(defineStudioHttp({ auth: silentAuth })).filter((route) =>
+      route.includes('/api/projects'),
+    )
+    expect(claims).toEqual([])
+  })
+})
+
+describe('auth routes are unaffected by the removal (EC-481)', () => {
+  it('leaves the /api/auth/* prefixes matching exactly as before', () => {
+    // The removed route was `/api/projects/`, which is neither a prefix of nor
+    // prefixed by any auth path — so Convex's longest-prefix-wins ordering cannot
+    // have changed for them. Asserted rather than argued.
+    const auth = {
+      addHttpRoutes: (http: HttpRouter) => {
+        http.route({ pathPrefix: '/api/auth/signin/', method: 'GET', handler })
+        http.route({ pathPrefix: '/api/auth/callback/', method: 'GET', handler })
+      },
+    }
+    const http = defineStudioHttp({ auth })
+    expect(http.lookup('/api/auth/signin/github', 'GET')?.[2]).toBe('/api/auth/signin/*')
+    expect(http.lookup('/api/auth/callback/github', 'GET')?.[2]).toBe('/api/auth/callback/*')
+    // …and the released prefix still resolves to nothing alongside them.
+    expect(http.lookup('/api/projects/demo', 'GET')).toBeNull()
+  })
+})
+
+describe('the registry-sync and CLI-token modules are gone, not merely unrouted (EC-481/EC-485)', () => {
+  // `import.meta.glob` is the module-enumeration pattern this directory already uses
+  // (`contract-parity.test.ts`). A literal `import('./sync')` cannot be used here: TS
+  // fails to *typecheck* a specifier that no longer resolves, so the assertion could
+  // never compile — the glob asks the same question without naming a missing module.
+  const convexModules = Object.keys(import.meta.glob('./*.ts'))
+
+  it('ships no `sync` module — a route can only come back from a handler that exists', () => {
+    expect(convexModules).not.toContain('./sync.ts')
+  })
+
+  it('ships no `cliTokens` module — the whole CLI-token path was retired (EC-485)', () => {
+    // The registry-sync endpoint was its only verifier (EC-481); with that gone the
+    // issuance path was inert and `cliTokens:byHash` was a public, unauthenticated
+    // query with an expired justification. Nothing addresses these functions any
+    // more — `ConvexCliTokenRepository` went with them, in the same change, because
+    // it named them by STRING and a half-rip would typecheck and fail at runtime.
+    expect(convexModules).not.toContain('./cliTokens.ts')
+  })
+
+  it('control: the glob DOES see this directory, so the absences above are real', () => {
+    expect(convexModules).toContain('./http.ts')
+    expect(convexModules).toContain('./users.ts')
+  })
+
+  it('control: `httpRouter()` itself is unchanged — an empty router really is empty', () => {
+    expect(routeTable(httpRouter())).toEqual([])
+  })
+})

package/convex/http.ts

@@ -1,6 +1,5 @@
 import { httpRouter } from 'convex/server'
 import type { HttpRouter } from 'convex/server'
-import { registrySync } from './sync'
 
 /** The slice of the Convex Auth object the studio's HTTP routes need. */
 interface AuthHttpRoutes {
@@ -8,23 +7,34 @@ interface AuthHttpRoutes {
 }
 
 /**
- * EC-252 — the studio's HTTP routes as a factory. `http`/`sync` are pure engine
- * infra, so they ship in the package; only the consumer's `auth` (provider choice)
- * is injected. The consumer's `convex/http.ts` is a two-liner:
+ * EC-252 — the studio's HTTP routes as a factory. Pure engine infra ships in the
+ * package; only the consumer's `auth` (provider choice) is injected. The consumer's
+ * `convex/http.ts` is a two-liner:
  *
  * ```ts
  * import { auth } from './auth'
  * export default defineStudioHttp({ auth })
  * ```
  *
- * Registers Convex Auth's JWT discovery endpoints (`/.well-known/*`, EC-150) plus the
- * EC-157 Bearer-token registry-sync endpoint. Convex routes by exact path or prefix
- * only, so the dynamic `/api/projects/:projectId/registry-sync/snapshot` segment is
- * parsed inside the action (`sync.ts`).
+ * ## The engine registers NO HTTP routes of its own (EC-481)
+ *
+ * Everything on this router comes from Convex Auth's `addHttpRoutes` — the JWT
+ * discovery endpoints (`/.well-known/*`, EC-150) and, only when a consumer supplies
+ * an OAuth provider, `/api/auth/signin/*` + `/api/auth/callback/*`.
+ *
+ * The engine used to add one more: `GET /api/projects/*`, the EC-157 Bearer-token
+ * registry-sync endpoint backing `builder typegen`/`builder check`. EC-470 deleted
+ * that CLI and with it the endpoint's only client; the handler had in any case
+ * answered with config-owned placeholders since EC-287 retired the project graph
+ * (`project: null`, `collections: []`). EC-481 removed the route and its handler
+ * together rather than leave a Bearer-authenticated surface serving stub data on
+ * every deployment. `http-routes.test.ts` pins that shut.
+ *
+ * A future engine-owned HTTP surface is fine — but it needs a real client and a
+ * narrower prefix than `/api/projects/`.
  */
 export function defineStudioHttp({ auth }: { auth: AuthHttpRoutes }): HttpRouter {
   const http = httpRouter()
   auth.addHttpRoutes(http)
-  http.route({ pathPrefix: '/api/projects/', method: 'GET', handler: registrySync })
   return http
 }

package/convex/schema.ts

@@ -109,25 +109,6 @@ export default defineSchema({
     at: v.string(),
   }).index('by_time', ['at']),
 
-  /**
-   * Revocable CLI sync tokens (EC-150, consumed by the EC-147 push CLI).
-   * Only the SHA-256 hash of a token is ever stored; revoked tokens keep
-   * their row (with `revokedAt`) for auditability.
-   *
-   * Single-tenant (EC-182/EC-183): a deployment hosts one project, so a token
-   * carries no per-project scope — `projectId` is gone (it was `optional`
-   * through EC-182; this drops the field now that both deployments are migrated).
-   */
-  cliTokens: defineTable({
-    tokenId: v.string(),
-    label: v.string(),
-    tokenHash: v.string(),
-    createdAt: v.string(),
-    revokedAt: v.optional(v.string()),
-  })
-    .index('by_token', ['tokenId'])
-    .index('by_hash', ['tokenHash']),
-
   /**
    * CMS documents (EC-043). The stored `document` is the continuous working
    * **draft**; `publishedVersion` pins which `documentVersions` row is live

package/convex/users.ts

@@ -42,7 +42,7 @@ export const me = query({
  * onto `@elytracms/core/persistence` `UserRecord`s.
  *
  * Admin-only, server-side: the list exposes every member's email + role — an
- * administration concern (like `cliTokens:list`), not a content read. UI gating
+ * administration concern (like `invites:list`), not a content read. UI gating
  * alone is never trusted.
  */
 

package/dist/components/app-views/default-modules.d.ts

@@ -1,7 +1,7 @@
 import type { ReactNode } from 'react';
 import type { LucideIcon } from 'lucide-react';
 import type { CmsDocument, CollectionDef, CollectionFieldOverride, CollectionFormMeta, LocaleConfig } from '@elytracms/core/cms-core';
-import type { Project, SectionId } from '@elytracms/core/studio-core';
+import type { CustomizationIssue, Project, SectionId } from '@elytracms/core/studio-core';
 import type { InstantiatedKit } from '@elytracms/core/starter-kits';
 import type { HydratedCms } from '@elytracms/studio/lib/operations';
 import { type AppViewContext, type AppViewDeepLink, type AppViewModule, type NavPermission, type SidebarViewNode } from './module.js';
@@ -28,6 +28,11 @@ export interface CmsViewConfig {
      * Scope the rail auto-expansion (EC-293) to these collection ids, in order. The
      * parent expands into one focused-lens child per id; the parent index shows the
      * same subset. Omitted → every collection. Ignored for a single-collection lens.
+     *
+     * A ONE-ITEM array is legal and degrades to a working (if redundant) parent+child
+     * pair — the parent takes the `cms-group:<id>` id so it cannot collide with its own
+     * child (EC-468). For a single collection with no group heading, prefer the
+     * {@link CmsViewConfig.collection} leaf form.
      */
     collections?: readonly string[];
     /** Single-collection lens: a LEAF rail item that opens straight into this collection. */
@@ -103,12 +108,46 @@ export interface CustomViewConfig {
     /** OPTIONAL, default-open nav-permission predicate (EC-240 / AD-18). See {@link BuiltinViewConfig.visible}. */
     visible?: NavPermission;
 }
+/**
+ * Derive a stable, deterministic id from the CMS focus (overridable via `config.id`).
+ *
+ * The id is the route segment, the rail's active-state key AND the override key
+ * (EC-311), so it must be injective: two focuses deriving one id means
+ * `resolveOverrides` drops the later view. The derived shapes:
+ *
+ * | focus                        | id                        |
+ * | ---------------------------- | ------------------------- |
+ * | none                         | `cms`                     |
+ * | `collection: 'page'` (leaf)  | `cms:page`                |
+ * | `collections: ['a','b']`     | `cms:a-b`                 |
+ * | `collections: ['page']`      | `cms-group:page`          |
+ *
+ * EC-468 — why the one-item group is its own namespace: `cms:${join(L)}` of a
+ * single-element list IS that element, so the auto-generated PARENT took the very id
+ * its own auto-expanded child derives (`cmsCollectionLeaf` → `cmsView({ collection })`).
+ * Both landed in the one flat override list `resolveSidebar` feeds `resolveOverrides`,
+ * so the child was dropped with a `duplicate-override-id` error and the parent rendered
+ * childless — a forced collision no config could avoid. Nothing else changes: the leaf
+ * and the multi-collection join keep their exact ids (consumer rails route on them).
+ *
+ * EC-477 — `-` is a SEPARATOR here, and a collection id may legally contain one, so a
+ * collection literally named `a-b` derives the same `cms:a-b` as a `['a','b']` group.
+ * That ambiguity is NOT closed by constraining collection ids (a permanent, repo-wide
+ * naming ban to fix a two-config coincidence, when hyphenated ids are ordinary — see
+ * the task's Done); it is DETECTED where both facts are known, by
+ * {@link checkSidebarIdKeyspace}, which raises a `derived-id-collision` the moment a
+ * group's join equals a real collection id. The escape hatch is unchanged: an explicit
+ * `nav.cms({ id })` always wins, and the derivation below is untouched — consumer rails
+ * route on these ids.
+ */
+export declare function cmsViewId(config: CmsViewConfig): string;
 /**
  * Build a CMS view — the default `cms` view, or a focused instance. Every instance
  * shares one surface ({@link CmsScreen}); `collections` narrows the sidebar + index
  * to a subset, `collection` is a single-collection lens that opens straight into
  * that collection's list. The id is derived from the focus (deterministic, stable
- * across rail reorders) unless `id` is given — so two focused views never collide.
+ * across rail reorders) unless `id` is given — see {@link cmsViewId} for the derived
+ * shapes and the one keyspace ambiguity that survives.
  */
 export declare function cmsView(config?: CmsViewConfig): AppViewModule;
 /** The components registry browser view. */
@@ -155,7 +194,15 @@ export declare function extensionsView(config?: BuiltinViewConfig): AppViewModul
 export declare function settingsView(config?: BuiltinViewConfig): AppViewModule;
 /** The legacy `builder` redirect — a hidden, routable view (so `/builder?page=` still lands). */
 export declare function builderView(): AppViewModule;
-/** Build a fully custom view (the `nav.view(...)` escape hatch). */
+/**
+ * Build a fully custom view (the `nav.view(...)` escape hatch).
+ *
+ * With no `id` the id is a SLUG of the label, and that slug carries a
+ * {@link DerivedViewId} marker (EC-476): a label is a display string a developer picks
+ * freely, so `label: 'CMS'` deriving `cms` is a coincidence, not a request to replace
+ * the built-in CMS surface. {@link checkSidebarIdKeyspace} refuses the takeover and
+ * says so; an explicit `id` carries no marker and keeps the documented replacement.
+ */
 export declare function customView(config: CustomViewConfig): AppViewModule;
 /**
  * The studio's built-in views in canonical rail order (components · CMS · routes ·
@@ -165,11 +212,57 @@ export declare function customView(config: CustomViewConfig): AppViewModule;
  * when a consumer's rail omits one.
  */
 export declare const DEFAULT_VIEWS: readonly AppViewModule[];
+/**
+ * Every id the engine already owns — the replacement targets of the sidebar seam,
+ * INCLUDING the hidden `builder` redirect (it is in the keyspace even though the stock
+ * rail does not list it, so a derived id can swallow it just the same).
+ */
+export declare const BUILTIN_VIEW_IDS: ReadonlySet<string>;
+/** The outcome of the keyspace check: the entries that may still act as overrides, plus the findings. */
+export interface SidebarIdKeyspace {
+    /**
+     * The views to resolve as overrides — an ACCIDENTAL built-in takeover removed, so the
+     * engine keeps its own block (the EC-236 contract for a rejected entry). Everything
+     * else passes through untouched, including the merely-ambiguous EC-477 case.
+     */
+    views: AppViewModule[];
+    /** What was found — visible at the rail foot, never silent. */
+    issues: CustomizationIssue[];
+}
+/**
+ * EC-476/477 — guard the sidebar id keyspace against ids that were DERIVED rather than
+ * declared, and landed somewhere that already means something.
+ *
+ * The seam's replacement rule is id equality (`resolveOverrides`: an entry whose id is a
+ * default's id replaces it). That is exactly right for an id the developer TYPED, and
+ * exactly wrong for one a builder computed — and the generic core cannot tell them
+ * apart, because by the time an entry reaches it, an id is just a string. So the rule
+ * lives HERE, next to the derivations that produce it ({@link slugify},
+ * {@link cmsViewId}) and next to {@link DEFAULT_VIEWS}, the set it has to protect.
+ *
+ * Two derived shapes, two different remedies — because the cost of being wrong differs:
+ *
+ * - **A slugged LABEL landing on a built-in id (EC-476) is REJECTED** (`error`). Losing
+ *   a whole built-in surface — the CMS, Assets, the users roster — to a coincidence of
+ *   spelling is far worse than one custom view not appearing, and the developer's fix is
+ *   a one-line explicit `id`. The built-in is kept, so nothing disappears.
+ * - **A collection JOIN equal to a real collection id (EC-477) is KEPT** (`warning`).
+ *   Nothing here is a takeover: the group's id is legitimate, it is merely no longer
+ *   unique to it, so dropping the view would destroy a rail item the developer
+ *   explicitly declared in order to report a naming clash. Reporting is the whole fix.
+ *
+ * Pure and deterministic — the house "extract the core, test the core" shape.
+ * `builtinIds` and `collections` are parameters so the rule is testable against a
+ * synthetic keyspace, not just the live one.
+ */
+export declare function checkSidebarIdKeyspace(views: readonly AppViewModule[], collections?: readonly CollectionDef[], builtinIds?: ReadonlySet<string>): SidebarIdKeyspace;
 export declare const nav: {
     /**
      * The CMS view. `nav.cms()` / `nav.cms({ collections })` is a PARENT that nests its
      * collections in the rail (each a focused `cms:<id>` lens); `nav.cms({ collection })`
      * is a single-collection LEAF; `nav.cms({ children })` supplies explicit children.
+     * A one-item `collections` group is a parent whose id is `cms-group:<id>`, distinct
+     * from its single child by construction (EC-468 — see {@link cmsViewId}).
      */
     readonly cms: (config?: CmsViewConfig) => SidebarViewNode;
     /** The component registry browser. */
@@ -193,46 +286,44 @@ export declare const nav: {
     readonly separator: () => import("./module.js").SidebarSeparatorNode;
 };
 /**
- * The CMS schema source for a project mount (bug fix, playground-collections):
- * a hydrated session wins (Convex), then a kit's imported schema (EC-119), then —
- * in playground mode only — the active project's config-declared collections
- * (AD-11, `resolveDeploymentCollections`). Without this last fallback, a non-kit
- * playground project has no hydrated session (`null`, by design — see
- * `project-session.tsx`) and no kit, so `CmsProvider` fell through to the core's
- * hardcoded `sampleFilterableCollections` fixture instead of the project's own
- * on-disk schema. Convex mode's first-run `null` is untouched — it still seeds
- * from the fixture there, as before. `playground` defaults to the live
- * {@link isPlaygroundMode} but is overridable so this stays unit testable
- * without stubbing the env (same seam as `resolveBackendConfig`).
- */
-export declare function resolveCmsInitialCollections(cms: HydratedCms | null, kit: InstantiatedKit | undefined, playground?: boolean): CollectionDef[] | undefined;
-/**
- * The CMS documents source for a project mount (EC-424) — the document-side
- * twin of {@link resolveCmsInitialCollections}, same ladder: a hydrated session
- * wins (Convex), then a kit's imported documents, then — in playground mode
- * only, and only when a config project actually resolved collections — the
- * engine's own `sampleDocuments` fixture RECONCILED against them.
+ * The CMS schema source for a project mount: a hydrated session wins (Convex),
+ * then a kit's imported schema (EC-119), then the active project's
+ * config-declared collections (AD-11, `resolveDeploymentCollections`).
+ *
+ * EC-479 — every rung is the PROJECT's own schema and there is no rung after
+ * them. The config rung used to be gated on playground mode, because outside it
+ * the `undefined` return let `CmsProvider` fall through to `cms-core`'s
+ * `sampleFilterableCollections` fixture — the engine's demo schema, shown as the
+ * project's, offering `filterable` fields the project's real backend would
+ * reject. With that fallback retired the gate has nothing left to protect: the
+ * Convex adapter is itself constructed with `resolveDeploymentCollections()`
+ * (`lib/persistence/index.ts`), so config collections are what connected mode
+ * serves too. Dropping it also DISSOLVES the EC-467 two-source divergence — the
+ * section rail reads `resolveDeploymentCollections()` directly, and now so does
+ * the store's last rung, so the two can no longer disagree.
+ */
+export declare function resolveCmsInitialCollections(cms: HydratedCms | null, kit: InstantiatedKit | undefined): CollectionDef[] | undefined;
+/**
+ * The CMS documents source for a project mount — the document-side twin of
+ * {@link resolveCmsInitialCollections}: a hydrated session wins (Convex), then a
+ * kit's imported documents, then **nothing**.
  *
- * Without this, a config project whose OWN schema diverges from the shared
- * fixture's localization (e.g. this repo's demo declares `post.slug` localized,
- * EC-315, while the engine's `postCollection` fixture deliberately does not)
- * left `CmsProvider` falling straight through to the un-reconciled
- * `sampleDocuments` default — the CMS surfaces' `initialCollections` already
- * reflected the config schema (via the fallback above), but `initialDocuments`
- * did not, so every seeded post showed EC-390's shape-aware validation's
- * `plain-value` warning + `missing-localized-value` error, standing noise a
- * project never actually wrote.
+ * EC-479 — the third rung used to be the engine's own `sampleDocuments` fixture,
+ * reconciled against the project's schema (EC-424). Reconciling it was already an
+ * admission that the content was foreign: EC-424 existed only because the demo
+ * declares `post.slug` localized while the shared fixture stores it plain, so the
+ * seeded posts carried standing validation noise no project had written. The
+ * honest fix is not a better reconciliation but no foreign content at all — a
+ * studio whose config did not arrive now shows an empty CMS and a visible issue
+ * at the rail, not six documents about Ada Lovelace wearing the project's schema.
  *
- * This is the STATIC-baseline twin of `reconcileSeedDocumentLocalization`
- * (`@elytracms/core/persistence`, wired into the seeded persistence adapter for
- * Convex-mode/delivery reads): no adapter round-trip, so the EC-138/EC-320
- * synchronous-first-render contract (`project-session.tsx`: "CMS surfaces keep
- * their fixture baseline") is untouched. `collections` defaults to the SAME
- * resolution `resolveCmsInitialCollections` returns, so the two stay in lockstep
- * by construction; only reconciles when that resolved to a non-empty config
- * schema (env-only playground, with nothing config-declared, is unaffected).
+ * The playground keeps its world through the ordinary path, not through here: its
+ * seeded in-memory adapter IS a persisted backend behind the operations seam
+ * (AD-17), so `CmsSessionGate` hydrates it and the first rung answers. What that
+ * adapter seeds is `persistence/seed.ts`'s business — EC-475 (project-defined seed
+ * content) owns it.
  */
-export declare function resolveCmsInitialDocuments(cms: HydratedCms | null, kit: InstantiatedKit | undefined, collections?: CollectionDef[] | undefined): CmsDocument[] | undefined;
+export declare function resolveCmsInitialDocuments(cms: HydratedCms | null, kit: InstantiatedKit | undefined): CmsDocument[] | undefined;
 /**
  * The CMS locale config for a project mount (EC-357 finding #3). Locales are
  * structure and structure is code: when the active `elytra.config.ts` project
@@ -240,10 +331,16 @@ export declare function resolveCmsInitialDocuments(cms: HydratedCms | null, kit:
  * wiring only applied the project's locale settings on a HYDRATED session, so a
  * playground boot — or a connected FIRST RUN with nothing persisted yet — fell
  * back to a kit's locales or the core's sample `en/de` fixture and the switcher
- * showed `EN·/DE` against a `locales: ['de']` config. Without a config project
- * (env-only wiring) the previous ladder is unchanged: hydrated project settings,
- * then the kit's locales, then the sample fixture (via `CmsProvider`'s default).
+ * showed `EN·/DE` against a `locales: ['de']` config.
+ *
+ * EC-479/EC-483 — the ladder is now TOTAL, and every rung is the project's own:
+ * config-declared locales, then (hydrated) its persisted settings, then a kit's,
+ * then its settings regardless. A `Project` only ever exists for a config-declared
+ * project (`studio-context.tsx`: `configProjects()`), so `project.settings` is
+ * config-derived too — which is what lets the CMS session require a locale instead
+ * of borrowing the engine's `en/de` fixture. The default locale is the literal
+ * storage key for every localized value, so a guessed one is a data migration.
  * `configLocales` is a parameter purely so the ladder is unit-testable (same seam
  * pattern as {@link resolveCmsInitialCollections}).
  */
-export declare function resolveCmsInitialLocaleConfig(cms: HydratedCms | null, kit: InstantiatedKit | undefined, project: Project, configLocales?: LocaleConfig | undefined): LocaleConfig | undefined;
+export declare function resolveCmsInitialLocaleConfig(cms: HydratedCms | null, kit: InstantiatedKit | undefined, project: Project, configLocales?: LocaleConfig | undefined): LocaleConfig;