@noodleseed/agent-kit 0.94.0 → 0.96.0

package/skills/claude-code/references/examples.md

@@ -15,6 +15,7 @@ Paths are relative to this skill directory. Assets (images/fonts) are omitted fr
 | `acme-tasks` | A two-way productivity app designed around its top-3 prioritized flows (capture/prioritize/complete), with a design-first flow spec + wireframe. | `examples/acme-tasks/src/server.ts` + `design/` |
 | `acme-bistro` | End-to-end ordering with a payment-only handoff; ships a gold-standard `design/` set (UX doc, wireframe with compliance audit, API contract). | `examples/acme-bistro/src/server.ts` + `design/` |
 | `customer-auth` | End-user OIDC, private customer API routing, route-bound confirmed actions, roles/scopes, and delegated credentials. | `examples/customer-auth/src/server.ts` |
+| `stateful-draft` | Review and save a brief before signup; carry caller-scoped state into an account. | `examples/stateful-draft/src/server.ts` |
 | `gmail-multi-account` | One curated Gmail connector reused by two account bindings, canonical account arrays, exact mutation confirmation, and an accompanying personal-automation skill. | `examples/gmail-multi-account/src/server.ts` |
 | `google-bigquery` | Keyless Google Workload Identity Federation with optional service-account impersonation, a BigQuery REST connector, and complete developer/operator setup. | `examples/google-bigquery/src/server.ts` |
 
@@ -22,7 +23,6 @@ Paths are relative to this skill directory. Assets (images/fonts) are omitted fr
 
 | Example | Use when |
 | :-- | :-- |
-| `stateful-draft` | Durable, caller-scoped widget state handles with optimistic revisions. |
 | `perplexity` | A real SaaS API with bearer auth and a managed `secret`. |
 | `bitcoin` | API-key HTTP connector, custom auth header, and compute normalization. |
 | `sharepoint` | Microsoft SharePoint delegated Microsoft Entra auth and Graph tools. |

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

@@ -23,6 +23,7 @@ Use this ordered evidence ladder. Start at the last known passing layer or the l
 1. **Compile** — the TypeScript build and authoring import surface are valid.
 2. **Validate** — `noodle validate --json` accepts the Noodle contract.
 3. **Local smoke** — `noodle test --json` starts the local runtime. Open apps exercise MCP registration; customer-auth apps must instead pass the anonymous 401 plus exact protected-resource metadata boundary and report `interactiveRequired: true`.
+   To prove a safe read, explicitly supply `--tool <read_tool> --args <json>` or use `noodle tools call <read_tool> --args <json> --json`. These commands fail on protocol/tool errors, missing or incomplete results, and a declared output-schema mismatch. `input_required` is not completion: use Devtools for interactive input, never fabricate approval or retry an uncertain write.
 4. **Customer auth** — when customer auth is declared, run `noodle auth doctor src/server.ts --json` for metadata and JWKS readiness, then run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or representative safe read. The doctor does not prove that registration or token issuance succeeds; the authenticated request proves issuer, signature, stable audience, and exact-resource binding together.
 5. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
 6. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
@@ -53,7 +54,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 ## Recovery paths
 
 - Compile/validation: repair the exact import, schema, or reported path, then rerun that command without freeform changes.
-- Local boot/smoke: use the structured startup error to correct the effective target, config, or entrypoint before retrying.
+- Local boot/smoke: use all reported missing variable and secret names and the exact-target recovery commands together. Values stay outside the diagnostic. `error.detail.reason` identifies incomplete/failed operation evidence; RPC message/data and continuation state are deliberately not copied. A failed response does not prove a write was rolled back.
 - 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.

package/skills/claude-code/references/widgets-and-apps.md

@@ -18,7 +18,7 @@ Use `tool(name, { description, input, output, fulfil, view })` for a model-visib
 
 Generated widgets, official examples, and agent-authored MCP Apps must start with `@noodleseed/one/react` primitives and semantic tokens. Custom React/CSS or third-party components remain valid when the kit lacks the required behavior or the developer explicitly requests them.
 
