@noodleseed/agent-kit 0.74.0 → 0.76.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.74.0",
+  "version": "0.76.0",
   "private": false,
   "description": "Self-checking, self-updating agent skills for the Noodle Seed CLI. Authored in this repo by @noodle-borg/agent-kit; this is the published, independently-versioned canonical skills artifact the CLI fetches and verifies.",
   "license": "Apache-2.0",

package/skills/claude-code/SKILL.md

@@ -3,7 +3,7 @@ name: noodle-seed
 description: "Use when building, validating, testing, deploying, or operating a local or hosted Noodle Seed MCP server or app authored in TypeScript with the noodle CLI."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.76.0 hash:13ddce01769caae4 -->
 
 # Noodle Seed
 

package/skills/claude-code/authoring-mcp-servers/SKILL.md

@@ -3,7 +3,7 @@ name: authoring-mcp-servers
 description: "Use when creating or extending a headless Noodle Seed MCP server, tool, resource, prompt, or typed model-facing capability."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:11523cb33b9473c0 -->
+<!-- noodle-skill version:0.76.0 hash:11523cb33b9473c0 -->
 
 # authoring-mcp-servers
 

package/skills/claude-code/building-mcp-apps/SKILL.md

@@ -3,7 +3,7 @@ name: building-mcp-apps
 description: "Use when a Noodle Seed MCP App, widget, interactive card, visual interaction, or host-visible UI is the primary requested outcome."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:9fd67d4d24328e15 -->
+<!-- noodle-skill version:0.76.0 hash:9fd67d4d24328e15 -->
 
 # building-mcp-apps
 

package/skills/claude-code/connecting-apis-to-mcp/SKILL.md

@@ -3,7 +3,7 @@ name: connecting-apis-to-mcp
 description: "Use when all four API-evidence inputs exist—and only then: API base URL, authentication scheme, representative safe read, and observed response."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:21bbd3ec441ffd30 -->
+<!-- noodle-skill version:0.76.0 hash:21bbd3ec441ffd30 -->
 
 # connecting-apis-to-mcp
 

package/skills/claude-code/creating-product-agent-guides/SKILL.md

@@ -3,7 +3,7 @@ name: creating-product-agent-guides
 description: "Use when a Noodle Seed MCP server needs a new or revised product agent guide, App Package skill, or explicit product-skill regeneration."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:0fa48a82fe836cf0 -->
+<!-- noodle-skill version:0.76.0 hash:0fa48a82fe836cf0 -->
 
 # creating-product-agent-guides
 

package/skills/claude-code/debugging-mcp-delivery/SKILL.md

@@ -3,7 +3,7 @@ name: debugging-mcp-delivery
 description: "Use when an existing Noodle Seed MCP project has a concrete validation, runtime, connector, App, host, deployment, or production failure."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.76.0 hash:aa715bae12041d7c -->
 
 # debugging-mcp-delivery
 

package/skills/claude-code/deploying-mcp-services/SKILL.md

@@ -3,7 +3,7 @@ name: deploying-mcp-services
 description: "Use when the user explicitly requests a Noodle Seed hosted link, configuration write, deployment, access change, rollback, or connection write."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.76.0 hash:93e735b7ffb45df1 -->
 
 # deploying-mcp-services
 

package/skills/claude-code/designing-mcp-products/SKILL.md

@@ -3,7 +3,7 @@ name: designing-mcp-products
 description: "Use when a Noodle Seed MCP product idea needs conversational fit, user benefit, scope, interaction, or evidence design before implementation."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:78a6f181b61f92f1 -->
+<!-- noodle-skill version:0.76.0 hash:78a6f181b61f92f1 -->
 
 # designing-mcp-products
 

package/skills/claude-code/embedding-mcp-assistants/SKILL.md

@@ -3,7 +3,7 @@ name: embedding-mcp-assistants
 description: "Use when embedding a Noodle assistant into an existing SaaS or web application with browser, identity, session, and credential boundaries."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.76.0 hash:cc54a67f21c0ecdb -->
 
 # embedding-mcp-assistants
 

package/skills/claude-code/examples/acme-discovery/src/server.ts

@@ -200,8 +200,12 @@ const shortlistGetaway = tool('shortlist_getaway', {
 });
 
 // Grounding beyond the catalog: two controlled files answer policy/pricing/support questions with
-// citations, and Acme's live public site stays current through its search provider — no sync job,
-// no handwritten search tool. One declaration, one generated `search_destinations` capability.
+// citations, and Acme's live public site is crawled on deploy and re-crawled on the declared
+// refresh cadence — no sync job, no handwritten search tool. One declaration, one generated
+// `search_destinations` capability. The managed crawler and index are the defaults; a component
+// can instead bring its own via `crawler: firecrawl({ apiKey: secret('FIRECRAWL_API_KEY') })`
+// and `index: algolia({ appId: variable('ALGOLIA_APP_ID'), apiKey: secret('ALGOLIA_API_KEY') })`
+// — the code names the config, `noodle secrets|variables set` supplies the values.
 const destinations = knowledge('destinations', {
   title: 'Acme Getaways destinations',
   description: 'Public destination, pricing, cancellation, and support information.',
@@ -216,6 +220,7 @@ const destinations = knowledge('destinations', {
     site({
       origin: 'https://getaways.acme.example',
       include: ['/destinations/**', '/pricing', '/support'],
+      refresh: '12h',
     }),
   ],
 });

package/skills/claude-code/executing-noodle-plans/SKILL.md

@@ -3,7 +3,7 @@ name: executing-noodle-plans
 description: "Use when the user asks to execute an approved, decision-complete implementation plan for a Noodle Seed project task by task with test-first changes, review, recovery, and final verification."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.76.0 hash:6a9f132ddb79352e -->
 
 # Execute a Noodle Seed implementation plan
 

package/skills/claude-code/publishing-mcp-integrations/SKILL.md

@@ -3,7 +3,7 @@ name: publishing-mcp-integrations
 description: "Use when preparing, reviewing, or submitting a Noodle Seed MCP integration to a host or app directory."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.76.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

package/skills/claude-code/references/authoring-workflow.md

@@ -420,12 +420,14 @@ const product = knowledge('product', {
     file('./knowledge/faq.txt', { title: 'FAQ' }),
   ],
   sites: [
-    site({ origin: 'https://www.acme.example', include: ['/docs/**', '/pricing'] }),
+    site({ origin: 'https://www.acme.example', include: ['/docs/**', '/pricing'], refresh: '6h' }),
   ],
 });
 ```
 
-The compiler validates and hashes every document at build time (bad extensions, root escapes, symlinks, oversize, and non-UTF-8 fail `noodle validate` with the exact path); deployment publishes versioned files transactionally with the app and the provider keeps live-site content current. Component names are lowercase snake-case; each component implies exactly one generated bounded search capability with cited results.
+The compiler validates and hashes every document at build time (bad extensions, root escapes, symlinks, oversize, and non-UTF-8 fail `noodle validate` with the exact path); deployment publishes versioned files transactionally with the app, crawls declared sites, and re-crawls them on the `refresh` cadence (`15m`–`7d`, default daily; `noodle knowledge refresh <name>` crawls on demand). Component names are lowercase snake-case; each component implies exactly one generated bounded search capability with cited results.
+
+The managed crawler and managed index are the defaults and need no configuration. A component may instead bring its own crawler (`crawler: firecrawl({ apiKey: secret('FIRECRAWL_API_KEY') })` or `tavily(...)`) and/or its own index (`index: algolia({ appId: variable('ALGOLIA_APP_ID'), apiKey: secret('ALGOLIA_API_KEY') })` or `meilisearch({ host: variable(...), apiKey: secret(...) })`). The code declares only config names; operators supply values with `noodle secrets set` / `noodle variables set`, and deploy preflight fails closed naming any unset reference.
 
 ## Boundaries
 

package/skills/claude-code/references/cli-commands.md

@@ -87,7 +87,7 @@ Developer-facing `noodle` commands, grouped by area. Local authoring commands (`
 | Command | What it does |
 | :-- | :-- |
 | `noodle audit` | Operator governance audit status and event queries. |
-| `noodle knowledge` | Operator-only knowledge components: list and status (ADR 0202). |
+| `noodle knowledge` | Operator-only knowledge components: list, status, and refresh (ADR 0202). |
 | `noodle logs` | View service/deployment logs. |
 | `noodle metrics` | MCP analytics for a deployed server (volume, sessions, latency percentiles, two-tier errors, tools, clients). Agents: `noodle metrics --agent-output` for a health verdict + next actions. |
 | `noodle events` | The per-request MCP event stream with status/tool/client filters; `--session <id>` replays one session in order. Agents: add `--json` and filter (`--status tool_error\|mcp_error`) when debugging. |

package/skills/claude-code/references/embedded-assistant.md

@@ -84,6 +84,8 @@ At most one public surface (`public` or `mixed`) and at most one authenticated s
 
 A public surface **must** declare `capabilities`: the exact positive allowlist it may reach. It is required by the type, and it is the whole externally reachable surface — a reviewer should read it in one screenful. Anything absent stays private, and a capability added to the server later is excluded until someone lists it. `authenticatedWebsite` may also take `capabilities` to narrow the in-app surface; omitted, it projects the whole server.
 
+A public `embedId` Web Component automatically attaches bounded anonymous same-origin Markdown page context, never DOM text. It is untrusted and nonpersistent, falls back to the URL alone on failure, yields to explicit `pageContext`, and never runs for authenticated or headless clients.
+
 ### Mixed surfaces: let a visitor sign in mid-conversation
 
 Add `signIn: true` to a public surface when some capabilities need a signed-in visitor. The surface becomes `mixed`: anonymous visitors start immediately, an identity-dependent capability stays **visible** so the assistant can offer it, and reaching for it raises a sign-in prompt instead of executing.
@@ -96,9 +98,11 @@ access: publicWebsite({
 }),
 ```
 
-Elevation runs through the **host application own login**, never a Noodle-operated one. The widget raises `assistant-sign-in-requested` with a single-use `continuation`; the page signs the visitor in as it already does, then its backend POSTs that continuation to the session exchange **with its own client credentials**. Possession of the continuation alone elevates nothing, and the service checks the client tenant owns that conversation.
+Elevation runs through the **host application own login**, never a Noodle-operated one. The widget raises `assistant-sign-in-requested` with a single-use `signInTicket` in its detail; the page signs the visitor in as it already does, then its backend spends the ticket with `createAssistantSession({ ..., signInTicket })` from `@noodleseed/assistant/server` — the same session exchange, its own client credentials. A refused spend throws a typed `AssistantSessionExchangeError`: branch on `elevationRefusal` (`elevation_ticket_expired` re-prompt; `elevation_tenant_mismatch` alert, never retry). Possession of the ticket alone elevates nothing, and the service checks the client tenant owns that conversation. The ticket is not the server-held interaction continuation — that value never reaches browser code; this one exists to travel through the page.
+
+The conversation is kept server-side: same session, new token, the anonymous one dead. Set honest expectations in UI copy — the assistant **remembers** the conversation (recent history feeds the model), but no transcript is replayed to the browser, so after a full-page navigation the visible panel starts fresh. Say "the assistant remembers", never "your conversation will reappear". Do not build a second identity provider for this.
 
-The conversation is kept: same history, new token, the anonymous one dead. Do not build a second identity provider for this.
+When the login lives on a different origin (marketing site + app), the flow is: the visitor signs in via full-page redirect as the site already does; the backend spends the ticket presenting the **origin the conversation will continue on** (any origin in the deployment allowlist — elevation re-pins the session there, and CORS follows); the token reaches the widget through the customer own **same-origin** session endpoint on that origin. The redirect handoff is mandatory, not stylistic: the widget calls the session endpoint with `credentials: "same-origin"`, so pointing a marketing page at a cross-origin endpoint is a guaranteed cookie-less 401. Persist the ticket across the login redirect (single-use, expires in minutes); a refused origin does not burn it.
 
 A connector-backed side effect needs **two** independent declarations to be reachable from a public or mixed surface: inclusion in `capabilities` **and** `{ confirm: true }` on the operation. Signing in proves who the visitor is; it does not pre-authorize an effect, so confirmation still applies on a mixed surface. Confirmation is never authentication or business authorization — the customer backend still owns payload validation, abuse controls, and idempotency. Local or session-only widget state needs no confirmation.
 
@@ -181,7 +185,7 @@ Validate the active deployment, backend credential, exact origin, and delegated
 noodle assistant doctor --origin "$PUBLIC_APP_ORIGIN" --org <org> --app <app> --env <env>
 ```
 
