@proveanything/smartlinks 2.1.2 → 2.1.4

package/dist/docs/API_SUMMARY.md

@@ -1,6 +1,6 @@
 # Smartlinks API Summary
 
-Version: 2.1.2  |  Generated: 2026-10-26T14:58:53.408Z
+Version: 2.1.4  |  Generated: 2026-10-28T12:35:09.709Z
 
 This is a concise summary of all available API functions and types.
 
@@ -2585,9 +2585,11 @@ interface AppContainerComponent {
 **DeepLinkEntry** (interface)
 ```typescript
 interface DeepLinkEntry {
+  id?: string;
   title: string;
   path?: string;
   params?: Record<string, string>;
+  accepts?: PublicViewParams;
   widget?: true;
 }
 ```
@@ -2711,6 +2713,7 @@ interface AppFunctionAgentExposure {
   description?: string;
   input?: Record<string, any>;
   approval?: 'auto' | 'require';
+  audience?: Array<'app' | 'public' | 'assistant'>;
 }
 ```
 
@@ -3049,10 +3052,29 @@ interface AppManifest {
   data?: AppDataDeclaration;
   headless?: AppHeadlessDeclaration;
   connector?: AppConnectorDeclaration;
+  assistant?: AppAssistantDeclaration;
   [key: string]: any;
 }
 ```
 
+**AppAssistantFile** (interface)
+```typescript
+interface AppAssistantFile {
+  name: string;
+  description?: string;
+  file: string;
+}
+```
+
+**AppAssistantDeclaration** (interface)
+```typescript
+interface AppAssistantDeclaration {
+  skills?: AppAssistantFile[];
+  knowledge?: AppAssistantFile[];
+  preview?: string;
+}
+```
+
 **ConnectorConnectionField** (interface)
 ```typescript
 interface ConnectorConnectionField {
@@ -7479,6 +7501,7 @@ interface IframeResponderOptions {
   version?: string;
   appUrl?: string;
   initialPath?: string;
+  params?: Record<string, string>;
   isAdmin?: boolean;
   cache?: CachedData;
   onAuthLogin?: (

package/dist/docs/agent-tools.md

@@ -44,7 +44,8 @@ needs to call it — a description and an input schema:
           "title": "Create an FAQ entry",
           "description": "Add a question/answer to this collection's FAQ. Use when the user asks to add or draft an FAQ.",
           "input": { /* JSON Schema for the arguments the agent supplies as event.body */ },
-          "approval": "auto"        // auto | require  (require = human confirmation before the call)
+          "approval": "auto",       // auto | require  (require = human confirmation before the call)
+          "audience": ["app"]       // optional: app | public | assistant — where it is offered (absent = everywhere)
         }
       }
     ]
@@ -103,6 +104,10 @@ Identical to server functions — nothing new to reason about:
 - **`visibility`** — who may call (admin/public).
 - **`authority`** — whose identity `ctx.sl` carries (`caller` vs `collection`).
 - **`capabilities`** — least-privilege, capped even when elevated.
+- **`agent.audience`** — where the tool is offered: `'app'` (the app's own agent runs, admin surface),
+  `'public'` (public assistants), `'assistant'` (the Studio assistant, the admin's agent —
+  [assistant-apps.md](assistant-apps.md)). Absent = everywhere the function's visibility allows. An
+  assistant-only tool declares `["assistant"]` and never joins an in-app or public run.
 - **`agent.approval: "require"`** — the agent must get human confirmation before invoking (use for
   destructive or public-facing actions).
 

package/dist/docs/app-manifest.md

@@ -326,11 +326,28 @@ Static deep-linkable states built into the app — fixed routes that exist regar
 
 See the [Deep Link Discovery guide](deep-link-discovery.md) for the full dual-source pattern (static manifest routes + dynamic `appConfig.linkable`).
 
+These are the app's **pages that a host opens**: portal menus and tabs, and websites that embed the app
+(websites.md → "Using another app's pages"). A host opens them with its own signed-in session, so one
+app can offer several pages that each know the visitor: book, upcoming bookings, past bookings, change a
+booking.
+
+```json
+"linkable": [
+  { "id": "book", "title": "Book an appointment", "path": "/",
+    "accepts": { "optional": ["service", "staff", "date"] } },
+  { "id": "upcoming", "title": "Your upcoming bookings", "path": "/my-bookings" },
+  { "id": "change", "title": "Change a booking", "path": "/booking",
+    "accepts": { "required": ["id"] } }
+]
+```
+
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
+| `id` | string | ❌ | Stable id, unique within the app: hosts and sites refer to the page by it |
 | `title` | string | ✅ | Human-readable label shown in menus and offered to AI agents |
 | `path` | string | ❌ | Hash route within the app (defaults to `"/"` if omitted) |
-| `params` | object | ❌ | App-specific query params appended to the URL — do **not** include platform params (`collectionId`, `productId`, etc.) |
+| `params` | object | ❌ | Params this entry PINS, appended to the URL — do **not** include platform params (`collectionId`, `productId`, etc.) |
+| `accepts` | `{ required?: string[]; optional?: string[] }` | ❌ | The params a host may supply when it opens the page (e.g. which service to start on) |
 
 #### `publicViews`
 
@@ -371,7 +388,7 @@ An app can have any combination of three setup styles. Only public views are ext
 | Style | Declared by | Lives | Context |
 |-------|-------------|-------|---------|
 | **Portal components** — where the app renders inside portal (collection / product / batch / variant / proof) | module registry `components.*` (set at publish) | Inside portal | Physical twin (QR/NFC scan) |
-| **Portal deep links** — the entry points portal menus/tabs/side-menus link to (e.g. list view vs calendar view) | `linkable` / `DeepLinkEntry` | Inside portal | Portal (menu picks the entry) |
+| **App pages** — the entry points portal menus/tabs link to and websites embed (e.g. list vs calendar; book vs my bookings) | `linkable` / `DeepLinkEntry` | Inside a host: portal or a website | The host: its signed-in session, plus the page's `accepts` params |
 | **Public views** — standalone external screens | `publicViews` (this block) | Outside portal | URL params only |
 
 #### `records`
@@ -443,6 +460,30 @@ lists it and draws its connect form and settings, and the integration engine cal
 functions (`testConnection`, `describeTarget`, `sample`, `fetch`, `shape`, `serialize`, `send`). It adapts the provider's format; core does each customer's mapping. The full
 contract is in the **[Connectors guide](connectors.md)**.
 
+#### `assistant`
+
+What the **Studio assistant** (the admin's own agent) knows about this app: skills and knowledge files
+shipped with the build and loaded into its box on demand, and an optional page that renders a planned
+change set before it is applied.
+
+```jsonc
+"assistant": {
+  "skills": [
+    { "name": "theme", "description": "Changing the Hub's colours, fonts or logo", "file": "assistant/skills/theme.md" },
+    { "name": "pages", "description": "Adding, ordering and editing pages and the menu", "file": "assistant/skills/pages.md" }
+  ],
+  "knowledge": [
+    { "name": "settings-schema", "description": "JSON Schema of the hub settings group", "file": "assistant/knowledge/settings.schema.json" }
+  ],
+  "preview": "/admin/preview?changeSet={id}"
+}
+```
+
+The files live under `public/assistant/` and ship with every release like any other static file. The
+assistant sees one line per skill (its description) and reads the file only when the job calls for it,
+so a big app can carry many skills at no cost to the conversation. Full guide, including what a skill
+should say and how the assistant changes config with undo: **[assistant-apps.md](assistant-apps.md)**.
+
 ---
 
 ## `app.admin.json`

package/dist/docs/assistant-apps.md

@@ -0,0 +1,168 @@
+# The Studio assistant and your app
+
+SmartLinks admins have **one assistant**: an agent that works for the signed-in admin on one
+collection, with the admin's own authority, from a chat in Studio. It reads and changes data through
+the SmartLinks API, every write is a **change set** the admin can see and undo, and the things that
+can't be undone (deleting, sending, calling out, publishing, spending) wait for the admin's "Allow".
+
+This page is for app authors: how the assistant learns what your app is, how it is set up, and what it
+can do for the admin — without you building a chat of your own. Your app declares three things:
+
+| What | Where | Status |
+|---|---|---|
+| **Skills and knowledge** — plain-words procedures for the admin side, and the facts they need | `assistant` block in `app.manifest.json`, files under `public/assistant/` | this page |
+| **Tools** — logic the assistant should call rather than reimplement | server functions with an `agent` block (`audience: ["assistant"]` for assistant-only) | [agent-tools.md](agent-tools.md) |
+| **Setup** — questions, config schema, how to save | `app.admin.json` + `ai-guide.md` | [app-manifest.md](app-manifest.md#appadminjson) |
+
+An app with none of these still works with the assistant: it can read the app's records and config
+and change them through change sets. The declarations make it *good* at your app.
+
+## The `assistant` block
+
+```jsonc
+// app.manifest.json
+"assistant": {
+  "skills": [
+    { "name": "setup",  "description": "First-time setup of the FAQ app: categories, tone, who answers", "file": "assistant/skills/setup.md" },
+    { "name": "content", "description": "Adding, editing, ordering and retiring questions and answers",  "file": "assistant/skills/content.md" }
+  ],
+  "knowledge": [
+    { "name": "config-schema", "description": "JSON Schema of the app's config document", "file": "assistant/knowledge/config.schema.json" },
+    { "name": "examples",      "description": "Three worked examples of good FAQ content",   "file": "assistant/knowledge/examples.md" }
+  ],
+  "preview": "/admin/preview?changeSet={id}"
+}
+```
+
+The files sit in `public/assistant/` in your project and ship with every release like any other static
+file (they are read from the release's CDN folder, on the channel the collection runs your app on).
+
+### How they are loaded
+
+When an admin opens a chat, the assistant's box gets the **index** of every installed app's skills: one
+line each, the description. Nothing else. A skill's body, and the knowledge files it names, are read
+only when the assistant decides the job needs them. Twenty apps with three skills each cost the
+conversation about sixty lines. So: write several focused skills rather than one long one, and spend
+care on the description — it is how the assistant decides to open the file.
+
+### Writing a skill
+
+A skill is a markdown file: what this area of your app is for, what each setting means, how to read and
+change it, what a good result looks like, what to check afterwards. Write it for a capable colleague who
+has never seen your app. The assistant works through the SmartLinks API with a small CLI (`sl`), so say
+things in those terms:
+
+```markdown
+---
+name: faq-content
+description: Adding, editing, ordering and retiring questions and answers in the FAQ app
+---
+# FAQ content
+
+Questions live as app records of type `question` (`sl get app/faq/records recordType=question`).
+Fields: `data.question`, `data.answer` (markdown), `data.category` (one of the categories in the app's
+config, `sl get app/faq` → `categories[]`), `data.order` (ascending), `status` (`published` | `draft`).
+
+## Adding questions
+Plan one change set per batch: items `{ "op": "create", "entity": "record", "appId": "faq",
+"data": { "recordType": "question", "data": { … }, "status": "draft" } }`. Match on `data.question`
+(case-insensitive) before creating, so a re-run updates instead of duplicating.
+
+## A good answer
+Two to five sentences, plain words, no marketing. Link to a product page when one exists
+(`/p/<collectionId>/<productId>`). Never invent policy: if the answer depends on something the admin
+hasn't said (returns window, delivery areas), ask.
+
+## Check afterwards
+`sl get app/faq/records recordType=question status=draft` — read three back and make sure the
+category is one that exists.
+```
+
+The frontmatter is optional; when it is missing, the manifest entry's `name` and `description` are used.
+Keep a skill under a few hundred lines; put long reference material in knowledge files and name them.
+
+### Knowledge
+
+Knowledge files are what the skills refer to: the schema of your config document, record shapes, worked
+examples, a glossary of your app's words. The assistant reads them when a skill points at them (each
+skill is told where the app's knowledge files are).
+
+**Generate the schema, don't write it.** If your config is typed (a TypeScript interface, a zod schema),
+produce the JSON Schema at build time (`ts-json-schema-generator`, `zod-to-json-schema`) into
+`public/assistant/knowledge/`. A hand-written schema drifts the first week.
+
+## Tools: when a skill is not enough
+
+Nearly every admin action is a read or a patch of config or records, and the assistant does those
+itself. Give it a **tool** only when a step can't be an API call it makes on its own:
+
+- logic that lives in your code (validate a layout, render a page from a design direction, compute
+  something from your data model),
+- a write that must be atomic across several objects,
+- anything that needs your app's secrets.
+
+A tool is an http server function with an `agent` block
+([agent-tools.md](agent-tools.md)); the assistant calls it as
+`sl post app/<appId>/functions/<name> '{ … }'`, under the function's own visibility, authority and
+capabilities. Set `"audience": ["assistant"]` to keep an assistant-only tool out of your in-app and
+public agent runs:
+
+```jsonc
+{
+  "name": "applyDesignDirection",
+  "trigger": { "type": "http" },
+  "visibility": "admin",
+  "authority": "caller",
+  "capabilities": ["sl:settings:write"],
+  "agent": {
+    "tool": true,
+    "title": "Apply a design direction",
+    "description": "Rewrites the theme, fonts and layout of the hub to match a named direction.",
+    "input": { "type": "object", "properties": { "direction": { "type": "string" } }, "required": ["direction"] },
+    "audience": ["assistant"]
+  }
+}
+```
+
+A tool that changes config should **return the patch, not apply it**, so the assistant can put it in a
+change set and the admin keeps undo. Tools that act directly are fine for reads and computations.
+
+## How the assistant changes your config
+
+Your config document (`SL.appConfiguration`, `sl get app/<appId>`) and the collection's settings
+groups (`sl get settings/<group>`) are changed through change-set items:
+
+```jsonc
+{ "op": "update", "entity": "appConfig", "id": "<appId>", "data": { "theme": { "accent": "#0a7" } } }
+{ "op": "update", "entity": "appConfig", "id": "<appId>", "scope": { "productId": "p1" }, "data": { … } }
+{ "op": "update", "entity": "settings",  "id": "hub", "data": { "pages": { "about": { … } } } }
+```
+
+Saves deep-merge, as your own admin UI's saves do (nested objects merge, arrays replace). The whole
+document before the change is kept, so **undo puts it back exactly**. Say in your skills which keys
+are arrays, so the assistant sends the whole array when it changes one element.
+
+### Preview before apply
+
+A planned change set can be rendered before it is applied. The API gives, for every document a set
+touches, the live document and the document as it would become:
+
+```
+GET /admin/collection/:collectionId/assistant/changesets/:id/preview
+→ { id, status, targets: [ { entity, id, scope?, before, after, ops } ] }
+```
+
+Declare `assistant.preview` — a page of your admin surface that takes `{id}`, calls that endpoint
+with the admin's session, and renders `targets[].after` as your app would render the live config. The
+Studio panel then shows "Preview" on the change set, and the admin sees the result before saying yes.
+
+## Checklist
+
+- `assistant.skills[]`: several focused skills with descriptions that say when they apply.
+- `assistant.knowledge[]`: the config schema generated from your types; record shapes; examples.
+- Every skill says which fields are arrays, what to match on before creating, what to check after.
+- Logic the assistant can't reproduce: a server function with `agent.tool` and `audience: ["assistant"]`,
+  returning a patch for config changes.
+- `assistant.preview` when your app has a visual surface worth seeing before a change lands.
+- `ai-guide.md` still describes first-time setup for the setup wizard; the assistant reads it too when
+  an app declares no skills.

package/dist/docs/deep-link-discovery.md

@@ -172,6 +172,9 @@ Both sources use the same entry shape:
 
 ```typescript
 interface DeepLinkEntry {
+  /** Stable id, unique within the app (optional): hosts and websites refer to the page by it */
+  id?: string;
+
   /** Human-readable label for this state (required) */
   title: string;
 
@@ -193,6 +196,13 @@ interface DeepLinkEntry {
    */
   params?: Record<string, string>;
 
+  /**
+   * The params a host may supply when it opens this page (optional), e.g. a booking page that can
+   * start on one service: `{ optional: ['service', 'staff', 'date'] }`. `params` are pinned by the
+   * entry; `accepts` are filled in by whoever opens it.
+   */
+  accepts?: { required?: string[]; optional?: string[] };
+
   /**
    * When `true`, this entry is also available as a dynamic data context for widgets.
    *
@@ -211,7 +221,9 @@ interface DeepLinkEntry {
 |-------|----------|-------|
 | `title` | ✅ | Displayed in menus and offered to AI agents. Should be concise and human-readable. |
 | `path` | ❌ | Hash route within the app. Defaults to `/` if omitted. |
+| `id` | ❌ | Stable id for hosts and websites to refer to the page by. |
 | `params` | ❌ | App-specific query params only. Platform params are injected automatically. |
+| `accepts` | ❌ | The params whoever opens the page may supply (`required` / `optional`). |
 | `widget` | ❌ | Set to `true` to make this entry selectable in the widget config picker as a dynamic data context. |
 
 > **Tip:** Different entries can share the same `path` if they differ by `params` — for example, two entries pointing at `/settings` with different `tab` params.

package/dist/docs/iframe-responder.md

@@ -103,6 +103,7 @@ interface IframeResponderOptions {
   version?: 'stable' | 'development'; // App version (default: 'stable')
   appUrl?: string;              // Override URL (for local dev)
   initialPath?: string;         // Initial hash path (e.g., '/settings')
+  params?: Record<string, string>; // The page's own params (e.g. { service: 'svc_123' }); context params win
   
   // Data
   cache?: CachedData;           // Pre-cached data

package/dist/docs/websites.md

@@ -66,6 +66,32 @@ bytes. `_server/` is never served to visitors.
   doing work that belongs in a server function or a scheduled job.
 - **No secrets** in the server bundle and no Node built-ins beyond `nodejs_compat`.
 
+## Using another app's pages
+
+Some apps do a job a site shouldn't rebuild: a booking journey holds the time rules, the clash
+handling and the confirmation; "my bookings" holds who may change what. Those apps declare their pages
+in `linkable` (app-manifest.md), each with a stable `id`, a `path` and the params it `accepts`. A site
+embeds one with **`IframeResponder`** (iframe-responder.md), from the browser:
+
+```typescript
+const site = SL.site.current()
+const responder = new SL.IframeResponder({
+  collectionId: site.collectionId,
+  appId: 'appointments',            // the app's id on this collection
+  initialPath: '/my-bookings',      // the page's `path`
+  params: { service: 'svc_123' },   // what the page `accepts`
+  onResize: (h) => { iframe.style.height = `${h}px` },
+})
+iframe.src = await responder.attach(iframe)
+```
+
+- **The visitor's session goes with it.** The page's API calls are proxied through the site, so it
+  acts as whoever is signed in to the site (or as a guest). Never pass a token in the URL.
+- **The app must be installed** on the site's collection; its address comes from there.
+- **Show the app's content natively where you can** (its `headless` data: services, staff, events)
+  for your own design and SEO, and embed the page only for the part that does the work.
+- Pages render on the client, after load: they aren't part of the server-rendered HTML.
+
 ## Caching
 
 The router keeps a rendered page at the edge when your response says it may:

package/dist/iframeResponder.d.ts

@@ -100,4 +100,6 @@ export declare function buildIframeSrc(options: {
         secondary?: string;
     };
     initialPath?: string;
+    /** The page's own params; the context params above always win. */
+    params?: Record<string, string>;
 }): string;

package/dist/iframeResponder.js

@@ -155,11 +155,16 @@ export class IframeResponder {
     // URL Building
     // ===========================================================================
     buildIframeSrc() {
-        var _a, _b;
+        var _a, _b, _c;
         if (!this.appUrl) {
             throw new Error('App URL not resolved');
         }
         const params = new URLSearchParams();
+        // The page's own params first: the platform's context below always wins.
+        for (const [key, value] of Object.entries((_a = this.options.params) !== null && _a !== void 0 ? _a : {})) {
+            if (value != null && value !== '')
+                params.set(key, String(value));
+        }
         // Required context
         params.set('collectionId', this.options.collectionId);
         params.set('appId', this.options.appId);
@@ -171,13 +176,13 @@ export class IframeResponder {
         if (this.options.isAdmin)
             params.set('isAdmin', 'true');
         // Dark mode from collection
-        const isDark = (_b = (_a = this.cache.collection) === null || _a === void 0 ? void 0 : _a.dark) !== null && _b !== void 0 ? _b : false;
+        const isDark = (_c = (_b = this.cache.collection) === null || _b === void 0 ? void 0 : _b.dark) !== null && _c !== void 0 ? _c : false;
         params.set('dark', isDark ? '1' : '0');
         // Parent URL for redirects
         try {
             params.set('parentUrl', window.location.href);
         }
-        catch (_c) {
+        catch (_d) {
             // Ignore if can't access location
         }
         // Encode theme from collection
@@ -192,7 +197,7 @@ export class IframeResponder {
                     params.set('theme', btoa(JSON.stringify(themeData)));
                 }
             }
-            catch (_d) {
+            catch (_e) {
                 // Ignore encoding errors
             }
         }
@@ -210,7 +215,8 @@ export class IframeResponder {
                 const path = this.options.initialPath.startsWith('/') ? this.options.initialPath : '/' + this.options.initialPath;
                 // Insert path before the ?
                 const [beforeHash, afterHash] = baseWithHash.split('#');
-                finalUrl = `${beforeHash}#${afterHash || ''}${path}?${existingParams.toString()}`;
+                // App addresses end in "#/": join without doubling the slash ("#//my-bookings" matches no route).
+                finalUrl = `${beforeHash}#${(afterHash || '').replace(/\/+$/, '')}${path}?${existingParams.toString()}`;
             }
             else {
                 finalUrl = `${baseWithHash}?${existingParams.toString()}`;
@@ -765,8 +771,12 @@ export function isAdminFromRoles(user, collection, proof) {
  * Standalone helper for cases where you don't need the full IframeResponder.
  */
 export function buildIframeSrc(options) {
-    var _a, _b;
+    var _a, _b, _c;
     const params = new URLSearchParams();
+    for (const [key, value] of Object.entries((_a = options.params) !== null && _a !== void 0 ? _a : {})) {
+        if (value != null && value !== '')
+            params.set(key, String(value));
+    }
     params.set('collectionId', options.collectionId);
     params.set('appId', options.appId);
     if (options.productId)
@@ -776,14 +786,14 @@ export function buildIframeSrc(options) {
     if (options.isAdmin)
         params.set('isAdmin', 'true');
     params.set('dark', options.dark ? '1' : '0');
-    if (((_a = options.theme) === null || _a === void 0 ? void 0 : _a.primary) || ((_b = options.theme) === null || _b === void 0 ? void 0 : _b.secondary)) {
+    if (((_b = options.theme) === null || _b === void 0 ? void 0 : _b.primary) || ((_c = options.theme) === null || _c === void 0 ? void 0 : _c.secondary)) {
         const themeData = { p: options.theme.primary, s: options.theme.secondary };
         params.set('theme', btoa(JSON.stringify(themeData)));
     }
     try {
         params.set('parentUrl', window.location.href);
     }
-    catch (_c) {
+    catch (_d) {
         // Ignore
     }
     let base = options.appUrl.replace(/#\/?$/, '').replace(/\/$/, '');

package/dist/openapi.yaml

@@ -19909,6 +19909,8 @@ components:
     DeepLinkEntry:
       type: object
       properties:
+        id:
+          type: string
         title:
           type: string
         path:
@@ -19917,6 +19919,8 @@ components:
           type: object
           additionalProperties:
             type: string
+        accepts:
+          $ref: "#/components/schemas/PublicViewParams"
         widget:
           type: object
           additionalProperties: true
@@ -20134,6 +20138,14 @@ components:
           enum:
             - auto
             - require
+        audience:
+          type: array
+          items:
+            type: string
+            enum:
+              - app
+              - public
+              - assistant
       required:
         - tool
     AppManifestFunctions:
@@ -20631,6 +20643,8 @@ components:
           $ref: "#/components/schemas/AppHeadlessDeclaration"
         connector:
           $ref: "#/components/schemas/AppConnectorDeclaration"
+        assistant:
+          $ref: "#/components/schemas/AppAssistantDeclaration"
       required:
         - name
         - version
@@ -20638,6 +20652,31 @@ components:
         - function
         - files
         - components
+    AppAssistantFile:
+      type: object
+      properties:
+        name:
+          type: string
+        description:
+          type: string
+        file:
+          type: string
+      required:
+        - name
+        - file
+    AppAssistantDeclaration:
+      type: object
+      properties:
+        skills:
+          type: array
+          items:
+            $ref: "#/components/schemas/AppAssistantFile"
+        knowledge:
+          type: array
+          items:
+            $ref: "#/components/schemas/AppAssistantFile"
+        preview:
+          type: string
     ConnectorConnectionField:
       type: object
       properties:
@@ -27652,6 +27691,10 @@ components:
           type: string
         initialPath:
           type: string
+        params:
+          type: object
+          additionalProperties:
+            type: string
         isAdmin:
           type: boolean
         cache:

package/dist/types/appManifest.d.ts

@@ -109,6 +109,12 @@ export interface AppContainerComponent {
  *   { "title": "About Us", "params": { "pageId": "about-us" } }
  */
 export interface DeepLinkEntry {
+    /**
+     * Stable id for this page, unique within the app (optional). Hosts and websites refer to the page
+     * by it (e.g. a site embeds `{ app: 'appointments', page: 'book' }`), so a renamed `title` or a moved
+     * `path` doesn't break them.
+     */
+    id?: string;
     /** Human-readable label shown in menus and offered to AI agents */
     title: string;
     /**
@@ -123,6 +129,12 @@ export interface DeepLinkEntry {
      * those are injected by the platform automatically.
      */
     params?: Record<string, string>;
+    /**
+     * The params a host may supply when it opens this page (in addition to the platform's own), e.g. a
+     * booking page that can start on one service: `{ optional: ['service', 'staff', 'date'] }`. `params`
+     * above are the values this entry PINS; `accepts` are the ones the caller fills in.
+     */
+    accepts?: PublicViewParams;
     /**
      * When `true`, this entry is also available as a dynamic data context for widgets
      * (in addition to being a navigable page / container route).
@@ -337,6 +349,13 @@ export interface AppFunctionAgentExposure {
      * the autonomous server-side loop (they'd otherwise run unconfirmed).
      */
     approval?: 'auto' | 'require';
+    /**
+     * Where the tool is offered. `'app'` = the app's own agent runs (admin surface), `'public'` = public
+     * assistants, `'assistant'` = the Studio assistant (the admin's agent, docs/assistant-apps.md).
+     * Absent = everywhere the function's visibility allows. An assistant-only tool (logic the assistant
+     * needs that lives in your code) declares `['assistant']` and never shows in an in-app or public run.
+     */
+    audience?: Array<'app' | 'public' | 'assistant'>;
 }
 /** The `functions` block in `app.manifest.json`. Presence means the app ships server functions. */
 export interface AppManifestFunctions {
@@ -856,10 +875,10 @@ export interface AppManifest {
         components: AppContainerComponent[];
     };
     /**
-     * PORTAL deep-linkable states built into this app — the entry points the portal's menu system
-     * (bottom menu, side menus, tabs) can link to. Use these when one app has several ways to enter/load
-     * its portal component (e.g. a list view and a calendar view, or a viewer and an editor) that
-     * different parts of portal should link to independently. These live INSIDE portal.
+     * The app's PAGES that a host opens — portal menus (bottom menu, side menus, tabs) and WEBSITES that
+     * embed the app (IframeResponder). Use these when one app has several ways in (a list view and a
+     * calendar view; book, upcoming bookings, change a booking). A host opens them with its own signed-in
+     * session: the page's API calls go through the host, so it acts as the person signed in there.
      * Fixed routes are declared here at build time; dynamic content entries (e.g. CMS pages) are stored
      * separately in `appConfig.linkable` — merge both for the full navigable set.
      * @see DeepLinkEntry
@@ -929,8 +948,52 @@ export interface AppManifest {
      * @see AppConnectorDeclaration · docs/connectors.md
      */
     connector?: AppConnectorDeclaration;
+    /**
+     * What the Studio assistant (the admin's agent) knows about this app: skills and knowledge files
+     * shipped with the build and loaded into its box on demand, and an optional page that renders a
+     * planned change set. See docs/assistant-apps.md. @see AppAssistantDeclaration
+     */
+    assistant?: AppAssistantDeclaration;
     [key: string]: any;
 }
+/** One skill or knowledge file the app ships for the assistant. */
+export interface AppAssistantFile {
+    /** Short id, unique within the app (`theme`, `pages`, `settings-schema`). */
+    name: string;
+    /**
+     * One line: what it covers and when to reach for it. For a skill this is what the assistant sees
+     * before deciding to read the file, so say when it applies ("Changing the Hub's colours, fonts or
+     * logo"). A knowledge file's description says what is in it.
+     */
+    description?: string;
+    /**
+     * Path of the file in the published build, relative to the app's root (`public/` in the project):
+     * `assistant/skills/theme.md`. Markdown for skills; markdown or JSON (a JSON Schema) for knowledge.
+     */
+    file: string;
+}
+/** The `assistant` block in `app.manifest.json`. */
+export interface AppAssistantDeclaration {
+    /**
+     * Skills: plain-words procedures for one area of the app's admin side — what the settings mean,
+     * which calls read and change them, what a good result looks like, what to check. Several for a big
+     * app (identity and theme; pages and navigation; domains and SEO). A skill file may start with
+     * YAML frontmatter (`name`, `description`); if it doesn't, these entries supply it.
+     */
+    skills?: AppAssistantFile[];
+    /**
+     * Knowledge the skills refer to: the settings schema (generate it from your config types — never
+     * by hand), object definitions, worked examples, a glossary. Loaded only when a skill reaches for it.
+     */
+    knowledge?: AppAssistantFile[];
+    /**
+     * A page of the app that renders a PLANNED change set over the live config, so the admin can see a
+     * change before it is applied. `{id}` is replaced with the change-set id; the page reads
+     * `GET /admin/collection/:cid/assistant/changesets/:id/preview` and renders `targets[].after`.
+     * Relative to the app's admin surface, e.g. `"/admin/preview?changeSet={id}"`.
+     */
+    preview?: string;
+}
 /** One field of a connector's "Connect" form. */
 export interface ConnectorConnectionField {
     /** Key in the installation's connection settings (non-secret fields) — `name` for a secret too. */

package/dist/types/iframeResponder.d.ts

@@ -24,6 +24,12 @@ export interface IframeResponderOptions {
     appUrl?: string;
     /** Initial hash path (e.g., '/settings') */
     initialPath?: string;
+    /**
+     * The page's own params (a `linkable` entry's pinned `params` plus what it `accepts`), e.g.
+     * `{ service: 'svc_123' }`. Added to the app's URL alongside the platform's context params, which
+     * always win (collectionId, appId, productId, proofId, isAdmin, dark, theme, parentUrl).
+     */
+    params?: Record<string, string>;
     /** Is user an admin of this collection */
     isAdmin?: boolean;
     cache?: CachedData;

package/docs/API_SUMMARY.md

@@ -1,6 +1,6 @@
 # Smartlinks API Summary
 
-Version: 2.1.2  |  Generated: 2026-10-26T14:58:53.408Z
+Version: 2.1.4  |  Generated: 2026-10-28T12:35:09.709Z
 
 This is a concise summary of all available API functions and types.
 
@@ -2585,9 +2585,11 @@ interface AppContainerComponent {
 **DeepLinkEntry** (interface)
 ```typescript
 interface DeepLinkEntry {
+  id?: string;
   title: string;
   path?: string;
   params?: Record<string, string>;
+  accepts?: PublicViewParams;
   widget?: true;
 }
 ```
@@ -2711,6 +2713,7 @@ interface AppFunctionAgentExposure {
   description?: string;
   input?: Record<string, any>;
   approval?: 'auto' | 'require';
+  audience?: Array<'app' | 'public' | 'assistant'>;
 }
 ```
 
@@ -3049,10 +3052,29 @@ interface AppManifest {
   data?: AppDataDeclaration;
   headless?: AppHeadlessDeclaration;
   connector?: AppConnectorDeclaration;
+  assistant?: AppAssistantDeclaration;
   [key: string]: any;
 }
 ```
 
+**AppAssistantFile** (interface)
+```typescript
+interface AppAssistantFile {
+  name: string;
+  description?: string;
+  file: string;
+}
+```
+
+**AppAssistantDeclaration** (interface)
+```typescript
+interface AppAssistantDeclaration {
+  skills?: AppAssistantFile[];
+  knowledge?: AppAssistantFile[];
+  preview?: string;
+}
+```
+
 **ConnectorConnectionField** (interface)
 ```typescript
 interface ConnectorConnectionField {
@@ -7479,6 +7501,7 @@ interface IframeResponderOptions {
   version?: string;
   appUrl?: string;
   initialPath?: string;
+  params?: Record<string, string>;
   isAdmin?: boolean;
   cache?: CachedData;
   onAuthLogin?: (

package/docs/agent-tools.md

@@ -44,7 +44,8 @@ needs to call it — a description and an input schema:
           "title": "Create an FAQ entry",
           "description": "Add a question/answer to this collection's FAQ. Use when the user asks to add or draft an FAQ.",
           "input": { /* JSON Schema for the arguments the agent supplies as event.body */ },
-          "approval": "auto"        // auto | require  (require = human confirmation before the call)
+          "approval": "auto",       // auto | require  (require = human confirmation before the call)
+          "audience": ["app"]       // optional: app | public | assistant — where it is offered (absent = everywhere)
         }
       }
     ]
@@ -103,6 +104,10 @@ Identical to server functions — nothing new to reason about:
 - **`visibility`** — who may call (admin/public).
 - **`authority`** — whose identity `ctx.sl` carries (`caller` vs `collection`).
 - **`capabilities`** — least-privilege, capped even when elevated.
+- **`agent.audience`** — where the tool is offered: `'app'` (the app's own agent runs, admin surface),
+  `'public'` (public assistants), `'assistant'` (the Studio assistant, the admin's agent —
+  [assistant-apps.md](assistant-apps.md)). Absent = everywhere the function's visibility allows. An
+  assistant-only tool declares `["assistant"]` and never joins an in-app or public run.
 - **`agent.approval: "require"`** — the agent must get human confirmation before invoking (use for
   destructive or public-facing actions).
 

package/docs/app-manifest.md

@@ -326,11 +326,28 @@ Static deep-linkable states built into the app — fixed routes that exist regar
 
 See the [Deep Link Discovery guide](deep-link-discovery.md) for the full dual-source pattern (static manifest routes + dynamic `appConfig.linkable`).
 
+These are the app's **pages that a host opens**: portal menus and tabs, and websites that embed the app
+(websites.md → "Using another app's pages"). A host opens them with its own signed-in session, so one
+app can offer several pages that each know the visitor: book, upcoming bookings, past bookings, change a
+booking.
+
+```json
+"linkable": [
+  { "id": "book", "title": "Book an appointment", "path": "/",
+    "accepts": { "optional": ["service", "staff", "date"] } },
+  { "id": "upcoming", "title": "Your upcoming bookings", "path": "/my-bookings" },
+  { "id": "change", "title": "Change a booking", "path": "/booking",
+    "accepts": { "required": ["id"] } }
+]
+```
+
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
+| `id` | string | ❌ | Stable id, unique within the app: hosts and sites refer to the page by it |
 | `title` | string | ✅ | Human-readable label shown in menus and offered to AI agents |
 | `path` | string | ❌ | Hash route within the app (defaults to `"/"` if omitted) |
-| `params` | object | ❌ | App-specific query params appended to the URL — do **not** include platform params (`collectionId`, `productId`, etc.) |
+| `params` | object | ❌ | Params this entry PINS, appended to the URL — do **not** include platform params (`collectionId`, `productId`, etc.) |
+| `accepts` | `{ required?: string[]; optional?: string[] }` | ❌ | The params a host may supply when it opens the page (e.g. which service to start on) |
 
 #### `publicViews`
 
@@ -371,7 +388,7 @@ An app can have any combination of three setup styles. Only public views are ext
 | Style | Declared by | Lives | Context |
 |-------|-------------|-------|---------|
 | **Portal components** — where the app renders inside portal (collection / product / batch / variant / proof) | module registry `components.*` (set at publish) | Inside portal | Physical twin (QR/NFC scan) |
-| **Portal deep links** — the entry points portal menus/tabs/side-menus link to (e.g. list view vs calendar view) | `linkable` / `DeepLinkEntry` | Inside portal | Portal (menu picks the entry) |
+| **App pages** — the entry points portal menus/tabs link to and websites embed (e.g. list vs calendar; book vs my bookings) | `linkable` / `DeepLinkEntry` | Inside a host: portal or a website | The host: its signed-in session, plus the page's `accepts` params |
 | **Public views** — standalone external screens | `publicViews` (this block) | Outside portal | URL params only |
 
 #### `records`
@@ -443,6 +460,30 @@ lists it and draws its connect form and settings, and the integration engine cal
 functions (`testConnection`, `describeTarget`, `sample`, `fetch`, `shape`, `serialize`, `send`). It adapts the provider's format; core does each customer's mapping. The full
 contract is in the **[Connectors guide](connectors.md)**.
 
+#### `assistant`
+
+What the **Studio assistant** (the admin's own agent) knows about this app: skills and knowledge files
+shipped with the build and loaded into its box on demand, and an optional page that renders a planned
+change set before it is applied.
+
+```jsonc
+"assistant": {
+  "skills": [
+    { "name": "theme", "description": "Changing the Hub's colours, fonts or logo", "file": "assistant/skills/theme.md" },
+    { "name": "pages", "description": "Adding, ordering and editing pages and the menu", "file": "assistant/skills/pages.md" }
+  ],
+  "knowledge": [
+    { "name": "settings-schema", "description": "JSON Schema of the hub settings group", "file": "assistant/knowledge/settings.schema.json" }
+  ],
+  "preview": "/admin/preview?changeSet={id}"
+}
+```
+
+The files live under `public/assistant/` and ship with every release like any other static file. The
+assistant sees one line per skill (its description) and reads the file only when the job calls for it,
+so a big app can carry many skills at no cost to the conversation. Full guide, including what a skill
+should say and how the assistant changes config with undo: **[assistant-apps.md](assistant-apps.md)**.
+
 ---
 
 ## `app.admin.json`

package/docs/assistant-apps.md

@@ -0,0 +1,168 @@
+# The Studio assistant and your app
+
+SmartLinks admins have **one assistant**: an agent that works for the signed-in admin on one
+collection, with the admin's own authority, from a chat in Studio. It reads and changes data through
+the SmartLinks API, every write is a **change set** the admin can see and undo, and the things that
+can't be undone (deleting, sending, calling out, publishing, spending) wait for the admin's "Allow".
+
+This page is for app authors: how the assistant learns what your app is, how it is set up, and what it
+can do for the admin — without you building a chat of your own. Your app declares three things:
+
+| What | Where | Status |
+|---|---|---|
+| **Skills and knowledge** — plain-words procedures for the admin side, and the facts they need | `assistant` block in `app.manifest.json`, files under `public/assistant/` | this page |
+| **Tools** — logic the assistant should call rather than reimplement | server functions with an `agent` block (`audience: ["assistant"]` for assistant-only) | [agent-tools.md](agent-tools.md) |
+| **Setup** — questions, config schema, how to save | `app.admin.json` + `ai-guide.md` | [app-manifest.md](app-manifest.md#appadminjson) |
+
+An app with none of these still works with the assistant: it can read the app's records and config
+and change them through change sets. The declarations make it *good* at your app.
+
+## The `assistant` block
+
+```jsonc
+// app.manifest.json
+"assistant": {
+  "skills": [
+    { "name": "setup",  "description": "First-time setup of the FAQ app: categories, tone, who answers", "file": "assistant/skills/setup.md" },
+    { "name": "content", "description": "Adding, editing, ordering and retiring questions and answers",  "file": "assistant/skills/content.md" }
+  ],
+  "knowledge": [
+    { "name": "config-schema", "description": "JSON Schema of the app's config document", "file": "assistant/knowledge/config.schema.json" },
+    { "name": "examples",      "description": "Three worked examples of good FAQ content",   "file": "assistant/knowledge/examples.md" }
+  ],
+  "preview": "/admin/preview?changeSet={id}"
+}
+```
+
+The files sit in `public/assistant/` in your project and ship with every release like any other static
+file (they are read from the release's CDN folder, on the channel the collection runs your app on).
+
+### How they are loaded
+
+When an admin opens a chat, the assistant's box gets the **index** of every installed app's skills: one
+line each, the description. Nothing else. A skill's body, and the knowledge files it names, are read
+only when the assistant decides the job needs them. Twenty apps with three skills each cost the
+conversation about sixty lines. So: write several focused skills rather than one long one, and spend
+care on the description — it is how the assistant decides to open the file.
+
+### Writing a skill
+
+A skill is a markdown file: what this area of your app is for, what each setting means, how to read and
+change it, what a good result looks like, what to check afterwards. Write it for a capable colleague who
+has never seen your app. The assistant works through the SmartLinks API with a small CLI (`sl`), so say
+things in those terms:
+
+```markdown
+---
+name: faq-content
+description: Adding, editing, ordering and retiring questions and answers in the FAQ app
+---
+# FAQ content
+
+Questions live as app records of type `question` (`sl get app/faq/records recordType=question`).
+Fields: `data.question`, `data.answer` (markdown), `data.category` (one of the categories in the app's
+config, `sl get app/faq` → `categories[]`), `data.order` (ascending), `status` (`published` | `draft`).
+
+## Adding questions
+Plan one change set per batch: items `{ "op": "create", "entity": "record", "appId": "faq",
+"data": { "recordType": "question", "data": { … }, "status": "draft" } }`. Match on `data.question`
+(case-insensitive) before creating, so a re-run updates instead of duplicating.
+
+## A good answer
+Two to five sentences, plain words, no marketing. Link to a product page when one exists
+(`/p/<collectionId>/<productId>`). Never invent policy: if the answer depends on something the admin
+hasn't said (returns window, delivery areas), ask.
+
+## Check afterwards
+`sl get app/faq/records recordType=question status=draft` — read three back and make sure the
+category is one that exists.
+```
+
+The frontmatter is optional; when it is missing, the manifest entry's `name` and `description` are used.
+Keep a skill under a few hundred lines; put long reference material in knowledge files and name them.
+
+### Knowledge
+
+Knowledge files are what the skills refer to: the schema of your config document, record shapes, worked
+examples, a glossary of your app's words. The assistant reads them when a skill points at them (each
+skill is told where the app's knowledge files are).
+
+**Generate the schema, don't write it.** If your config is typed (a TypeScript interface, a zod schema),
+produce the JSON Schema at build time (`ts-json-schema-generator`, `zod-to-json-schema`) into
+`public/assistant/knowledge/`. A hand-written schema drifts the first week.
+
+## Tools: when a skill is not enough
+
+Nearly every admin action is a read or a patch of config or records, and the assistant does those
+itself. Give it a **tool** only when a step can't be an API call it makes on its own:
+
+- logic that lives in your code (validate a layout, render a page from a design direction, compute
+  something from your data model),
+- a write that must be atomic across several objects,
+- anything that needs your app's secrets.
+
+A tool is an http server function with an `agent` block
+([agent-tools.md](agent-tools.md)); the assistant calls it as
+`sl post app/<appId>/functions/<name> '{ … }'`, under the function's own visibility, authority and
+capabilities. Set `"audience": ["assistant"]` to keep an assistant-only tool out of your in-app and
+public agent runs:
+
+```jsonc
+{
+  "name": "applyDesignDirection",
+  "trigger": { "type": "http" },
+  "visibility": "admin",
+  "authority": "caller",
+  "capabilities": ["sl:settings:write"],
+  "agent": {
+    "tool": true,
+    "title": "Apply a design direction",
+    "description": "Rewrites the theme, fonts and layout of the hub to match a named direction.",
+    "input": { "type": "object", "properties": { "direction": { "type": "string" } }, "required": ["direction"] },
+    "audience": ["assistant"]
+  }
+}
+```
+
+A tool that changes config should **return the patch, not apply it**, so the assistant can put it in a
+change set and the admin keeps undo. Tools that act directly are fine for reads and computations.
+
+## How the assistant changes your config
+
+Your config document (`SL.appConfiguration`, `sl get app/<appId>`) and the collection's settings
+groups (`sl get settings/<group>`) are changed through change-set items:
+
+```jsonc
+{ "op": "update", "entity": "appConfig", "id": "<appId>", "data": { "theme": { "accent": "#0a7" } } }
+{ "op": "update", "entity": "appConfig", "id": "<appId>", "scope": { "productId": "p1" }, "data": { … } }
+{ "op": "update", "entity": "settings",  "id": "hub", "data": { "pages": { "about": { … } } } }
+```
+
+Saves deep-merge, as your own admin UI's saves do (nested objects merge, arrays replace). The whole
+document before the change is kept, so **undo puts it back exactly**. Say in your skills which keys
+are arrays, so the assistant sends the whole array when it changes one element.
+
+### Preview before apply
+
+A planned change set can be rendered before it is applied. The API gives, for every document a set
+touches, the live document and the document as it would become:
+
+```
+GET /admin/collection/:collectionId/assistant/changesets/:id/preview
+→ { id, status, targets: [ { entity, id, scope?, before, after, ops } ] }
+```
+
+Declare `assistant.preview` — a page of your admin surface that takes `{id}`, calls that endpoint
+with the admin's session, and renders `targets[].after` as your app would render the live config. The
+Studio panel then shows "Preview" on the change set, and the admin sees the result before saying yes.
+
+## Checklist
+
+- `assistant.skills[]`: several focused skills with descriptions that say when they apply.
+- `assistant.knowledge[]`: the config schema generated from your types; record shapes; examples.
+- Every skill says which fields are arrays, what to match on before creating, what to check after.
+- Logic the assistant can't reproduce: a server function with `agent.tool` and `audience: ["assistant"]`,
+  returning a patch for config changes.
+- `assistant.preview` when your app has a visual surface worth seeing before a change lands.
+- `ai-guide.md` still describes first-time setup for the setup wizard; the assistant reads it too when
+  an app declares no skills.

package/docs/deep-link-discovery.md

@@ -172,6 +172,9 @@ Both sources use the same entry shape:
 
 ```typescript
 interface DeepLinkEntry {
+  /** Stable id, unique within the app (optional): hosts and websites refer to the page by it */
+  id?: string;
+
   /** Human-readable label for this state (required) */
   title: string;
 
@@ -193,6 +196,13 @@ interface DeepLinkEntry {
    */
   params?: Record<string, string>;
 
+  /**
+   * The params a host may supply when it opens this page (optional), e.g. a booking page that can
+   * start on one service: `{ optional: ['service', 'staff', 'date'] }`. `params` are pinned by the
+   * entry; `accepts` are filled in by whoever opens it.
+   */
+  accepts?: { required?: string[]; optional?: string[] };
+
   /**
    * When `true`, this entry is also available as a dynamic data context for widgets.
    *
@@ -211,7 +221,9 @@ interface DeepLinkEntry {
 |-------|----------|-------|
 | `title` | ✅ | Displayed in menus and offered to AI agents. Should be concise and human-readable. |
 | `path` | ❌ | Hash route within the app. Defaults to `/` if omitted. |
+| `id` | ❌ | Stable id for hosts and websites to refer to the page by. |
 | `params` | ❌ | App-specific query params only. Platform params are injected automatically. |
+| `accepts` | ❌ | The params whoever opens the page may supply (`required` / `optional`). |
 | `widget` | ❌ | Set to `true` to make this entry selectable in the widget config picker as a dynamic data context. |
 
 > **Tip:** Different entries can share the same `path` if they differ by `params` — for example, two entries pointing at `/settings` with different `tab` params.

package/docs/iframe-responder.md

@@ -103,6 +103,7 @@ interface IframeResponderOptions {
   version?: 'stable' | 'development'; // App version (default: 'stable')
   appUrl?: string;              // Override URL (for local dev)
   initialPath?: string;         // Initial hash path (e.g., '/settings')
+  params?: Record<string, string>; // The page's own params (e.g. { service: 'svc_123' }); context params win
   
   // Data
   cache?: CachedData;           // Pre-cached data

package/docs/websites.md

@@ -66,6 +66,32 @@ bytes. `_server/` is never served to visitors.
   doing work that belongs in a server function or a scheduled job.
 - **No secrets** in the server bundle and no Node built-ins beyond `nodejs_compat`.
 
+## Using another app's pages
+
+Some apps do a job a site shouldn't rebuild: a booking journey holds the time rules, the clash
+handling and the confirmation; "my bookings" holds who may change what. Those apps declare their pages
+in `linkable` (app-manifest.md), each with a stable `id`, a `path` and the params it `accepts`. A site
+embeds one with **`IframeResponder`** (iframe-responder.md), from the browser:
+
+```typescript
+const site = SL.site.current()
+const responder = new SL.IframeResponder({
+  collectionId: site.collectionId,
+  appId: 'appointments',            // the app's id on this collection
+  initialPath: '/my-bookings',      // the page's `path`
+  params: { service: 'svc_123' },   // what the page `accepts`
+  onResize: (h) => { iframe.style.height = `${h}px` },
+})
+iframe.src = await responder.attach(iframe)
+```
+
+- **The visitor's session goes with it.** The page's API calls are proxied through the site, so it
+  acts as whoever is signed in to the site (or as a guest). Never pass a token in the URL.
+- **The app must be installed** on the site's collection; its address comes from there.
+- **Show the app's content natively where you can** (its `headless` data: services, staff, events)
+  for your own design and SEO, and embed the page only for the part that does the work.
+- Pages render on the client, after load: they aren't part of the server-rendered HTML.
+
 ## Caching
 
 The router keeps a rendered page at the edge when your response says it may:

package/openapi.yaml

@@ -19909,6 +19909,8 @@ components:
     DeepLinkEntry:
       type: object
       properties:
+        id:
+          type: string
         title:
           type: string
         path:
@@ -19917,6 +19919,8 @@ components:
           type: object
           additionalProperties:
             type: string
+        accepts:
+          $ref: "#/components/schemas/PublicViewParams"
         widget:
           type: object
           additionalProperties: true
@@ -20134,6 +20138,14 @@ components:
           enum:
             - auto
             - require
+        audience:
+          type: array
+          items:
+            type: string
+            enum:
+              - app
+              - public
+              - assistant
       required:
         - tool
     AppManifestFunctions:
@@ -20631,6 +20643,8 @@ components:
           $ref: "#/components/schemas/AppHeadlessDeclaration"
         connector:
           $ref: "#/components/schemas/AppConnectorDeclaration"
+        assistant:
+          $ref: "#/components/schemas/AppAssistantDeclaration"
       required:
         - name
         - version
@@ -20638,6 +20652,31 @@ components:
         - function
         - files
         - components
+    AppAssistantFile:
+      type: object
+      properties:
+        name:
+          type: string
+        description:
+          type: string
+        file:
+          type: string
+      required:
+        - name
+        - file
+    AppAssistantDeclaration:
+      type: object
+      properties:
+        skills:
+          type: array
+          items:
+            $ref: "#/components/schemas/AppAssistantFile"
+        knowledge:
+          type: array
+          items:
+            $ref: "#/components/schemas/AppAssistantFile"
+        preview:
+          type: string
     ConnectorConnectionField:
       type: object
       properties:
@@ -27652,6 +27691,10 @@ components:
           type: string
         initialPath:
           type: string
+        params:
+          type: object
+          additionalProperties:
+            type: string
         isAdmin:
           type: boolean
         cache:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@proveanything/smartlinks",
-  "version": "2.1.2",
+  "version": "2.1.4",
   "description": "Official JavaScript/TypeScript SDK for the Smartlinks API",
   "type": "module",
   "main": "dist/index.js",