@proveanything/smartlinks 1.6.7 → 1.7.1

package/dist/docs/interactions.md

@@ -0,0 +1,291 @@
+# Interactions: Event Tracking & Analytics
+
+The `interactions` namespace is a **critical pattern** for tracking user engagement. Many apps rely heavily on it for logging events that can trigger journeys, feed analytics dashboards, and drive aggregated results such as vote counts.
+
+---
+
+## Overview
+
+Interactions have two distinct layers:
+
+| Layer | Purpose |
+|-------|---------|
+| **Interaction Types** | Definitions stored in the database — configure an interaction's ID, permissions, and display metadata once per collection |
+| **Interaction Events** | Individual event records logged each time a user performs that interaction |
+
+```text
+┌──────────────────────────────────────────────────────────────────┐
+│ Your App                                                         │
+│                                                                  │
+│  1. Create type once:  interactions.create(collectionId, {       │
+│       id: 'vote', permissions: { uniquePerUser: true } })        │
+│                                                                  │
+│  2. Log events:        interactions.appendEvent(collectionId, {  │
+│       interactionId: 'vote', outcome: 'option-a', userId })      │
+│                                                                  │
+│  3. Read results:      interactions.countsByOutcome(collectionId, │
+│       { interactionId: 'vote' })                                 │
+│       → [{ outcome: 'option-a', count: 42 }, ...]               │
+└──────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Common Use Cases
+
+| Use Case | `interactionId` example | `outcome` example |
+|----------|-------------------------|-------------------|
+| Competition entry | `competition-entry` | `"entered"` |
+| Voting / polling | `vote` | `"option-a"` |
+| Mailing list signup | `newsletter-signup` | `"subscribed"` |
+| Warranty registration | `warranty-registration` | `"activated"` |
+| Product scan / view | `product-view` | `"scanned"` |
+| Form submission | `registration-form` | `"submitted"` |
+
+---
+
+## Interaction Types (Definitions)
+
+Interaction types are defined once per collection and control permissions, display metadata, and uniqueness constraints.
+
+### Create a Type
+
+```typescript
+await SL.interactions.create(collectionId, {
+  id: 'vote',
+  appId: 'my-app',
+  permissions: {
+    allowPublicSubmit: true,
+    uniquePerUser: true,
+    startAt: '2026-06-01T00:00:00Z',
+    endAt: '2026-06-30T23:59:59Z',
+    allowPublicSummary: true,
+  },
+  data: {
+    display: {
+      title: 'Vote',
+      description: 'Cast your vote for the competition.',
+    },
+  },
+});
+```
+
+### Update / Delete a Type
+
+```typescript
+// Update permissions or display
+await SL.interactions.update(collectionId, 'vote', {
+  permissions: { endAt: '2026-07-15T23:59:59Z' },
+});
+
+// Delete the definition (does not delete existing events)
+await SL.interactions.remove(collectionId, 'vote');
+```
+
+### List / Get Types
+
+```typescript
+// Admin: list all types for an app
+const { items } = await SL.interactions.list(collectionId, { appId: 'my-app' });
+
+// Admin: get a single type
+const type = await SL.interactions.get(collectionId, 'vote');
+
+// Public: list available types (respects permissions)
+const { items } = await SL.interactions.publicList(collectionId, { appId: 'my-app' });
+```
+
+---
+
+## Logging Events
+
+### Admin Event Append
+
+Use on the server side or in admin flows. Requires `userId` **or** `contactId`.
+
+```typescript
+await SL.interactions.appendEvent(collectionId, {
+  appId: 'my-app',
+  interactionId: 'vote',
+  outcome: 'option-a',      // The result / choice — used by countsByOutcome()
+  userId: 'user_abc123',    // One of userId or contactId is required
+  productId: 'prod_xyz',    // Optional — scope to a specific product
+  scope: 'round-1',         // Optional — custom segmentation string
+  metadata: { source: 'mobile', region: 'UK' },
+});
+```
+
+### Public Event Submit
+
+Use in client-side app code. Same body shape as `appendEvent` but hits the public endpoint (respects interaction permissions like `allowPublicSubmit`, `requireAuth`).
+
+```typescript
+await SL.interactions.submitPublicEvent(collectionId, {
+  appId: 'my-app',
+  interactionId: 'competition-entry',
+  outcome: 'entered',
+  userId: currentUser.id,
+  metadata: { answer: 'Paris' },
+});
+```
+
+### Update an Existing Event
+
+```typescript
+await SL.interactions.updateEvent(collectionId, {
+  eventId: 'evt_abc123',    // Required — the event to update
+  interactionId: 'vote',
+  userId: 'user_abc123',
+  outcome: 'option-b',      // Override the outcome
+  status: 'deleted',        // Soft-delete the event
+});
+```
+
+### Event Body Fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `interactionId` | string | ✅ | Which interaction type this event belongs to |
+| `userId` or `contactId` | string | ✅ (one of) | The actor. `appendEvent` / `updateEvent` require one of these |
+| `appId` | string | ❌ | Scopes the event to your app |
+| `outcome` | string | ❌ | The result or choice — what `countsByOutcome()` aggregates |
+| `scope` | string | ❌ | Custom segmentation (e.g., `"round-1"`, `"region-uk"`) |
+| `productId` | string | ❌ | Scope to a product |
+| `proofId` | string | ❌ | Scope to a proof |
+| `broadcastId` | string | ❌ | Links the event to a broadcast campaign |
+| `journeyId` | string | ❌ | Links the event to a journey run |
+| `metadata` | object | ❌ | Arbitrary extra data stored with the event |
+| `timestamp` | string | ❌ | ISO datetime override (defaults to server time) |
+| `source` | string | ❌ | Free-text source tag (e.g., `"mobile"`, `"email-link"`) |
+
+---
+
+## Reading Results
+
+### Counts by Outcome (Aggregations)
+
+The primary analytics function — returns how many times each outcome was recorded:
+
+```typescript
+// Admin (full access, deduplication options)
+const results = await SL.interactions.countsByOutcome(collectionId, {
+  appId: 'my-app',
+  interactionId: 'vote',
+  scope: 'round-1',       // Optional — filter by scope
+  from: '2026-06-01',     // Optional — date range
+  to: '2026-06-30',
+  dedupeLatest: true,     // Count only the latest event per user (for re-votes)
+});
+// Returns: [{ outcome: 'option-a', count: 42 }, { outcome: 'option-b', count: 37 }]
+
+// Public (respects allowPublicSummary permission)
+const results = await SL.interactions.publicCountsByOutcome(
+  collectionId,
+  { appId: 'my-app', interactionId: 'vote' },
+  authToken     // Optional — pass if user is authenticated
+);
+```
+
+### Query Event History
+
+Flexible admin query for raw interaction events:
+
+```typescript
+const events = await SL.interactions.query(collectionId, {
+  appId: 'my-app',
+  interactionId: 'vote',
+  userId: 'user_abc123',      // Filter by user
+  outcome: 'option-a',        // Filter by outcome
+  from: '2026-06-01T00:00Z',
+  to: '2026-06-30T23:59Z',
+  limit: 100,
+  order: 'DESC',
+  latestPerEventId: true,     // Deduplicate: one row per interactionId per user
+  include: ['interaction'],   // Embed the interaction type definition in each row
+});
+```
+
+### Public: User's Own History
+
+Lets authenticated users see their own events:
+
+```typescript
+const myEvents = await SL.interactions.publicMyInteractions(
+  collectionId,
+  { appId: 'my-app', interactionId: 'vote' },
+  authToken
+);
+```
+
+---
+
+## Permissions Reference
+
+Set on the interaction type definition via `permissions`:
+
+| Permission | Type | Description |
+|------------|------|-------------|
+| `enabled` | boolean | Master on/off switch for submissions (default: enabled) |
+| `allowPublicSubmit` | boolean | Allow unauthenticated / public submissions |
+| `allowAnonymousSubmit` | boolean | Allow submissions without any session |
+| `requireAuth` | boolean | Block submissions unless user is authenticated |
+| `allowedOrigins` | string[] | Restrict to specific site domains (substring match) |
+| `startAt` | string (ISO) | Earliest time submissions are accepted |
+| `endAt` | string (ISO) | Latest time submissions are accepted |
+| `uniquePerUser` | boolean | Prevent duplicate submissions per user |
+| `uniquePerUserWindowSeconds` | number | Time window for uniqueness (e.g., `86400` = 1 day) |
+| `uniqueOutcome` | string | Outcome tag to check for duplicates (e.g., `"submitted"`) |
+| `allowPublicSummary` | boolean | Show counts/aggregates to unauthenticated users |
+| `allowAuthenticatedSummary` | boolean | Show counts/aggregates to authenticated users |
+| `allowOwnRead` | boolean | Let users read their own event history via public API |
+
+---
+
+## Integration with Journeys
+
+Interactions are the primary bridge between user actions and automated workflows:
+
+```text
+User submits interaction event
+        ↓
+Platform emits event to Journey trigger
+        ↓
+Journey step runs: send confirmation email, update CRM, award points, etc.
+```
+
+When defining a journey trigger, reference the `interactionId` that should fire it. The interaction `outcome` and `metadata` are available as variables in journey steps.
+
+---
+
+## TypeScript Types
+
+```typescript
+import type {
+  AppendInteractionBody,          // Event body for appendEvent / submitPublicEvent
+  UpdateInteractionBody,          // Event body for updateEvent
+  InteractionEventRow,            // Raw event record returned by query()
+  OutcomeCount,                   // { outcome: string | null; count: number }
+  InteractionPermissions,         // Full permissions config shape
+  InteractionTypeRecord,          // Definition record from create() / get()
+  InteractionTypeList,            // { items, limit, offset }
+  CreateInteractionTypeBody,      // Body for create()
+  UpdateInteractionTypeBody,      // Body for update()
+  AdminInteractionsQueryRequest,  // query() filter options
+  AdminInteractionsCountsByOutcomeRequest,
+  PublicInteractionsCountsByOutcomeRequest,
+  PublicInteractionsByUserRequest,
+} from '@proveanything/smartlinks';
+```
+
+---
+
+## Best Practices
+
+- Use descriptive `interactionId` values: `warranty-registration`, `competition-entry`, `newsletter-vote`
+- Use `outcome` to capture the choice — it's the key field that `countsByOutcome()` aggregates on
+- Include `metadata` for richer analytics and debugging (`source`, `device`, `region`, etc.)
+- Use `uniquePerUser: true` for actions that should only happen once (votes, registrations)
+- Set `startAt`/`endAt` on the type definition — don't enforce time limits in app code
+- Use `scope` to segment a single interaction type across multiple rounds, regions, or variants
+- Prefer `submitPublicEvent` in client-side widget code; use `appendEvent` in server-side / admin flows
+- Keep `getSEO()` and `getLLMContent()` calls separate from interaction submission paths

package/dist/docs/manifests.md

@@ -0,0 +1,200 @@
+# AI-Native App Manifests
+
+SmartLinks apps are designed to be **AI-discoverable, AI-configurable, and AI-importable**. Every app ships with a structured manifest and a prose guide that allow AI systems to set up, configure, and populate apps without custom integration code.
+
+---
+
+## The Split Manifest
+
+The manifest is split into two files so the public portal never loads admin-only configuration data.
+
+```text
+app.manifest.json   ←  lean, always loaded (widget render, SEO, executor discovery)
+app.admin.json      ←  loaded on-demand (setup wizards, import, AI config flows)
+```
+
+### `app.manifest.json` — always loaded
+
+| Section | Purpose | AI Consumer |
+|---------|---------|-------------|
+| `meta` | App identity, version, appId, SEO priority | All workflows |
+| `admin` | Pointer to `app.admin.json` | Admin orchestrators |
+| `widgets` | Bundle files + component definitions + settings schemas | Widget Builder |
+| `containers` | Bundle files + component definitions | Container Loader |
+| `executor` | Bundle files, factory name, exports list | Server / AI |
+| `linkable` | Static deep-link routes | Portal menus / AI nav |
+
+```json
+{
+  "meta": { "name": "My App", "appId": "my-app", "version": "1.0.0" },
+  "admin": "app.admin.json",
+  "widgets": {
+    "files": {
+      "js": { "umd": "dist/widgets.umd.js", "esm": "dist/widgets.es.js" },
+      "css": null
+    },
+    "components": [
+      {
+        "name": "MyWidget",
+        "description": "Compact summary card.",
+        "sizes": ["compact", "standard", "large"],
+        "settings": { ... }
+      }
+    ]
+  },
+  "containers": {
+    "files": {
+      "js": { "umd": "dist/containers.umd.js", "esm": "dist/containers.es.js" },
+      "css": null
+    },
+    "components": [{ "name": "PublicContainer", "description": "Full app view." }]
+  },
+  "executor": {
+    "files": { "js": { "umd": "dist/executor.umd.js", "esm": "dist/executor.es.js" } },
+    "factory": "createMyAppExecutor",
+    "exports": ["createMyAppExecutor", "getSEO", "getLLMContent"],
+    "description": "Programmatic configuration and SEO API for My App."
+  },
+  "linkable": [
+    { "title": "Home", "path": "/" },
+    { "title": "Gallery", "path": "/gallery" }
+  ]
+}
+```
+
+> ⚠️ **`css` is `null` by default.** Most widgets and containers use Tailwind/shadcn classes inherited from the parent and produce **no CSS output file**. Set `"css": null` in the manifest. Only set it to a filename if your widget/container ships a custom CSS file that actually exists in `dist/`. The parent portal checks this value before injecting a `<link>` tag — a non-null value pointing to a missing file will cause a 404.
+
+---
+
+### `app.admin.json` — loaded on-demand
+
+| Section | Purpose | AI Consumer |
+|---------|---------|-------------|
+| `aiGuide` | Pointer to `ai-guide.md` prose instructions | All AI workflows |
+| `setup` | Setup wizard: questions, config schema, save instructions | Setup Wizard |
+| `import` | Bulk data import: field definitions, CSV shape, API calls | Data Importer |
+| `tunable` | Runtime-adjustable settings | AI Optimizer |
+| `metrics` | Tracked interactions and KPIs | Analytics Advisor |
+
+The admin orchestrator fetches the manifest, reads the `admin` pointer, and fetches `app.admin.json` only when needed — never on public page loads.
+
+See the [App Configuration Files reference](app-manifest.md) for the full field-by-field schema for both files.
+
+---
+
+## Widget Settings Schema
+
+Each widget component in `app.manifest.json` should include a `settings` object using **JSON Schema** to describe its configurable props. This enables schema-form libraries and AI orchestrators to auto-generate configuration UIs without per-widget code.
+
+```json
+"components": [
+  {
+    "name": "MyWidget",
+    "description": "What this widget does",
+    "sizes": ["compact", "standard", "large"],
+    "settings": {
+      "type": "object",
+      "properties": {
+        "displayMode": {
+          "type": "string",
+          "title": "Display Mode",
+          "description": "How the widget renders",
+          "enum": ["compact", "standard", "large"],
+          "enumLabels": {
+            "compact": "Icons only",
+            "standard": "With names",
+            "large": "Full cards"
+          },
+          "default": "standard",
+          "order": 1
+        },
+        "showImage": {
+          "type": "boolean",
+          "title": "Show Product Image",
+          "default": true,
+          "order": 2
+        }
+      }
+    }
+  }
+]
+```
+
+| Field | Purpose |
+|-------|---------|
+| `type`, `enum` | Standard JSON Schema for validation |
+| `title` | Human-readable label for form rendering |
+| `description` | Help text shown alongside the field |
+| `enumLabels` | Friendly display names for enum values (`{ value → label }`) |
+| `default` | Pre-selected value when no configuration exists |
+| `order` | Field display order in rendered forms (lower number = higher position) |
+
+The `settings` schema serves dual purposes: AI orchestrators use it to understand what a widget accepts and generate configuration conversationally; schema-form renderers (e.g., in admin consoles) use it to auto-generate settings UIs.
+
+---
+
+## The AI Guide (`ai-guide.md`)
+
+A companion Markdown file deployed alongside the manifest provides **natural-language instructions** for AI orchestrators. The admin config references it via `"aiGuide": "ai-guide.md"` — orchestrators resolve and fetch it relative to the manifest URL.
+
+While the manifest is structured data, the AI guide provides prose context, nuance, and step-by-step instructions that help an LLM drive setup wizards, imports, and troubleshooting flows conversationally.
+
+Use the [AI Guide Template](ai-guide-template.md) as your starting point.
+
+---
+
+## Three AI Workflows
+
+### 1. Widget Builder
+
+An AI fetches `app.manifest.json`, reads `widgets.components[]` including the `settings` JSON Schema for each widget, and can:
+- Generate React code to embed the widget with correct props
+- Auto-render a configuration UI from the settings schema
+- Understand valid size hints and required vs optional props
+
+### 2. Setup Wizard
+
+An AI reads `setup` from `app.admin.json` to drive a conversational configuration flow:
+
+1. Walk the user through each `setup.questions[]` entry
+2. Validate answers against `setup.configSchema` (JSON Schema)
+3. Optionally use `setup.contentHints` to auto-generate content via `SL.ai.chat.completions`
+4. Save using the `setup.saveWith` instructions (method, scope, admin flag)
+
+The AI guide (`ai-guide.md`) provides prose instructions on how to handle each question, what sensible defaults look like, and what to do if the user is unsure.
+
+### 3. Data Importer
+
+An AI reads `import` from `app.admin.json` to:
+
+1. Generate a CSV template from `import.fields[]` (with types, required flags, and examples)
+2. Normalise user-provided data against field types
+3. Call `import.saveWith.method` for each row
+
+For multi-app imports, fields from multiple manifests can be merged into a single CSV template.
+
+---
+
+## Maintaining the Manifest
+
+When you change your app's configuration shape, update all three files together:
+
+| File | What to update |
+|------|---------------|
+| `app.manifest.json` | `widgets.components[].settings`, `containers`, `executor.exports`, `linkable` |
+| `app.admin.json` | `setup.questions`, `setup.configSchema`, `import.fields`, `tunable.fields` |
+| `ai-guide.md` | Prose instructions, validation rules, examples, and any new question guidance |
+
+Keeping all three in sync ensures AI orchestrators, setup wizards, and data importers all work from consistent, accurate information.
+
+---
+
+## Related Guides
+
+| Guide | What it covers |
+|-------|---------------|
+| [App Configuration Files](app-manifest.md) | Full field-by-field reference for both JSON files |
+| [Executor Model](executor.md) | Building `executor.umd.js` — SEO, LLM content, config mutations |
+| [Deep Link Discovery](deep-link-discovery.md) | `linkable` — static and dynamic navigable states |
+| [AI Guide Template](ai-guide-template.md) | Starter template for `ai-guide.md` |
+| [AI & Chat Completions](ai.md) | `SL.ai` — used in `contentHints` auto-generation |

package/dist/docs/mpa.md

@@ -0,0 +1,135 @@
+# Multi-Page App (MPA) Architecture
+
+SmartLinks apps use Vite's multi-page build to produce **separate bundles** for public and admin interfaces. This keeps the public bundle lean even as admin features grow.
+
+---
+
+## Why Multi-Page?
+
+| Entry Point | HTML file | Purpose | Bundle target |
+|-------------|-----------|---------|---------------|
+| Public Portal | `index.html` | End-user interface | Lean, mobile-optimised |
+| Admin Console | `admin.html` | Configuration & management | Can grow large |
+
+Because `AdminApp.tsx` and its heavy dependencies are **never imported** into the public entry point, the public bundle stays small regardless of how complex the admin UI becomes:
+
+| Scenario | Public bundle | Admin bundle |
+|----------|--------------|-------------|
+| App template (baseline) | ~150 KB | ~150 KB |
+| Rich admin (future) | ~150 KB | ~500 KB+ |
+
+---
+
+## Entry Points
+
+| File | Loads | Routes |
+|------|-------|--------|
+| `index.html` → `src/PublicApp.tsx` | Public routes only | `/#/`, `/#/__dev` (dev only) |
+| `admin.html` → `src/AdminApp.tsx` | Admin routes only | `/#/`, `/#/settings`, … |
+
+Both use `HashRouter` for iframe compatibility — the hash keeps routing client-side so the server always serves the same HTML file regardless of the route.
+
+### Development Helper: `/#/__dev`
+
+The `/#/__dev` route is a hidden helper page available **in dev mode only**. It provides:
+- URL parameter testing and context injection
+- Quick navigation to public / admin views
+- Widget preview at all three sizes
+- Context documentation inline
+
+It is lazy-loaded and **stripped from production builds**.
+
+---
+
+## Build Pipeline
+
+The build runs **five sequential steps**, each appending to `dist/` — no step wipes the output directory:
+
+```
+vite build
+  && vite build --config vite.config.widget.ts
+  && vite build --config vite.config.container.ts
+  && vite build --config vite.config.executor.ts
+  && node scripts/hash-bundles.mjs
+```
+
+| Step | Config / Script | Gate env var | Output |
+|------|----------------|-------------|--------|
+| 1 | `vite.config.ts` | Always runs | `index.html`, `admin.html`, `assets/*` |
+| 2 | `vite.config.widget.ts` | `VITE_ENABLE_WIDGETS=true` | `widgets.umd.js`, `widgets.es.js`, `widgets.css` |
+| 3 | `vite.config.container.ts` | `VITE_ENABLE_CONTAINERS=true` | `containers.umd.js`, `containers.es.js`, `containers.css` |
+| 4 | `vite.config.executor.ts` | `VITE_ENABLE_EXECUTOR!=false` | `executor.umd.js`, `executor.es.js` |
+| 5 | `scripts/hash-bundles.mjs` | Always runs | Renames bundles with content hashes; patches `dist/app.manifest.json` |
+
+Steps 2–4 produce a harmless stub file when their gate env var is not set. Step 5 detects and skips stub files automatically.
+
+**Convenience scripts:**
+
+```bash
+npm run build              # Full pipeline
+npm run build:widgets      # Widget build only (step 2)
+npm run build:containers   # Container build only (step 3)
+npm run build:executor     # Executor build only (step 4)
+```
+
+---
+
+## Content-Hashed Bundles
+
+Widget, container, and executor bundles are renamed with an 8-character content hash after the build (e.g., `widgets.umd.js` → `widgets-a3b4c5d6.umd.js`). The post-build script (`scripts/hash-bundles.mjs`) patches `dist/app.manifest.json` with the hashed filenames.
+
+This enables aggressive CDN caching:
+- The **manifest** is served with no cache / short TTL — it always reflects current filenames
+- The **bundles** use permanent caching (e.g., `Cache-Control: max-age=31536000, immutable`) — any content change produces a new hash and a new URL
+
+The source `public/app.manifest.json` keeps template names (e.g., `widgets.umd.js`). Only the built copy in `dist/` gets the hashed filenames patched in.
+
+---
+
+## Build Output
+
+```
+dist/
+├── index.html                      ← Public portal entry
+├── admin.html                      ← Admin console entry
+├── app.manifest.json               ← Patched with hashed bundle filenames
+├── assets/
+│   ├── index-[hash].js             ← Public bundle (lean)
+│   ├── admin-[hash].js             ← Admin bundle (can be large)
+│   └── shared-[hash].js            ← Shared chunks (UI components, etc.)
+├── widgets-[hash].umd.js           ← Widget bundle (UMD)
+├── widgets-[hash].es.js            ← Widget bundle (ESM)
+├── widgets-[hash].css              ← Widget styles (only if custom CSS exists)
+├── containers-[hash].umd.js        ← Container bundle (UMD)
+├── containers-[hash].es.js         ← Container bundle (ESM)
+├── containers-[hash].css           ← Container styles (only if custom CSS exists)
+├── executor-[hash].umd.js          ← Executor bundle (UMD)
+└── executor-[hash].es.js           ← Executor bundle (ESM)
+```
+
+> Widget and container CSS files are only present when the bundle ships custom styles. Most apps set `"css": null` in the manifest because they rely entirely on Tailwind/shadcn from the parent. See the [AI-Native App Manifests](manifests.md) guide for the CSS null warning.
+
+---
+
+## Platform Integration
+
+The parent SmartLinks platform embeds apps via iframe:
+
+| Context | URL pattern |
+|---------|------------|
+| Portal (public) | `https://app.example.com/#/?collectionId=...&appId=...` |
+| Admin Console | `https://app.example.com/admin.html#/?collectionId=...&appId=...` |
+
+Context parameters (`collectionId`, `appId`, `productId`, `proofId`) are passed as URL query params and read via the iframe responder. See the [iframe Responder guide](iframe-responder.md) for the full context injection API.
+
+---
+
+## Related Guides
+
+| Guide | What it covers |
+|-------|---------------|
+| [Widgets](widgets.md) | Widget bundle: components, props, settings |
+| [Containers](containers.md) | Container bundle: full-app embeds |
+| [Executor Model](executor.md) | Executor bundle: SEO, LLM content, config mutations |
+| [AI-Native App Manifests](manifests.md) | How manifests wire all bundles together for AI discovery |
+| [iframe Responder](iframe-responder.md) | Reading context params inside the iframe |