@noodleseed/agent-kit 0.30.0 → 0.30.1

package/manifest.json

@@ -1,9 +1,9 @@
 {
-  "packageVersion": "0.30.0",
+  "packageVersion": "0.30.1",
   "files": [
     {
       "path": "skills/codex/SKILL.md",
-      "sha256": "1c4dd7e2af79db3ca212106bf8764db5471ba828861cc1b438be777665d02b41",
+      "sha256": "4e2de1199627d9a194ed2ae0985f440288f895ee82ae65935ebf37385affe6c6",
       "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"
     },
     {
@@ -378,7 +378,7 @@
     },
     {
       "path": "skills/claude-code/SKILL.md",
-      "sha256": "e4a9d32883a8d9b2d0dbb8f758977beb8a8334e93321d4eb50bad5db94e478ae",
+      "sha256": "ed60e53c77c3e71d162ab1040c75ad648e51d7c7ccf867794801216afe246651",
       "agentTarget": "claude-code"
     },
     {
@@ -413,7 +413,7 @@
     },
     {
       "path": "skills/claude-code/references/connect-an-api.md",
-      "sha256": "982b5652635706793bf20b0d2b6abb7887302e3ab39886002b23f09d1515ac26",
+      "sha256": "b2ab03691502794d0e8b328d81a906636c9a65623abeddd51ce9658a4542fc4b",
       "agentTarget": "claude-code"
     },
     {
@@ -433,7 +433,7 @@
     },
     {
       "path": "skills/claude-code/references/troubleshooting.md",
-      "sha256": "0fac5c07a9707ffeb88860905f351c58b567dcae1337ea9ac044cf5df8c8afef",
+      "sha256": "238a8d0f4ff8635ed8b0bc63db734634c44ba82e78a3851dc50c85486e1fb942",
       "agentTarget": "claude-code"
     },
     {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noodleseed/agent-kit",
-  "version": "0.30.0",
+  "version": "0.30.1",
   "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.30.1
+hash: d16ddb93b02b757a
 ---
 
 # 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`).

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/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.30.1
+hash: c2a03a8059656742
 ---
 
 # 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`).

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/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` |