-`noodle init my-app` defaults to the SaaS profile: federated OIDC placeholders, one explicit context-provider tool, MCP App UI, resource, prompt, state contract, branding, handoff, and embedded assistant. Begin by replacing the IdP/audience/domain placeholders. Use `--template widget`, `hello`, or `http-api` only when that narrower profile is intentional.
+`noodle init my-app` defaults to an embedded-first SaaS profile: managed website assistant, operator-bound `ASSISTANT_ORIGIN`, context-provider read, MCP App UI, resource, prompt, state contract and branding. It installs pinned local tooling and verifies synthetic behavior; previews do not save customer changes. No placeholder IdP or handoff destination is enabled. Bind the application origin, then reuse the maintained host and customer-auth recipes and prove the real boundary. Use `--template widget`, `hello`, or `http-api` only when intentional.
 
 The default composition rule is: build the smallest useful conversational surface. Inline has one purpose, one primary action, and at most two visible actions. Use progressive disclosure or a later conversational turn for secondary detail; request fullscreen only when the user asks or the task genuinely needs it. Never use nested scrolling. At 280px and wider, the widget must remain one-column, readable, touch-safe, and free of horizontal overflow. Remove secondary chrome before shrinking essential content.
 

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

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

@@ -23,6 +23,7 @@ Use this ordered evidence ladder. Start at the last known passing layer or the l
 1. **Compile** — the TypeScript build and authoring import surface are valid.
 2. **Validate** — `noodle validate --json` accepts the Noodle contract.
 3. **Local smoke** — `noodle test --json` starts the local runtime. Open apps exercise MCP registration; customer-auth apps must instead pass the anonymous 401 plus exact protected-resource metadata boundary and report `interactiveRequired: true`.
+   To prove a safe read, explicitly supply `--tool <read_tool> --args <json>` or use `noodle tools call <read_tool> --args <json> --json`. These commands fail on protocol/tool errors, missing or incomplete results, and a declared output-schema mismatch. `input_required` is not completion: use Devtools for interactive input, never fabricate approval or retry an uncertain write.
 4. **Customer auth** — when customer auth is declared, run `noodle auth doctor src/server.ts --json` for metadata and JWKS readiness, then run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or representative safe read. The doctor does not prove that registration or token issuance succeeds; the authenticated request proves issuer, signature, stable audience, and exact-resource binding together.
 5. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
 6. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
@@ -53,7 +54,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 ## Recovery paths
 
 - Compile/validation: repair the exact import, schema, or reported path, then rerun that command without freeform changes.
-- Local boot/smoke: use the structured startup error to correct the effective target, config, or entrypoint before retrying.
+- Local boot/smoke: use all reported missing variable and secret names and the exact-target recovery commands together. Values stay outside the diagnostic. `error.detail.reason` identifies incomplete/failed operation evidence; RPC message/data and continuation state are deliberately not copied. A failed response does not prove a write was rolled back.
 - 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.

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.94.0 hash:379ab9f64878f1fe -->
+<!-- noodle-skill version:0.96.0 hash:379ab9f64878f1fe -->
 
 # wrapping-existing-applications
 

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

@@ -22,8 +22,9 @@
 ## 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>` emits a starter `server.ts` from a spec. Use it when the user provides an OpenAPI document.
+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.
 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.
 
 ## Fit check
@@ -393,20 +394,14 @@ Compute `run` functions are serialized and sandboxed: no imports, no closure cap
 
 ## Tests
 
-Use Vitest for app-local tests. The generated `npm test` command scans only the project-owned `test/` directory; skill-local example tests are reference material, not part of the app suite. Keep fixtures project-local; do not import from `examples/`. A minimum test suite imports the default server, checks the intended definitions compile, then lets `noodle test --json` perform the loopback MCP smoke.
+Start from the generated `test/server.test.ts`, not a blank test file. `npm test` runs `vitest run --dir test` over the project-owned `test/` directory; skill-local example tests are reference material. The generated suite compiles the actual source/view, lists tools, asserts a representative result and rejects invalid input. It copies source into temporary fixture storage and uses synthetic configuration, never customer secrets or saved hosted targets. The HTTP profile proves one local backend read and zero extra calls for invalid input.
 
