@noodleseed/agent-kit 0.96.0 → 0.98.0

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

@@ -9,13 +9,14 @@ Read hosted evidence without changing target, credentials, configuration, access
 
 ## 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.
+This route is read-only. `deploy preflight` inspects authored deployment inputs with existing access; it is not `deploy` publication. This route never authorizes `login`, `logout`, `link`, `target set`, hosted secret/variable/config/access changes, publication, `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.
+For authored deployment readiness, select `deploy preflight` from the generated CLI command reference and supply the intended target. It does not configure, import dotenv, upload assets, save a retry key or publish. Routine login refresh may renew credentials. Missing-config actions are suggestions requiring separate authorization. A ready report is not backend, host or deployment evidence; publication always checks again.
 4. When the installed Developer MCP is available, call `get_context` to read the signed-in user’s current organizations and roles. Resolve the intended organization from the request or project context, then pass that explicit `org` to every scoped inspection or diagnosis tool. Never infer a remote default, and never ask the user to preselect organizations during OAuth. Treat the connection as live 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.
 

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

@@ -58,6 +58,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 - 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.
+- Authored deploy readiness: with existing access and the intended target, inspect `noodle deploy preflight --json` through the installed execution transport (`noodle-readiness.preflight_build` for plugin users). It never configures or publishes. Use all returned findings; proposed configuration commands require separate authorization. Readiness is not a backend call or hosted journey.
 - Repeated external failure: preserve passing evidence and report the sanitized failure, required authority or external state, owner, and exact next action.
 
 ## Stop conditions

package/skills/codex/reporting-noodle-feedback/SKILL.md

@@ -3,7 +3,7 @@ name: reporting-noodle-feedback
 description: "Use when a Noodle Seed bug, misleading instruction, missing capability, or concrete product improvement should be proposed to the user."
 ---
 
-<!-- noodle-skill version:0.96.0 hash:660cc6ad9469d90f -->
+<!-- noodle-skill version:0.98.0 hash:660cc6ad9469d90f -->
 
 # reporting-noodle-feedback
 

package/skills/codex/verifying-mcp-delivery/SKILL.md

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

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

@@ -58,6 +58,7 @@ Report a compact ledger for every exercised layer: command/action, target, resul
 - 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.
+- Authored deploy readiness: with existing access and the intended target, inspect `noodle deploy preflight --json` through the installed execution transport (`noodle-readiness.preflight_build` for plugin users). It never configures or publishes. Use all returned findings; proposed configuration commands require separate authorization. Readiness is not a backend call or hosted journey.
 - Repeated external failure: preserve passing evidence and report the sanitized failure, required authority or external state, owner, and exact next action.
 
 ## Stop conditions

package/skills/codex/wrapping-existing-applications/SKILL.md

@@ -3,7 +3,7 @@ name: wrapping-existing-applications
 description: "Use when an existing application has no stable usable API and needs a read-only, identity-first Noodle Seed integration plan before implementation."
 ---
 
-<!-- noodle-skill version:0.96.0 hash:379ab9f64878f1fe -->
+<!-- noodle-skill version:0.98.0 hash:379ab9f64878f1fe -->
 
 # wrapping-existing-applications
 

package/skills/codex/wrapping-existing-applications/references/authoring-workflow.md

@@ -22,7 +22,7 @@
 ## Input paths
 
 1. **Website scrape** — if the user gives a URL, scrape it for surface hints (products, services, hours, contact, pricing). Stop there: the URL does not reveal CRM, booking systems, custom APIs, auth model, eligibility rules, quoting logic, or approval flows. Those live in the business systems and the owner’s head — ask.
-2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review unsupported-body/auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
+2. **OpenAPI import** — `noodle import openapi <file>` writes a pinned project at `src/server.ts`, shared operation/tool schemas, managed auth references, and an offline contract test. Supported JSON bodies become typed `input.body`, sent unchanged; unsupported request constraints/encodings stop import before writes. It does not install dependencies or call the backend. Follow its README, run `agent:check`, and add a reviewed sandbox-operation test; compile success is not live integration proof. Review auth warnings before deployment. Modified files are preserved unless `--force` is explicit.
 3. **Upstream MCP import** — `noodle import mcp <url> --name <slug> --output <dir>` discovers `tools/list` once, validates and freezes tool schemas into TypeScript, and writes a secret-free drift snapshot. Upstream annotations are untrusted, so generated tools remain destructive confirmed actions until an author verifies and narrows them. Use `--header-env <header>=<ENV_NAME>` for import-only auth and `--check` for classified, non-mutating drift detection. Runtime never performs discovery.
 Both imports use `src/server.ts` as the declared entrypoint, include an offline compile test and `.env.example`, and write files only. Install the pinned dependencies, run the generated checks, then `noodle agents setup --apply`. Never treat generated contract tests as customer authentication or business-workflow evidence.
 4. **User interview** — Noodle does not interview; you do. Cover custom APIs/integrations, eligibility rules, quoting/approval logic, and private schemas (SQL DDL or JSON samples for custom `connector` declarations). Ask for concrete examples and sample payloads; do not guess a schema from a URL or invent endpoints.