@noodleseed/agent-kit 0.84.1 → 0.86.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.84.1",
+  "version": "0.86.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.1 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.86.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.1 hash:11523cb33b9473c0 -->
+<!-- noodle-skill version:0.86.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.1 hash:9fd67d4d24328e15 -->
+<!-- noodle-skill version:0.86.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.1 hash:21bbd3ec441ffd30 -->
+<!-- noodle-skill version:0.86.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.1 hash:0fa48a82fe836cf0 -->
+<!-- noodle-skill version:0.86.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.1 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.86.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.1 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.86.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.1 hash:78a6f181b61f92f1 -->
+<!-- noodle-skill version:0.86.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.1 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.86.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/customer-auth/README.md

@@ -380,7 +380,15 @@ loopback development origins such as `http://localhost:3000`, `http://127.0.0.1:
 
 The bounded `presentation` object configures the panel, launcher, header, composer, and messages. Its
 primitives derive colors from shared server `branding`; raw HTML, CSS, inline SVG, renderer classes, and
-callbacks are not accepted.
+callbacks are not accepted. This example omits `presentation.panel.surface`, so the renderer keeps the
+opaque default panel treatment while the example's light/dark `branding` surfaces provide its customer colors;
+set the bounded surface to `glass` only when translucency is intentional.
+
+These TypeScript values remain the reusable developer defaults. After deployment, an environment operator
+can adjust theme, logo, launcher style, position, and the bounded color palette from the Console's
+**Assistant** tab or `noodle assistant appearance` without changing the customer's embed code. See the
+[embedded assistant guide](https://docs.noodleseed.dev/guides/embedded-assistant) for precedence and reset
+behavior.
 
 Create the backend credential after deployment. The CLI writes it to a mode-0600 file and never prints the
 secret:

package/skills/claude-code/examples/customer-auth/src/server.ts

@@ -173,14 +173,22 @@ export default server(
       access: authenticatedWebsite({
         origins: [assistantOrigin, 'https://dev.noodleseed.com', 'http://localhost:3000'],
       }),
-      layout: { mode: 'floating', position: 'bottom-right', panelWidth: 420 },
+      theme: 'auto',
+      layout: { mode: 'floating', position: 'bottom-center', panelWidth: 970 },
+      behavior: { showPoweredBy: true },
       labels: {
         welcomeHeading: 'How can I help with Noodle Seed?',
+        launcherPlaceholder: 'Ask Noodle Seed anything',
         composerPlaceholder: 'Ask about your apps…',
       },
       presentation: {
-        panel: { surface: 'glass', elevation: 'soft', border: 'subtle' },
-        launcher: { icon: 'brand-mark', status: 'session', effect: 'pulse' },
+        panel: { elevation: 'soft', border: 'subtle' },
+        launcher: {
+          style: 'pill',
+          icon: 'brand-mark',
+          status: 'session',
+          effect: 'pulse',
+        },
         header: {
           mark: 'status',
           badge: { text: 'Workspace online', tone: 'success', indicator: true },

package/skills/claude-code/examples/customer-auth/test/server.test.ts

@@ -9,7 +9,7 @@ describe('customer-auth example', () => {
       model: { kind: 'openai-compatible', apiKey: 'ASSISTANT_MODEL_API_KEY' },
       layout: { mode: 'floating' },
       presentation: {
-        panel: { surface: 'glass', elevation: 'soft', border: 'subtle' },
+        panel: { elevation: 'soft', border: 'subtle' },
         launcher: { icon: 'brand-mark', status: 'session', effect: 'pulse' },
         header: { mark: 'status', badge: { text: 'Workspace online', tone: 'success' } },
       },

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.1 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.86.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.1 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.86.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

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

@@ -53,7 +53,7 @@ assistant: embeddedAssistant({
   access: authenticatedWebsite({
     origins: ["http://localhost:3000", "https://app.example.com"],
   }),
-  layout: { mode: "floating", position: "bottom-right" },
+  layout: { mode: "floating", position: "bottom-center" },
 }),
 ```
 
@@ -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.
 
