@noodleseed/agent-kit 0.101.0 → 0.103.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.101.0",
+  "version": "0.103.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.101.0 hash:d3ceb1902ef4bb72 -->
+<!-- noodle-skill version:0.103.0 hash:d3ceb1902ef4bb72 -->
 
 # 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.101.0 hash:dd57a15df15d10b2 -->
+<!-- noodle-skill version:0.103.0 hash:dd57a15df15d10b2 -->
 
 # authoring-mcp-servers
 

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

@@ -47,6 +47,9 @@ Declare typed connectors:
 - **HTTP**: `connector("id").version("1.0.0").http({ baseUrl, allowedOrigins, auth, operations })`; map request/response with `${args...}` / `${response...}`. Use `${execution.id}` for provider idempotency, never model input. Optional `evidence: { outcome: "${response.execution_outcome}", reference: "${response.id}" }` classifies completed/rejected/accepted/unknown; reference is a bounded opaque ID, never a bearer URL or payload. No automatic action retry.
 - **MCP**: `connector("id").version("1.0.0").mcp({ endpoint, allowedOrigins, auth?, operations })` where each operation freezes the separate upstream `tool` wire name plus input/output schema. Import with `noodle import mcp`; do not hand-copy a live surface or call `tools/list` at runtime.
 - **Compute**: `connector("id").version("1.0.0").compute(name, { input, output, calls?, run })` — a self-contained, sandboxed function (no imports/closure capture) that may call allowlisted operations via `callOperation`.
+- **Explicit helpers**: `run: (input, host) => ...` can use `host.time.parse(iso)`, `host.time.format(epochMs)`, `host.time.parts(epochMs, timeZone)` and `host.digest(text, "hex")` (or `"base32hex"`). They convert bounded explicit data; there is no ambient clock. Pass trusted `context.temporal.instant` through fulfilment when current time is needed. `examples/weather` demonstrates a stable digest fallback for provider records without IDs.
+- **Expected HTTP errors**: declare `responses: { "409": { response: { status: "conflict" }, evidence: { outcome: "rejected" } } }` alongside the ordinary success `response`. Explicit 4xx overrides exclude 401/403/429; validate against the same output schema. Undeclared errors still fail. Overrides never inherit successful completion evidence or introduce action retries.
+- **Coordinated external actions**: a compute action may declare `coordination: { connectionId, namespace, key: "${args.resource}", reference: "${execution.id}" }` with a bounded execution deadline. It requires an installed application with a live bound connection and durable service coordination. Read `host.coordination.acquired` before writing; a blocked invocation may inspect `previous` through a declared read and call `host.resolveCoordination()` only after exact source proof, then require a fresh invocation/confirmation. The runtime permits at most one nested action when acquired and zero when blocked, even after recovery. Report explicit completed/rejected/unknown evidence with `host.reportOutcome(...)`; a successful return alone never unlocks uncertainty. Do not create an external-record collection for this.
 
 Tools record connector calls into a flow; recording is not execution. Do not branch on runtime outputs with native `if` — use declarative `when(...)` conditions.
 
@@ -219,7 +222,7 @@ Every federated issuer must repeat every endpoint key used by the app, although
 
 Resolved customer URLs are private routing authority: they never enter the manifest/artifact, `${user}`, logs, model output, widgets, public confirmation review, cache keys, or delegated-token-exchange assertions. Routed reads may be used by tools, including declared nested calls. A routed action—including one reached through a connector wrapper—requires exact `annotations.confirm: true`; omitted or `false` fails with `customer_endpoint_action_unsupported`. Routed resources, prompts, and ambient context fail with `customer_endpoint_surface_unsupported`.
 
-At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` remains based only on roles and scopes, so route availability neither reveals tenant topology nor changes the existing authorization filter.
+At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` follows the scope/role discovery rule and its explicit public-descriptor opt-in, so route availability neither reveals tenant topology nor changes execution authorization.
 
 ## Per-tool authorization
 
@@ -241,7 +244,10 @@ tool('list_org_apps', {
 })
 ```
 
-Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Eligible tools remain in authored order in `tools/list`; ineligible tools are omitted and a guessed direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
+Use `authorization.discovery: 'public'` on a nonempty scope/role rule to expose its MCP descriptor before sign-in. Omission and explicit 'authorized' preserve filtered discovery and compile identically. Visibility grants no execution or product-skill eligibility; scopes remain ALL and roles ANY. Noodle derives securitySchemes; never author them.
+For mixed customer preview, keep server customerAuth and adopt on the same org/app/env, endpoint, issuer and audience; keep the separate public Help endpoint during the pilot, and never create overlapping active issuer/audience ownership. Before any mixed deploy or access change, leave only Help unrestricted, add authorization to every customer tool, and validate plus preview with `noodle dev --access mixed`. For an existing customer-only app, first run `noodle deployments list --org <org> --app <app> --env <env> --json` and inspect an inactive `customers` record for the exact server version. If none exists, record the active ID, redeploy the unchanged secured source to the same version with `--access customers`, then list and inspect again to prove that ID is now inactive; recording it alone preserves nothing. Next deploy the policy-prepared source with `--access customers`, verify the original rollback record remains inactive, and only then run `noodle access set mixed ... --version <version>`. On pilot failure use `noodle rollback <deployment-id> --org <org> --app <app> --env <env> --reason <text>`. This app-history rollback differs from the compatible hosted service-release floor. Invalid supplied credentials fail, with no platform-human fallback. Broker exchange remains required. Local Devtools retries after successful sign-in and leaves Help available after cancellation without executing the protected tool. After deployment, test anonymous discovery, sign-in, cancellation, authenticated retry and expiry in the actual host before customer cutover; local/SDK checks do not prove ChatGPT or another host.
+
+Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Tools retain authored order in `tools/list`; protected descriptors are omitted unless explicitly public, and an unauthorized direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
 
 ## Delegated downstream auth (call your API as the signed-in user)
 
@@ -409,7 +415,7 @@ Adapt the representative arguments and assertions when business contracts change
 
 Author managed config as `secret("NAME")` / `variable("NAME")` and operate it with `noodle secrets set` / `noodle variables set` (scoped org/app/env). Never inline secret values in `server.ts`, tests, or generated files.
 
-For business-editable configuration, declare `const notice = variable("SERVICE_NOTICE", { schema: z.string().max(500), default: "Welcome", portal: { label: "Service notice", group: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [notice], ... }, tools)`. Use the same ref in ordinary fulfilment/connector arguments. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
+For business-editable configuration, declare `const guestExperience = variable("GUEST_EXPERIENCE", { schema: z.object({ notice: z.string().max(500) }), default: { notice: "Welcome" }, portal: { label: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [guestExperience], ... }, tools)`. Use the whole ref or `guestExperience.field("notice")` in ordinary fulfilment/connector arguments. `.field()` selects a schema-declared object property, can chain for nested objects, and retains the parent variable and full configuration snapshot; it never reads operator data at author time. Keep confirmed action arguments shallow enough for complete review; do not label ordinary settings sensitive to bypass the review. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
 
 Business schemas must be bounded: booleans, finite bounded numbers, bounded text, string enums, bounded arrays, and closed objects. Put defaults in the declaration, not inside Zod schema defaults; custom transforms/refinements and arbitrary schema code cannot run in the shared runtime. `requiredFor` names existing tools whose invocation needs the value; unresolved settings must leave only dependent capabilities unavailable. Publisher compilation does not require a future buyer’s values. Application code enforces business rules server-side; exposing a control or placing the rule in a prompt is insufficient.
 

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.101.0 hash:98c7b07c82a7d7ce -->
+<!-- noodle-skill version:0.103.0 hash:98c7b07c82a7d7ce -->
 
 # 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 all four API-evidence inputs exist—and only then: API base URL, authentication scheme, representative safe read, and observed response."
 ---
 
-<!-- noodle-skill version:0.101.0 hash:8020811f1769c538 -->
+<!-- noodle-skill version:0.103.0 hash:8020811f1769c538 -->
 
 # connecting-apis-to-mcp
 

package/skills/claude-code/connecting-apis-to-mcp/references/authoring-workflow.md

@@ -47,6 +47,9 @@ Declare typed connectors:
 - **HTTP**: `connector("id").version("1.0.0").http({ baseUrl, allowedOrigins, auth, operations })`; map request/response with `${args...}` / `${response...}`. Use `${execution.id}` for provider idempotency, never model input. Optional `evidence: { outcome: "${response.execution_outcome}", reference: "${response.id}" }` classifies completed/rejected/accepted/unknown; reference is a bounded opaque ID, never a bearer URL or payload. No automatic action retry.
 - **MCP**: `connector("id").version("1.0.0").mcp({ endpoint, allowedOrigins, auth?, operations })` where each operation freezes the separate upstream `tool` wire name plus input/output schema. Import with `noodle import mcp`; do not hand-copy a live surface or call `tools/list` at runtime.
 - **Compute**: `connector("id").version("1.0.0").compute(name, { input, output, calls?, run })` — a self-contained, sandboxed function (no imports/closure capture) that may call allowlisted operations via `callOperation`.
+- **Explicit helpers**: `run: (input, host) => ...` can use `host.time.parse(iso)`, `host.time.format(epochMs)`, `host.time.parts(epochMs, timeZone)` and `host.digest(text, "hex")` (or `"base32hex"`). They convert bounded explicit data; there is no ambient clock. Pass trusted `context.temporal.instant` through fulfilment when current time is needed. `examples/weather` demonstrates a stable digest fallback for provider records without IDs.
+- **Expected HTTP errors**: declare `responses: { "409": { response: { status: "conflict" }, evidence: { outcome: "rejected" } } }` alongside the ordinary success `response`. Explicit 4xx overrides exclude 401/403/429; validate against the same output schema. Undeclared errors still fail. Overrides never inherit successful completion evidence or introduce action retries.
+- **Coordinated external actions**: a compute action may declare `coordination: { connectionId, namespace, key: "${args.resource}", reference: "${execution.id}" }` with a bounded execution deadline. It requires an installed application with a live bound connection and durable service coordination. Read `host.coordination.acquired` before writing; a blocked invocation may inspect `previous` through a declared read and call `host.resolveCoordination()` only after exact source proof, then require a fresh invocation/confirmation. The runtime permits at most one nested action when acquired and zero when blocked, even after recovery. Report explicit completed/rejected/unknown evidence with `host.reportOutcome(...)`; a successful return alone never unlocks uncertainty. Do not create an external-record collection for this.
 
 Tools record connector calls into a flow; recording is not execution. Do not branch on runtime outputs with native `if` — use declarative `when(...)` conditions.
 
@@ -219,7 +222,7 @@ Every federated issuer must repeat every endpoint key used by the app, although
 
 Resolved customer URLs are private routing authority: they never enter the manifest/artifact, `${user}`, logs, model output, widgets, public confirmation review, cache keys, or delegated-token-exchange assertions. Routed reads may be used by tools, including declared nested calls. A routed action—including one reached through a connector wrapper—requires exact `annotations.confirm: true`; omitted or `false` fails with `customer_endpoint_action_unsupported`. Routed resources, prompts, and ambient context fail with `customer_endpoint_surface_unsupported`.
 
-At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` remains based only on roles and scopes, so route availability neither reveals tenant topology nor changes the existing authorization filter.
+At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` follows the scope/role discovery rule and its explicit public-descriptor opt-in, so route availability neither reveals tenant topology nor changes execution authorization.
 
 ## Per-tool authorization
 
@@ -241,7 +244,10 @@ tool('list_org_apps', {
 })
 ```
 
-Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Eligible tools remain in authored order in `tools/list`; ineligible tools are omitted and a guessed direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
+Use `authorization.discovery: 'public'` on a nonempty scope/role rule to expose its MCP descriptor before sign-in. Omission and explicit 'authorized' preserve filtered discovery and compile identically. Visibility grants no execution or product-skill eligibility; scopes remain ALL and roles ANY. Noodle derives securitySchemes; never author them.
+For mixed customer preview, keep server customerAuth and adopt on the same org/app/env, endpoint, issuer and audience; keep the separate public Help endpoint during the pilot, and never create overlapping active issuer/audience ownership. Before any mixed deploy or access change, leave only Help unrestricted, add authorization to every customer tool, and validate plus preview with `noodle dev --access mixed`. For an existing customer-only app, first run `noodle deployments list --org <org> --app <app> --env <env> --json` and inspect an inactive `customers` record for the exact server version. If none exists, record the active ID, redeploy the unchanged secured source to the same version with `--access customers`, then list and inspect again to prove that ID is now inactive; recording it alone preserves nothing. Next deploy the policy-prepared source with `--access customers`, verify the original rollback record remains inactive, and only then run `noodle access set mixed ... --version <version>`. On pilot failure use `noodle rollback <deployment-id> --org <org> --app <app> --env <env> --reason <text>`. This app-history rollback differs from the compatible hosted service-release floor. Invalid supplied credentials fail, with no platform-human fallback. Broker exchange remains required. Local Devtools retries after successful sign-in and leaves Help available after cancellation without executing the protected tool. After deployment, test anonymous discovery, sign-in, cancellation, authenticated retry and expiry in the actual host before customer cutover; local/SDK checks do not prove ChatGPT or another host.
+
+Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Tools retain authored order in `tools/list`; protected descriptors are omitted unless explicitly public, and an unauthorized direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
 
 ## Delegated downstream auth (call your API as the signed-in user)
 
@@ -409,7 +415,7 @@ Adapt the representative arguments and assertions when business contracts change
 
 Author managed config as `secret("NAME")` / `variable("NAME")` and operate it with `noodle secrets set` / `noodle variables set` (scoped org/app/env). Never inline secret values in `server.ts`, tests, or generated files.
 
-For business-editable configuration, declare `const notice = variable("SERVICE_NOTICE", { schema: z.string().max(500), default: "Welcome", portal: { label: "Service notice", group: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [notice], ... }, tools)`. Use the same ref in ordinary fulfilment/connector arguments. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
+For business-editable configuration, declare `const guestExperience = variable("GUEST_EXPERIENCE", { schema: z.object({ notice: z.string().max(500) }), default: { notice: "Welcome" }, portal: { label: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [guestExperience], ... }, tools)`. Use the whole ref or `guestExperience.field("notice")` in ordinary fulfilment/connector arguments. `.field()` selects a schema-declared object property, can chain for nested objects, and retains the parent variable and full configuration snapshot; it never reads operator data at author time. Keep confirmed action arguments shallow enough for complete review; do not label ordinary settings sensitive to bypass the review. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
 
 Business schemas must be bounded: booleans, finite bounded numbers, bounded text, string enums, bounded arrays, and closed objects. Put defaults in the declaration, not inside Zod schema defaults; custom transforms/refinements and arbitrary schema code cannot run in the shared runtime. `requiredFor` names existing tools whose invocation needs the value; unresolved settings must leave only dependent capabilities unavailable. Publisher compilation does not require a future buyer’s values. Application code enforces business rules server-side; exposing a control or placing the rule in a prompt is insufficient.
 

package/skills/claude-code/creating-product-agent-guides/SKILL.md

@@ -3,7 +3,7 @@ name: creating-product-agent-guides
 description: "Use when a Noodle Seed MCP server needs a new or revised product agent guide, App Package skill, or explicit product-skill regeneration."
 ---
 
-<!-- noodle-skill version:0.101.0 hash:0e06e11254563b6a -->
+<!-- noodle-skill version:0.103.0 hash:0e06e11254563b6a -->
 
 # creating-product-agent-guides
 

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.101.0 hash:8d75ad13f4b3120a -->
+<!-- noodle-skill version:0.103.0 hash:8d75ad13f4b3120a -->
 
 # 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.101.0 hash:3a1e14ff9b98ddbd -->
+<!-- noodle-skill version:0.103.0 hash:3a1e14ff9b98ddbd -->
 
 # 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.101.0 hash:a21b2ed9997f9454 -->
+<!-- noodle-skill version:0.103.0 hash:a21b2ed9997f9454 -->
 
 # designing-mcp-products
 

package/skills/claude-code/designing-mcp-products/references/authoring-workflow.md

@@ -47,6 +47,9 @@ Declare typed connectors:
 - **HTTP**: `connector("id").version("1.0.0").http({ baseUrl, allowedOrigins, auth, operations })`; map request/response with `${args...}` / `${response...}`. Use `${execution.id}` for provider idempotency, never model input. Optional `evidence: { outcome: "${response.execution_outcome}", reference: "${response.id}" }` classifies completed/rejected/accepted/unknown; reference is a bounded opaque ID, never a bearer URL or payload. No automatic action retry.
 - **MCP**: `connector("id").version("1.0.0").mcp({ endpoint, allowedOrigins, auth?, operations })` where each operation freezes the separate upstream `tool` wire name plus input/output schema. Import with `noodle import mcp`; do not hand-copy a live surface or call `tools/list` at runtime.
 - **Compute**: `connector("id").version("1.0.0").compute(name, { input, output, calls?, run })` — a self-contained, sandboxed function (no imports/closure capture) that may call allowlisted operations via `callOperation`.
+- **Explicit helpers**: `run: (input, host) => ...` can use `host.time.parse(iso)`, `host.time.format(epochMs)`, `host.time.parts(epochMs, timeZone)` and `host.digest(text, "hex")` (or `"base32hex"`). They convert bounded explicit data; there is no ambient clock. Pass trusted `context.temporal.instant` through fulfilment when current time is needed. `examples/weather` demonstrates a stable digest fallback for provider records without IDs.
+- **Expected HTTP errors**: declare `responses: { "409": { response: { status: "conflict" }, evidence: { outcome: "rejected" } } }` alongside the ordinary success `response`. Explicit 4xx overrides exclude 401/403/429; validate against the same output schema. Undeclared errors still fail. Overrides never inherit successful completion evidence or introduce action retries.
+- **Coordinated external actions**: a compute action may declare `coordination: { connectionId, namespace, key: "${args.resource}", reference: "${execution.id}" }` with a bounded execution deadline. It requires an installed application with a live bound connection and durable service coordination. Read `host.coordination.acquired` before writing; a blocked invocation may inspect `previous` through a declared read and call `host.resolveCoordination()` only after exact source proof, then require a fresh invocation/confirmation. The runtime permits at most one nested action when acquired and zero when blocked, even after recovery. Report explicit completed/rejected/unknown evidence with `host.reportOutcome(...)`; a successful return alone never unlocks uncertainty. Do not create an external-record collection for this.
 
 Tools record connector calls into a flow; recording is not execution. Do not branch on runtime outputs with native `if` — use declarative `when(...)` conditions.
 
@@ -219,7 +222,7 @@ Every federated issuer must repeat every endpoint key used by the app, although
 
 Resolved customer URLs are private routing authority: they never enter the manifest/artifact, `${user}`, logs, model output, widgets, public confirmation review, cache keys, or delegated-token-exchange assertions. Routed reads may be used by tools, including declared nested calls. A routed action—including one reached through a connector wrapper—requires exact `annotations.confirm: true`; omitted or `false` fails with `customer_endpoint_action_unsupported`. Routed resources, prompts, and ambient context fail with `customer_endpoint_surface_unsupported`.
 
-At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` remains based only on roles and scopes, so route availability neither reveals tenant topology nor changes the existing authorization filter.
+At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` follows the scope/role discovery rule and its explicit public-descriptor opt-in, so route availability neither reveals tenant topology nor changes execution authorization.
 
 ## Per-tool authorization
 
@@ -241,7 +244,10 @@ tool('list_org_apps', {
 })
 ```
 
-Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Eligible tools remain in authored order in `tools/list`; ineligible tools are omitted and a guessed direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
+Use `authorization.discovery: 'public'` on a nonempty scope/role rule to expose its MCP descriptor before sign-in. Omission and explicit 'authorized' preserve filtered discovery and compile identically. Visibility grants no execution or product-skill eligibility; scopes remain ALL and roles ANY. Noodle derives securitySchemes; never author them.
+For mixed customer preview, keep server customerAuth and adopt on the same org/app/env, endpoint, issuer and audience; keep the separate public Help endpoint during the pilot, and never create overlapping active issuer/audience ownership. Before any mixed deploy or access change, leave only Help unrestricted, add authorization to every customer tool, and validate plus preview with `noodle dev --access mixed`. For an existing customer-only app, first run `noodle deployments list --org <org> --app <app> --env <env> --json` and inspect an inactive `customers` record for the exact server version. If none exists, record the active ID, redeploy the unchanged secured source to the same version with `--access customers`, then list and inspect again to prove that ID is now inactive; recording it alone preserves nothing. Next deploy the policy-prepared source with `--access customers`, verify the original rollback record remains inactive, and only then run `noodle access set mixed ... --version <version>`. On pilot failure use `noodle rollback <deployment-id> --org <org> --app <app> --env <env> --reason <text>`. This app-history rollback differs from the compatible hosted service-release floor. Invalid supplied credentials fail, with no platform-human fallback. Broker exchange remains required. Local Devtools retries after successful sign-in and leaves Help available after cancellation without executing the protected tool. After deployment, test anonymous discovery, sign-in, cancellation, authenticated retry and expiry in the actual host before customer cutover; local/SDK checks do not prove ChatGPT or another host.
+
+Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Tools retain authored order in `tools/list`; protected descriptors are omitted unless explicitly public, and an unauthorized direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
 
 ## Delegated downstream auth (call your API as the signed-in user)
 
@@ -409,7 +415,7 @@ Adapt the representative arguments and assertions when business contracts change
 
 Author managed config as `secret("NAME")` / `variable("NAME")` and operate it with `noodle secrets set` / `noodle variables set` (scoped org/app/env). Never inline secret values in `server.ts`, tests, or generated files.
 
-For business-editable configuration, declare `const notice = variable("SERVICE_NOTICE", { schema: z.string().max(500), default: "Welcome", portal: { label: "Service notice", group: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [notice], ... }, tools)`. Use the same ref in ordinary fulfilment/connector arguments. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
+For business-editable configuration, declare `const guestExperience = variable("GUEST_EXPERIENCE", { schema: z.object({ notice: z.string().max(500) }), default: { notice: "Welcome" }, portal: { label: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [guestExperience], ... }, tools)`. Use the whole ref or `guestExperience.field("notice")` in ordinary fulfilment/connector arguments. `.field()` selects a schema-declared object property, can chain for nested objects, and retains the parent variable and full configuration snapshot; it never reads operator data at author time. Keep confirmed action arguments shallow enough for complete review; do not label ordinary settings sensitive to bypass the review. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
 
 Business schemas must be bounded: booleans, finite bounded numbers, bounded text, string enums, bounded arrays, and closed objects. Put defaults in the declaration, not inside Zod schema defaults; custom transforms/refinements and arbitrary schema code cannot run in the shared runtime. `requiredFor` names existing tools whose invocation needs the value; unresolved settings must leave only dependent capabilities unavailable. Publisher compilation does not require a future buyer’s values. Application code enforces business rules server-side; exposing a control or placing the rule in a prompt is insufficient.
 

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.101.0 hash:d554d661ed7ac7be -->
+<!-- noodle-skill version:0.103.0 hash:d554d661ed7ac7be -->
 
 # embedding-mcp-assistants
 

package/skills/claude-code/embedding-mcp-assistants/references/authoring-workflow.md

@@ -47,6 +47,9 @@ Declare typed connectors:
 - **HTTP**: `connector("id").version("1.0.0").http({ baseUrl, allowedOrigins, auth, operations })`; map request/response with `${args...}` / `${response...}`. Use `${execution.id}` for provider idempotency, never model input. Optional `evidence: { outcome: "${response.execution_outcome}", reference: "${response.id}" }` classifies completed/rejected/accepted/unknown; reference is a bounded opaque ID, never a bearer URL or payload. No automatic action retry.
 - **MCP**: `connector("id").version("1.0.0").mcp({ endpoint, allowedOrigins, auth?, operations })` where each operation freezes the separate upstream `tool` wire name plus input/output schema. Import with `noodle import mcp`; do not hand-copy a live surface or call `tools/list` at runtime.
 - **Compute**: `connector("id").version("1.0.0").compute(name, { input, output, calls?, run })` — a self-contained, sandboxed function (no imports/closure capture) that may call allowlisted operations via `callOperation`.
+- **Explicit helpers**: `run: (input, host) => ...` can use `host.time.parse(iso)`, `host.time.format(epochMs)`, `host.time.parts(epochMs, timeZone)` and `host.digest(text, "hex")` (or `"base32hex"`). They convert bounded explicit data; there is no ambient clock. Pass trusted `context.temporal.instant` through fulfilment when current time is needed. `examples/weather` demonstrates a stable digest fallback for provider records without IDs.
+- **Expected HTTP errors**: declare `responses: { "409": { response: { status: "conflict" }, evidence: { outcome: "rejected" } } }` alongside the ordinary success `response`. Explicit 4xx overrides exclude 401/403/429; validate against the same output schema. Undeclared errors still fail. Overrides never inherit successful completion evidence or introduce action retries.
+- **Coordinated external actions**: a compute action may declare `coordination: { connectionId, namespace, key: "${args.resource}", reference: "${execution.id}" }` with a bounded execution deadline. It requires an installed application with a live bound connection and durable service coordination. Read `host.coordination.acquired` before writing; a blocked invocation may inspect `previous` through a declared read and call `host.resolveCoordination()` only after exact source proof, then require a fresh invocation/confirmation. The runtime permits at most one nested action when acquired and zero when blocked, even after recovery. Report explicit completed/rejected/unknown evidence with `host.reportOutcome(...)`; a successful return alone never unlocks uncertainty. Do not create an external-record collection for this.
 
 Tools record connector calls into a flow; recording is not execution. Do not branch on runtime outputs with native `if` — use declarative `when(...)` conditions.
 
@@ -219,7 +222,7 @@ Every federated issuer must repeat every endpoint key used by the app, although
 
 Resolved customer URLs are private routing authority: they never enter the manifest/artifact, `${user}`, logs, model output, widgets, public confirmation review, cache keys, or delegated-token-exchange assertions. Routed reads may be used by tools, including declared nested calls. A routed action—including one reached through a connector wrapper—requires exact `annotations.confirm: true`; omitted or `false` fails with `customer_endpoint_action_unsupported`. Routed resources, prompts, and ambient context fail with `customer_endpoint_surface_unsupported`.
 
-At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` remains based only on roles and scopes, so route availability neither reveals tenant topology nor changes the existing authorization filter.
+At runtime, an initially missing, malformed, or disallowed claim returns the same safe `connector_route_unavailable` tool error before credential lookup or connector egress. Preparation stores only sorted route `{ key, fingerprint }` bindings in the private server-held continuation. Acceptance re-resolves the current request routes; a missing or changed binding returns `invalid_continuation` before policy, credentials, or egress, then the matching frozen snapshot is reused for the action and nested/later calls. `tools/list` follows the scope/role discovery rule and its explicit public-descriptor opt-in, so route availability neither reveals tenant topology nor changes execution authorization.
 
 ## Per-tool authorization
 
@@ -241,7 +244,10 @@ tool('list_org_apps', {
 })
 ```
 
-Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Eligible tools remain in authored order in `tools/list`; ineligible tools are omitted and a guessed direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
+Use `authorization.discovery: 'public'` on a nonempty scope/role rule to expose its MCP descriptor before sign-in. Omission and explicit 'authorized' preserve filtered discovery and compile identically. Visibility grants no execution or product-skill eligibility; scopes remain ALL and roles ANY. Noodle derives securitySchemes; never author them.
+For mixed customer preview, keep server customerAuth and adopt on the same org/app/env, endpoint, issuer and audience; keep the separate public Help endpoint during the pilot, and never create overlapping active issuer/audience ownership. Before any mixed deploy or access change, leave only Help unrestricted, add authorization to every customer tool, and validate plus preview with `noodle dev --access mixed`. For an existing customer-only app, first run `noodle deployments list --org <org> --app <app> --env <env> --json` and inspect an inactive `customers` record for the exact server version. If none exists, record the active ID, redeploy the unchanged secured source to the same version with `--access customers`, then list and inspect again to prove that ID is now inactive; recording it alone preserves nothing. Next deploy the policy-prepared source with `--access customers`, verify the original rollback record remains inactive, and only then run `noodle access set mixed ... --version <version>`. On pilot failure use `noodle rollback <deployment-id> --org <org> --app <app> --env <env> --reason <text>`. This app-history rollback differs from the compatible hosted service-release floor. Invalid supplied credentials fail, with no platform-human fallback. Broker exchange remains required. Local Devtools retries after successful sign-in and leaves Help available after cancellation without executing the protected tool. After deployment, test anonymous discovery, sign-in, cancellation, authenticated retry and expiry in the actual host before customer cutover; local/SDK checks do not prove ChatGPT or another host.
+
+Role values are trusted only from the explicitly configured claim path (or the platform-private bridge role claim). Direct OIDC scopes default to standard `scope`, `scp`, or `scopes` claims unless `claims.scopes` is configured. Embedded-assistant backends pass verified `user.roles` and `user.scopes` separately during `createAssistantSession(...)`; page context never grants either. Claim values must be a string or string array; malformed or oversized values fail closed. Tools retain authored order in `tools/list`; protected descriptors are omitted unless explicitly public, and an unauthorized direct call is still denied before argument validation or connector execution. Scope denials use MCP OAuth step-up metadata without disclosing role names.
 
 ## Delegated downstream auth (call your API as the signed-in user)
 
@@ -409,7 +415,7 @@ Adapt the representative arguments and assertions when business contracts change
 
 Author managed config as `secret("NAME")` / `variable("NAME")` and operate it with `noodle secrets set` / `noodle variables set` (scoped org/app/env). Never inline secret values in `server.ts`, tests, or generated files.
 
-For business-editable configuration, declare `const notice = variable("SERVICE_NOTICE", { schema: z.string().max(500), default: "Welcome", portal: { label: "Service notice", group: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [notice], ... }, tools)`. Use the same ref in ordinary fulfilment/connector arguments. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
+For business-editable configuration, declare `const guestExperience = variable("GUEST_EXPERIENCE", { schema: z.object({ notice: z.string().max(500) }), default: { notice: "Welcome" }, portal: { label: "Guest experience" }, requiredFor: ["show_menu"] })` and register it in `server(..., { variables: [guestExperience], ... }, tools)`. Use the whole ref or `guestExperience.field("notice")` in ordinary fulfilment/connector arguments. `.field()` selects a schema-declared object property, can chain for nested objects, and retains the parent variable and full configuration snapshot; it never reads operator data at author time. Keep confirmed action arguments shallow enough for complete review; do not label ordinary settings sensitive to bypass the review. The default is reusable safe intent; each business supplies its own values without editing source. Only explicit `portal` metadata exposes a setting. Name-only references and declared variables without `portal` remain technical configuration; secrets remain credential slots. See the bundled `acme-bistro` source.
 
 Business schemas must be bounded: booleans, finite bounded numbers, bounded text, string enums, bounded arrays, and closed objects. Put defaults in the declaration, not inside Zod schema defaults; custom transforms/refinements and arbitrary schema code cannot run in the shared runtime. `requiredFor` names existing tools whose invocation needs the value; unresolved settings must leave only dependent capabilities unavailable. Publisher compilation does not require a future buyer’s values. Application code enforces business rules server-side; exposing a control or placing the rule in a prompt is insufficient.
 

package/skills/claude-code/examples/acme-bistro/README.md

@@ -2,7 +2,7 @@
 
 Fictional [`menu/cart`](src/server.ts) with off-app payment: card data stays outside the app.
 
-`SERVICE_NOTICE` settings and native `guest_requests` demonstrate status, field exposure and notes. `submit_guest_request` requires an authorized installation and returns a receipt
+`GUEST_EXPERIENCE` settings use `guestExperience.field('notice')` to select a typed business value; native `guest_requests` demonstrate status, field exposure and notes. `submit_guest_request` requires an authorized installation and returns a receipt
 for staff review. The installed skill's `references/authoring-workflow.md` owns setup and source contracts.
 External collections declare a bounded connector scan; provider changes remain ordinary tools.
 

package/skills/claude-code/examples/acme-bistro/src/server.ts

@@ -20,11 +20,11 @@ const menu = [
 
 const itemId = z.enum(['stone_pizza', 'roast_bowl', 'house_salad', 'lemon_tart', 'sparkling']);
 
-// A business administrator may change this notice; the reusable application stays the same.
-const serviceNotice = variable('SERVICE_NOTICE', {
-  schema: z.string().max(500),
-  default: 'Ask us about dietary requirements before placing your order.',
-  portal: { label: 'Service notice', group: 'Guest experience' },
+// Operators configure the notice without redeploying.
+const guestExperience = variable('GUEST_EXPERIENCE', {
+  schema: z.object({ notice: z.string().max(500) }),
+  default: { notice: 'Ask us about dietary requirements before placing your order.' },
+  portal: { label: 'Guest experience', group: 'Guest experience' },
   requiredFor: ['show_menu'],
 });
 
@@ -86,7 +86,7 @@ export default server(
     // Reusable business-record intent. Storage, lifecycle, access, and public intake bind separately.
     collections: [guestRequests],
     use: { records: noodlePlatform.records.v1 },
-    variables: [serviceNotice],
+    variables: [guestExperience],
   },
   [
     tool('submit_guest_request', {
@@ -123,7 +123,7 @@ export default server(
       fulfil: ({ input }) => ({
         status: `Acme Bistro menu is ready for ${input.customer}. Build the order here; pay at checkout.`,
         customer: input.customer,
-        serviceNotice,
+        serviceNotice: guestExperience.field('notice'),
         items: menu,
       }),
       viewTitle: 'Order at Acme Bistro',

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

@@ -7,20 +7,16 @@ This curated example owns the customer/end-user authentication capability slot.
 can protect an MCP endpoint with direct OIDC, retain role/scope-based tool authorization, and route ordinary
 reads and confirmed actions to the API origin selected by the verified customer's identity provider.
 
-It also owns the customer-branded embedded-assistant presentation showcase. Direct MCP calls obtain the
-route from the verified OIDC claim; embedded sessions obtain it from the authenticated customer backend's
-session exchange. Both paths keep the URL outside tool/model/browser-visible state. The built-in card hides
-its optional technical Additional details disclosure while retaining the business review and confirmation
-controls; this presentation setting does not weaken the exact runtime confirmation boundary.
+Direct MCP calls obtain the private route from verified OIDC claims; embedded sessions obtain it from the authenticated backend. Both keep routes out of model and browser state.
 
 The public developer entrypoint is [`src/server.ts`](src/server.ts). It exposes a deliberately small MCP
 surface for organization discovery and app lifecycle operations:
 
-- `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 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.
+- `help` explains the product without customer identity.
+- `list_my_organizations` publicly advertises its descriptor but requires `organizations:read` to list the signed-in customer’s organizations.
+- `list_org_apps` uses `authorization.discovery: 'public'` to expose its descriptor on an anonymously
+  accessible endpoint. Execution still requires `org_apps:read` and `org_admin` or `org_member`. Visibility
+  grants no permissions, records, role disclosure, or product-guide eligibility. ChatGPT sign-in is unproven.
 - `archive_org_app` archives one app only after exact runtime confirmation. It requires the
   `org_apps:write` scope and `org_admin` role.
 
@@ -28,22 +24,7 @@ The tools chain: `list_my_organizations` surfaces the `org_id`s the customer can
 `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.
 
-The server also declares one typed `agentGuide` for those product workflows. The deployed embedded assistant
-uses it automatically: each turn keeps only complete workflows supported by the verified session's roles,
-scopes, and model-visible tools. An organization member can receive organization/app review guidance, while
-only an administrator with `org_apps:write` receives the complete archive workflow and its confirmation
-boundary. The guide stays server-side, so the Web Component, React renderer, headless hook, and public client
-need no new option and receive no raw skill content. See
-[using a product guide at runtime](https://docs.noodleseed.dev/docs/guides/product-agent-guides#use-the-guide-at-runtime)
-for the public behavior guide.
-
-A skill-aware external agent connected directly to the same tenant MCP URL receives the same
-complete-workflow filtering through the modern draft MCP Skills extension. Members and administrators may
-therefore receive different `SKILL.md` and MCP-surface bytes, each with matching caller-specific digests.
-This reuses the configured customer OAuth boundary; it does not require a second skill installation or auth
-system, and it is not a claim that every external host currently implements the draft extension. The
-same [runtime guide](https://docs.noodleseed.dev/docs/guides/product-agent-guides#use-the-guide-at-runtime)
-explains this preview boundary.
+The typed `agentGuide` retains only complete workflows the verified caller can execute. Public descriptor discovery does not grant workflow access. See the [runtime guide](https://docs.noodleseed.dev/docs/guides/product-agent-guides#use-the-guide-at-runtime) for embedded behavior and the draft MCP Skills preview.
 
 ## Declare the customer endpoint
 
@@ -212,6 +193,7 @@ rule beside the rest of its public contract:
 ```ts
 tool('list_org_apps', {
   authorization: {
+    discovery: 'public',
     requiredScopes: ['org_apps:read'],
     allowedRoles: ['org_admin', 'org_member'],
   },
@@ -220,9 +202,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. 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.
+both conditions apply. In mixed customer mode, `discovery: 'public'` exposes this descriptor before sign-in;
+execution still requires those scopes and roles. Other restricted tools remain filtered by authorization.
+Route availability never changes discovery, and unauthorized direct calls fail closed.
 
 Tool code calls the connector normally:
 
@@ -811,11 +793,7 @@ subject assertion and mints a short-lived token scoped to the signed-in user and
 
 ## Launch and qualified-usage proof
 
-Use the [embedded assistant guide](https://docs.noodleseed.dev/docs/guides/embedded-assistant) for the complete
-pre-launch, browser-proof, qualified-usage, recovery, measurement, and operator procedure; do not copy those
-commands into this example. Keep deployed capability, production-browser proof, qualified usage, and measured
-outcome separate; raw turn volume is utilization rather than outcome. Platform-owned completion events still
-require a separate human-approved analytics and customer-data contract.
+For launch, browser verification, and qualified usage, follow the [embedded assistant guide](https://docs.noodleseed.dev/docs/guides/embedded-assistant).
 
 ## Deploy customer-protected to Noodle Seed Cloud
 
@@ -833,13 +811,23 @@ Endpoint:
 https://cloud.noodleseed.dev/o/noodleseed/customer-auth/mcp
 ```
 
-## MCP Primitives
-
-- 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`.
+## Preview anonymous Help with customer sign-in
+
+Use `noodle dev examples/customer-auth/src/server.ts --access mixed`. Help remains available before sign-in;
+protected reads advertise descriptors and require their verified scopes/roles to execute. Customer mode
+remains the default. Local Devtools retries a protected call after successful sign-in; cancellation executes
+nothing and leaves Help available. With a hosted service, a new target may use
+`--access mixed` only after every customer tool has an authorization rule. For an existing customer-only
+target, preserve its org/app/env, endpoint, issuer, and audience. Follow the public guide: verify an inactive
+`customers` record for the exact version, creating it by unchanged secured redeploy if absent; add and
+validate every tool rule; deploy the prepared source as `customers`; recheck the rollback; then adopt mixed
+access. On pilot failure, use
+`noodle rollback <deployment-id>` with the same org/app/env. This app-history rollback is separate from the
+compatible hosted service-release floor. Keep the public Help endpoint through the post-deployment ChatGPT
+and customer API pilot. Local behavior and wire checks do not prove that host
+journey. See the
+[customer auth rollback and adoption procedure](https://docs.noodleseed.dev/docs/guides/customer-auth#preserve-an-app-rollback-target-and-adopt)
+for the exact commands and checks.
 
 ## Auth boundary
 

package/skills/claude-code/examples/customer-auth/src/server.ts

@@ -202,10 +202,23 @@ export default server(
     }),
   },
   [
+    tool('help', {
+      title: 'Help with organizations and apps',
+      description: 'Explain what customers can do before they sign in.',
+      input: z.object({}),
+      output: z.object({ help: z.string() }),
+      annotations: annotations.readOnly(),
+      fulfil() {
+        return {
+          help: 'Sign in to browse your organizations and apps. Archiving an app requires an administrator and confirmation.',
+        };
+      },
+    }),
     tool('list_org_apps', {
       title: 'List organization apps',
       description: 'List NoodleSeed.com apps for an organization from its customer API.',
       authorization: {
+        discovery: 'public',
         requiredScopes: ['org_apps:read'],
         allowedRoles: ['org_admin', 'org_member'],
       },
@@ -232,12 +245,10 @@ export default server(
     tool('list_my_organizations', {
       title: 'List my organizations',
       description: 'List the NoodleSeed.com organizations the signed-in customer belongs to.',
+      authorization: { discovery: 'public', requiredScopes: ['organizations:read'] },
       contextProvider: true,
       input: z.object({}),
-      // 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`.
+      // The API returns all of the caller's organizations without pagination; bound the output shape.
       output: z.object({
         organizations: z.array(z.unknown()).max(100),
       }),

package/skills/claude-code/examples/customer-auth/test/server.test.ts

@@ -85,12 +85,17 @@ describe('customer-auth example', () => {
     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({
+      discovery: 'public',
       requiredScopes: ['org_apps:read'],
       allowedRoles: ['org_admin', 'org_member'],
     });
     expect(
       manifest.tools.find((tool) => tool.name === 'list_my_organizations')?.authorization,
-    ).toBeUndefined();
+    ).toEqual({ discovery: 'public', requiredScopes: ['organizations:read'] });
+    const help = manifest.tools.find((tool) => tool.name === 'help');
+    expect(help).toBeDefined();
+    expect(help?.authorization).toBeUndefined();
+    expect(help?.annotations?.readOnlyHint).toBe(true);
     expect(manifest.tools.find((tool) => tool.name === 'archive_org_app')).toMatchObject({
       authorization: {
         requiredScopes: ['org_apps:write'],

package/skills/claude-code/examples/weather/src/server.ts

@@ -158,8 +158,8 @@ const placeNarrow = connector('geo_places')
     type: 'read',
     input: z.object({ results: z.unknown().optional() }),
     output: z.object({ places: z.array(z.unknown()) }),
-    // Self-contained: no imports, no closure over outer variables, synchronous.
-    run: (input) => {
+    // Synchronous and self-contained.
+    run: (input, host) => {
       const raw = input.results;
       const list = Array.isArray(raw) ? raw : [];
       const places = list.map((entry) => {
@@ -169,7 +169,7 @@ const placeNarrow = connector('geo_places')
         const id =
           entry.id !== undefined && entry.id !== null
             ? String(entry.id)
-            : `${entry.latitude},${entry.longitude}`;
+            : host.digest(`${entry.latitude},${entry.longitude}`);
         return { id, label: parts.join(', ') };
       });
       return { places };

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.101.0 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.103.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.101.0 hash:0ccafb222038f553 -->
+<!-- noodle-skill version:0.103.0 hash:0ccafb222038f553 -->
 
 # publishing-mcp-integrations