@noodleseed/agent-kit 0.53.0 → 0.55.0

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

@@ -1,102 +1,138 @@
-# 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
+read-only connector calls 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:
 
 - `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.
 
 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.
+`list_org_apps` takes one of those `org_id`s. 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'],
+      audience: 'noodleseed-customer-api',
+    },
+    operations: {
+      // read 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' },
+    },
+  },
 }),
 ```
 
-That protects the MCP endpoint with the SaaS customer's Firebase identity. The connector then opts into
-delegated customer credentials:
+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: {
-  kind: 'delegatedSessionCookie',
-  provider: 'firebase',
-  sessionUrl: `${noodleseedApiOrigin}/api/auth/session`,
-  tokenField: 'idToken',
-},
+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' },
+        },
+      },
+    },
+  ],
+}),
 ```
 
-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:
+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, confirmation review, broker cache
+keys, or delegated exchange assertions.
+
+This release permits routed reads in tools, including declared nested calls. Routed actions fail with
+`customer_endpoint_action_unsupported`; routed resources, prompts, and ambient context fail with
+`customer_endpoint_surface_unsupported`.
+
+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 +145,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 +163,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.
+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).
 
-```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'],
-},
-```
-
-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
 
@@ -184,13 +194,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 +211,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 +393,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 +450,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
 
@@ -499,11 +490,10 @@ https://cloud.noodleseed.dev/o/noodleseed/customer-auth/mcp
 
 ## 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.

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

@@ -2,6 +2,7 @@ import {
   annotations,
   connector,
   customerAuth,
+  customerEndpoint,
   embeddedAssistant,
   openAICompatible,
   secret,
@@ -11,18 +12,21 @@ import {
   z,
 } from '@noodleseed/one';
 
-const noodleseedApiOrigin = 'https://dev.noodleseed.com';
+const customerApi = customerEndpoint('customer_api', {
+  allowedHttpsHostSuffixes: ['api.noodleseed.dev'],
+});
 
 const noodleseedApi = connector('noodleseed_app_api')
   .version('1.0.0')
   .http({
-    baseUrl: noodleseedApiOrigin,
-    allowedOrigins: [noodleseedApiOrigin],
+    baseUrl: customerApi,
     auth: {
-      kind: 'delegatedSessionCookie',
-      provider: 'firebase',
-      sessionUrl: `${noodleseedApiOrigin}/api/auth/session`,
-      tokenField: 'idToken',
+      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'],
+      audience: 'noodleseed-customer-api',
     },
     operations: {
       list_org_apps: {
@@ -69,22 +73,25 @@ export default server(
       },
     },
     use: { app_api: noodleseedApi },
-    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' },
+        },
       },
     }),
     instructions:
-      'Customer-authenticated demo. Firebase proves the customer identity, while read-only NoodleSeed.com API calls use broker-managed delegated Firebase customer credentials.',
+      'Direct/federated MCP OIDC demo. The customer IdP proves identity and privately selects the tenant API base URL for read-only MCP calls, while the broker supplies delegated credentials.',
     assistant: embeddedAssistant({
       model: openAICompatible({
         baseUrl: variable('ASSISTANT_MODEL_BASE_URL'),
@@ -111,13 +118,13 @@ export default server(
         },
         composer: { leadingIcon: 'brand-mark', shape: 'pill' },
       },
-      suggestedPrompts: ['Show my organizations', 'List the apps in my organization'],
+      suggestedPrompts: ['Explain how to connect this customer-authenticated MCP server'],
     }),
   },
   [
     tool('list_org_apps', {
       title: 'List organization apps',
-      description: 'List NoodleSeed.com apps for an organization from the dev app API.',
+      description: 'List NoodleSeed.com apps for an organization from its customer API.',
       authorization: {
         requiredScopes: ['org_apps:read'],
         allowedRoles: ['org_admin', 'org_member'],
@@ -147,7 +154,7 @@ export default server(
       description: 'List the NoodleSeed.com organizations the signed-in customer belongs to.',
       contextProvider: true,
       input: z.object({}),
-      // The dev app API returns every organization for the signed-in customer in one response, with no
+      // The customer API returns every organization for the signed-in customer in one response, with no
       // page parameter to pass through, so the bound is declared on the shape. A customer belongs to a
       // handful of organizations; `noodle check` reports an unbounded list as
       // `tool_design_output_bounds`.

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

@@ -23,17 +23,46 @@ describe('customer-auth example', () => {
       name: 'Noodle Seed Assistant',
       colorScheme: 'auto',
     });
-    expect(manifest.server.auth).toMatchObject({
-      kind: 'bridge',
-      provider: 'firebase',
-      projectId: '${env.FIREBASE_PROJECT_ID}',
-      apiKey: '${env.FIREBASE_WEB_API_KEY}',
-      authDomain: '${env.FIREBASE_AUTH_DOMAIN}',
-      user: {
-        roles: 'claims.roles',
-        scopes: 'claims.scopes',
+    expect(manifest.server.auth).toEqual({
+      kind: 'oidc',
+      issuer: 'https://id.noodleseed.dev',
+      audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+      claims: {
+        id: 'sub',
+        email: 'email',
+        name: 'name',
+        orgs: 'permissions.orgs',
+        roles: 'permissions.roles',
+        scopes: 'permissions.scopes',
+      },
+      routing: {
+        endpoints: {
+          customer_api: { claim: 'tenant.api_base_url' },
+        },
+      },
+    });
+    const catalog = app.toConnectorCatalog();
+    expect(catalog?.connectors).toHaveLength(1);
+    expect(catalog?.connectors[0]?.http).toMatchObject({
+      baseUrl: {
+        kind: 'customerEndpoint',
+        name: 'customer_api',
+        policy: { allowedHttpsHostSuffixes: ['api.noodleseed.dev'] },
+      },
+      auth: {
+        kind: 'delegatedTokenExchange',
+        tokenUrl: 'https://id.noodleseed.dev/oauth/token',
+        clientId: '${env.CUSTOMER_API_CLIENT_ID}',
+        clientSecret: 'CUSTOMER_API_CLIENT_SECRET',
       },
     });
+    expect(
+      Object.values(catalog?.connectors[0]?.http?.operations ?? {}).every(
+        (operation) => operation.type === 'read',
+      ),
+    ).toBe(true);
+    expect(catalog?.connectors[0]?.http).not.toHaveProperty('allowedOrigins');
+    expect(JSON.stringify({ manifest, catalog })).not.toContain('tenant-a.api.noodleseed.dev');
     expect(manifest.tools.find((tool) => tool.name === 'list_org_apps')?.authorization).toEqual({
       requiredScopes: ['org_apps:read'],
       allowedRoles: ['org_admin', 'org_member'],

package/skills/codex/examples/food-ordering/README.md

@@ -84,13 +84,14 @@ noodle connect inspector
 ## Deploy
 
 ```sh