@@ -134,13 +142,15 @@ Keep portable identity and semantic light/dark colors in the one server-level `b
 
 ```ts
 assistant: embeddedAssistant({
-  model, allowedOrigins,
-  layout: { panelWidth: 520, panelMinHeight: 540, panelMaxHeight: 740, edgeOffset: 24 },
-  behavior: { showTimestamps: true },
-  labels: { composerPlaceholder: "Message Acme Support…", sessionReady: "Acme support is online" },
+  model,
+  access: authenticatedWebsite({ origins: ["https://app.example.com"] }),
+  theme: "invert",
+  layout: { position: "bottom-right", panelWidth: 520, panelMinHeight: 540, panelMaxHeight: 740, edgeOffset: 24 },
+  behavior: { showTimestamps: true, showPoweredBy: false },
+  labels: { launcherPlaceholder: "Ask Acme anything", composerPlaceholder: "Message Acme Support…", sessionReady: "Acme support is online" },
   presentation: {
     panel: { surface: "solid", elevation: "dramatic", border: "strong", radius: 20 },
-    launcher: { icon: "chat", size: "lg", status: "session", effect: "pulse" },
+    launcher: { style: "bubble", icon: "chat", size: "lg", status: "session", effect: "pulse" },
     header: {
       mark: "status",
       badge: { text: "Online", tone: "success", indicator: true },
@@ -151,9 +161,9 @@ assistant: embeddedAssistant({
 }),
 ```
 
-The Atlas-style product treatment above is the maximum deployment-configurable presentation. The bounded surface covers panel treatment, launcher icon/size/session pulse, header mark/status badge, composer controls, and message treatment; it does not accept custom header actions, structured empty-state layouts, footers, spectacle variants/effects, or tenant code.
+The Atlas-style product treatment above is the maximum deployment-configurable presentation. The bounded surface covers panel treatment, pill/bubble launcher style plus icon/size/session pulse, header mark/status badge, composer controls, and message treatment; it does not accept custom header actions, structured empty-state layouts, footers, tenant-defined launcher variants/effects, or tenant code.
 
-Omitted fields retain the quiet premium baseline. For exact application-owned color roles, pass the typed React `appearance={{ light: { panel: { surface, text, border }, composer: {...}, confirmation: {...}, primaryButton: {...} }, dark: {...} }}` prop or assign the same object to `element.appearance`. CSS custom properties inherit through the assistant host, so those values may reuse existing application tokens such as `surface: "var(--app-surface)"` without copying literals. The appearance surface covers canvas, panel, header, messages, composer, suggestions, confirmation, buttons, launcher, code, and the MCP App frame; the package README publishes the complete role-to-`--ns-assistant-*` map. Exact parseable literal colors are preserved and low contrast emits `assistant-appearance-warning`; contrast for unresolved CSS references remains host-owned. Precedence is host appearance object, host slots/public variables, deployed semantic presentation, then defaults. Prefer `server.ts` configuration first so every embedding app receives the same assistant after redeploy.
+Omitted UI fields retain the complete managed baseline: a bottom-center frosted prompt pill, 970px outer desktop shell with 20px side padding, 85vh/1025px height bounds, 24px panel with built-in `#F8F8F8` light and `#0C0A09` dark surfaces, bottom prompt chips and pill composer, plain assistant messages, 85%-wide user bubbles, Noodle Seed attribution, and mobile fullscreen. The pill morphs into an input before opening; `launcher.style: "bubble"` opens directly, while `panel.surface: "glass"` remains an explicit translucent alternative. `theme: "auto"` follows the host page and `"invert"` selects its opposite. The generic suggestions are defaults; an authored list, including `[]`, replaces them. The ChatGPT promotion is intentionally absent. For exact application-owned color roles, pass the typed React `appearance={{ light: { panel: { surface, text, border }, composer: {...}, confirmation: {...}, primaryButton: {...} }, dark: {...} }}` prop or assign the same object to `element.appearance`. CSS custom properties inherit through the assistant host, so those values may reuse existing application tokens such as `surface: "var(--app-surface)"` without copying literals. The appearance surface covers canvas, panel, header, messages, composer, suggestions, confirmation, buttons, launcher, code, and the MCP App frame; the package README publishes the complete role-to-`--ns-assistant-*` map. Exact parseable literal colors are preserved and low contrast emits `assistant-appearance-warning`; contrast for unresolved CSS references remains host-owned. Precedence is host appearance object, host slots/public variables, saved environment operator override, deployed semantic presentation, then defaults. Prefer reusable `server.ts` defaults; use the Console Assistant tab or `noodle assistant appearance show|apply|reset` for environment-owned changes that should reach existing embeds without a redeploy.
 
 Give every business action a portable `tool(..., { title: "Complete task", description: "This will mark the task complete for everyone.", input: z.object({ task: z.string().meta({ title: "Task" }) }) })` title. The standard confirmation uses the tool title/description plus schema field `title`, `description`, and `format`; it shows Confirm and Don't proceed and keeps technical action details secondary. Do not put JSON or implementation names in business-facing copy.
 
@@ -311,12 +321,15 @@ const session = await createAssistantSession({
 
 ```ts
 assistant: embeddedAssistant({
-  model, allowedOrigins,
-  sessionClaims: {
-    displayName: { exposeToModel: true },
-    accountTier: { exposeToModel: true },
-    region: {}, // tools only, never in the prompt
-  },
+  model,
+  access: authenticatedWebsite({
+    origins: ["https://app.example.com"],
+    sessionClaims: {
+      displayName: { exposeToModel: true },
+      accountTier: { exposeToModel: true },
+      region: {}, // tools only, never in the prompt
+    },
+  }),
 }),
 ```
 
@@ -372,7 +385,9 @@ import { NoodleAssistant } from "@noodleseed/assistant/react";
 
 Or import the package root once and mount `<noodle-assistant session-endpoint="/api/assistant/session" theme="auto"></noodle-assistant>`. Mount only inside the authenticated application surface.
 
-`theme="auto"` follows the browser operating-system preference. If the SaaS application owns a theme toggle, obtain its resolved application theme (`"light"` or `"dark"`), pass `theme={resolvedTheme}` to `NoodleAssistant`, and update the custom element's `theme` attribute when that value changes.
+That custom element is the complete managed assistant in Vue, Angular, or plain DOM; it has no React runtime requirement. Configure the framework to accept `noodle-assistant` as a custom element. If the session exchange needs an authenticated fetch wrapper, create the element imperatively, assign `element.fetch` and then `element.sessionEndpoint`, and append it only after both properties are set.
+
+`theme="auto"` follows an explicit host-page light/dark class or data attribute, then the browser operating-system preference; `theme="invert"` selects the opposite. If the SaaS application owns a theme toggle, obtain its resolved application theme (`"light"` or `"dark"`), pass `theme={resolvedTheme}` to `NoodleAssistant`, and update the custom element's `theme` attribute when that value changes.
 
 The component renders a custom element and must mount client-side. In a Next.js App Router tree, put the mount in a `"use client"` component; from a server component or the Pages Router, load it with `next/dynamic` and `ssr: false`.
 
@@ -627,7 +642,7 @@ Devtools privacy gate: default model and connector exercises to synthetic or moc
 
 - Signed-out session exchange returns `401`.
 - The browser network/DOM/storage contains no client secret or model key.
-- The local and production origins match `allowedOrigins` character-for-character.
+- The local and production origins match the authored `access.origins` character-for-character.
 - At the manifest/runtime boundary and in TypeScript action helpers, only `confirm: true` enables confirmation; omitted or `false` preserves direct execution. Action hints alone never enforce approval; `annotations.action({ confirm: false })` is equivalent to omission.
 - An expired turn re-exchanges once; interaction decisions never auto-retry. An explicit same-decision repeat returns the stored outcome without executing again.
 - Accept, decline, and cancel are single-use. Only accept executes; the server ignores replacement tool arguments.
@@ -645,9 +660,9 @@ Devtools privacy gate: default model and connector exercises to synthetic or moc
 | `assistant-error` with code `invalid_response` | The turn endpoint returned HTML or non-SSE content (auth redirect, proxy page) | Check the backend session route path and any middleware/rewrites on the embedding app |
 | Build error `Package path ./react is not exported` | Outdated package version with import-only export conditions | Update `@noodleseed/assistant`; do not add webpack aliases or type shims |
 | Deploy fails with `server_auth_required` | `--access customers` without `server.auth` | Add direct/federated OIDC or a built-in Firebase/Microsoft adapter |
-| Validate rejects an origin | Non-loopback HTTP origin in `allowedOrigins` | Use the exact HTTPS production origin; HTTP is only for `localhost`/`127.0.0.1` |
+| Validate rejects an origin | Non-loopback HTTP origin in `access.origins` | Use the exact HTTPS production origin; HTTP is only for `localhost`/`127.0.0.1` |
 | Session exchange returns 404 | `serviceUrl` points at the deployment MCP endpoint | Use the control-plane service URL printed by `noodle assistant clients create` |
-| Session exchange returns 403 `origin is not allowed` | Request origin differs from `allowedOrigins` character-for-character | Align the exact scheme/host/port on both sides and redeploy |
+| Session exchange returns 403 `origin is not allowed` | Request origin differs from the authored `access.origins` character-for-character | Align the exact scheme/host/port on both sides and redeploy |
 | Session exchange returns `400` with `invalid assistant routing` | The authenticated backend supplied an unknown endpoint name or a malformed/policy-disallowed URL | Resolve the route from server-owned membership, use the exact authored endpoint name, and ensure the canonical HTTPS URL satisfies its active `customerEndpoint` policy; the error never reflects the URL |
 | A routed assistant tool returns `connector_route_unavailable` | The authenticated backend omitted that endpoint during session exchange | Pass the server-verified route as `routing.endpoints.<name>` when minting a new session; keep it out of browser input |
 | Host session 503 | A required backend environment name is absent or mapped into the wrong deployment environment | Run `noodle assistant embed --check --json`, repair the host CI mapping, then probe the session route again |

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.1 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.86.0 hash:0f404109f4845683 -->
 
 # reporting-noodle-feedback