@noodleseed/agent-kit 0.34.0 → 0.35.0

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

@@ -0,0 +1,52 @@
+# Outcome
+
+Deliver an MCP App whose visual interaction gives the user a concrete benefit beyond a good text response, while preserving useful model-visible output when the widget is unavailable.
+
+## Use when
+
+- The user asks for an MCP App, widget, interactive card, visual workflow, or host-visible UI.
+- Comparison, selection, progress, editing, confirmation, or another visual interaction materially improves the conversational job.
+
+## Do not use when
+
+- A concise text or structured tool result fully serves the user. UI must earn its place.
+- The requested task is a headless server, API connector, diagnosis, deployment, or publication with no UI change; select that route.
+- The agent lacks the product inputs needed to explain who benefits, what action the UI enables, and what happens without it.
+
+## Required inputs
+
+Before implementation, capture a short design spec: target user, conversational job, explicit user benefit, information hierarchy, primary interaction, states (loading/empty/error/success), model-visible result, widget-only data, and useful text fallback. Use `references/experience-design.md` for the deeper product-design questions only when needed.
+
+## Workflow
+
+1. **Pass the UI fit check.** State why a visual interaction is better than text for this request. If there is no defensible user benefit, keep the capability headless and stop the App route.
+2. **Agree on the design spec.** Describe the smallest complete experience and its states before writing the component. Avoid recreating a full dashboard or website inside the conversation.
+3. **Define the output boundary.** Keep concise facts and action results model-visible. Put presentation-heavy or interactive widget data in the widget-only channel. The model must not depend on opaque UI state to continue the conversation.
+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. **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.
+6. **Validate the local artifact.** Run `noodle validate --json`, `noodle test --json`, and `noodle check --json`. Repair failures at the layer that produced them.
+7. **Inspect the experience.** Run `noodle devtools` and verify loading, empty, error, success, responsive layout, focus/keyboard behavior, and the text fallback.
+8. **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 and the UI fit decision.
+- **Server:** `noodle validate --json` and `noodle test --json` succeeded.
+- **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.
+
+## Recovery paths
+
+- Weak UI fit: remove the widget and ship the stronger headless result, or narrow the visual interaction to the one decision it improves.
+- App check failure: repair the cited view, metadata, output, CSP, or accessibility issue and rerun `noodle check --json` before reopening devtools.
+- Blank or stale widget: verify the tool returns the intended widget data, the view is registered, and state derives from supported hooks rather than hidden global state.
+- Model cannot continue without UI: move the essential facts into model-visible output and keep only presentation data widget-only.
+- Host-only mismatch: record local checks as passed, isolate the host symptom, and select the host-testing lookup only for that observed host; do not rewrite a working local contract without host evidence.
+
+## Stop conditions
+
+- Stop complete at the locally requested boundary when product fit, server tests, App checks, devtools states, and text fallback are evidenced.
+- Stop before host connection, deployment, or submission unless the user requested that next evidence level.
+- Stop blocked when the required design decision, external data, credentials, or host access is unavailable; name the missing input and the exact next action.
+- Never claim host compatibility, directory compliance, or production behavior from local devtools evidence alone.

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

