@noodleseed/agent-kit 0.43.0 → 0.44.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.43.0",
+  "version": "0.44.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.43.0 hash:cd6ca0d915e6acb9 -->
+<!-- noodle-skill version:0.44.0 hash:cd6ca0d915e6acb9 -->
 
 # 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.43.0 hash:0b2fd8c7e43fc69f -->
+<!-- noodle-skill version:0.44.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.43.0 hash:f7fa54992c8d7692 -->
+<!-- noodle-skill version:0.44.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.43.0 hash:1e86b8704f407bd3 -->
+<!-- noodle-skill version:0.44.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.43.0 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.44.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.43.0 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.44.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.43.0 hash:76cce86729cffbee -->
+<!-- noodle-skill version:0.44.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.43.0 hash:5d8f40f904d6ab4b -->
+<!-- noodle-skill version:0.44.0 hash:5d8f40f904d6ab4b -->
 
 # embedding-mcp-assistants
 

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

@@ -21,6 +21,19 @@ The two tools chain: `list_my_organizations` surfaces the `org_id`s the customer
 `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.
 
+## Direct or federated OIDC instead of the built-in adapter
+
+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.
+
+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.
+
 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

package/skills/claude-code/examples/hello/README.md

@@ -9,6 +9,8 @@ When an installed Noodle Developer plugin drives this example, its skill runs th
 `noodle` commands through the plugin-managed, version-pinned launcher and isolated host profile.
 Do not install or update a global CLI: the coding agent writes and tests this source while Noodle
 guides and operates the validate, preview, deploy, inspect, and debug workflow.
+For an approved implementation plan, the installed `executing-noodle-plans` skill owns the
+test-first task, review, recovery, and final-verification loop.
 If that agent discovers a Noodle Seed product gap while working, the installed skill prepares a
 sanitized `noodle feedback` proposal, discovers current fields from `noodle commands --json`, runs
 `--dry-run --json` to inspect the exact normalized submission, diagnostics, and private destination,

package/skills/claude-code/executing-noodle-plans/SKILL.md

@@ -0,0 +1,51 @@
+---
+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.44.0 hash:6a9f132ddb79352e -->
+
+# Execute a Noodle Seed implementation plan
+
+Execute an approved plan without reopening settled design decisions. Keep implementation, review, and evidence scoped to the current repository and the authority the user granted.
+
+## Preconditions
+
+- Read the plan, repository instructions, current branch status, and the files named by the first incomplete task.
+- Confirm the plan is decision-complete, test-first, compatible with the current code, and explicit about public contracts and required verification.
+- Work in the repository-required isolated branch or worktree and preserve unrelated changes.
+- If current code invalidates the plan or two requirements conflict, stop before editing and ask which requirement governs.
+
+## Task loop
+
+Execute one task at a time in plan order:
+
+1. Restate the task boundary, expected behavior, focused failing test, and files in scope.
+2. Add or update the focused test first and run it to confirm the expected failure when practical.
+3. Implement only the behavior required to make that test pass. Do not add compatibility paths, abstractions, or adjacent cleanup the plan did not require.
+4. Run the focused test, then the package-level checks named by the plan.
+5. Review the task diff for plan compliance, correctness, security, type safety, and unnecessary surface area.
+6. Record completion in the plan checkbox when it is writable and in a focused conventional commit.
+
+When the active host provides isolated task workers and user authorization permits delegation, use a fresh implementer for an independent task and a separate reviewer after it. Give each worker only the task requirements, binding global constraints, file paths, and required evidence. Never run workers in parallel when their files or contracts overlap. Execute inline when workers are unavailable, tasks are tightly coupled, or delegation is not authorized.
+
+## Review and recovery
+
+- Independent review must compare the task requirements with the exact task diff and test evidence; implementer self-review does not replace it when a reviewer is available.
+- Return concrete findings to the implementer, rerun the tests that cover each correction, and review the correction diff again.
+- Allow at most three correction rounds for the same finding. Then stop with the unresolved requirement, attempted fixes, and current evidence instead of silently accepting drift.
+- On context loss or interruption, resume from the plan checkboxes, git status, and git log; verify the last completed task before starting the first incomplete one.
+
+## Completion
+
+- Review the complete branch diff against the plan and all accepted design constraints.
+- Run the focused tests, affected package checks, generated-surface checks, and the repository readiness gate.
+- For Noodle application behavior, also run the validation, test, check, preview, or hosted evidence level selected by the owning Noodle Seed build or verification skill.
+- Report commits, evidence, residual risk, and the first unproven layer. Do not claim deployment, publication, merge, or production behavior that was not performed.
+- Hand delivery to the repository workflow; executing a plan does not itself authorize merge, deploy, publication, or other external mutation.
+
+## Stop conditions
+
+- Stop before implementation when the plan is incomplete or stale in a way that changes behavior, architecture, security, or public contracts.
+- Stop after three unsuccessful correction rounds on the same load-bearing finding.
+- Stop before any external mutation or destructive action outside the user-authorized task boundary.

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.43.0 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.44.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

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

@@ -7,6 +7,7 @@
 - Repair loop
 - Connectors
 - HTTP connector example (full server)
+- Customer OAuth for remote MCP clients
 - Delegated downstream auth (call your API as the signed-in user)
 - Invocation context
 - Compute connector example
@@ -101,6 +102,12 @@ Naming: connector operation names and tool names are lowercase-with-underscores.
 
 More: `auth.kind` is `bearer` | `apiKey` (needs `header`) | `clientCredentials` | `delegatedOAuth` | `delegatedSessionCookie` | `delegatedTokenExchange`. For client credentials use `{ kind: "clientCredentials", tokenUrl, clientId, clientSecret, scopes? }` (RFC-6749 grant); for a non-standard partner token endpoint add `profile: "custom"` with a `custom: { requestFormat, clientIdField, clientSecretField, tokenResponsePath, expirySource }` descriptor. Do not put credential headers in operation `headers`; use connector `auth`. Use `.compute(name, { input, output, run })` for a sandboxed transform; `provides:` (instead of `use:`) exposes a connector only to compute `callOperation`; and `noodle import openapi <file>` generates a connector from an OpenAPI spec.
 
+## Customer OAuth for remote MCP clients
+
+For `customerAuth.oidc(...)` and `.federatedOidc(...)`, the application developer owns the standards-compliant authorization server. Noodle verifies its access tokens; it does not proxy discovery, create OAuth clients, or repair the upstream server. For issuer `https://id.example.com/oauth`, publish the path-inserted RFC 8414 document at `https://id.example.com/.well-known/oauth-authorization-server/oauth` as direct unauthenticated HTTP 200 JSON — never a login redirect.
+
+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"]`. Implement RFC 8707 `resource`, mint access-token `aud` for the exact MCP resource URL, and 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.
+
 ## Delegated downstream auth (call your API as the signed-in user)
 
 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:

package/skills/claude-code/references/sdk-surface.md

@@ -41,7 +41,7 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 
 ### Customer auth
 
-- `customerAuth.oidc(...)`, `.firebase(...)`, `.microsoft(...)`, or `.bridge(...)` — end-user/customer identity for `--access customers` deployments. Firebase Web App fields are browser-visible configuration: use `variable(...)`, not `secret(...)`, and restrict the key in Firebase.
+- `customerAuth.oidc(...)`, `.federatedOidc(...)`, `.firebase(...)`, or `.microsoft(...)` — end-user/customer identity for `--access customers` deployments. A direct/federated issuer must publish direct RFC 8414 discovery, Dynamic Client Registration, authorization-code + refresh grants, PKCE `code_challenge_methods_supported: ["S256"]`, public-client `token_endpoint_auth_methods_supported: ["none"]`, and a public JWKS; verify it with `noodle auth doctor src/server.ts`. Firebase Web App fields are browser-visible configuration: use `variable(...)`, not `secret(...)`, and restrict the key in Firebase.
 
 ### Sessions
 

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.43.0 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.44.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.43.0 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.44.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.43.0 hash:cd6ca0d915e6acb9 -->
+<!-- noodle-skill version:0.44.0 hash:cd6ca0d915e6acb9 -->
 
 # 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.43.0 hash:0b2fd8c7e43fc69f -->
