@noodleseed/agent-kit 0.77.0 → 0.79.0

package/skills/codex/references/embedded-assistant.md

@@ -5,6 +5,7 @@
 - Architecture
 - Choose the host experience
 - Author and validate
+- Product workflow guidance
 - Customize the presentation
 - Configure and deploy
 - Access modes and customer auth
@@ -61,6 +62,14 @@ assistant: embeddedAssistant({
 
 Origins are exact: scheme, host, and optional port, with no path, trailing slash, or wildcard. Production origins must be HTTPS; plain HTTP is accepted only for loopback development origins (`http://localhost:<port>`, `http://127.0.0.1:<port>`). `noodle dev` serves the MCP project, not the embedding SaaS.
 
+## Product workflow guidance
+
+Decide whether the product needs `agentGuide` even when the builder does not name it. Multiple permission-gated capabilities, ordered multi-tool work, product-specific grounding, and consequential boundaries are strong signals. Keep `server.instructions` concise and global; put workflow triggers, ordering, and permission-specific prose in the guide. Global guide description, use cases, and boundaries must be safe for every exposed assistant surface.
+
+After deployment, the embedded assistant automatically projects the typed guide into compact server-side model context on every turn. It keeps only complete workflows supported by that session surface and by the exact model-visible tools allowed for the backend-verified roles and scopes. A member and an administrator can therefore receive different workflow guidance from the same deployment. Mixed anonymous sessions retain only the explicitly selected surface and sign-in workflows; the next turn is reprojected after successful elevation.
+
+No renderer prop, browser package field, or second skill installation is required. The managed Web Component, React component, headless hook, and public client all share the same server-side turn path. Raw guide content and generated skill files never enter session responses or browser events. Missing, incompatible, empty, or oversize guidance is omitted without changing the tool surface or breaking an otherwise valid turn.
+
 ### Surfaces: one assistant, every front door
 
 A product usually has more than one front door — a marketing site and a signed-in app. One assistant (one brand, one model, one UI) projects onto both; pass `access` an array and each surface owns its own origins and allowlist:

package/skills/codex/references/product-agent-guides.md

@@ -20,7 +20,7 @@ Make the judgment from the user’s stated outcome and grounded product evidence
 
 Noodle workflow skills teach a coding agent how to build and operate Noodle projects. The generated app product skill is team-local guidance for using one product. A marketplace plugin is a separate host distribution bundle.
 
-A host-neutral distribution metadata and archive framework now exists, but per-app marketplace plugin generation is not available until a target adapter lands, and customer-agent distribution is not available. If the user asks for either, explain the boundary and stop at the proven local App Package, product-skill, and metadata work. Do not claim a target bundle, submission, hosted distribution, or customer-agent projection.
+Host-neutral distribution metadata, available target adapters, local exports, and deployment-bound archives are separate projections from the guide; use the live command catalog for exact target availability, and never claim that an export submitted or published itself. The deployed embedded assistant automatically consumes a compact authorization-aware guide projection. A direct external agent connected to the tenant MCP URL can discover the deployment skill through the modern draft MCP Skills extension when its host supports that extension; this is protocol delivery, not evidence of host support or marketplace installation.
 
 ## Creation workflow
 
@@ -38,7 +38,11 @@ The guide contains `description`, `useWhen`, named `workflows`, optional `bounda
 
 Keep identifiers within 200 characters and prose within 4,000 characters. A guide has at most 32 `useWhen` entries, 32 workflows, 64 steps per workflow, 64 boundaries, and 64 examples. The compiler rejects an App Package whose bounded derived MCP surface would still exceed its artifact ceiling.
 
-Use `server.instructions` for a concise live MCP-session primer. Noodle-owned workflow skills teach how to build and operate Noodle projects; a product guide teaches agents how to use this one deployed product. Compilation validates references and produces an App Package sibling while the RuntimeArtifact deliberately omits guide prose.
+Use `server.instructions` for concise global behavior that applies to every turn and caller. Put product workflow ordering, triggers, and workflow-specific permission guidance in `agentGuide`; global description, `useWhen`, and boundaries must be safe for every assistant surface. Noodle-owned workflow skills teach how to build and operate Noodle projects; a product guide teaches agents how to use this one deployed product. Compilation validates references and produces an App Package sibling while the RuntimeArtifact deliberately omits guide prose.
+
+For a deployed embedded assistant, Noodle automatically derives bounded server-side model guidance from that App Package. Each turn retains only complete workflows supported by the session surface and the exact model-visible tools allowed for the verified roles and scopes. All managed, React, headless, and public-client renderers benefit without a new browser option; raw guide and skill files never enter the browser response. An unavailable or oversize projection is omitted without widening tools or failing the turn.
+
+For a direct modern MCP connection, use the deployment tenant MCP URL and its existing OAuth flow; do not install a second skill or create another auth integration. `skills/list`, `skills/get`, and the related `resources/read` files are rebuilt from the same deployment package for the verified caller. Only complete workflows backed by currently authorized, model-visible tools and available resources or prompts survive; app-only helpers and forbidden tools stay out of both the workflow body and MCP-surface reference. The response is private with zero freshness, and each file has a caller-specific SHA-256 digest. A role or scope change can therefore change the next response and its digest, allowing a supporting host to require fresh approval. Legacy MCP clients and modern hosts without Skills support continue to use the ordinary capability surface.
 
 ## Local lifecycle
 

package/skills/codex/references/sdk-surface.md

@@ -74,6 +74,7 @@ Platform helper connectors are explicit subpath imports from `@noodleseed/one/pl
 
 - `server(name, options, definitions)` — `options` commonly includes `title`, `version`, `instructions`, `agentGuide`, `distribution`, `branding`, `auth`, `use`, `provides`, `state`, and `handoff`; `definitions` is the array of tools/resources/prompts.
 - `tool(name, { description, input, output, annotations?, visibility?, view?, fulfil })` — `input`/`output` are Zod schemas; `fulfil({ input, connectors, user })` returns data matching `output`. Add `view: { component, entry }` for a React widget; use `visibility: ["app"]` for an app-only helper.
+- Keep tool input names application-owned and meaningful; `__noodleIntent` is reserved for an optional serve-time operator analytics adapter and never reaches `fulfil`.
 - `resource(name, { uri, description?, mimeType?, fulfil })` and `prompt(name, { description?, arguments?, fulfil })` expose MCP resources/prompts.
 - View metadata (`viewTitle`, `viewDescription`, `csp`, `domain`, `permissions`) belongs on the tool that renders it; `asset("./path")` packages local files.
 - `customerAuth.*(...)` belongs in `server` options when deployed customer callers need verified identity; inspect `examples/customer-auth` or `examples/sharepoint` before using it.

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.77.0 hash:0f404109f4845683 -->
+<!-- noodle-skill version:0.79.0 hash:0f404109f4845683 -->
 
 # 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.77.0 hash:6ef6ef551e26b78e -->
+<!-- noodle-skill version:0.79.0 hash:6ef6ef551e26b78e -->
 
 # verifying-mcp-delivery
 

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.77.0 hash:eccc3c158dcafba8 -->
+<!-- noodle-skill version:0.79.0 hash:eccc3c158dcafba8 -->
 
 # wrapping-existing-applications