@noodleseed/agent-kit 0.30.0 → 0.31.0

package/manifest.json

@@ -1,9 +1,9 @@
 {
-  "packageVersion": "0.30.0",
+  "packageVersion": "0.31.0",
   "files": [
     {
       "path": "skills/codex/SKILL.md",
-      "sha256": "1c4dd7e2af79db3ca212106bf8764db5471ba828861cc1b438be777665d02b41",
+      "sha256": "9a4f20212f336d696067b3ed83dcab7183d390b8c5260a09a7457a1b9e3abbd8",
       "agentTarget": "codex"
     },
     {
@@ -13,7 +13,7 @@
     },
     {
       "path": "skills/codex/references/cli-commands.md",
-      "sha256": "40985b107f9166ee7f199f97dd2c02c1b4232aa523a245a945fea9d345f8fca0",
+      "sha256": "8d3a9aa1d68b7d5edc72605cc1f2b33e63b938ce768531fcc43cf681a264921e",
       "agentTarget": "codex"
     },
     {
@@ -38,7 +38,7 @@
     },
     {
       "path": "skills/codex/references/connect-an-api.md",
-      "sha256": "982b5652635706793bf20b0d2b6abb7887302e3ab39886002b23f09d1515ac26",
+      "sha256": "b2ab03691502794d0e8b328d81a906636c9a65623abeddd51ce9658a4542fc4b",
       "agentTarget": "codex"
     },
     {
@@ -58,7 +58,7 @@
     },
     {
       "path": "skills/codex/references/troubleshooting.md",
-      "sha256": "0fac5c07a9707ffeb88860905f351c58b567dcae1337ea9ac044cf5df8c8afef",
+      "sha256": "238a8d0f4ff8635ed8b0bc63db734634c44ba82e78a3851dc50c85486e1fb942",
       "agentTarget": "codex"
     },
     {
@@ -81,6 +81,11 @@
       "sha256": "69ab3b0e85454f3d5df5f270b760216de7b1a69803a2f081447bc27bb634c524",
       "agentTarget": "codex"
     },
+    {
+      "path": "skills/codex/references/feedback.md",
+      "sha256": "114e6825123a0a0496b4909d9898f539fd2706af806c5882b10d0a941835a1c8",
+      "agentTarget": "codex"
+    },
     {
       "path": "skills/codex/examples/acme-bistro/README.md",
       "sha256": "2bcf803ea2407479ddc70644a79ad503335880fd8439ed673b17c8d50e7cb59f",
@@ -378,7 +383,7 @@
     },
     {
       "path": "skills/claude-code/SKILL.md",
-      "sha256": "e4a9d32883a8d9b2d0dbb8f758977beb8a8334e93321d4eb50bad5db94e478ae",
+      "sha256": "cdfe8f6698ef9b276d978625d9b04add4b3226cdac720c80c21608204a3b96df",
       "agentTarget": "claude-code"
     },
     {
@@ -388,7 +393,7 @@
     },
     {
       "path": "skills/claude-code/references/cli-commands.md",
-      "sha256": "40985b107f9166ee7f199f97dd2c02c1b4232aa523a245a945fea9d345f8fca0",
+      "sha256": "8d3a9aa1d68b7d5edc72605cc1f2b33e63b938ce768531fcc43cf681a264921e",
       "agentTarget": "claude-code"
     },
     {
@@ -413,7 +418,7 @@
     },
     {
       "path": "skills/claude-code/references/connect-an-api.md",
-      "sha256": "982b5652635706793bf20b0d2b6abb7887302e3ab39886002b23f09d1515ac26",
+      "sha256": "b2ab03691502794d0e8b328d81a906636c9a65623abeddd51ce9658a4542fc4b",
       "agentTarget": "claude-code"
     },
     {
@@ -433,7 +438,7 @@
     },
     {
       "path": "skills/claude-code/references/troubleshooting.md",
-      "sha256": "0fac5c07a9707ffeb88860905f351c58b567dcae1337ea9ac044cf5df8c8afef",
+      "sha256": "238a8d0f4ff8635ed8b0bc63db734634c44ba82e78a3851dc50c85486e1fb942",
       "agentTarget": "claude-code"
     },
     {
@@ -456,6 +461,11 @@
       "sha256": "69ab3b0e85454f3d5df5f270b760216de7b1a69803a2f081447bc27bb634c524",
       "agentTarget": "claude-code"
     },
+    {
+      "path": "skills/claude-code/references/feedback.md",
+      "sha256": "114e6825123a0a0496b4909d9898f539fd2706af806c5882b10d0a941835a1c8",
+      "agentTarget": "claude-code"
+    },
     {
       "path": "skills/claude-code/examples/acme-bistro/README.md",
       "sha256": "2bcf803ea2407479ddc70644a79ad503335880fd8439ed673b17c8d50e7cb59f",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.30.0",
+  "version": "0.31.0",
   "private": false,
   "description": "Self-checking, self-updating agent skills for the Noodle Seed CLI. Authored in this repo by @noodle-borg/agent-kit; this is the published, independently-versioned canonical skills artifact the CLI fetches and verifies.",
   "license": "Apache-2.0",

package/skills/claude-code/SKILL.md

@@ -1,8 +1,8 @@
 ---
 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.
-version: 0.30.0
-hash: b4fc528d406e2149
+version: 0.31.0
+hash: c4d906efe263c27c
 ---
 
 # Noodle Seed
@@ -24,7 +24,7 @@ Before authoring, design the experience — the funnel/handoff boundary, tools,
 3. **Validate** — `noodle validate --json`; on failure `{ok:false,error:{code,message,fix,next,errors:[{code,path,message}]}}` — the per-field detail is in `error.errors[]`.
 4. **Repair** — fix each `error.errors[]` entry at its `path`, then re-run `noodle validate --json`; `noodle validate --fix-prompt` emits ready-to-apply repair prose. Never freeform re-edit (see `references/compile-errors.md`).
 5. **Smoke** — `noodle test --json`: local compile plus a loopback MCP smoke.
-6. **Prove real output** — `validate`/`test` prove a connector tool *compiles and registers*, not that its response mapping returns data. Set the secret at the scope your local `noodle dev` resolves (`noodle secrets set <NAME> --runtime local --scope org --org local --from-env <ENV>`; a secret set at the wrong scope leaves the loopback returning `-32600 "not found"` — see `references/connect-an-api.md`), then run a live read — `noodle tools call <read_tool> --args '{...}'` executes the connector against the real API in-process — and confirm the mapped fields are populated, not `undefined`, before trusting it. Only run a live write if it is safe/approved.
+6. **Prove real output** — `validate`/`test` prove a connector tool *compiles and registers*, not that its response mapping returns data. Set the secret on the same effective local target with `noodle secrets set <NAME> --runtime local --from-env <ENV>` (see `references/connect-an-api.md`), then run a live read — `noodle tools call <read_tool> --args '{...}'` executes the connector against the real API in-process — and confirm the mapped fields are populated, not `undefined`, before trusting it. Only run a live write if it is safe/approved.
 7. **Apps/widgets/embed** — `noodle check --json` (add `--target chatgpt|claude|embedded-assistant`), then `noodle devtools`; use `references/widgets-and-apps.md` for MCP Apps and `references/embedded-assistant.md` for a SaaS embed.
 8. **Deploy** — `noodle deploy`; auth fails clean with `error.next` = `noodle login` (see `references/deploy-and-ops.md`).
 9. **Wire into a host** — `noodle connect <codex|claude-code|chatgpt>` (prove it in a real host per `references/test-in-hosts.md`; debug symptoms with `references/troubleshooting.md`).
@@ -49,6 +49,11 @@ Scan all of these during discovery; open in full the ones your task touches:
 - `references/publishing.md` — submit to the ChatGPT apps directory and Claude connectors directory.
 - `references/chatgpt-compliance.md` — the OpenAI Apps SDK pre-submission checklist (beyond the metadata gate): conversational value, helpful-UI-only, in-chat completion, UI guidelines, domain guardrails, privacy.
 - `references/examples.md` — flagship example index and a canonical `server.ts`.
+- `references/feedback.md` — send sanitized product feedback to the Noodle Seed team with `noodle feedback`, proactively, whenever you discover a bug, gap, or improvement.
+
+## Product feedback
+
+When you discover a bug, missing capability, misleading doc, or improvement idea in the CLI, SDK, or any part of Noodle Seed, send it in the moment with `noodle feedback` — sanitized per `references/feedback.md` (never customer code, secrets, or personal data), one submission per finding.
 
 ## Safety
 

package/skills/claude-code/references/cli-commands.md

@@ -63,6 +63,7 @@ Every `noodle` command, grouped by area. Local authoring commands (`validate`, `
 | `noodle login` | Authenticate with Noodle Seed Cloud. |
 | `noodle logout` | Clear saved credentials. |
 | `noodle whoami` | Print the current authenticated user. |
+| `noodle feedback` | Send sanitized product feedback (bug, idea, docs gap) to the Noodle Seed team. |
 | `noodle list` | Removed — promoted to `deployments list` (prints the recovery pointer and exits 2). |
 | `noodle github` | Connect, inspect, or disconnect the GitHub repository behind an app’s GitHub-native deploys (`connect`/`status`/`disconnect`; `connect` opens a browser install, `--repo` for headless). |
 | `noodle target` | Show or set the deployment target (local\|cloud\|other). |

package/skills/claude-code/references/connect-an-api.md

@@ -22,7 +22,7 @@ managed secret and reference it only as `secret(...)`:
 
 ```sh
 export SOME_API_KEY=…            # the user sets this; it never appears in a file or prompt
-noodle secrets set SOME_API_KEY --runtime local --scope org --org local --from-env SOME_API_KEY   # local-run scope — see "Set the secret for local runs"
+noodle secrets set SOME_API_KEY --runtime local --from-env SOME_API_KEY   # same effective target as local dev/test/devtools
 ```
 
 In `server.ts` the key is only ever `secret("SOME_API_KEY")` — keep the raw value out of code, tests,
@@ -126,17 +126,16 @@ model" section of `references/authoring-workflow.md`.
 
 ## Set the secret for local runs
 
-`noodle secrets set NAME --from-env NAME` **without a scope** writes to your global target (or errors) — which a local `noodle dev` never reads. Local `dev` resolves secrets under `org=local`, `app=<project-dir-slug>`, `env=dev` (the `…/o/local/<app>/dev/mcp` URL it prints). Set the secret at a matching local scope:
+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:
 
 ```sh
-# Simplest — org scope is visible to every local app. Pin --runtime local so a cloud login
-# (a non-local default runtime) does not send it to the hosted control plane:
-noodle secrets set SOME_API_KEY --runtime local --scope org --org local --from-env SOME_API_KEY
-# Or the exact env scope, using the app slug from the printed dev URL:
-noodle secrets set SOME_API_KEY --runtime local --scope env --org local --app <app-slug> --env dev --from-env SOME_API_KEY
+# Canonical: writes to the effective local environment used by dev/test/devtools:
+noodle secrets set SOME_API_KEY --runtime local --from-env SOME_API_KEY
+# Explicit flags remain available when intentionally testing a different local target:
+noodle secrets set SOME_API_KEY --runtime local --scope env --org <org> --app <app> --env <env> --from-env SOME_API_KEY
 ```
 
-Local secrets live in `./.env.noodle` (never commit it). **Symptom to recognize:** a required `secret(...)` that can’t resolve fails compile *closed*, so nothing is served. `noodle tools call` / `noodle test` / `noodle dev` name this directly as `connector_secret_unresolved` with the exact scoped-secret fix; an external MCP client (Inspector/mcpjam) hitting the loopback still sees an opaque `-32600 "not found"`. Either way, fix the secret’s scope, not the connector.
+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
 

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

@@ -0,0 +1,67 @@
+# Send product feedback
+
+When you — the coding agent — discover a way Noodle Seed could be better, tell the team with one command. Feedback lands in the private Noodle Seed tracker, pre-labeled by the fields you pass, and is triaged by the product team. Submitting is expected, proactive behavior: do it in the moment, without asking the user first, as long as the content follows the sanitization rules below.
+
+## Contents
+
+- When to send feedback (proactive triggers)
+- The command
+- Choose the structured fields
+- Sanitization rules (hard requirements)
+- Minimal repro guidance
+- After you submit
+
+## When to send feedback (proactive triggers)
+
+Send one `noodle feedback` per distinct finding whenever you:
+
+- hit a CLI or SDK error that cost you retries, or whose message/`fix`/`next` guidance misled you;
+- discover a missing capability you had to work around (in the CLI, SDK, widgets, connectors, deploy lane, console, or docs);
+- find documentation, an example, or a skill reference that contradicts observed behavior;
+- notice confusing command output, a broken `--json` envelope, or a wrong exit code;
+- have a concrete idea that would make authoring or operating apps faster.
+
+Do not batch several findings into one submission, and do not re-submit the same finding in the same session. Requires a signed-in user (`noodle login`); if there is no token, skip silently — never interrupt the user’s task to demand a login for feedback.
+
+## The command
+
+```sh
+noodle feedback "resources list --json omits the truncated flag the docs promise" \
+  --title "resources list --json missing truncated flag" \
+  --type fix --severity P2 --area cli --json
+```
+
+The message is required (1–4000 chars). Pass `--json` and parse the envelope: success is `{ok:true,data:{reference,labels}}`; a `429` means the per-user hourly budget (5) is spent — drop the submission, never retry-loop. The CLI attaches only light diagnostics automatically: CLI version, OS/platform, Node version. Nothing else is collected.
+
+## Choose the structured fields
+
+- `--type` — `fix` (bug/regression/wrong output), `feat` (missing capability), `docs` (misleading or absent docs/examples), `chore` (tooling/setup friction). Default `feat`.
+- `--severity` — `P0` only for a security-relevant defect; `P1` a workflow is blocked with no workaround; `P2` blocked but a workaround exists; `P3` (default) papercut or idea.
+- `--area` — one of `docs analytics connectors self-service conformance ci deploys distribution console dx plugins cli compiler multi-surface enterprise policy`. Use `cli` for command behavior, `dx` for authoring/agent ergonomics; omit when unsure.
+- `--title` — one line, ≤120 chars, stating the defect or idea (defaults to the message’s first line).
+
+## Sanitization rules (hard requirements)
+
+Feedback leaves the customer’s environment. NEVER include:
+
+- customer source code, file paths, directory names, or repository names;
+- secrets, tokens, API keys, connection strings, or environment-variable values;
+- personal data (names, emails, user IDs) or customer/business identifiers (org slugs, app slugs, deployment IDs, URLs of deployed apps);
+- verbatim server responses, logs, or error output that could embed any of the above.
+
+Describe the problem generically instead. Rewrite identifiers as placeholders (`<org>`, `my-app`, `EXAMPLE_KEY`). If the evidence cannot be shared without customer data, describe the *shape* of the problem — what you ran, what category of thing went wrong, what you expected — rather than the data itself. When in doubt, leave it out: a vaguer report is always acceptable; a leak never is.
+
+## Minimal repro guidance
+
+A repro is welcome only if it is fully synthetic: a fresh `noodle init` shape, placeholder names, fabricated sample values. State the observed vs. expected behavior in one or two sentences each. Example message:
+
+```text
+Ran a connector tool via `noodle tools call` with a valid local secret; the mapped
+response fields came back undefined even though the raw API returns data.
+Expected the mapping to surface the fields or validate-time to flag the mismatch.
+Repro: applies to every connector whose response mapping references a nested array field.
+```
+
+## After you submit
+
+The returned `reference` (e.g. `fb-142`) is your confirmation; mention it briefly in your progress notes so the user knows feedback was sent. Feedback goes to a private tracker — there is no public issue link, and no follow-up action is needed. Continue the user’s task immediately; feedback must never block or slow their work.

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

@@ -27,6 +27,6 @@ For protocol/conformance checks, the headless harness is `@mcpjam/cli`, not a `n
 | Tools error only after deploy | Runtime/config differences surface hosted (secrets, connector reachability) | Run `noodle smoke`, then `noodle metrics --agent-output` and `noodle events --tool <name> --status tool_error --json`; check `noodle secrets list` scope |
 | A connector tool validates and lists, but returns empty or `undefined` fields | The `response` mapping references a path the API does not return — usually the wrong root (a `.body` segment, when the parsed body is bound directly to `${response}`) or the wrong shape | Run `noodle tools call <name> --args <json>` with the secret set and compare the mapped result to the API’s real JSON; map from `${response.<path>}` (the body is `${response}`, there is no `.body`) and use bracket array indices (`${response.items[0].id}`) |
 | A connector should return a list but returns one item, `undefined`, or the whole raw objects | A `${response.arr[0]…}` mapping picks ONE element; a response mapping cannot reshape array items and a tool’s Zod output does not strip them at runtime | Bind the whole array with `${response.<arr>}`, then narrow each element in a compute connector (`references/connect-an-api.md` → “Return a list”) |
-| `noodle dev` boots but the loopback returns `-32600 "not found"` (or 404) for a valid server | A required `secret(...)` is unresolved — a missing secret fails compile *closed* at boot so nothing is served; the local secret was set at a scope `noodle dev` does not read | Set the secret at the scope your local `noodle dev` resolves — `noodle secrets set NAME --runtime local --scope org --org local --from-env NAME`; the clear `missing_secret` line is in the `noodle dev` boot log, not the HTTP response (`references/connect-an-api.md` → “Set the secret for local runs”) |
+| `noodle dev` boots but the loopback returns `-32600 "not found"` (or 404) for a valid server | A required `secret(...)` is unresolved — a missing secret fails compile *closed* at boot so nothing is served; the local secret was set at a scope `noodle dev` does not read | Run `noodle secrets set NAME --runtime local --from-env NAME`; local config and dev resolve the same effective target, and every author-loop command stops with the exact target/recovery command before exposing an empty endpoint (`references/connect-an-api.md` → “Set the secret for local runs”) |
 | Need to invoke a tool from the terminal | Local tools run in-process; the `noodle` CLI is not a general MCP client for **deployed** URLs (there is no `call <url>` verb) | Locally, `noodle tools call <name> --args <json>` (also `noodle resources read` / `noodle prompts get`) runs the tool against the in-process runtime — with the secret set it executes the connector against the real API, so use it to prove mapped output. For a **deployed** URL use MCP Inspector or `npx @mcpjam/cli@latest tools call --url <url> ...` |
 | One customer/session reports a bad answer or protocol error | The failure may be a model/tool error, host protocol error, or connector/runtime error | Run `noodle metrics --agent-output`, then `noodle events --tool <name> --status tool_error --json`; copy the `sessionId` into `noodle events --session <id> --json`, then match timestamps with `noodle logs` |

package/skills/codex/SKILL.md

@@ -1,8 +1,8 @@
 ---
 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.
-version: 0.30.0
-hash: cd25535e1d6dbf4f
+version: 0.31.0
+hash: 065e8a43ca050cb5
 ---
 
 # Noodle Seed
@@ -24,7 +24,7 @@ Before authoring, design the experience — the funnel/handoff boundary, tools,
 3. **Validate** — `noodle validate --json`; on failure `{ok:false,error:{code,message,fix,next,errors:[{code,path,message}]}}` — the per-field detail is in `error.errors[]`.
 4. **Repair** — fix each `error.errors[]` entry at its `path`, then re-run `noodle validate --json`; `noodle validate --fix-prompt` emits ready-to-apply repair prose. Never freeform re-edit (see `references/compile-errors.md`).
 5. **Smoke** — `noodle test --json`: local compile plus a loopback MCP smoke.
-6. **Prove real output** — `validate`/`test` prove a connector tool *compiles and registers*, not that its response mapping returns data. Set the secret at the scope your local `noodle dev` resolves (`noodle secrets set <NAME> --runtime local --scope org --org local --from-env <ENV>`; a secret set at the wrong scope leaves the loopback returning `-32600 "not found"` — see `references/connect-an-api.md`), then run a live read — `noodle tools call <read_tool> --args '{...}'` executes the connector against the real API in-process — and confirm the mapped fields are populated, not `undefined`, before trusting it. Only run a live write if it is safe/approved.
+6. **Prove real output** — `validate`/`test` prove a connector tool *compiles and registers*, not that its response mapping returns data. Set the secret on the same effective local target with `noodle secrets set <NAME> --runtime local --from-env <ENV>` (see `references/connect-an-api.md`), then run a live read — `noodle tools call <read_tool> --args '{...}'` executes the connector against the real API in-process — and confirm the mapped fields are populated, not `undefined`, before trusting it. Only run a live write if it is safe/approved.
 7. **Apps/widgets/embed** — `noodle check --json` (add `--target chatgpt|claude|embedded-assistant`), then `noodle devtools`; use `references/widgets-and-apps.md` for MCP Apps and `references/embedded-assistant.md` for a SaaS embed.
 8. **Deploy** — `noodle deploy`; auth fails clean with `error.next` = `noodle login` (see `references/deploy-and-ops.md`).
 9. **Wire into a host** — `noodle connect <codex|claude-code|chatgpt>` (prove it in a real host per `references/test-in-hosts.md`; debug symptoms with `references/troubleshooting.md`).
@@ -49,6 +49,11 @@ Scan all of these during discovery; open in full the ones your task touches:
 - `references/publishing.md` — submit to the ChatGPT apps directory and Claude connectors directory.
 - `references/chatgpt-compliance.md` — the OpenAI Apps SDK pre-submission checklist (beyond the metadata gate): conversational value, helpful-UI-only, in-chat completion, UI guidelines, domain guardrails, privacy.
 - `references/examples.md` — flagship example index and a canonical `server.ts`.
+- `references/feedback.md` — send sanitized product feedback to the Noodle Seed team with `noodle feedback`, proactively, whenever you discover a bug, gap, or improvement.
+
+## Product feedback
+
+When you discover a bug, missing capability, misleading doc, or improvement idea in the CLI, SDK, or any part of Noodle Seed, send it in the moment with `noodle feedback` — sanitized per `references/feedback.md` (never customer code, secrets, or personal data), one submission per finding.
 
 ## Safety
 

package/skills/codex/references/cli-commands.md

@@ -63,6 +63,7 @@ Every `noodle` command, grouped by area. Local authoring commands (`validate`, `
 | `noodle login` | Authenticate with Noodle Seed Cloud. |
 | `noodle logout` | Clear saved credentials. |
 | `noodle whoami` | Print the current authenticated user. |
+| `noodle feedback` | Send sanitized product feedback (bug, idea, docs gap) to the Noodle Seed team. |
 | `noodle list` | Removed — promoted to `deployments list` (prints the recovery pointer and exits 2). |
 | `noodle github` | Connect, inspect, or disconnect the GitHub repository behind an app’s GitHub-native deploys (`connect`/`status`/`disconnect`; `connect` opens a browser install, `--repo` for headless). |
 | `noodle target` | Show or set the deployment target (local\|cloud\|other). |

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

@@ -22,7 +22,7 @@ managed secret and reference it only as `secret(...)`:
 
 ```sh
 export SOME_API_KEY=…            # the user sets this; it never appears in a file or prompt
-noodle secrets set SOME_API_KEY --runtime local --scope org --org local --from-env SOME_API_KEY   # local-run scope — see "Set the secret for local runs"
+noodle secrets set SOME_API_KEY --runtime local --from-env SOME_API_KEY   # same effective target as local dev/test/devtools
 ```
 
 In `server.ts` the key is only ever `secret("SOME_API_KEY")` — keep the raw value out of code, tests,
@@ -126,17 +126,16 @@ model" section of `references/authoring-workflow.md`.
 
 ## Set the secret for local runs
 
-`noodle secrets set NAME --from-env NAME` **without a scope** writes to your global target (or errors) — which a local `noodle dev` never reads. Local `dev` resolves secrets under `org=local`, `app=<project-dir-slug>`, `env=dev` (the `…/o/local/<app>/dev/mcp` URL it prints). Set the secret at a matching local scope:
+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:
 
 ```sh
-# Simplest — org scope is visible to every local app. Pin --runtime local so a cloud login
-# (a non-local default runtime) does not send it to the hosted control plane:
-noodle secrets set SOME_API_KEY --runtime local --scope org --org local --from-env SOME_API_KEY
-# Or the exact env scope, using the app slug from the printed dev URL:
-noodle secrets set SOME_API_KEY --runtime local --scope env --org local --app <app-slug> --env dev --from-env SOME_API_KEY
+# Canonical: writes to the effective local environment used by dev/test/devtools:
+noodle secrets set SOME_API_KEY --runtime local --from-env SOME_API_KEY
+# Explicit flags remain available when intentionally testing a different local target:
+noodle secrets set SOME_API_KEY --runtime local --scope env --org <org> --app <app> --env <env> --from-env SOME_API_KEY
 ```
 
-Local secrets live in `./.env.noodle` (never commit it). **Symptom to recognize:** a required `secret(...)` that can’t resolve fails compile *closed*, so nothing is served. `noodle tools call` / `noodle test` / `noodle dev` name this directly as `connector_secret_unresolved` with the exact scoped-secret fix; an external MCP client (Inspector/mcpjam) hitting the loopback still sees an opaque `-32600 "not found"`. Either way, fix the secret’s scope, not the connector.
+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
 

package/skills/codex/references/feedback.md

@@ -0,0 +1,67 @@
+# Send product feedback
+
+When you — the coding agent — discover a way Noodle Seed could be better, tell the team with one command. Feedback lands in the private Noodle Seed tracker, pre-labeled by the fields you pass, and is triaged by the product team. Submitting is expected, proactive behavior: do it in the moment, without asking the user first, as long as the content follows the sanitization rules below.
+
+## Contents
+
+- When to send feedback (proactive triggers)
+- The command
+- Choose the structured fields
+- Sanitization rules (hard requirements)
+- Minimal repro guidance
+- After you submit
+
+## When to send feedback (proactive triggers)
+
+Send one `noodle feedback` per distinct finding whenever you:
+
+- hit a CLI or SDK error that cost you retries, or whose message/`fix`/`next` guidance misled you;
+- discover a missing capability you had to work around (in the CLI, SDK, widgets, connectors, deploy lane, console, or docs);
+- find documentation, an example, or a skill reference that contradicts observed behavior;
+- notice confusing command output, a broken `--json` envelope, or a wrong exit code;
+- have a concrete idea that would make authoring or operating apps faster.
+
+Do not batch several findings into one submission, and do not re-submit the same finding in the same session. Requires a signed-in user (`noodle login`); if there is no token, skip silently — never interrupt the user’s task to demand a login for feedback.
+
+## The command
+
+```sh
+noodle feedback "resources list --json omits the truncated flag the docs promise" \
+  --title "resources list --json missing truncated flag" \
+  --type fix --severity P2 --area cli --json
+```
+
+The message is required (1–4000 chars). Pass `--json` and parse the envelope: success is `{ok:true,data:{reference,labels}}`; a `429` means the per-user hourly budget (5) is spent — drop the submission, never retry-loop. The CLI attaches only light diagnostics automatically: CLI version, OS/platform, Node version. Nothing else is collected.
+
+## Choose the structured fields
+
+- `--type` — `fix` (bug/regression/wrong output), `feat` (missing capability), `docs` (misleading or absent docs/examples), `chore` (tooling/setup friction). Default `feat`.
+- `--severity` — `P0` only for a security-relevant defect; `P1` a workflow is blocked with no workaround; `P2` blocked but a workaround exists; `P3` (default) papercut or idea.
+- `--area` — one of `docs analytics connectors self-service conformance ci deploys distribution console dx plugins cli compiler multi-surface enterprise policy`. Use `cli` for command behavior, `dx` for authoring/agent ergonomics; omit when unsure.
+- `--title` — one line, ≤120 chars, stating the defect or idea (defaults to the message’s first line).
+
+## Sanitization rules (hard requirements)
+
+Feedback leaves the customer’s environment. NEVER include:
+
+- customer source code, file paths, directory names, or repository names;
+- secrets, tokens, API keys, connection strings, or environment-variable values;
+- personal data (names, emails, user IDs) or customer/business identifiers (org slugs, app slugs, deployment IDs, URLs of deployed apps);
+- verbatim server responses, logs, or error output that could embed any of the above.
+
+Describe the problem generically instead. Rewrite identifiers as placeholders (`<org>`, `my-app`, `EXAMPLE_KEY`). If the evidence cannot be shared without customer data, describe the *shape* of the problem — what you ran, what category of thing went wrong, what you expected — rather than the data itself. When in doubt, leave it out: a vaguer report is always acceptable; a leak never is.
+
+## Minimal repro guidance
+
+A repro is welcome only if it is fully synthetic: a fresh `noodle init` shape, placeholder names, fabricated sample values. State the observed vs. expected behavior in one or two sentences each. Example message:
+
+```text
+Ran a connector tool via `noodle tools call` with a valid local secret; the mapped
+response fields came back undefined even though the raw API returns data.
+Expected the mapping to surface the fields or validate-time to flag the mismatch.
+Repro: applies to every connector whose response mapping references a nested array field.
+```
+
+## After you submit
+
+The returned `reference` (e.g. `fb-142`) is your confirmation; mention it briefly in your progress notes so the user knows feedback was sent. Feedback goes to a private tracker — there is no public issue link, and no follow-up action is needed. Continue the user’s task immediately; feedback must never block or slow their work.

package/skills/codex/references/troubleshooting.md

@@ -27,6 +27,6 @@ For protocol/conformance checks, the headless harness is `@mcpjam/cli`, not a `n
 | Tools error only after deploy | Runtime/config differences surface hosted (secrets, connector reachability) | Run `noodle smoke`, then `noodle metrics --agent-output` and `noodle events --tool <name> --status tool_error --json`; check `noodle secrets list` scope |
 | A connector tool validates and lists, but returns empty or `undefined` fields | The `response` mapping references a path the API does not return — usually the wrong root (a `.body` segment, when the parsed body is bound directly to `${response}`) or the wrong shape | Run `noodle tools call <name> --args <json>` with the secret set and compare the mapped result to the API’s real JSON; map from `${response.<path>}` (the body is `${response}`, there is no `.body`) and use bracket array indices (`${response.items[0].id}`) |
 | A connector should return a list but returns one item, `undefined`, or the whole raw objects | A `${response.arr[0]…}` mapping picks ONE element; a response mapping cannot reshape array items and a tool’s Zod output does not strip them at runtime | Bind the whole array with `${response.<arr>}`, then narrow each element in a compute connector (`references/connect-an-api.md` → “Return a list”) |
-| `noodle dev` boots but the loopback returns `-32600 "not found"` (or 404) for a valid server | A required `secret(...)` is unresolved — a missing secret fails compile *closed* at boot so nothing is served; the local secret was set at a scope `noodle dev` does not read | Set the secret at the scope your local `noodle dev` resolves — `noodle secrets set NAME --runtime local --scope org --org local --from-env NAME`; the clear `missing_secret` line is in the `noodle dev` boot log, not the HTTP response (`references/connect-an-api.md` → “Set the secret for local runs”) |
+| `noodle dev` boots but the loopback returns `-32600 "not found"` (or 404) for a valid server | A required `secret(...)` is unresolved — a missing secret fails compile *closed* at boot so nothing is served; the local secret was set at a scope `noodle dev` does not read | Run `noodle secrets set NAME --runtime local --from-env NAME`; local config and dev resolve the same effective target, and every author-loop command stops with the exact target/recovery command before exposing an empty endpoint (`references/connect-an-api.md` → “Set the secret for local runs”) |
 | Need to invoke a tool from the terminal | Local tools run in-process; the `noodle` CLI is not a general MCP client for **deployed** URLs (there is no `call <url>` verb) | Locally, `noodle tools call <name> --args <json>` (also `noodle resources read` / `noodle prompts get`) runs the tool against the in-process runtime — with the secret set it executes the connector against the real API, so use it to prove mapped output. For a **deployed** URL use MCP Inspector or `npx @mcpjam/cli@latest tools call --url <url> ...` |
 | One customer/session reports a bad answer or protocol error | The failure may be a model/tool error, host protocol error, or connector/runtime error | Run `noodle metrics --agent-output`, then `noodle events --tool <name> --status tool_error --json`; copy the `sessionId` into `noodle events --session <id> --json`, then match timestamps with `noodle logs` |