@noodleseed/agent-kit 0.91.0 → 0.92.0

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

@@ -0,0 +1,80 @@
+# Send product feedback
+
+When you — the coding agent — discover a way Noodle Seed could be better, prepare one sanitized feedback proposal. Feedback crosses the customer project boundary and lands in the Noodle Seed private feedback tracker, so the user must make an informed choice. Preview the exact normalized submission locally, show its stable public `noodle feedback` action, and ask for explicit user approval. Do not submit it until approval is given.
+
+## Contents
+
+- When to propose feedback
+- Approval workflow
+- The command
+- Choose the structured fields
+- Sanitization rules (hard requirements)
+- Minimal repro guidance
+- After you submit
+
+## When to propose feedback
+
+Draft one `noodle feedback` proposal per distinct finding when 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 proposal, and do not re-propose the same finding in the same session.
+
+## Approval workflow
+
+1. Discover the current positional arguments, flags, choices, defaults, and limits from `noodle commands --json`; `noodle feedback --help` is the human-readable view. Do not guess or rely on a remembered catalog.
+2. Draft one finding, then sanitize its title and message using the rules below. When your coding-agent name is known, add `--agent`; add `--model` only when the exact model identifier is also known. These fields are client-reported provenance: never guess either value.
+3. Run the proposal with `--dry-run --json`. This local preview needs no login and sends nothing. Parse `{"ok":true,"data":{"mode":"preview","willSubmit":false,"destination":"Noodle Seed private feedback tracker","submission":{...}}}`.
+4. Inspect the complete `submission`, including its normalized defaults and automatically attached diagnostics. Show the user the exact previewed proposal, its `destination`, and the stable public `noodle feedback` action. Keep the proposal as structured fields instead of rebuilding it as shell text.
+5. Ask for explicit approval of that exact previewed proposal. If the user changes any field, preview the changed proposal again before asking.
+6. Only after approval, submit it once with `noodle-readiness.submit_product_feedback` when the installed plugin tool is available, or pass the same structured fields directly to the public CLI without `--dry-run`. Never auto-login and never retry-loop. If authentication fails before the request or a rate limit denies it, report that nothing was sent. For `feedback_recording_failed`, report that no reference was returned and the outcome may be unknown; do not retry because the private issue might already exist.
+
+## 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 --agent 'coding-agent' --model 'model-id' \
+  --dry-run --json
+```
+
+This is a preview example only: replace `coding-agent` and `model-id` with your known coding-agent identity, or omit both when unavailable. Build structured arguments for the finding using current `noodle commands --json` metadata and inspect the returned submission instead of reconstructing it. Invoke the CLI with an argument array or the typed plugin function, never a shell wrapper or copy/paste request. The message is required (1–4000 chars). The CLI attaches only the disclosed light diagnostics automatically: CLI version, OS/platform, Node version. Agent/model provenance is included only through the explicit client-reported flags. Nothing else is collected. After approval, the live success envelope is `{ok:true,data:{reference,labels}}`; a `429` means the per-user hourly budget (5) is spent — report that it was not sent and never retry-loop.
+
+## 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.
+- `--agent` — your known coding-agent product name (1–64 chars). Omit when unavailable; the CLI does not auto-detect it.
+- `--model` — the exact known model identifier (1–64 chars). Requires `--agent`; omit rather than guessing.
+- `--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
+
+Only after explicit user approval and a successful command, the returned `reference` (e.g. `fb-142`) is confirmation; mention it briefly so the user knows what 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/verifying-mcp-delivery/SKILL.md

@@ -3,7 +3,7 @@ name: verifying-mcp-delivery
 description: "Use when proving a Noodle Seed MCP project works at a named compile, local, connector, App, host, deployment, or production evidence level."
 ---
 
-<!-- noodle-skill version:0.91.0 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.92.0 hash:292253cbaed9a3c5 -->
 
 # verifying-mcp-delivery
 
@@ -27,8 +27,8 @@ Report the highest evidence level actually rerun without upgrading weaker proof.
 
 ## Workflow
 
-Read and follow the canonical playbook `references/verify-and-recover.md` at `../noodle-seed/references/verify-and-recover.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
-Load `references/test-in-hosts.md` at `../noodle-seed/references/test-in-hosts.md` only when the playbook or observed evidence names that concern.
+Read and follow the canonical playbook at `references/verify-and-recover.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
+Load the supporting reference at `references/test-in-hosts.md` only when the playbook or observed evidence names that concern.
 
 ## Verification evidence
 

package/skills/claude-code/verifying-mcp-delivery/references/test-in-hosts.md

