@noodleseed/agent-kit 0.96.0 → 0.98.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.96.0",
+  "version": "0.98.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.96.0 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.98.0 hash:d3ceb1902ef4bb72 -->
 
 # Noodle Seed
 
@@ -21,7 +21,7 @@ Choose exactly one primary route from the user outcome below, then load the sele
 
 Apply this precedence when wording overlaps: concrete failure evidence takes the debugging route; an explicit request to create, revise, regenerate, or recover an app product skill takes `creating-product-agent-guides`; an MCP App/UI outcome takes the App route; an existing application with no stable, usable API or specification takes `wrapping-existing-applications`; only when all four API-evidence inputs exist—an API base URL, authentication scheme, representative safe read, and observed response—use `connecting-apis-to-mcp`; missing, stale, inaccessible, undocumented-only, or otherwise unusable evidence remains in `wrapping-existing-applications`; both integration routes take precedence over generic server building; hosted inspection is debugging read-only; hosted mutation requires the explicitly requested deployment route.
 
-Negative routing examples: “Inspect hosted logs/status” → `inspect-hosted` (read-only). “Prepare for deployment” → the applicable build or verification route and stop with a handoff; preparation does not authorize `link`, hosted config, deployment, rollback, host writes, or submission. “Keep this local” → a build or verification route, never a hosted route.
+Negative routing examples: “Inspect hosted logs/status” → `inspect-hosted` (read-only). “Prepare for deployment” → the applicable build or verification route; with existing access it may inspect `deploy preflight`, then stop with a handoff. Preparation does not authorize `link`, hosted config, publication, rollback, host writes, or submission. “Keep this local” → a build or verification route, never a hosted route.
 
 | User outcome | Load sibling skill | Canonical playbook | Done when |
 | :--- | :--- | :--- | :--- |

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.96.0 hash:dd57a15df15d10b2 -->
+<!-- noodle-skill version:0.98.0 hash:dd57a15df15d10b2 -->
 
 # authoring-mcp-servers
 

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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.96.0 hash:98c7b07c82a7d7ce -->
+<!-- noodle-skill version:0.98.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.96.0 hash:8020811f1769c538 -->
+<!-- noodle-skill version:0.98.0 hash:8020811f1769c538 -->
 
 # connecting-apis-to-mcp
 

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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.96.0 hash:0e06e11254563b6a -->
+<!-- noodle-skill version:0.98.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.96.0 hash:8d75ad13f4b3120a -->
+<!-- noodle-skill version:0.98.0 hash:8d75ad13f4b3120a -->
 
 # debugging-mcp-delivery
 

package/skills/claude-code/debugging-mcp-delivery/references/inspect-hosted.md

@@ -9,13 +9,14 @@ Read hosted evidence without changing target, credentials, configuration, access
 
 ## Authority boundary
 
-This route is read-only. It never authorizes `login`, `logout`, `link`, `target set`, hosted secret/variable/config/access changes, `deploy`, `rollback`, host configuration writes, or directory submission. If evidence shows one of those actions is needed, report the exact proposed action and target, then stop for a new explicit user request.
+This route is read-only. `deploy preflight` inspects authored deployment inputs with existing access; it is not `deploy` publication. This route never authorizes `login`, `logout`, `link`, `target set`, hosted secret/variable/config/access changes, publication, `rollback`, host configuration writes, or directory submission. If evidence shows one of those actions is needed, report the exact proposed action and target, then stop for a new explicit user request.
 
 ## Workflow
 
 1. Resolve the requested org, app, environment, and deployment from existing non-secret context. Do not change the effective target to make inspection easier.
 2. Choose the narrowest read-only command: `noodle target show`, `noodle status`, `noodle inspect`, `noodle smoke`, `noodle metrics --agent-output`, `noodle events --json`, `noodle logs`, or `noodle audit`.
 3. Prefer machine output when the selected command supports it. Record the target, revision/deployment ID, timestamp, result, and any request ID without exposing secrets or customer payloads.
+For authored deployment readiness, select `deploy preflight` from the generated CLI command reference and supply the intended target. It does not configure, import dotenv, upload assets, save a retry key or publish. Routine login refresh may renew credentials. Missing-config actions are suggestions requiring separate authorization. A ready report is not backend, host or deployment evidence; publication always checks again.
 4. When the installed Developer MCP is available, call `get_context` to read the signed-in user’s current organizations and roles. Resolve the intended organization from the request or project context, then pass that explicit `org` to every scoped inspection or diagnosis tool. Never infer a remote default, and never ask the user to preselect organizations during OAuth. Treat the connection as live evidence gathering, not mutation authority.
 5. If a command fails, distinguish missing authentication/access from unhealthy application behavior. Do not repair, relink, redeploy, rotate config, or roll back under this route.
 

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

@@ -58,6 +58,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 - Real API: distinguish authentication, reachability, legitimate empty results, and broken response mappings before changing code.
 - App: repair the cited contract or state in `noodle check --json`, then confirm it in devtools before attempting a host.
 - Host/deployment/production: confirm revision, target, identity, and configuration independently; do not infer one from another.
+- Authored deploy readiness: with existing access and the intended target, inspect `noodle deploy preflight --json` through the installed execution transport (`noodle-readiness.preflight_build` for plugin users). It never configures or publishes. Use all returned findings; proposed configuration commands require separate authorization. Readiness is not a backend call or hosted journey.
 - Repeated external failure: preserve passing evidence and report the sanitized failure, required authority or external state, owner, and exact next action.
 
 ## Stop conditions

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.96.0 hash:3a1e14ff9b98ddbd -->
+<!-- noodle-skill version:0.98.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.96.0 hash:a21b2ed9997f9454 -->
+<!-- noodle-skill version:0.98.0 hash:a21b2ed9997f9454 -->
 
 # designing-mcp-products
 

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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

@@ -8,7 +8,8 @@ Capability slots: HTTP connector authoring, ordered fulfilment flows, query/resp
 sandboxed compute, including an explicit least-privilege per-operation response-size bound.
 
 For a different API with an OpenAPI document, start with `noodle import openapi <file>` in a separate
