@noodleseed/agent-kit 0.63.1 → 0.65.0

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

@@ -39,7 +39,9 @@ Before choosing code, ask the user which experience belongs in the existing prod
 
 ## Author and validate
 
-Use the same server tools in the embed; do not create a second tool set. Declare one server-level brand kit and an assistant configuration:
+`noodle init` and `noodle init --template widget` deliberately produce credential-free MCP Apps. Add an assistant declaration only when the product explicitly includes a customer-hosted assistant; do not make ordinary external-host widgets depend on model-provider settings.
+
+Use the same server tools in the embed; do not create a second tool set. Declare one server-level brand kit and an assistant configuration. `access` decides who may open a session, so choose it before anything else — `authenticatedWebsite(...)` for an in-app embed, `publicWebsite(...)` for a marketing page, or both:
 
 ```ts
 branding: { name: "Acme", accent: "#3157D5" },
@@ -50,12 +52,55 @@ assistant: embeddedAssistant({
     model: variable("ASSISTANT_MODEL"),
     apiKey: secret("ASSISTANT_MODEL_API_KEY"),
   }),
-  allowedOrigins: ["http://localhost:3000", "https://app.example.com"],
+  access: authenticatedWebsite({
+    origins: ["http://localhost:3000", "https://app.example.com"],
+  }),
   layout: { mode: "floating", position: "bottom-right" },
 }),
 ```
 
-`allowedOrigins` are exact origins: scheme, host, and optional port, with no path, trailing slash, or wildcard. Production origins must be HTTPS; plain HTTP is accepted only for loopback development origins (`http://localhost:<port>`, `http://127.0.0.1:<port>`). `noodle dev` serves the MCP project, not the embedding SaaS.
+Origins are exact: scheme, host, and optional port, with no path, trailing slash, or wildcard. Production origins must be HTTPS; plain HTTP is accepted only for loopback development origins (`http://localhost:<port>`, `http://127.0.0.1:<port>`). `noodle dev` serves the MCP project, not the embedding SaaS.
+
+### Surfaces: one assistant, every front door
+
+A product usually has more than one front door — a marketing site and a signed-in app. One assistant (one brand, one model, one UI) projects onto both; pass `access` an array and each surface owns its own origins and allowlist:
+
+```ts
+access: [
+  publicWebsite({
+    origins: ["https://www.example.com"],
+    capabilities: [answerProductQuestion, requestDemo],
+  }),
+  authenticatedWebsite({
+    origins: ["https://app.example.com"],
+    sessionClaims: { plan: { exposeToModel: true } },
+  }),
+],
+```
+
+At most one public surface (`public` or `mixed`) and at most one authenticated surface, and no origin may appear on two surfaces — otherwise "which projection is this request?" would be ambiguous. Each gets its own embed snippet, budget, and kill switch.
+
+`publicWebsite` is for a page with no signed-in user. The visitor is an **anonymous principal**, not an empty user: there is no `${user}`, no roles, no scopes, no customer routing, and no delegated credentials. A tool that needs identity — because it reads `${user}` or declares an `authorization` requirement — cannot be projected to a `public` surface, and the compiler says so.
+
+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.
+
+### Mixed surfaces: let a visitor sign in mid-conversation
+
+Add `signIn: true` to a public surface when some capabilities need a signed-in user. The surface becomes `mixed`: anonymous visitors start immediately, and an identity-dependent capability becomes a **sign-in trigger** rather than a compile error — the same shape ChatGPT and Claude use for connectors that work with or without a linked account.
+
+```ts
+access: publicWebsite({
+  origins: ["https://www.example.com"],
+  capabilities: [answerProductQuestion, requestDemo, myOrders],
+  signIn: true,   // `myOrders` reads ${user}; visitors sign in to reach it
+}),
+```
+
+Elevation runs through the **host application’s own login**, never a Noodle-operated one: the page signs the visitor in and its backend exchanges that verified user for an elevated session on the same conversation. Do not build a second identity provider for this.
+
+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.
+
+Origin is a browser boundary, never bot authentication — scripts can reproduce an allowed `Origin` header. Do not tell a user that origins protect a public embed; the real controls are the capability allowlist, confirmation, admission limits, and the per-surface daily budget.
 
 Run:
 
@@ -279,6 +324,25 @@ To make the *downstream API call itself* run as the signed-in user (your API enf
 
 The exchange returns the versioned Embedded Assistant v1 contract. `token`, `expiresAt`, and `endpoints.turns` / legacy `endpoints.toolConfirmations` (absolute URLs) are always present; current services add `endpoints.interactions` for accept/decline/cancel. `configuration` is optional theming data. Forward the body unchanged; browser clients choose the advertised endpoint. Do not rebuild, filter, or rewrite the response.
 
+## Mount a public website surface
+
+A `publicWebsite` surface has no backend exchange, because it has no embed secret to protect. `noodle deploy` provisions a non-secret embed id and prints the snippet; the page presents that id directly and receives an anonymous session. Do not build a session route for a public surface — there is nothing for it to hold.
+
+```html
+<script src="https://cloud.noodleseed.dev/v1/assistant/embed.js"
+        data-embed-id="pub_7f2q4k9x" async></script>
+```
+
+The script derives its service origin from its own `src`, so one snippet works unchanged in every environment. In a React application, mount `<NoodleAssistant embedId="pub_7f2q4k9x" />` instead. `embedId` and `sessionEndpoint` are mutually exclusive: an embed id beside a backend endpoint is a mistake, and the client refuses rather than guessing which transport was meant.
+
+The embed id is safe in page source and stable across deploys — paste it once; redeploy and rollback swap the projection under a page that never changes. Never treat it as a credential, and never put a client secret on a public page.
+
+Tell the operator the two commands that matter: `noodle assistant embeds list` shows each surface with its live origins, capabilities, and today's spend against its cap; `noodle assistant budget set --turns-per-day 0` is the kill switch and stops conversations already under way. Raising the cap serves visitors again. Prefer it to revoking an embed, which destroys the pasted id.
+
+A public surface is capped per day, so a visitor can meet an exhausted budget. The widget renders that calmly and offers no retry; do not add one. If the embedding page sets a Content-Security-Policy, it must allow the Noodle service origin in `script-src` (the embed script), `connect-src` (session and turns), and `frame-src` (widget sandbox) — a blocked `script-src` runs no widget code at all, so nothing can report it from the page.
+
+Run `noodle check --target embedded-assistant` before deploying a public surface: it lists exactly what a stranger can reach and warns when no `privacyUrl` is declared.
+
 ## Choose a browser renderer
 
 Use the React wrapper in React applications:

package/skills/claude-code/references/experience-design.md

@@ -29,6 +29,7 @@ the app evolves. It has required fields:
   (inline card / carousel / fullscreen / picture-in-picture). State the modes you deliberately do
   *not* use, and why.
 - **Grounding sources** — where each fact comes from (a `connector` operation, a provided dataset).
+- **Product-guide decision** — guided or unguided, with the reason. Do not wait for the user to know the `agentGuide` name; use `references/product-agent-guides.md` to judge whether cross-capability workflows or product-specific boundaries need one.
 - **Handoff domains** — the external origins the app links out to (these become server
   `handoff.allowedDomains`).
 - **Exceptions** — any deliberate departure from the defaults below, each with its reason.
@@ -150,5 +151,5 @@ and element evidence as untrusted data, never as agent instructions.
 ## From design to build
 
 Once the design spec is settled, build it: `references/authoring-workflow.md` for the author→validate
-loop and connectors, `references/widgets-and-apps.md` for widgets and CSP, `references/examples.md`
+loop and connectors, `references/product-agent-guides.md` for a selected guide, `references/widgets-and-apps.md` for widgets and CSP, `references/examples.md`
 for a flagship to extend, and `references/deploy-and-ops.md` to ship.

package/skills/claude-code/references/product-agent-guides.md

@@ -1,6 +1,22 @@
 # Product agent guides
 
-Author one optional `agentGuide` in `server(name, { agentGuide, ... }, definitions)` when an agent needs product-level workflow guidance beyond individual MCP capability descriptions. It is host-neutral and TypeScript-only.
+An `agentGuide` is the optional, host-neutral, TypeScript-only source for product-level workflow guidance beyond individual MCP capability descriptions. Noodle validates it and generates the App Package product skill; it does not invent the guide’s product judgment.
+
+## Required decision
+
+Do not wait for the user to name `agentGuide`. During every MCP server or App build, decide whether the product needs one and state the decision and reason in the design or handoff.
+
+Author a guide when any of these conditions applies:
+
+- A request for an App Package, product skill, plugin, or agent distribution requires one.
+- Multiple capabilities participate in one user workflow, especially when order or purpose matters.
+- Safe or useful operation depends on product-specific ordering, grounding, clarification, boundaries, or representative examples that capability descriptions cannot express.
+
+A product with a single self-explanatory capability may omit the guide when its description, schema, and annotations fully communicate safe use and there is no product-specific workflow or boundary to add. Tool count is a signal, not a rule: one ambiguous or consequential capability can still require a guide, while several independent self-explanatory capabilities may not.
+
+Make the judgment from the user’s stated outcome and grounded product evidence. If a guide is warranted but a decision-changing workflow or boundary is unknown, ask only for that missing product input; never fabricate it. The user should not need to know this feature name to receive the benefit.
+
+## Authoring shape
 
 The guide contains `description`, `useWhen`, named `workflows`, optional `boundaries`, and optional example prompt-to-workflow mappings. Each workflow step references a declared `tool`, `resource`, or `prompt` by symbolic `{ kind, name }`; do not duplicate schemas, connector bindings, URLs, credentials, or raw runtime data.
 
@@ -8,4 +24,10 @@ Keep identifiers within 200 characters and prose within 4,000 characters. A guid
 
 Use `server.instructions` for a concise live MCP-session primer. Noodle-owned workflow skills teach how to build and operate Noodle projects; a product guide teaches agents how to use this one deployed product. Compilation validates references and produces an App Package sibling while the RuntimeArtifact deliberately omits guide prose.
 
+## Local lifecycle
+
+`noodle agents setup` previews the local product-skill files compiled from `server.ts`; add `--write` to install them under `.agents/skills/<app-skill>/` and `.claude/skills/<app-skill>/`. No account or hosted deployment is required. The app files have an ownership record separate from the Noodle workflow skills.
+
+`noodle agents setup --write` is idempotent and never overwrites a modified app-skill file. `--force` applies only to Noodle-owned project context, not app product skills. Run `noodle agents doctor --json`: `agent_skill_modified` means preserve and review local bytes; `agent_skill_stale` means source, surface, renderer, or installed files changed, so preview before writing; `agent_skill_invalid_state` means the ownership record is malformed or unsafe, so preserve the files and review the record before retrying.
+
 Recover `agent_guide_*` errors by correcting the guide shape, workflow IDs, and capability kind/name. Remove any credential-shaped value: managed config is referenced by name only.

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

@@ -53,6 +53,7 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 
 ### Other
 
+- `authenticatedWebsite`
 - `clientCredentials`
 - `customerEndpoint`
 - `embeddedAssistant`
@@ -60,6 +61,7 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 - `gmailConnector`
 - `managedSecret`
 - `openAICompatible`
+- `publicWebsite`
 
 ## 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.63.1 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.65.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.63.1 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.65.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.63.1 hash:eccc3c158dcafba8 -->
+<!-- noodle-skill version:0.65.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.63.1 hash:88e3ae21d02f2fe7 -->
+<!-- noodle-skill version:0.65.0 hash:7732a64aac011333 -->
 
 # Noodle Seed
 
@@ -56,7 +56,7 @@ Inside the installed plugin, perform mapped steps with `noodle-readiness` tools
 This is a lookup catalog, not a discovery checklist. Return here only when the selected primary route names a missing technical detail:
 
 - `references/agent-contract.md` — the `--json` envelope, exit codes, and the three output modes.
-- `references/product-agent-guides.md` — author one host-neutral guide for a product MCP surface.
+- `references/product-agent-guides.md` — decide whether a product needs one host-neutral guide, then author it when selected.
 - `references/sdk-surface.md` — what to import from `@noodleseed/one` and which builder to use.
 - `references/cli-commands.md` — every `noodle` command, grouped by area.
 - `references/compile-errors.md` — fix `noodle validate` errors by code.

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.63.1 hash:0b2fd8c7e43fc69f -->
+<!-- noodle-skill version:0.65.0 hash:11523cb33b9473c0 -->
 
 # authoring-mcp-servers
 
@@ -33,7 +33,7 @@ Load `references/sdk-surface.md` at `../noodle-seed/references/sdk-surface.md` o
 
 ## Verification evidence
 
-The TypeScript behavior validates and passes local smoke; connector reads also have real-output proof.
+The TypeScript behavior and explicit product-guide decision validate and pass local smoke; connector reads also have real-output proof.
 
 ## Recovery paths
 

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.63.1 hash:f7fa54992c8d7692 -->
+<!-- noodle-skill version:0.65.0 hash:9fd67d4d24328e15 -->
 
 # building-mcp-apps
 
@@ -33,7 +33,7 @@ Load `references/widgets-and-apps.md` at `../noodle-seed/references/widgets-and-
 
 ## Verification evidence
 
-The App passes validation, local smoke, app checks, and the requested preview or host evidence level.
+The App records its product-guide decision and passes validation, local smoke, app checks, and the requested preview or host evidence level.
 
 ## Recovery paths
 

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.63.1 hash:21bbd3ec441ffd30 -->
+<!-- noodle-skill version:0.65.0 hash:21bbd3ec441ffd30 -->
 
 # connecting-apis-to-mcp
 

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.63.1 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.65.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.63.1 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.65.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.63.1 hash:76cce86729cffbee -->
+<!-- noodle-skill version:0.65.0 hash:78a6f181b61f92f1 -->
 
 # designing-mcp-products
 
@@ -32,7 +32,7 @@ Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-
 
 ## Verification evidence
 
-A bounded product contract states user benefit, model boundary, interaction, fallback, risks, and next implementation skill.
+A bounded product contract states user benefit, model boundary, interaction, fallback, product-guide decision, risks, and next implementation skill.
 
 ## Recovery paths
 

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.63.1 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.65.0 hash:cc54a67f21c0ecdb -->
 
 # embedding-mcp-assistants
 

package/skills/codex/examples/acme-discovery/README.md

@@ -7,9 +7,28 @@ deep link. It pairs a `tool` discovery carousel with a model-visible `create_han
 server-level `handoff.allowedDomains`.
 
 Capability slots: top-of-funnel funnel discipline, discovery carousel widget, `create_handoff` deep-link
-handoff with attribution, `handoff.allowedDomains`, and a worked **design-first** artifact (the UX spec +
-wireframe below). It shows the "design the experience, then build it" flow the `noodle-seed` skill's
-`references/experience-design.md` teaches.
+handoff with attribution, `handoff.allowedDomains`, the **public website assistant surface**, and a worked
+**design-first** artifact (the UX spec + wireframe below). It shows the "design the experience, then build
+it" flow the `noodle-seed` skill's `references/experience-design.md` teaches.
+
+## The same tools on Acme's own website
+
+The funnel does not only start in ChatGPT. The `assistant` block projects these same three tools onto
+Acme's marketing site for a visitor with **no account and no session backend**:
+
+```ts
+access: publicWebsite({
+  origins: ['https://getaways.acme.example'],
+  capabilities: [discoverGetaways, createHandoff, shortlistGetaway],
+}),
+```
+
+There is no second tool set and no second app — one `server.ts`, projected onto another front door.
+`capabilities` is the entire externally reachable surface, so it stays short enough to review at a glance
+and closed by default: a tool added to this server later is unreachable from the website until someone
+lists it. A tool that needed a signed-in user could not be listed here at all (the compiler rejects it);
+serving those to visitors means `publicWebsite({ ..., signIn: true })`, which lets a visitor sign in
+mid-conversation through Acme's own login.
 
 ## Design spec (write this before the code)
 

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

@@ -1,4 +1,14 @@
-import { annotations, server, tool, z } from '@noodleseed/one';
+import {
+  annotations,
+  embeddedAssistant,
+  openAICompatible,
+  publicWebsite,
+  secret,
+  server,
+  tool,
+  variable,
+  z,
+} from '@noodleseed/one';
 
 // Acme Getaways is a fictional travel brand. This app is deliberately top-of-funnel: discovery and
 // configuration happen inside ChatGPT; the booking/transaction happens off-app on Acme's own site,
@@ -95,6 +105,97 @@ const destinationOutput = z.object({
   why: z.string(),
 });
 
+const discoverGetaways = tool('discover_getaways', {
+  title: 'Discover getaways',
+  description:
+    'Suggest Acme Getaways destinations for a vibe and month and render a discovery carousel.',
+  annotations: readOnly,
+  input: discoverInput,
+  output: z.object({
+    status: z.string(),
+    vibe: z.string(),
+    month: z.string(),
+    travelers: z.number(),
+    // Bounded list: the curated catalog is fixed and small, and the declared ceiling tells the
+    // model and host the payload cannot grow. `noodle check` reports `tool_design_output_bounds`.
+    options: z.array(destinationOutput).max(20),
+  }),
+  // The carousel presents Acme's curated catalog; the model narrates which fit the stated vibe.
+  // (A tool cannot filter on an input value — that is connector/flow work — so all are returned.)
+  fulfil: ({ input }) => ({
+    status: `Acme Getaways for a ${input.vibe} trip in ${input.month}, ${input.travelers} traveler(s).`,
+    vibe: input.vibe,
+    month: input.month,
+    travelers: input.travelers,
+    options: catalog,
+  }),
+  viewTitle: 'Discover getaways',
+  // ChatGPT host status copy (openai/toolInvocation/*) — required for widget-opening tools.
+  invoking: 'Finding getaways…',
+  invoked: 'Getaways ready',
+  domain: 'https://getaways.acme.example',
+  view: {
+    component: 'discovery-carousel',
+    entry: './views/discovery-carousel.tsx',
+  },
+  viewDescription:
+    'A top-of-funnel discovery carousel: pick a destination, then hand off to Acme to book.',
+  csp: {
+    connectDomains: ['https://acme.example'],
+    resourceDomains: ['https://acme.example'],
+    frameDomains: ['https://acme.example'],
+  },
+});
+
+const createHandoff = tool('create_handoff', {
+  title: 'Create booking handoff',
+  description:
+    'Create the Acme booking deep link for a chosen destination, carrying the configured trip. ' +
+    'Pass the destination id (url-safe slug, e.g. "coral_bay") and its display name.',
+  annotations: openLink,
+  input: z.object({
+    destination: destinationId,
+    destinationName: z.string().min(1),
+    month: monthEnum,
+    travelers: z.number().int().min(1).default(2),
+  }),
+  output: z.object({
+    status: z.string(),
+    destination: z.string(),
+    summary: z.string(),
+    handoffUrl: z.string(),
+  }),
+  // Inline the inputs directly so they substitute at runtime; every value is already url-safe
+  // (id slug, month enum, integer), and `src=chatgpt` is the attribution the partner measures
+  // ChatGPT-sourced conversions on.
+  fulfil: ({ input }) => ({
+    status: `Ready to continue on Acme for ${input.destinationName}.`,
+    destination: input.destination,
+    summary: `${input.destinationName} · ${input.month} · ${input.travelers} traveler(s)`,
+    handoffUrl: `https://book.acme.example/plan?dest=${input.destination}&month=${input.month}&pax=${input.travelers}&src=chatgpt`,
+  }),
+});
+
+const shortlistGetaway = tool('shortlist_getaway', {
+  visibility: ['app'],
+  description: 'Record the traveler’s shortlisted destination from the discovery widget.',
+  annotations: localWrite,
+  input: z.object({
+    destination: z.string(),
+    note: z.string().default(''),
+  }),
+  output: z.object({
+    status: z.string(),
+    destination: z.string(),
+    note: z.string(),
+  }),
+  fulfil: ({ input }) => ({
+    status: `Shortlisted ${input.destination}.`,
+    destination: input.destination,
+    note: input.note,
+  }),
+});
+
 export default server(
   'acme_discovery',
   {
@@ -113,95 +214,23 @@ export default server(
     handoff: {
       allowedDomains: ['https://book.acme.example', 'https://acme.example'],
     },
-  },
-  [
-    tool('discover_getaways', {
-      title: 'Discover getaways',
-      description:
-        'Suggest Acme Getaways destinations for a vibe and month and render a discovery carousel.',
-      annotations: readOnly,
-      input: discoverInput,
-      output: z.object({
-        status: z.string(),
-        vibe: z.string(),
-        month: z.string(),
-        travelers: z.number(),
-        // Bounded list: the curated catalog is fixed and small, and the declared ceiling tells the
-        // model and host the payload cannot grow. `noodle check` reports `tool_design_output_bounds`.
-        options: z.array(destinationOutput).max(20),
+    // The same three tools also serve Acme's own marketing site, with no second tool set and no
+    // session backend: a visitor with no account gets the discovery carousel and the booking
+    // handoff. `capabilities` is the whole externally reachable surface — short enough to review in
+    // one glance, and closed by default when a tool is added to the server later.
+    assistant: embeddedAssistant({
+      model: openAICompatible({
+        baseUrl: variable('ASSISTANT_MODEL_BASE_URL'),
+        model: variable('ASSISTANT_MODEL'),
+        apiKey: secret('ASSISTANT_MODEL_API_KEY'),
       }),
-      // The carousel presents Acme's curated catalog; the model narrates which fit the stated vibe.
-      // (A tool cannot filter on an input value — that is connector/flow work — so all are returned.)
-      fulfil: ({ input }) => ({
-        status: `Acme Getaways for a ${input.vibe} trip in ${input.month}, ${input.travelers} traveler(s).`,
-        vibe: input.vibe,
-        month: input.month,
-        travelers: input.travelers,
-        options: catalog,
+      access: publicWebsite({
+        origins: ['https://getaways.acme.example'],
+        capabilities: [discoverGetaways, createHandoff, shortlistGetaway],
       }),
-      viewTitle: 'Discover getaways',
-      // ChatGPT host status copy (openai/toolInvocation/*) — required for widget-opening tools.
-      invoking: 'Finding getaways…',
-      invoked: 'Getaways ready',
-      domain: 'https://getaways.acme.example',
-      view: {
-        component: 'discovery-carousel',
-        entry: './views/discovery-carousel.tsx',
-      },
-      viewDescription:
-        'A top-of-funnel discovery carousel: pick a destination, then hand off to Acme to book.',
-      csp: {
-        connectDomains: ['https://acme.example'],
-        resourceDomains: ['https://acme.example'],
-        frameDomains: ['https://acme.example'],
-      },
+      layout: { mode: 'floating', position: 'bottom-right' },
+      labels: { welcomeHeading: 'Where would you like to go?' },
     }),
-    tool('create_handoff', {
-      title: 'Create booking handoff',
-      description:
-        'Create the Acme booking deep link for a chosen destination, carrying the configured trip. ' +
-        'Pass the destination id (url-safe slug, e.g. "coral_bay") and its display name.',
-      annotations: openLink,
-      input: z.object({
-        destination: destinationId,
-        destinationName: z.string().min(1),
-        month: monthEnum,
-        travelers: z.number().int().min(1).default(2),
-      }),
-      output: z.object({
-        status: z.string(),
-        destination: z.string(),
-        summary: z.string(),
-        handoffUrl: z.string(),
-      }),
-      // Inline the inputs directly so they substitute at runtime; every value is already url-safe
-      // (id slug, month enum, integer), and `src=chatgpt` is the attribution the partner measures
-      // ChatGPT-sourced conversions on.
-      fulfil: ({ input }) => ({
-        status: `Ready to continue on Acme for ${input.destinationName}.`,
-        destination: input.destination,
-        summary: `${input.destinationName} · ${input.month} · ${input.travelers} traveler(s)`,
-        handoffUrl: `https://book.acme.example/plan?dest=${input.destination}&month=${input.month}&pax=${input.travelers}&src=chatgpt`,
-      }),
-    }),
-    tool('shortlist_getaway', {
-      visibility: ['app'],
-      description: 'Record the traveler’s shortlisted destination from the discovery widget.',
-      annotations: localWrite,
-      input: z.object({
-        destination: z.string(),
-        note: z.string().default(''),
-      }),
-      output: z.object({
-        status: z.string(),
-        destination: z.string(),
-        note: z.string(),
-      }),
-      fulfil: ({ input }) => ({
-        status: `Shortlisted ${input.destination}.`,
-        destination: input.destination,
-        note: input.note,
-      }),
-    }),
-  ],
+  },
+  [discoverGetaways, createHandoff, shortlistGetaway],
 );

package/skills/codex/examples/acme-tasks/README.md

@@ -82,8 +82,9 @@ noodle open
 
 ## Optional in-product assistant
 
-The same task tools can also sit inside Acme's authenticated web app. Add an `assistant` option to this
-server without creating a second tool set:
+The default SaaS and widget scaffolds are credential-free. When the product deliberately includes an
+assistant, use the existing server tools and add an `assistant` option to the same `server.ts` instead of
+creating a second entrypoint or tool set:
 
 ```ts
 assistant: embeddedAssistant({

package/skills/codex/examples/customer-auth/src/server.ts

@@ -1,5 +1,6 @@
 import {
   annotations,
+  authenticatedWebsite,
   connector,
   customerAuth,
   customerEndpoint,
@@ -113,11 +114,13 @@ export default server(
         apiKey: secret('ASSISTANT_MODEL_API_KEY'),
       }),
       // Production origins are exact HTTPS; http://localhost:<port> is allowed for local development.
-      allowedOrigins: [
-        'https://app.noodleseed.com',
-        'https://dev.noodleseed.com',
-        'http://localhost:3000',
-      ],
+      access: authenticatedWebsite({
+        origins: [
+          'https://app.noodleseed.com',
+          'https://dev.noodleseed.com',
+          'http://localhost:3000',
+        ],
+      }),
       layout: { mode: 'floating', position: 'bottom-right', panelWidth: 420 },
       labels: {
         welcomeHeading: 'How can I help with Noodle Seed?',

package/skills/codex/examples/weather/README.md

@@ -32,7 +32,8 @@ It exercises, in one TypeScript-authored app:
   to `[]`.
 - **A per-operation transport bound** — `search_list` sets
   `limits: { maxResponseBytes: 256 * 1024 }`, tightening this known-small endpoint below the 1 MiB default.
-  Raise a limit only when representative evidence proves the required raw response is larger.
+  The authoring ceiling is 6 MiB, but grant only the bytes representative evidence proves this operation
+  needs.
 - **Sandboxed compute** (no network/fs/env/clock) turning raw numbers into conditions + advice.
 - **Typed input/output schemas** emitted as JSON Schema 2020-12.
 

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.63.1 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.65.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.63.1 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.65.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations