@aotter/mantle 0.1.5-alpha.1 → 0.2.0-alpha.1

package/docs/handbook/guides/agent-setup.md

@@ -1,97 +1,82 @@
 ---
-description: Trace what npx skills add installs, hand off to the pinned SDK, project version-matched skills and diagnose missing or stale instructions.
+description: Install the Mantle agent plugin or its one skill, hand off to the installed package's own docs, and diagnose missing or stale instructions.
 ---
 # Install and verify agent instructions
 
-There are two separate installations: an agent's bootstrap skill and the
-application's SDK. Installing one does not install the other.
+Two separate things are installed: the agent's `mantle` skill and the
+application's `@aotter/mantle` package. Installing one does not install the
+other, and the installed package is always the authority for the version it
+carries.
 
-## 1. Install the bootstrap skill
+## 1. Install the `mantle` skill
 
-```sh
-npx skills add aotter/mantle
+The Mantle plugin carries one skill, `mantle`, its helper script, and the
+Mantle Cloud MCP connection (`https://cloud.mantle.tools/mcp`).
+
+```bash
+# Claude Code: two separate prompts
+/plugin marketplace add aotter/mantle
+/plugin install mantle@mantle
+
+# Codex
+codex plugin marketplace add aotter/mantle
+codex plugin add mantle@mantle
 ```
 
-The installer selects the repository's `mantle` skill. Read its printed
-installation path. In a project-local Codex installation that is
-`.agents/skills/mantle/SKILL.md`, not `skills/install/SKILL.md` (the latter is
-its source-repository path). Other agent selections and global installation
-can use different locations.
+Cursor and GitHub Copilot read the plugin manifests from the repository.
+Without a plugin host, install the skill alone:
 
-The command installs the selected brief; it does not materialize a Mantle
-application, install `@aotter/mantle`, or copy `docs/`. The unqualified GitHub
-source follows its default branch, not necessarily `develop` or the npm
-version you intend to use. The skills installer's lock identifies the source
-skill; it is not the application's dependency lockfile.
+```sh
+npx skills add aotter/mantle
+```
 
-## 2. Select the SDK version, then read its own instructions
+A skill-only install has no Cloud MCP connection; add one by hand if you need
+it. Either way, read the path the installer prints (for project-local Codex,
+`.agents/skills/mantle/SKILL.md`). The skill installs no SDK, creates no
+project and copies no handbook.
 
-Use the version the project already pins, or resolve the requested npm channel
-once and pin every selected `@aotter/mantle*` dependency to the same exact
-version. `latest` and `alpha` can describe different capabilities. Resolve only
-requirements the user has not provided: host, storage, public API/HTML, and
-whether staff need Admin. Follow the bootstrap skill to install the selected
-packages locally.
-No matching `mantle-starters` tag or bundle is needed to create a project.
+## 2. Install the SDK, then read its own docs
 
-Then read:
+Use the version the project already pins. For a new project, choose a 0.2.x
+version with `npm view @aotter/mantle dist-tags` and install it with an exact
+version; every `@aotter/mantle*` package stays at that same version. Then
+read, from the application:
 
 ```text
-node_modules/@aotter/mantle/skills/install/SKILL.md
+node_modules/@aotter/mantle/README.md
 node_modules/@aotter/mantle/docs/handbook/start/overview.md
 node_modules/@aotter/mantle/docs/handbook/reference/features.md
+node_modules/@aotter/mantle/docs/skills/<workflow>/SKILL.md
 ```
 
-These files are in the npm tarball. They are the version-matched authority,
-including when the bootstrap skill came from a different Git ref. Every
-`docs/...` path in the skill resolves under the installed package, not under
-`.agents/skills/mantle/`. Keep using that SDK's docs for host examples and CLI
-behavior. No local `mantle` binary is available before package installation.
+These ship in the npm tarball and match the installed code. Prefer them over
+the skill's GitHub copy and over any online handbook.
 
-## 3. Project the ongoing workflows
-
-From the application root, after installing the SDK:
-
-```sh
-pnpm exec mantle --help
-pnpm exec mantle skills
-pnpm exec mantle skills --check
-```
-
-| Artifact | What you get |
+| Package skill | Read it when |
 |---|---|