@@ -0,0 +1,39 @@
+# Test in real hosts
+
+Local `noodle dev` and `noodle devtools` prove the server works; the widget experience is only proven inside a real host. `noodle connect <client>` prints the exact setup flow per host.
+
+## Contents
+
+- Local inspection first
+- Agent hosts (Claude Code, Codex, editors)
+- ChatGPT (developer mode)
+- Claude
+- Public URL for a local server
+- What to verify
+
+## Local inspection first
+
+Run `noodle dev` and inspect the loopback endpoint with MCP Inspector: `noodle connect inspector` prints the flow (`npx @modelcontextprotocol/inspector <printed endpoint>`). Preview widget metadata and rendering with `noodle devtools`.
+
+## Agent hosts (Claude Code, Codex, editors)
+
+`noodle connect claude-code` / `noodle connect codex` (add `--write` for project-local setup). For other editors (`cursor`, `vscode`, `gemini`), `noodle connect <client>` prints the setup steps, and `noodle docs export --format llms` produces portable context. With a deployed endpoint, `noodle connect <client> --endpoint <url>` prints the MCP client registration config.
+
+## ChatGPT (developer mode)
+
+1. Deploy: `noodle deploy`, then `noodle open --print` for the hosted MCP URL (ChatGPT needs a public HTTPS endpoint, not loopback).
+2. In ChatGPT: Settings → Connectors → enable Developer mode → add the endpoint (`noodle connect chatgpt` prints these steps).
+3. Toggle the connector on in a new conversation and sign in when prompted; testers outside your org need a wider access mode (`noodle access set`).
+4. Test on mobile too — invoke the same connector from the ChatGPT iOS/Android apps to check widget layout.
+
+## Claude
+
+`noodle connect claude` prints the flow: deploy, then add the hosted MCP URL as a custom connector in Claude settings and sign in when prompted. Widgets render in Apps-capable Claude surfaces; elsewhere the tool’s text/structured result is shown.
+
+## Public URL for a local server
+
+To try an undeployed server in a host that requires a public URL, `noodle dev --tunnel` publishes a temporary public URL for the loopback endpoint (requires the external `cloudflared` binary on PATH). Treat it as a short-lived test URL — deploy for anything shared.
+
+## What to verify
+
+Run a golden prompt set — direct (“use <tool> to…”), indirect (a natural request the model should route), and negative (requests that must not trigger the tool). Confirm the model picks the right tool with the right arguments, the widget renders and its actions work, external links open, and the experience degrades to readable text where Apps are unsupported. Symptoms → `references/troubleshooting.md`.

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

@@ -0,0 +1,67 @@
+# 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. Open apps exercise MCP registration; customer-auth apps must instead pass the anonymous 401 plus exact protected-resource metadata boundary and report `interactiveRequired: true`.
+4. **Customer auth** — when customer auth is declared, run `noodle auth doctor src/server.ts --json` for metadata and JWKS readiness, then run `noodle devtools src/server.ts`, complete sign-in, and make one authenticated `tools/list` request or representative safe read. The doctor does not prove that registration or token issuance succeeds; the authenticated request proves issuer, signature, stable audience, and exact-resource binding together.
+5. **Real API** — a representative safe `noodle tools call` proves connector credentials, transport, observed mapping, and populated data.
+6. **App compliance** — `noodle check --json` and local devtools prove the App contract and intended states.
+7. **Host** — the requested host connects, invokes the expected capability, and renders useful fallback/UI behavior.
+8. **Deploy** — the requested hosted revision and configuration exist and report healthy at the deployment layer.
+9. **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.
+- A protected-boundary smoke or passing auth doctor does not prove DCR, token issuance, token audience, or authenticated MCP access.
+- 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/wrapping-existing-applications/SKILL.md

@@ -3,7 +3,7 @@ name: wrapping-existing-applications
 description: "Use when an existing application has no stable usable API and needs a read-only, identity-first Noodle Seed integration plan before implementation."
 ---
 
-<!-- noodle-skill version:0.91.0 hash:eccc3c158dcafba8 -->
+<!-- noodle-skill version:0.92.0 hash:379ab9f64878f1fe -->
 
 # wrapping-existing-applications
 
@@ -28,9 +28,9 @@ Produce the smallest safe, repository-grounded existing-application integration
 
 ## Workflow
 
-Read and follow the canonical playbook `references/wrap-existing-app.md` at `../noodle-seed/references/wrap-existing-app.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
-Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.
-Load `references/tool-design.md` at `../noodle-seed/references/tool-design.md` only when the playbook or observed evidence names that concern.
+Read and follow the canonical playbook at `references/wrap-existing-app.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
+Load the supporting reference at `references/authoring-workflow.md` only when the playbook or observed evidence names that concern.
+Load the supporting reference at `references/tool-design.md` only when the playbook or observed evidence names that concern.
 
 ## Verification evidence