@lunora/platform 1.0.0-alpha.6 → 1.0.0-alpha.61

package/dist/index.d.mts

@@ -1,4 +1,4 @@
-export { type D as DirectShardDirectory, type S as ScheduleOptions, type a as ScheduledJob, type b as ScheduledJobStatus, type c as SchedulerHost, type d as ShardAlarms, type e as ShardAsyncSqlExec, type f as ShardDirectory, type g as ShardHost, type h as ShardJurisdiction, type i as ShardKvListOptions, type j as ShardKvStore, type k as ShardSqlCursor, type l as ShardSqlExec, type m as ShardStub, type n as SocketHandle, type o as SocketHost, type p as SqlRow, type T as TwoStepShardDirectory, r as resolveShard } from "./packem_shared/socket-host.d-DCVFvmXn.mjs";
+export { type D as DirectShardDirectory, L as LUNORA_ROLE_PREFIX, type S as ScheduleOptions, type a as ScheduledJob, type b as ScheduledJobStatus, type c as SchedulerHost, type d as ShardAlarms, type e as ShardDirectory, type f as ShardHost, type g as ShardJurisdiction, type h as ShardKvListOptions, type i as ShardKvStore, type j as ShardRegionHint, type k as ShardSqlCursor, type l as ShardSqlExec, type m as ShardStub, type n as SocketHandle, type o as SocketHost, type p as SqlRow, type T as TwoStepShardDirectory, r as resolveShard } from "./packem_shared/socket-host.d-VUTw8RC_.mjs";
 /**
  * The subset of the Cloudflare `ExecutionContext` the Lunora worker entry and
  * the framework mount seams rely on — `waitUntil` for fire-and-forget work that
@@ -22,15 +22,70 @@ export { type D as DirectShardDirectory, type S as ScheduleOptions, type a as Sc
  * fall back to {@link NOOP_EXECUTION_CONTEXT}.
  */
 interface ExecutionContextLike {
+  /**
+   * Present only when Cloudflare Access authenticated the request against a
+   * policy attached to the **Worker** (rather than to a hostname). `undefined`
+   * on every unauthenticated request, so its presence is itself the "Access
+   * authorized this caller" signal — see {@link AccessContextLike}.
+   */
+  access?: AccessContextLike;
   cache?: {
     purge: (options: {
       purgeEverything?: boolean;
       tags?: string[];
     }) => Promise<unknown>;
   };
+  /**
+   * Loopback bindings to the Worker's own top-level exports — where Cloudflare
+   * exposes the workflows and agents declared in wrangler `exports`, keyed by
+   * class name (see `shared/workflow-binding.ts`).
+   */
+  exports?: unknown;
   passThroughOnException?: () => void;
   waitUntil?: (promise: Promise<unknown>) => void;
 }
