@noodleseed/agent-kit 0.57.1 → 0.58.0

package/package.json

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

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

@@ -209,13 +209,84 @@ contract lives in [docs/spec/connectors.md](../../docs/spec/connectors.md).
 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.
 
+## Supabase direct-OIDC access-token hook
+
+Dynamic Client Registration lets any OAuth client register, so the presence of `client_id` is not approval.
+Keep an operator-controlled client-to-audience map and rewrite `aud` only for an exact mapped client. For a
+dynamically registered client, review its generated client ID, name, and exact redirect URIs in the consent
+flow before adding the mapping. Each new registration needs its own row; never approve by name or prefix.
+
+Replace `<approved-oauth-client-id>` with the reviewed client ID and `<stable-mcp-audience>` with the exact
+value configured in `customerAuth.oidc`:
+
+```sql
+create table if not exists public.mcp_oauth_client_audiences (
+  client_id text primary key check (btrim(client_id) <> ''),
+  audience text not null check (btrim(audience) <> '')
+);
+
+revoke all on table public.mcp_oauth_client_audiences from authenticated, anon, public;
+grant usage on schema public to supabase_auth_admin;
+grant select on table public.mcp_oauth_client_audiences to supabase_auth_admin;
+
+insert into public.mcp_oauth_client_audiences (client_id, audience)
+values ('<approved-oauth-client-id>', '<stable-mcp-audience>')
+on conflict (client_id) do update set audience = excluded.audience;
+
+create or replace function public.mcp_access_token_hook(event jsonb)
+returns jsonb
+language plpgsql
+stable
+as $$
+declare
+  claims jsonb := coalesce(event->'claims', '{}'::jsonb);
+  oauth_client_id text := nullif(btrim(claims->>'client_id'), '');
+  mapped_audience text;
+begin
+  if oauth_client_id is not null then
+    select mapping.audience
+      into mapped_audience
+      from public.mcp_oauth_client_audiences as mapping
+      where mapping.client_id = oauth_client_id;
+  end if;
+
+  if mapped_audience is not null then
+    claims := jsonb_set(
+      claims,
+      '{aud}',
+      to_jsonb(mapped_audience),
+      true
+    );
+  end if;
+
+  return jsonb_build_object('claims', claims);
+end;
+$$;
+
+grant execute on function public.mcp_access_token_hook(jsonb) to supabase_auth_admin;
+revoke execute on function public.mcp_access_token_hook(jsonb) from authenticated, anon, public;
+```
+
+| Token source | Mapping | Resulting `aud` |
+| --- | --- | --- |
+| Approved OAuth client | Exact client row | Mapped stable MCP audience |
+| Unrelated or unknown OAuth client | No row | Original Supabase audience |
+| Browser session | No `client_id` | Original Supabase audience |
+
+Select this function under Supabase Auth Hooks before completing the interactive verification below.
+
 ## Validate
 
 ```bash
-noodle auth doctor examples/customer-auth/src/server.ts
-noodle validate examples/customer-auth/src/server.ts
+noodle validate examples/customer-auth/src/server.ts --json
+noodle auth doctor examples/customer-auth/src/server.ts --json
+noodle test examples/customer-auth/src/server.ts --json
 ```
 
+The doctor proves metadata and JWKS readiness without registering a client. For this protected app,
+`noodle test` proves the anonymous 401 plus exact protected-resource metadata boundary and reports
+`interactiveRequired: true`; neither command proves token issuance or audience verification.
+
 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 any business tool. Add `--version 1` when testing a pinned version;
@@ -224,9 +295,13 @@ the reported customer resource must match that versioned MCP endpoint.
 ## Run locally
 
 ```bash
-noodle dev examples/customer-auth/src/server.ts --app noodleseed-customer-auth
+noodle devtools examples/customer-auth/src/server.ts
 ```
 
+Complete sign-in in Devtools and load the tool list. That authenticated request is the local proof that DCR,
+PKCE, token issuance, issuer/signature verification, the stable audience, and exact-resource binding work
+together. Invoke a representative safe read when the configured customer API is available.
+
 ## Configuration
 
 The embedded assistant uses a customer-supplied OpenAI Chat Completions-compatible endpoint. Configure its

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.57.1 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.58.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.57.1 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.58.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.
 
+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
 
 Use a customer endpoint when the verified IdP selects a different API base URL for each SaaS customer. The claim contains the complete base URL; tool input and `${user}` do not select it. Declare one named policy, use that reference as the connector `baseUrl`, and map its claim path in direct OIDC or on every federated issuer:

package/skills/claude-code/references/verify-and-recover.md