-```ts
-import { describe, expect, it } from 'vitest';
-import app from '../src/server.js';
-
-describe('server', () => {
-  it('declares the expected tool surface', () => {
-    expect(app.name).toBe('support_assistant');
-  });
-});
+```sh
+npm test
+npm run agent:check
 ```
 
-After focused tests pass, run `noodle validate --json`, `noodle test --json`, and then `noodle dev` for interactive local verification.
+Adapt the representative arguments and assertions when business contracts change; keep invalid-input and authorization cases. A name/export assertion or `noodle test --json` without `--tool` proves no useful call. After fixture tests pass, bind the real local configuration, run an authorized representative read, and use `noodle dev` for interactive checks. Never use a production mutation or fixture success as customer-readiness evidence.
 
 ## Secrets and variables
 

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.94.0 hash:13ddce01769caae4 -->
+<!-- noodle-skill version:0.96.0 hash:13ddce01769caae4 -->
 
 # Noodle Seed
 

package/skills/codex/authoring-mcp-servers/SKILL.md

@@ -3,7 +3,7 @@ name: authoring-mcp-servers
 description: "Use when creating or extending a headless Noodle Seed MCP server, tool, resource, prompt, or typed model-facing capability."
 ---
 
-<!-- noodle-skill version:0.94.0 hash:dd57a15df15d10b2 -->
+<!-- noodle-skill version:0.96.0 hash:dd57a15df15d10b2 -->
 
 # authoring-mcp-servers
 

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

@@ -22,8 +22,9 @@
 ## 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>` emits a starter `server.ts` from a spec. Use it when the user provides an OpenAPI document.
+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.
 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.
 
 ## Fit check
@@ -393,20 +394,14 @@ Compute `run` functions are serialized and sandboxed: no imports, no closure cap
 
 ## Tests
 
-Use Vitest for app-local tests. The generated `npm test` command scans only the project-owned `test/` directory; skill-local example tests are reference material, not part of the app suite. Keep fixtures project-local; do not import from `examples/`. A minimum test suite imports the default server, checks the intended definitions compile, then lets `noodle test --json` perform the loopback MCP smoke.
+Start from the generated `test/server.test.ts`, not a blank test file. `npm test` runs `vitest run --dir test` over the project-owned `test/` directory; skill-local example tests are reference material. The generated suite compiles the actual source/view, lists tools, asserts a representative result and rejects invalid input. It copies source into temporary fixture storage and uses synthetic configuration, never customer secrets or saved hosted targets. The HTTP profile proves one local backend read and zero extra calls for invalid input.
 
-```ts
-import { describe, expect, it } from 'vitest';
-import app from '../src/server.js';
-
-describe('server', () => {
-  it('declares the expected tool surface', () => {
-    expect(app.name).toBe('support_assistant');
-  });
-});
+```sh
+npm test
+npm run agent:check
 ```
 
-After focused tests pass, run `noodle validate --json`, `noodle test --json`, and then `noodle dev` for interactive local verification.
+Adapt the representative arguments and assertions when business contracts change; keep invalid-input and authorization cases. A name/export assertion or `noodle test --json` without `--tool` proves no useful call. After fixture tests pass, bind the real local configuration, run an authorized representative read, and use `noodle dev` for interactive checks. Never use a production mutation or fixture success as customer-readiness evidence.
 
 ## Secrets and variables
 

package/skills/codex/authoring-mcp-servers/references/build-an-mcp-server.md

@@ -26,7 +26,7 @@ Establish only the inputs needed for the requested stopping point. Follow `refer
 5. **Author in TypeScript.** Follow `references/authoring-workflow.md` for connector and flow patterns, `references/tool-design.md` for the model-facing tool surface, and `references/sdk-surface.md` for exact builders. These are this route’s complete canonical support set; use the router lookup catalog only when observed evidence names a different concern.
    MCP protocol versions are platform-owned and negotiated automatically at the serving endpoint. Do not add protocol-version settings to server options, `noodle.json`, app manifests, or deployment configuration.
 6. **Validate and repair.** Run `noodle validate --json`. Parse `error.errors[]`, repair the cited `path`, and rerun validation. Consult the lookup catalog only for the specific reported error code; do not open another reference speculatively.
-7. **Run the local smoke.** After validation succeeds, run `noodle test --json` and repair any failure at that evidence layer.
+7. **Run local behavior.** Start from the generated tests and run `npm test`: compile, tools/list, representative result and invalid-input rejection. `noodle test --json` without `--tool` is registration-only; repair failures before claiming a working capability.
 8. **Prove external behavior.** For connector-backed reads, set credentials through the effective local target and run a safe representative `noodle tools call`. Confirm populated mapped fields from real output, not merely successful registration.
 9. **Stop at the requested boundary.** Do not add an App, host test, hosted environment, publication work, or deployment unless the user requested that outcome. Deploy only when the selected route or the user explicitly requires it.
 
