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

package/docs/adr/0016-site-semantic-layer.md

@@ -1,70 +0,0 @@
-# ADR-0016: Site semantic layer — `AGENTS.md` + launch state
-
-## Status
-
-Superseded by [ADR-0021](0021-retire-starter-scaffolding.md) for 0.1.2 and
-later. The launch-state and provision-bundle rules below describe the legacy
-Starter/Landing flow; new applications are authored directly from the installed
-SDK's skill and handbook.
-
-## Decision
-
-Every agent-authored mantle project carries a small cross-tool entry file
-and deterministic launch state at fixed paths:
-
-| File | Audience | Size budget | Format |
-|---|---|---|---|
-| `AGENTS.md` | Any cross-tool agent harness (Codex / Cursor / Aider / Amp / Factory / Claude Code) | ~30 lines | Plain markdown |
-| `.mantle/launch-state.json` | Install/provision context captured by landing or direct CLI flags | Small JSON record | JSON |
-
-`AGENTS.md` answers "what is this and how do I run it." Launch state
-carries install-critical facts such as archetype, brand, description,
-locales, selected features, GitHub owner/admin login, starter ref, and
-repo target.
-
-The earlier `mantle/site.md` semantic/letter surface and `## welcome`
-5-card letter surface are suspended for the first-run path. Provisioning
-must not block on prose completion; a first deploy should be possible
-from deterministic scaffold state.
-
-## Placeholder macros
-
-Mantle landing substitutes these across provision-bundle `*.template`
-files in a single pass:
-
-| Macro | Source | Example |
-|---|---|---|
-| `{{ARCHETYPE}}` | CLI flag | `presence` |
-| `{{BRAND}}` | CLI flag | `Lab Cafe` |
-| `{{DESCRIPTION}}` | CLI flag | `Coffee + research notes from Taipei.` |
-| `{{LOCALES}}` | CLI flag (JSON array) | `["zh-TW","en"]` |
-| `{{CANONICAL_LOCALE}}` | first locale | `zh-TW` |
-| `{{SITE_URL}}` | placeholder until provision | `https://example.com` |
-| `{{GITHUB_OWNER}}` | CLI flag | `phsu` |
-| `{{INSTALL_TIMESTAMP}}` | ISO 8601 of install run | `2026-05-12T14:03:00Z` |
-| `{{INSTALL_SUMMARY}}` | CLI flag | `bootstrapped publication site for Lab Cafe in zh-TW/en` |
-
-New macros must be added here, to `mantle-starters` bundle templates,
-and to the landing substitution pass.
-
-## Update rules
-
-- **Mantle on return**: read `AGENTS.md`, `.mantle/launch-state.json`,
-  and repo-local skills before changing code.
-- **provision on deploy**: rewrite `AGENTS.md` `Public site:`
-  placeholder → real Workers URL. Single commit at end of provision.
-- **No hidden letter gate.** Prose may be added later, but first deploy
-  only depends on deterministic scaffold state and provider configuration.
-
-## Cross-tool compatibility
-
-`AGENTS.md` lives at repo root because that is where the AGENTS.md ecosystem (`agents.md`) looks. `.mantle/` is for Mantle-owned non-secret state.
-
-## Implementation
-
-- Templates: `mantle-starters/blank/AGENTS.md.template` and
-  generated `.mantle/*.template` bundle files.
-- Substitution: Mantle landing provision-bundle substitution.
-- Install handoff: `skills/install/SKILL.md` describes how agents continue from the landing-provisioned repo.
-- Provision update: `docs/skills/provision/SKILL.md` describes the `AGENTS.md` public-site rewrite after deploy.
-- Type overlays are applied while building `provision-bundles/<type>.json`; generated repos should not need a second overlay step.

package/docs/adr/0017-media-multi-variant-agent-side-optimization.md