@@ -0,0 +1,54 @@
+# Outcome
+
+Deliver the smallest useful Noodle Seed MCP server that turns a real user intent into a safe, typed result. Author only the configured TypeScript entrypoint, normally `src/server.ts`; keep the public authoring surface TypeScript-only and never hand-author generated manifests or connector IR.
+
+## Use when
+
+- The user asks to create or extend a headless MCP server, tools, resources, prompts, or connector-backed behavior.
+- The requested result is primarily model-facing and does not require a widget or host-visible UI.
+
+## Do not use when
+
+- The primary outcome is an MCP App, widget, or visual interaction; select the App route.
+- The task is only to diagnose existing failures, deploy, publish, embed, or report feedback; select that dedicated route.
+- The idea has no conversational fit: static content, a dashboard, deep navigation, or a full existing app port should be narrowed to the few actions that are better said than clicked.
+
+## Required inputs
+
+Establish only the inputs needed for the requested stopping point. Follow `references/authoring-workflow.md` for the canonical discovery paths. Do not guess or invent a private schema, endpoint, authentication model, eligibility rule, or approval flow. If a required input is unavailable, state exactly what evidence is missing and stop before fabricating behavior.
+
+## Workflow
+
+1. **Confirm conversational fit.** Name one to three focused jobs where saying the request is easier than navigating the underlying system, and identify the data or action the model cannot provide by itself.
+2. **Define the product contract.** For each job, write the user phrase, the intent-shaped tool or resource, its minimal typed input, the useful output, read/write effect, and backing operation. Design for user intent, not a 1:1 API endpoint wrapper.
+3. **Choose the smallest implementation.** Use native tools, resources, or prompts for local/static behavior; add a connector only when external data or actions are required. Keep response output small and model-readable.
+4. **Author in TypeScript.** Follow `references/authoring-workflow.md` for connector and flow patterns 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.
+5. **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.
+6. **Run the local smoke.** After validation succeeds, run `noodle test --json` and repair any failure at that evidence layer.
+7. **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.
+8. **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.
+
+## Verification evidence
+
+Report evidence as a ladder and claim only levels actually exercised:
+
+- **Authoring:** the requested TypeScript behavior exists with typed inputs and outputs.
+- **Compilation:** `noodle validate --json` returned success.
+- **Local smoke:** `noodle test --json` returned success.
+- **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.
+
+## Recovery paths
+
+- Validation failure: fix each structured error at its reported path, rerun validation, then resume at the next unproven layer.
+- Tool registers but returns empty or `undefined` fields: inspect one sanitized real response, correct `${response...}` mappings, and rerun the same read.
+- Credential unavailable: verify `secret(...)` naming and the effective local target; never inline or print the secret.
+- Missing product input: ask for the smallest concrete example, schema, or rule that unblocks the selected job. Do not widen the build to compensate.
+- Repeated failure at the same layer: stop after two evidence-backed repair attempts with the same failure signature and report the command, sanitized error, evidence already proven, and exact next action.
+
+## Stop conditions
+
+- Stop complete when the requested behavior passes validation and local smoke, and every connector-backed read has real-output evidence.
+- Stop at the user's requested boundary; do not deploy unless the user requested deployment.
+- Stop blocked when progress requires unavailable credentials, private schemas, external approval, or a live write the user has not approved.
+- In the handoff, name what changed, what passed, what was not run, and any remaining risk without upgrading local evidence into a hosted or production claim.

package/skills/codex/references/connect-an-api.md

@@ -1,10 +1,13 @@
-# Connect a live API (you were given a key)
+# Outcome
 
-When the user hands you an API key or credentials, don't infer the data from documentation — docs
-drift. Probe the live API, learn the real shape, then encode it as a `connector`. The loop:
+Connect a real API to a focused MCP product using managed credentials, mappings derived from observed responses, and representative live-read evidence. A connector that merely compiles is not complete.
 
 ## Contents
 
+- Use when
+- Do not use when
+- Required inputs
+- Workflow
 - Secure the key first
 - Probe the live API
 - Model the connector from the observed shape
@@ -13,9 +16,30 @@ drift. Probe the live API, learn the real shape, then encode it as a `connector`
 - Design intent tools
 - Set the secret for local runs
 - Prove real output
-- Then build the app
+- Verification evidence
+- Recovery paths
+- Stop conditions
 
-## Secure the key first
+## Use when
+
+- The user provides credentials, a reachable API, or an OpenAPI document and wants real MCP behavior backed by it.
+- Existing connector behavior compiles but still needs proof against the actual service and data shape.
+
+## Do not use when
+
+- The task is a local/static MCP capability with no external data source.
+- The user only wants a widget, deployment, publication, or diagnosis unrelated to API behavior; select that route.
+- Required credentials or authority are unavailable. Do not bypass authentication or substitute fabricated payloads for live evidence.
+
+## Required inputs
+
+Identify the API base URL, authentication scheme, one representative safe read, the user intent it serves, and either an OpenAPI document or one sanitized example response. For writes, also establish the effect, a safe test target, and explicit user approval before any live write.
+
+Do not guess or invent a field, schema, endpoint, pagination contract, or authentication behavior. Documentation is a hypothesis until a representative live read confirms the response actually returned.
+
+## Workflow
+
+### Secure the key first
 
 Never inline or log the key. Have the user put it in an environment variable, then store it as a
 managed secret and reference it only as `secret(...)`:
@@ -28,7 +52,7 @@ noodle secrets set SOME_API_KEY --runtime local --from-env SOME_API_KEY   # same
 In `server.ts` the key is only ever `secret("SOME_API_KEY")` — keep the raw value out of code, tests,
 prompts, logs, and generated files.
 
-## Probe the live API
+### Probe the live API
 
 Learn the actual response shape empirically. Two ways — capture one real example response per endpoint
 you will use, and read its field names, nesting, array shapes, pagination, and id-vs-label fields:
@@ -40,7 +64,7 @@ you will use, and read its field names, nesting, array shapes, pagination, and i
   '${response}' }`), `noodle secrets set` the key, then `noodle tools call` it to see the real payload
   in-process.
 
-## Model the connector from the observed shape
+### Model the connector from the observed shape
 
 Encode the API as an HTTP connector, mapping only the fields you actually saw into a small typed
 `output`:
@@ -56,7 +80,7 @@ Encode the API as an HTTP connector, mapping only the fields you actually saw in
 The full connector shape, every `auth.kind`, and compute connectors are in
 `references/authoring-workflow.md`.
 
-## Return a list
+### Return a list
 
 Most real tools return a variable-length list (search results, a user’s tasks). Bind the **whole array** — a single `${response.path}` returns the referenced value verbatim, arrays included:
 
@@ -87,7 +111,7 @@ pagination: {
 response: { tasks: '${response.items}' },
 ```
 
-## Create, update, delete
+### Create, update, delete
 
 Pair the read/list with the mutations your intent tools need:
 - **Create / update** — `method: 'POST'` / `'PATCH'`; author the body as `request: { field: '${input.x}' }` (do not nest it under `body`). It is JSON by default; use `requestEncoding: 'form-urlencoded'` only when the API requires a URLSearchParams body. URL query params remain the operation-level `query: [...]` array.
@@ -117,14 +141,14 @@ close_task: {
 },
 ```
 
-## Design intent tools
+### Design intent tools
 
-Shape tools around what the user says, not 1:1 around endpoints. Pair an id-taking action with a
+Create intent-shaped tools around what the user says, not 1:1 around endpoints. Pair an id-taking action with a
 find/search operation that returns `{ id, label }` summaries so the model resolves text → id itself,
 and map each response to a few labelled fields the model can speak from. See the "Design tools for the
 model" section of `references/authoring-workflow.md`.
 
-## Set the secret for local runs
+### 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:
 
@@ -137,17 +161,33 @@ noodle secrets set SOME_API_KEY --runtime local --scope env --org <org> --app <a
 
 Local secrets live in `./.env.noodle` (never commit it). A required `secret(...)` or `variable(...)` that cannot resolve fails boot closed. `noodle tools call` / `noodle test` / `noodle dev` / `noodle devtools` stop before exposing an empty endpoint and print the exact effective target plus recovery command.
 
-## Prove real output
+### Prove real output
 
 `noodle validate` / `noodle test` 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, fix the `${response…}` paths against the real payload and re-run.
-Only run a live write if it is safe or the user approved it.
+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.
+Only run a live write after explicit user approval and when a safe test target and expected effect are known.
+
+## Verification evidence
+
+- **Credential path:** the raw credential remained in an environment variable and the managed `secret(...)` path for the same effective local target.
+- **Observed shape:** a representative safe live read established the real fields, nesting, arrays, pagination, and empty-result behavior used by the mapping.
+- **Local proof:** `noodle validate --json` and `noodle test --json` succeeded, then `noodle tools call` returned populated mapped fields or an intentionally verified empty result.
+- **Writes:** name the approval and safe target used, or report writes as not run.
+- **Hosted boundary:** local proof does not prove hosted credentials, deployment health, or host behavior. Report hosted checks as not run unless a separate requested route exercised them.
+
+## Recovery paths
+
+- Authentication failure: verify the connector auth kind, managed secret name, and effective local target without printing the credential.
+- Successful HTTP call with `undefined` fields: compare the mapping with one sanitized observed response, correct the path, and rerun the same read.
+- Legitimate empty result: test a second known query or record the empty case as intentional; do not rewrite a correct mapping merely to manufacture data.
+- Response too broad for the model: narrow it with response mapping, projection, or a separate compute connector; do not rely on a Zod output to strip runtime fields.
+- Repeated external failure: stop after bounded attempts and report the sanitized status, endpoint class, evidence already proven, and exact external action needed.
 
-## Then build the app
+## Stop conditions
 
-With real data flowing, design the experience (`references/experience-design.md`), add widgets where a
-UI genuinely helps (`references/widgets-and-apps.md`), and verify with `noodle check`. Deploy per
-`references/deploy-and-ops.md`, and set the same secret in the hosted environment with `noodle secrets
-set` before the first hosted call.
+- Stop complete when the representative safe read returns populated mapped fields or an intentionally verified empty result through the same effective local target.
+- Stop before a live write without explicit approval, a known effect, and a safe target.
+- Stop blocked when credentials, a reachable service, a representative input, or a required private schema is unavailable.
+- Do not continue into App design, deployment, or publication unless the user requested that next outcome; route to the corresponding primary playbook instead.

package/skills/codex/references/deploy-and-ops.md

@@ -1,89 +1,25 @@
-# Deploy and operations
+# Hosted mutation authorization
 
-## Contents
+> This route changes hosted or external state. Use it only when the current user request explicitly authorizes the exact mutation and target.
 
-- Authenticate
-- Link and target
-- Deploy and inspect
-- Installed Developer plugin handoff
-- Eject path (portable manifest)
-- Connect into a host
-- Access modes
-- Org and members
-- Config and observability
-- Agent-safe CLI recipes
-- Analytics
+## Route boundary
 
-## Authenticate
+- Select this route only for the exact hosted mutation the user requested.
+- Route inspection, diagnosis, preparation, validation, testing, and other read-only work to their read-only references. Those requests do not authorize a mutation.
+- Authentication, target binding, configuration, access changes, deployment, connection writes, and rollback are separate mutations. Authorization for one does not imply another.
 
-`noodle login` to authenticate with Noodle Seed Cloud, `noodle whoami` to confirm, `noodle logout` to clear credentials. Local commands (`dev`/`validate`/`test`) need none of this.
+## Authorization check
 
-## Link and target
+Before any mutation, require the current request to name both the action and its complete target. A mutation-capable target consists of an explicit organization, application, and environment. When the environment is absent, stop and ask for it instead of applying a default, reusing local state, or selecting a target implicitly.
 
-`noodle link --org <slug> --app <slug> [--env <slug>]` binds the directory to a target. Unlinked, `noodle deploy` uses your default org, the project name as the app, and `prod`. `noodle target show|set` inspects or changes the target.
+Do not broaden a request to prepare, inspect, diagnose, or validate into permission to authenticate, bind a target, change configuration or access, deploy, connect, submit, or roll back.
 
-## Deploy and inspect
+## Command and service contract
 
-`noodle deploy` deploys the server. Then `noodle open` (latest URL), `noodle status`, `noodle inspect` (metadata, no secrets), `noodle smoke` (readiness diagnostics), and `noodle rollback <deploymentId>` to revert.
+Use `references/cli-commands.md` as the generated command, flag, and exit-code contract. Consult the live command catalog before acting, and treat the service response as the authority for resulting hosted state. This reference intentionally does not duplicate operational command sequences, defaults, or status semantics.
 
-## Installed Developer plugin handoff
+## Evidence and stop conditions
 
-When this project was bootstrapped by the installed Noodle Developer plugin, preserve its managed launcher invocation for every local CLI command. After `deploy --json`, take the returned deployment ID to the connected remote `noodle-developer.inspect_deployment` tool. Use `noodle-developer.diagnose_app` only when the Cloud evidence needs diagnosis. Those tools inspect the selected organization and environment; they do not edit or replace the application source, which remains the coding agent's responsibility.
-
-## Eject path (portable manifest)
-
-`noodle export manifest [--output <file>]` compiles the entrypoint locally and emits the portable, vendor-neutral manifest JSON — no service, no login, no account. A Noodle app is just `src/server.ts` plus this manifest: the user can read it, diff it, and keep it.
-
-## Connect into a host
-
-Once deployed, register the server as a tool in a host with `noodle connect <host>` (`claude-code`, `codex`, `chatgpt`, `cursor`, `vscode`, `claude`, `inspector`) — it prints the exact config to paste.
-
-- **Claude Code / Claude Desktop** (verified) — add the `mcpServers` block, or one-shot `claude mcp add-json noodle-server '<json>'`:
-
-```json
-{
-  "mcpServers": {
-    "noodle-server": { "type": "https", "url": "https://<app>.mcp.noodleseed.dev" }
-  }
-}
-```
-
-- **Codex / Cursor / VS Code** — the same `mcpServers` block is emitted as a starting point (these hosts' config formats are not officially documented). Wiring a deployed Noodle server into Codex means registering that block in Codex's MCP config.
-- **ChatGPT / Claude.ai** — no config file: open the host's Settings → Connectors → Add custom connector, paste the MCP URL, then authenticate.
-- `noodle connect codex|claude-code --write` writes the project-local agent files (only these two targets).
-
-## Access modes
-
-`noodle access set owner-only|org-members|authenticated|customers` controls who can call the deployed server. Hosted access is identity-based; never add static data-plane keys.
-
-## Org and members
-
-`noodle orgs list|create` and `noodle members list|add|remove --org <slug>` manage organizations and membership.
-
-## Config and observability
-
-Manage runtime config with `noodle secrets` / `noodle variables` (scoped org/app/env). Operators use `noodle logs`, `noodle audit`, and `noodle policy` for logs, governance audit, and policy.
-
-## Agent-safe CLI recipes
-
-Use explicit flags in headless runs so commands never wait for a prompt:
-
-```sh
-noodle link --org acme --app support-assistant --env prod
-noodle secrets set CRM_TOKEN --scope env --org acme --app support-assistant --env prod --from-env CRM_TOKEN
-noodle secrets set CRM_CERT --scope env --org acme --app support-assistant --env prod --from-file ./cert.pem
-printf %s "$CRM_TOKEN" | noodle secrets set CRM_TOKEN --scope env --org acme --app support-assistant --env prod --from-stdin
-noodle variables set CRM_BASE_URL --scope env --org acme --app support-assistant --env prod --value https://crm.example.com
-noodle secrets list --scope env --org acme --app support-assistant --env prod --json
-noodle validate --json
-noodle test --json
-noodle deploy --json
-noodle smoke --json
-noodle agents doctor --json
-```
-
-`secrets resolve` is for local diagnostics only; do not print resolved values into prompts, logs, tests, or docs. Prefer `--from-env`, `--from-file`, or `--from-stdin` over inline `--value` for sensitive values. Variables may use `--value` when the value is non-secret.
-
-## Analytics (verify after deploy, debug errors)
-
-After a deploy gets traffic, verify with `noodle metrics --agent-output` — it returns a `health` verdict (`ok`/`attention`), a one-line summary, and `attention[]` items each carrying the exact next command. When a tool errors, drill in with `noodle events --tool <name> --json` (filters: `--status tool_error|mcp_error`, `--client <name>`); `noodle events --session <id> --json` replays one session chronologically. `--json` on both returns the full payload; human runs get the branded report. Two-tier errors: `tool_error` is recoverable (handed back to the model), `mcp_error` needs attention (protocol/timeout/internal). Wire edge-triggered webhooks on error share, error count, calls, or p95 latency with `noodle alerts add|list|remove|test`.
+- Stop before execution when the action or complete target is missing.
+- After an authorized mutation, report only the state evidenced by the command and service response.
+- Do not claim host behavior, production health, or successful external registration without direct evidence at that layer.

package/skills/codex/references/experience-design.md

@@ -126,7 +126,7 @@ The design phase produces up to three artifacts — worked gold-standard version
   architecture, demo scope, success metrics, and future enhancements — opening on the funnel-boundary
   line every scope debate resolves against.
 - **Wireframe** — the single-file HTML alignment artifact (anatomy above) with the embedded compliance
-  audit; see `references/chatgpt-compliance.md`.
+  audit; see `references/app-directory-compliance.md`.
 - **API contract** — when the partner's backend must be built or wrapped. Escalate: (1) the MCP
   tool→call-sequence map (always); (2) "Recommended API Shapes" — concrete request/response JSON per
   tool, including the hardest nested case; (3) a full OpenAPI spec for transactional apps. Contract

package/skills/codex/references/inspect-hosted.md

@@ -0,0 +1,26 @@
+# Inspect hosted state
+
+Read hosted evidence without changing target, credentials, configuration, access, host wiring, revisions, or directory state.
+
+## Use when
+
+- The user asks for hosted status, deployment metadata, health, logs, events, metrics, audit evidence, or diagnosis.
+- The request is inspect-only, diagnose-only, or asks whether an existing deployment works.
+
+## 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.
+
+## 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.
+4. When the installed Developer MCP is available, use its deployment inspection or diagnosis tool only for the selected org/app/env. Treat it as 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.
+
+## Stop conditions
+
+- Stop complete when the requested hosted fact is supported by current evidence and higher untested levels are named.
+- Stop blocked when existing access cannot read the target or the requested evidence requires a host/user journey unavailable in scope.
+- Stop for authorization when the next useful action would mutate local targeting, hosted state, host configuration, or directory state.

package/skills/codex/references/publishing.md

@@ -1,31 +1,29 @@
 # Publish to app directories
 
-Directory requirements evolve — treat this as the workflow map and verify against the host’s current submission docs before submitting.
+> Preparation is read-only unless the current user request explicitly authorizes the exact deploy, access change, host write, or submission target. A request to prepare must report missing readiness work and stop before mutation.
+
+Directory requirements evolve. Identify the requested directory first and verify its current official requirements before preparing directory-specific evidence.
 
 ## Contents
 
-- Readiness gate
-- ChatGPT apps directory
-- Claude connectors directory
+- Shared readiness gate
+- Directory-specific evidence
+- Submission boundary
 
-## Readiness gate
+## Shared readiness gate
 
 Before any submission:
 
-1. `noodle check --target chatgpt` must be clean — every widget needs `domain` (one https origin per app) and an exact `csp` (hosts require the CSP to list precisely the domains you fetch from).
-2. Audit tool responses in developer mode: run realistic prompts and strip anything not strictly needed — PII, internal identifiers (session/trace/request IDs, internal account IDs), and any secrets.
-3. The server must be deployed and publicly reachable: `noodle deploy`, confirm with `noodle open --print` and `noodle smoke`. Reviewers connect to the real endpoint — never submit a placeholder or loopback URL, and the access mode must not be `owner-only` (`noodle access set`).
-4. Polish the listing surface: tool descriptions, widget titles, and the `server` branding tokens are what reviewers and users see.
+Use `references/app-directory-compliance.md` as this route’s canonical shared compliance checklist.
+
+Prepare evidence for a reachable production MCP endpoint, accurate capability descriptions and schemas, useful fallback behavior, realistic positive and negative tests, data minimization, privacy disclosures, support ownership, and any interactive surface the directory will review.
 
-## ChatGPT apps directory
+## Directory-specific evidence
 
-Submit from the OpenAI developer dashboard (platform.openai.com → Apps):
+Read the selected directory’s current official submission documentation at review time. Record each additional requirement separately from the shared checklist, including listing fields, identity verification, test credentials, screenshots, policy declarations, review limits, and appeal or resubmission steps. Never project one directory’s requirements onto another.
 
-- Complete organization identity verification first (individual or business) — it is enforced at review time.
-- The submission form asks for the app name, logo, description, company and privacy policy URLs, MCP server URL and tool information, screenshots, test prompts with expected responses, and localization details.
-- One version may be published and one in review at a time; to revise a pending submission, cancel the review and resubmit rather than creating a new app.
-- Review combines automated checks and manual evaluation; rejections come with feedback — fix and resubmit, or reply to appeal. An approved app is also distributed as a Codex plugin.
+When a requirement cannot be verified from the selected directory’s current documentation or direct review evidence, mark it unknown instead of borrowing a rule from another host.
 
-## Claude connectors directory
+## Submission boundary
 
-Anthropic runs a connectors directory for Claude; submission goes through Anthropic’s published process (see the Anthropic connectors directory FAQ on support.claude.com). The same readiness gate applies: deployed public endpoint, clean `noodle check`, and graceful degradation where Apps rendering is unavailable.
+Preparation is read-only. Deployment, access changes, directory registration, and final submission each require explicit authorization for the exact target. Report remaining evidence gaps and stop when that authority or required directory access is absent.

package/skills/codex/references/verify-and-recover.md

@@ -0,0 +1,65 @@
+# Outcome
+
+Identify the first failing evidence layer, repair only that layer, rerun it, and report the highest level actually proven. A successful lower layer must never be presented as proof of a higher one.
+
+## Use when
+
+- The user asks to validate, test, diagnose, recover, or establish whether a local or hosted Noodle Seed project works.
+- A command, connector, App, host integration, deployment, or production check is failing or has uncertain evidence.
+
+## Do not use when
+
+- The primary request is to design or build a new product capability; select its build route and use this playbook only if evidence fails.
+- The user asks for a higher-risk external action rather than diagnosis. This route does not grant deployment, publication, live-write, or merge authority.
+
+## Required inputs
+
+Capture the requested evidence level, the exact command or user-visible symptom, sanitized machine output, the environment/target, and the last known passing layer. Do not broaden the goal beyond the level the user asked to prove.
+
+## Workflow
+
+Use this ordered evidence ladder. Start at the last known passing layer or the lowest plausible failure; never jump upward over an unproven dependency:
+
+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 and exercises registration.
+4. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
+5. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
+6. **Host** — the requested host connects, invokes the expected capability, and renders useful fallback/UI behavior.
+7. **Deploy** — the requested hosted revision and configuration exist and report healthy at the deployment layer.
+8. **Production health** — the live production endpoint and requested user journey are observed on the intended revision.
+
+For the first failing layer:
+
+1. Read the process exit code or status first. If machine JSON exists, parse it before reading human prose or editing files.
+2. For validation envelopes, inspect every `error.errors[]` item and repair the field at its reported `path`. Use `references/agent-contract.md` for the envelope and `references/compile-errors.md` for the named error code.
+3. Form one evidence-backed cause from the observed output. If the two canonical supports do not cover it, select one matching symptom from the router lookup catalog; do not scan every recovery path.
+4. Make the smallest in-scope repair. Do not freeform re-edit adjacent code, change credentials, redeploy, or add product behavior without evidence and authority.
+5. Rerun only the same evidence layer that failed. Once it passes, continue upward only to the user-requested level.
+6. Stop after two evidence-backed repair attempts with the same failure signature, or immediately when the next action requires new authority or external state.
+
+## Verification evidence
+
+Report a compact ledger for every exercised layer: command/action, target, result, and the evidence it establishes. Claim only the highest contiguous passing layer.
+
+- Compile success does not prove runtime behavior.
+- Validation and local smoke do not prove a real API mapping or credential path.
+- Local evidence does not prove hosted or host behavior.
+- Deployment existence does not prove production health or a user journey.
+- Report every requested but unperformed or blocked higher layer as not run, with the reason.
+
+## 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.
+- 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.
+- Repeated external failure: preserve passing evidence and report the sanitized failure, required authority or external state, owner, and exact next action.
+
+## Stop conditions
+
+- Stop complete when the user-requested evidence level and every dependency below it pass in the current target.
+- Stop blocked when progress requires credentials, approval, host access, deployment authority, production access, or an external-state change not available in scope.
+- Stop after two evidence-backed repair attempts with the same failure signature at one layer; do not hide repetition behind unrelated edits.
+- Never claim fixed or working without rerunning the failed layer, and never upgrade compile, local, deployment, or stale historical evidence into a stronger claim.

package/skills/claude-code/references/chatgpt-compliance.md

@@ -1,63 +0,0 @@
-# ChatGPT App compliance (pre-submission)
-
-`noodle check --target chatgpt` verifies the *metadata* prerequisites; app-store submission also faces a
-human review against OpenAI’s Apps SDK UX principles. Run this checklist against the built app before
-submitting, and render it as an audit table in the design wireframe (`design/wireframe.html` in the
-`acme-*` examples) so partners and reviewers see it up front.
-
-## Contents
-
-- Metadata gate vs review
-- Pre-submission checklist
-- UI guidelines
-- Domain guardrails
-- Privacy and data
-
-## Metadata gate vs review
-
-`noodle check --target chatgpt --json` returning `ok:true` means the widget is *metadata-ready* (widget
-`domain`, `openai/outputTemplate`, CSP, tool annotations, and `invoking`/`invoked` invocation copy are
-present) — it does NOT prove host rendering, conversation UX, or submission acceptance. Validate real
-rendering in ChatGPT Developer Mode / MCP Inspector, then run the checklist below.
-
-## Pre-submission checklist (what review looks for)
-
-1. **Conversational value** — at least one capability relies on ChatGPT’s strengths: natural-language
-   actions no tap-driven app can do (e.g. "two margheritas and a lemon tart" parses into a cart). Cite
-   concrete app behavior, not aspirations.
-2. **Beyond base ChatGPT** — new knowledge, actions, or presentation (grounded partner data, live
-   inventory, signed handoffs, real-world routing).
-3. **Atomic, model-friendly actions** — self-contained tools with explicit input/output schemas, and an
-   annotation on every tool (`annotations.readOnly()` / `.action()` / `.openAction()`).
-4. **Helpful UI only** — justify each widget (would plain text degrade UX?), and note what you
-   deliberately did NOT build a widget for (payment is off-app → no payment widget).
-5. **In-chat task completion** — the user finishes a meaningful task in chat. For a top-of-funnel app,
-   the task is the discovery/config loop completed in-chat with an intentional handoff.
-6. **Performance** — tool calls scoped per step; response-time targets stated.
-7. **Discoverability** — broad, natural trigger prompts listed; description keywords planned. Golden
-   prompt sets and metadata optimization are a launch workstream, not polish.
-8. **Platform fit** — multi-turn dialogue, conversation memory, and multimodality where genuinely useful.
-
-## UI guidelines
-
-System fonts, monochrome outlined icons, WCAG AA contrast, at most two actions on inline cards, no nested
-scroll, and the right display mode per intent (inline by default; fullscreen only where browsing needs
-it; picture-in-picture only for live state). Brand only through `server` `branding` tokens — accent on
-the primary CTA, logo, and badges, nothing else; the compiler derives the palette. Never inject raw
-global CSS.
-
-## Domain guardrails
-
-For regulated-adjacent apps, add app-specific trust behaviors and **show them in the rendered pixels**:
-cite the source and its revision for consequential lookups; frame regulated content as "considerations,
-not a ruling"; never invent compatibility, availability, or pricing; and always show the relevant
-caution/disclaimer. These are what make a regulated-adjacent app approvable.
-
-## Privacy and data
-
-Data flows through OpenAI; tool payloads and whatever the server stores must match the partner’s privacy
-policy. No payment happens in chat (PCI stays off-app). Avoid per-user OAuth in a top-of-funnel v1 (use
-service credentials via a `connector`); add end-user auth only for two-way apps (`customerAuth`). Keep
-secrets out of tool output, widgets, and logs. If the partner’s published policy predates the app, flag a
-privacy gap for their counsel before submission. Re-run this checklist against the *built* app before
-every submission — not just the wireframe.