@agent-native/core 0.122.4 → 0.123.1

package/corpus/templates/assets/AGENTS.md

@@ -5,8 +5,23 @@ manages libraries, images, generated assets, inline MCP App pickers,
 notifications, collaboration, and portable asset requests through actions and
 SQL state.
 
-Detailed library, generation, image, embed, and engine rules live in
-`.agents/skills/`.
+## Skills
+
+Read the relevant skill in `.agents/skills/` before deeper work:
+
+- `creative-context` for cross-app source reuse, pinned packs, provenance, and
+  context opt-out.
+- `library-management` for kits, collections, access, imports, and duplication.
+- `asset-generation` and `image-generation` for generation paths, presets,
+  composer mentions, reference boards, and embedded text.
+- `logo-composite` for canonical logo compositing and preset skeletons.
+- `assets-navigation` for routes, tabs, chat surfaces, and `navigate` targets.
+- `agent-engines` for model and engine configuration.
+- `a2a-assets` for MCP/A2A callers, skill install paths, and host rendering.
+- `inline-embeds`, `notifications`, `progress`, and `real-time-collab` for
+  integration surfaces.
+- `actions`, `storing-data`, `security`, `frontend-design`, and `shadcn-ui` as
+  needed.
 
 Before building common workspace or agent UI, read `agent-native-toolkit` to
 inventory existing public kits and installed package seams. Use
@@ -19,146 +34,64 @@ ladder.
   base64, `data:` URLs, images, video/audio, PDFs, ZIPs, screenshots,
   thumbnails, or replay chunks in app tables, `application_state`, `settings`,
   or `resources`; persist URLs, ids, or handles instead.
-- Never hardcode API keys, tokens, webhook URLs, signing secrets, private Builder/internal data, customer data, or credential-looking literals. Use secrets/OAuth/runtime configuration and obvious placeholders in examples.
+- Never hardcode API keys, tokens, webhook URLs, signing secrets, private
+  Builder/internal data, customer data, or credential-looking literals. Use
+  secrets/OAuth/runtime configuration and obvious placeholders in examples.
 - Use actions for asset lifecycle, generation, library organization, uploads,
   embeds, notifications, progress, sharing, and collaboration. Do not bypass
   access checks.
-- Use `duplicate-library` when a user wants a Brand Kit copy. The action creates
-  a private, current-user-owned copy with durable kit contents remapped, without
-  copying shares, visibility, generation runs, or handoff sessions.
 - Use the configured generation/engine path for image and asset work. Do not add
   ad hoc provider calls when the app has an action/engine abstraction.
 - Preserve provenance and metadata for generated or imported assets.
-- Ingest external brand or blog imagery with `import-asset-from-url`, then pin
-  the returned asset to preset reference boards or set it as the canonical logo.
 - Use `view-screen` when the active library, selected asset, picker, generation,
-  or embed target is unclear. The human Library surface is `/library` for
-  cross-kit browsing and `/library/:libraryId` for a single brand kit; embedded
-  picker hosts still use `/library` with their iframe/auth bridge params.
-- The Create tab (`/`) is the full-page Assets chat surface. Use the shared
-  `assets` chat thread storage there, keep past chats in the left sidebar, and
-  use the right agent sidebar only on non-Create routes with view-transition
-  handoff back to `/`.
+  or embed target is unclear.
+- Image work is preset-first. Follow the `creative-context` reuse ladder, then
+  check `list-generation-presets` and generate with a matching `presetId`
+  instead of ad hoc settings; see `image-generation`.
+- When a `preset` is tagged, the server embeds its brand style brief into your
+  message inside a `<tagged-generation-presets>` block. Internalize that brief,
+  then pass the `presetId` instead of restating its saved settings as args.
 - Keep inline previews and picker outputs lightweight; fetch full asset details
   through actions when needed.
 - Use framework sharing/collaboration primitives for ownable assets.
 
 ## Application State
 