@@ -1,181 +0,0 @@
-# ADR-0017: Multi-variant media assets, agent-side optimization
-
-**Status:** Accepted (v0.1.0-alpha.14)
-**Issue:** [#272](https://github.com/aotter/mantle/issues/272)
-
-## Context
-
-The pre-#272 media subsystem treated each upload as one artifact: one
-`create_media_upload` returned one presigned PUT URL, one
-`commit_media_upload` returned one `MediaAsset` with one `publicUrl`,
-and entry data fields embedded that URL directly. Two consumer pains
-surfaced in `toa-shop`:
-
-1. **URL embedding ties entries to bucket/CDN identity.** Moving
-   buckets, switching custom domains, or auditing "where is asset X
-   used" all require rewriting entries — there's no logical handle.
-2. **One artifact = no `<picture>`.** Modern formats (avif, webp)
-   cut bytes by 30–70 % on the storefront photos toa-shop measured,
-   but the SDK had no way to deliver three formats from one logical
-   asset. Consumers would have had to pre-encode three formats,
-   upload three times, and store three URLs per image position —
-   awkward for the MCP agent and impossible to express in the
-   admin upload widget.
-
-## Decision
-
-Ship the corrected shape in one breaking change. Pre-v0.1 means there
-is no production consumer to migrate; an intermediate "one URL, three
-variants behind it" shape would be incoherent (renderer can't get the
-variants without refetching by id) and not worth the
-backwards-compat work.
-
-### 1. `MediaAsset.variants[]` is required
-
-Every committed asset carries one or more variants. Renderers consume
-the array directly and emit `<picture>`. There is no top-level
-`publicUrl` / `storageKey` / `mimeType` / `byteSize` — the single-URL
-shape is what we're leaving behind.
-
-### 2. Optimization runs **agent-side**, not on the Worker
-
-workerd has no usable image-processing stack (no sharp / libvips —
-WASM ports are large and slow). Rather than spin up a separate
-transform Worker or pay for Cloudflare Images, the SDK shifts the
-encode step to where it already runs in a real Node-like runtime:
-
-- Scaffolders, ops scripts, the admin SPA's local helper, and MCP
-  agents (Claude Code, etc.) all execute in environments where
-  `sharp` works.
-- The MCP client or operator tooling runs the agent-side image
-  processor: take a source file, produce the format set, call
-  `create_media_upload`, upload every variant, and call
-  `commit_media_upload`.
-- The Worker only **enforces policy**: required mime set, per-mime
-  byte caps, suspicious-shape heuristic (modern format must not be
-  larger than its fallback). It never decodes or re-encodes.
-
-The Worker's contract: *received bytes are already optimized, or I
-refuse them*. The agent's contract: *I optimize before uploading, in
-a runtime that can run sharp*.
-
-### 3. `siteDefaults.media.purposes` is a policy object
-
-Replace the `string[]` shape with `MediaPurposePolicy[]`:
-
-```ts
-purposes: [
-  {
-    name: "post-cover",
-    required: ["image/avif", "image/webp", "image/jpeg"],
-    maxBytes: {
-      "image/avif": 200_000,
-      "image/webp": 300_000,
-      "image/jpeg": 500_000,
-    },
-  },
-]
-```
-
-Each purpose carries its own required mime set + per-mime byte cap.
-The runtime emits the policy summary into `create_media_upload`'s
-tool description so MCP agents see the contract via `tools/list`
-without a separate round trip.
-
-### 4. Asset-id refs in entries, `media_assets` table for resolution
-
-Entries hold `MediaAsset.id` strings, not URLs:
-
-```yaml
-coverAssetId:
-  type: string
-  x-mantle-ref: media_assets
-  x-mcp-hint: media-image
-```
-
-`x-mantle-ref` and `x-mcp-hint` are existing v0.1 grammar
-extensions — no new manifest keys. The runtime contract changes
-(these fields now hold ids instead of URLs), but the grammar surface
-does not.
-
-A new `media_assets` D1 table persists committed assets:
-
-```sql
-CREATE TABLE media_assets (
-  id          TEXT PRIMARY KEY,
-  created_at  INTEGER NOT NULL,
-  owner_id    TEXT,
-  alt         TEXT,
-  caption     TEXT,
-  variants    TEXT NOT NULL,    -- JSON
-  metadata    TEXT
-);
-```
-
-New port `MediaAssetRepository` (findById / findManyByIds / save /
-delete); new runtime helper `runtime.media.resolve(id)` and
-`resolveMany(ids)` for render-time materialisation. The renderer
-batches a render-pass's worth of references in one DB round trip.
-
-### 5. Adapter stays storage-key-shaped
-
-`MediaStorage` port methods (`getPublicUrl`, `deleteObject`) take
-storage keys — the asset-id → storage-key translation happens in the
-use case layer via the repository. The R2 adapter:
-
-- Mints storage keys under `<purpose>/<uploadGroupId>/<role>.<ext>`
-  so every variant of one logical asset lives under a shared prefix.
-- HEAD-verifies every variant before commit; any failure rejects
-  the whole bundle (all-or-nothing).
-- Enforces the primary-role invariant the renderer depends on.
-- Orphan sweep (#254) can list a prefix to find partially-committed
-  bundles.
-
-## Consequences
-
-### Positive
-
-- One coherent shape ships at once — no migration debt for the
-  "intermediate URL-in-entry world".
-- Worker stays workerd-clean. No new infrastructure component
-  (no sharp Worker, no Cloudflare Images dependency, no Queue +
-  background worker).
-- MCP agents see the full policy via `tools/list`; the type system
-  and the diagnostic catalog catch most misuses before bytes flow.
-- Asset-id refs decouple entries from CDN identity; the orphan
-  sweeper, "where used", and asset metadata editing all become
-  cheap follow-ups.
-
-### Negative / accepted
-
-- Agent-side optimization shifts compute to the uploader. Browser-
-  side admin uploads (drag-drop in the SPA) would need to either
-  invoke a local helper subprocess (Tauri / Electron) or call the
-  scaffolder's helper indirectly — UI work tracked separately.
-- Every starter using media needs to migrate schemas from URL
-  fields to `*AssetId` fields + adopt the resolver in their renderer.
-- `siteDefaults.media.purposes` is a breaking shape change. Pre-v0.1
-  cadence allows this; downstream sweeps coordinate via the existing
-  fix-forward release process.
-
-## Why not the alternatives
-
-- **CF Images binding**: vendor lock-in + per-image billing; rejected
-  because the agent runtime can already produce the variants without
-  introducing a new commercial dependency.
-- **Separate transform Worker (with container running sharp)**: real
-  infrastructure complexity (queue + worker + observability), much
-  larger blast radius than a CLI helper.
-- **Variant URLs stored inline in the entry**: re-introduces the URL-
-  embedding problem the asset-id refs solve. Was the original
-  "phase 1" plan; rejected after recognising the intermediate state
-  is incoherent.
-
-## References
-
-- `packages/mantle-runtime/src/domain/port/MediaStorage.ts`
-- `packages/mantle-runtime/src/domain/port/MediaAssetRepository.ts`
-- `packages/mantle-runtime/src/infrastructure/persistence/DatabaseMediaAssetRepository.ts`
-- `packages/mantle-spec/src/domain/model/SiteConfig.ts` (MediaPurposePolicy)
-- `packages/adapters/cloudflare/src/bindings/R2MediaStorage.ts`
-- MCP client / operator-side image processing tools

package/docs/adr/0018-core-starters-repository-boundary.md

@@ -1,179 +0,0 @@
-# ADR-0018: Keep Core and public starters in separate repositories
-
-> Superseded for 0.1.2 by [ADR-0021](0021-retire-starter-scaffolding.md).
-> The contract below is retained as alpha.17 history, not current launch/release guidance.
-
-**Status:** Superseded by ADR-0021 for 0.1.2 and later. Historical alpha.17 decision only.
-
-**Date:** 2026-08-02
-
-**Related:** [#542](https://github.com/aotter/mantle/issues/542),
-[#191](https://github.com/aotter/mantle/issues/191),
-[#97](https://github.com/aotter/mantle/issues/97),
-[#99](https://github.com/aotter/mantle/issues/99)
-
-## Context
-
-Core and the public starter source currently form a producer-consumer
-boundary:
-
-```text
-Core (SDK producer)
-  -> published npm contract
-mantle-starters (external consumer and bundle producer)
-  -> immutable provision bundle
-mantle-landing (provisioner)   Core CLI (`mantle create`)
-```
-
-> **Amended 2026-08-19 (#699).** The chain above is no longer linear. Core's
-> umbrella CLI is now also a consumer of the immutable bundle: `mantle create`
-> resolves the official `v${packageVersion}` starter tag, renders it through
-> the environment-neutral module Core owns, and writes a local project. Core
-> is therefore both the upstream producer of the npm contract and a downstream
-> consumer of the release train it starts.
->
-> This does not move starter content into Core, so the decision below stands:
-> starters still author the bundles and still validate the published SDK as an
-> external consumer. What changed is the supporting argument. Two consequences
-> are worth stating rather than rediscovering:
->
-> - **The published-consumer guarantee is now proven twice.** `mantle create`
->   materializes a project that installs the published package, so a break in
->   the npm contract fails in Core's own release smoke as well as in starter CI.
-> - **Reconsideration input 1 is being answered.** #699 replaces the release
->   order so a candidate is published under a temporary dist-tag, validated
->   against the exact packed artifacts, and only then promoted. That was listed
->   below as an unresolved prerequisite for any future merge; when it lands,
->   this ADR should record it as resolved rather than pending.
-
-The repositories were originally split because premium starters needed a
-private ACL. That reason does not determine where public starters must live,
-and the private premium repository remains a stub. A later decision, #191,
-made Core, starters, and landing mirror the same version and connected them
-with an automated release fanout.
-
-The fanout accumulated real costs: release-only commits, `main`/`develop`
-backports, fallback tag creation, commit-subject detection, cross-repository
-credentials, and a Core-skill drift check that can skip when the sibling
-checkout is unavailable. Issue #542 therefore proposed moving public starters
-back into this repository.
-
-That operational pain does not by itself prove source cohesion. The separate
-starter repository now provides a useful invariant that did not exist in the
-original rationale: the canonical generated-site fixture consumes published
-SDK packages and cannot silently link Core workspace packages.
-
-A heuristic review of merged PRs from 2026-06-03 through 2026-08-02 also did
-not show sustained majority co-change. After excluding release, promotion,
-backport, and dependency PRs, 9 of 64 Core PRs explicitly referenced starters,
-and 13 of 79 starter PRs explicitly referenced Core. Explicit references
-undercount forced adaptations, so these numbers are directional rather than a
-permanent threshold. They do show that release noise is not a sufficient proxy
-for product coupling.
-
-## Decision
-
-Keep `aotter/mantle` and `aotter/mantle-starters` separate for now.
-
-The boundary is a release-contract boundary, not an ACL boundary:
-
-- Core produces versioned npm artifacts.
-- Starters validate those artifacts as an external consumer and produce
-  immutable provision bundles.
-- Landing consumes the released bundle and provisions end-user repositories.
-
-Do not merge or archive the starters repository until the following no-regret
-work has landed:
-
-1. **Pre-publish downstream harness.** Validate starters against the exact SDK
-   tarballs that would be published, preferably through an ephemeral registry,
-   before a release tag exists.
-2. **Fail-closed Core-skill drift check.** Compare starter-vendored skills with
-   the installed SDK package in normal starter CI; never depend on an optional
-   sibling checkout.
-3. **One release controller.** Replace the bump/tag/dispatch/fallback chain and
-   remove avoidable `main`/`develop` backport noise without moving source code.
-4. **Repository-agnostic updates.** Make generated sites resolve a configured
-   bundle base URL instead of hard-coding `aotter/mantle-starters`.
-
-Issue #542 remains the work and reconsideration tracker. This ADR is the
-canonical explanation of the repository-boundary decision. The current
-mechanics belong in `docs/release-process.md`; implementation details should
-not be duplicated here.
-
-## Reconsideration triggers
-
-Re-evaluate a monorepo after the four items above land if either signal persists:
-
-- the release path still needs at least two special-case workaround fixes per
-  quarter, such as fallback tags, backports, or commit-message detectors; or
-- SDK contract changes require same-release starter adaptations more often than
-  roughly once per month, making atomic cross-repository work a recurring cost.
-
-A future merge proposal must also resolve:
-
-- how the same tagged starter version is validated against the exact package
-  artifacts before npm publication;
-- a real last-legacy-version to first-new-location update for an existing site;
-- landing dispatch and release credentials, which do not disappear merely by
-  moving starters;
-- premium-repository direction;
-- nested pnpm/Dependabot/lockfile CI, licensing, open issues, and repository
-  history migration.
-
-These are decision inputs, not a disguised permanent prohibition. A monorepo
-is appropriate if its atomicity benefit remains material after the release
-machinery is simplified.
-
-## Consequences
-
-### Positive
-
-- The published-package consumer guarantee remains structural rather than
-  simulated by workspace exclusions and realpath assertions.
-- The four improvements reduce risk and complexity under either eventual
-  repository shape.
-- Existing generated-site update URLs remain valid while the updater contract
-  is made portable.
-- Starter-only product work keeps an independent source boundary.
-
-### Negative
-
-- Cross-repository changes cannot land in one atomic PR.
-- A release event still crosses repository boundaries and needs a narrowly
-  scoped credential or GitHub App.
-- Release noise remains until the controller and branch flow are simplified.
-- Core-skill drift remains possible until the fail-closed check lands.
-
-## Alternatives
-
-### Merge immediately
-
-Rejected. The proposed release order cannot both start from an immutable tag
-and regenerate a same-version registry-backed starter lockfile after publish.
-Existing generated sites also cannot cross the hard-coded repository boundary
-without a bridge.
-
-### Keep the repositories separate without simplifying the release path
-
-Rejected. The current fanout complexity and silent skill-check escape hatch are
-real defects; retaining the boundary does not justify retaining those defects.
-
-### Declare that the repositories must never merge
-
-Rejected. The current boundary is valuable, but it is replaceable with explicit
-and tested invariants if future co-change and release evidence justify the cost.
-
-## How to apply
-
-- Treat starters as a downstream SDK consumer in CI and release design.
-- Do not add starter projects to the Core pnpm workspace as a shortcut for
-  cross-contract validation.
-- Track the four prerequisite changes and future merge evidence in #542.
-- Any future repository-move proposal must supersede this ADR and #191
-  explicitly, with the transition tests listed above.
-
-## Implementation status
-
-The repository-boundary decision is active. The four no-regret improvements are
-tracked from #542 and may land independently; none requires a repository move.

package/docs/adr/0019-sealed-manifest-runtime-pipeline.md

@@ -1,244 +0,0 @@
-# ADR-0019: Seal the manifest-to-runtime pipeline
-
-**Status:** Accepted
-
-**Date:** 2026-08-16; last amended 2026-09-01
-
-**Related:** [#656](https://github.com/aotter/mantle/issues/656),
-[#662](https://github.com/aotter/mantle/issues/662),
-[#759](https://github.com/aotter/mantle/issues/759),
-[#760](https://github.com/aotter/mantle/issues/760),
-[#546](https://github.com/aotter/mantle/issues/546), ADR-0008, ADR-0009,
-ADR-0011, ADR-0018
-
-## Context
-
-Mantle already has an adapter-neutral runtime package and structured
-diagnostics, but its real execution boundary is still the complete Cloudflare
-site product. Authored YAML is parsed into an ordinary `Manifest[]`; validation,
-defaulting, lookup construction, boot checks, SQL compilation, storage setup,
-public rendering, and Admin helpers then overlap across spec, runtime, and the
-Cloudflare adapter.
-
-That overlap creates two portability failures:
-
-1. A downstream caller can bypass an earlier stage and reinterpret raw
-   manifests, so a rule or default can have more than one owner.
-2. Embedding the runtime also selects SQL-shaped storage, public Web behavior,
-   Admin assets, and Cloudflare-oriented boot conventions.
-
-The product needs one embeddable Core that can be called directly by an
-existing application, with Web, Admin, and platform integrations selected
-downstream. The migration cannot introduce a permanent `v2` pipeline beside
-the current one: every compatibility path must delegate forward and be deleted
-within the same milestone.
-
-## Decision
-
-### One sealed pipeline
-
-Mantle has one supported semantic path:
-
-```text
-ManifestSourceSet
-  -> parse + normalize
-  -> ParsedManifestSet
-  -> link
-  -> LinkedManifestSet
-  -> compile
-  -> RuntimePlan
-  -> prepare deployment
-  -> PreparedRevision
-  -> bind runtime
-  -> MantleRuntime
-```
-
-Decode may remain an internal parser step. The public contract starts with
-caller-supplied sources and ends with a programmatic runtime. A failed stage
-does not produce a usable value for the next stage.
-
-Parse, link, and compile are pure and deterministic. Their sealed outputs may
-be constructed only by their owning package, apart from explicit test fixture
-helpers. Source locations remain authored metadata; they do not affect the
-semantic fingerprint.
-
-### One owner per invariant
-
-| Stage | Owns | Must not own |
-|---|---|---|
-| Parse + normalize | YAML syntax/alias limits, closed four-atom shape, primitive and atom-local rules, behavior-affecting defaults, source metadata | Cross-atom references, handlers, storage, optional routes |
-| Link | Duplicate symbols, cross-atom references, guard graphs, translations, manifest-owned route/tool collisions | I/O, selected modules, handler availability |
-| Compile | Immutable lookup records, authorization plans, Trigger indices, Procedure descriptors, logical View plans, semantic fingerprint | Connections, repositories, handlers, requests, templates, assets |
-| Prepare | Selected storage migrations/native Schema tables and indexes/prepared Views, handler availability, selected capability/route checks, readiness revision | YAML interpretation or request execution |
-| Bind/invoke | Semantic ports, handler dispatch, parameter binding, centralized authorization, content/View/Procedure/Trigger/lifecycle operations | DDL, route mounting, assets, HTTP/session/cache policy |
-| Optional modules/adapters | Web/Admin composition and request/session/cache/platform translation | Re-parsing, re-linking, or a second authorization/runtime stack |
-
-The current-to-target rule ledger and evidence are maintained in
-[`docs/sealed-pipeline-ownership.md`](https://github.com/aotter/mantle/blob/main/docs/sealed-pipeline-ownership.md).
-
-### Core and optional products
-
-`@aotter/mantle-spec` owns source, parse, normalize, link, introspection, and
-manifest-derived code generation. It has no runtime or platform dependency.
-
-`@aotter/mantle-runtime` owns `RuntimePlan`, preparation contracts, semantic
-storage ports, and `MantleRuntime`. The portable runtime input is prepared
-semantic storage, not `DatabaseDriver`. It has no Web, Admin, Cloudflare, Bun,
-or Vercel dependency.
-
-`@aotter/mantle-web` is optional and owns the official public HTML, Markdown,
-`llms.txt`, sitemap, SEO, preview, template, and public-path composition.
-Applications still own their router, URLs, navigation, and design. Platform
-adapters own HTTP mounting and cache behavior.
-
-`@aotter/mantle-admin` is optional and owns Admin API/application
-orchestration and its asset contract. `@aotter/mantle-admin-ui` remains the UI
-artifact. Core supplies content operations and authorization but does not
-serve the UI or reserve Admin paths when the module is absent.
-
-Cloudflare, Bun, and Vercel packages bind platform storage, lifecycle,
-request/session, cache, and asset concerns. They may expose convenience
-facades, but those facades compose the same Core and selected modules.
-
-### Storage and Views
-
-Preparation accepts a selected storage adapter and produces semantic ports,
-including existing content repositories/readers and a `ViewQueryExecutor`.
-Concrete D1/SQLite drivers and SQL repositories remain implementation details.
-An existing application may either pass its already-owned database/client to
-an official adapter or implement the semantic ports over its own tables.
-
-`@aotter/mantle-indexeddb` is the optional browser storage implementation of
-the same semantic ports. One adapter exclusively owns one application-selected
-database name, uses structured-clone persistence and IndexedDB transaction
-completion as its write boundary, and exposes database deletion only on the
-concrete adapter. Runtime Core gains no browser global, browser facade,
-namespace, persistence request, reactive binding, or synchronization port.
-Declarative browser Views use a documented O(n) scan until measured use proves
-an IndexedDB query planner necessary.
-
-Declarative Views compile to logical plans once. Storage preparation lowers
-those plans to native queries. The v0.1 `View.spec.sql` form remains explicitly
-SQLite-only and is rejected by unsupported storage during preparation; Mantle
-does not guess a translation and does not add a universal query driver.
-
-### Callable capability projection
-
-Optional callable transports consume `projectCallableCapabilities(RuntimePlan)`.
-Each Procedure capability retains the owning MCP Trigger name while its
-input/output/title/description remain owned by the target Procedure; View
-capabilities retain their read-only View contract. Discovery and invocation use
-the same projected descriptor, and invocation routes through `invokeTrigger`
-rather than bypassing Trigger identity with a direct Procedure call. Hosts may
-select a surface and bind transport or browser lifecycle, but do not rescan raw
-manifests or maintain a second registry.
-
-`@aotter/mantle-web/webmcp` is an opt-in host binding over that projection. It
-feature-detects `document.modelContext`, adds public capabilities without
-replacing existing host tools, and uses the registration `AbortSignal` only for
-teardown. A browser-local host supplies the projected capabilities and a
-late-bound invoker; Procedure calls retain their explicit MCP Trigger identity.
-For a server-backed host, the Cloudflare adapter publishes a minimal public View
-catalog at `GET /api/views`; the binding validates that wire catalog and invokes
-the existing same-origin `GET /api/views/<name>` route. The catalog contains no
-raw manifest or staff capability.
-Invocation hooks may drive host UI effects but cannot replace Runtime
-validation, authorization, dispatch, or domain results. The binding does not
-add browser globals to Runtime Core, expose staff capabilities, or introduce a
-second manifest/runtime path.
-
-### Naming and code generation
-
-This section records the original codegen decision. The current generated API
-uses a sealed `plan` and wire-keyed `Schemas`, `Views`, and `Store` type maps;
-see the [typed queries guide](../handbook/guides/typed-queries.md).
-
-The Core execution unit is `MantleRuntime`, not a site. Optional TypeScript
-generation is a pure projection of linked/compiled semantics. It exposes
-`bindMantle(runtime)` plus an eager `createMantle()` convenience that delegates
-one preparation attempt to Runtime. Generated code never caches, retries,
-mounts routes, or owns host lifecycle. The bound API retains its raw `runtime`
-so typed projection does not hide lower-level Core capabilities. It emits
-deterministic lower-camel identifiers while preserving manifest wire names
-internally. Identifier collisions are errors.
-
-Code generation is never required by the runtime and never copies Web or Admin
-assets. Dynamic/string-based calls remain the escape hatch for JavaScript and
-runtime-defined consumers.
-
-### Migration rule
-
-Issues #663 through #673 move ownership in pipeline order. At every step:
-
-- existing callers may use a temporary wrapper only if it delegates to the new
-  owner;
-- no rule, default, query compiler, authorization evaluator, or router is
-  implemented twice;
-- the old owner and its obsolete tests are deleted when its last caller moves;
-- exact packed consumers, not workspace links, are the final compatibility
-  gate.
-
-Breaking API changes from the `v0.1.0-alpha.7` contract are allowed in the
-0.1.2 milestone. Migration notes should keep old projects mechanically
-adaptable, but downward compatibility is not a reason to retain a second stack.
-
-## Consequences
-
-### Positive
-
-- Human and agent authors get one deterministic path and one diagnostic owner.
-- Existing applications can embed Core without surrendering process, router,
-  database, or transaction ownership.
-- Web, Admin, and each platform can evolve without entering Core.
-- Performance work happens once per semantic revision instead of per request.
-- Compatibility code has a defined deletion point.
-
-### Negative
-
-- 0.1.2 intentionally breaks parts of the alpha.7 API.
-- Cloudflare's current convenience facade must be decomposed and then
-  reassembled from optional modules.
-- Downstream projects must update generated imports and runtime construction.
-- Exact consumer tests are required across more than one platform.
-
-## Alternatives
-
-### Keep `Manifest[]` as the shared contract
-
-Rejected. It cannot prove that defaults, references, and plans were evaluated
-once, and it lets every downstream package rebuild semantic state.
-
-### Generalize `DatabaseDriver` for every database
-
-Rejected. Its SQL/D1 shape is not a useful MongoDB or application-domain
-contract. Existing semantic repository ports are the smaller portable seam.
-
-### Add a plugin/provider framework
-
-Rejected. Ordinary package dependencies, exported mount functions, and narrow
-ports cover the known compositions. A registry would add a second architecture
-before a use case requires it.
-
-### Build a parallel Core v2 and migrate later
-
-Rejected. It duplicates rules and makes deletion optional. The migration is
-ordered specifically so each new owner replaces the old owner in place.
-
-## How to apply
-
-- Start a pipeline change at the current owner listed in the rule ledger.
-- Add one check at the new owner, route every caller through it, then delete the
-  old implementation and obsolete tests.
-- Reject runtime imports of raw manifests, Web/Admin packages, or platform
-  primitives once their migration issue closes.
-- Prefer current ports and native platform APIs; add a package only for a real
-  dependency/runtime boundary.
-- PR descriptions for #656 must state old owner, new owner, evidence, deleted
-  code, and any diagnostic timing change.
-
-## Implementation status
-
-Issue #662 records the current behavior, ownership ledger, consumer corpus, and
-performance baseline. Issues #663 through #674 execute the migration and final
-repository cleanup. The ADR is complete only when #673 removes every temporary
-compatibility path; #674 then updates contributor guidance to the final tree.