@@ -22,12 +22,13 @@ Use this ordered evidence ladder. Start at the last known passing layer or the l
 
 1. **Compile** — the TypeScript build and authoring import surface are valid.
 2. **Validate** — `noodle validate --json` accepts the Noodle contract.
-3. **Local smoke** — `noodle test --json` starts the local runtime and exercises registration.
-4. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
-5. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
-6. **Host** — the requested host connects, invokes the expected capability, and renders useful fallback/UI behavior.
-7. **Deploy** — the requested hosted revision and configuration exist and report healthy at the deployment layer.
-8. **Production health** — the live production endpoint and requested user journey are observed on the intended revision.
+3. **Local smoke** — `noodle test --json` starts the local runtime. Open apps exercise MCP registration; customer-auth apps must instead pass the anonymous 401 plus exact protected-resource metadata boundary and report `interactiveRequired: true`.
+4. **Customer auth** — when customer auth is declared, run `noodle auth doctor src/server.ts --json` for metadata and JWKS readiness, then run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or representative safe read. The doctor does not prove that registration or token issuance succeeds; the authenticated request proves issuer, signature, stable audience, and exact-resource binding together.
+5. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
+6. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
+7. **Host** — the requested host connects, invokes the expected capability, and renders useful fallback/UI behavior.
+8. **Deploy** — the requested hosted revision and configuration exist and report healthy at the deployment layer.
+9. **Production health** — the live production endpoint and requested user journey are observed on the intended revision.
 
 For the first failing layer:
 
@@ -44,6 +45,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 
 - Compile success does not prove runtime behavior.
 - Validation and local smoke do not prove a real API mapping or credential path.
+- A protected-boundary smoke or passing auth doctor does not prove DCR, token issuance, token audience, or authenticated MCP access.
 - Local evidence does not prove hosted or host behavior.
 - Deployment existence does not prove production health or a user journey.
 - Report every requested but unperformed or blocked higher layer as not run, with the reason.

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.57.1 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.58.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.57.1 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.58.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.57.1 hash:ec5bfcd0d8165205 -->
+<!-- noodle-skill version:0.58.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.57.1 hash:0b2fd8c7e43fc69f -->
+<!-- noodle-skill version:0.58.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.57.1 hash:f7fa54992c8d7692 -->
+<!-- noodle-skill version:0.58.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.57.1 hash:1e86b8704f407bd3 -->
+<!-- noodle-skill version:0.58.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.57.1 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.58.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.57.1 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.58.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.57.1 hash:76cce86729cffbee -->
+<!-- noodle-skill version:0.58.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.57.1 hash:cc54a67f21c0ecdb -->
+<!-- noodle-skill version:0.58.0 hash:cc54a67f21c0ecdb -->
 
 # embedding-mcp-assistants
 

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

@@ -209,13 +209,84 @@ contract lives in [docs/spec/connectors.md](../../docs/spec/connectors.md).
 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.
 
+## Supabase direct-OIDC access-token hook
+
+Dynamic Client Registration lets any OAuth client register, so the presence of `client_id` is not approval.
+Keep an operator-controlled client-to-audience map and rewrite `aud` only for an exact mapped client. For a
+dynamically registered client, review its generated client ID, name, and exact redirect URIs in the consent
+flow before adding the mapping. Each new registration needs its own row; never approve by name or prefix.
+
+Replace `<approved-oauth-client-id>` with the reviewed client ID and `<stable-mcp-audience>` with the exact
+value configured in `customerAuth.oidc`:
+
+```sql
+create table if not exists public.mcp_oauth_client_audiences (
+  client_id text primary key check (btrim(client_id) <> ''),
+  audience text not null check (btrim(audience) <> '')
+);
+
+revoke all on table public.mcp_oauth_client_audiences from authenticated, anon, public;
+grant usage on schema public to supabase_auth_admin;
+grant select on table public.mcp_oauth_client_audiences to supabase_auth_admin;
+
+insert into public.mcp_oauth_client_audiences (client_id, audience)
+values ('<approved-oauth-client-id>', '<stable-mcp-audience>')
+on conflict (client_id) do update set audience = excluded.audience;
+
+create or replace function public.mcp_access_token_hook(event jsonb)
+returns jsonb
+language plpgsql
+stable
+as $$
+declare
+  claims jsonb := coalesce(event->'claims', '{}'::jsonb);
+  oauth_client_id text := nullif(btrim(claims->>'client_id'), '');
+  mapped_audience text;
+begin
+  if oauth_client_id is not null then
+    select mapping.audience
+      into mapped_audience
+      from public.mcp_oauth_client_audiences as mapping
+      where mapping.client_id = oauth_client_id;
+  end if;
+
+  if mapped_audience is not null then
+    claims := jsonb_set(
+      claims,
+      '{aud}',
+      to_jsonb(mapped_audience),
+      true
+    );
+  end if;
+
+  return jsonb_build_object('claims', claims);
+end;
+$$;
+
+grant execute on function public.mcp_access_token_hook(jsonb) to supabase_auth_admin;
+revoke execute on function public.mcp_access_token_hook(jsonb) from authenticated, anon, public;
+```
+
+| Token source | Mapping | Resulting `aud` |
+| --- | --- | --- |
+| Approved OAuth client | Exact client row | Mapped stable MCP audience |
+| Unrelated or unknown OAuth client | No row | Original Supabase audience |
+| Browser session | No `client_id` | Original Supabase audience |
+
+Select this function under Supabase Auth Hooks before completing the interactive verification below.
+
 ## Validate
 
 ```bash
-noodle auth doctor examples/customer-auth/src/server.ts
-noodle validate examples/customer-auth/src/server.ts
+noodle validate examples/customer-auth/src/server.ts --json
+noodle auth doctor examples/customer-auth/src/server.ts --json
+noodle test examples/customer-auth/src/server.ts --json
 ```
 