-noodle link --org demo --app food-ordering
-noodle deploy --access owner-only
+noodle deploy --org demo --app food-ordering --env prod --access owner-only
 noodle open
 ```
 
-Use `--access org-members` for an org-wide internal demo. This example has no connector secrets and does not
-include tokens, caller-key mechanisms, or `.env.noodle` values.
+That one deploy command preflights the complete target, creates a missing app/environment, and verifies
+hosted readiness. If it is interrupted, rerun the same command to resume the unfinished operation without a
+duplicate deployment. Use `--access org-members` for an org-wide internal demo. This example has no
+connector secrets and does not include tokens, caller-key mechanisms, or `.env.noodle` values.
 
 ## Demo Assets
 

package/skills/codex/examples/google-bigquery/README.md

@@ -99,3 +99,9 @@ Compilation and tests need no Google credentials:
 noodle validate
 noodle test
 ```
+
+For a local run that needs the declared provider values, the exact project-root `.env` can contain
+`GOOGLE_WIF_PROVIDER` and `GOOGLE_SERVICE_ACCOUNT`; `noodle dev` uses matching declarations only as a
+read-only fallback, and scoped `.env.noodle` values override it. Never commit or ask an agent to read either
+file. Interactive deploy can offer a default-No import of matching missing names to the visible target;
+non-interactive and plugin deploys keep the value-free `noodle variables set ... --from-env` recovery path.

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.53.0 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.55.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.53.0 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.55.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations