@noodleseed/agent-kit 0.94.0 → 0.96.0

package/skills/codex/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/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/references/embedded-assistant.md

@@ -4,6 +4,7 @@
 
 - Architecture
 - Select the architecture before code
+- Install into the existing application
 - Author and validate
 - Product workflow guidance
 - Customize the presentation
@@ -63,6 +64,20 @@ Use the existing host framework and its package manager. Recommend the managed r
 
 The architecture brief must state the selected topology, why it fits the named user and job, the two code owners and two local processes, credential and identity flow, routing authority, model owner, files expected to change, and the first requested evidence boundary. If identity/session ownership, exact origin, tenant-routing authority, model ownership, or evidence target is unavailable, return a blocked architecture brief naming the missing owner or decision and do not edit either codebase.
 
+## Install into the existing application
+
+Configure or reuse an existing capability before generating files. Public embedding uses the existing script or embed ID and needs no customer backend session/config route. Reuse application APIs and business functions; generate a thin handler only where the approved architecture identifies a missing stable boundary.
+
+For a supported host, first run `noodle assistant embed --framework nextjs --surface public --dry-run --json` in the customer application, substituting `authenticated` or `mixed` only for the selected surface. Read the returned recipe applicability, applicationSeams, generated contents/hashes, skipped conflicts and nextSteps. The output is an installation plan, not permission to change the repository.
+
+For the documented non-Node backend/static-frontend authenticated profile, discover the framework choice through `noodle commands --json` and follow the linked framework guide below. The installer supplies a session view, a fail-closed identity seam, real CSRF-enforced request tests, a browser wrapper and exact-destination CSRF transport tests. Keep the existing package managers, authentication middleware and same-origin proxy. Pass the existing CSRF token and user/tenant principalKey to the wrapper; the managed element supports injected fetch, so preserving CSRF does not require a custom renderer or Node production server. Unsupported combinations use the neutral contract, not a claimed qualified profile.
+
+Once local changes are authorized, rerun without `--dry-run`; never add `--force` to resolve a conflict automatically. Read the installed `NOODLE-INTEGRATION.md` and newly installed project skill before editing. Implement only the named session/business/mount seams and preserve the host framework, package manager, login and authorization. Mixed mode also requires an application-owned login transaction; the generated callback does not implement or verify that transaction.
+
+Use generated tests and independently maintained acceptance cases at the actual customer boundary. A static host check, a mock test or installed files cannot prove application authorization or production browser behavior. Missing identities, sandbox access, customer approval or a reachable service remain unverified. Record the exact application/Noodle revisions, package versions and environment for observed evidence; rerun affected checks after changes.
+
+Unsupported hosts use the framework-neutral integration contract below; do not claim they received a generated, qualified framework profile. Keep direct MCP and headless projections on the same TypeScript source, and preserve their separate identity requirements.
+
 ## Author and validate
 
 `noodle init` and `noodle init --template widget` deliberately produce credential-free MCP Apps. Add an assistant declaration only when the product explicitly includes a customer-hosted assistant; do not make ordinary external-host widgets depend on model-provider settings.
@@ -143,6 +158,16 @@ The sign-in card renders on the same themed chrome as every proposal card and fo
 
 #### Complete mixed-mode handoff
 
+For a small SaaS onboarding flow, first read the bundled [stateful-draft example](../examples/stateful-draft/README.md). Compose the existing capabilities; do not introduce an onboarding platform API, workflow engine, research pipeline, or second identity provider.
+
+Start from one useful result the visitor can see before signup. Ask only for missing information, one short question at a time. Show an editable preview, and offer an account only when it unlocks a meaningful next step. Keep the ordinary signup route available. Research and document parsing are optional enrichment, never required because the flow is conversational.
+
+Use a finite-TTL caller state handle only if the draft needs server persistence. Opt it into `claimOnAuthentication` when it should move to the verified account. An explicit typed read tool supplies the current revision; a typed patch tool sends that revision and the complete reviewed value. Widget state is a display cache, never proof of a save. A failed or missing result must not increment the revision, mark the draft saved, or silently retry a conflicting write.
+
+Keep the final business action in the customer API. Map the reviewed draft to its existing create/update operation after authentication, with confirmation and the backend’s existing authorization and idempotency. Ticket adoption transfers temporary state, not a CRM record or completed onboarding.
+
+Prove this journey before calling it ready: useful anonymous preview; actual saved state; cancelled/expired signup; verified signup with the same draft; a destination conflict without an automatic merge; and no business write merely because login succeeded. A synthetic login demonstrates the integration shape but is not evidence that the customer identity system is connected.
+
 1. **Capture the ticket.** The widget raises `assistant-sign-in-requested` with a single-use `signInTicket`. POST it to the host application same-origin backend and bind it to the short-lived login transaction; keep it out of query strings, logs, analytics, and durable browser storage.
 2. **Use the existing login.** Send the visitor through the host application full-page redirect for sign-in or sign-up. Noodle never becomes the customer identity provider.
 3. **Elevate on the backend.** After authentication, recover the bound ticket and call `createAssistantSession({ ..., signInTicket })` with the verified user, server-owned routing, backend client credentials, and the exact **origin the conversation will continue on**. The allowed destination may differ from the anonymous marketing origin; successful elevation rebinds the session to it.
@@ -246,39 +271,20 @@ The doctor reads `NOODLE_ASSISTANT_CLIENT_ID` / `NOODLE_ASSISTANT_CLIENT_SECRET`
 
 Read the customer repository lockfile or `packageManager` field and install `@noodleseed/assistant` with that existing package manager; never introduce a second lockfile.
 
-Create an authenticated same-origin backend route:
+Use the installed same-origin route and `createAssistantSessionHandler` from `@noodleseed/assistant/server`; do not regenerate guards, JSON parsing or token-exchange infrastructure. The only identity seam is `authenticateAssistantRequest` in `lib/noodle-assistant-auth.ts`.
 
