@noodleseed/agent-kit 0.58.1 → 0.59.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.58.1",
+  "version": "0.59.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.58.1 hash:ec5bfcd0d8165205 -->
+<!-- noodle-skill version:0.59.0 hash:ec5bfcd0d8165205 -->
 
 # 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.58.1 hash:0b2fd8c7e43fc69f -->
+<!-- noodle-skill version:0.59.0 hash:0b2fd8c7e43fc69f -->
 
 # 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.58.1 hash:f7fa54992c8d7692 -->
+<!-- noodle-skill version:0.59.0 hash:f7fa54992c8d7692 -->
 
 # 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 credentials, an API URL, an OpenAPI document, or an observed response must become real Noodle Seed MCP behavior."
 ---
 
-<!-- noodle-skill version:0.58.1 hash:1e86b8704f407bd3 -->
+<!-- noodle-skill version:0.59.0 hash:1e86b8704f407bd3 -->
 
 # connecting-apis-to-mcp
 

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.58.1 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.59.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.58.1 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.59.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.58.1 hash:76cce86729cffbee -->
+<!-- noodle-skill version:0.59.0 hash:76cce86729cffbee -->
 
 # 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.58.1 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.59.0 hash:cc54a67f21c0ecdb -->
 
 # embedding-mcp-assistants
 

package/skills/claude-code/examples/customer-auth/README.md

@@ -4,9 +4,9 @@ This curated example owns the customer/end-user authentication capability slot.
 can protect an MCP endpoint with direct OIDC, retain role/scope-based tool authorization, and route ordinary
 reads and confirmed actions to the API origin selected by the verified customer's identity provider.
 
-It also owns the customer-branded embedded-assistant presentation showcase. Embedded sessions lack
-direct/federated MCP OIDC endpoint claims, so these routed tools fail with `connector_route_unavailable`;
-static connectors still support embedded delegated exchange. Exercise routed tools through the MCP endpoint.
+It also owns the customer-branded embedded-assistant presentation showcase. Direct MCP calls obtain the
+route from the verified OIDC claim; embedded sessions obtain it from the authenticated customer backend's
+session exchange. Both paths keep the URL outside tool/model/browser-visible state.
 
 The public developer entrypoint is [`src/server.ts`](src/server.ts). It exposes a deliberately small MCP
 surface for organization discovery and app lifecycle operations:
@@ -60,6 +60,12 @@ const api = connector('noodleseed_app_api')
   });
 ```
 
+At both connector and operation level, auth must be omitted or use `delegatedTokenExchange`. The compiler
+validates the concrete connector definition emitted from TypeScript, including connector defaults and
+operation overrides, and reports the exact failing auth path and kind. Do not keep a bearer, API-key,
+client-credentials, or managed-provider fallback for local mode; use operation fakes while leaving auth
+declarative.
+
 ## Map the endpoint from verified OIDC
 
 The IdP claim contains the complete base URL, including an optional base path. Routing is separate from the
@@ -165,7 +171,9 @@ and refresh, then maps approved versions of this app/environment to `noodleseed-
 apps and environments use distinct audiences.
 
 Run `noodle auth doctor src/server.ts` before sharing. Its bounded, read-only probes never register a client.
-Adding the embedded assistant does not choose or rewrite MCP customer auth.
+Adding the embedded assistant does not choose or rewrite MCP customer auth. Its authenticated backend may
+bind `routing.endpoints.customer_api` during assistant-session exchange from server-owned membership data;
+direct MCP requests continue to resolve the same endpoint from the configured verified OIDC claim.
 
 ## Per-tool authorization remains independent
 
@@ -325,9 +333,11 @@ The embedded assistant uses a customer-supplied OpenAI Chat Completions-compatib
 managed values at the Noodle deployment environment; none of these values belongs in the customer web
 application environment, and the API key never reaches the browser:
 
-The assistant session carries a verified user, tenant, deployment, roles, and scopes, but not the IdP's
-`tenant.api_base_url` claim. These routed operations are MCP-only; do not copy the route into page context,
-session claims, tool input, or model instructions.
+The assistant session carries a verified user, tenant, deployment, roles, and scopes. For this flagship's
+routed tools, the embedding backend resolves the signed-in user's cluster from server-owned membership data
+and passes `routing: { endpoints: { customer_api: cluster.apiBaseUrl } }` to
+`createAssistantSession`. Noodle validates and privately stores that route; it is not returned to the
+browser. Do not copy the route into page context, session claims, tool input, or model instructions.
 
 ```bash
 noodle variables set ASSISTANT_MODEL_BASE_URL https://model.example.com/v1 --scope env
@@ -530,8 +540,9 @@ After deployment, use the assistant doctor to verify the embed client, model, an
 noodle assistant doctor --user-id <real-test-user> --origin "$PUBLIC_APP_ORIGIN" --org <org> --app <app> --env <env>
 ```
 
-This does not add an OIDC customer route. Routed operations succeed only through a direct/federated
-customer-authenticated MCP request with an allowed endpoint claim.
+The doctor does not invent or test an application-specific customer route. Prove routed assistant tools by
+having the authenticated embedding backend pass the user's server-verified endpoint during session
+exchange, then invoke one representative safe read.
 
 If the application deliberately sends a first turn on mount, do not combine a persistent "sent" ref with a
 mount effect. React Strict Mode can abort that provisional request and then suppress the stable remount.

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.58.1 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.59.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.58.1 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.59.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

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

@@ -110,6 +110,8 @@ For `customerAuth.oidc(...)` and `.federatedOidc(...)`, the application develope
 
 That metadata must expose HTTPS `authorization_endpoint`, `token_endpoint`, `jwks_uri`, and RFC 7591 `registration_endpoint`; advertise authorization-code and refresh-token grants, Dynamic Client Registration, PKCE with `code_challenge_methods_supported: ["S256"]`, and public clients with `token_endpoint_auth_methods_supported: ["none"]`. Validate the exact RFC 8707 `resource` on authorize, code exchange, and refresh, then map approved versions of one app/environment to the stable audience configured in `customerAuth`; use distinct audiences across apps and environments. Publish only public signing keys in JWKS. Run `noodle auth doctor src/server.ts`; its issuer-readiness probes perform bounded read-only GET checks and never register a client. A successful `noodle deploy --access customers` reports the same readiness without turning a diagnostic failure into a failed deployment.
 
+The MCP client, or Devtools during local testing, opens the configured `authorization_endpoint`; Noodle does not submit the login form or manage the authorization server's session or CSRF cookies. Keep the login and consent UI plus credential POST on the same origin as the authorization endpoint. If a separate-site UI is unavoidable, the authorization server must explicitly trust the UI origin, use exact credentialed CORS where browser JavaScript calls it, issue the session and CSRF cookies needed by cross-site POSTs as `SameSite=None; Secure`, and return a CSRF token that the UI submits with credentials. Cookies cannot be shared across unrelated registrable domains. Browser privacy controls may still block this cross-site flow, so a same-origin route or reverse proxy remains the reliable design.
+
 Verify customer OAuth in three explicit layers. First run `noodle auth doctor src/server.ts --json`; a pass proves metadata and JWKS readiness, but it does not prove that registration or token issuance succeeds. Next run `noodle test src/server.ts --json`; for a protected app it proves that anonymous MCP access fails closed with exact protected-resource metadata and returns `interactiveRequired: true`. Finally run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or one representative safe read. Only that final layer proves issuer, signature, stable audience, and exact-resource binding together. Never report a passing doctor or anonymous boundary smoke as working end-to-end authentication.
 
 ## Auth-derived customer API endpoints