-The doctor reads `NOODLE_ASSISTANT_CLIENT_ID` / `NOODLE_ASSISTANT_CLIENT_SECRET` or the saved mode-0600 client file and never prints the secret. Pass `--user-id <real-test-user>` only when the downstream exchange requires an existing application user. The assistant doctor does not supply application-specific routes; after the backend mints a routed session, invoke one representative safe read to verify its route-bound exchange and connector together.
+The doctor reads `NOODLE_ASSISTANT_CLIENT_ID` / `NOODLE_ASSISTANT_CLIENT_SECRET` or the saved mode-0600 client file and never prints the secret. Pass `--user-id <real-test-user>` only when the downstream exchange requires an existing application user. On a deployment with a mixed surface it also runs a synthetic sign-in round trip (`elevation` check): issue, claim, and elevate against a throwaway anonymous session on the same code path a real sign-in takes, proving the store is configured and that elevation rebinds the issuer basis to the backend client — so a green doctor now certifies the sign-in leg too, not just the authenticated exchange. The assistant doctor does not supply application-specific routes; after the backend mints a routed session, invoke one representative safe read to verify its route-bound exchange and connector together.
 
 ## Integrate the customer backend
 
@@ -584,7 +588,7 @@ noodle assistant embed --check --json
 noodle assistant embed --check --json --require-env EXAMPLE_DELEG_CLIENT_SECRET
 ```
 
-The check reports only required and missing environment names, never their values. It checks both `connect-src` and `frame-src` when a common static host CSP is determinable, fails on missing directives, and marks a dynamic expression unverified instead of guessing. Additional `--require-env` names are application-owned; use them for the customer side of delegated exchange or other backend-only integration requirements.
+The check reports only required and missing environment names, never their values. Pass `--surface public|mixed|authenticated` to match the deployment: `public` drops the backend client id/secret requirement (a public embed has neither), and `public`/`mixed` additionally require `script-src` — the one directive whose failure runs no widget code at all, so nothing can report it from inside the page. CSP directives verify against the service origin exactly, via the env placeholder, or through a covering wildcard (`https://*.example.com`); a dynamic expression is marked unverified instead of guessed. Additional `--require-env` names are application-owned; `--env-alias NAME=HOST_NAME` follows a host repo that names an env var differently.
 
 Inspect the host repository for generated environment bindings after adding names. Run its existing generator, review the diff, commit generated types only when that repository requires them, then run the production-equivalent host build. Do not invent a framework command or add a second generator.
 

package/skills/claude-code/references/sdk-surface.md

@@ -53,18 +53,22 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 
 ### Other
 
+- `algolia`
 - `authenticatedWebsite`
 - `clientCredentials`
 - `customerEndpoint`
 - `embeddedAssistant`
 - `externalExchange`
 - `file`
+- `firecrawl`
 - `gmailConnector`
 - `knowledge`
 - `managedSecret`
+- `meilisearch`
 - `openAICompatible`
 - `publicWebsite`
 - `site`
+- `tavily`
 
 ## Authoring signatures
 

package/skills/claude-code/reporting-noodle-feedback/SKILL.md

@@ -3,7 +3,7 @@ name: reporting-noodle-feedback
 description: "Use when a Noodle Seed bug, misleading instruction, missing capability, or concrete product improvement should be proposed to the user."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.76.0 hash:0f404109f4845683 -->
 
 # reporting-noodle-feedback
 

package/skills/claude-code/verifying-mcp-delivery/SKILL.md

@@ -3,7 +3,7 @@ name: verifying-mcp-delivery
 description: "Use when proving a Noodle Seed MCP project works at a named compile, local, connector, App, host, deployment, or production evidence level."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.76.0 hash:6ef6ef551e26b78e -->
 
 # verifying-mcp-delivery
 

package/skills/claude-code/wrapping-existing-applications/SKILL.md

@@ -3,7 +3,7 @@ name: wrapping-existing-applications
 description: "Use when an existing application has no stable usable API and needs a read-only, identity-first Noodle Seed integration plan before implementation."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:eccc3c158dcafba8 -->
+<!-- noodle-skill version:0.76.0 hash:eccc3c158dcafba8 -->
 
 # wrapping-existing-applications
 

package/skills/codex/SKILL.md

@@ -3,7 +3,7 @@ name: noodle-seed
 description: "Use when building, validating, testing, deploying, or operating a local or hosted Noodle Seed MCP server or app authored in TypeScript with the noodle CLI."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.76.0 hash:13ddce01769caae4 -->
 
 # Noodle Seed
 

package/skills/codex/authoring-mcp-servers/SKILL.md

@@ -3,7 +3,7 @@ name: authoring-mcp-servers
 description: "Use when creating or extending a headless Noodle Seed MCP server, tool, resource, prompt, or typed model-facing capability."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:11523cb33b9473c0 -->
+<!-- noodle-skill version:0.76.0 hash:11523cb33b9473c0 -->
 
 # authoring-mcp-servers
 

package/skills/codex/building-mcp-apps/SKILL.md

@@ -3,7 +3,7 @@ name: building-mcp-apps
 description: "Use when a Noodle Seed MCP App, widget, interactive card, visual interaction, or host-visible UI is the primary requested outcome."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:9fd67d4d24328e15 -->
+<!-- noodle-skill version:0.76.0 hash:9fd67d4d24328e15 -->
 
 # building-mcp-apps
 

package/skills/codex/connecting-apis-to-mcp/SKILL.md

@@ -3,7 +3,7 @@ name: connecting-apis-to-mcp
 description: "Use when all four API-evidence inputs exist—and only then: API base URL, authentication scheme, representative safe read, and observed response."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:21bbd3ec441ffd30 -->
+<!-- noodle-skill version:0.76.0 hash:21bbd3ec441ffd30 -->
 
 # connecting-apis-to-mcp
 

package/skills/codex/creating-product-agent-guides/SKILL.md

@@ -3,7 +3,7 @@ name: creating-product-agent-guides
 description: "Use when a Noodle Seed MCP server needs a new or revised product agent guide, App Package skill, or explicit product-skill regeneration."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:0fa48a82fe836cf0 -->
+<!-- noodle-skill version:0.76.0 hash:0fa48a82fe836cf0 -->
 
 # creating-product-agent-guides
 

package/skills/codex/debugging-mcp-delivery/SKILL.md

@@ -3,7 +3,7 @@ name: debugging-mcp-delivery
 description: "Use when an existing Noodle Seed MCP project has a concrete validation, runtime, connector, App, host, deployment, or production failure."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.76.0 hash:aa715bae12041d7c -->
 
 # debugging-mcp-delivery
 

package/skills/codex/deploying-mcp-services/SKILL.md

@@ -3,7 +3,7 @@ name: deploying-mcp-services
 description: "Use when the user explicitly requests a Noodle Seed hosted link, configuration write, deployment, access change, rollback, or connection write."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.76.0 hash:93e735b7ffb45df1 -->
 
 # deploying-mcp-services
 

package/skills/codex/designing-mcp-products/SKILL.md

@@ -3,7 +3,7 @@ name: designing-mcp-products
 description: "Use when a Noodle Seed MCP product idea needs conversational fit, user benefit, scope, interaction, or evidence design before implementation."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:78a6f181b61f92f1 -->
+<!-- noodle-skill version:0.76.0 hash:78a6f181b61f92f1 -->
 
 # designing-mcp-products
 

package/skills/codex/embedding-mcp-assistants/SKILL.md

@@ -3,7 +3,7 @@ name: embedding-mcp-assistants
 description: "Use when embedding a Noodle assistant into an existing SaaS or web application with browser, identity, session, and credential boundaries."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.76.0 hash:cc54a67f21c0ecdb -->
 
 # embedding-mcp-assistants
 

package/skills/codex/examples/acme-discovery/src/server.ts

@@ -200,8 +200,12 @@ const shortlistGetaway = tool('shortlist_getaway', {
 });
 
 // Grounding beyond the catalog: two controlled files answer policy/pricing/support questions with
