@noodleseed/agent-kit 0.54.0 → 0.56.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.54.0",
+  "version": "0.56.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.54.0 hash:ec5bfcd0d8165205 -->
+<!-- noodle-skill version:0.56.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.54.0 hash:0b2fd8c7e43fc69f -->
+<!-- noodle-skill version:0.56.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.54.0 hash:f7fa54992c8d7692 -->
+<!-- noodle-skill version:0.56.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.54.0 hash:1e86b8704f407bd3 -->
+<!-- noodle-skill version:0.56.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.54.0 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.56.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.54.0 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.56.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.54.0 hash:76cce86729cffbee -->
+<!-- noodle-skill version:0.56.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.54.0 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.56.0 hash:cc54a67f21c0ecdb -->
 
 # embedding-mcp-assistants
 

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

@@ -1,102 +1,174 @@
-# Customer Auth - NoodleSeed.com Firebase customer identity
+# Customer Auth - OIDC identity and customer-routed APIs
 
-This curated example owns the customer/end-user authentication with Firebase bridge capability slot. It is
-the NoodleSeed.com dogfood app for proving that a SaaS app can protect an MCP endpoint with its own customer
-identity provider while still using the generic Noodle Seed authoring API.
+This curated example owns the customer/end-user authentication capability slot. It proves that a SaaS app
+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 embedded-assistant showcase: the same authenticated MCP surface can be dropped into the
-SaaS web application as a fully customer-branded assistant with independent light and dark themes. The
-assistant loads the active deployment's instructions and model-visible tools rather than installing a stale
-second skill bundle. The standard embedded element also hosts linked MCP Apps behind its sandbox bridge.
+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.
 
-The public developer entrypoint is [`src/server.ts`](src/server.ts). It declares `customerAuth.firebase(...)` with
-the NoodleSeed.com Firebase project and Firebase Web App public config. It exposes a deliberately small MCP
-surface for org discovery:
+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:
 
 - `list_my_organizations` lists the NoodleSeed.com organizations the signed-in customer belongs to (no
   arguments — the org set comes from the verified customer session).
-- `list_org_apps` lists apps for one of those organizations through the dev app API. It is visible and
+- `list_org_apps` lists apps for one of those organizations through that tenant's API. It is visible and
   callable only when the verified customer has the `org_apps:read` scope and either the `org_admin` or
   `org_member` role.
+- `archive_org_app` archives one app only after exact runtime confirmation. It requires the
+  `org_apps:write` scope and `org_admin` role.
 
-The two tools chain: `list_my_organizations` surfaces the `org_id`s the customer can act on, and
-`list_org_apps` takes one of those `org_id`s. There is no NoodleSeed-specific SDK helper. The downstream API
-is an ordinary authored HTTP connector.
+The tools chain: `list_my_organizations` surfaces the `org_id`s the customer can act on,
+`list_org_apps` takes one of those ids, and `archive_org_app` accepts the selected app id. Tool code remains
+independent of the selected origin.
 
-## Direct or federated OIDC instead of the built-in adapter
+## Declare the customer endpoint
 
-This flagship uses the managed Firebase adapter. If an app replaces it with `customerAuth.oidc(...)` or
-`customerAuth.federatedOidc(...)`, the app developer owns the authorization server. It must publish the
-primary path-inserted RFC 8414 URL as direct HTTP 200 JSON with the exact issuer, HTTPS authorization/token/
-registration/JWKS endpoints, authorization-code and refresh grants, PKCE S256, public-client auth method
-`none`, RFC 8707 resource handling, an access-token `aud` equal to the exact MCP URL, and public signing keys.
+`customerEndpoint` names one private routing authority and bounds the origins an IdP may select:
 
-Run `noodle auth doctor src/server.ts` before sharing the endpoint. Its issuer-readiness probes perform
-bounded read-only GET checks and never register a client. A successful
-`noodle deploy --access customers` reports the same findings as nonblocking warnings; the application team
-repairs the issuer rather than adding a Noodle OAuth proxy.
-
-Adding the embedded assistant does not choose or rewrite MCP customer auth. Inspect the exact active
-deployment before changing configuration:
-
-```sh
-noodle deployments list --org <org> --app <app> --env <env> --json
+```ts
+const customerApi = customerEndpoint('customer_api', {
+  allowedHttpsHostSuffixes: ['api.noodleseed.dev'],
+});
 ```
 
-This Firebase bridge intentionally advertises the Noodle authorization server. A direct or federated
-replacement must advertise its configured tenant issuer. If the exact active direct/federated `customers`
-deployment instead advertises the platform issuer, report `customer_auth_state_inconsistent` with only the
-endpoint, deployment ID, server version, and sanitized protected-resource metadata. Do not share tokens or
-secrets, proxy or rewrite metadata, rotate credentials, or redeploy repeatedly to conceal the mismatch.
+Use either non-empty `allowedHttpsHostSuffixes` or non-empty `allowedHttpsOrigins`, never both. Exact-origin
+policies may include a non-default port. Suffix policies match only the exact hostname or dot-boundary
+subdomains on port 443. A routed connector must not add `allowedOrigins`; its endpoint policy is the egress
+allowlist.
 
-During MCP OAuth login, Noodle Cloud hosts the Firebase bridge page at
-`https://cloud.noodleseed.dev/oauth/customer/firebase/authorize`. The customer app does not add an
-authorization route. The SaaS operator only configures Firebase Auth to allow the Noodle Cloud origin, and
-Noodle Cloud signs the customer in with Firebase before posting the Firebase ID token back to its own bridge
-callback.
+The connector uses that declaration as its normal base URL. Its token endpoint remains a fixed, independently
+validated HTTPS URL:
 
-## How delegated customer credentials are used
+```ts
+const api = connector('noodleseed_app_api')
+  .version('1.0.0')
+  .http({
+    baseUrl: customerApi,
+    auth: {
+      kind: 'delegatedTokenExchange',
+      tokenUrl: 'https://id.noodleseed.dev/oauth/token',
+      clientId: variable('CUSTOMER_API_CLIENT_ID'),
+      clientSecret: secret('CUSTOMER_API_CLIENT_SECRET'),
+      scopes: ['organizations:read', 'org_apps:read', 'org_apps:write'],
+      audience: 'noodleseed-customer-api',
+    },
+    operations: {
+      // read and action operations...
+    },
+  });
+```
 
-This flagship uses the legacy Firebase provider bridge because it is runnable today. That is distinct from
-Core-v2 account-selecting connector aliases: those declare catalog `credentialProfiles` and bind each alias
-with `bind(connector, { profile, connection })`. Hosted bound `managedSecret(...)` connections are runnable;
-bound `externalExchange()` and `clientCredentials(...)` currently compile as portable metadata but fail
-closed before secret or network access until their provider slice lands. Do not replace this example's
-working delegated-session-cookie path with either unsupported bound exchange source.
+## Map the endpoint from verified OIDC
 
-The example has two declarations that work together:
+The IdP claim contains the complete base URL, including an optional base path. Routing is separate from the
+public `${user}` expression scope:
 
 ```ts
-auth: customerAuth.firebase({
-  projectId: variable('FIREBASE_PROJECT_ID'),
-  apiKey: variable('FIREBASE_WEB_API_KEY'),
-  authDomain: variable('FIREBASE_AUTH_DOMAIN'),
-  user: {
+auth: customerAuth.oidc({
+  issuer: 'https://id.noodleseed.dev',
+  audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+  claims: {
     id: 'sub',
     email: 'email',
     name: 'name',
-    tenant: 'firebase.tenant',
-        orgs: 'claims.orgs',
-        roles: 'claims.roles',
-        scopes: 'claims.scopes',
+    orgs: 'permissions.orgs',
+    roles: 'permissions.roles',
+    scopes: 'permissions.scopes',
+  },
+  routing: {
+    endpoints: {
+      customer_api: { claim: 'tenant.api_base_url' },
+    },
+  },
+}),
+```
+
+For federated OIDC, put the same endpoint map on every issuer. Claim paths may differ, but each issuer must
+map every endpoint the app uses:
+
+```ts
+auth: customerAuth.federatedOidc({
+  issuers: [
+    {
+      issuer: 'https://id.customer-a.com',
+      audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+      routing: {
+        endpoints: {
+          customer_api: { claim: 'tenant.api_base_url' },
+        },
       },
+    },
+    {
+      issuer: 'https://login.customer-b.com',
+      audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+      routing: {
+        endpoints: {
+          customer_api: { claim: 'organization.routes.customer_api' },
+        },
+      },
+    },
+  ],
 }),
 ```
 
-That protects the MCP endpoint with the SaaS customer's Firebase identity. The connector then opts into
-delegated customer credentials:
+At runtime, Noodle Seed validates both the configured audience and exact MCP resource, projects the route
+into private request state, applies its policy, and freezes it for the call. Missing, malformed, or
+disallowed claims return `connector_route_unavailable` before credential lookup or connector egress.
+Resolved URLs never enter artifacts, `${user}`, logs, model output, widgets, public confirmation review,
+broker cache keys, or delegated exchange assertions.
+
+Routed reads work in tools, including declared nested calls. Routed actions require exact
+`annotations.confirm: true`; otherwise they fail with `customer_endpoint_action_unsupported`. Routed
+resources, prompts, and ambient context fail with `customer_endpoint_surface_unsupported`.
+
+The flagship's routed action uses the normal TypeScript action helper:
 
 ```ts
-auth: {
-  kind: 'delegatedSessionCookie',
-  provider: 'firebase',
-  sessionUrl: `${noodleseedApiOrigin}/api/auth/session`,
-  tokenField: 'idToken',
+tool('archive_org_app', {
+  authorization: {
+    requiredScopes: ['org_apps:write'],
+    allowedRoles: ['org_admin'],
+  },
+  annotations: annotations.openAction({ destructive: false, confirm: true }),
+  // input, output, and the normal connectors.app_api.archiveOrgApp(...) call...
+});
+```
+
+The flagship also opts into the current stateless hosted MCP path:
+
+```ts
+interactions: {
+  confirmationFallback: 'host',
 },
 ```
 
-The mapped `roles` and `scopes` paths are read only after Firebase verifies the ID token. The restricted
-tool declares its rule beside the rest of its public contract:
+A bidirectional client that negotiated form elicitation can complete the standard confirmation exchange
+instead. The explicit host fallback trusts the MCP host to have collected native write approval before the
+tool call reaches Noodle Seed; it is never inferred from client identity and does not replace auth, policy,
+or accurate action/destructive annotations. Omit the fallback when connected hosts are not trusted to
+provide that approval. If neither standard confirmation nor the fallback is available, the action fails
+closed with `interaction_unavailable`.
+
+Preparation stores only sorted route `{ key, fingerprint }` bindings in its private server-held
+continuation; the public review exposes none of them. Acceptance re-resolves the current request route and
+returns `invalid_continuation` if it is missing or changed, before policy, credentials, or egress. A match
+reuses the current frozen snapshot for the action and all nested or later reads.
+
+The application developer owns the direct/federated authorization server. It must publish its path-inserted
+RFC 8414 document as direct HTTP 200 JSON with exact issuer and HTTPS authorization/token/registration/JWKS
+endpoints, authorization-code and refresh grants, PKCE S256, public-client auth method `none`, RFC 8707
+resource handling, and public signing keys. Access tokens must include the exact MCP resource audience; there
+is no audience fallback.
+
+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.
+
+## Per-tool authorization remains independent
+
+The mapped `roles` and `scopes` paths are read only after OIDC verification. The restricted tool declares its
+rule beside the rest of its public contract:
 
 ```ts
 tool('list_org_apps', {
@@ -109,9 +181,9 @@ tool('list_org_apps', {
 ```
 
 Every required scope must be present and at least one allowed role must match. When both lists are declared,
