@noodleseed/agent-kit 0.84.0 → 0.85.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.84.0",
+  "version": "0.85.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.84.0 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:11523cb33b9473c0 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:9fd67d4d24328e15 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:21bbd3ec441ffd30 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:0fa48a82fe836cf0 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.85.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.84.0 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:78a6f181b61f92f1 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.85.0 hash:cc54a67f21c0ecdb -->
 
 # embedding-mcp-assistants
 

package/skills/claude-code/examples/acme-discovery/README.md

@@ -13,30 +13,73 @@ 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**:
+The funnel does not only start in ChatGPT. The `assistant` block projects these same tools onto
+Acme's marketing site for a visitor with **no account and no session backend** — as a **mixed**
+surface, so the visitor can also sign in mid-conversation:
 
 ```ts
-access: publicWebsite({
-  origins: ['https://getaways.acme.example'],
-  capabilities: [discoverGetaways, createHandoff, shortlistGetaway],
-  instructions:
-    'Be a friendly, consultative travel guide, never pushy. Help visitors narrow a getaway before suggesting the next useful step.',
-}),
+access: [
+  publicWebsite({
+    origins: ['https://getaways.acme.example'],
+    capabilities: [destinations, discoverGetaways, createHandoff, shortlistGetaway, captureLead, myTrips],
+    signIn: true, // my_trips reads ${user}; reaching it raises the sign-in card
+    instructions:
+      'Be a friendly, consultative travel guide, never pushy. Help visitors narrow a getaway before suggesting the next useful step.',
+  }),
+  authenticatedWebsite({
+    origins: ['https://account.acme.example'],
+    capabilities: [destinations, discoverGetaways, createHandoff, myTrips],
+    instructions: 'The traveler is signed in. Help them plan from their saved trips.',
+  }),
+],
 ```
 
-There is no second tool set and no second app — one `server.ts`, projected onto another front door.
+There is no second tool set and no second app — one `server.ts`, projected onto its front doors.
 The flagship selects `model: noodleManaged()`, so an enrolled hosted deployment needs no customer model
 endpoint, name, or key and its artifact remains provider-neutral. Sponsored beta enrollment is exact to the
 org/app/environment and fails closed outside that cohort; `openAICompatible(...)` remains the BYO alternative.
 The surface `instructions` add only the website-specific voice and goal; shared product truth stays in
-`server.instructions`. This public guidance is injected into public assistant turns, never MCP
+`server.instructions`. This public guidance is injected into that surface's assistant turns, never MCP
 `initialize` or another assistant surface.