-// citations, and Acme's live public site stays current through its search provider — no sync job,
-// no handwritten search tool. One declaration, one generated `search_destinations` capability.
+// citations, and Acme's live public site is crawled on deploy and re-crawled on the declared
+// refresh cadence — no sync job, no handwritten search tool. One declaration, one generated
+// `search_destinations` capability. The managed crawler and index are the defaults; a component
+// can instead bring its own via `crawler: firecrawl({ apiKey: secret('FIRECRAWL_API_KEY') })`
+// and `index: algolia({ appId: variable('ALGOLIA_APP_ID'), apiKey: secret('ALGOLIA_API_KEY') })`
+// — the code names the config, `noodle secrets|variables set` supplies the values.
 const destinations = knowledge('destinations', {
   title: 'Acme Getaways destinations',
   description: 'Public destination, pricing, cancellation, and support information.',
@@ -216,6 +220,7 @@ const destinations = knowledge('destinations', {
     site({
       origin: 'https://getaways.acme.example',
       include: ['/destinations/**', '/pricing', '/support'],
+      refresh: '12h',
     }),
   ],
 });

package/skills/codex/executing-noodle-plans/SKILL.md

@@ -3,7 +3,7 @@ name: executing-noodle-plans
 description: "Use when the user asks to execute an approved, decision-complete implementation plan for a Noodle Seed project task by task with test-first changes, review, recovery, and final verification."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.76.0 hash:6a9f132ddb79352e -->
 
 # Execute a Noodle Seed implementation plan
 

package/skills/codex/publishing-mcp-integrations/SKILL.md

@@ -3,7 +3,7 @@ name: publishing-mcp-integrations
 description: "Use when preparing, reviewing, or submitting a Noodle Seed MCP integration to a host or app directory."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.76.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

package/skills/codex/references/authoring-workflow.md

@@ -420,12 +420,14 @@ const product = knowledge('product', {
     file('./knowledge/faq.txt', { title: 'FAQ' }),
   ],
   sites: [
-    site({ origin: 'https://www.acme.example', include: ['/docs/**', '/pricing'] }),
+    site({ origin: 'https://www.acme.example', include: ['/docs/**', '/pricing'], refresh: '6h' }),
   ],
 });
 ```
 
-The compiler validates and hashes every document at build time (bad extensions, root escapes, symlinks, oversize, and non-UTF-8 fail `noodle validate` with the exact path); deployment publishes versioned files transactionally with the app and the provider keeps live-site content current. Component names are lowercase snake-case; each component implies exactly one generated bounded search capability with cited results.
+The compiler validates and hashes every document at build time (bad extensions, root escapes, symlinks, oversize, and non-UTF-8 fail `noodle validate` with the exact path); deployment publishes versioned files transactionally with the app, crawls declared sites, and re-crawls them on the `refresh` cadence (`15m`–`7d`, default daily; `noodle knowledge refresh <name>` crawls on demand). Component names are lowercase snake-case; each component implies exactly one generated bounded search capability with cited results.
+
+The managed crawler and managed index are the defaults and need no configuration. A component may instead bring its own crawler (`crawler: firecrawl({ apiKey: secret('FIRECRAWL_API_KEY') })` or `tavily(...)`) and/or its own index (`index: algolia({ appId: variable('ALGOLIA_APP_ID'), apiKey: secret('ALGOLIA_API_KEY') })` or `meilisearch({ host: variable(...), apiKey: secret(...) })`). The code declares only config names; operators supply values with `noodle secrets set` / `noodle variables set`, and deploy preflight fails closed naming any unset reference.
 
 ## Boundaries
 

package/skills/codex/references/cli-commands.md

@@ -87,7 +87,7 @@ Developer-facing `noodle` commands, grouped by area. Local authoring commands (`
 | Command | What it does |
 | :-- | :-- |
 | `noodle audit` | Operator governance audit status and event queries. |
-| `noodle knowledge` | Operator-only knowledge components: list and status (ADR 0202). |
+| `noodle knowledge` | Operator-only knowledge components: list, status, and refresh (ADR 0202). |
 | `noodle logs` | View service/deployment logs. |
 | `noodle metrics` | MCP analytics for a deployed server (volume, sessions, latency percentiles, two-tier errors, tools, clients). Agents: `noodle metrics --agent-output` for a health verdict + next actions. |
 | `noodle events` | The per-request MCP event stream with status/tool/client filters; `--session <id>` replays one session in order. Agents: add `--json` and filter (`--status tool_error\|mcp_error`) when debugging. |

package/skills/codex/references/embedded-assistant.md

@@ -84,6 +84,8 @@ At most one public surface (`public` or `mixed`) and at most one authenticated s
 
 A public surface **must** declare `capabilities`: the exact positive allowlist it may reach. It is required by the type, and it is the whole externally reachable surface — a reviewer should read it in one screenful. Anything absent stays private, and a capability added to the server later is excluded until someone lists it. `authenticatedWebsite` may also take `capabilities` to narrow the in-app surface; omitted, it projects the whole server.
 
+A public `embedId` Web Component automatically attaches bounded anonymous same-origin Markdown page context, never DOM text. It is untrusted and nonpersistent, falls back to the URL alone on failure, yields to explicit `pageContext`, and never runs for authenticated or headless clients.
+
 ### Mixed surfaces: let a visitor sign in mid-conversation
 
 Add `signIn: true` to a public surface when some capabilities need a signed-in visitor. The surface becomes `mixed`: anonymous visitors start immediately, an identity-dependent capability stays **visible** so the assistant can offer it, and reaching for it raises a sign-in prompt instead of executing.
@@ -96,9 +98,11 @@ access: publicWebsite({
 }),
 ```
 
-Elevation runs through the **host application own login**, never a Noodle-operated one. The widget raises `assistant-sign-in-requested` with a single-use `continuation`; the page signs the visitor in as it already does, then its backend POSTs that continuation to the session exchange **with its own client credentials**. Possession of the continuation alone elevates nothing, and the service checks the client tenant owns that conversation.
+Elevation runs through the **host application own login**, never a Noodle-operated one. The widget raises `assistant-sign-in-requested` with a single-use `signInTicket` in its detail; the page signs the visitor in as it already does, then its backend spends the ticket with `createAssistantSession({ ..., signInTicket })` from `@noodleseed/assistant/server` — the same session exchange, its own client credentials. A refused spend throws a typed `AssistantSessionExchangeError`: branch on `elevationRefusal` (`elevation_ticket_expired` re-prompt; `elevation_tenant_mismatch` alert, never retry). Possession of the ticket alone elevates nothing, and the service checks the client tenant owns that conversation. The ticket is not the server-held interaction continuation — that value never reaches browser code; this one exists to travel through the page.
+
+The conversation is kept server-side: same session, new token, the anonymous one dead. Set honest expectations in UI copy — the assistant **remembers** the conversation (recent history feeds the model), but no transcript is replayed to the browser, so after a full-page navigation the visible panel starts fresh. Say "the assistant remembers", never "your conversation will reappear". Do not build a second identity provider for this.
 
-The conversation is kept: same history, new token, the anonymous one dead. Do not build a second identity provider for this.
+When the login lives on a different origin (marketing site + app), the flow is: the visitor signs in via full-page redirect as the site already does; the backend spends the ticket presenting the **origin the conversation will continue on** (any origin in the deployment allowlist — elevation re-pins the session there, and CORS follows); the token reaches the widget through the customer own **same-origin** session endpoint on that origin. The redirect handoff is mandatory, not stylistic: the widget calls the session endpoint with `credentials: "same-origin"`, so pointing a marketing page at a cross-origin endpoint is a guaranteed cookie-less 401. Persist the ticket across the login redirect (single-use, expires in minutes); a refused origin does not burn it.
 
 A connector-backed side effect needs **two** independent declarations to be reachable from a public or mixed surface: inclusion in `capabilities` **and** `{ confirm: true }` on the operation. Signing in proves who the visitor is; it does not pre-authorize an effect, so confirmation still applies on a mixed surface. Confirmation is never authentication or business authorization — the customer backend still owns payload validation, abuse controls, and idempotency. Local or session-only widget state needs no confirmation.
 
@@ -181,7 +185,7 @@ Validate the active deployment, backend credential, exact origin, and delegated
 noodle assistant doctor --origin "$PUBLIC_APP_ORIGIN" --org <org> --app <app> --env <env>
 ```
 