-The route must return a JSON `401` for a signed-out caller rather than an HTML login redirect, require JSON, and compare the request against the exact configured Origin before exchange. The managed renderer sends same-origin cookies but does not invent an application CSRF token. Treat JSON plus exact Origin as the minimum cookie/CSRF boundary; when the host keeps token-based CSRF middleware, use the DOM-free client with an injected `fetch` that supplies the token instead of exempting the route. Resolve claims and connector routes from the authenticated user and server-owned membership only.
+The route must return a JSON `401` for a signed-out caller rather than an HTML login redirect, require JSON, and compare the request against the exact configured Origin before exchange. The managed renderer sends same-origin cookies but does not invent an application CSRF token. Preserve the host token-based CSRF middleware: inject a same-origin-only token fetch into the managed element before mounting, as the Django/Vue profile does; a custom renderer is not required. Invalid CSRF may correctly fail before authentication. Resolve claims and connector routes from the authenticated user and server-owned membership only.
 
 For the complete framework-neutral server-to-server HTTP exchange in a non-Node host, link to the [Django and Vue guide](https://docs.noodleseed.dev/docs/guides/embedded-assistant-django-vue); keep its framework-specific middleware and mounting mechanics there rather than copying them into agent instructions.
 
-```ts
-import { createAssistantSession } from "@noodleseed/assistant/server";
-
-export async function POST(request: Request) {
-  const user = await requireCurrentUser(request);
-  const { context } = await request.json();
-  const session = await createAssistantSession({
-    serviceUrl: process.env.NOODLE_SERVICE_URL!,
-    clientId: process.env.NOODLE_ASSISTANT_CLIENT_ID!,
-    clientSecret: process.env.NOODLE_ASSISTANT_CLIENT_SECRET!,
-    origin: process.env.PUBLIC_APP_ORIGIN!,
-    user: {
-      id: user.id,
-      email: user.email,
-      roles: user.roles,
-      scopes: user.scopes,
-    },
-    context,
-    // Saved, backend-verified user preferences outrank browser hints.
-    preferences: { locale: user.locale, timeZone: user.timeZone },
-  });
-  return Response.json(session);
-}
-```
+Return `AssistantSessionIdentity | null` from the adapter. Null means signed out; service failure must throw rather than masquerade as signed out. Derive `user`, claims, preferences and routes from the existing verified session/membership. The maintained handler owns exact-Origin/JSON checks, bounded flat context, no-store JSON failures, a 15-second deadline, no redirects and no exchange retries. For mixed-mode continuation, return a `signInTicket` only from the backend-bound login transaction; never take it directly from browser JSON.
+
+For saved presentation preferences, return `preferences: { locale: user.locale, timeZone: user.timeZone }` beside the verified `user`. Omit unknown values; browser hints are not verified account preferences.
 
 Authenticate before exchange. Pass backend-verified `user.roles` and OAuth-style `user.scopes` separately; they govern the same per-tool authorization rules as verified MCP bearer claims. Source `origin` from trusted server configuration or strictly match the request origin against the same exact allowlist; never accept an arbitrary request header. Treat page context as untrusted model context, never authorization. Forward the helper response unchanged.
 
+Run the generated `test/noodle-assistant.test.ts` with the application's Vitest runner (add the dev dependency using its existing package manager if absent). It tests the real generated route with synthetic identities. Separately exercise the real session function with signed-out, tenant-A, tenant-B and authorized fixtures before claiming integration proof. A green mock suite does not prove customer authorization.
+
 `serviceUrl` is the Noodle Seed control-plane base URL: the value `noodle assistant clients create` prints, also stored as `serviceUrl` in `deployment.json`. It is NOT the deployment MCP endpoint (`url`, which ends in `/v1/mcp` and rejects session exchange). Never probe or guess endpoints with real credentials.
 
 ### Route customer endpoints from the backend
@@ -765,7 +771,7 @@ noodle assistant embed --check --json
 noodle assistant embed --check --json --require-env EXAMPLE_DELEG_CLIENT_SECRET
 ```
 
-The check reports only required and missing environment names, never their values. Pass `--surface public|mixed|authenticated` to match the deployment: `public` drops the backend client id/secret requirement (a public embed has neither), and `public`/`mixed` additionally require `script-src` — the one directive whose failure runs no widget code at all, so nothing can report it from inside the page. CSP directives verify against the service origin exactly, via the env placeholder, or through a covering wildcard (`https://*.example.com`); a dynamic expression is marked unverified instead of guessed. Additional `--require-env` names are application-owned; `--env-alias NAME=HOST_NAME` follows a host repo that names an env var differently.
+The check reports required and missing environment names, never their values. Use the exact command in an installed NOODLE-INTEGRATION.md, including its aliases and additional names, with the host environment exported; the CLI does not load application dotenv files. Pass `--surface public|mixed|authenticated` to match the deployment: `public` needs no backend client credentials. Public script-tag mounts need the service in `script-src`; the generated bundled React mount needs only `connect-src` and `frame-src` for that service. Unknown public mounts retain the conservative script check. CSP verifies an exact service origin, an env placeholder or a covering wildcard; dynamic expressions stay unverified. `--require-env` adds application-owned names and `--env-alias NAME=HOST_NAME` follows existing host naming.
 
 Read `evidence.levels` in order and stop at `evidence.firstUnproven`:
 

package/skills/codex/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/codex/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/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/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/codex/verifying-mcp-delivery/SKILL.md

@@ -3,7 +3,7 @@ name: verifying-mcp-delivery
 description: "Use when proving a Noodle Seed MCP project works at a named compile, local, connector, App, host, deployment, or production evidence level."
 ---
 
-<!-- noodle-skill version:0.94.0 hash:292253cbaed9a3c5 -->
+<!-- noodle-skill version:0.96.0 hash:292253cbaed9a3c5 -->
 
 # verifying-mcp-delivery
 

package/skills/codex/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/codex/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/codex/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