-`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);
-serve those from `authenticatedWebsite({ origins })` instead, where Acme's own backend proves who the
-visitor is, or add `signIn: true` so visitors sign in mid-conversation through Acme own login.
+`capabilities` is the entire externally reachable surface per front door, 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.
+
+## Sign in mid-conversation, land in the account
+
+`signIn: true` makes the marketing surface **mixed**: `my_trips` stays visible so the assistant can
+offer it, and an anonymous visitor who reaches for it sees a branded card — *Sign in* plus, because
+`labels.signUpAction` is authored, *Create free account*. Both raise `assistant-sign-in-requested`
+with a single-use `signInTicket`; the detail's `intent` tells the page whether to route its login or
+its registration. Acme's page signs the visitor in exactly as it already does, its backend spends the
+ticket with `createAssistantSession({ ..., signInTicket })`, and the **same conversation continues**
+on whichever origin the backend designates:
+
+- landing back on `getaways.acme.example` keeps the mixed surface's projection with identity attached;
+- landing on `account.acme.example` rebinds the conversation to the authenticated surface — its
+  capabilities and its voice — and the widget repaints the visible transcript and auto-answers the
+  intercepted `my_trips` ask under the new identity.
+
+The ticket spend after account creation is identical to the one after sign-in; the service never
+operates a login of its own.
+
+## The consultative sales gateway
+
+When a visitor's plans firm up but they would rather not sign up, the assistant may — with explicit
+confirmation — take their details and deliver them to Acme's own sink. The recipe is a composition of
+existing primitives, not a platform feature:
+
+- `capture_lead` is an ordinary tool with `annotations.action({ confirm: true })`: the confirmation
+  card, showing every field, is the visitor's consent moment.
+- Delivery is a declarative HTTP connector whose endpoint is `variable('LEAD_SINK_URL')` and whose
+  credential is `secret('LEAD_SINK_TOKEN')` — the operator supplies values with
+  `noodle variables set` / `noodle secrets set`; the example stays credential-free and one authored
+  class serves any business.
+- The request mapping sets `source: 'website-assistant'` itself, so Acme's sink can trust the
+  attribution; the model never supplies it.
+- The lead rests only in Acme's own system. The platform stores no lead, and a vendor sink is just
+  different data: Resend/Postmark are `auth: { kind: 'apiKey', … }`, a HubSpot private app is
+  `auth: { kind: 'bearer', … }` — never a named vendor package.
 
 ## Design spec (write this before the code)
 

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

@@ -1,13 +1,17 @@
 import {
   annotations,
+  authenticatedWebsite,
+  connector,
   embeddedAssistant,
   file,
   knowledge,
   noodleManaged,
   publicWebsite,
+  secret,
   server,
   site,
   tool,
+  variable,
   z,
 } from '@noodleseed/one';
 
@@ -197,6 +201,90 @@ const shortlistGetaway = tool('shortlist_getaway', {
   }),
 });
 
+// The consultative sales gateway (ADR 0214): when a visitor would rather not sign up, the assistant
+// may — with explicit confirmation — take their details and deliver them to Acme's own sink. The
+// recipe is a composition of existing primitives, not a platform feature: an ordinary confirm-gated
+// action plus a declarative HTTP connector whose endpoint and credential are operator-managed
+// (`noodle variables set LEAD_SINK_URL …`, `noodle secrets set LEAD_SINK_TOKEN …`). The payload
+// rests only in Acme's own system; the platform stores no lead. A vendor sink is the same shape as
+// data: Resend/Postmark take `auth: { kind: 'apiKey', … }`, a HubSpot private app takes
+// `auth: { kind: 'bearer', … }` — never a named vendor package.
+const leadSink = connector('lead_sink')
+  .version('1.0.0')
+  .http({
+    baseUrl: variable('LEAD_SINK_URL'),
+    allowedOrigins: ['https://acme.example'],
+    auth: { kind: 'bearer', secret: secret('LEAD_SINK_TOKEN') },
+    operations: {
+      submit_lead: {
+        type: 'action',
+        method: 'POST',
+        path: '/api/assistant-lead',
+        input: z.object({
+          name: z.string().trim().min(2).max(120),
+          workEmail: z.email().max(240),
+          company: z.string().trim().min(2).max(200),
+          note: z.string().max(500),
+        }),
+        output: z.object({ ok: z.boolean() }),
+        request: {
+          name: '${args.name}',
+          workEmail: '${args.workEmail}',
+          company: '${args.company}',
+          note: '${args.note}',
+          // Fixed attribution, set here rather than model-supplied: Acme's sink can trust it.
+          source: 'website-assistant',
+        },
+        response: { ok: '${response.ok}' },
+      },
+    },
+  });
+
+const captureLead = tool('capture_lead', {
+  title: 'Send my details to Acme',
+  description:
+    'Send the visitor’s contact details and trip interest to Acme Getaways so the team may follow ' +
+    'up. Call only after the visitor explicitly agrees to be contacted; the confirmation card is ' +
+    'their consent moment. After a confirmed success, say only that the details were sent — never ' +
+    'promise response timing.',
+  annotations: annotations.action({ confirm: true }),
+  input: z.object({
+    name: z.string().trim().min(2).max(120).meta({ title: 'Your name' }),
+    workEmail: z.email().max(240).meta({ title: 'Work email' }),
+    company: z.string().trim().min(2).max(200).meta({ title: 'Company' }),
+    note: z.string().max(500).default('').meta({ title: 'What are you planning?' }),
+  }),
+  output: z.object({ ok: z.boolean() }),
+  fulfil: ({ input, connectors }) => {
+    const result = connectors.leads.submitLead({
+      name: input.name,
+      workEmail: input.workEmail,
+      company: input.company,
+      note: input.note,
+    });
+    return { ok: result.ok };
+  },
+});
+
+// The mixed surface's sign-in trigger (ADR 0201): reading `${user.id}` classifies this tool
+// requires-identity, so an anonymous visitor who reaches for it sees the sign-in card instead of an
+// error — and after signing in on Acme's account origin, the conversation continues under the
+// authenticated surface below.
+const myTrips = tool('my_trips', {
+  title: 'My saved trips',
+  description: 'Read the signed-in traveler’s saved trips and their booking status.',
+  annotations: readOnly,
+  input: z.object({}),
+  output: z.object({
+    traveler: z.string(),
+    status: z.string(),
+  }),
+  fulfil: ({ user }) => ({
+    traveler: user.id as string,
+    status: 'No trips booked yet — shortlist a getaway to start one.',
+  }),
+});
+
 // Grounding beyond the catalog: two controlled files answer policy/pricing/support questions with
 // 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
@@ -241,23 +329,49 @@ export default server(
     handoff: {
       allowedDomains: ['https://book.acme.example', 'https://acme.example'],
     },
-    // 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. The knowledge
-    // component projects its generated search capability the same way a tool does.
+    use: { leads: leadSink },
+    // The same tools also serve Acme's own websites, with no second tool set. The marketing site is
+    // a **mixed** surface (`signIn: true`): a visitor with no account gets discovery, the booking
+    // handoff, and the confirm-gated lead capture — and reaching for `my_trips` raises the sign-in
+    // card instead of an error, with `signUpAction` offering account creation through Acme's own
+    // registration. After the login redirect lands on the account origin, the same conversation
+    // continues under the authenticated surface's capabilities and instructions (ADR 0201).
+    // `capabilities` is the whole externally reachable surface per front door — short enough to
+    // review in one glance, and closed by default when a tool is added to the server later.
     assistant: embeddedAssistant({
       model: noodleManaged(),
-      access: publicWebsite({
-        origins: ['https://getaways.acme.example'],
-        capabilities: [destinations, discoverGetaways, createHandoff, shortlistGetaway],
-        instructions:
-          'Be a friendly, consultative travel guide, never pushy. Help visitors narrow a getaway before suggesting the next useful step. Ground recommendations in Acme knowledge, and clearly separate discovery from booking.',
-      }),
+      access: [
+        publicWebsite({
+          origins: ['https://getaways.acme.example'],
+          capabilities: [
+            destinations,
+            discoverGetaways,
+            createHandoff,
+            shortlistGetaway,
+            captureLead,
+            myTrips,
+          ],
+          signIn: true,
+          instructions:
+            'Be a friendly, consultative travel guide, never pushy. Help visitors narrow a getaway before suggesting the next useful step. Ground recommendations in Acme knowledge, and clearly separate discovery from booking. When a visitor’s plans firm up, invite them to sign in or create an account; if they would rather not, offer — once — to send their details to the Acme team instead.',
+        }),
+        authenticatedWebsite({
+          origins: ['https://account.acme.example'],
+          capabilities: [destinations, discoverGetaways, createHandoff, myTrips],
+          instructions:
+            'The traveler is signed in. Help them plan from their saved trips, and keep booking on Acme’s own pages through the handoff.',
+        }),
+      ],
       layout: { mode: 'floating', position: 'bottom-right' },
-      labels: { welcomeHeading: 'Where would you like to go?' },
+      labels: {
+        welcomeHeading: 'Where would you like to go?',
+        signInHeading: 'Continue with your Acme account',
+        signInBody: 'Saved trips need an account.',
+        signInAction: 'Sign in',
+        signUpAction: 'Create free account',
+      },
     }),
     knowledge: [destinations],
   },
-  [discoverGetaways, createHandoff, shortlistGetaway],
+  [discoverGetaways, createHandoff, shortlistGetaway, captureLead, myTrips],
 );

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

@@ -30,6 +30,45 @@ describe('acme-discovery example', () => {
     );
   });
 
+  it('keeps the lead capture behind explicit confirmation and a managed customer sink', async () => {
+    const manifest = (await app.toManifest()) as {
+      tools: { name: string; annotations?: Record<string, unknown> }[];
+    };
+    const captureLead = manifest.tools.find((tool) => tool.name === 'capture_lead');
+    // The confirmation card is the visitor's consent moment (ADR 0214): a lead may never leave the
+    // conversation without it, and the sink endpoint/credential stay operator-managed data.
+    expect(captureLead?.annotations?.confirm).toBe(true);
+    const catalog = JSON.stringify(
+      (app as unknown as { toConnectorCatalog: () => unknown }).toConnectorCatalog(),
+    );
+    expect(catalog).toContain('${env.LEAD_SINK_URL}');
+    expect(catalog).toContain('LEAD_SINK_TOKEN');
+    // Fixed attribution set in the request mapping, never model-supplied; no named vendor host.
+    expect(catalog).toContain('website-assistant');
+    expect(catalog).not.toContain('api.resend.com');
+    expect(catalog).not.toContain('api.hubapi.com');
+  });
+
+  it('serves a mixed marketing surface and an authenticated account surface from one server', async () => {
+    const manifest = await app.toManifest();
+    const surfaces = manifest.server.assistant?.surfaces ?? [];
+    expect(surfaces.map((surface) => surface.mode)).toEqual(['mixed', 'authenticated']);
+    // The sign-in trigger is listed on the mixed surface so the assistant can offer it; the
+    // authenticated surface carries its own narrowed list and voice.
+    const capabilityNames = (surface: (typeof surfaces)[number]) =>
+      surface.capabilities?.map((capability) => capability.name) ?? [];
+    expect(capabilityNames(surfaces[0]!)).toContain('my_trips');
+    expect(capabilityNames(surfaces[0]!)).toContain('capture_lead');
+    expect(capabilityNames(surfaces[1]!)).toEqual([
+      'destinations',
+      'discover_getaways',
+      'create_handoff',
+      'my_trips',
+    ]);
+    // Authoring the sign-up label is the opt-in for the card's create-account button.
+    expect(manifest.server.assistant?.labels?.signUpAction).toBe('Create free account');
+  });
+
   it('declares the grounded knowledge component and its live site scope', async () => {
     const manifest = (await app.toManifest()) as { server: { knowledge?: unknown[] } };
     // One declaration: controlled files plus the live public site, compiled later into the

package/skills/claude-code/examples/food-ordering/src/server.ts

@@ -363,6 +363,7 @@ export default server(
           'delivery',
           'checkout',
         ],
+        oncePerSession: true,
       },
       input: z.object({
         query: z.string().optional(),

package/skills/claude-code/examples/food-ordering/test/server.test.ts

@@ -86,6 +86,7 @@ describe('food-ordering example', () => {
         'menu',
         'checkout',
       ]),
+      'x-noodleseed-model-once-per-session': true,
     });
     expect(JSON.stringify(tools.get('sync_cart'))).toContain('revision');
     expect(tools.get('sync_cart')?.annotations?.confirm).toBe(false);

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.84.0 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.85.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.84.0 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.85.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

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

@@ -107,11 +107,19 @@ access: publicWebsite({
   capabilities: [answerProductQuestion, requestDemo, myOrders],
   signIn: true,   // `myOrders` reads ${user}; visitors sign in to reach it
 }),
+labels: {
+  signInHeading: "Continue with your Acme account",
+  signInBody: "Order history needs an account.",   // optional; empty hides the line
+  signInAction: "Sign in",
+  signUpAction: "Create free account",             // authoring this label is the sign-up opt-in
+},
 ```
 
