@aotter/mantle 0.2.0-alpha.5 → 0.2.0-alpha.7

package/docs/adr/0024-manifest-native-schema-tables.md

@@ -1,264 +0,0 @@
-# ADR-0024: Materialize each Schema as a native storage table
-
-**Status:** Accepted; the clauses allowing authored data to use `id`, `status` or `createdAt` are superseded by [ADR-0025](0025-reserved-native-columns-and-published-only-public-views.md) (2026-09-22); the migration-artifact and destructive-change workflow is superseded by [ADR-0033](0033-storage-converges-to-the-plan.md) for 0.2.0
-
-**Date:** 2026-09-18
-
-**Related:** ADR-0010, ADR-0011, ADR-0019, ADR-0020, ADR-0022, ADR-0023
-
-## Context
-
-The SQLite adapter currently stores every Schema row in one `entries` table.
-Business fields live in a JSON `data` column. Schema indexes add generated
-columns and partial indexes to that shared table, and Schema-shaped SQL views
-project JSON fields back into columns.
-
-That layout made the first dynamic runtime small, but it is now the wrong
-authority for a manifest-built system:
-
-- a successfully built Manifest already fixes every Schema and field type;
-- generated columns for every historical indexed field accumulate on one
-  table, while D1 allows at most 100 columns per table;
-- native SQL, inspection, export, and migration tooling see an implementation
-  envelope instead of the authored data model;
-- application migrations and Mantle's canonical `entries` migrations form two
-  persistence systems;
-- the compatibility layer is now larger than direct table CRUD.
-
-Mantle has not shipped a stable storage format. Keeping the generic table for
-downward compatibility would create the dual path this change is intended to
-remove.
-
-## Decision
-
-### One physical table per Schema
-
-The SQLite/D1 storage adapter materializes every compiled Schema as a quoted
-native table. The table contains:
-
-- Mantle columns: `_mantle_id`, `_mantle_status`, `_mantle_version`,
-  `_mantle_created_at`, `_mantle_updated_at`, and `_mantle_author_id`;
-- one column for every top-level Schema property;
-- native indexes for every `indexes` and `uniqueIndexes` tuple.
-
-Single scalar JSON Schema types map to SQLite affinities: string to `TEXT`,
-integer and boolean to `INTEGER`, and number to `REAL`. Objects, arrays, unions,
-and otherwise polymorphic values use `TEXT` containing canonical JSON so a
-round trip cannot change their JSON type. Nullable values use SQL `NULL`.
-
-Business columns remain nullable at the database layer. Mantle allows an
-incomplete authoring draft; Runtime validation enforces required fields when a
-record becomes complete or when an operational Schema is written. An optional
-nullable property reads as `null` when its column is null. This is the v0.1
-native-table contract; it intentionally does not preserve a distinction
-between an absent optional nullable field and an explicit null.
-
-Schema names and field names remain authored wire names and are always SQL
-identifier quoted. A Schema table uses its authored Schema name. SQLite
-preparation rejects collisions with selected infrastructure tables or views,
-including auth tables; this check belongs to the concrete deployment because
-the portable Manifest cannot know which optional infrastructure a host binds.
-Internal Mantle tables and columns use the reserved `_mantle_` prefix, so
-Mantle metadata never collides with authored column names. *Superseded in
-part by ADR-0025:* authored data may no longer use the six native column
-names (`id`, `status`, `version`, `createdAt`, `updatedAt`, `authorId`); the
-prefix remains for every other authored name.
-
-The SQLite adapter no longer creates `entries`, generated field columns, or
-Schema projection views. There is no dual write, compatibility view, or
-fallback JSON repository.
-
-### The compiled storage plan owns DDL
-
-SQLite preparation lowers the Schemas already present in the sealed
-`RuntimePlan` into quoted DDL and prepared queries. A persistence-only
-projection of those Schemas has a deterministic storage fingerprint; changes
-to Procedures, Views, or Triggers do not create a storage revision. No second
-physical-plan model mirrors `RuntimePlan`.
-
-Other adapters map the same Schema manifests into their own native storage.
-Runtime continues to consume semantic `EntryRepository`,
-`EntryReader`, and `ViewQueryExecutor` ports; SQL remains infrastructure.
-
-Repository operations that address one row carry its Schema collection.
-`get(id)` and `readById(id)` become collection-qualified operations. Generated
-bindings hide this argument behind Schema-specific APIs. Runtime operations
-already know the target Schema from their compiled handler, route, or row
-context; callers must not search every table for an unqualified id.
-
-Cross-Schema reads are compiled explicitly from the Runtime plan. There is no
-implicit union of all tables. A caller that needs several Schemas invokes the
-declared Views or Schema-specific readers and combines their results at the
-application layer.
-
-### Migrations are build artifacts
-
-The SQLite build compares a stored source Schema description with the target
-RuntimePlan and emits a versioned SQL migration artifact containing:
-
-- source and target storage fingerprints;
-- ordered SQLite SQL;
-- a checksum over the exact migration content;
-- whether the change is expand-only or destructive.
-
-Mantle deterministically emits initial tables and safe additive changes. Field
-renames, type conversions, data transforms, narrowing constraints, and any
-`uniqueIndexes` tuple change are
-destructive in the pre-beta contract. Cloud rejects them; operators rebuild the
-database and move required data manually outside Mantle and Control. Production
-neither generates nor accepts arbitrary migration SQL.
-
-Preparation records applied migration ids in the `_mantle_migrations` ledger (#1150).
-The enclosing immutable artifact checksum protects the ordered SQL,
-fingerprints, and target projections. Preparation rejects an unknown source
-fingerprint, changed artifact checksum, skipped revision, or target mismatch.
-Generated migrations are idempotent and retryable after partial application;
-activation and integrity verification run on every attempt instead of being
-treated as one-time ledger entries.
-
-Generated migrations quote all identifiers and never interpolate runtime
-input. Automatic deployments retain removed fields, indexes, and tables as a
-physical superset; logical reads follow the selected plan, while retained
-storage keeps the previous Worker rollback-compatible.
-
-### Builder support
-
-Builder keeps its in-memory or IndexedDB semantic adapter for interactive
-preview. It does not carry SQLite into portable Runtime.
-
-Each successful build can show a draft-to-draft storage delta for authoring
-feedback. It is not labeled as the deployment artifact: only Cloud knows the
-last successfully deployed source revision and produces the exact immutable
-artifact used by deployment. The publish result shows its source/target
-fingerprints, risk classification, ordered SQL, and checksum.
-The interactive preview continues to run the real Mantle Runtime over the
-existing IndexedDB semantic adapter; it does not carry a second SQLite runtime
-or copy preview data into one. Destructive changes remain previewable but are
-not deployable on the pre-beta Cloud path.
-
-CI executes generated SQL against SQLite. Mantle Cloud/D1 is authoritative at
-deployment: it checks the immutable artifact, migration ledger, source/target
-fingerprints, database integrity, and canary before restoring traffic. Running
-the same DDL in every Builder browser would duplicate those gates while adding
-WASM weight and a second Worker/browser compatibility surface.
-
-Unsaved invalid Manifest edits produce diagnostics and no storage revision.
-Intermediate Builder edits do not become production migrations. Deployment
-diffs the last deployed storage revision against the selected project revision.
-
-### Cloud runtime and Schema upgrades
-
-Every Cloud deployment pins these immutable identities:
-
-- Mantle runtime release;
-- project revision and compiled plan fingerprint;
-- source and target storage fingerprints;
-- migration checksum;
-- application artifact checksum.
-
-Automatic migrations are expand-only and therefore run online. The deployment
-sequence is:
-
-1. verify the current tenant D1 storage fingerprint;
-2. apply idempotent additive DDL and verify the ledger, marker, and integrity;
-3. upload an immutable Worker script named by project revision;
-4. run the canary directly against that script and the actual D1 marker;
-5. select that revision for the default and custom host routes;
-6. record the revision active.
-
-There is no KV maintenance gate: KV propagation cannot drain in-flight writes,
-and additive DDL does not need one. Destructive changes stop before deployment.
-The old revision script remains addressable, so route failure or operator
-rollback selects the previous script without rebuilding or replacing it.
-
-Automatic deployments retain old columns and tables needed by the previous
-active Worker. This keeps code rollback valid. Physical cleanup happens only
-during a later reset or rebuild. Mantle runtime upgrades use the same mechanism
-even when the authored Manifest does not change.
-
-Release and application objects are content-addressed. A retry validates and
-reads the same bytes selected by the original operation; mutable release names
-are not valid deployment input.
-
-## Consequences
-
-### Positive
-
-- D1, SQLite tools, generated types, and the Manifest describe the same tables.
-- Each Schema gets independent native limits, indexes, query plans, and schema
-  evolution.
-- The shared-table column ceiling and permanent generated-column buildup are
-  removed.
-- Application migrations and Mantle runtime upgrades use one revision model.
-- Removing the compatibility repository leaves less persistence code.
-
-### Negative
-
-- This is a storage-format break and requires coordinated changes across Spec,
-  Runtime, SQLite adapters, conformance tests, Builder, and Cloud deployment.
-- Unqualified global entry lookups and implicit cross-Schema lists disappear.
-- Optional nullable fields no longer distinguish absent from explicit null.
-- Destructive schema changes require a manual rebuild and data move outside
-  Mantle and Control.
-
-## Alternatives
-
-### Keep `entries` and improve its generated indexes
-
-Rejected. It preserves the shared table's column ceiling, JSON inspection
-surface, and a second schema representation after Manifest build already knows
-the physical model.
-
-### Keep `entries` as a registry beside native Schema tables
-
-Rejected. A registry adds dual-write atomicity and stale-index failure modes.
-Schema-qualified access removes the need for it.
-
-### Put SQLite WASM in the portable Runtime
-
-Rejected. Runtime already has a semantic storage boundary. Builder can verify
-the SQLite lowering as a build check without making every adapter or browser
-preview depend on SQLite.
-
-### Generate production migrations at deploy time
-
-Rejected. Deployment must execute an immutable reviewed artifact and remain
-deterministic when retried. AI generation belongs before review, not inside a
-production mutation.
-
-## How to apply
-
-1. Add the sealed physical storage plan and SQLite DDL lowering.
-2. Change semantic row operations to require collection identity and update all
-   first-party callers.
-3. Replace the shared SQLite repository and View compiler with native-table
-   implementations; delete shared-table DDL, views, index reconciliation, and
-   compatibility helpers.
-4. Update memory and IndexedDB adapters to the new semantic port shape.
-5. Add build-time migration diff/artifact inspection, plus SQLite execution in
-   CI and Cloud/D1 deployment verification.
-6. Pin content-addressed runtime, storage, migration, application, and Worker
-   revision identities in Cloud deploys; test initial deploy, additive Schema
-   change, runtime-only upgrade, partial migration retry, and route rollback.
-7. Update all public storage, Schema, Builder, deployment, and migration
-   documentation after the conformance and consumer checks pass.
-
-## Decision review
-
-Reviewed after implementation against ADR-0019, the semantic storage ports,
-Builder preview persistence, and Mantle Cloud's retryable deployment state.
-The review found and corrected three boundary mistakes before acceptance:
-
-- authored data was allowed to contain `id`, `status`, or `createdAt`, so
-  physical envelope columns require the `_mantle_` prefix (the prefix stays;
-  ADR-0025 later reserved those names for authored data as well);
-- Builder should expose draft storage risk without pretending it knows the
-  deployed baseline; Cloud shows the exact immutable artifact, while CI and
-  Cloud/D1 own executable DDL verification and preview stays on IndexedDB;
-- Cloud must pin the runtime release and storage artifact selected when the
-  operation starts; a mutable current release would make retry and rollback
-  nondeterministic.
-
-The native-table path is implemented without a compatibility `entries` table.
-Acceptance is gated by the repository consumer check and the Cloud upgrade,
-retry, and rollback checks in the ADR's final application step.

package/docs/adr/0025-reserved-native-columns-and-published-only-public-views.md

@@ -1,105 +0,0 @@
-# ADR-0025: Reserved native column names and published-only public Views
-
-**Status:** Accepted
-
-**Date:** 2026-09-22
-
-**Related:** [#962](https://github.com/aotter/mantle/issues/962),
-[#1007](https://github.com/aotter/mantle/issues/1007),
-[#1008](https://github.com/aotter/mantle/issues/1008),
-[#1009](https://github.com/aotter/mantle/issues/1009),
-[#1010](https://github.com/aotter/mantle/issues/1010),
-[ADR-0022](0022-caller-observed-version-occ.md),
-[ADR-0024](0024-manifest-native-schema-tables.md) (partially superseded: its clauses allowing authored `id`, `status`, `createdAt`)
-
-## Context
-
-Every entry carries six native columns outside `data`: `id`, `status`,
-`version`, `createdAt`, `updatedAt`, `authorId`. Before this decision the
-grammar treated their names inconsistently:
-
-- A Schema data property could reuse one of the names. The SQLite dialect then
-  resolved the name to the data column first; IndexedDB resolved it to the
-  native field first. The same View read different columns on different
-  storage.
-- `Schema.spec.indexes` could not reference the names at all
-  (`SCHEMA_INDEX_INVALID`), while the runtime's own indexes lead with
-  `_mantle_status`.
-- A public View over a `publishing` Schema hid drafts only when the author
-  wrote `filter: eq status published`. The handbook promised drafts are
-  unreadable until published; nothing enforced it on REST, MCP
-  `query_view_*` or WebMCP, which share one compiled plan.
-
-The #962 soak measured the consequence of the second point: the list View
-read 14,940 rows per request on a 10,991-row D1 table. Without planner
-statistics, which production SQLite-family storage never has, SQLite chose
-the runtime's `(_mantle_status, _mantle_updated_at, _mantle_id)` index for the
-status equality and sorted every published row in a temporary B-tree; the
-declared `[publishedAt]` index was never used, and the grammar refused the
-`(status, publishedAt)` index that would have served the query.
-
-Two alternatives were considered and rejected during review (#1008):
-
-- **Core derives indexes from Views.** Rejected: the manifest is a deployment
-  spec; Mantle Core is not a query optimizer, and a derived index has no
-  owner when a View is deleted.
-- **Explicit object references** such as `{ meta: status }` /
-  `{ field: publishedAt, direction: desc }`. Deferred: it adds a grammar shape
-  to solve an ambiguity that reserving the names removes, and no shipped View
-  needs mixed-direction ordering. It remains the upgrade path.
-
-A data-first resolution rule with only `status` reserved was also rejected: an
-index declared as `[[createdAt]]` would silently change meaning when a data
-property `createdAt` is added later, while the index identity (field-name
-hex) kept the old physical index.
-
-## Decision
-
-1. **The six native column names are reserved.** A Schema data property may
-   not use them; `mantle validate` fails closed with
-   `INVALID_MANIFEST_ENVELOPE` at `/spec/schema/properties/<name>`, the same
-   mechanism ADR-0022 uses for `expectedVersion`. Domain names replace them
-   (`submittedAt`, `orderStatus`, `submittedBy`).
-2. **Every storage resolves a native name to the native column, first.** With
-   shadowing rejected this is a no-op for valid manifests; it is stated so the
-   SQLite dialect, IndexedDB and the index DDL cannot drift apart again.
-3. **`Schema.spec.indexes` may reference native names**; the SQLite dialect
-   maps them to `_mantle_*` columns in `CREATE INDEX`. `uniqueIndexes` may not:
-   native columns carry no domain uniqueness. Tuples stay `string[][]`; no
-   direction, no object form.
-4. **The author declares the access path; Mantle measures it.** A public View
-   over a `publishing` Schema always carries `status = published`, so its
-   index leads with `status` (`indexes: [[status, publishedAt]]`). Core does
-   not synthesize that index. The harness and the D1 inspector (#1010) report
-   whether the declared index is used.
-5. **Public Views over `publishing` Schemas read published rows only, fail
-   closed.** The linker injects `status = published` into the compiled plan
-   whether or not the manifest writes it; an authored identical predicate is
-   redundant and kept; any other `status` comparison on such a View is
-   `VIEW_PUBLIC_STATUS_INVALID`. Staff Views, `operational` Schemas and SQL
-   Views are untouched.
-
-## Consequences
-
-- ADR-0024's statement that authored data may legitimately use `id`, `status`
-  or `createdAt` no longer holds; its `_mantle_` physical prefix is unchanged
-  and still guards every other authored name.
-
-- Breaking for manifests that declared a data property with one of the six
-  names; the official examples and tests were renamed (#1009). Storage is
-  additive: the renamed property is a new column and the old one stays until
-  an explicit migration. The 0.1.3 release entry carries the upgrade note.
-- The semantic fingerprint of any plan with a public publishing View changes
-  once (the injected predicate); `mantle generate` regenerates it.
-- Index identities of existing declarations are unchanged; native-name tuples
-  get new identities. Stale indexes left behind by redeclaration are tracked
-  separately (#1011).
-- Verified on real D1 without `ANALYZE`: the list View reads 50 rows per
-  request with `[status, publishedAt]` and 10,000 without it (#1014).
-
-## Where this lives
-
-The handbook is the single source: [`reference/schema.md`](../handbook/reference/schema.md)
-(reserved columns, index rules), [`reference/view.md`](../handbook/reference/view.md)
-(surfaces). Skills and CLI diagnostics point there; they do not restate the
-rules.

package/docs/adr/0026-progressive-generate.md

@@ -1,36 +0,0 @@
-# ADR-0026: Progressive application generation
-
-**Status:** Accepted by owner for the 0.1.5 line (#1081–#1086). Supersedes the no-initialization clause of ADR-0021; direct authorship and optional package boundaries remain.
-
-Mantle is progressive. A new application defaults to Spec, Runtime, API, MCP, Admin, and an editable blank Web home so an agent does not forget the optional Admin composition. `--features` is a positive replacement list over `spec,runtime,api,mcp,admin,web`; dependencies are closed automatically. `spec` alone is host-free. The first generated hosts are `cf` and `chatgpt-sites`. Only host-dependent selections require `--host`; a TTY may prompt, while headless use must pass it explicitly.
-
-| Feature | Required features | Direct package additions |
-| --- | --- | --- |
-| `spec` | — | `@aotter/mantle`, `zod` peer |
-| `runtime` | `spec` | Host adapter; current CF adapter also brings Admin/Auth/Web transitively |
-| `api` | `runtime` | Host route composition and `hono` peer |
-| `mcp` | `runtime` | Host MCP route composition |
-| `admin` | `runtime,api,mcp` | `@aotter/mantle-admin`, `@aotter/mantle-admin-ui`; CF owner auth also uses `@aotter/mantle-auth` |
-| `web` | `runtime` | `@aotter/mantle-web` and a user-owned blank home |
-
-The host adapter's declared peers (`better-auth`, `hono`, `zod`, `aws4fetch`) are installed for host-dependent selections until its package dependency graph is split. A reduced selection still omits unselected routes and assets; it does not claim smaller transitive installation today.
-
-An application with only Git, installed skills, package metadata, a lockfile, README, and installed dependencies is new. Existing manifests or application code remain in direct-authoring compile mode. A saved `mantle.config.json` decides subsequent runs before that heuristic. V1 refuses host changes and feature-list changes after selection; application owners can make an explicit migration rather than have generation delete routes or data. An explicitly named missing manifest path is an error. A new default manifest directory may be absent or empty, yielding a valid empty plan without a fake business Schema.
-
-Generation preflights selection, manifest validity, package/script conflicts, file ownership, and symlink escapes before writing. It saves the selection and adds only absent package declarations and scripts; it does not run a package manager. Selected Mantle packages use the running CLI's exact version. Missing selected packages produce an incomplete, nonzero result and an explicit install-and-rerun instruction. `--check` never writes, installs, prompts, or provisions. Generated code and assets remain CLI-owned; the editable frontend, host config, identity, secrets, handlers, and historical migrations are application-owned. A later SDK upgrade does not overwrite them. Clean builds remove only copied output.
-
-Cloudflare currently has a facade with transitive Admin/Auth/Web dependencies and mounts OAuth/MCP unconditionally. Host generation must use a lower-level composition for reduced selections or change that facade; omitting dependencies from a manifest does not prove route omission. Cloudflare D1 remains runtime-managed. ChatGPT Sites uses reviewed, append-only managed migrations with applied-state checks (owned by #1086). Neither host generator provisions resources or deploys.
-
-This decision restores a convenient default while keeping the sealed Manifest-to-RuntimePlan pipeline and user-owned application source. It does not reintroduce a remote Starter catalog or a `mantle create` command.
-
-## 2026-09-25 amendment — existing application integration
-
-The original implementation added `--adopt` to convert an existing authored
-application into the generated-project layout. This amendment removes that
-mode. Applications with their own host shape continue direct authoring;
-integrating Mantle is guided by the version-matched `integrate` consumer skill.
-The agent may embed selected capabilities, replace one part at a time, or
-build a fresh Mantle application and migrate frontend and data. The CLI owns
-only deterministic generation and its declared checks; it does not certify
-arbitrary user-owned host wiring. A saved generated project still reruns from
-its own configuration, with file ownership and migration safeguards intact.

package/docs/adr/0027-scheduled-procedure-triggers.md

@@ -1,31 +0,0 @@
-# ADR-0027: Scheduled Procedure Triggers
-
-**Status:** Accepted for 0.1.5 (#1087). Revises the closed Trigger-source grammar from ADR-0001 and the host-only cron guidance of #322.
-
-**Date:** 2026-09-25
-
-## Context
-
-The earlier contract kept cron outside the Manifest graph. That forced an application Worker to invoke a Procedure by name with its own caller context, leaving scheduling invisible to validation and the compiled plan. A portable declaration is needed without pretending that every host can register a cron event.
-
-## Decision
-
-`Trigger.spec.source` gains `kind: schedule`, a five-field Cloudflare UTC `cron` (weekday 1=Sunday), and optional `enabled` (default true). It targets one Procedure whose input accepts `{}` and requires no user or staff authorization. The compiled plan carries Trigger identity, expression, target, enabled state, and the required `cloudflare` host. No HTTP route or user identity is granted.
-
-Cloudflare's `scheduled` entry finds enabled plan entries with the exact incoming expression and invokes them in Trigger-name order through the existing Procedure pipeline, continuing after individual failures and reporting them together. The system context has null user and staff, no credential, and `ctx.schedule` with stable `${trigger}:${scheduledTime}` identity. The application registers exact expressions with Wrangler. Cloudflare Cron Triggers do not document automatic retries; handlers still use the identity for possible duplicate/manual replay. Other hosts reject enabled schedules rather than silently omit them.
-
-## Consequences
-
-The grammar and sealed plan version advance. Applications must rerun `mantle generate` after upgrading. A Procedure needing staff authorization cannot run from a schedule. Cron provisioning, retries, retention and exactly-once execution remain host/operator responsibilities; the runtime does not claim them.
-
-## Alternatives
-
-Keeping host-only calls would preserve the old grammar but fail static validation and omit the feature from introspection. A general background-job framework would add storage and scheduling responsibilities without a second host implementation.
-
-## How to apply
-
-Declare a schedule Trigger, export `worker.scheduled`, and register its expression in `wrangler.jsonc`. Use `ctx.schedule.id` to deduplicate writes. See [Trigger reference](../handbook/reference/trigger.md#schedule).
-
-## Implementation status
-
-Implemented in the 0.1.5 scheduled Procedure PR, with parser, linker, compiler, runtime and Cloudflare adapter tests.

package/docs/adr/0028-schema-ttl-expiry.md

@@ -1,33 +0,0 @@
-# ADR-0028: Logical Schema TTL before explicit physical cleanup
-
-**Status:** Accepted for 0.1.5 (#1088).
-
-**Date:** 2026-09-25
-
-## Context
-
-An application needs a portable expiry rule across D1 and Bun SQLite. A cron-only delete task cannot guarantee that readers stop seeing expired data if it runs late or fails. Applying a new policy to a populated table must not silently bulk-delete rows.
-
-## Decision
-
-`Schema.spec.ttl` names one top-level date-time field and a nonnegative `expireAfterSeconds`. At `timestamp + duration <= now`, semantic reads exclude the row. Missing, null and unparseable legacy dates never expire. Declarative Views include the same predicate. Native SQL Views that name a TTL Schema's table are rejected (SQL over other tables is unaffected), and shared caching of a TTL View is rejected. The compiled plan and introspection expose the policy. Public Cloudflare pages derived from TTL collections use `no-store` rather than shared caching.
-
-SQLite storage implements an optional bounded `ExpirySweeper`. A sweep previews by default; `delete: true` is required for physical removal. It returns counts and a cursor, selects at most 100 expired IDs in stable order, and rechecks expiry in one bounded delete statement. A failed page can be retried with the previous cursor. Ref Procedures can call the semantic capability, including from a scheduled Trigger. No host automatically invokes it.
-
-Physical TTL removal does not fire before/after entry lifecycle hooks. Expiry already changed logical visibility; cleanup reclaims storage rather than representing an editorial deletion. Consumers needing business actions at expiry must implement them in idempotent scheduled host code before calling the sweep.
-
-## Consequences
-
-Adding or shortening TTL changes read visibility immediately but never starts physical deletion. Owners preview counts and choose when to sweep; expired rows can still occupy unique indexes until removal. Other adapters must implement equivalent read filtering and a sweep or fail closed for TTL plans. The runtime does not promise an exact deletion time.
-
-## Alternatives
-
-Scheduler-driven deletion alone leaves a visibility gap. Implicit migration-time cleanup risks irreversible bulk deletion. Firing ordinary deletion hooks during storage reclamation would cause delayed, retry-sensitive business effects after the row was already logically gone.
-
-## How to apply
-
-Declare `ttl` on a Schema, use declarative Views, preview with `runtime.store.sweepExpired({ collection, delete: false })`, then explicitly request deletion page by page. See [Schema TTL](../handbook/reference/schema.md#ttl).
-
-## Implementation status
-
-Implemented in the 0.1.5 TTL PR for the SQLite family, with Bun and local D1 conformance checks.