@@ -36,7 +36,7 @@ Report evidence as a ladder and claim only levels actually exercised:
 
 - **Authoring:** the requested TypeScript behavior exists with typed inputs and outputs, and the product-guide decision and reason are recorded.
 - **Compilation:** `noodle validate --json` returned success.
-- **Local smoke:** `noodle test --json` returned success.
+- **Local behavior:** the generated/adapted suite passed a representative call and a negative case. Synthetic fixtures prove only their configured behavior.
 - **Connector reality:** a representative safe read via `noodle tools call` returned populated mapped fields. This is required for connector-backed work.
 - **Higher levels:** explicitly report host, deployment, and production checks as not run unless they were separately requested and evidenced.
 

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

package/skills/codex/building-mcp-apps/references/build-an-mcp-app.md

@@ -25,14 +25,14 @@ Before implementation, capture a short design spec: target user, conversational
 4. **Preserve fallback.** Every tool that launches a widget must still return useful text without the widget, so unsupported hosts and failed rendering remain usable.
 5. **Decide product-guide coverage.** Record the required product-guide decision and its reason, then use `references/product-agent-guides.md` as the canonical selection and authoring guidance.
 6. **Author and wire the App contract.** Follow `references/widgets-and-apps.md` for the canonical component guidance, view registration, hooks, state, CSP, tool visibility, and output shaping. Keep tool effects and confirmation semantics correct independently of the UI.
-7. **Validate the local artifact.** Run `noodle validate --json`, `noodle test --json`, and `noodle check --json`. Repair failures at the layer that produced them.
+7. **Validate the local artifact.** Run the generated/adapted `npm test`, `noodle validate --json` and `noodle check --json`. Prove a representative result and negative case, not just registration. Synthetic preference previews do not save; replace their backend seam and verify the authorized effect before showing success.
 8. **Inspect the experience.** Run `noodle devtools` and verify loading, empty, error, success, responsive layout, focus/keyboard behavior, and the text fallback.
 9. **Escalate evidence only on request.** Run a host test only when the user requested host verification. Run host-specific compliance only when preparing that host submission; select the exact host-testing or compliance entry from the router lookup catalog only after that evidence level is explicitly requested.
 
 ## Verification evidence
 
 - **Product:** the design spec states the user benefit, UI fit decision, and product-guide decision with its reason.
-- **Server:** `noodle validate --json` and `noodle test --json` succeeded.
+- **Server:** compilation, a representative call and negative input/authorization cases passed; report whether fixtures or a real authorized backend were used.
 - **App contract:** `noodle check --json` succeeded.
 - **Local UX:** `noodle devtools` exercised the relevant states and the useful text fallback without the widget.
 - **Host/compliance:** report each requested host or compliance check with its evidence; report every unperformed higher level as not run.

package/skills/codex/building-mcp-apps/references/widgets-and-apps.md

@@ -18,7 +18,7 @@ Use `tool(name, { description, input, output, fulfil, view })` for a model-visib
 
 Generated widgets, official examples, and agent-authored MCP Apps must start with `@noodleseed/one/react` primitives and semantic tokens. Custom React/CSS or third-party components remain valid when the kit lacks the required behavior or the developer explicitly requests them.
 
-`noodle init my-app` defaults to the SaaS profile: federated OIDC placeholders, one explicit context-provider tool, MCP App UI, resource, prompt, state contract, branding, handoff, and embedded assistant. Begin by replacing the IdP/audience/domain placeholders. Use `--template widget`, `hello`, or `http-api` only when that narrower profile is intentional.
+`noodle init my-app` defaults to an embedded-first SaaS profile: managed website assistant, operator-bound `ASSISTANT_ORIGIN`, context-provider read, MCP App UI, resource, prompt, state contract and branding. It installs pinned local tooling and verifies synthetic behavior; previews do not save customer changes. No placeholder IdP or handoff destination is enabled. Bind the application origin, then reuse the maintained host and customer-auth recipes and prove the real boundary. Use `--template widget`, `hello`, or `http-api` only when intentional.
 
 The default composition rule is: build the smallest useful conversational surface. Inline has one purpose, one primary action, and at most two visible actions. Use progressive disclosure or a later conversational turn for secondary detail; request fullscreen only when the user asks or the task genuinely needs it. Never use nested scrolling. At 280px and wider, the widget must remain one-column, readable, touch-safe, and free of horizontal overflow. Remove secondary chrome before shrinking essential content.
 

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.94.0 hash:8020811f1769c538 -->
+<!-- noodle-skill version:0.96.0 hash:8020811f1769c538 -->
 
 # connecting-apis-to-mcp
 

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

@@ -22,8 +22,9 @@
 ## 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>` emits a starter `server.ts` from a spec. Use it when the user provides an OpenAPI document.
+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.
 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.
 
 ## Fit check
@@ -393,20 +394,14 @@ Compute `run` functions are serialized and sandboxed: no imports, no closure cap
 
 ## Tests
 
-Use Vitest for app-local tests. The generated `npm test` command scans only the project-owned `test/` directory; skill-local example tests are reference material, not part of the app suite. Keep fixtures project-local; do not import from `examples/`. A minimum test suite imports the default server, checks the intended definitions compile, then lets `noodle test --json` perform the loopback MCP smoke.
+Start from the generated `test/server.test.ts`, not a blank test file. `npm test` runs `vitest run --dir test` over the project-owned `test/` directory; skill-local example tests are reference material. The generated suite compiles the actual source/view, lists tools, asserts a representative result and rejects invalid input. It copies source into temporary fixture storage and uses synthetic configuration, never customer secrets or saved hosted targets. The HTTP profile proves one local backend read and zero extra calls for invalid input.
 
-```ts
-import { describe, expect, it } from 'vitest';
-import app from '../src/server.js';
-
-describe('server', () => {
-  it('declares the expected tool surface', () => {
-    expect(app.name).toBe('support_assistant');
-  });
-});
+```sh
+npm test
+npm run agent:check
 ```
 
-After focused tests pass, run `noodle validate --json`, `noodle test --json`, and then `noodle dev` for interactive local verification.
+Adapt the representative arguments and assertions when business contracts change; keep invalid-input and authorization cases. A name/export assertion or `noodle test --json` without `--tool` proves no useful call. After fixture tests pass, bind the real local configuration, run an authorized representative read, and use `noodle dev` for interactive checks. Never use a production mutation or fixture success as customer-readiness evidence.
 
 ## Secrets and variables
 

package/skills/codex/connecting-apis-to-mcp/references/connect-an-api.md

@@ -198,7 +198,7 @@ model" section of `references/authoring-workflow.md`.
 
 ### Set the secret for local runs
 
-Local `dev`, smoke commands, secrets, and variables resolve one effective target: explicit flags, then the project link, then the saved CLI target, then local defaults. Set the secret through that same target:
+Local authoring resolves explicit coordinates, then the complete project link, then deterministic local defaults; saved global coordinates do not redirect an unlinked project. Follow the diagnostic’s exact-target commands from the project directory for every missing secret and variable:
 
 ```sh
 # Canonical: writes to the effective local environment used by dev/test/devtools:
@@ -215,7 +215,7 @@ Scoped local values live in `./.env.noodle`; the exact project-root `.env` is a
 
 ### Prove real output
 
-`noodle validate` / `noodle test` prove a connector tool *compiles and registers* — not that its
+`noodle validate` / `noodle test` without `--tool` prove a connector tool *compiles and registers* — not that its
 mapping returns data. With the secret set, run a live read: `noodle tools call <read_tool> --args
 '{…}'` executes the connector against the real API in-process. Confirm the mapped fields are populated,
 not `undefined`; if they are empty, distinguish a legitimate empty result from a missing or incorrect mapping, fix `${response…}` paths against the real payload when needed, and re-run.

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

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

@@ -23,6 +23,7 @@ Use this ordered evidence ladder. Start at the last known passing layer or the l
 1. **Compile** — the TypeScript build and authoring import surface are valid.
 2. **Validate** — `noodle validate --json` accepts the Noodle contract.
 3. **Local smoke** — `noodle test --json` starts the local runtime. Open apps exercise MCP registration; customer-auth apps must instead pass the anonymous 401 plus exact protected-resource metadata boundary and report `interactiveRequired: true`.
+   To prove a safe read, explicitly supply `--tool <read_tool> --args <json>` or use `noodle tools call <read_tool> --args <json> --json`. These commands fail on protocol/tool errors, missing or incomplete results, and a declared output-schema mismatch. `input_required` is not completion: use Devtools for interactive input, never fabricate approval or retry an uncertain write.
 4. **Customer auth** — when customer auth is declared, run `noodle auth doctor src/server.ts --json` for metadata and JWKS readiness, then run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or representative safe read. The doctor does not prove that registration or token issuance succeeds; the authenticated request proves issuer, signature, stable audience, and exact-resource binding together.
 5. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
 6. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