+The sign-in card renders on the same themed chrome as every proposal card and follows the server `branding`. Authoring `signUpAction` adds a second button; leaving it out renders none. Both buttons raise the same `assistant-sign-in-requested` event with the same single-use ticket — the detail adds `intent: "sign-in" | "sign-up"` so the page routes `sign-up` to its registration page instead of its login. The ticket spend after account creation is identical to the one after sign-in; the service does not care which path produced the session. Headless renderers receive the same moment as a `data-sign-in` transcript part from `subscribeChat` (it has no status and is not respondable through `client.respond` — resolution is the elevated session).
+
 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. By default the pending request also completes itself: the service re-attempts the intercepted tool under the new principal and streams it as the elevated session first turn (one-shot; mooted if the visitor types first; confirm-gated tools stop at their confirmation card; pass `resume: false` beside the ticket to disable). Set honest expectations in UI copy — the assistant **remembers** the conversation and finishes the pending request, but no transcript is replayed to the browser, so after a full-page navigation earlier messages do not repaint. Say "the assistant remembers", never "your conversation will reappear". Do not build a second identity provider or client-side resume scaffolding for this.
+The conversation is kept server-side: same session, new token, the anonymous one dead. By default the pending request also completes itself: the service re-attempts the intercepted tool under the new principal and streams it as the elevated session first turn (one-shot; mooted if the visitor types first; confirm-gated tools stop at their confirmation card; pass `resume: false` beside the ticket to disable). On a backend-exchanged reattach the widget also repaints the bounded visible transcript (`endpoints.transcript`) before the resume runs — only rows the panel actually showed replay, never tool internals or a spent ticket. On an older service without the endpoint the panel starts visually fresh while the model still remembers, so keep copy honest either way: "the assistant remembers". Do not build a second identity provider or client-side resume scaffolding 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.
 

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