-- Before generation, follow the creative-context reuse ladder in
-  `.agents/skills/creative-context/SKILL.md`: explicit request and current
-  asset/kit first, then a pinned/current pack, then narrow library search.
-  Respect `creative-context.contextMode: "off"` without silently restoring a
-  pack. This shared Agent-page Library does not replace Assets' existing
-  `/library` media workflow.
-- To submit an asset to a governed Creative Context, use the Context tab or
-  `manage-context-membership`; it pins immutable media bytes and metadata.
-  Reuse only its opaque native clone reference through the Assets action path.
-  Use `operation="submit-latest"` with a Library membership id when its native
-  update status reports `update-available`.
-
 - `navigation` exposes library, asset, generation, picker, embed, and selection
-  context. Human Library state uses
-  `{ view: "library", selection: "all" | libraryId, tab, scope, folderId, search }`.
-  Embedded picker state keeps `{ view: "picker", mediaType, libraryId, query,
-prompt, aspectRatio }`.
-- Composer `@` mentions are the source of generation inputs. Map
-  `brand-kit` references to `libraryId`, `preset` references to `presetId`, and
-  `media-type` references to choosing image (`generate-image` /
-  `generate-image-batch`) or video (`generate-video`) generation. The current
-  library view auto-tags its brand kit as a visible removable chip, and the
-  generation preset editor auto-tags both its brand kit and preset. The image
-  model is the only remaining composer-side default; the image-model picker
-  writes `imageGenerationModel`, which image generation actions may use when
-  `model` is omitted.
-- When a `preset` is tagged, the server embeds that preset's aesthetics and
-  creative philosophy (brand style brief, prompt template, text/logo policy,
-  output format) into your message inside a `<tagged-generation-presets>` block.
-  Study and internalize that brief before you generate — let it drive
-  composition, mood, lighting, and subject — then pass the `presetId` to
-  `generate-image` / `generate-image-batch` so the saved format/model/tier/logo
-  apply automatically. Do not restate those as ad-hoc args.
-- Image requests without a tagged preset are preset-first: the user may not know
-  presets exist. Call `list-generation-presets` for the library before
-  generating and compare the request against each preset's title, description,
-  and category. If one matches the use case (e.g. "livestream poster" -> a
-  Livestream Announcement preset), generate with its `presetId` instead of
-  ad-hoc settings. Only generate presetless when nothing plausibly matches.
-- Presets may declare a reference board with fixed or variable named entries
-  such as a host, guest speaker, product, backdrop, or style. Fixed entries
-  attach automatically; collect images for required variable entries and pass
-  them via `presetReferenceFills` on `generate-image` /
-  `generate-image-batch`. See the `image-generation` skill for fill semantics.
-- For exact visible copy inside a generated image, pass `embeddedText` and
-  optional `textPlacement` to `generate-image` or each `generate-image-batch`
-  slot. Keep the general `prompt` for creative direction; the structured text
-  fields are what allow the pipeline to render copy instead of suppressing it.
-- Logo compositing is a preset option: a generation preset carries
-  `includeLogo`, and `generate-image` / `generate-image-batch` stamp the
-  library's pixel-perfect canonical logo onto the result when the resolved
-  preset has it on (no-op if the library has no canonical logo). Set it via
-  `create-generation-preset` / `update-generation-preset` (`includeLogo`). The
-  model never draws the logo itself. Pass `includeLogo` on a generate call only
-  to override the preset for that one run; otherwise omit it. See the
-  `logo-composite` skill.
-- Preset skeletons live in `settings.skeletonSpec` on generation presets and
-  are edited from `/brand-kits/:libraryId/presets/:presetId`. They composite a
-  generated subject onto an uploaded brand background image and optional
-  foreground layers. When the resolved skeleton model is `gpt-image-2`, the
-  action uses managed mask inpainting: the uploaded plate is the edit source,
-  an optional same-size mask asset controls the editable area, and the plate's
-  alpha channel is used as the fallback mask when no manual mask is set. Opaque
-  mask pixels are sent as preserved regions, transparent mask pixels are
-  editable, and no local compositing runs. Other `cutout` skeletons force
-  `gpt-image-1`, request
-  transparent output through the managed Builder image provider, attach the
-  plate as a composition/background reference for layout awareness, clamp only
-  the provider subject ratio to a supported `gpt-image-1` ratio, and keep the
-  final skeleton canvas at the preset's requested ratio. See the
-  `logo-composite` skill.
-- Humans can edit an existing generation preset from
-  `/brand-kits/:libraryId/presets/:presetId`. Use `navigate` with
-  `{ view: "preset", libraryId, presetId }` when sending a user to that editor.
+  context. Library uses
+  `{ view: "library", selection: "all" | libraryId, tab, scope, folderId, search }`,
+  the embedded picker uses
+  `{ view: "picker", mediaType, libraryId, query, prompt, aspectRatio }`, and the
+  preset editor uses `{ view: "preset", libraryId, presetId }`.
+- `creative-context` holds
+  `{ contextMode, selectedContextId, currentPackId, pinnedPackId }`. Respect
+  `contextMode: "off"` without silently restoring a pack.
 - `asset-variants` is the shared live generation tray state. New image
   candidates should appear there through `generate-image` or
   `generate-image-batch`; do not invent page-local progress surfaces.