@@ -192,6 +194,8 @@ export default server(
 
 `customerEndpoint` accepts exactly one non-empty policy arm: exact HTTPS origins, or HTTPS hostname suffixes. Exact policies may authorize an explicit non-default port; suffix policies allow port 443 and match only the exact host or dot-boundary subdomains. Do not add connector `allowedOrigins` to a customer-routed connector. Its fixed credential/token endpoints are validated independently and cannot come from caller claims.
 
+Customer-routed connector auth must be omitted or use `delegatedTokenExchange` at both connector and operation level. The compiler validates the concrete connector definition emitted from TypeScript, including connector defaults and operation overrides. Do not emit bearer, API-key, client-credentials, or managed-provider fallbacks for local mode; use operation fakes while leaving auth declarative. `customer_endpoint_unsupported_auth` reports the exact failing path and auth kind.
+
 On a bidirectional MCP transport whose client negotiated form elicitation, Noodle sends the standard confirmation form. The current stateless hosted MCP transport cannot initiate that exchange, so the example explicitly declares `server.interactions.confirmationFallback: 'host'`. That fallback trusts the MCP host to have collected native write approval before the tool call reaches Noodle; it is never inferred from client identity and does not replace authentication, authorization, policy, or accurate action/destructive annotations. Omit it when connected hosts are not trusted to provide that approval; confirmation then fails closed with `interaction_unavailable` when the standard exchange is unavailable.
 
 Every federated issuer must repeat every endpoint key used by the app, although each issuer may choose a different claim path. Endpoint names use lowercase letters, numbers, and underscores. Resolved claims must be exact absolute HTTPS URLs of at most 2,048 UTF-8 bytes with no userinfo, query, fragment, IP literal, special-use host, or unsafe whitespace/control characters. The runtime preserves a canonical optional base path.
@@ -226,7 +230,7 @@ Role values are trusted only from the explicitly configured claim path (or the p
 
 Use delegated connector auth when the downstream API must enforce its own per-user authorization — a shared service credential plus a forwarded user id would bypass it. Three shapes exist; pick by who owns the downstream:
 
-- **`delegatedTokenExchange`** — your own API. The platform signs a short-lived, verifiable assertion of the signed-in user and exchanges it at a token endpoint you implement (RFC 8693). It works with verified customer OIDC identities and the built-in Firebase/Microsoft adapters; no per-user OAuth enrollment. Embedded-assistant sessions support this exchange for static connectors. Customer-routed connectors require a direct or federated MCP OIDC request and fail closed in embedded-assistant sessions because those sessions carry no IdP endpoint claim.
+- **`delegatedTokenExchange`** — your own API. The platform signs a short-lived, verifiable assertion of the signed-in user and exchanges it at a token endpoint you implement (RFC 8693). It works with verified customer OIDC identities and the built-in Firebase/Microsoft adapters; no per-user OAuth enrollment. Embedded-assistant sessions can bind customer-routed connectors when the authenticated embedding backend resolves each route from server-owned tenancy data and passes it during session exchange. Browser input, page context, session claims, and tool arguments cannot supply or override that private route authority.
 - **`delegatedOAuth` with `provider: "firebase" | "microsoft"`** — Noodle-managed bridge providers using stored per-user refresh tokens. Requires the matching `customerAuth` bridge; any other provider string is the compile error `unsupported_delegated_provider`.
 - **`delegatedSessionCookie`** — Firebase-managed session-cookie apps only; not a generic mechanism.
 
@@ -258,7 +262,7 @@ scope=time_off            (space-joined, when configured)
 audience=example-api      (when configured)
 ```
 
-The `subject_token` claims: `iss` (platform issuer; JWKS at `{iss}/.well-known/jwks.json`), `sub` (verified user id), `aud` (your configured audience or the tokenUrl), `email`, `name`, `claims` (declared session claims), `tenant` (`org/app/env`), `deployment`, `iat`, `exp` (about 120 s), `jti`. A routed exchange adds `route: { key, fingerprint }`, never the customer URL; credential cache and single-flight keys include that route binding. Respond with `{ "access_token": "...", "token_type": "Bearer", "expires_in": 900 }`; the broker caches per user + connector + scopes + route until `expires_in` minus 300 s and presents the token downstream as `Authorization: Bearer`.
+The `subject_token` claims: `iss` (platform issuer; JWKS at `{iss}/.well-known/jwks.json`), `sub` (verified user id), `aud` (your configured audience or the tokenUrl), `email`, `name`, `claims` (declared session claims), `tenant` (`org/app/env`), `deployment`, `customer_identity: { version: 1, issuer }`, `iat`, `exp` (about 120 s), `jti`. Key downstream users by `(customer_identity.issuer, sub)`, never by `sub` alone. Firebase uses `https://securetoken.google.com/<project-id>`; Microsoft uses `https://login.microsoftonline.com/<tenant-id>/v2.0`. A routed exchange adds `route: { key, fingerprint }`, never the customer URL; credential cache and single-flight keys include that route binding. Respond with `{ "access_token": "...", "token_type": "Bearer", "expires_in": 900 }`; the broker caches per user + connector + scopes + route until `expires_in` minus 300 s and presents the token downstream as `Authorization: Bearer`.
 
 ### The downstream token endpoint (your backend)
 
@@ -302,7 +306,7 @@ Local customer OIDC sign-in and delegated-exchange assertion trust are two disti
 
 **Never trust the Devtools issuer in production: anyone holding the local private key could impersonate a customer.**
 
-Diagnose statically with `noodle auth doctor`; set a short-lived real customer token only in `NOODLE_CUSTOMER_TOKEN` and add `--live --org <org> --app <app> --env <env>` to perform one exchange per delegated binding without invoking a business tool. Add `--version <version>` to test that exact pinned MCP resource. Common failures include structured `credential_unavailable` reasons such as `caller_identity_not_customer`. Direct/federated OIDC verification assigns the customer identity at the trusted verifier boundary; never ask an IdP to mint a Noodle-specific classification claim.
+Diagnose statically with `noodle auth doctor`; set a short-lived real customer token only in `NOODLE_CUSTOMER_TOKEN` and add `--live --org <org> --app <app> --env <env>` to perform one exchange per delegated binding without invoking a business tool. Add `--version <version>` to test that exact pinned MCP resource. Common failures include structured `credential_unavailable` reasons such as `caller_identity_not_customer`. For a Firebase/Microsoft bridge, `caller_issuer_missing` means the session predates issuer binding: reconnect once through customer authentication, then retry. No IdP custom claim or `server.ts` change is required. Direct/federated OIDC verification assigns the customer identity at the trusted verifier boundary; never ask an IdP to mint a Noodle-specific classification claim.
 
 ## Design tools for the model
 

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

@@ -128,13 +128,13 @@ noodle assistant clients create --name web --org <org> --app <app> --env <env>
 
 The CLI writes `{ clientId, clientSecret }` to a mode-`0600` file and prints only its path. Move the values into the SaaS backend secret manager without printing or committing them. Rotation invalidates the previous secret.
 
-Validate the active deployment, backend credential, exact origin, and delegated credential exchanges without invoking a business tool:
+Validate the active deployment, backend credential, exact origin, and delegated credential exchanges that do not require an application-specific customer route:
 
 ```sh
 noodle assistant doctor --origin "$PUBLIC_APP_ORIGIN" --org <org> --app <app> --env <env>
 ```
 
-The doctor reads `NOODLE_ASSISTANT_CLIENT_ID` / `NOODLE_ASSISTANT_CLIENT_SECRET` or the saved mode-0600 client file and never prints the secret. Pass `--user-id <real-test-user>` only when the downstream exchange requires an existing application user.
+The doctor reads `NOODLE_ASSISTANT_CLIENT_ID` / `NOODLE_ASSISTANT_CLIENT_SECRET` or the saved mode-0600 client file and never prints the secret. Pass `--user-id <real-test-user>` only when the downstream exchange requires an existing application user. The assistant doctor does not supply application-specific routes; after the backend mints a routed session, invoke one representative safe read to verify its route-bound exchange and connector together.
 
 ## Integrate the customer backend
 
@@ -171,6 +171,32 @@ Authenticate before exchange. Pass backend-verified `user.roles` and OAuth-style
 
 `serviceUrl` is the Noodle Seed control-plane base URL: the value `noodle assistant clients create` prints, also stored as `serviceUrl` in `deployment.json`. It is NOT the deployment MCP endpoint (`url`, which ends in `/v1/mcp` and rejects session exchange). Never probe or guess endpoints with real credentials.
 
+### Route customer endpoints from the backend
+
+When a connector uses `customerEndpoint("customer_api", ...)`, resolve the signed-in user's API base URL from authenticated, server-owned tenancy data and bind it during session exchange:
+
+```ts
+const user = await requireCurrentUser(request);
+const account = await requireAccountMembership(user.id);
+
+const session = await createAssistantSession({
+  serviceUrl,
+  clientId,
+  clientSecret,
+  origin,
+  user: { id: user.id, email: user.email },
+  routing: {
+    endpoints: {
+      customer_api: account.clusterApiBaseUrl,
+    },
+  },
+});
+```
+
+The browser does not send `routing`. Authenticate the user and validate account/cluster membership before selecting the URL. Never read it from page context, request headers, session claims, tool arguments, or model output. The endpoint key must match the authored `customerEndpoint` name. Noodle validates the canonical HTTPS URL against the active artifact policy, stores it only in the private short-lived session, and omits it from the session response and caller identity.
+
+Routing is optional: static tools continue to work, while a tool whose endpoint was omitted fails closed with `connector_route_unavailable` before credential or connector egress. A confirmed routed action binds a URL-blind fingerprint at proposal time and rejects a missing or changed route on acceptance.
+
 ## Ground time and ambient facts
 
 Every assistant turn receives a server-authoritative instant and user-local date/time. Locale and IANA time zone resolve in this order: backend-verified `preferences` from session exchange, fresh per-turn browser `clientContext` hints, `server.context.defaults`, then platform defaults (`en-US`/`UTC`). Browser hints affect presentation and relative-date interpretation only; they are untrusted and never authorize a tool.
@@ -515,6 +541,7 @@ Devtools privacy gate: default model and connector exercises to synthetic or moc
 - 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.
 - Wrong-origin and malformed-origin requests fail closed.
+- Browser-controlled fields cannot select or override `routing.endpoints`; a customer-routed connector uses only the backend-verified session route.
 - Run the production-equivalent host build after regenerating environment bindings.
 - In a real browser, submit with the keyboard, inspect console and network failures, complete session exchange and one tool turn, and render one linked App before claiming the host works.
 
@@ -530,6 +557,8 @@ Devtools privacy gate: default model and connector exercises to synthetic or moc
 | 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` |
 | 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 `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 |
 | `HEAD` on a widget or session path looks broken | The route contract is `GET` for the hosted sandbox/widget document or `POST` for session exchange; `HEAD` is not the product flow | Exercise the documented method and inspect its response instead of inferring readiness from `HEAD` |
 | Local server reports `listen EPERM` | The coding sandbox blocked loopback binding before application behavior ran | Rerun the same local/browser test with approved loopback permissions; do not change product code |

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.58.1 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.59.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.58.1 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.59.0 hash:6ef6ef551e26b78e -->
 
 # verifying-mcp-delivery
 

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.58.1 hash:ec5bfcd0d8165205 -->
+<!-- noodle-skill version:0.59.0 hash:ec5bfcd0d8165205 -->
 
 # 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.58.1 hash:0b2fd8c7e43fc69f -->
+<!-- noodle-skill version:0.59.0 hash:0b2fd8c7e43fc69f -->
 
 # 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.58.1 hash:f7fa54992c8d7692 -->
+<!-- noodle-skill version:0.59.0 hash:f7fa54992c8d7692 -->
 
 # building-mcp-apps
 

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

@@ -3,7 +3,7 @@ name: connecting-apis-to-mcp
 description: "Use when credentials, an API URL, an OpenAPI document, or an observed response must become real Noodle Seed MCP behavior."
 ---
 
-<!-- noodle-skill version:0.58.1 hash:1e86b8704f407bd3 -->
+<!-- noodle-skill version:0.59.0 hash:1e86b8704f407bd3 -->
 
 # 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.58.1 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.59.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.58.1 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.59.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.58.1 hash:76cce86729cffbee -->
+<!-- noodle-skill version:0.59.0 hash:76cce86729cffbee -->
 
 # designing-mcp-products
 

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

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

package/skills/codex/examples/customer-auth/README.md

@@ -4,9 +4,9 @@ This curated example owns the customer/end-user authentication capability slot.
 can protect an MCP endpoint with direct OIDC, retain role/scope-based tool authorization, and route ordinary
 reads and confirmed actions to the API origin selected by the verified customer's identity provider.
 
-It also owns the customer-branded embedded-assistant presentation showcase. Embedded sessions lack
-direct/federated MCP OIDC endpoint claims, so these routed tools fail with `connector_route_unavailable`;
-static connectors still support embedded delegated exchange. Exercise routed tools through the MCP endpoint.
+It also owns the customer-branded embedded-assistant presentation showcase. Direct MCP calls obtain the
+route from the verified OIDC claim; embedded sessions obtain it from the authenticated customer backend's
+session exchange. Both paths keep the URL outside tool/model/browser-visible state.
 
 The public developer entrypoint is [`src/server.ts`](src/server.ts). It exposes a deliberately small MCP
 surface for organization discovery and app lifecycle operations:
@@ -60,6 +60,12 @@ const api = connector('noodleseed_app_api')
   });
 ```
 
+At both connector and operation level, auth must be omitted or use `delegatedTokenExchange`. The compiler
+validates the concrete connector definition emitted from TypeScript, including connector defaults and
+operation overrides, and reports the exact failing auth path and kind. Do not keep a bearer, API-key,
+client-credentials, or managed-provider fallback for local mode; use operation fakes while leaving auth
+declarative.
+
 ## Map the endpoint from verified OIDC
 
 The IdP claim contains the complete base URL, including an optional base path. Routing is separate from the
@@ -165,7 +171,9 @@ and refresh, then maps approved versions of this app/environment to `noodleseed-
 apps and environments use distinct audiences.
 
 Run `noodle auth doctor src/server.ts` before sharing. Its bounded, read-only probes never register a client.
-Adding the embedded assistant does not choose or rewrite MCP customer auth.
+Adding the embedded assistant does not choose or rewrite MCP customer auth. Its authenticated backend may
+bind `routing.endpoints.customer_api` during assistant-session exchange from server-owned membership data;
+direct MCP requests continue to resolve the same endpoint from the configured verified OIDC claim.
 
 ## Per-tool authorization remains independent
 
@@ -325,9 +333,11 @@ The embedded assistant uses a customer-supplied OpenAI Chat Completions-compatib
 managed values at the Noodle deployment environment; none of these values belongs in the customer web
 application environment, and the API key never reaches the browser:
 
-The assistant session carries a verified user, tenant, deployment, roles, and scopes, but not the IdP's
-`tenant.api_base_url` claim. These routed operations are MCP-only; do not copy the route into page context,
-session claims, tool input, or model instructions.
+The assistant session carries a verified user, tenant, deployment, roles, and scopes. For this flagship's
+routed tools, the embedding backend resolves the signed-in user's cluster from server-owned membership data
+and passes `routing: { endpoints: { customer_api: cluster.apiBaseUrl } }` to
+`createAssistantSession`. Noodle validates and privately stores that route; it is not returned to the
+browser. Do not copy the route into page context, session claims, tool input, or model instructions.
 
 ```bash
 noodle variables set ASSISTANT_MODEL_BASE_URL https://model.example.com/v1 --scope env
@@ -530,8 +540,9 @@ After deployment, use the assistant doctor to verify the embed client, model, an
 noodle assistant doctor --user-id <real-test-user> --origin "$PUBLIC_APP_ORIGIN" --org <org> --app <app> --env <env>
 ```
 
-This does not add an OIDC customer route. Routed operations succeed only through a direct/federated
-customer-authenticated MCP request with an allowed endpoint claim.
+The doctor does not invent or test an application-specific customer route. Prove routed assistant tools by
+having the authenticated embedding backend pass the user's server-verified endpoint during session
+exchange, then invoke one representative safe read.
 
 If the application deliberately sends a first turn on mount, do not combine a persistent "sent" ref with a
 mount effect. React Strict Mode can abort that provisional request and then suppress the stable remount.

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.58.1 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.59.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.58.1 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.59.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

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

@@ -110,6 +110,8 @@ For `customerAuth.oidc(...)` and `.federatedOidc(...)`, the application develope
 
 That metadata must expose HTTPS `authorization_endpoint`, `token_endpoint`, `jwks_uri`, and RFC 7591 `registration_endpoint`; advertise authorization-code and refresh-token grants, Dynamic Client Registration, PKCE with `code_challenge_methods_supported: ["S256"]`, and public clients with `token_endpoint_auth_methods_supported: ["none"]`. Validate the exact RFC 8707 `resource` on authorize, code exchange, and refresh, then map approved versions of one app/environment to the stable audience configured in `customerAuth`; use distinct audiences across apps and environments. Publish only public signing keys in JWKS. Run `noodle auth doctor src/server.ts`; its issuer-readiness probes perform bounded read-only GET checks and never register a client. A successful `noodle deploy --access customers` reports the same readiness without turning a diagnostic failure into a failed deployment.
 
+The MCP client, or Devtools during local testing, opens the configured `authorization_endpoint`; Noodle does not submit the login form or manage the authorization server's session or CSRF cookies. Keep the login and consent UI plus credential POST on the same origin as the authorization endpoint. If a separate-site UI is unavoidable, the authorization server must explicitly trust the UI origin, use exact credentialed CORS where browser JavaScript calls it, issue the session and CSRF cookies needed by cross-site POSTs as `SameSite=None; Secure`, and return a CSRF token that the UI submits with credentials. Cookies cannot be shared across unrelated registrable domains. Browser privacy controls may still block this cross-site flow, so a same-origin route or reverse proxy remains the reliable design.
+
 Verify customer OAuth in three explicit layers. First run `noodle auth doctor src/server.ts --json`; a pass proves metadata and JWKS readiness, but it does not prove that registration or token issuance succeeds. Next run `noodle test src/server.ts --json`; for a protected app it proves that anonymous MCP access fails closed with exact protected-resource metadata and returns `interactiveRequired: true`. Finally run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or one representative safe read. Only that final layer proves issuer, signature, stable audience, and exact-resource binding together. Never report a passing doctor or anonymous boundary smoke as working end-to-end authentication.
 
 ## Auth-derived customer API endpoints
@@ -192,6 +194,8 @@ export default server(
 
 `customerEndpoint` accepts exactly one non-empty policy arm: exact HTTPS origins, or HTTPS hostname suffixes. Exact policies may authorize an explicit non-default port; suffix policies allow port 443 and match only the exact host or dot-boundary subdomains. Do not add connector `allowedOrigins` to a customer-routed connector. Its fixed credential/token endpoints are validated independently and cannot come from caller claims.
 
+Customer-routed connector auth must be omitted or use `delegatedTokenExchange` at both connector and operation level. The compiler validates the concrete connector definition emitted from TypeScript, including connector defaults and operation overrides. Do not emit bearer, API-key, client-credentials, or managed-provider fallbacks for local mode; use operation fakes while leaving auth declarative. `customer_endpoint_unsupported_auth` reports the exact failing path and auth kind.
+
 On a bidirectional MCP transport whose client negotiated form elicitation, Noodle sends the standard confirmation form. The current stateless hosted MCP transport cannot initiate that exchange, so the example explicitly declares `server.interactions.confirmationFallback: 'host'`. That fallback trusts the MCP host to have collected native write approval before the tool call reaches Noodle; it is never inferred from client identity and does not replace authentication, authorization, policy, or accurate action/destructive annotations. Omit it when connected hosts are not trusted to provide that approval; confirmation then fails closed with `interaction_unavailable` when the standard exchange is unavailable.
 
 Every federated issuer must repeat every endpoint key used by the app, although each issuer may choose a different claim path. Endpoint names use lowercase letters, numbers, and underscores. Resolved claims must be exact absolute HTTPS URLs of at most 2,048 UTF-8 bytes with no userinfo, query, fragment, IP literal, special-use host, or unsafe whitespace/control characters. The runtime preserves a canonical optional base path.
@@ -226,7 +230,7 @@ Role values are trusted only from the explicitly configured claim path (or the p
 
 Use delegated connector auth when the downstream API must enforce its own per-user authorization — a shared service credential plus a forwarded user id would bypass it. Three shapes exist; pick by who owns the downstream:
 
-- **`delegatedTokenExchange`** — your own API. The platform signs a short-lived, verifiable assertion of the signed-in user and exchanges it at a token endpoint you implement (RFC 8693). It works with verified customer OIDC identities and the built-in Firebase/Microsoft adapters; no per-user OAuth enrollment. Embedded-assistant sessions support this exchange for static connectors. Customer-routed connectors require a direct or federated MCP OIDC request and fail closed in embedded-assistant sessions because those sessions carry no IdP endpoint claim.
+- **`delegatedTokenExchange`** — your own API. The platform signs a short-lived, verifiable assertion of the signed-in user and exchanges it at a token endpoint you implement (RFC 8693). It works with verified customer OIDC identities and the built-in Firebase/Microsoft adapters; no per-user OAuth enrollment. Embedded-assistant sessions can bind customer-routed connectors when the authenticated embedding backend resolves each route from server-owned tenancy data and passes it during session exchange. Browser input, page context, session claims, and tool arguments cannot supply or override that private route authority.
 - **`delegatedOAuth` with `provider: "firebase" | "microsoft"`** — Noodle-managed bridge providers using stored per-user refresh tokens. Requires the matching `customerAuth` bridge; any other provider string is the compile error `unsupported_delegated_provider`.
 - **`delegatedSessionCookie`** — Firebase-managed session-cookie apps only; not a generic mechanism.
 
@@ -258,7 +262,7 @@ scope=time_off            (space-joined, when configured)
 audience=example-api      (when configured)
 ```
 
-The `subject_token` claims: `iss` (platform issuer; JWKS at `{iss}/.well-known/jwks.json`), `sub` (verified user id), `aud` (your configured audience or the tokenUrl), `email`, `name`, `claims` (declared session claims), `tenant` (`org/app/env`), `deployment`, `iat`, `exp` (about 120 s), `jti`. A routed exchange adds `route: { key, fingerprint }`, never the customer URL; credential cache and single-flight keys include that route binding. Respond with `{ "access_token": "...", "token_type": "Bearer", "expires_in": 900 }`; the broker caches per user + connector + scopes + route until `expires_in` minus 300 s and presents the token downstream as `Authorization: Bearer`.
+The `subject_token` claims: `iss` (platform issuer; JWKS at `{iss}/.well-known/jwks.json`), `sub` (verified user id), `aud` (your configured audience or the tokenUrl), `email`, `name`, `claims` (declared session claims), `tenant` (`org/app/env`), `deployment`, `customer_identity: { version: 1, issuer }`, `iat`, `exp` (about 120 s), `jti`. Key downstream users by `(customer_identity.issuer, sub)`, never by `sub` alone. Firebase uses `https://securetoken.google.com/<project-id>`; Microsoft uses `https://login.microsoftonline.com/<tenant-id>/v2.0`. A routed exchange adds `route: { key, fingerprint }`, never the customer URL; credential cache and single-flight keys include that route binding. Respond with `{ "access_token": "...", "token_type": "Bearer", "expires_in": 900 }`; the broker caches per user + connector + scopes + route until `expires_in` minus 300 s and presents the token downstream as `Authorization: Bearer`.
 
 ### The downstream token endpoint (your backend)
 
@@ -302,7 +306,7 @@ Local customer OIDC sign-in and delegated-exchange assertion trust are two disti
 
 **Never trust the Devtools issuer in production: anyone holding the local private key could impersonate a customer.**
 
-Diagnose statically with `noodle auth doctor`; set a short-lived real customer token only in `NOODLE_CUSTOMER_TOKEN` and add `--live --org <org> --app <app> --env <env>` to perform one exchange per delegated binding without invoking a business tool. Add `--version <version>` to test that exact pinned MCP resource. Common failures include structured `credential_unavailable` reasons such as `caller_identity_not_customer`. Direct/federated OIDC verification assigns the customer identity at the trusted verifier boundary; never ask an IdP to mint a Noodle-specific classification claim.
+Diagnose statically with `noodle auth doctor`; set a short-lived real customer token only in `NOODLE_CUSTOMER_TOKEN` and add `--live --org <org> --app <app> --env <env>` to perform one exchange per delegated binding without invoking a business tool. Add `--version <version>` to test that exact pinned MCP resource. Common failures include structured `credential_unavailable` reasons such as `caller_identity_not_customer`. For a Firebase/Microsoft bridge, `caller_issuer_missing` means the session predates issuer binding: reconnect once through customer authentication, then retry. No IdP custom claim or `server.ts` change is required. Direct/federated OIDC verification assigns the customer identity at the trusted verifier boundary; never ask an IdP to mint a Noodle-specific classification claim.
 
 ## Design tools for the model