+The doctor proves metadata and JWKS readiness without registering a client. For this protected app,
+`noodle test` proves the anonymous 401 plus exact protected-resource metadata boundary and reports
+`interactiveRequired: true`; neither command proves token issuance or audience verification.
+
 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 any business tool. Add `--version 1` when testing a pinned version;
@@ -224,9 +295,13 @@ the reported customer resource must match that versioned MCP endpoint.
 ## Run locally
 
 ```bash
-noodle dev examples/customer-auth/src/server.ts --app noodleseed-customer-auth
+noodle devtools examples/customer-auth/src/server.ts
 ```
 
+Complete sign-in in Devtools and load the tool list. That authenticated request is the local proof that DCR,
+PKCE, token issuance, issuer/signature verification, the stable audience, and exact-resource binding work
+together. Invoke a representative safe read when the configured customer API is available.
+
 ## Configuration
 
 The embedded assistant uses a customer-supplied OpenAI Chat Completions-compatible endpoint. Configure its

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.57.1 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.58.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.57.1 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.58.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.
 
+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
 
 Use a customer endpoint when the verified IdP selects a different API base URL for each SaaS customer. The claim contains the complete base URL; tool input and `${user}` do not select it. Declare one named policy, use that reference as the connector `baseUrl`, and map its claim path in direct OIDC or on every federated issuer:

package/skills/codex/references/verify-and-recover.md

@@ -22,12 +22,13 @@ Use this ordered evidence ladder. Start at the last known passing layer or the l
 
 1. **Compile** — the TypeScript build and authoring import surface are valid.
 2. **Validate** — `noodle validate --json` accepts the Noodle contract.
-3. **Local smoke** — `noodle test --json` starts the local runtime and exercises registration.
-4. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
-5. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
-6. **Host** — the requested host connects, invokes the expected capability, and renders useful fallback/UI behavior.
-7. **Deploy** — the requested hosted revision and configuration exist and report healthy at the deployment layer.
-8. **Production health** — the live production endpoint and requested user journey are observed on the intended revision.
+3. **Local smoke** — `noodle test --json` starts the local runtime. Open apps exercise MCP registration; customer-auth apps must instead pass the anonymous 401 plus exact protected-resource metadata boundary and report `interactiveRequired: true`.
+4. **Customer auth** — when customer auth is declared, run `noodle auth doctor src/server.ts --json` for metadata and JWKS readiness, then run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or representative safe read. The doctor does not prove that registration or token issuance succeeds; the authenticated request proves issuer, signature, stable audience, and exact-resource binding together.
+5. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
+6. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
+7. **Host** — the requested host connects, invokes the expected capability, and renders useful fallback/UI behavior.
+8. **Deploy** — the requested hosted revision and configuration exist and report healthy at the deployment layer.
+9. **Production health** — the live production endpoint and requested user journey are observed on the intended revision.
 
 For the first failing layer:
 
@@ -44,6 +45,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 
 - Compile success does not prove runtime behavior.
 - Validation and local smoke do not prove a real API mapping or credential path.
+- A protected-boundary smoke or passing auth doctor does not prove DCR, token issuance, token audience, or authenticated MCP access.
 - Local evidence does not prove hosted or host behavior.
 - Deployment existence does not prove production health or a user journey.
 - Report every requested but unperformed or blocked higher layer as not run, with the reason.

package/skills/codex/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.57.1 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.58.0 hash:0f404109f4845683 -->
 
 # reporting-noodle-feedback
 

package/skills/codex/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.57.1 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.58.0 hash:6ef6ef551e26b78e -->
 
 # verifying-mcp-delivery