@@ -53,7 +54,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 ## Recovery paths
 
 - Compile/validation: repair the exact import, schema, or reported path, then rerun that command without freeform changes.
-- Local boot/smoke: use the structured startup error to correct the effective target, config, or entrypoint before retrying.
+- Local boot/smoke: use all reported missing variable and secret names and the exact-target recovery commands together. Values stay outside the diagnostic. `error.detail.reason` identifies incomplete/failed operation evidence; RPC message/data and continuation state are deliberately not copied. A failed response does not prove a write was rolled back.
 - 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.

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

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

@@ -22,8 +22,9 @@
 ## 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>` emits a starter `server.ts` from a spec. Use it when the user provides an OpenAPI document.
+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.
 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.
 
 ## Fit check
@@ -393,20 +394,14 @@ Compute `run` functions are serialized and sandboxed: no imports, no closure cap
 
 ## Tests
 
-Use Vitest for app-local tests. The generated `npm test` command scans only the project-owned `test/` directory; skill-local example tests are reference material, not part of the app suite. Keep fixtures project-local; do not import from `examples/`. A minimum test suite imports the default server, checks the intended definitions compile, then lets `noodle test --json` perform the loopback MCP smoke.
+Start from the generated `test/server.test.ts`, not a blank test file. `npm test` runs `vitest run --dir test` over the project-owned `test/` directory; skill-local example tests are reference material. The generated suite compiles the actual source/view, lists tools, asserts a representative result and rejects invalid input. It copies source into temporary fixture storage and uses synthetic configuration, never customer secrets or saved hosted targets. The HTTP profile proves one local backend read and zero extra calls for invalid input.
 
-```ts
-import { describe, expect, it } from 'vitest';
-import app from '../src/server.js';
-
-describe('server', () => {
-  it('declares the expected tool surface', () => {
-    expect(app.name).toBe('support_assistant');
-  });
-});
+```sh
+npm test
+npm run agent:check
 ```
 
-After focused tests pass, run `noodle validate --json`, `noodle test --json`, and then `noodle dev` for interactive local verification.
+Adapt the representative arguments and assertions when business contracts change; keep invalid-input and authorization cases. A name/export assertion or `noodle test --json` without `--tool` proves no useful call. After fixture tests pass, bind the real local configuration, run an authorized representative read, and use `noodle dev` for interactive checks. Never use a production mutation or fixture success as customer-readiness evidence.
 
 ## Secrets and variables
 

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

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

@@ -22,8 +22,9 @@
 ## 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>` emits a starter `server.ts` from a spec. Use it when the user provides an OpenAPI document.
+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.
 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.
 
 ## Fit check
@@ -393,20 +394,14 @@ Compute `run` functions are serialized and sandboxed: no imports, no closure cap
 
 ## Tests
 
-Use Vitest for app-local tests. The generated `npm test` command scans only the project-owned `test/` directory; skill-local example tests are reference material, not part of the app suite. Keep fixtures project-local; do not import from `examples/`. A minimum test suite imports the default server, checks the intended definitions compile, then lets `noodle test --json` perform the loopback MCP smoke.
+Start from the generated `test/server.test.ts`, not a blank test file. `npm test` runs `vitest run --dir test` over the project-owned `test/` directory; skill-local example tests are reference material. The generated suite compiles the actual source/view, lists tools, asserts a representative result and rejects invalid input. It copies source into temporary fixture storage and uses synthetic configuration, never customer secrets or saved hosted targets. The HTTP profile proves one local backend read and zero extra calls for invalid input.
 
-```ts
-import { describe, expect, it } from 'vitest';
-import app from '../src/server.js';
-
-describe('server', () => {
-  it('declares the expected tool surface', () => {
-    expect(app.name).toBe('support_assistant');
-  });
-});
+```sh
+npm test
+npm run agent:check
 ```
 
-After focused tests pass, run `noodle validate --json`, `noodle test --json`, and then `noodle dev` for interactive local verification.
+Adapt the representative arguments and assertions when business contracts change; keep invalid-input and authorization cases. A name/export assertion or `noodle test --json` without `--tool` proves no useful call. After fixture tests pass, bind the real local configuration, run an authorized representative read, and use `noodle dev` for interactive checks. Never use a production mutation or fixture success as customer-readiness evidence.
 
 ## Secrets and variables