@@ -74,7 +74,7 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 ## Authoring signatures
 
 - `server(name, options, definitions)` — `options` commonly includes `title`, `version`, `instructions`, `agentGuide`, `distribution`, `branding`, `auth`, `use`, `provides`, `state`, and `handoff`; `definitions` is the array of tools/resources/prompts.
-- `tool(name, { description, input, output, annotations?, visibility?, modelVisibility?, view?, fulfil })` — `input`/`output` are Zod schemas; `fulfil({ input, connectors, user })` returns data matching `output`. Add `view: { component, entry }` for a React widget; use `visibility: ["app"]` for an app-only helper. Use `modelVisibility.latestMessageIncludesAny` only for normalized literal explicit-intent discovery; it does not authorize execution.
+- `tool(name, { description, input, output, annotations?, visibility?, modelVisibility?, view?, fulfil })` — `input`/`output` are Zod schemas; `fulfil({ input, connectors, user })` returns data matching `output`. Add `view: { component, entry }` for a React widget; use `visibility: ["app"]` for an app-only helper. Use `modelVisibility.latestMessageIncludesAny` only for normalized literal explicit-intent discovery; `oncePerSession` and `requiredWhenVisible` add deterministic presentation controls, never authorization or idempotency.
 - Keep tool input names application-owned and meaningful; `__noodleIntent` is reserved for an optional serve-time operator analytics adapter and never reaches `fulfil`.
 - `resource(name, { uri, description?, mimeType?, fulfil })` and `prompt(name, { description?, arguments?, fulfil })` expose MCP resources/prompts.
 - View metadata (`viewTitle`, `viewDescription`, `csp`, `domain`, `permissions`) belongs on the tool that renders it; `asset("./path")` packages local files.