+<!-- noodle-skill version:0.44.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.43.0 hash:f7fa54992c8d7692 -->
+<!-- noodle-skill version:0.44.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.43.0 hash:1e86b8704f407bd3 -->
+<!-- noodle-skill version:0.44.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.43.0 hash:aa715bae12041d7c -->
+<!-- noodle-skill version:0.44.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.43.0 hash:93e735b7ffb45df1 -->
+<!-- noodle-skill version:0.44.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.43.0 hash:76cce86729cffbee -->
+<!-- noodle-skill version:0.44.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.43.0 hash:5d8f40f904d6ab4b -->
+<!-- noodle-skill version:0.44.0 hash:5d8f40f904d6ab4b -->
 
 # embedding-mcp-assistants
 

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

@@ -21,6 +21,19 @@ The two tools chain: `list_my_organizations` surfaces the `org_id`s the customer
 `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.
 
+## Direct or federated OIDC instead of the built-in adapter
+
+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.
+
+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.
+
 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

package/skills/codex/examples/hello/README.md

@@ -9,6 +9,8 @@ When an installed Noodle Developer plugin drives this example, its skill runs th
 `noodle` commands through the plugin-managed, version-pinned launcher and isolated host profile.
 Do not install or update a global CLI: the coding agent writes and tests this source while Noodle
 guides and operates the validate, preview, deploy, inspect, and debug workflow.
+For an approved implementation plan, the installed `executing-noodle-plans` skill owns the
+test-first task, review, recovery, and final-verification loop.
 If that agent discovers a Noodle Seed product gap while working, the installed skill prepares a
 sanitized `noodle feedback` proposal, discovers current fields from `noodle commands --json`, runs
 `--dry-run --json` to inspect the exact normalized submission, diagnostics, and private destination,

package/skills/codex/executing-noodle-plans/SKILL.md

@@ -0,0 +1,51 @@
+---
+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.44.0 hash:6a9f132ddb79352e -->
+
+# Execute a Noodle Seed implementation plan
+
+Execute an approved plan without reopening settled design decisions. Keep implementation, review, and evidence scoped to the current repository and the authority the user granted.
+
+## Preconditions
+
+- Read the plan, repository instructions, current branch status, and the files named by the first incomplete task.
+- Confirm the plan is decision-complete, test-first, compatible with the current code, and explicit about public contracts and required verification.
+- Work in the repository-required isolated branch or worktree and preserve unrelated changes.
+- If current code invalidates the plan or two requirements conflict, stop before editing and ask which requirement governs.
+
+## Task loop
+
+Execute one task at a time in plan order:
+
+1. Restate the task boundary, expected behavior, focused failing test, and files in scope.
+2. Add or update the focused test first and run it to confirm the expected failure when practical.
+3. Implement only the behavior required to make that test pass. Do not add compatibility paths, abstractions, or adjacent cleanup the plan did not require.
+4. Run the focused test, then the package-level checks named by the plan.
+5. Review the task diff for plan compliance, correctness, security, type safety, and unnecessary surface area.
+6. Record completion in the plan checkbox when it is writable and in a focused conventional commit.
+
+When the active host provides isolated task workers and user authorization permits delegation, use a fresh implementer for an independent task and a separate reviewer after it. Give each worker only the task requirements, binding global constraints, file paths, and required evidence. Never run workers in parallel when their files or contracts overlap. Execute inline when workers are unavailable, tasks are tightly coupled, or delegation is not authorized.
+
+## Review and recovery
+
+- Independent review must compare the task requirements with the exact task diff and test evidence; implementer self-review does not replace it when a reviewer is available.
+- Return concrete findings to the implementer, rerun the tests that cover each correction, and review the correction diff again.
+- Allow at most three correction rounds for the same finding. Then stop with the unresolved requirement, attempted fixes, and current evidence instead of silently accepting drift.
+- On context loss or interruption, resume from the plan checkboxes, git status, and git log; verify the last completed task before starting the first incomplete one.
+
+## Completion
+
+- Review the complete branch diff against the plan and all accepted design constraints.
+- Run the focused tests, affected package checks, generated-surface checks, and the repository readiness gate.
+- For Noodle application behavior, also run the validation, test, check, preview, or hosted evidence level selected by the owning Noodle Seed build or verification skill.
+- Report commits, evidence, residual risk, and the first unproven layer. Do not claim deployment, publication, merge, or production behavior that was not performed.
+- Hand delivery to the repository workflow; executing a plan does not itself authorize merge, deploy, publication, or other external mutation.
+
+## Stop conditions
+
+- Stop before implementation when the plan is incomplete or stale in a way that changes behavior, architecture, security, or public contracts.
+- Stop after three unsuccessful correction rounds on the same load-bearing finding.
+- Stop before any external mutation or destructive action outside the user-authorized task boundary.

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.43.0 hash:efffbf82007f935d -->
+<!-- noodle-skill version:0.44.0 hash:efffbf82007f935d -->
 
 # publishing-mcp-integrations
 

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

@@ -7,6 +7,7 @@
 - Repair loop
 - Connectors
 - HTTP connector example (full server)
+- Customer OAuth for remote MCP clients
 - Delegated downstream auth (call your API as the signed-in user)
 - Invocation context
 - Compute connector example
@@ -101,6 +102,12 @@ Naming: connector operation names and tool names are lowercase-with-underscores.
 
 More: `auth.kind` is `bearer` | `apiKey` (needs `header`) | `clientCredentials` | `delegatedOAuth` | `delegatedSessionCookie` | `delegatedTokenExchange`. For client credentials use `{ kind: "clientCredentials", tokenUrl, clientId, clientSecret, scopes? }` (RFC-6749 grant); for a non-standard partner token endpoint add `profile: "custom"` with a `custom: { requestFormat, clientIdField, clientSecretField, tokenResponsePath, expirySource }` descriptor. Do not put credential headers in operation `headers`; use connector `auth`. Use `.compute(name, { input, output, run })` for a sandboxed transform; `provides:` (instead of `use:`) exposes a connector only to compute `callOperation`; and `noodle import openapi <file>` generates a connector from an OpenAPI spec.
 
+## Customer OAuth for remote MCP clients
+
+For `customerAuth.oidc(...)` and `.federatedOidc(...)`, the application developer owns the standards-compliant authorization server. Noodle verifies its access tokens; it does not proxy discovery, create OAuth clients, or repair the upstream server. For issuer `https://id.example.com/oauth`, publish the path-inserted RFC 8414 document at `https://id.example.com/.well-known/oauth-authorization-server/oauth` as direct unauthenticated HTTP 200 JSON — never a login redirect.
+
+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"]`. Implement RFC 8707 `resource`, mint access-token `aud` for the exact MCP resource URL, and 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.
+
 ## Delegated downstream auth (call your API as the signed-in user)
 
 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:

package/skills/codex/references/sdk-surface.md

@@ -41,7 +41,7 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 
 ### Customer auth
 
-- `customerAuth.oidc(...)`, `.firebase(...)`, `.microsoft(...)`, or `.bridge(...)` — end-user/customer identity for `--access customers` deployments. Firebase Web App fields are browser-visible configuration: use `variable(...)`, not `secret(...)`, and restrict the key in Firebase.
+- `customerAuth.oidc(...)`, `.federatedOidc(...)`, `.firebase(...)`, or `.microsoft(...)` — end-user/customer identity for `--access customers` deployments. A direct/federated issuer must publish direct RFC 8414 discovery, Dynamic Client Registration, authorization-code + refresh grants, PKCE `code_challenge_methods_supported: ["S256"]`, public-client `token_endpoint_auth_methods_supported: ["none"]`, and a public JWKS; verify it with `noodle auth doctor src/server.ts`. Firebase Web App fields are browser-visible configuration: use `variable(...)`, not `secret(...)`, and restrict the key in Firebase.
 
 ### Sessions
 

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