-both conditions apply. A restricted tool is omitted from `tools/list` for an ineligible customer and a
-direct `tools/call` still fails closed. Do not use unverified page context, request arguments, connector
-responses, or an arbitrary generic `roles` claim as authorization input.
+both conditions apply. Route availability never changes `tools/list`: discovery remains based only on
+roles/scopes. A restricted tool is omitted for an ineligible customer and a guessed direct call still fails
+closed.
 
 Tool code calls the connector normally:
 
@@ -127,39 +199,13 @@ fulfil({ input, connectors }) {
 }
 ```
 
-At runtime, Noodle Seed verifies the Firebase customer during MCP OAuth, stores that customer's delegated
-Firebase refresh token in the credential broker, and refreshes a short-lived Firebase ID token only when a
-connector-backed tool calls the NoodleSeed.com API. For this app API, the broker exchanges that ID token at
-the existing Next.js `/api/auth/session` route and sends the resulting session cookie to the API. The MCP
-access token remains a Noodle-issued resource-bound token and is never sent to the downstream API.
-
-## Delegated downstream auth for your own API (token exchange)
-
-The Firebase path above only works for Firebase-session downstreams. When the downstream is **your own
-API** with its own token issuance, use `delegatedTokenExchange` instead
-([ADR 0152](../../docs/decisions/0152-delegated-token-exchange-connector-auth.md)): the platform signs a
-short-lived, JWKS-verifiable assertion of the signed-in user and exchanges it (RFC 8693) at a token
-endpoint you implement, which mints your own user-scoped token — so your API enforces its own per-user
-authorization on every call. It works for verified direct/federated OIDC, built-in provider identities, and
-embedded assistant sessions, with no per-user OAuth enrollment.
-
-```ts
-auth: {
-  kind: 'delegatedTokenExchange',
-  tokenUrl: 'https://app.example.com/api/assistant/oauth/token', // origin must be in allowedOrigins
-  clientId: variable('EXAMPLE_DELEG_CLIENT_ID'),
-  clientSecret: secret('EXAMPLE_DELEG_CLIENT_SECRET'),
-  scopes: ['time_off'],
-},
-```
+The broker exchanges a short-lived, platform-signed assertion at the fixed token endpoint and caches the
+result by caller, connector, scopes, and a route fingerprint. The assertion carries only the route key and
+fingerprint, never the URL. The MCP access token is never forwarded to the customer API. The exchange wire
+contract lives in [docs/spec/connectors.md](../../docs/spec/connectors.md).
 
-Your endpoint authenticates the broker's client credential, verifies the `subject_token` JWT against the
-platform issuer JWKS (claims include the verified `sub`, `email`, `name`, declared session `claims`,
-`tenant`, and `deployment`), mints a short-lived user-scoped token, and returns the standard
-`{ access_token, token_type, expires_in }` response. The exact wire contract and a copyable endpoint
-implementation live in [docs/spec/connectors.md](../../docs/spec/connectors.md) and the Agent Kit
-authoring-workflow reference ("Delegated downstream auth"). `noodle auth doctor` reports each declared
-exchange endpoint.
+Firebase and Microsoft remain supported managed adapters; their provider-specific contracts and tests live
+in [docs/spec/auth-and-policy.md](../../docs/spec/auth-and-policy.md) and the SharePoint flagship.
 
 ## Validate
 
@@ -170,7 +216,7 @@ noodle validate examples/customer-auth/src/server.ts
 
 Against a deployed customer-protected environment, set a short-lived real customer token only in
 `NOODLE_CUSTOMER_TOKEN` and add `--live --org <org> --app <app> --env <env>`. The live doctor performs
-credential exchanges without invoking either business tool.
+credential exchanges without invoking any business tool.
 
 ## Run locally
 
@@ -184,13 +230,16 @@ 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.
+
 ```bash
 noodle variables set ASSISTANT_MODEL_BASE_URL https://model.example.com/v1 --scope env
 noodle variables set ASSISTANT_MODEL your-model --scope env
 noodle secrets set ASSISTANT_MODEL_API_KEY --scope env
-noodle variables set FIREBASE_PROJECT_ID your-firebase-project --scope env
-noodle variables set FIREBASE_WEB_API_KEY your-firebase-web-api-key --scope env
-noodle variables set FIREBASE_AUTH_DOMAIN your-firebase-project.firebaseapp.com --scope env
+noodle variables set CUSTOMER_API_CLIENT_ID your-broker-client-id --scope env
+noodle secrets set CUSTOMER_API_CLIENT_SECRET --scope env
 noodle check --target embedded-assistant src/server.ts
 ```
 
@@ -198,11 +247,9 @@ Assistant origins are exact. Production embedding origins must use HTTPS; plain
 loopback development origins such as `http://localhost:3000`, `http://127.0.0.1:3000`, or
 `http://[::1]:3000`. `noodle dev` serves the MCP project, not that separate embedding application.
 
-The assistant's panel, launcher, status header, composer, and message treatment are configured through the
-bounded `presentation` object in `src/server.ts`. The Atlas-style product treatment is the supported
-customization ceiling. These primitives derive their colors from the shared server `branding` block and
-require no edits to `@noodleseed/assistant`; raw HTML, CSS, inline SVG, renderer class names, and callbacks
-are intentionally not accepted in deployment configuration.
+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.
 
 Create the backend credential after deployment. The CLI writes it to a mode-0600 file and never prints the
 secret:
@@ -382,13 +429,15 @@ secret allowlist; regenerate existing framework-owned environment binding types
 Devtools/model exercises to synthetic data, and obtain approval before sending real connector data to an
 external model.
 
-After deployment, verify the public delegated exchange without extracting a customer bearer token or invoking
-a business operation:
+After deployment, use the assistant doctor to verify the embed client, model, and static session boundary:
 
 ```sh
 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.
+
 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.
 Schedule the send after the provisional cleanup and settle its promise:
@@ -437,43 +486,21 @@ assistant.subscribeChat((state) => {
 });
 ```
 
-`theme="auto"` follows the browser operating-system preference, not a SaaS-owned theme toggle. Pass the
-application's resolved `light`/`dark` theme to both `NoodleAssistant` and `NoodleAppView`; later updates
-reach mounted MCP Apps without remounting them. CSS custom properties inherit through the assistant host, so
-typed appearance roles may reuse existing application tokens with `var(--app-token)`. The server-level
-`branding` block is inherited by both MCP App widgets and the assistant; documented `--ns-assistant-*`
-semantic CSS variables remain the final integration escape hatch. There is no second assistant branding
-declaration.
-The end-user UI contains only customer branding.
-Text streams progressively. Expired turns re-exchange through the authenticated backend and retry once;
-consent-bound tool confirmations never replay automatically.
-
-The Firebase project ID is required because Firebase ID tokens use the project ID as the token audience and
-issuer suffix. The runtime verifies `aud` against the project ID and `iss` against
-`https://securetoken.google.com/<projectId>`.
-
-The Firebase Web API key and auth domain are public Firebase browser configuration. They let the Noodle
-Cloud-hosted bridge initialize Firebase Auth for this customer project; they are not server secrets. Keep
-them out of source with `variable(...)`, restrict the Firebase key to the expected browser origins and APIs,
-and use `secret(...)` only for credentials that must never reach a browser.
-
-The `noodleseed_app_api` connector currently points at the NoodleSeed.com dev app surface:
-
-```text
-https://dev.noodleseed.com
-```
-
-When the customer app moves from `dev.noodleseed.com` to `app.noodleseed.com`, update the connector's
-`noodleseedApiOrigin` constant to the production API origin that serves the same paths.
+`theme="auto"` follows the operating-system preference, not a SaaS-owned toggle. Pass the resolved
+`light`/`dark` theme to `NoodleAssistant` and `NoodleAppView`; updates reach mounted MCP Apps without a
+remount. CSS custom properties inherit through the host, and documented `--ns-assistant-*` variables remain
+the final integration escape hatch. Server `branding` is shared by widgets and the assistant; there is no
+second branding declaration. Text streams progressively. Expired turns re-exchange and retry once;
+confirmations never replay automatically.
 