@@ -146,7 +146,7 @@ prompt('summarize_ticket', {
 
 ### Non-trivial tool: ctx connectors, annotations, visibility, async
 
-`ctx` is `{ input, user, connectors }`. Bind connectors with `use` on the server, then call one inside `fulfil` to record a step. `annotations.readOnly()` declares a closed-world safe read. TypeScript action helpers enforce confirmation only with `{ confirm: true }`; omitted or `false` executes directly, and action/destructive/open-world hints alone never enable the gate. For stateless hosts that cannot present Noodle confirmation, set `interactions: { confirmationFallback: 'host' }` in the `server` options to explicitly trust native host write approval; omission remains fail-closed and the fallback never supplies missing `ctx.elicit` input. `visibility` defaults to `['model', 'app']` — set `['app']` to hide a helper from the model. For a narrow explicit-intent tool, `modelVisibility: { latestMessageIncludesAny: [...] }` deterministically limits model discovery to a latest user message containing one of the normalized literal phrases; it is not authorization. `fulfil` may be `async` (the compiler awaits it while recording).
+`ctx` is `{ input, user, connectors }`. Bind connectors with `use` on the server, then call one inside `fulfil` to record a step. `annotations.readOnly()` declares a closed-world safe read. TypeScript action helpers enforce confirmation only with `{ confirm: true }`; omitted or `false` executes directly, and action/destructive/open-world hints alone never enable the gate. For stateless hosts that cannot present Noodle confirmation, set `interactions: { confirmationFallback: 'host' }` in the `server` options to explicitly trust native host write approval; omission remains fail-closed and the fallback never supplies missing `ctx.elicit` input. `visibility` defaults to `['model', 'app']` — set `['app']` to hide a helper from the model. For a narrow explicit-intent tool, `modelVisibility: { latestMessageIncludesAny: [...] }` deterministically limits model discovery to a latest user message containing one normalized literal phrase. Add `oncePerSession: true` to prevent another successful model-selected use in that conversation, and `requiredWhenVisible: true` only when the matching tool must be called before normal discovery resumes. These are presentation controls, not authorization or idempotency. `fulfil` may be `async` (the compiler awaits it while recording).
 
 ```ts
 import { annotations, connector, server, tool, z } from '@noodleseed/one';

package/skills/claude-code/references/widgets-and-apps.md

@@ -12,7 +12,7 @@
 
 ## Tools and views
 
-Use `tool(name, { description, input, output, fulfil, view })` for a model-visible tool that renders a widget, and the same `tool(name, { ..., visibility: ["app"] })` for an app-only helper hidden from the model. When a view is valid only for narrow explicit intent, add `modelVisibility: { latestMessageIncludesAny: ["open the form", ...] }`; Noodle normalizes and matches those literal phrases against the latest user message before model discovery and fails closed on malformed data. This is relevance filtering, never authorization. A `view` is `{ component: "name", entry: "./views/name.tsx" }` — a React component the compiler bundles at validate/deploy time.
+Use `tool(name, { description, input, output, fulfil, view })` for a model-visible tool that renders a widget, and the same `tool(name, { ..., visibility: ["app"] })` for an app-only helper hidden from the model. When a view is valid only for narrow explicit intent, add `modelVisibility: { latestMessageIncludesAny: ["open the form", ...] }`; Noodle normalizes and matches those literal phrases against the latest user message before model discovery and fails closed on malformed data. Add `oncePerSession: true` when a successful model-selected view must not repeat in that conversation, and `requiredWhenVisible: true` only when a matching turn must render that sole required tool before normal model discovery resumes. These options control presentation and relevance, never idempotency or authorization. A `view` is `{ component: "name", entry: "./views/name.tsx" }` — a React component the compiler bundles at validate/deploy time.
 
 ## Noodle Design default
 

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.84.0 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.85.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.84.0 hash:eccc3c158dcafba8 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:11523cb33b9473c0 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:9fd67d4d24328e15 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:21bbd3ec441ffd30 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:0fa48a82fe836cf0 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.85.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.84.0 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.85.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.84.0 hash:78a6f181b61f92f1 -->
+<!-- noodle-skill version:0.85.0 hash:78a6f181b61f92f1 -->
 
 # designing-mcp-products