-The doctor reads `NOODLE_ASSISTANT_CLIENT_ID` / `NOODLE_ASSISTANT_CLIENT_SECRET` or the saved mode-0600 client file and never prints the secret. Pass `--user-id <real-test-user>` only when the downstream exchange requires an existing application user. The assistant doctor does not supply application-specific routes; after the backend mints a routed session, invoke one representative safe read to verify its route-bound exchange and connector together.
+The doctor reads `NOODLE_ASSISTANT_CLIENT_ID` / `NOODLE_ASSISTANT_CLIENT_SECRET` or the saved mode-0600 client file and never prints the secret. Pass `--user-id <real-test-user>` only when the downstream exchange requires an existing application user. On a deployment with a mixed surface it also runs a synthetic sign-in round trip (`elevation` check): issue, claim, and elevate against a throwaway anonymous session on the same code path a real sign-in takes, proving the store is configured and that elevation rebinds the issuer basis to the backend client — so a green doctor now certifies the sign-in leg too, not just the authenticated exchange. The assistant doctor does not supply application-specific routes; after the backend mints a routed session, invoke one representative safe read to verify its route-bound exchange and connector together.
 
 ## Integrate the customer backend
 
@@ -584,7 +588,7 @@ noodle assistant embed --check --json
 noodle assistant embed --check --json --require-env EXAMPLE_DELEG_CLIENT_SECRET
 ```
 
-The check reports only required and missing environment names, never their values. It checks both `connect-src` and `frame-src` when a common static host CSP is determinable, fails on missing directives, and marks a dynamic expression unverified instead of guessing. Additional `--require-env` names are application-owned; use them for the customer side of delegated exchange or other backend-only integration requirements.
+The check reports only required and missing environment names, never their values. Pass `--surface public|mixed|authenticated` to match the deployment: `public` drops the backend client id/secret requirement (a public embed has neither), and `public`/`mixed` additionally require `script-src` — the one directive whose failure runs no widget code at all, so nothing can report it from inside the page. CSP directives verify against the service origin exactly, via the env placeholder, or through a covering wildcard (`https://*.example.com`); a dynamic expression is marked unverified instead of guessed. Additional `--require-env` names are application-owned; `--env-alias NAME=HOST_NAME` follows a host repo that names an env var differently.
 
 Inspect the host repository for generated environment bindings after adding names. Run its existing generator, review the diff, commit generated types only when that repository requires them, then run the production-equivalent host build. Do not invent a framework command or add a second generator.
 

package/skills/codex/references/sdk-surface.md

@@ -53,18 +53,22 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 
 ### Other
 
+- `algolia`
 - `authenticatedWebsite`
 - `clientCredentials`
 - `customerEndpoint`
 - `embeddedAssistant`
 - `externalExchange`
 - `file`
+- `firecrawl`
 - `gmailConnector`
 - `knowledge`
 - `managedSecret`
+- `meilisearch`
 - `openAICompatible`
 - `publicWebsite`
 - `site`
+- `tavily`
 
 ## Authoring signatures
 

package/skills/codex/reporting-noodle-feedback/SKILL.md

@@ -3,7 +3,7 @@ name: reporting-noodle-feedback
 description: "Use when a Noodle Seed bug, misleading instruction, missing capability, or concrete product improvement should be proposed to the user."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.76.0 hash:0f404109f4845683 -->
 
 # reporting-noodle-feedback
 

package/skills/codex/verifying-mcp-delivery/SKILL.md

@@ -3,7 +3,7 @@ name: verifying-mcp-delivery
 description: "Use when proving a Noodle Seed MCP project works at a named compile, local, connector, App, host, deployment, or production evidence level."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.76.0 hash:6ef6ef551e26b78e -->
 
 # verifying-mcp-delivery
 

package/skills/codex/wrapping-existing-applications/SKILL.md

@@ -3,7 +3,7 @@ name: wrapping-existing-applications
 description: "Use when an existing application has no stable usable API and needs a read-only, identity-first Noodle Seed integration plan before implementation."
 ---
 
-<!-- noodle-skill version:0.74.0 hash:eccc3c158dcafba8 -->
+<!-- noodle-skill version:0.76.0 hash:eccc3c158dcafba8 -->
 
 # wrapping-existing-applications