-The connector uses delegated Firebase customer credentials. During the customer OAuth bridge, Noodle Seed
-verifies the Firebase ID token, stores the Firebase refresh token through the credential broker, and refreshes
-a Firebase ID token when the connector calls the NoodleSeed.com app API. The broker then exchanges that ID
-token for the app's existing Next.js session cookie. There is no shared `NOODLESEED_APP_API_TOKEN` for this
-example.
+The customer IdP must place the full tenant API base URL in `tenant.api_base_url`. For example, one verified
+customer may receive `https://customer-a.api.noodleseed.dev/v1` and another
+`https://customer-b.api.noodleseed.dev/v1`; both satisfy the declared suffix policy. Application code,
+deployment variables, and connector arguments do not select the tenant route.
 
-Firebase Auth must list `cloud.noodleseed.dev` as an authorized domain before browser sign-in works in
-production.
+`CUSTOMER_API_CLIENT_ID` and `CUSTOMER_API_CLIENT_SECRET` authenticate only the broker to the fixed exchange
+endpoint. They are not customer API bearer tokens. The exchange endpoint verifies the platform-signed
+subject assertion and mints a short-lived token scoped to the signed-in user and route binding.
 
 ## Deploy customer-protected to Noodle Seed Cloud
 
@@ -496,14 +523,16 @@ https://cloud.noodleseed.dev/o/noodleseed/customer-auth/mcp
 - Tool `list_my_organizations`: calls `GET /api/organizations` and returns the organizations the signed-in
   customer is a member of. Takes no arguments; the org set is scoped by the verified customer session.
 - Tool `list_org_apps`: calls `GET /api/organizations/{org_id}/apps` for one organization `org_id`.
+- Tool `archive_org_app`: after confirmation, calls
+  `POST /api/organizations/{org_id}/apps/{app_id}/archive`.
 
 ## Auth boundary
 
-Firebase ID-token verification is handled by Noodle Seed's generic Firebase bridge adapter during OAuth
-issuance. The MCP client receives a Noodle-issued, resource-bound access token marked as a Firebase customer
-identity; raw Firebase tokens and inbound MCP bearer tokens are never forwarded to tools, connectors,
-widgets, or downstream systems.
+Noodle Seed verifies the configured OIDC issuer, audience, and exact MCP resource before reading identity or
+routing claims. Public caller identity contains the user/role/scope projection; the customer route remains
+private request state.
 
-The connector-backed tools use the credential broker to turn the signed-in Firebase customer session into the
-same session-cookie credential that the existing NoodleSeed.com Next.js API already expects. The inbound MCP
-bearer token is never used as an app API credential.
+Connector-backed tools ask the broker for a route-bound delegated credential; only the endpoint key and
+fingerprint enter broker cache/single-flight state or the assertion. The route claim and inbound MCP bearer
+token never reach tools, connectors, widgets, model output, or downstream systems. Confirmed actions keep
+the same URL-blind binding only in private continuation state and reject acceptance-time drift.