+/**
+ * The identity Cloudflare Access attaches to a Worker-protected request.
+ *
+ * Shape follows the Access application-token payload: `sub` is the stable per-user
+ * id, `email` the verified address, `common_name` the service-token name (machine
+ * callers, whose `sub` is empty), and `exp` the credential expiry in epoch
+ * **seconds**. Group membership is whatever the Access policy emits — a list of
+ * names, or of `{ id, name }` objects — hence `unknown`; normalize before use.
+ *
+ * Cloudflare may add further fields, so the index signature keeps them rather
+ * than dropping them: this is a view of a payload we do not own.
+ */
+interface AccessIdentityLike {
+  [claim: string]: unknown;
+  /** Service-token name. Present for non-interactive (machine) callers instead of `email`. */
+  common_name?: string;
+  /** Verified user email. Present for interactive (SSO) callers. */
+  email?: string;
+  /** Credential expiry, epoch **seconds**. */
+  exp?: number;
+  /** IdP group membership — names or `{ id, name }` objects, depending on the policy. */
+  groups?: unknown;
+  /** Display name from the identity provider, when it emits one. */
+  name?: string;
+  /** Stable per-user id, and what consumers key a user on. Empty for service tokens. */
+  sub?: string;
+  /** Cloudflare's per-user UUID. Carried through, but deliberately not used as an id — only this path emits it, so keying on it would not match the JWT path. */
+  user_uuid?: string;
+}
+/**
+ * The `ctx.access` facade Cloudflare exposes on a Worker protected by Access.
+ *
+ * Reading the identity from here is preferable to verifying the
+ * `Cf-Access-Jwt-Assertion` header: the platform has already authenticated the
+ * caller, so there is no JWKS fetch, no audience check to get wrong, and nothing
+ * a request can forge — the field simply does not exist unless Access authorized
+ * the call. The header path remains the fallback for hostname-scoped Access
+ * applications, which do not populate this.
+ */
+interface AccessContextLike {
+  getIdentity: () => AccessIdentityLike | null | undefined | Promise<AccessIdentityLike | null | undefined>;
+}
 /**
  * No-op `ExecutionContext` used when the host runtime didn't supply one (a
  * non-Cloudflare preview, or a unit test), so the worker's `fetch` always
@@ -65,6 +120,35 @@ interface QueueMessageLike<Body = unknown> {
   }) => void;
   readonly timestamp: Date;
 }
+/** Options accepted by {@link HttpCacheLike.match} and {@link HttpCacheLike.delete}. */
+interface HttpCacheQueryOptions {
+  /** Match a non-`GET` request against a stored `GET` entry. */
+  ignoreMethod?: boolean;
+}
+/**
+ * Minimal projection of one Web Cache API cache — the store a host puts in front
+ * of the app, reached on Cloudflare as `caches.default` (the colo cache).
+ *
+ * Only the three calls Lunora makes are declared, so a host that has a cache but
+ * not the whole `Cache` interface still satisfies it, and a unit test can pass a
+ * plain object double. This is a **host** primitive, not a binding: it is reached
+ * through a runtime global rather than `env`, and a target without one leaves it
+ * `undefined` rather than shipping a fake — see `httpCache` in
+ * `PlatformCapabilities`.
+ *
+ * The stored entry is keyed by the request, so a caller that needs `Vary`
+ * semantics must fold the varying header values into the key itself: Cloudflare's
+ * cache honours `Vary` for `Accept-Encoding` only, and a projection cannot make
+ * that portable.
+ */
+interface HttpCacheLike {
+  /** Evict the entry stored under `request`. Resolves `true` when something was removed. */
+  delete: (request: Request | string, options?: HttpCacheQueryOptions) => Promise<boolean>;
+  /** The stored response for `request`, or `undefined` on a miss. */
+  match: (request: Request | string, options?: HttpCacheQueryOptions) => Promise<Response | undefined>;
+  /** Store `response` under `request`. Rejects for a `206`, a `Vary: *`, or a `Set-Cookie`-bearing response. */
+  put: (request: Request | string, response: Response) => Promise<void>;
+}
 /** A single vector match. */
 interface VectorMatchLike {
   id: string;
@@ -85,6 +169,7 @@ interface AnalyticsEngineDataPointLike {
 }
 interface D1PreparedStatementLike {
   all: <T = unknown>() => Promise<{
+    meta?: Record<string, unknown>;
     results: T[];
     success: boolean;
   }>;
@@ -214,30 +299,53 @@ type KvNamespaceListResult<Metadata = unknown> = {
   list_complete: true;
 };
 /**
- * Minimal structural projection of `VectorizeIndex` so unit tests can pass a
+ * Minimal structural projection of `Vectorize` so unit tests can pass a
  * plain-object double and the real Cloudflare binding satisfies the same shape.
  * Mirrors the surface documented at
  * https://developers.cloudflare.com/vectorize/reference/client-api/.
+ *
+ * **Method** syntax, not arrow properties: `ReadonlyArray` is the correct (wider)
+ * parameter type, but an arrow property makes parameters strictly contravariant
+ * under `strictFunctionTypes`, and Cloudflare declares `deleteByIds(ids: string[])`
+ * — so the real binding did not satisfy this interface at all. Methods are checked
+ * bivariantly, which admits both it and a `readonly`-clean double.
+ * `binding-assignability.test-d.ts` in `@lunora/bindings` pins that against the
+ * published types. `this: void` keeps the members usable as bare references, which
+ * is what every `expect(double.query)` assertion in those tests does.
  */
 interface VectorizeIndexLike {
-  deleteByIds: (ids: ReadonlyArray<string>) => Promise<VectorizeDeleteMutation>;
-  describe?: () => Promise<VectorizeIndexDetails>;
-  getByIds: (ids: ReadonlyArray<string>) => Promise<ReadonlyArray<VectorizeVector>>;
-  insert: (vectors: ReadonlyArray<VectorizeVector>) => Promise<VectorizeUpsertMutation>;
-  query: (vector: ReadonlyArray<number>, options?: VectorizeQueryOptions) => Promise<VectorizeMatches>;
-  upsert: (vectors: ReadonlyArray<VectorizeVector>) => Promise<VectorizeUpsertMutation>;
+  deleteByIds(this: void, ids: ReadonlyArray<string>): Promise<VectorizeDeleteMutation>;
+  describe?(this: void): Promise<VectorizeIndexDetails>;
+  getByIds(this: void, ids: ReadonlyArray<string>): Promise<ReadonlyArray<VectorizeVector>>;
+  insert(this: void, vectors: ReadonlyArray<VectorizeVector>): Promise<VectorizeUpsertMutation>;
+  query(this: void, vector: VectorValues, options?: VectorizeQueryOptions): Promise<VectorizeMatches>;
+  upsert(this: void, vectors: ReadonlyArray<VectorizeVector>): Promise<VectorizeUpsertMutation>;
 }
 type VectorMetric = "cosine" | "euclidean" | "dot-product";
+/**
+ * An embedding, as either a plain array or one of the typed arrays Vectorize
+ * accepts. The typed-array arms are not a convenience: Cloudflare's own
+ * `VectorizeVector.values` is `VectorFloatArray | number[]`, so a projection
+ * limited to `ReadonlyArray<number>` excluded every vector the real binding
+ * returns. Read one with `Array.from(...)` rather than an array method.
+ */
+type VectorValues = Float32Array | Float64Array | ReadonlyArray<number>;
 interface VectorizeVector {
   id: string;
   metadata?: Record<string, unknown>;
   namespace?: string;
-  values: ReadonlyArray<number>;
+  values: VectorValues;
 }
+/**
+ * Query options, kept a superset of Cloudflare's own `VectorizeQueryOptions` so
+ * the real binding satisfies {@link VectorizeIndexLike}. `returnMetadata` carries
+ * the legacy `boolean` arm for that reason - pass one of the three levels; the
+ * boolean is what Cloudflare still accepts, not what callers should write.
+ */
 interface VectorizeQueryOptions {
   filter?: Record<string, unknown>;
   namespace?: string;
-  returnMetadata?: "none" | "indexed" | "all";
+  returnMetadata?: "none" | "indexed" | "all" | boolean;
   returnValues?: boolean;
   topK?: number;
 }
@@ -246,7 +354,7 @@ interface VectorizeMatch {
   metadata?: Record<string, unknown>;
   namespace?: string;
   score: number;
-  values?: ReadonlyArray<number>;
+  values?: VectorValues;
 }
 interface VectorizeMatches {
   count: number;
@@ -259,11 +367,24 @@ interface VectorizeDeleteMutation {
   count?: number;
   mutationId: string;
 }
+/**
+ * What `describe()` reports. Both spellings of the row count are optional because
+ * Cloudflare renamed it between API generations — the beta `VectorizeIndex`
+ * returns `vectorsCount`, the current `Vectorize` returns `vectorCount` — and a
+ * projection that required either one excluded a real binding. Read them as
+ * `vectorCount ?? vectorsCount`.
+ *
+ * `processedUpTo*` are typed loosely for the same reason: documented as ISO 8601
+ * strings, typed as `number` in `@cloudflare/workers-types`.
+ */
 interface VectorizeIndexDetails {
   dimensions: number;
-  processedUpToDatetime?: string;
-  processedUpToMutation?: string;
-  vectorsCount: number;
+  processedUpToDatetime?: number | string;
+  processedUpToMutation?: number | string;
+  /** The current `Vectorize.describe()` spelling. */
+  vectorCount?: number;
+  /** The beta `VectorizeIndex.describe()` spelling. */
+  vectorsCount?: number;
 }
 /**
  * A single-range read against R2: an `{ offset, length }` window (at least one
@@ -296,7 +417,8 @@ interface R2BucketLike {
       contentType?: string;
     };
   }) => Promise<R2MultipartUploadLike>;
-  delete: (key: string) => Promise<void>;
+  /** Delete one key, or up to 1000 in one call (R2's bulk delete). Absent keys are a no-op. */
+  delete: (keys: string | string[]) => Promise<void>;
   get: (key: string, options?: {
     range?: R2RangeLike;
   }) => Promise<R2ObjectBodyLike | null>;
@@ -310,22 +432,53 @@ interface R2BucketLike {
   list: (options?: {
     cursor?: string;
     delimiter?: string;
+    include?: ("customMetadata" | "httpMetadata")[];
     limit?: number;
     prefix?: string;
+    startAfter?: string;
   }) => Promise<{
     cursor?: string;
+    delimitedPrefixes?: string[];
     objects: R2ObjectLike[];
     truncated?: boolean;
   }>;
-  put: (key: string, body: ReadableStream | ArrayBuffer | Blob | string | null, options?: {
-    customMetadata?: Record<string, string>;
-    httpMetadata?: {
-      contentType?: string;
-    };
-  }) => Promise<R2ObjectLike>;
+  put: {
+    (key: string, body: R2PutBodyLike, options: R2PutOptionsLike & {
+      onlyIf: R2ConditionalLike;
+    }): Promise<R2ObjectLike | null>;
+    (key: string, body: R2PutBodyLike, options?: R2PutOptionsLike): Promise<R2ObjectLike>;
+  };
   /** Resume an in-progress multipart upload by id (R2 `resumeMultipartUpload`). Optional; see {@link Storage.resumeMultipartUpload}. */
   resumeMultipartUpload?: (key: string, uploadId: string) => R2MultipartUploadLike;
 }
+/**
+ * What `R2BucketLike.put` stores bytes from. `ArrayBufferView` is in the real
+ * `R2Bucket.put` signature and in `uploadPart`; a `Uint8Array` is the most
+ * natural thing to hand a byte store.
+ */
+type R2PutBodyLike = ReadableStream | ArrayBuffer | ArrayBufferView | Blob | string | null;
+/**
+ * The put options `R2BucketLike.put` accepts. `sha256` is in the real
+ * `R2Bucket.put` signature and `@lunora/storage`'s `upload` has always passed
+ * it: R2 verifies the digest on write and records it, and a recorded digest is
+ * the only reason `list()`/`head()` can report `checksums.sha256` at all.
+ */
+interface R2PutOptionsLike {
+  customMetadata?: Record<string, string>;
+  httpMetadata?: {
+    contentType?: string;
+  };
+  sha256?: ArrayBuffer | string;
+}
+/**
+ * A put precondition (R2's `R2Conditional`, the etag half). `etagMatches` is
+ * `If-Match`; `etagDoesNotMatch: "*"` is `If-None-Match: *`, "only if the key
+ * does not exist yet".
+ */
+interface R2ConditionalLike {
+  etagDoesNotMatch?: string;
+  etagMatches?: string;
+}
 /** One uploaded multipart part — returned by `uploadPart`, required to `complete`. Mirrors R2's `R2UploadedPart`. */
 interface R2UploadedPartLike {
   etag: string;
@@ -455,9 +608,112 @@ interface QueueRetryOptions {
  * Lunora features a target platform supports natively, emulates, or cannot
  * support at all.
  *
- * Codegen consumes this matrix to omit unsupported `ctx.*` surfaces from
- * emitted types and to emit diagnostics for features that need emulation.
- * Docs and Studio also read it to show parity per target.
+ * # Who reads it
+ *
+ * **`@lunora/codegen` is the only gating consumer.** `gateAgainstMatrix`
+ * (`packages/codegen/src/platform-target.ts`) intersects an app's detected
+ * feature usage with the target's matrix and diagnoses exactly two states:
+ * `unsupported` (`platform_unsupported_feature`) and a key missing from the
+ * matrix altogether (`platform_undeclared_feature`, the fail-closed arm).
+ * `native` and `emulated` are emitted identically, with no diagnostic between
+ * them — that distinction exists for honest parity reporting, not for codegen.
+ *
+ * The generated worker also reports its target's levels to `@lunora/studio`
+ * (the `platform` field of `__lunora_admin__:studioFeatures`), which marks a
+ * page whose feature the target rates `unsupported` as unavailable. Studio
+ * still imports nothing from here — the worker tells it. The per-feature table
+ * in `packages/platform-node/docs/index.mdx` is a hand-written copy held
+ * verbatim by `pnpm run lint:node-capabilities-docs`: change a rating or a note
+ * here first, then that table, or the check fails.
+ *
+ * # Gate-bearing keys
+ *
+ * A rating only gates something if `@lunora/codegen` reads it — either through a
+ * usage key mapped onto the feature (`CAPABILITY_ROWS` + `CAPABILITY_TO_FEATURE`,
+ * for an app-imported `ctx.*` module) or through a `PlatformSignals` entry (for
+ * something the app declares in its schema or a declaration file). The
+ * gate-bearing keys are:
+ *
+ * `agents`, `ai`, `aiSearch`, `analytics`, `analyticsSql`, `artifacts`, `browser`, `commitOrderedTables`,
+ * `containerEgressPolicy`, `containerRuntimeScheduling`, `containerSandboxTools`, `containers`,
+ * `cronTriggers`, `crossShardFanout`,
+ * `durableStreams`, `globalTables`, `hyperdrive`, `images`, `keyValueStore`,
+ * `mail`, `objectStorage`, `pipelines`, `queues`, `relationGraph`,
+ * `scheduler`, `secrets`, `services`, `topics`, `vectorStore`, `workerLoaders`, `workflowRollback`,
+ * `workflowSchedules`, `workflows`.
+ *
+ * Every other key here — `authJurisdictionMove`, `conditionalWrites`, `edgeRequestMetadata`, `hostTraceFusion`, `httpCache`,
+ * `identityProxy`, `localSql`, `logArchive`, `memoryTables`,
+ * `objectColumnPaths`, `objectStorageBackups`, `objectStorageCdcArchive`, `pointInTimeRecovery`, `queryExplain`,
+ * `serverReactors`,
+ * `shardAlarms`, `shardedState`, `shardPlacement`, `shardReadReplicas`,
+ * `websocketHibernation` — is
+ * **advisory**: rating one `unsupported` omits no surface and warns nobody. It
+ * still records parity honestly, which is its job; it is not a gate.
+ *
+ * # Advisory is not one thing — there are two reasons, and only one is final
+ *
+ * `conditionalWrites` is advisory by nature as well: it is one `ctx.db` method
+ * (`patchIf`), and every backend that runs it decides in the database's own
+ * statement, so no target needs codegen to withhold it. A backend without one
+ * refuses the call at first use instead of reading and then writing.
+ * `authJurisdictionMove` is advisory by nature too: an app never declares it.
+ * Codegen wires the admin ops whenever DO-backed auth is pinned to a
+ * jurisdiction, so the thing a host would have to refuse is the jurisdiction.
+ *
+ * Most advisory keys are advisory *by nature*: the feature is engine-internal
+ * (`shardAlarms`, `shardedState`, `shardPlacement`, `shardReadReplicas`,
+ * `websocketHibernation`, `localSql`, `serverReactors`) or degrades honestly on
+ * its own (`httpCache` falls back to headers-only, `identityProxy` to header
+ * verification). There is nothing an app declares for codegen to notice, so
+ * there is nothing to gate. These stay ratings, permanently.
+ *
+ * The three telemetry keys — `edgeRequestMetadata`, `hostTraceFusion`,
+ * `logArchive` — are advisory by nature for a third reason worth naming, since
+ * it is not obvious: each is configured through a `createWorker` argument or an
+ * `ObservabilitySink` field (`trustInboundTraceContext`, `fuseCloudflareTraces`,
+ * `logArchive`), and codegen reads neither. There is no app-side DECLARATION to
+ * gate on, so promoting them would mean inventing one. Where that silence
+ * actually bites — `trustInboundTraceContext: "mtls"` collapsing to never-trust
+ * off Cloudflare — the runtime warns once instead, from the only tier that can
+ * observe it (`createDroppedTraceNotice` in `@lunora/runtime`).
+ *
+ * The rest of the telemetry pipeline — `ctx.log`, `ctx.trace`, `ctx.span`,
+ * `ctx.metrics`, traced `ctx.fetch`, automatic `ctx.db` / `ctx.sql` database
+ * instrumentation (a wrapper over the client the target already rates, so it
+ * follows `hyperdrive`'s rating rather than needing its own), and W3C trace
+ * propagation — deliberately
+ * has NO key: it is sink callbacks over the `fetch` global, needs no host
+ * primitive, and a key every target must rate `native` forever is paperwork, not
+ * a control.
+ *
+ * The rest are advisory only because nobody wired them, and they are the ones
+ * to watch: an app DOES declare the feature, codegen CAN see the declaration,
+ * and the rating is still consulted by nothing. Codegen already has the shape
+ * for exactly this — `PlatformSignals` in `platform-target.ts`, the second gate
+ * pass that diagnoses app-declared features with no `ctx.*` capability row
+ * (`agents`, `commitOrderedTables`, `containerEgressPolicy`,
+ * `containerRuntimeScheduling`, `containerSandboxTools`, `cronTriggers`,
+ * `crossShardFanout`, `durableStreams`, `globalTables`, `queues`,
+ * `relationGraph`, `secrets`, `services`, `topics`, `vectorStore`, `workflowRollback`,
+ * `workflowSchedules`).
+ * Promoting one is three lines there: a `PlatformSignals` field, plus its entry
+ * in that module's signal-key list and its human-readable label — and then
+ * setting the signal from the IR.
+ *
+ * `commitOrderedTables` was promoted that way: `TableIR.commitOrdered` sits in
+ * the same IR that feeds `globalTables`, and until it was read a host rating it
+ * `unsupported` emitted the full `.commitOrdered()` surface with no diagnostic
+ * and silently lost commit ordering — the one guarantee the feature is.
+ * `memoryTables`, `objectStorageBackups` and `objectStorageCdcArchive` remain
+ * weaker instances of the same shape, still unpromoted.
+ *
+ * **Adding a feature key is therefore half a change.** The other half is a row
+ * in `CAPABILITY_ROWS` and an entry in `CAPABILITY_TO_FEATURE` (for an
+ * app-imported `ctx.*` module), or a `PlatformSignals` entry (for something the
+ * app declares in its schema), or a deliberate decision that the key is advisory
+ * by nature — recorded here. Silence means the rating ships as documentation
+ * while the surface it describes is emitted anyway.
  */
 /** Support level for a single feature on a target platform. */
 type CapabilityLevel = "native" | "emulated" | "unsupported";
@@ -475,52 +731,528 @@ interface Capability {
 interface PlatformCapabilities {
   /** Feature-level capabilities. */
   features: {
-    /** AI inference (Workers AI / Bedrock / OpenAI). */
+    /**
+     * Durable agents — a `defineAgent` export in `lunora/agents.ts`.
+     *
+     * Its own key rather than a facet of `workflows` or `ai`, because an
+     * agent needs BOTH and neither implies the other: the generated class
+     * compiles onto the host's workflow engine as a `ctx.exports.<Class>` workflow
+     * the emitted context resolves off `env`, and the loop it runs there
+     * calls model inference. A host that emulates workflows but has no
+     * inference (or no way to mount a generated class into its engine) can
+     * rate `workflows` honestly and still not run an agent.
+     */
+    agents?: Capability;
+    /**
+     * AI inference — `ctx.ai` (Workers AI / Bedrock / OpenAI).
+     *
+     * Covers every model id `ctx.ai.model(...)` resolves, including
+     * `"<provider>/<model>"` catalog slugs and `dynamic/<route>` ids, which
+     * route through Cloudflare AI Gateway over the same `AI` binding rather
+     * than a binding of their own. A host rating this `native` must say how
+     * slugs resolve there; one without a gateway is honest to rate the
+     * Workers AI half and note the slug half missing. Usage accounting rides
+     * `ctx.trace` / `ctx.metrics`, which need no key.
+     */
     ai?: Capability;
+    /**
+     * Cloudflare AI Search (formerly AutoRAG) — `ctx.aiSearch`, the raw
+     * `ai_search_namespaces` binding passed through as-is, on ActionCtx only.
+     *
+     * Its own key rather than a facet of `ai` or `vectorStore`: it is a
+     * managed retrieval service (chunking, embedding, the hybrid index and
+     * reranking all live on the instance), not inference and not a vector
+     * index a host could stand in for. No Lunora host contract carries it —
+     * a second host would have to supply an `AiSearchNamespace` look-alike.
+     * Gate-bearing through `CAPABILITY_TO_FEATURE`.
+     */
+    aiSearch?: Capability;
     /** Analytics / observability sinks. */
     analytics?: Capability;
+    /**
+     * Read-only SQL over Cloudflare's Analytics SQL API through the Analytics
+     * SQL binding (wrangler `analytics` key) — `ctx.analyticsSql`, on
+     * ActionCtx only.
+     *
+     * Its own key rather than a facet of `analytics`: that one rates the
+     * write-only Analytics Engine sink (`ctx.analytics`, every ctx), a
+     * different binding a host could stand in for independently. No Lunora
+     * host contract carries this one — a second host would have to supply a
+     * `query({ query, params })` look-alike over its own analytics store.
+     * Gate-bearing through `CAPABILITY_TO_FEATURE`.
+     */
+    analyticsSql?: Capability;
+    /** Git-backed versioned repos via an Artifacts binding (`ctx.artifacts`). */
+    artifacts?: Capability;
+    /**
+     * Copying DO-backed auth from its un-pinned object into the
+     * jurisdiction-pinned one, and purging the un-pinned copy afterwards
+     * (the worker's `copyAuthToJurisdiction` / `purgeUnpinnedAuth` admin
+     * ops). Advisory by nature: it exists only once a schema pins auth with
+     * `.jurisdiction(…)`, which is itself the thing a host without
+     * jurisdictions cannot run.
+     */
+    authJurisdictionMove?: Capability;
     /** Browser rendering / headless browser. */
     browser?: Capability;
-    /** Container execution (Cloudflare Containers / Fargate). */
+    /**
+     * `.commitOrdered()` tables — the `_commitSeq` system field: a per-shard
+     * integer allocated once per mutation and strictly increasing in commit
+     * order.
+     *
+     * Listed as a capability rather than assumed, because the ordering
+     * guarantee is not the engine's to give. It rests on two things the HOST
+     * provides: an atomic write boundary the counter bump shares with the
+     * rows it stamps, and serialized execution so two mutations cannot
+     * interleave their allocations. A host that offers neither can still
+     * create the counter and hand out increasing numbers — they just would
+     * not order commits, which is the whole contract.
+     *
+     * Gate-bearing: `TableIR.commitOrdered` feeds the `PlatformSignals`
+     * pass off the same IR the `globalTables` signal reads, so a host
+     * rating this `unsupported` refuses the app rather than emitting the
+     * full `.commitOrdered()` surface and silently dropping the ordering
+     * guarantee — which is the only thing the feature is.
+     */
+    commitOrderedTables?: Capability;
+    /**
+     * Atomic conditional writes — `ctx.db.patchIf(table, id, { where, patch })`,
+     * which applies a patch only while the stored row matches `where`, decided
+     * in the same step as the write. What makes a read-decide-write (a rate
+     * limiter's admission, a compare-and-set) safe against concurrent callers.
+     *
+     * Carried by no host contract: it is SQL the engines already run. A
+     * shard-local table decides it in one synchronous run over `localSql`; a
+     * `.global()` table in one conditional `UPDATE` through `@lunora/sql-store`
+     * on the target's `globalTables` backend. A writer that cannot decide it
+     * atomically omits the method and the call is refused, never emulated with
+     * a read followed by a write. Advisory by nature (see the module header).
+     */
+    conditionalWrites?: Capability;
+    /**
+     * An outbound-traffic policy on a container — `defineContainer({
+     * allowedHosts | deniedHosts | interceptHttps })`, which
+     * `LunoraContainer` applies through `@cloudflare/containers`'
+     * outbound interception.
+     *
+     * Rated apart from `containers` because a host can run a container and
+     * still not police its egress; the policy is then not merely absent,
+     * the container refuses to start. Gate-bearing: codegen sets the
+     * `containerEgressPolicy` `PlatformSignals` flag when a
+     * `defineContainer` call carries one of those keys, so the gap is a
+     * build-time diagnostic rather than a container that fails on first use.
+     */
+    containerEgressPolicy?: Capability;
+    /**
+     * The `durable_object` container scheduling policy —
+     * `defineContainer({ schedulingPolicy: "durable_object" })`: each
+     * instance picks its image and size at `start()`, and can save and
+     * restore its filesystem (`snapshot()` / `start({ snapshot })`).
+     *
+     * One key for both halves because snapshots only exist under this
+     * policy — there is no app declaration for a snapshot that codegen
+     * could gate apart from the policy. Rated apart from `containers`
+     * because a host can run a container from one configured image and
+     * still have no way to start a chosen image or restore a filesystem.
+     * Gate-bearing: codegen sets the `containerRuntimeScheduling`
+     * `PlatformSignals` flag off `ContainerIR.schedulingPolicy`.
+     */
+    containerRuntimeScheduling?: Capability;
+    /**
+     * Container execution (Cloudflare Containers / Fargate), including
+     * `ctx.containers.<name>.exec`. Deliberately one rating rather than two:
+     * `exec` is a method on the accessor this key already gates, not a
+     * separate app-imported surface, so there is no usage signal codegen
+     * could gate it on independently and nothing that could act on a second
+     * rating. A host that can reach a container but cannot carry a command
+     * result back should say so in this note.
+     */
     containers?: Capability;
+    /**
+     * The Sandbox SDK helpers on a `defineContainer({ sandbox: true })`
+     * container: structured file operations (`Files`), directory backups to
+     * R2 (`DirectoryBackup`) and S3-compatible bucket mounts (`S3Mount`),
+     * from `@cloudflare/sandbox`. All three run the `sandbox-shim` helper
+     * through the native `ctx.container.exec()`, and the backup and mount
+     * helpers route the container's storage traffic through Worker
+     * entrypoints via `interceptOutboundHttp`. A host that runs a container
+     * but has neither cannot carry them. Gate-bearing: codegen sets the
+     * `containerSandboxTools` `PlatformSignals` flag off `ContainerIR.sandbox`.
+     */
+    containerSandboxTools?: Capability;
+    /**
+     * DECLARED cron triggers — the `cronJobs()` registrations codegen lifts
+     * into `LUNORA_CRONS`, dispatched by whatever the host wakes on a
+     * schedule.
+     *
+     * Separate from {@link PlatformCapabilities.features.scheduler}, which
+     * rates the imperative surface (`ctx.scheduler.runAfter/runAt`, a job
+     * the app enqueues at runtime). The two are genuinely independent: a
+     * host can dispatch enqueued jobs perfectly and still walk nothing into
+     * its declared crons, in which case an app's `crons.daily(...)` never
+     * fires. One rating covering both is how that shipped as green.
+     */
+    cronTriggers?: Capability;
     /** Cross-shard fan-out queries. */
     crossShardFanout?: Capability;
+    /**
+     * Durable streams: a `.stream()` run whose chunks are persisted and
+     * whose producer outlives the socket that opened it, so a reconnecting
+     * or second client resumes the same transcript.
+     */
+    durableStreams?: Capability;
+    /**
+     * Platform-injected PER-REQUEST metadata the runtime reads off the
+     * request object itself rather than a header — Cloudflare's `request.cf`.
+     *
+     * Two telemetry surfaces stand on it, and both degrade SILENTLY without
+     * it, which is why it is rated rather than assumed: the
+     * `trustInboundTraceContext: "mtls"` trust signal reads
+     * `cf.tlsClientAuth.certVerified` (absent ⇒ no caller is ever trusted, so
+     * every inbound `traceparent` is dropped), and the OTLP resource detector
+     * reads the colo/country placement attributes (absent ⇒ the spans carry
+     * no placement resource).
+     *
+     * What makes it a capability and not a header check is unforgeability:
+     * the platform sets it, so a caller cannot write it. A host that merely
+     * stamps a header carries no such proof and should rate this
+     * `unsupported`.
+     *
+     * Advisory by nature: both consumers are `createWorker` options, which
+     * codegen never sees, so there is no app-side declaration to gate on. The
+     * runtime warns once instead when a dropped trace proves the signal is
+     * undeliverable — see `createDroppedTraceNotice` in `@lunora/runtime`.
+     */
+    edgeRequestMetadata?: Capability;
     /** Global (replicated) tables backed by a SQL store. */
     globalTables?: Capability;
+    /**
+     * Merging Lunora's spans into the HOST's own trace tree, so its native
+     * tracing shows one nested tree instead of two unrelated ones — the
+     * sink's `fuseCloudflareTraces` opt-in, which reaches `cloudflare:workers`'
+     * `tracing.enterSpan` (plus, where present, `getActiveSpan` for the
+     * invocation root and a span's `setAttributes` / `recordException` /
+     * `setStatus`).
+     *
+     * Rated because it is the one telemetry surface that reaches past
+     * `ShardHost` into a provider API. Everything else in the pipeline is
+     * engine-level (a sink callback), so it runs anywhere; this needs the
+     * host to HAVE a trace tree and to expose a way to enter a span in it.
+     *
+     * `unsupported` costs nothing: the feature is already capability-probed
+     * at runtime and no-ops where the import is unavailable. The rating is
+     * what makes that a stated fact rather than something a second host
+     * discovers.
+     *
+     * Advisory by nature: the flag lives on the sink object passed to
+     * `createWorker`/`createShardDO`, which codegen never sees.
+     */
+    hostTraceFusion?: Capability;
+    /**
+     * A shared HTTP cache in front of the app that the runtime can READ AND
+     * WRITE — the Web Cache API (`caches.default` on Cloudflare), projected
+     * as `HttpCacheLike`.
+     *
+     * Rated separately from the app merely emitting `Cache-Control`, because
+     * only this half needs a host primitive. Emitting the header is portable
+     * by construction: any host that returns an HTTP response can do it, and
+     * browsers and downstream CDNs honour it wherever the app runs. What is
+     * not portable is a store the Worker itself can `match`/`put` against,
+     * which is why `@lunora/runtime`'s REST edge cache degrades to
+     * headers-only on a target rated `unsupported` rather than failing.
+     */
+    httpCache?: Capability;
     /** BYO database via connection pooling (Hyperdrive / RDS Proxy). */
     hyperdrive?: Capability;
+    /**
+     * An identity-aware proxy in front of the app that authenticates the
+     * caller before the request reaches it, and hands the runtime a verified
+     * identity **out-of-band** — on the execution context rather than on the
+     * request (Cloudflare Access attached to a Worker; IAP; an ALB OIDC
+     * action).
+     *
+     * Rated separately from the header-stamping form of the same product
+     * because only this one needs a host primitive. An identity-aware proxy
+     * that merely adds a signed header is portable by construction: any host
+     * that receives an HTTP request can verify it, which is why
+     * `@lunora/cloudflare-access` still works on a target rated
+     * `unsupported` here (it falls back to the `Cf-Access-Jwt-Assertion`
+     * JWT). What is not portable is the identity arriving beside the
+     * request, which is why `ExecutionContextLike.access` is a projection a
+     * host either populates or does not.
+     */
+    identityProxy?: Capability;
+    /** Image transforms (resize/format/optimize) via an Images binding. */
+    images?: Capability;
     /** Key-value storage (KV / Redis / DynamoDB). */
     keyValueStore?: Capability;
     /** Local SQL execution inside a shard. */
     localSql?: Capability;
+    /**
+     * Reading back the DURABLE `ctx.log` archive — the `logArchive` worker
+     * option behind the studio Logs panel's Archive feed and `lunora logs
+     * --durable`.
+     *
+     * Distinct from `pipelines` (which writes the records) because the read
+     * side needs two more things the write side does not: an Iceberg catalog
+     * over the object store, and an SQL engine that can query it
+     * (R2 Data Catalog + R2 SQL). A host that can ship log records to cold
+     * storage but cannot query them back should say `unsupported` here.
+     *
+     * Advisory by nature: the archive table is named by a `createWorker`
+     * option or the `LUNORA_LOG_ARCHIVE_TABLE` env var, neither of which
+     * codegen sees. Both fail closed at runtime with a single
+     * `LOG_ARCHIVE_NOT_CONFIGURED`, which the panel renders as an empty
+     * state, so an unsupported host degrades visibly rather than silently.
+     */
+    logArchive?: Capability;
     /** Email sending (Resend / SES / etc). */
     mail?: Capability;
-    /** Object storage (R2 / S3 / MinIO). */
+    /**
+     * `.memory()` tables — the ephemeral tier: rows cleared on every shard
+     * cold start, never written to the CDC changelog, refilled by
+     * `onShardInit`.
+     *
+     * The rating answers "does a memory table avoid durable storage on this
+     * host", NOT "does it work". The lifetime semantics are the engine's and
+     * hold everywhere; whether the rows actually stay out of the durable
+     * store depends on the host offering a second, memory-backed SQL handle,
+     * which is a per-target fact.
+     */
+    memoryTables?: Capability;
+    /**
+     * Paths into an object column — `where: { "profile.plan": "pro" }` and
+     * `patch(id, { "profile.plan": "pro" })`.
+     *
+     * Carried by no host contract: a shard-local table reads into its JSON document with SQLite's
+     * `json_extract`, and a `.global()` table does the same over its JSON-text column through
+     * `@lunora/sql-store`, so it follows the `globalTables` backend. Postgres and MySQL behind
+     * Hyperdrive read the same paths with their own JSON operators (`->` and `JSON_EXTRACT`), verified
+     * against PGlite (Postgres 18) and MySQL 8.0; Postgres needs 16 or later for `pg_input_is_valid`. Every
+     * path form works on all three, `contains` included, with no refusal. The partial update is made in the
+     * engine and works everywhere. Advisory by nature (see the module header).
+     */
+    objectColumnPaths?: Capability;
+    /**
+     * Object storage (R2 / S3 / MinIO).
+     *
+     * `ctx.storage.deleteAfterCommit(key)` rides on this rating and gets no
+     * key of its own: it needs no host primitive beyond the bucket. The
+     * post-commit flush uses `ShardHost.waitUntil` where the host has one and
+     * is awaited inline where it does not, so a host that can serve
+     * `objectStorage` serves the deferral at the same level.
+     */
     objectStorage?: Capability;
+    /**
+     * Snapshot backups kept in object storage rather than on the machine
+     * that took them — `lunora backup create|list|restore --bucket`, and
+     * the platform's own `backupCron`. Distinct from
+     * `objectStorage` above because it needs three things a
+     * bucket alone does not imply: an admin-gated read of one object
+     * (`GET /_lunora/admin/storage/object`), a checksum-verified write, and
+     * a scheduler to run the unattended half.
+     */
+    objectStorageBackups?: Capability;
+    /**
+     * The CDC changelog's cold tier: rows a retention sweep is about to
+     * destroy are written to an object-storage bucket first
+     * (`LUNORA_CDC_ARCHIVE`), and a consumer whose cursor has fallen below
+     * the retained window is served from there instead of being told to
+     * re-seed.
+     *
+     * Distinct from `objectStorage` because it needs the bucket to do one
+     * thing a plain byte store need not: resume a key-ordered listing from a
+     * position (`list({ startAfter })`). Without it the read-back re-lists
+     * the prefix from the front every time and stops finding the range it
+     * needs once enough segments precede the cursor — which fails as a
+     * refusal rather than a gap, but fails permanently and silently, so a
+     * host that cannot seek should say `unsupported` here rather than
+     * inherit `objectStorage`'s rating.
+     */
+    objectStorageCdcArchive?: Capability;
     /** Pipelines / streaming data. */
     pipelines?: Capability;
+    /**
+     * In-place point-in-time recovery of a shard — the `getPitrBookmark` /
+     * `pitrRestore` admin ops and the studio page that drives them. They
+     * need the host's own change log: a bookmark names a moment in it and a
+     * restore rewinds the shard's database to one. Nothing in `ShardHost`
+     * carries that, so a host without it answers `PITR_UNAVAILABLE`.
+     *
+     * Advisory for codegen by nature — an app declares nothing to gate on;
+     * the admin ops are always wired. Studio reads it to mark the page
+     * unavailable on a host that cannot serve it. The off-platform tier
+     * (`lunora backup`) is {@link PlatformCapabilities.features.objectStorageBackups}.
+     */
+    pointInTimeRecovery?: Capability;
+    /**
+     * Query plans — `ctx.db.<table>.explain(args)`, which returns the SQL a `findMany`
+     * compiles to and the database's own plan for it.
+     *
+     * Carried by no host contract: it prefixes a statement the engines already build with
+     * `EXPLAIN QUERY PLAN` (SQLite, D1) or `EXPLAIN` (Postgres, MySQL), on `localSql` for a
+     * shard-local table and through `@lunora/sql-store` on the `globalTables` backend. The plan
+     * text is the database's own, so its wording differs by backend. Advisory by nature (see the
+     * module header).
+     */
+    queryExplain?: Capability;
     /** Queue-backed workpools. */
     queues?: Capability;
+    /**
+     * `ctx.db.related(...)` — breadth-first traversal of the foreign-key
+     * graph the schema's `v.id("target")` columns describe, returning each
+     * reached row with its depth, the edge names walked to reach it, and a
+     * depth-decaying score.
+     *
+     * Rated on its own key rather than folded into `localSql`, because the
+     * two answer different questions: `localSql` says a shard can run SQL,
+     * while this says a host can serve the traversal's read SHAPE — an
+     * id lookup per out-edge and a batched `WHERE fk IN (...)` per in-edge,
+     * repeated per hop within one request. A host whose reads are remote
+     * enough that a multi-hop expansion cannot finish inside a request
+     * should say `unsupported` here even though every individual read works.
+     *
+     * Gate-bearing: codegen sets the `relationGraph` `PlatformSignals` flag
+     * from the schema IR's `v.id` columns, so a host rating it
+     * `unsupported` refuses the app rather than emitting a `related` that
+     * throws (or worse, silently returns nothing) on the first hop.
+     */
+    relationGraph?: Capability;
+    /**
+     * The origin a request reached the app on, forwarded to the shard with the
+     * dispatch: `ctx.origin` in mutations and actions, and the base
+     * `ctx.storage` signs URLs against when no `publicBaseUrl` is declared.
+     *
+     * The runtime reads it off `request.url`, never off a client header, so
+     * the rating answers whether the HOST vouches for that URL's host. An app
+     * signing URLs against it may hand them to other callers, and a host that
+     * builds the URL from a caller-typed `Host` header lets that caller choose
+     * where they point.
+     *
+     * Advisory by nature: every target populates it, so codegen has nothing
+     * to omit. Where the host does not vouch for it, configure a base
+     * (`publicBaseUrl`, or the storage registry item's
+     * `STORAGE_PUBLIC_BASE_URL`), which always wins over the origin.
+     */
+    requestOrigin?: Capability;
     /** Cron triggers / scheduled functions. */
     scheduler?: Capability;
     /** Secrets management. */
     secrets?: Capability;
+    /**
+     * `onQueryChange` reactors — server-side reactivity: a subscriber that is
+     * not a socket, woken after a write flush when a watched read's result
+     * changed.
+     *
+     * Host-dependent because the whole mechanism rests on the host being able
+     * to run work AFTER a write commits, on the same shard, without a client
+     * connection to hang it off — and on that work being serialized against
+     * further writes so a reactor's own writes cascade deterministically
+     * rather than interleaving.
+     */
+    serverReactors?: Capability;
+    /**
+     * Service bindings to sibling Workers — `lunora.config.*` `services` →
+     * `ctx.services.<name>` on actions (plan 457): a fetch `Fetcher`, or an
+     * RPC stub for a `WorkerEntrypoint`. Gate-bearing: codegen sets the
+     * `services` `PlatformSignals` flag on a declared service.
+     */
+    services?: Capability;
     /** Alarms / scheduled wakeup inside a shard. */
     shardAlarms?: Capability;
     /** Durable Object-style sharded state. */
     shardedState?: Capability;
+    /** Geographic placement of a shard (`ShardPlacement.locationHint`). */
+    shardPlacement?: Capability;
+    /** Region-local read replicas of a shard, for one-shot queries. */
+    shardReadReplicas?: Capability;
+    /**
+     * Pub/Sub topics — `defineTopic` / `defineSubscription` → `ctx.topics`.
+     * Each subscription deploys as its own queue and a publish sends to all
+     * of them, so this is never better than `queues` on the same host.
+     * Gate-bearing: codegen sets the `topics` `PlatformSignals` flag on a
+     * `defineTopic` export.
+     */
+    topics?: Capability;
     /** Vector database (Vectorize / pgvector / Pinecone). */
     vectorStore?: Capability;
     /** Hibernated WebSocket subscriptions. */
     websocketHibernation?: Capability;
+    /**
+     * Worker Loaders (Dynamic Workers): load code supplied at runtime into
+     * its own isolate with an `env`, egress and CPU budget the loader
+     * chooses. `@lunora/agent`'s `jsCodeTool` runs model-written scripts
+     * through it. Gate-bearing: codegen sets the `workerLoaders`
+     * `PlatformSignals` flag on a `jsCodeTool` import in `lunora/`.
+     */
+    workerLoaders?: Capability;
+    /**
+     * Compensation for a failed workflow — `defineStep({ rollback })`,
+     * which `@lunora/workflow` forwards to the host's `step.do` rollback
+     * option.
+     *
+     * Rated apart from `workflows` because a host can run steps, sleeps and
+     * events and still not implement rollback, and there the step does not
+     * run without it — it fails. Gate-bearing: codegen sets the
+     * `workflowRollback` `PlatformSignals` flag when a `defineStep` call
+     * declares a `rollback`, so the gap is a build-time diagnostic rather
+     * than a step that fails on first use.
+     */
+    workflowRollback?: Capability;
     /** Durable workflows (step-based). */
     workflows?: Capability;
+    /**
+     * Cron-started workflow instances — `defineWorkflow({ schedules })`,
+     * written to the wrangler `workflows[].schedules` list, where the host
+     * itself creates an instance on each tick (no `scheduled()` handler).
+     *
+     * Rated apart from `workflows` and from `cronTriggers` because it is
+     * neither: a host can run workflows it is asked to create, and dispatch
+     * declared crons to `scheduled()`, and still never start a workflow off
+     * its own schedule list. That host would build the app green and the
+     * workflow would simply never run. Gate-bearing: codegen sets the
+     * `workflowSchedules` `PlatformSignals` flag when a workflow declares
+     * `schedules`.
+     */
+    workflowSchedules?: Capability;
   };
   /** Platform identifier used in codegen and config (e.g. "cloudflare", "aws"). */
   id: string;
   /** Human-readable platform name (e.g. "Cloudflare", "AWS", "Rivet"). */
   name: string;
 }
+/**
+ * The celld capability matrix — `@lunora/platform-celld`'s honest self-rating.
+ *
+ * celld (github.com/denoland/celld) is a self-hosted, distributed Durable
+ * Objects daemon: each node embeds V8, executes Wrangler bundles, and
+ * coordinates ownership through an S3-compatible (or GCS / Azure Blob) bucket
+ * instead of a control plane. Because it implements the Workers/Durable Object
+ * API itself, the Cloudflare host adapters ARE the celld host adapters — what
+ * differs is which primitives exist, and that difference is exactly this
+ * matrix.
+ *
+ * Ratings track celld **v0.6.1** and derive from its documented compatibility
+ * surface (`docs/cloudflare-compat.md`, `docs/services/*.md`,
+ * `docs/limitations.md` in the celld repo; v0.6.0 was celld's first beta). The host contracts
+ * behind `shardedState`, `localSql`, `shardAlarms`, `commitOrderedTables` and
+ * `websocketHibernation` are also exercised by the conformance TCK against a
+ * live single-node celld (`@lunora/platform-celld`'s `celld` vitest project),
+ * which also drives D1, KV, R2, Queues, Workflows and Cron Triggers through
+ * Lunora's own adapters and runs a `LunoraContainer`, and a two-node fleet
+ * test covers routing, crash takeover and rebalancing. celld's own rule is
+ * that an unsupported configuration or API must fail at deploy or first use,
+ * so "Partial" there means a listed set of gaps rather than silent
+ * degradation; the gaps that bite Lunora are named per key below.
+ *
+ * `shardPlacement` and `shardReadReplicas` stay `unsupported`, and by celld's
+ * own design rather than a gap: its Durable Object docs state it "makes no
+ * placement, migration, or jurisdiction promise". Nodes carry no region, and
+ * rebalancing moves hibernated cells toward each node's `CELLD_PLACEMENT_WEIGHT`
+ * share, not toward a reader — so there is no location to hint at and no region
+ * to place a read replica in. Revisit only if celld grows node regions.
+ */
+declare const CELLD_CAPABILITIES: PlatformCapabilities;
 /**
  * The Cloudflare capability matrix — the reference implementation.
  *
@@ -535,33 +1267,72 @@ declare const CLOUDFLARE_CAPABILITIES: PlatformCapabilities;
  * The Node capability matrix — `@lunora/platform-node`'s honest self-rating
  * (plan 234).
  *
- * `@lunora/platform-node` is a spike: a `ShardHost`/`SocketHost`/
- * `ShardDirectory`/`ShardKvStore`/`SchedulerHost` implementation over
- * `better-sqlite3` and an in-process registry, built to run the conformance
- * TCK against a second host and discover what the contracts under-specify.
- * It is a single Node process with no distributed placement, no host-level
- * scheduler to re-arm timers after a restart, and no bindings at all for the
- * Cloudflare-specific products (R2, Vectorize, Workers AI, Queues,
- * Workflows, Containers, Browser Rendering, Analytics Engine, Secrets Store,
- * Hyperdrive) most `ctx.*` surfaces are built on. Every one of those is
- * rated `"unsupported"` here rather than left undeclared — see
- * `gateAgainstMatrix` in `@lunora/codegen`, whose fail-closed gate (plan
- * 229) treats an undeclared feature as unsupported anyway, but under a
- * different diagnostic name than an honest, explicit rating.
- *
- * Two features are rated `"emulated"` rather than `"native"` even though
- * this package fully implements their contract, because "native" would
- * overstate what a bare Node process provides on its own: `keyValueStore` is
- * a SQL table wearing a KV-shaped API, not a dedicated KV product, and
- * `websocketHibernation` never actually evicts a socket to save memory — it
- * only proves the attachment/tag durability half of the contract, not real
- * hibernation. `scheduler` and `shardAlarms` are rated `"unsupported"`, not
- * `"emulated"`: the Node host stores and times both, but its timer body only
- * clears bookkeeping — nothing dispatches the scheduled function or wakes the
- * alarm callback. `"emulated"` means built on lower-level primitives and
- * working; never-dispatched is not that (plan 267). `globalTables` is also
- * `"unsupported"` — no replicated SQL store is implemented. All ratings are
- * argued in detail in `plans/234-node-host-findings.md`.
+ * `@lunora/platform-node` implements every contract in this package
+ * (`ShardHost`, `SocketHost`, `ShardDirectory`, `ShardKvStore`,
+ * `SchedulerHost`) over `better-sqlite3` and an in-process registry, plus the
+ * `.global()` table backend via `@lunora/sql-store`. It began as a spike to run
+ * the conformance TCK against a second host; the durability gaps that spike
+ * surfaced — alarms and scheduler jobs that were persisted but never re-armed,
+ * socket attachments that lived only in memory — are closed, and each is now
+ * pinned by a restart test rather than only by a simulated recycle.
+ *
+ * `scheduler` and `shardAlarms` were rated `"unsupported"` under plan 267, on
+ * the grounds that the host stored and timed both while its timer body only
+ * cleared bookkeeping — nothing dispatched the scheduled function or woke the
+ * alarm. That rating was correct for the code it described, and the code is
+ * what changed: both now dispatch (through `onDispatch` / `onAlarm`) and both
+ * re-arm from their durable rows on construction, so `"emulated"` — built on
+ * lower-level primitives and *working* — is now the honest reading.
+ *
+ * What remains genuinely absent is everything a single Node process cannot
+ * distribute: placement across nodes, failover, and most Cloudflare-specific
+ * product bindings (Vectorize, Workers AI, Containers, Browser Rendering,
+ * Analytics Engine, Secrets Store, Hyperdrive). Workflows, object storage and
+ * queues are the three that CAN be emulated locally — `defineWorkflow` handlers
+ * compile onto the `@visulima/workflow` engine, R2 becomes a filesystem bucket,
+ * and Queues becomes a durable table with the same batch/ack/retry/dead-letter
+ * semantics — so those three are rated `"emulated"`; the rest of the Cloudflare
+ * products most `ctx.*` surfaces are built on are rated `"unsupported"` here
+ * rather than left undeclared — see `gateAgainstMatrix` in `@lunora/codegen`,
+ * whose fail-closed gate (plan 229) treats an undeclared feature as unsupported
+ * anyway, but under a different diagnostic name than an honest, explicit rating.
+ *
+ * Almost nothing here is rated `"native"`, and that is the matrix's own
+ * definition doing its job rather than a hedge: `native` means the platform
+ * itself provides the feature, and a bare Node process provides essentially
+ * none of them — Lunora builds alarms out of `setTimeout` plus a durable row,
+ * a KV store out of a SQL table, and `.global()` tables out of a second SQLite
+ * file. `localSql` is the exception, because SQLite genuinely is the platform
+ * primitive there. The ratings say who does the work; the notes say how well.
+ * Both are argued in detail in `plans/234-node-host-findings.md`.
  */
 declare const NODE_CAPABILITIES: PlatformCapabilities;
-export { type AnalyticsEngineDataPoint, type AnalyticsEngineDataPointLike, type AnalyticsEngineDatasetLike, CLOUDFLARE_CAPABILITIES, type Capability, type CapabilityLevel, type D1DatabaseLike, type D1PreparedStatementLike, type D1SessionLike, type ExecutionContextLike, type KVNamespaceLike, type KvGetOptions, type KvListKey, type KvNamespaceListResult, type KvNamespacePutOptions, type KvValue, type KvValueType, type MessageBatchLike, type MessageLike, type MessageSendRequestLike, NODE_CAPABILITIES, NOOP_EXECUTION_CONTEXT, type PlatformCapabilities, type QueueBindingLike, type QueueContentType, type QueueMessageLike, type QueueRetryOptions, type QueueSendBatchOptions, type QueueSendOptions, type QueueSendOptionsLike, type QueueSendRequestLike, type R2BucketLike, type R2MultipartUploadLike, type R2ObjectBodyLike, type R2ObjectLike, type R2RangeLike, type R2UploadedPartLike, type VectorMatchLike, type VectorMetric, type VectorRecordLike, type VectorizeDeleteMutation, type VectorizeIndexDetails, type VectorizeIndexLike, type VectorizeMatch, type VectorizeMatches, type VectorizeQueryOptions, type VectorizeUpsertMutation, type VectorizeVector };
+export { type AnalyticsEngineDataPoint, type AnalyticsEngineDataPointLike, type AnalyticsEngineDatasetLike, CELLD_CAPABILITIES, CLOUDFLARE_CAPABILITIES, type Capability, type CapabilityLevel, type D1DatabaseLike, type D1PreparedStatementLike, type D1SessionLike,
+/**
+ * `@lunora/platform` — provider-neutral host contracts for Lunora.
+ *
+ * This package defines the structural interfaces that separate the Lunora
+ * engine from any specific host (Cloudflare Workers, AWS, Rivet, Node, etc.).
+ * It contains **types and capability metadata only** — near-zero runtime code.
+ *
+ * The contracts fall into four groups:
+ *
+ * 1. **Shard host** (`ShardHost`) — single-writer execution, transactions,
+ * local SQL, alarms, and background continuation per shard key.
+ * 2. **Socket host** (`SocketHost`) — hibernated WebSocket subscriptions with
+ * durable attachments and tagged fan-out.
+ * 3. **Shard directory** (`ShardDirectory`) — deterministic placement and RPC
+ * dispatch from shard keys to stubs.
+ * 4. **Scheduler host** (`SchedulerHost`) — durable delayed jobs, cron, and
+ * at-least-once dispatch.
+ *
+ * Plus canonical binding projections (`KVNamespaceLike`, `R2BucketLike`,
+ * `QueueBindingLike`, `D1DatabaseLike`, `VectorizeIndexLike`, …) and the
+ * `PlatformCapabilities` matrix that codegen uses to tailor emitted types per
+ * target.
+ *
+ * This package is **zero-dependency** and safe on every runtime (browser,
+ * workerd, Node). It is intended to be the leaf dependency every other
+ * `@lunora/*` package can import without creating cycles.
+ */
+type ExecutionContextLike, type HttpCacheLike, type HttpCacheQueryOptions, type KVNamespaceLike, type KvGetOptions, type KvListKey, type KvNamespaceListResult, type KvNamespacePutOptions, type KvValue, type KvValueType, type MessageBatchLike, type MessageLike, type MessageSendRequestLike, NODE_CAPABILITIES, NOOP_EXECUTION_CONTEXT, type PlatformCapabilities, type QueueBindingLike, type QueueContentType, type QueueMessageLike, type QueueRetryOptions, type QueueSendBatchOptions, type QueueSendOptions, type QueueSendOptionsLike, type QueueSendRequestLike, type R2BucketLike, type R2ConditionalLike, type R2MultipartUploadLike, type R2ObjectBodyLike, type R2ObjectLike, type R2PutBodyLike, type R2PutOptionsLike, type R2RangeLike, type R2UploadedPartLike, type VectorMatchLike, type VectorMetric, type VectorRecordLike, type VectorValues, type VectorizeDeleteMutation, type VectorizeIndexDetails, type VectorizeIndexLike, type VectorizeMatch, type VectorizeMatches, type VectorizeQueryOptions, type VectorizeUpsertMutation, type VectorizeVector };