-directory. Its shared schemas and offline test establish the contract, not live behavior; follow the
+directory. It preserves supported typed JSON bodies and scalar parameters; unsupported input encodings
+stop import instead of dropping fields. Its offline test establishes the contract, not live behavior; follow the
 [connector guide](https://docs.noodleseed.dev/docs/guides/connectors) before replacing this curated flow.
 
 1. **`geo.search`** → geocode the city to coordinates (Open-Meteo Geocoding API)
@@ -70,6 +71,11 @@ or set `Content-Type` manually; the connector owns both.
 
 ## Run it locally
 
+Before an authorized hosted deployment, inspect this project's inputs with your project-local CLI:
+`noodle deploy preflight --org <org> --app weather --env staging --version 1 --json`.
+This requires existing hosted access but does not publish or call the weather backend. Its readiness result
+does not replace the local and hosted representative-call checks below.
+
 From the repo root, with the workspace built (`pnpm build`):
 
 ```bash

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

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

package/skills/claude-code/references/inspect-hosted.md

@@ -9,13 +9,14 @@ Read hosted evidence without changing target, credentials, configuration, access
 
 ## Authority boundary
 
-This route is read-only. It never authorizes `login`, `logout`, `link`, `target set`, hosted secret/variable/config/access changes, `deploy`, `rollback`, host configuration writes, or directory submission. If evidence shows one of those actions is needed, report the exact proposed action and target, then stop for a new explicit user request.
+This route is read-only. `deploy preflight` inspects authored deployment inputs with existing access; it is not `deploy` publication. This route never authorizes `login`, `logout`, `link`, `target set`, hosted secret/variable/config/access changes, publication, `rollback`, host configuration writes, or directory submission. If evidence shows one of those actions is needed, report the exact proposed action and target, then stop for a new explicit user request.
 
 ## Workflow
 
 1. Resolve the requested org, app, environment, and deployment from existing non-secret context. Do not change the effective target to make inspection easier.
 2. Choose the narrowest read-only command: `noodle target show`, `noodle status`, `noodle inspect`, `noodle smoke`, `noodle metrics --agent-output`, `noodle events --json`, `noodle logs`, or `noodle audit`.
 3. Prefer machine output when the selected command supports it. Record the target, revision/deployment ID, timestamp, result, and any request ID without exposing secrets or customer payloads.
+For authored deployment readiness, select `deploy preflight` from the generated CLI command reference and supply the intended target. It does not configure, import dotenv, upload assets, save a retry key or publish. Routine login refresh may renew credentials. Missing-config actions are suggestions requiring separate authorization. A ready report is not backend, host or deployment evidence; publication always checks again.
 4. When the installed Developer MCP is available, call `get_context` to read the signed-in user’s current organizations and roles. Resolve the intended organization from the request or project context, then pass that explicit `org` to every scoped inspection or diagnosis tool. Never infer a remote default, and never ask the user to preselect organizations during OAuth. Treat the connection as live evidence gathering, not mutation authority.
 5. If a command fails, distinguish missing authentication/access from unhealthy application behavior. Do not repair, relink, redeploy, rotate config, or roll back under this route.
 

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

@@ -58,6 +58,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 - Real API: distinguish authentication, reachability, legitimate empty results, and broken response mappings before changing code.
 - App: repair the cited contract or state in `noodle check --json`, then confirm it in devtools before attempting a host.
 - Host/deployment/production: confirm revision, target, identity, and configuration independently; do not infer one from another.
+- Authored deploy readiness: with existing access and the intended target, inspect `noodle deploy preflight --json` through the installed execution transport (`noodle-readiness.preflight_build` for plugin users). It never configures or publishes. Use all returned findings; proposed configuration commands require separate authorization. Readiness is not a backend call or hosted journey.
 - Repeated external failure: preserve passing evidence and report the sanitized failure, required authority or external state, owner, and exact next action.
 
 ## Stop conditions

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.96.0 hash:660cc6ad9469d90f -->
+<!-- noodle-skill version:0.98.0 hash:660cc6ad9469d90f -->
 
 # 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.96.0 hash:292253cbaed9a3c5 -->
+<!-- noodle-skill version:0.98.0 hash:292253cbaed9a3c5 -->
 
 # verifying-mcp-delivery
 

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

@@ -58,6 +58,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 - Real API: distinguish authentication, reachability, legitimate empty results, and broken response mappings before changing code.
 - App: repair the cited contract or state in `noodle check --json`, then confirm it in devtools before attempting a host.
 - Host/deployment/production: confirm revision, target, identity, and configuration independently; do not infer one from another.
+- Authored deploy readiness: with existing access and the intended target, inspect `noodle deploy preflight --json` through the installed execution transport (`noodle-readiness.preflight_build` for plugin users). It never configures or publishes. Use all returned findings; proposed configuration commands require separate authorization. Readiness is not a backend call or hosted journey.
 - Repeated external failure: preserve passing evidence and report the sanitized failure, required authority or external state, owner, and exact next action.
 
 ## Stop conditions

package/skills/claude-code/wrapping-existing-applications/SKILL.md

@@ -3,7 +3,7 @@ name: wrapping-existing-applications
 description: "Use when an existing application has no stable usable API and needs a read-only, identity-first Noodle Seed integration plan before implementation."
 ---
 
-<!-- noodle-skill version:0.96.0 hash:379ab9f64878f1fe -->
+<!-- noodle-skill version:0.98.0 hash:379ab9f64878f1fe -->
 
 # wrapping-existing-applications
 

package/skills/claude-code/wrapping-existing-applications/references/authoring-workflow.md

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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.96.0 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.98.0 hash:d3ceb1902ef4bb72 -->
 
 # Noodle Seed
 
@@ -21,7 +21,7 @@ Choose exactly one primary route from the user outcome below, then load the sele
 
 Apply this precedence when wording overlaps: concrete failure evidence takes the debugging route; an explicit request to create, revise, regenerate, or recover an app product skill takes `creating-product-agent-guides`; an MCP App/UI outcome takes the App route; an existing application with no stable, usable API or specification takes `wrapping-existing-applications`; only when all four API-evidence inputs exist—an API base URL, authentication scheme, representative safe read, and observed response—use `connecting-apis-to-mcp`; missing, stale, inaccessible, undocumented-only, or otherwise unusable evidence remains in `wrapping-existing-applications`; both integration routes take precedence over generic server building; hosted inspection is debugging read-only; hosted mutation requires the explicitly requested deployment route.
 
-Negative routing examples: “Inspect hosted logs/status” → `inspect-hosted` (read-only). “Prepare for deployment” → the applicable build or verification route and stop with a handoff; preparation does not authorize `link`, hosted config, deployment, rollback, host writes, or submission. “Keep this local” → a build or verification route, never a hosted route.
+Negative routing examples: “Inspect hosted logs/status” → `inspect-hosted` (read-only). “Prepare for deployment” → the applicable build or verification route; with existing access it may inspect `deploy preflight`, then stop with a handoff. Preparation does not authorize `link`, hosted config, publication, rollback, host writes, or submission. “Keep this local” → a build or verification route, never a hosted route.
 
 | User outcome | Load sibling skill | Canonical playbook | Done when |
 | :--- | :--- | :--- | :--- |

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.96.0 hash:dd57a15df15d10b2 -->
+<!-- noodle-skill version:0.98.0 hash:dd57a15df15d10b2 -->
 
 # authoring-mcp-servers
 

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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.96.0 hash:98c7b07c82a7d7ce -->
+<!-- noodle-skill version:0.98.0 hash:98c7b07c82a7d7ce -->
 
 # building-mcp-apps
 

package/skills/codex/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.96.0 hash:8020811f1769c538 -->
+<!-- noodle-skill version:0.98.0 hash:8020811f1769c538 -->
 
 # connecting-apis-to-mcp
 

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

package/skills/codex/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.96.0 hash:0e06e11254563b6a -->
+<!-- noodle-skill version:0.98.0 hash:0e06e11254563b6a -->
 
 # creating-product-agent-guides
 

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.96.0 hash:8d75ad13f4b3120a -->
+<!-- noodle-skill version:0.98.0 hash:8d75ad13f4b3120a -->
 
 # debugging-mcp-delivery
 

package/skills/codex/debugging-mcp-delivery/references/inspect-hosted.md

@@ -9,13 +9,14 @@ Read hosted evidence without changing target, credentials, configuration, access
 
 ## Authority boundary
 
-This route is read-only. It never authorizes `login`, `logout`, `link`, `target set`, hosted secret/variable/config/access changes, `deploy`, `rollback`, host configuration writes, or directory submission. If evidence shows one of those actions is needed, report the exact proposed action and target, then stop for a new explicit user request.
+This route is read-only. `deploy preflight` inspects authored deployment inputs with existing access; it is not `deploy` publication. This route never authorizes `login`, `logout`, `link`, `target set`, hosted secret/variable/config/access changes, publication, `rollback`, host configuration writes, or directory submission. If evidence shows one of those actions is needed, report the exact proposed action and target, then stop for a new explicit user request.
 
 ## Workflow
 
 1. Resolve the requested org, app, environment, and deployment from existing non-secret context. Do not change the effective target to make inspection easier.
 2. Choose the narrowest read-only command: `noodle target show`, `noodle status`, `noodle inspect`, `noodle smoke`, `noodle metrics --agent-output`, `noodle events --json`, `noodle logs`, or `noodle audit`.
 3. Prefer machine output when the selected command supports it. Record the target, revision/deployment ID, timestamp, result, and any request ID without exposing secrets or customer payloads.
+For authored deployment readiness, select `deploy preflight` from the generated CLI command reference and supply the intended target. It does not configure, import dotenv, upload assets, save a retry key or publish. Routine login refresh may renew credentials. Missing-config actions are suggestions requiring separate authorization. A ready report is not backend, host or deployment evidence; publication always checks again.
 4. When the installed Developer MCP is available, call `get_context` to read the signed-in user’s current organizations and roles. Resolve the intended organization from the request or project context, then pass that explicit `org` to every scoped inspection or diagnosis tool. Never infer a remote default, and never ask the user to preselect organizations during OAuth. Treat the connection as live evidence gathering, not mutation authority.
 5. If a command fails, distinguish missing authentication/access from unhealthy application behavior. Do not repair, relink, redeploy, rotate config, or roll back under this route.
 

package/skills/codex/debugging-mcp-delivery/references/verify-and-recover.md

@@ -58,6 +58,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 - Real API: distinguish authentication, reachability, legitimate empty results, and broken response mappings before changing code.
 - App: repair the cited contract or state in `noodle check --json`, then confirm it in devtools before attempting a host.
 - Host/deployment/production: confirm revision, target, identity, and configuration independently; do not infer one from another.
+- Authored deploy readiness: with existing access and the intended target, inspect `noodle deploy preflight --json` through the installed execution transport (`noodle-readiness.preflight_build` for plugin users). It never configures or publishes. Use all returned findings; proposed configuration commands require separate authorization. Readiness is not a backend call or hosted journey.
 - Repeated external failure: preserve passing evidence and report the sanitized failure, required authority or external state, owner, and exact next action.
 
 ## Stop conditions

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.96.0 hash:3a1e14ff9b98ddbd -->
+<!-- noodle-skill version:0.98.0 hash:3a1e14ff9b98ddbd -->
 
 # 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.96.0 hash:a21b2ed9997f9454 -->
+<!-- noodle-skill version:0.98.0 hash:a21b2ed9997f9454 -->
 
 # designing-mcp-products
 

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.

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

@@ -8,7 +8,8 @@ Capability slots: HTTP connector authoring, ordered fulfilment flows, query/resp
 sandboxed compute, including an explicit least-privilege per-operation response-size bound.
 
 For a different API with an OpenAPI document, start with `noodle import openapi <file>` in a separate
-directory. Its shared schemas and offline test establish the contract, not live behavior; follow the
+directory. It preserves supported typed JSON bodies and scalar parameters; unsupported input encodings
+stop import instead of dropping fields. Its offline test establishes the contract, not live behavior; follow the
 [connector guide](https://docs.noodleseed.dev/docs/guides/connectors) before replacing this curated flow.
 
 1. **`geo.search`** → geocode the city to coordinates (Open-Meteo Geocoding API)
@@ -70,6 +71,11 @@ or set `Content-Type` manually; the connector owns both.
 
 ## Run it locally
 
+Before an authorized hosted deployment, inspect this project's inputs with your project-local CLI:
+`noodle deploy preflight --org <org> --app weather --env staging --version 1 --json`.
+This requires existing hosted access but does not publish or call the weather backend. Its readiness result
+does not replace the local and hosted representative-call checks below.
+
 From the repo root, with the workspace built (`pnpm build`):
 
 ```bash

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

@@ -3,7 +3,7 @@ name: executing-noodle-plans
 description: "Use when the user asks to execute an approved, decision-complete implementation plan for a Noodle Seed project task by task with test-first changes, review, recovery, and final verification."
 ---
 
-<!-- noodle-skill version:0.96.0 hash:6a9f132ddb79352e -->
+<!-- noodle-skill version:0.98.0 hash:6a9f132ddb79352e -->
 
 # Execute a Noodle Seed implementation plan
 

package/skills/codex/publishing-mcp-integrations/SKILL.md

@@ -3,7 +3,7 @@ name: publishing-mcp-integrations
 description: "Use when preparing, reviewing, or submitting a Noodle Seed MCP integration to a host or app directory."
 ---
 
-<!-- noodle-skill version:0.96.0 hash:0ccafb222038f553 -->
+<!-- noodle-skill version:0.98.0 hash:0ccafb222038f553 -->
 
 # publishing-mcp-integrations
 

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

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.