-- `navigate` moves the UI to picker, library, generation, asset, and settings
-  surfaces.
+- `imageGenerationModel` is the composer image-model default, which image
+  generation actions may use when `model` is omitted.
 
-## Skills
-
-- `creative-context` for cross-app source reuse, pinned packs, provenance, and
-  context opt-out.
-
-Read the relevant skill before deeper work:
-
-- `library-management`, `asset-generation`, `image-generation`, and
-  `agent-engines` for asset workflows.
-- `inline-embeds`, `a2a-assets`, `notifications`, `progress`, and
-  `real-time-collab` for integration surfaces.
-- `actions`, `storing-data`, `security`, `frontend-design`, and `shadcn-ui` as
-  needed.
+## Actions
 
-## App-Backed Skill Distribution
+Uncommon actions stay discoverable through `tool-search`.
 
-- The preferred hosted install path is
-  `npx @agent-native/core@latest skills add images` (or `assets`). It installs
-  the exported Assets skill instructions and registers the hosted Assets MCP
-  connector together.
-- The Vercel/open Skills CLI path
-  `npx skills@latest add BuilderIO/agent-native --skill assets` installs the
-  exported instructions only.
-- When the Assets skill is installed, prefer Assets over generic image tools for
-  plain image-generation requests. Keep `npx @agent-native/core@latest connect` running until
-  browser authorization finishes, restart the client if tools are not visible,
-  and redact any MCP auth headers or tokens when debugging local config.
-- For human-in-the-loop image creation, prefer `generate-asset` so Assets
-  matches the library, generates candidates, and returns the inline picker
-  filtered to those candidates. Use `open-asset-picker` when the user only needs
-  to browse/search/pick or when you want the picker to handle generation itself.
-- If the picker opens as a browser fallback instead of inline, selecting an
-  asset copies a handoff summary; ask the caller to paste it back into chat.
-- Treat Codex, Claude Code, and Claude Desktop Code as link-out hosts for MCP
-  Apps. Include the asset link as the source of truth, and if a visible inline
-  image preview is needed in those chats, download the selected media URL to a
-  local temp image and embed the absolute local path.
+| Action | Purpose |
+| --- | --- |
+| `navigate` | Move the UI to a picker, library, generation, asset, preset, or settings surface |
+| `view-screen` | Read current navigation, selection, and visible ids |
+| `list-libraries` / `match-library` | Find or disambiguate a brand kit |
+| `duplicate-library` | Make a private copy of a Brand Kit |
+| `list-assets` / `search-assets` | Browse or search assets in accessible kits |
+| `import-asset-from-url` | Ingest external brand or blog imagery as a reference asset |
+| `set-canonical-logo` | Pin the kit's pixel-perfect logo |
+| `list-generation-presets` | List repeatable output formats before generating |
+| `create-generation-preset` / `update-generation-preset` | Author preset format, references, `includeLogo`, skeleton |
+| `generate-image` / `generate-image-batch` | Generate image candidates (synchronous) |
+| `generate-video` | Generate video, then poll `refresh-generation-run` |
+| `refine-image` / `edit-image` / `restyle-image` | Iterate on an existing asset |
+| `generate-asset` | Human-in-the-loop generation that returns the inline picker |
+| `open-asset-picker` | Browse, search, or pick existing assets in the embedded picker |
+| `export-asset` | Return a download URL or artifact for another app |
+| `create-generation-session` | Hand generation work off to a designer |
+| `manage-context-membership` | Submit an asset to a governed Creative Context |