-| `.agents/skills/mantle-{develop,plugin,theme,update}/SKILL.md` | The installed package's four project-scoped workflows. |
-| `.claude/skills/mantle-{develop,plugin,theme,update}/SKILL.md` | Identical bytes for Claude compatibility. |
-| `node_modules/@aotter/mantle/skills/` | All eight shipped skills, including opt-in `mantle`, `integrate`, `provision` and `media-gc`. |
-| `node_modules/@aotter/mantle/docs/` | Handbook and examples matched to the package. |
+| `docs/skills/develop/SKILL.md` | changing manifests, handlers, the service or its surfaces |
+| `docs/skills/integrate/SKILL.md` | adding Mantle to an existing application |
+| `docs/skills/update/SKILL.md` | upgrading `@aotter/mantle`, including from 0.1.x |
+| `docs/skills/provision/SKILL.md` | deploying, with production sign-in |
+| `docs/skills/media-gc/SKILL.md` | auditing or removing stale R2 uploads |
+
+0.2.0 has no `mantle skills` command: nothing is copied into the project.
+An agent reads these files from `node_modules` when the task calls for them.
 
-`mantle skills` overwrites these four generated projections. Keep project-specific
-instructions elsewhere. `--check` does not write: exit 0 means they match,
-1 means missing/stale projections, and 2 means a command/package error.
-`mantle generate` does not project skills. Projection does not remove an older
-bootstrap `install` or legacy `.agent/skills` copy; use the version-matched
-project skills for ongoing work.
+## 3. Verify the application
 
-## 4. Complete and verify the application
+Installing instructions proves only that they were copied. Prove the service:
 
-Follow a [tutorial](../start/overview.md#start-with-your-integration), then run
-its generation, validation, TypeScript checks and actual local route probes.
-Successful skill installation proves only that the instructions were copied.
-It does not prove a server, login, Admin assets or MCP connection works.
+1. `mantle generate` and `mantle generate --check` exit 0.
+2. The project typechecks against `.mantle/generated/mantle.ts`.
+3. `wrangler dev` (or, on Bun, `bun src/index.ts`) starts, and the routes you depend on answer: a REST View, an
+   HTTP Trigger, `/mcp` `tools/list`, and with identity `mantle` a sign-in and
+   `GET /admin/api/me`.
 
 | Symptom | Cause and next step |
 |---|---|
-| `skills/install/SKILL.md` is missing | That is source provenance. Read the installer's destination instead. |
-| `docs/...` is missing after `skills add` | The skill does not carry the handbook. Install the pinned SDK and read its embedded docs. |
-| `mantle` is missing | Install local `@aotter/mantle`; run its binary through the project package manager. |
-| `MANIFEST_ROOT_NOT_FOUND` | Check the installed CLI and saved project selection. New generated projects may start with an empty manifest set; legacy compile mode still needs the configured source. |
-| `mantle skills --check` exits 1 | Run `mantle skills`, then read the refreshed project skill. |
-| No projected integrate/provision/media-gc skill | These are intentionally opt-in. Read their installed package files when the task calls for them. |
-| A documented feature fails on an older release | Use that release's docs or explicitly upgrade; changing a skill does not change Runtime. |
-
-## Source
-
-- [Bootstrap install skill](../../../skills/install/SKILL.md)
-- [Projection implementation](../../../packages/mantle/src/cli/skills.ts)
-- [Package file list](../../../packages/mantle/package.json)
-- [Package docs and skills copying](../../../scripts/sync-package-docs.mjs)
+| `docs/...` is missing after installing the skill | The skill carries no docs. Install the SDK and read `node_modules/@aotter/mantle/docs/`. |
+| `mantle` is not found | Install `@aotter/mantle` locally and run it through the package manager (`pnpm exec mantle`). |
+| `mantle skills` is unknown | It is 0.1.x. Follow the installed 0.2.x docs. |
+| A v1 manifest or a `version: 1` config fails | The project is on 0.1.x. Follow `docs/upgrade-0.1-to-0.2.md`. |
+| A documented feature is missing | The installed version is older than the docs you read. Read its own docs, or upgrade deliberately. |

package/docs/handbook/guides/typed-queries.md

@@ -1,26 +1,34 @@
 ---
-description: Generate and call typed Views, including internal-only queries, and choose indexed entry readers without confusing them with authorized public reads.
+description: Read and write through the typed Store from handlers and service code, call named Views, and choose between ctx.store, runtime.store and runtime.store.as(caller).
 ---
 # Query from TypeScript
 
-Use a **View** when a read needs declared params, projection, pagination or
-`requires` authorization. Use an **entry reader** for trusted host code that
-needs stored entries by a data field. Both are exposed by generated bindings;
-only the View executes the declared View authorization contract.
+Handler and service code reach Mantle-owned rows only through Store. The
+generated `.mantle/generated/mantle.ts` types it over your Schemas and Views:
+`ctx.store` in a `MantleHandlers` handler is its `CallerStore`, while
+`runtime.store` is the untyped `MantleStore` until you cast it to the
+generated `Store`.
 
-## Declare an internal query
+| Store | Where | Scope |
+|---|---|---|
+| `ctx.store` | inside a `ref` handler | bound to the invocation's caller. A guard or a before hook gets a read-only one |
+| `runtime.store.as(caller)` | service code that has resolved a caller | that caller |
+| `runtime.store` | trusted host code (imports, maintenance) | none: no caller scope. TTL still applies |
+
+Each one applies TTL visibility, and published-only on public Views. Only
+`runtime.store` skips caller scope, so never hand it a request's input
+unchecked.
 
-Save this complete source as `manifests/tickets.yaml`. The operational Schema
-uses a business status field distinct from Mantle's native `status`.
+## Declare an internal View
 
 ```yaml
-apiVersion: cms.mantle.aotter.net/v1
+apiVersion: cms.mantle.aotter.net/v2
 kind: Schema
-metadata:
-  name: tickets
+metadata: { name: tickets }
 spec:
   title: Tickets
   lifecycle: operational
+  indexes: [[ticketState]]
   schema:
     type: object
     additionalProperties: false
@@ -28,134 +36,120 @@ spec:
     properties:
       subject: { type: string }
       ticketState: { type: string, enum: [open, closed] }
-  indexes: [[ticketState]]
 ---
-apiVersion: cms.mantle.aotter.net/v1
+apiVersion: cms.mantle.aotter.net/v2
 kind: View
-metadata:
-  name: tickets-by-state
+metadata: { name: tickets-by-state }
 spec:
   surface: internal
-  from: tickets
-  fields: [id, subject, ticketState]
-  filter:
-    eq: { field: ticketState, value: { $param: ticketState } }
-  params:
+  input:
     type: object
     additionalProperties: false
     required: [ticketState]
     properties:
       ticketState: { type: string, enum: [open, closed] }
-  limit: 50
-```
-
-```sh
-pnpm exec mantle validate --no-source
-pnpm exec mantle generate
-pnpm exec mantle generate --check
+  sql: |
+    SELECT id, subject, ticketState FROM tickets
+    WHERE ticketState = input.ticketState
+    ORDER BY created_at DESC LIMIT 50
 ```
 
-`internal` keeps this query out of REST routes, OpenAPI, MCP/WebMCP catalogs and
-Admin reports. It remains in the plan and generated binding. It is not a
-security bypass: adding `requires` evaluates the same authorization and guards
-against the host-supplied `ctx` on every call. No `uiSchema` or shared HTTP
-cache is allowed for an internal View.
-
-## Bind and call
+`internal` keeps the View off REST, MCP and Admin. It is still in the plan and
+the typed Store. It is not a security bypass: a `requires` on it is checked
+for the caller the Store is bound to.
 
-When the host already owns a prepared Runtime, bind it once where you need the
-typed API. This function can live in `src/queries.ts`:
+## Call it
 
 ```ts
-import type { MantleRuntime } from "@aotter/mantle/runtime";
-import { bindMantle } from "../.mantle/generated/mantle.js";
-
-export async function openTickets(runtime: MantleRuntime) {
-  const mantle = bindMantle(runtime);
-  const result = await mantle.views.ticketsByState({
-    params: { ticketState: "open" },
-    page: 1,
-    show: 20,
-  });
-  if (!result.ok) throw new Error(result.diagnostic.message);
-  return result.result.rows;
-}
+import type { MantleHandlers } from "../.mantle/generated/mantle.js";
+
+export const handlers: MantleHandlers = {
+  closeStale: async (_input, ctx) => {
+    const { rows, nextCursor } = await ctx.store.view("tickets-by-state", { input: { ticketState: "open" }, limit: 20 });
+    // rows: { id: unknown; subject: string | null; ticketState: "open" | "closed" | null }[]
+    return { open: rows.length, more: nextCursor !== undefined };
+  },
+};
 ```
 
-The runtime response uses `result` on success (`result.result.rows` above);
-REST wraps those rows under `data` instead.
-
-The wire name `tickets-by-state` becomes `ticketsByState`. Required params
-make the request and `params` mandatory; invalid enum values are TypeScript
-errors, and Runtime also validates actual inputs. `show` remains capped by
-`limit`. For an authorized View, pass the verified caller context as `ctx`;
-do not fabricate staff/user identities from request input.
+The View name, its `input` and its row type are checked by `tsc`. A staff View
+with `uiSchema.list.searchFields` or `filterFields` also takes `search` and
+`filters` (`ctx.store.view(name, { search: "refund", filters: { ticketState: "open" } })`);
+Store refuses a filter the View does not declare. An output that reads a
+Schema field unchanged has that field's type, `created_at` and `updated_at`
+are `string | null`, and an expression, or another native column such as `id`,
+is `unknown`. Page with `limit` (default 50, at most 500) and the opaque
+`cursor` from `nextCursor`.
 
-A host without a Runtime can use generated `createMantle({ storage, handlers,
-ports })`, which delegates one eager boot attempt and returns the typed
-binding. Host code still owns connection lifetime and retries. See
-[Runtime and adapters](../concepts/runtime-and-adapters.md).
+## `select` and `write`
 
-## What is typed
-
-| Query form | Generated shape | Limit |
-|---|---|---|
-| Declarative View | `Mantle.ViewParams_<name>` and `Mantle.ViewRow_<name>` | Projection follows `fields`; native columns have their native types. Data properties remain optional in the row type. |
-| SQL View | Typed params; row type `unknown` | The generator does not infer SQL expressions or aliases. Narrow/validate rows in host code. |
-| Entry field reader | `MantleEntry<Mantle.Entry_<schema>>` | The field must be a declared data property and the value a compatible string, number or boolean. Types do not prove an index exists. |
-| Dynamic Runtime call | `runtime.executeView({ view, ctx, options })` | Useful without codegen; supplying a generic row type is the caller's assertion, not SQL validation. |
-
-Without `fields`, a declarative View includes native entry columns and Schema
-properties. Use explicit projections on exposed reads. Public declarative
-Views over publishing Schemas inject `status = published`; internal/staff
-Views and SQL statements do not. See [View reference](../reference/view.md).
-
-## Indexed entry reads
-
-For the Schema above:
+For a query that needs no declared View, `select` takes a JSON query over one
+Schema:
 
 ```ts
-const rows = await mantle.entries.tickets.findManyByDataField({
-  field: "ticketState",
-  value: "open",
+const { rows } = await ctx.store.select({
+  from: "tickets",
+  columns: ["id", "subject"],
+  where: { ticketState: "open", subject: { like: "%refund%" } },
+  orderBy: { updatedAt: "desc" },
   limit: 20,
 });
-// rows[n].data is the generated tickets data shape.
 ```
 
-| Method | Returns | Options worth knowing |
-|---|---|---|
-| `readBySlug({ slug, locale?, status? })` | One entry or `null` | Use on a Schema with a slug field and an appropriate index. |
-| `readByDataField({ field, value, locale?, status? })` | One entry or `null` | Equality on one data property. |
-| `readByDataFieldIn({ field, values, latestPerValue?, locale?, status? })` | Entry array | Batch equality lookups; `latestPerValue` selects the newest match per value. |
-| `findManyByDataField({ field, value, limit })` | Entry array | Bounded equality lookup across statuses; no `ctx`, `status` or `locale` option. |
-
-These readers do not evaluate View `requires`, inject public visibility or
-fire mutation hooks. In particular, `findManyByDataField` can return drafts.
-Use a public View for untrusted callers; do not expose a raw reader as a public
-route and assume the generated type authorizes it. Declare a measured index
-whose leftmost field matches the lookup; do not scan an entire collection in
-TypeScript to replace a field query.
+- `where`: `{ column: value }` is equality and sibling keys are AND; also
+  `{ column: { eq, ne, gt, gte, lt, lte, like, in, notIn, isNull } }`, and
+  `and`, `or`, `not`. `in` takes a list or `{ select, from, where }`.
+- `orderBy`: one column; `id` breaks ties. Default `{ updatedAt: "desc" }`.
+- `search`: text matched against `searchableFields` (and `id`).
+- Native columns are camelCase here (`createdAt`, `authorId`), while SQL spells
+  them snake_case (`created_at`).
 
-## Generate from an existing plan
-
-A build tool that already compiled a sealed plan can use the pure emitter:
+`write` applies every operation or none, in order:
 
 ```ts
-import { emitMantleModule } from "@aotter/mantle/codegen";
-
-const emitted = emitMantleModule({ plan });
-if (!emitted.ok) throw new Error(emitted.diagnostics.map(d => d.message).join("\n"));
-// Write emitted.source to your generated module in the build step.
+await ctx.store.write([
+  { update: "tickets", set: { ticketState: "closed" }, where: { id }, lock: expectedVersion },
+  { insert: "ticket-events", values: { ticketId: id, kind: "closed" } },
+]);
 ```
 
-Pass either `{ plan }` or `{ linked }`, never both. The plan form avoids
-reparsing YAML and preserves the same generated types and entry/View/Procedure
-bindings. The emitter does no I/O, asset copying, storage preparation or caching.
+- `insert` with `values`, optional client `id` (`ctx.store.id()`) and
+  `onConflict: "ignore" | { columns, update }`. A scoped Schema refuses a
+  client `id`, because a chosen id could collide with another owner's row and
+  reveal it: give such rows a field of your own that is unique with the scope
+  field (`uniqueIndexes: [[owner, clientKey]]`) when other rows of the same
+  write must point at them, or when a retry must find them.
+- `update` with `set` and `where`; `delete` with `where`. A `where` that pins
+  `id` is a row op: it may carry `lock` (the version the caller saw), and
+  writing no row is `CONFLICT`.
+- A result is `{ id, version }` for a row op and `{ affected }` for a set op.
+- `set` and `values` never name the scope field or a native column (except
+  `status` on a `publishing` Schema, below); Store
+  fills them. A `null` leaves empty, or clears, a field the Schema does not
+  require (the generated `values` and `set` types accept it); for a required
+  field it is refused. On a `publishing` Schema, `set: { status }` is how a `ref`
+  handler publishes, unpublishes or archives.
+
+Failures throw `DiagnosticError` with `INPUT_VALIDATION_FAILED` (including a
+failed `check`), `CONFLICT` (`conflict.reason` is `lock`, `expect` or
+`unique`, and `conflict.opIndex` names the operation; for `unique` it is
+present when exactly one operation of the write targets the violated Schema,
+since the engine names the table and not the statement), `RESOURCE_UNAVAILABLE`
+or `OUTCOME_UNKNOWN`. Nothing is written on any failure. After
+`OUTCOME_UNKNOWN`, retry with the same client ids and locks: a replayed insert
+conflicts on its id, a replayed update on its lock.
+
+## From service code
+
+The service's `fetch` receives the runtime. Resolve the caller first, as the
+generated `withCaller` does, and bind Store to it:
 
-## Source
+```ts
+const caller = await resolveCaller(request);
+if (!("caller" in caller)) return new Response("unauthorized", { status: 401 });
+const { rows } = await runtime.store.as(caller.caller).view("tickets-by-state", { input: { ticketState: "open" } });
+```
 
-- [Binding generator](../../../packages/mantle/src/codegen/emitMantleModule.ts)
-- [Type generator](../../../packages/mantle-spec/src/usecase/EmitTypesUseCase.ts)
-- [Entry reader contract](../../../packages/mantle-runtime/src/domain/port/EntryReader.ts)
-- [View execution](../../../packages/mantle-runtime/src/usecase/view/ExecuteViewUseCase.ts)
+To run a Procedure from service code, with its auth, guard and validation, call
+`runtime.invokeProcedure({ procedure, input, caller, cause: { kind: "internal", id } })`.
+Inside a handler, `ctx.invoke(name, input)` does the same and keeps the caller.

package/docs/handbook/navigation.json

@@ -5,17 +5,15 @@
       "text": "Start here",
       "items": [
         { "text": "Handbook overview", "link": "/start/overview" },
-        { "text": "Generate a project and use the CLI", "link": "/start/project-and-cli" },
-        { "text": "Quickstart: a minimal Worker", "link": "/start/quickstart-worker" },
-        { "text": "Quickstart: authored Worker Admin", "link": "/start/quickstart-admin" },
-        { "text": "When the host is ChatGPT Sites", "link": "/chatgpt-sites/index" }
+        { "text": "Quickstart: a service on Workers", "link": "/start/quickstart-worker" },
+        { "text": "Project layout and CLI", "link": "/start/project-and-cli" }
       ]
     },
     {
       "text": "Task guides",
       "items": [
         { "text": "Agent installation and handoff", "link": "/guides/agent-setup" },
-        { "text": "Typed queries and internal Views", "link": "/guides/typed-queries" },
+        { "text": "Query from TypeScript", "link": "/guides/typed-queries" },
         { "text": "Customize Admin from manifests", "link": "/guides/admin-ui" }
       ]
     },
@@ -28,7 +26,7 @@
         { "text": "Writes: Procedures, Triggers and hooks", "link": "/concepts/procedures-and-triggers" },
         { "text": "Authorization", "link": "/concepts/authorization" },
         { "text": "MCP and agents", "link": "/concepts/mcp-and-agents" },
-        { "text": "Runtime pipeline and adapters", "link": "/concepts/runtime-and-adapters" }
+        { "text": "Runtime, Store and dialects", "link": "/concepts/runtime-and-adapters" }
       ]
     },
     {
@@ -46,49 +44,26 @@
         { "text": "HTTP, MCP, CLI and packages", "link": "/reference/surface" }
       ]
     },
-    {
-      "text": "ChatGPT Sites",
-      "items": [
-        { "text": "Get started", "link": "/chatgpt-sites/index" },
-        { "text": "Generate a blank app", "link": "/chatgpt-sites/generated-app" },
-        { "text": "Host reference", "link": "/chatgpt-sites/host-reference" },
-        { "text": "Equipment checkout and external APIs", "link": "/chatgpt-sites/equipment-checkout" },
-        { "text": "Earlier guide URL", "link": "/cloudflare/chatgpt-sites" }
-      ]
-    },
     {
       "text": "Cloudflare",
       "items": [
-        { "text": "The conventional Worker", "link": "/cloudflare/conventional-worker" },
-        { "text": "Bindings and primitives", "link": "/cloudflare/bindings" },
+        { "text": "The service and its entry", "link": "/cloudflare/service-entry" },
         { "text": "Authentication", "link": "/cloudflare/authentication" },
-        { "text": "Public web, SEO and cache", "link": "/cloudflare/public-web" },
-        { "text": "Site chrome", "link": "/cloudflare/site-chrome" },
-        { "text": "Deferred hooks with Queues", "link": "/cloudflare/deferred-hooks-queues" },
         { "text": "Media uploads with R2", "link": "/cloudflare/media-r2" },
         { "text": "Deploy and operate", "link": "/cloudflare/deploy-and-operate" },
-        { "text": "Low-level composition", "link": "/cloudflare/low-level-composition" }
+        { "text": "Mantle on ChatGPT Sites", "link": "/cloudflare/chatgpt-sites" }
       ]
     },
     {
       "text": "Examples",
       "items": [
-        { "text": "Examples hub", "link": "/examples/hub" },
-        { "text": "Intake form (builtin)", "link": "/examples/intake-form" },
-        { "text": "Intake Turnstile and email hooks", "link": "/examples/intake-hooks" },
-        { "text": "Publication", "link": "/examples/publication" },
-        { "text": "Legal documents and consent", "link": "/examples/legal-documents" },
-        { "text": "Reservation requests", "link": "/examples/reservation" },
-        { "text": "Procurement approvals", "link": "/examples/procurement-approvals" },
-        { "text": "Commerce catalog (builtin)", "link": "/examples/commerce" },
-        { "text": "Commerce inventory (DO/Queue)", "link": "/examples/commerce-transaction" },
-        { "text": "Guarded API access", "link": "/examples/guarded-api" }
+        { "text": "Examples", "link": "/examples/hub" }
       ]
     },
     {
       "text": "Releases",
       "items": [
-        { "text": "Stable releases", "link": "/releases/index" }
+        { "text": "Releases", "link": "/releases/index" }
       ]
     }
   ]