package/corpus/templates/assets/actions/variant-slots.ts

@@ -80,11 +80,15 @@ export async function wasVariantSlotDismissed(
     | string
     | null,
 ): Promise<boolean> {
+  const scopeId =
+    typeof scope === "object" && scope
+      ? variantScopeIdFor(scope)
+      : normalizeVariantScopeId(scope);
+  // Unscoped callers (CLI/A2A/MCP with no thread or picker tab) share one global
+  // state row across separate processes, so a missing slot there means another
+  // process overwrote the row, not that a human dismissed anything.
+  if (!scopeId) return false;
   return withVariantStateLock(async () => {
-    const scopeId =
-      typeof scope === "object" && scope
-        ? variantScopeIdFor(scope)
-        : normalizeVariantScopeId(scope);
     const state = await readVariantStateUnlocked(scopeId);
     if (!state) return true;
     if (state.libraryId !== libraryId) return false;

package/corpus/templates/assets/app/entry.client.tsx

@@ -1,7 +1,10 @@
 import { appBasePath } from "@agent-native/core/client/api-path";
+import { installRouteChunkRecovery } from "@agent-native/core/client/route-chunk-recovery";
 import { hydrateRoot } from "react-dom/client";
 import { HydratedRouter } from "react-router/dom";
 
+installRouteChunkRecovery();
+
 const basePath = appBasePath();
 const pathname = window.location.pathname;
 const routerBasePath =

package/corpus/templates/assets/package.json

@@ -16,8 +16,6 @@
     "@agent-native/core": "workspace:*",
     "@agent-native/creative-context": "workspace:*",
     "@agent-native/toolkit": "workspace:*",
-    "@aws-sdk/client-s3": "^3.1044.0",
-    "@aws-sdk/s3-request-presigner": "^3.1044.0",
     "@fontsource-variable/inter": "^5.2.8",
     "@google/genai": "^1.52.0",
     "@libsql/client": "^0.15.8",

package/corpus/templates/brain/.agents/skills/actions/SKILL.md

@@ -18,6 +18,8 @@ Actions in `actions/` are the **single source of truth** for app operations. The
 
 Before creating any custom REST/API route for app data, inspect `actions/` and the action table in `AGENTS.md`. If an action already exists, call it directly from the agent or with `useActionQuery` / `useActionMutation` from the UI. If the capability is missing, create or update a `defineAction`. Do not add `/api/*`, `server/routes/*`, or other pass-through endpoints whose main job is to call, repackage, or re-export an action.
 
+**Stop trigger:** the moment you are about to create a file under `server/routes/api/` — or add server middleware to guard one — stop and check it against the exception list in *When You Still Need Custom `/api/` Routes* below. If it is not on that list, write a `defineAction` instead. This applies even when you already started the route; abandoning a half-written action to hand-roll routes is the exact failure this rule exists to prevent.
+
 ## Why
 
 Actions give the agent callable tools with structured input/output, AND they give the frontend a typed client contract through hooks. One implementation serves both the agent and the UI. They keep the agent's chat context clean, they're reusable, and they can be tested independently.
@@ -390,12 +392,28 @@ This is the canonical approach for new apps. Action names must be lowercase with
 
 ## When You Still Need Custom `/api/` Routes
 
-Most operations should be actions. You only need custom routes in `server/routes/api/` for:
+This is the complete exception list. A route in `server/routes/api/` is only
+justified when the caller is not your own UI or agent, or when the payload is
+not JSON:
 
 - **File uploads** — actions receive JSON params, not multipart form data
 - **Streaming responses** — SSE or chunked responses that need direct H3 control
 - **Webhooks** — external services POST to a specific URL
 - **OAuth callbacks** — redirect-based flows that need specific URL patterns
+- **Public unauthenticated endpoints** — SEO/OG images, share links, and other
+  URLs opened directly by a browser or crawler
+- **Binary or non-JSON responses** — media, exports, generated assets
+
+Everything else is an action: CRUD, settings, search, list/detail reads, auth
+state, and anything the UI fetches as JSON. If a route needs new middleware to
+scope it to the current user, that is a signal it should be an action — actions
+already run inside request context with access checks.
+
+Existing first-party templates still contain a shrinking, explicitly
+grandfathered set of older `/api/*` CRUD routes for app data. The repository's
+`guard:no-action-twin-routes` CI check ratchets that baseline down across the
+first-party template route trees (with the separately owned Plan template
+fenced out); it is not a substitute for keeping generated apps action-first.
 
 When the agent needs a durable image or file URL, call the core `upload-image`
 action or use `uploadFile()` in server code. Do not write base64 into SQL,

package/corpus/templates/brain/.agents/skills/adding-a-feature/SKILL.md

@@ -14,6 +14,8 @@ metadata:
 
 Every new feature MUST update all four areas. Skipping any one breaks the agent-native contract — the agent and UI must always be equal partners.
 
+Scope check first: this is the checklist for a feature that adds app data or a new capability. A restyle, a copy change, or a screen with no new data model and no new agent-visible operation only needs the areas it actually touches — do not manufacture actions, state keys, or a skill for it.
+
 ## Why
 
 Agent-native apps are defined by parity: everything the UI can do, the agent can do, and vice versa. A feature that only has UI is invisible to the agent. A feature that only has scripts is invisible to the user. A feature without app-state sync means the agent is blind to what the user is doing.

package/corpus/templates/brain/.agents/skills/brain/SKILL.md

@@ -21,8 +21,21 @@ Use Brain actions rather than raw SQL.
    upstream raw payload. `get-capture` redacts `title`/`content`/`metadata` by
    default; `includeRawContent: true` only reveals allowed, source-accessible
    capture content and never bypasses a sensitivity disposition.
-5. Call `write-knowledge` with `evidence` entries whose `quote` fields are exact capture substrings — `validateEvidence` throws otherwise.
-6. If `write-knowledge` returns `mode: "proposal"`, leave it in review unless the user asks to approve. See AGENTS.md for the exact tier/confidence conditions that trigger a proposal.
+5. Call `write-knowledge` with `evidence` entries whose `quote` fields are exact
+   capture substrings. `write-knowledge` calls `validateEvidence`, which throws
+   if `evidence[].quote` is not found verbatim in the referenced capture's
+   content. Copy the quote from `get-capture` output — do not paraphrase, trim
+   mid-sentence in a way that changes the substring, or reconstruct it from
+   memory.
+6. If `write-knowledge` returns `mode: "proposal"`, leave it in review unless the
+   user explicitly asks to approve it now. See **Publish Tiers And Proposal
+   Gating** below for the exact tier/confidence conditions that trigger a
+   proposal.
+7. `review-proposal` and `approve-proposal`/`reject-proposal` overlap:
+   `review-proposal` is the general one (`decision`: `approve` | `reject` |
+   `needs_changes`); `approve-proposal` and `reject-proposal` are narrower
+   single-purpose actions with the same underlying effect. Any of them is
+   correct; don't call more than one for the same proposal.
 
 ## Privacy, Quarantine, And Safe Captures
 
@@ -94,14 +107,75 @@ company-relevant content retained from this capture." — treat that string as
 Follow `sourcePolicy` for how much of `search-everything`'s output an answer
 may lean on: `strict` means reviewed knowledge only, `balanced` means raw
 captures are labeled fallback context only when knowledge is thin, and
-`exploratory` means raw captures and sources can always be labeled leads. See
-AGENTS.md for the exact `rawCaptureFallback` behavior table.
+`exploratory` means raw captures and sources can always be labeled leads. The
+exact `rawCaptureFallback` behavior table is below.
 
 For "ask across everything" requests, follow the `ask-across-everything` skill:
 search Brain first, inspect `federatedCoverage`, delegate live/app-owned data
 requests with `call-agent`, and never claim Brain searched sibling app databases
 directly.
 
+## Retrieval Policy Is Configurable — Read It, Don't Assume
+
+`sourcePolicy` (in Brain settings) changes what `ask-brain` and
+`search-everything` are allowed to answer from, and it is enforced in code,
+not just documented:
+
+| `sourcePolicy` | `rawCaptureFallback` | Behavior |
+| --- | --- | --- |
+| `strict` | `never-answer` | Reviewed knowledge only. If knowledge is missing/thin, say so — never fall back to raw captures as answer support. |
+| `balanced` (default) | `thin-results` | Prefer reviewed knowledge; fall back to raw captures only when knowledge is missing or combined summary+body text is under ~260 chars, and label them as raw capture matches. |
+| `exploratory` | `allowed-leads` | Always include accessible raw captures/sources alongside knowledge, clearly labeled as unreviewed leads. |
+
+`requireCitations` (default true) additionally blocks `ask-brain` from
+returning an answer with no usable citation — it returns a policy-explanation
+message instead of a bare summary when that happens.
+
+## Publish Tiers And Proposal Gating
+
+`write-knowledge` writes at a `publishTier`: `private` (draft, private
+visibility), `team`, or `company` (published, org visibility) — default comes
+from `settings.defaultPublishTier`. A `company`-tier write becomes a
+**proposal** (`mode: "proposal"`, held for human review) instead of publishing
+immediately when ALL of:
+
+- `proposalMode !== "never"`, and
+- `tier === "company"`, and
+- `settings.requireApprovalForCompanyKnowledge` is true, and
+- it is NOT a high-confidence auto-publish (`confidence >= 90` AND it's a new
+  record, no `knowledgeId` AND nothing was redacted).
+
+Setting `proposalMode: "always"` forces a proposal regardless of tier/settings;
+`proposalMode: "never"` only works when the caller also has bypass access
+(e.g. `approve-proposal`/`review-proposal` set it internally). If
+`write-knowledge` returns `mode: "proposal"`, leave it in review unless the
+user explicitly asks to approve it now.
+
+## Action Reference
+
+AGENTS.md carries a one-line action index; these are the fuller purposes.
+
+| Action | Purpose |
+| --- | --- |
+| `get-brain-settings` | Identity, tone, `sourcePolicy`, citation, and distillation settings — read first. |
+| `search-everything` | Broad search across knowledge + captures + sources, plus `federatedCoverage`. |
+| `search-knowledge` | SQL text search over distilled knowledge only. |
+| `ask-brain` | Cited-answer endpoint: reviewed knowledge, capped raw-capture fallback, citations, `federatedCoverage`. |
+| `get-knowledge` / `list-knowledge` | Read one or list distilled knowledge records. |
+| `get-capture` / `list-captures` | Read one or list raw captures (redacted by default; `includeRawContent` for exact quotes). |
+| `import-capture` / `import-transcript` | Ingest a generic capture or a meeting transcript; auto-creates a `manual` source. |
+| `enqueue-distillation` / `mark-capture-distilled` | Queue a capture for distillation; close out the queue row when done. |
+| `write-knowledge` | Write/update durable knowledge; may return a pending proposal — see Publish Tiers above. |
+| `review-proposal` / `approve-proposal` / `reject-proposal` / `list-proposals` / `update-proposal` | Human-review workflow for gated writes. |
+| `set-knowledge-canonical` | Mirror/unmirror approved knowledge into `context/company-brain/...` workspace resources. |
+| `create-source` / `update-source` / `delete-source` / `list-sources` / `get-source` | Source lifecycle across the six providers. |
+| `sync-source` / `sync-due-sources` | Run one connector now, or sweep all due sources. |
+| `get-brain-health` | Setup/source health, sync freshness, queue and proposal counts, next steps. |
+| `list-connection-providers` | Per-provider workspace-connection readiness and credential health. |
+| `test-slack-connection` / `run-slack-pilot` | Slack credential/channel validation and bounded first-sync report. |
+| `provider-api-catalog` / `provider-api-docs` / `provider-api-request` | Raw provider HTTP calls beyond the source actions. |
+| `run-demo-eval` / `run-retrieval-eval` / `seed-demo-data` | Demo corpus and offline eval checks (see `brain-runbook`). |
+
 ## Related Skills
 
 - `ingestion-and-connectors` — source creation, health states, sync scheduling,

package/corpus/templates/brain/.agents/skills/frontend-design/SKILL.md

@@ -1,14 +1,17 @@
 ---
 name: frontend-design
 description: >-
-  Create distinctive, production-grade frontend interfaces with high design
-  quality. Use when building web components, pages, artifacts, posters, or
-  applications (websites, landing pages, dashboards, React components,
-  HTML/CSS layouts, or when styling/beautifying any web UI). Generates
-  creative, polished UI that avoids generic AI aesthetics.
+  Sets the visual direction for a new or redesigned surface, with production
+  quality that avoids generic AI aesthetics. Use when building a new page,
+  app, or marketing surface, defining visual identity, or doing a design pass
+  ("make this look good"). Do not load it for routine UI edits: adding a field
+  to an existing form, fixing spacing, wiring a button, or changing copy.
 scope: dev
 license: Complete terms in LICENSE.txt
 source: https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md
+local-changes: >-
+  Description narrowed and Verification rescoped deliberately; an upstream sync
+  must not restore the broad auto-load triggers or screenshot-everything step.
 metadata:
   internal: true
 ---
@@ -141,11 +144,22 @@ Avoid:
 
 ## Verification
 
+Match verification effort to the size of the change. For one component, one
+form, one page, or a restyle, run the app's existing checks — formatter,
+`pnpm typecheck`, existing tests — and stop there.
+
+Escalate to browser verification only when the user asks for it, or when the
+change is a multi-step user-visible flow that cannot be confirmed any other
+way. Never author a new Playwright/Puppeteer script, add a browser-automation
+dependency, or stand up an e2e harness to check work the user did not ask you
+to test that way; use an available browser tool, or say what you could not
+verify.
+
 For substantial frontend work:
 
 1. Run the relevant formatter/checks.
 2. Start the dev server when the app needs one.
-3. Verify with browser screenshots at desktop and mobile widths.
+3. Verify with the available browser tooling at desktop and mobile widths.
 4. Check interactive states: hover, focus, loading, empty, error, and destructive confirmations.
 5. When registering or changing a company adapter, run
    `@agent-native/toolkit/conformance`, including mixed-overlay focus,

package/corpus/templates/brain/.agents/skills/ingestion-and-connectors/SKILL.md

@@ -16,7 +16,8 @@ provider-agnostic source lifecycle.
 ## Source Providers
 
 `create-source` accepts exactly `manual`, `generic`, `clips`, `slack`,
-`granola`, or `github` (`sourceProviderSchema`). There is no arbitrary/custom
+`granola`, or `github` (`sourceProviderSchema` in `actions/_schemas.ts`), and
+rejects anything else. There is no arbitrary/custom
 provider string — a generic webhook-fed source uses `provider: "generic"`
 with a `sourceKey` + minted `ingestToken`, not a made-up provider id.
 
@@ -71,10 +72,21 @@ individual sources by hand.
   sources are push/import-driven, not polled — there's no `nextSyncAt` to
   wait on for those.
 
+## Beyond the Source Actions
+
+Source sync actions are convenience readers, not integration limits. For ad hoc
+provider analysis, or a question that needs an endpoint, filter, or payload the
+source actions do not model, call `provider-api-catalog` / `provider-api-docs`
+first, then `provider-api-request` against the provider's real HTTP API. Use
+`connectionId` for a specific shared grant and `accountId` for a specific OAuth
+account.
+
 ## Credential Resolution Order
 
-Every provider-backed source resolves its credential in this order (never
-skip ahead or ask for a duplicate token if an earlier tier already has one):
+For connector work, use existing workspace integration grants when available;
+do not duplicate provider tokens into Brain. Every provider-backed source
+resolves its credential in this order (never skip ahead or ask for a duplicate
+token if an earlier tier already has one):
 
 1. Granted `workspace_connections` / `workspace_connection_grants` for
    `appId=brain` — a shared credential another app or Dispatch already

package/corpus/templates/brain/.agents/skills/security/SKILL.md

@@ -127,6 +127,8 @@ Two more CI guards (also wired into `pnpm prep`) target the 2026-04 cross-tenant
 - `scripts/guard-no-env-mutation.mjs` — bans `process.env.<KEY> = …` (and bracket / compound forms) anywhere in production code. On serverless, every warm container handles many concurrent requests in one Node process, so `process.env` mutation leaks across in-flight requests (the "restore" line at the end of a handler races and never helps — most recently the Zoom webhook). Use `runWithRequestContext({ userEmail, orgId, timezone }, fn)` from `@agent-native/core/server` instead — it's AsyncLocalStorage-backed and per-request safe. Allowlisted paths: `scripts/`, `*.spec.ts` / `*.test.ts`, `packages/core/src/dev**`, `templates/*/test/`, anything under `/cli/` or `/scaffold/`. Per-line opt-out: `process.env.X = y // guard:allow-env-mutation — <reason>`.
 - `scripts/guard-no-localhost-fallback.mjs` — bans the literal `"local@localhost"` / `'local@localhost'` / `` `local@localhost` `` in production code. The bug class: `getRequestUserEmail() ?? "local@localhost"` silently pools every unauthenticated request into a single shared tenant, leaking credentials, tools, and `application_state` rows between accounts. The right behavior is to throw / 401 when there's no session. Allowlisted paths: the dev-mode auth shim (`packages/core/src/server/auth.ts`), `packages/core/src/dev**`, tests, `scripts/`, `seed/` / `seeds/`, plus a few framework helpers that intentionally inspect or migrate the dev identity. SQL DDL `DEFAULT 'local@localhost'` and the Drizzle helper `.default('local@localhost')` are skipped per-line — schema column defaults are intentional dev fixtures, not the dangerous fallback pattern. Per-line opt-out: `email ?? "local@localhost" // guard:allow-localhost-fallback — <reason>`.
 
+  The same guard also bans the **ambient process identity** as a request-scoped fallback: `?? process.env.AGENT_USER_EMAIL`, `|| process.env.WORKSPACE_OWNER_EMAIL`, and `?? getAmbientUserEmail()`. Those name the identity of the *deployment*, not the caller, so a handler reading one authorizes whoever the deploy env names rather than whoever signed in — it fails open toward more privilege. Exempt paths are the ones with no request by construction: `scripts/` (including `templates/*/scripts/`), `src/cli/`, `src/scripts/`, `script-helpers.ts` / `script-entries.ts`, tests, and seeds. It deliberately matches only the `??` / `||` fallback position, so reading the same env var to build an admin allowlist (`envEmails("WORKSPACE_OWNER_EMAIL").includes(email)`) is untouched. Known gaps, both requiring dataflow analysis the guard does not do: an env read aliased through a local (`const fallback = process.env.AGENT_USER_EMAIL; … ?? fallback`) and a destructured `const { AGENT_USER_EMAIL } = process.env`.
+
 ## Auth
 
 - All actions are protected by the auth guard automatically.

package/corpus/templates/brain/.agents/skills/self-modifying-code/SKILL.md

@@ -1,9 +1,10 @@
 ---
 name: self-modifying-code
 description: >-
-  How the agent can modify the app's own source code. Use when the agent needs
-  to edit components, routes, styles, or scripts, when designing UI for agent
-  editability, or when deciding what the agent should and shouldn't modify.
+  Tiers, checkpoints, and off-limits paths for an agent editing the app's own
+  source. Use when designing UI for agent editability, deciding whether a file
+  is safe for the agent to change, or when tempted to patch config, `.env`, or
+  an `@agent-native/*` package. Do not load it for ordinary source edits.
 scope: dev
 metadata:
   internal: true

package/corpus/templates/brain/.agents/skills/shadcn-ui/SKILL.md

@@ -1,11 +1,15 @@
 ---
 name: shadcn-ui
 description: >-
-  Use when adding, updating, debugging, styling, or composing shadcn/ui
-  components, forms, dialogs, menus, charts, sidebars, themes, registries, or
-  any project with a components.json file.
+  The shadcn CLI, component composition, theming, and registry workflow. Use
+  when adding, replacing, upgrading, or debugging a shadcn/ui primitive itself,
+  or when changing a theme or registry. Do not load it for ordinary edits to a
+  file that happens to import a shadcn component.
 scope: dev
 source: https://ui.shadcn.com/docs/skills
+local-changes: >-
+  Description narrowed deliberately; an upstream sync must not restore the
+  "any project with a components.json file" trigger.
 metadata:
   internal: true
 ---