@agent-native/core 0.119.4 → 0.119.5

package/corpus/README.md

@@ -30,4 +30,4 @@ rg -n "defineAction|useActionQuery" node_modules/@agent-native/core/corpus
 
 - core files: 1660
 - toolkit files: 159
-- template files: 6327
+- template files: 6330

package/corpus/core/CHANGELOG.md

@@ -1,5 +1,13 @@
 # @agent-native/core
 
+## 0.119.5
+
+### Patch Changes
+
+- 13eb9f7: Fix AI SDK provider engines being unusable on bundled serverless deploys, and stop rewriting custom model IDs on save/read.
+  - **Serverless package detection.** `isAgentEnginePackageInstalled` relied on `require.resolve`, which fails on bundled serverless runtimes (Vercel/Netlify via Nitro) where optional provider packages (`ai`, `@ai-sdk/*`) are inlined into the function bundle. Every engine-usability gate then rejected the AI SDK engines and the agent silently fell back to the native Anthropic engine. Package resolution now treats a resolve miss as available only when there is real evidence of a bundled runtime (Vercel/Netlify markers, or a bundle-output module path), and defers to the engine's own dynamic `import()` as the real gate. Generic container/Lambda/Cloud Run deploys that ship a real `node_modules` still surface genuine "package not installed" misses.
+  - **Custom model preservation.** `normalizeModelForEngine` replaced any unrecognized model ID with the engine default when the settings actions passed a static registry entry, so a custom OpenAI-compatible gateway model (e.g. an Ollama model) reverted to the OpenAI default on save and read. The set/list/app-default actions now resolve the OpenAI-compatible-endpoint capability (`resolveEnginePreservesCustomModels`) and pass it through, preserving custom IDs verbatim — including version-shaped IDs — while first-party OpenAI still normalizes unknown IDs to a supported model.
+
 ## 0.119.4
 
 ### Patch Changes

package/corpus/core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.119.4",
+  "version": "0.119.5",
   "description": "Framework for agent-native application development — where AI agents and UI share SQL state, actions, and context",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {

package/corpus/core/src/agent/engine/index.ts

@@ -25,6 +25,8 @@ export {
   getConfiguredEngineNameForRequest,
   getStoredModelForEngine,
   normalizeModelForEngine,
+  resolveEnginePreservesCustomModels,
+  type NormalizeModelOptions,
   detectEngineFromEnv,
   detectEngineFromEnvForRequest,
   detectEngineFromUserSecrets,

package/corpus/core/src/agent/engine/registry.ts

@@ -96,6 +96,42 @@ function packageNameFromInstallSpecifier(specifier: string): string | null {
   return versionIndex === -1 ? trimmed : trimmed.slice(0, versionIndex);
 }
 
+/**
+ * True only when there is positive evidence this module is executing from a
+ * bundled serverless function where optional dependencies were inlined into the
+ * bundle and are therefore NOT resolvable via `require.resolve` — even though
+ * the dynamic `import()` the engine uses to load them still works.
+ *
+ * Deliberately narrow. The Nitro Vercel/Netlify presets (which agent-native's
+ * own `deploy` command emits) inline optional peers and always set these env
+ * markers, so they are a reliable signal. Other serverless runtimes — a
+ * container on Cloud Run / Google Cloud Functions (`K_SERVICE` /
+ * `FUNCTION_TARGET`), or a plain AWS Lambda — commonly ship a real
+ * `node_modules` where `require.resolve` is authoritative; there a resolve miss
+ * means the package is genuinely absent and must NOT be masked. Those runtimes
+ * are still covered *when the code is actually bundled*, via the module-path
+ * check below, which stays false for a normal `node_modules` layout.
+ */
+function isBundledServerlessRuntime(): boolean {
+  const env = process.env;
+  // Nitro's Vercel/Netlify presets inline optional peers into the function
+  // bundle; these platforms always set these markers.
+  if (env.VERCEL || env.NETLIFY) return true;
+  // Otherwise require direct evidence that this module is running from inside a
+  // bundle output directory (Vercel's `/var/task`, Nitro's `.output/server`,
+  // inlined `_libs`). This is the real signal that `require.resolve` cannot be
+  // trusted; it stays false for normal `node_modules` layouts (dev, tests, and
+  // container/Lambda/Cloud Run deploys that ship their dependencies), so a
+  // genuine "package not installed" miss still surfaces there.
+  try {
+    return /[\\/](?:_libs|\.vercel|\.netlify|\.output)[\\/]|\/var\/task\//.test(
+      import.meta.url ?? "",
+    );
+  } catch {
+    return false;
+  }
+}
+
 function canResolvePackage(packageName: string): boolean {
   const cached = _packageAvailabilityCache.get(packageName);
   if (cached !== undefined) return cached;
@@ -104,7 +140,15 @@ function canResolvePackage(packageName: string): boolean {
     require.resolve(packageName);
     available = true;
   } catch {
-    available = false;
+    // Bundled serverless runtimes (e.g. Nitro on Vercel/Netlify) inline optional
+    // provider packages into the function bundle, so require.resolve cannot find
+    // them even though the dynamic `import()` the engine actually uses to load
+    // them works. Treat them as available there and let the engine's own import
+    // be the real gate — it already fails with a clear "pnpm add …" message when
+    // the package is genuinely missing. Without this, every engine-usability
+    // gate rejects the AI-SDK engines at runtime and the agent silently falls
+    // back to the native Anthropic engine.
+    available = isBundledServerlessRuntime();
   }
   _packageAvailabilityCache.set(packageName, available);
   return available;
@@ -179,17 +223,41 @@ function findLatestSupportedVersionMatch(
   return best?.model;
 }
 
+export interface NormalizeModelOptions {
+  /**
+   * Force unrecognized (custom) model IDs to be kept verbatim, as if
+   * `engine.preserveCustomModels` were set on a live engine instance.
+   *
+   * The settings actions call `normalizeModelForEngine` with a static registry
+   * ENTRY, which never carries the runtime `preserveCustomModels` flag — that
+   * is only set on the engine INSTANCE created with an OpenAI-compatible
+   * `baseUrl`. They resolve the capability with
+   * {@link resolveEnginePreservesCustomModels} and pass it here so a gateway
+   * model (e.g. an Ollama `gemma4`) is not rewritten to the OpenAI default on
+   * save/read. First-party OpenAI (no gateway) leaves this unset, so an unknown
+   * or invalid model still normalizes to a supported one.
+   */
+  preserveCustomModels?: boolean;
+}
+
 export function normalizeModelForEngine(
   engine: Pick<
     AgentEngine,
     "name" | "defaultModel" | "supportedModels" | "preserveCustomModels"
   >,
   model: string | null | undefined,
+  options: NormalizeModelOptions = {},
 ): string {
   const candidate = typeof model === "string" ? model.trim() : "";
   if (!candidate) return engine.defaultModel;
 
-  if (engine.preserveCustomModels) return candidate;
+  // Preserve custom IDs verbatim BEFORE any catalog/version matching, so a
+  // version-shaped gateway model that happens to share a family with a
+  // built-in model (e.g. `gpt-5.4` on an OpenAI-compatible endpoint) is not
+  // rewritten to a catalog entry.
+  if (engine.preserveCustomModels || options.preserveCustomModels) {
+    return candidate;
+  }
 
   if (engine.supportedModels.length === 0) return candidate;
 
@@ -203,6 +271,31 @@ export function normalizeModelForEngine(
   );
 }
 
+/**
+ * Whether models saved or read for this engine ENTRY should be preserved
+ * verbatim instead of normalized against the built-in catalog.
+ *
+ * `normalizeModelForEngine` honors a live engine's `preserveCustomModels`, but
+ * that flag is only set on an AI SDK engine INSTANCE when the OpenAI provider
+ * is pointed at an OpenAI-compatible gateway (a custom base URL — e.g. Ollama
+ * Cloud or LiteLLM), whose model IDs are not in the built-in OpenAI catalog.
+ * The static registry entry the settings actions pass to
+ * `normalizeModelForEngine` cannot carry that runtime flag, so this async
+ * helper reproduces the same decision — `ai-sdk:openai` AND a resolved base URL
+ * — from the request's stored/deploy config. First-party OpenAI (no gateway)
+ * returns false so an unknown/invalid model still normalizes to a supported one.
+ */
+export async function resolveEnginePreservesCustomModels(
+  entry: Pick<AgentEngineEntry, "name">,
+): Promise<boolean> {
+  if (entry.name !== "ai-sdk:openai") return false;
+  try {
+    return Boolean(await resolveOpenAiBaseUrl());
+  } catch {
+    return false;
+  }
+}
+
 function assertAgentEnginePackageInstalled(entry: AgentEngineEntry): void {
   if (isAgentEnginePackageInstalled(entry)) return;
   const installHint = entry.installPackage

package/corpus/core/src/scripts/agent-engines/list-agent-engines.ts

@@ -13,6 +13,7 @@ import {
   isAgentEnginePackageInstalled,
   isStoredEngineUsableForRequest,
   normalizeModelForEngine,
+  resolveEnginePreservesCustomModels,
 } from "../../agent/engine/index.js";
 import type { ActionTool } from "../../agent/types.js";
 import { getSetting } from "../../settings/index.js";
@@ -82,11 +83,18 @@ export async function run(args: Record<string, string> = {}): Promise<string> {
         ? current?.model
         : undefined;
   const currentEngineName = currentEntry?.name ?? "anthropic";
+  // Resolve the OpenAI-compatible-endpoint capability so a custom gateway model
+  // is reported as-is instead of being normalized to the engine default — the
+  // read-side counterpart of the same fix in set-/manage-agent-engine.
+  const preserveCustomModels = currentEntry
+    ? await resolveEnginePreservesCustomModels(currentEntry)
+    : false;
   const currentModel =
     currentEntry && !envUnavailable
       ? normalizeModelForEngine(
           currentEntry,
           currentModelCandidate ?? currentEntry.defaultModel,
+          { preserveCustomModels },
         )
       : (currentModelCandidate ?? DEFAULT_MODEL);
   const result = {

package/corpus/core/src/scripts/agent-engines/manage-agent-engine.ts

@@ -16,6 +16,7 @@ import {
   getAgentEngineEntry,
   isAgentEnginePackageInstalled,
   normalizeModelForEngine,
+  resolveEnginePreservesCustomModels,
   registerBuiltinEngines,
 } from "../../agent/engine/index.js";
 import type { ActionTool } from "../../agent/types.js";
@@ -113,7 +114,10 @@ async function runSetAppDefault(args: Record<string, string>): Promise<string> {
   if (!isAgentEnginePackageInstalled(entry)) {
     return `Error: Engine "${engine}" requires optional packages that are not installed in this app. Run: pnpm add ${entry.installPackage}`;
   }
-  const normalizedModel = normalizeModelForEngine(entry, model);
+  const preserveCustomModels = await resolveEnginePreservesCustomModels(entry);
+  const normalizedModel = normalizeModelForEngine(entry, model, {
+    preserveCustomModels,
+  });
 
   const ctx = currentContext();
   const canUpdate = await canUpdateAgentAppModelDefaultSettings(

package/corpus/core/src/scripts/agent-engines/set-agent-engine.ts

@@ -8,6 +8,7 @@ import {
   isAgentEnginePackageInstalled,
   isStoredEngineUsableForRequest,
   normalizeModelForEngine,
+  resolveEnginePreservesCustomModels,
   registerBuiltinEngines,
 } from "../../agent/engine/index.js";
 import type { ActionTool } from "../../agent/types.js";
@@ -54,7 +55,14 @@ export async function run(args: Record<string, string>): Promise<string> {
   }
 
   const requestedModel = model ?? entry.defaultModel;
-  const resolvedModel = normalizeModelForEngine(entry, requestedModel);
+  // A static registry entry can't carry the runtime `preserveCustomModels`
+  // flag, so resolve the OpenAI-compatible-endpoint capability here and pass it
+  // through — otherwise a gateway model (e.g. an Ollama id) is rewritten to the
+  // engine default on save.
+  const preserveCustomModels = await resolveEnginePreservesCustomModels(entry);
+  const resolvedModel = normalizeModelForEngine(entry, requestedModel, {
+    preserveCustomModels,
+  });
 
   const usable = await isStoredEngineUsableForRequest(
     { engine: engineName },

package/corpus/templates/slides/actions/patch-deck.ts

@@ -26,6 +26,7 @@ import { z } from "zod";
 import { normalizeSlidePadding } from "../app/lib/normalize-slide-padding.js";
 import { getDb, schema } from "../server/db/index.js";
 import { notifyClients } from "../server/handlers/decks.js";
+import { ASPECT_RATIO_VALUES } from "../shared/aspect-ratios.js";
 
 // ---------------------------------------------------------------------------
 // Per-deck write lock — same pattern as add-slide.ts so all client and agent
@@ -122,7 +123,7 @@ const PatchDeckFieldsOp = z.object({
       tweaks: z
         .record(z.string(), z.union([z.string(), z.number(), z.boolean()]))
         .optional(),
-      aspectRatio: z.string().optional(),
+      aspectRatio: z.enum(ASPECT_RATIO_VALUES).optional(),
       shareToken: z.string().optional(),
       visibility: z.enum(["private", "org", "public"]).optional(),
     })

package/corpus/templates/slides/changelog/2026-07-23-opening-or-refining-a-deck-no-longer-crashes-with-a-blank-er.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-07-23
+---
+
+Opening or refining a deck no longer crashes with a blank error screen when the deck has an unrecognized aspect ratio

package/corpus/templates/slides/shared/aspect-ratios.ts

@@ -30,5 +30,8 @@ export const ASPECT_RATIO_VALUES = ["16:9", "1:1", "9:16", "4:5"] as const;
 export const DEFAULT_ASPECT_RATIO: AspectRatio = "16:9";
 
 export function getAspectRatioDims(ratio: AspectRatio | undefined | null) {
-  return ASPECT_RATIOS[ratio ?? DEFAULT_ASPECT_RATIO];
+  if (ratio && Object.prototype.hasOwnProperty.call(ASPECT_RATIOS, ratio)) {
+    return ASPECT_RATIOS[ratio];
+  }
+  return ASPECT_RATIOS[DEFAULT_ASPECT_RATIO];
 }

package/corpus/templates/tasks/.oxfmtrc.json

@@ -0,0 +1,8 @@
+{
+  "tabWidth": 2,
+  "useTabs": false,
+  "printWidth": 80,
+  "trailingComma": "all",
+  "proseWrap": "preserve",
+  "sortImports": true
+}

package/corpus/templates/tasks/AGENTS.md

@@ -7,6 +7,11 @@ inventory existing public kits and installed package seams. Use
 `customizing-agent-native` for the configure → compose → eject → propose seam
 ladder.
 
+## Authoritative References
+
+- [Feature docs](./docs/features/README.md) define product behavior and feature status.
+- [Action definitions](./actions/) contain the canonical tool descriptions, input schemas, and implementations.
+
 ## Core Rules
 
 - 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.
@@ -16,34 +21,38 @@ ladder.
 - Keep the action surface small: task CRUD actions plus `reorder-tasks`, `view-screen`, and `navigate`.
 - Do not use `db-query` for normal task operations.
 - Call `view-screen` first when the user's visible task context matters (especially on `/tasks`).
+- Tasks are private to each user. Preserve `ownerEmail` scoping unless intentionally implementing sharing.
+- The task detail panel exposes `tasks.task-detail.bottom` as an `ExtensionSlot` with `slotContext` containing `taskId`, `title`, `done`, and `fieldValues`.
 
 ## Actions
 
-| Action                       | Method | Purpose                                                                                      |
-| ---------------------------- | ------ | -------------------------------------------------------------------------------------------- |
-| `list-tasks`                 | GET    | List current user's tasks; `includeDone` and `includeFields` default to false                |
-| `create-task`                | POST   | Create a task with `title`                                                                   |
-| `update-task`                | POST   | Patch `title`, `done`, and/or `fieldValues` by `taskId`                                      |
-| `delete-task`                | POST   | Delete a task by `taskId` (confirm with user first)                                          |
-| `bulk-update-tasks`          | POST   | Patch `title` and/or `done` on multiple tasks by id                                          |
-| `bulk-delete-tasks`          | POST   | Delete multiple tasks by id (confirm with user first)                                        |
-| `reorder-tasks`              | POST   | Reorder visible tasks by id list top-to-bottom                                               |
-| `list-inbox-items`           | GET    | List current user's inbox items                                                              |
-| `create-inbox-item`          | POST   | Create a not-ready inbox item with `title` (default chat capture)                            |
-| `update-inbox-item`          | POST   | Patch inbox item `title` by `inboxItemId`                                                    |
-| `delete-inbox-item`          | POST   | Delete an inbox item (confirm with user first)                                               |
-| `mark-inbox-item-ready`      | POST   | Promote inbox item to an incomplete task                                                     |
-| `reorder-inbox-items`        | POST   | Reorder inbox items by id list top-to-bottom                                                 |
-| `list-custom-fields`         | GET    | List custom field definitions                                                                |
-| `create-custom-field`        | POST   | Create a custom field definition with `title`, `type`, and optional `config`                 |
-| `update-custom-field`        | POST   | Patch a field definition `title` and/or type-compatible `config`; type is immutable          |
-| `delete-custom-field`        | POST   | Delete a field definition and its values on every task (confirm with user first)             |
-| `reorder-custom-fields`      | POST   | Reorder custom field definitions by id list top-to-bottom                                    |
-| `list-visible-task-fields`   | GET    | List custom field ids shown on task cards for the current user                               |
-| `update-visible-task-fields` | POST   | Replace which custom fields appear on task cards (max 3)                                     |
-| `view-screen`                | —      | Read navigation, UI bulk selection, visible tasks, and inbox snapshot                        |
-| `navigate`                   | —      | Move UI to a view: `tasks`, `inbox`, `fields`, `extensions`, `team` (`home`/`ask` → `tasks`) |
-| `render-task-list-inline`    | —      | Render an interactive task-list widget inline in chat without leaving the current view       |
+| Action                        | Method | Purpose                                                                                      |
+| ----------------------------- | ------ | -------------------------------------------------------------------------------------------- |
+| `list-tasks`                  | GET    | List current user's tasks; `includeDone` and `includeFields` default to false                |
+| `create-task`                 | POST   | Create a task with `title`                                                                   |
+| `update-task`                 | POST   | Patch `title`, `done`, and/or `fieldValues` by `taskId`                                      |
+| `delete-task`                 | POST   | Delete a task by `taskId` (confirm with user first)                                          |
+| `bulk-update-tasks`           | POST   | Patch `title` and/or `done` on multiple tasks by id                                          |
+| `bulk-delete-tasks`           | POST   | Delete multiple tasks by id (confirm with user first)                                        |
+| `reorder-tasks`               | POST   | Reorder visible tasks by id list top-to-bottom                                               |
+| `list-inbox-items`            | GET    | List current user's inbox items                                                              |
+| `create-inbox-item`           | POST   | Create a not-ready inbox item with `title` (default chat capture)                            |
+| `update-inbox-item`           | POST   | Patch inbox item `title` by `inboxItemId`                                                    |
+| `delete-inbox-item`           | POST   | Delete an inbox item (confirm with user first)                                               |
+| `bulk-delete-inbox-items`     | POST   | Delete multiple inbox items by id (confirm with user first)                                  |
+| `mark-inbox-item-ready`       | POST   | Promote inbox item to an incomplete task                                                     |
+| `bulk-mark-inbox-items-ready` | POST   | Promote multiple inbox items to incomplete tasks by id                                       |
+| `reorder-inbox-items`         | POST   | Reorder inbox items by id list top-to-bottom                                                 |
+| `list-custom-fields`          | GET    | List custom field definitions                                                                |
+| `create-custom-field`         | POST   | Create a custom field definition with `title`, `type`, and optional `config`                 |
+| `update-custom-field`         | POST   | Patch a field definition `title` and/or type-compatible `config`; type is immutable          |
+| `delete-custom-field`         | POST   | Delete a field definition and its values on every task (confirm with user first)             |
+| `reorder-custom-fields`       | POST   | Reorder custom field definitions by id list top-to-bottom                                    |
+| `list-visible-task-fields`    | GET    | List custom field ids shown on task cards for the current user                               |
+| `update-visible-task-fields`  | POST   | Replace which custom fields appear on task cards (max 3)                                     |
+| `view-screen`                 | —      | Read navigation, UI bulk selection, visible tasks, and inbox snapshot                        |
+| `navigate`                    | —      | Move UI to a view: `tasks`, `inbox`, `fields`, `extensions`, `team` (`home`/`ask` → `tasks`) |
+| `render-task-list-inline`     | —      | Render an interactive task-list widget inline in chat without leaving the current view       |
 
 ## Store Functions And Transactions
 
@@ -80,22 +89,6 @@ export type DbHandle = Pick<
 
 ## Commit Message Conventions
 
-- Never include `Made-with: Cursor` in commit messages. Remove it if it appears
-  in a generated message.
-- Use one of these prefixes:
-  - `feature: ...` or `feature(PROJECT): ...`
-  - `fix: ...` or `fix(PROJECT): ...`
-  - `refactor: ...` or `refactor(PROJECT): ...`
-  - `technical: ...` or `technical(PROJECT): ...`
-  - `chore: ...` or `chore(PROJECT): ...`
-- `PROJECT` is optional. If provided, it must be one of `generator` or `web`.
-- Before creating any commit, always:
-  - ask for confirmation,
-  - show the proposed commit message first,
-  - commit only after explicit user approval.
-
-## Commit Message Conventions
-
 - Never include `Made-with: Cursor` in commit messages. Remove it if it appears
   in a generated message.
 - Use one of these prefixes:

package/corpus/templates/tasks/README.md

@@ -4,13 +4,20 @@ Task-list-first agent-native app. Default home is `/tasks`; chat handles capture
 
 ## TODO
 
-- [ ] **i18n** — Add `app/i18n/` catalogs (`en-US` + locale mirrors) and migrate UI copy from raw literals to `useT()`. Remove tasks strings from `scripts/i18n-raw-literal-baseline.txt` once migrated.
-- [ ] **Delete dialog wiring** — `TaskList` and `InboxList` duplicate single/bulk delete dialog state (`pendingDeleteId`, `bulkDeleteOpen`, confirm handlers, toast on bulk success). Extract a shared hook or composer helper (e.g. `useDeleteDialogs`) that owns pending id, open state, and confirm wiring while composers pass entity labels and delete mutations.
-- [ ] Extract shared action schema helpers (e.g. `taskId` field, title patch) once the action surface grows beyond MVP.
-- [ ] Add route-level `ErrorBoundary` and `Suspense` around task list loading (align with other agent-native templates).
+- [ ] **Runtime action discovery filtering** — Update `@agent-native/core` development action discovery to exclude colocated `*.test.*`, `*.spec.*`, and helper-only modules so they are never exposed as agent tools or HTTP action routes.
+- [ ] **Optional event-triggered automations** — If Tasks needs workflows such as “when a task is completed, notify another system,” register stable domain events in `server/plugins/agent-chat.ts` and emit owner-scoped payloads from the successful write paths. Add event discovery, payload-validation, transition, and failure-isolation tests before exposing the events as a public automation contract.
 - [ ] **`view-screen` agent snapshot** — Revisit `AGENT_TASKS_LIST_CAP` in `actions/view-screen.ts`: it caps the agent tool payload (token budget), not the UI list. Confirm whether `list` / `selectedItem` / `inListSnapshot` correctly represent what the user sees, tune or document the cap, and align with UI limits if needed. Also review Zod parsing of `navigation` / app-state selection keys for strictness vs backward compatibility.
-- [ ] **Selection context** — Revisit prop drilling through `TaskList` → header/bar/rows once the composer stabilizes; a narrow context for `{ state, actions }` would trim wiring but must not blur the `dnd/` ↔ `selection/` boundary.
 - [ ] **`TaskList` optimistic state** — Refactor manual `allTasks` buffer in `app/components/tasks/TaskList.tsx` to TanStack Query `onMutate` once exit animations and reorder rollback can share one cache strategy.
 - [ ] **Exit-animation list reconcile** — Move exit-animation reconcile / `exitingIdsRef` out of `app/components/tasks/TaskList.tsx` into a neutral list helper (e.g. `use-ordered-tasks-with-exit-animation.ts`). That logic keeps completed rows visible during CSS exit when Show all is off; it is not DnD. `TaskList` should pass an ordered list into generic `SortableList`.
-- Shared `ListRowPreview` (`app/components/shared/dnd/ListRowPreview.tsx`) still duplicates row chrome; render the live row in the overlay when `SortableList` can mount previews safely (see TODO in that file).
 - [ ] **`move-tasks` / relative reorder (try on a separate branch)** — Today DnD persistence is FE-heavy: `SortableList` runs `reorderMovingItems` (`app/components/dnd/reorder-moving-items.ts`) to compute the **full visible id list**, then `TaskList` calls `reorder-tasks` with every id top-to-bottom. The BE already persists order via `server/tasks/store.ts` `reorderTasks` — no separate `bulkReorder` needed, but the **drop → order** translation is brittle (multi-select before/after/top/bottom edge cases). **Proposal:** add a relative move action, e.g. `move-tasks` with `{ taskIds, beforeId? | afterId?, includeDone? }` (or extend `reorder-tasks` with a relative mode). BE applies the block move, validates visible list / ownership, rewrites `sortOrder`, returns updated tasks. Keep **absolute** full-list `taskIds[]` as an escape hatch for agent/import flows. **FE after refactor:** dnd-kit still handles overlay/collision/optimistic UI, but on drop only derives `{ selected ids, anchor id, before | after }` from `over` + drag direction — delete most of `computeBlockInsertIndex`. **Prefer `beforeId`/`afterId` over `toIndex`** — matches user/agent language (“put these after task Z”) and avoids index ambiguity with `includeDone` / hidden rows. **Touch:** new `actions/move-tasks.ts`, `server/tasks/store.ts`, `use-tasks.ts`, `TaskList.tsx` / `InboxList.tsx`, agent prompt in `server/plugins/agent-chat.ts`, unit tests on store + thin FE mapping tests; keep `reorder-tasks` until callers migrate.
+- [ ] **List pagination + virtualization (when volume warrants)** — `listStoredItems` is unbounded and rows render unvirtualized. Fine at personal-list volumes; if lists grow, adopt mail's pattern (`useInfiniteQuery` with page size 25 + `@tanstack/react-virtual` in `EmailList.tsx`). Parked by the 2026-07-17 sibling-parity review as a latent scaling concern, not an active bug.
+
+## Optional improvements
+
+Reviewed against sibling templates (starter, mail, content, calendar, plan): none of these has an established cross-template convention to adopt, so they are optional polish rather than alignment work.
+
+- [ ] **Delete dialog wiring** — `TaskList` and `InboxList` duplicate single/bulk delete dialog state (`pendingDeleteId`, `bulkDeleteOpen`, confirm handlers, toast on bulk success); a shared `useDeleteDialogs` hook could own that wiring. Siblings: no template has a shared delete-confirm hook — each inlines shadcn `AlertDialog` per call site (calendar's `DeleteEventDialog` is feature-specific). tasks' shared `DeleteItemDialog`/`BulkDeleteDialog` components already lead here; this would be a net-new pattern, not adoption.
+- [ ] **Shared action schema helpers** — Extract shared helpers (e.g. `taskId` field, title patch) if duplication grows. Siblings: no template has generic schema helpers — every action inlines `z.object({...})` in `defineAction`; the only shared primitives are feature-specific (clips' `booleanParam`, tasks' own `boolean-query-param`). Wait for a concrete third duplication before abstracting.
+- [ ] **Custom `ErrorBoundary` copy** — tasks already exports the root-level `ErrorBoundary` (re-export from `@agent-native/core/client`), which is full boundary parity: no template has per-route boundaries, and `Suspense` only wraps `lazy()` components — data loads through react-query, not loaders. The only optional delta: mail and content (2 of 4) replace the re-export with custom copy plus `ErrorReportActions` (send feedback / open issue).
+- [ ] **Task attachments** — no `@agent-native/core/file-upload` usage anywhere, though `.gitignore` already carries the standard `data/uploads/` entry. mail/content/plan use the framework file-upload module. A product decision, not an alignment gap.
+- [ ] **Selection context** — Revisit prop drilling through `TaskList` → header/bar/rows; a narrow `{ state, actions }` context would trim wiring but must not blur the `dnd/` ↔ `selection/` boundary. Siblings: no template uses a React context for list multi-select — the universal pattern is a `useState<Set<string>>` hook plus prop drilling (mail's `EmailList` passes `selectedIds` down as props), and tasks' `use-list-selection.ts` is already the most generalized version of it.

package/corpus/templates/tasks/actions/bulk-delete-inbox-items.ts

@@ -4,16 +4,18 @@ import { z } from "zod";
 import { deleteInboxItems, requireUserEmail } from "../server/inbox/store.js";
 import { BULK_ID_LIMIT } from "../shared/bulk-limits.js";
 
+export const bulkDeleteInboxItemsSchema = z.object({
+  inboxItemIds: z
+    .array(z.string())
+    .min(1)
+    .max(BULK_ID_LIMIT)
+    .describe("Inbox item ids to delete"),
+});
+
 export default defineAction({
   description:
-    "Delete multiple inbox items permanently. Ask the user to confirm before calling.",
-  schema: z.object({
-    inboxItemIds: z
-      .array(z.string())
-      .min(1)
-      .max(BULK_ID_LIMIT)
-      .describe("Inbox item ids to delete"),
-  }),
+    "Delete multiple inbox items permanently. Use delete-inbox-item for one item. Ask the user to confirm before calling.",
+  schema: bulkDeleteInboxItemsSchema,
   run: async (args, ctx) => {
     const ownerEmail = requireUserEmail(ctx?.userEmail);
     return deleteInboxItems({

package/corpus/templates/tasks/actions/bulk-delete-tasks.ts

@@ -4,16 +4,18 @@ import { z } from "zod";
 import { deleteTasks, requireUserEmail } from "../server/tasks/store.js";
 import { BULK_ID_LIMIT } from "../shared/bulk-limits.js";
 
+export const bulkDeleteTasksSchema = z.object({
+  taskIds: z
+    .array(z.string())
+    .min(1)
+    .max(BULK_ID_LIMIT)
+    .describe("Task ids to delete"),
+});
+
 export default defineAction({
   description:
-    "Delete multiple tasks permanently. Ask the user to confirm before calling.",
-  schema: z.object({
-    taskIds: z
-      .array(z.string())
-      .min(1)
-      .max(BULK_ID_LIMIT)
-      .describe("Task ids to delete"),
-  }),
+    "Delete multiple tasks permanently. Use delete-task for one task. Ask the user to confirm before calling.",
+  schema: bulkDeleteTasksSchema,
   run: async (args, ctx) => {
     const ownerEmail = requireUserEmail(ctx?.userEmail);
     return deleteTasks({ ownerEmail, ids: args.taskIds });

package/corpus/templates/tasks/actions/bulk-mark-inbox-items-ready.ts

@@ -9,7 +9,7 @@ import { BULK_ID_LIMIT } from "../shared/bulk-limits.js";
 
 export default defineAction({
   description:
-    "Promote multiple inbox items to incomplete tasks in one atomic batch.",
+    "Promote multiple inbox items to incomplete tasks in one atomic batch, preserving their ids. Use mark-inbox-item-ready for one item.",
   schema: z.object({
     inboxItemIds: z
       .array(z.string())

package/corpus/templates/tasks/actions/bulk-update-tasks.ts

@@ -5,18 +5,20 @@ import { UserInputError } from "../server/errors.js";
 import { requireUserEmail, updateTasks } from "../server/tasks/store.js";
 import { BULK_ID_LIMIT } from "../shared/bulk-limits.js";
 
+export const bulkUpdateTasksSchema = z.object({
+  taskIds: z
+    .array(z.string())
+    .min(1)
+    .max(BULK_ID_LIMIT)
+    .describe("Task ids to update"),
+  title: z.string().min(1).optional().describe("New title for every task"),
+  done: z.boolean().optional().describe("Completion state for every task"),
+});
+
 export default defineAction({
   description:
-    "Update multiple tasks with the same title and/or completion patch.",
-  schema: z.object({
-    taskIds: z
-      .array(z.string())
-      .min(1)
-      .max(BULK_ID_LIMIT)
-      .describe("Task ids to update"),
-    title: z.string().min(1).optional().describe("New title for every task"),
-    done: z.boolean().optional().describe("Completion state for every task"),
-  }),
+    "Apply the same title and/or completion state to multiple tasks. Use update-task for one task or custom field values.",
+  schema: bulkUpdateTasksSchema,
   run: async (args, ctx) => {
     const ownerEmail = requireUserEmail(ctx?.userEmail);
     if (args.title === undefined && args.done === undefined) {

package/corpus/templates/tasks/actions/create-inbox-item.ts

@@ -5,11 +5,14 @@ import { z } from "zod";
 import { createInboxItem, requireUserEmail } from "../server/inbox/store.js";
 import type { InboxItem } from "../server/inbox/store.js";
 
+export const createInboxItemSchema = z.object({
+  title: z.string().min(1).describe("Inbox item title"),
+});
+
 export default defineAction({
-  description: "Create a not-ready inbox item with a title.",
-  schema: z.object({
-    title: z.string().min(1).describe("Inbox item title"),
-  }),
+  description:
+    "Create a not-ready inbox item for later triage. Use create-task when the user explicitly wants it added directly to the task list.",
+  schema: createInboxItemSchema,
   run: async (args, ctx) => {
     const ownerEmail = requireUserEmail(ctx?.userEmail);
     const item = await createInboxItem({ ownerEmail, title: args.title });

package/corpus/templates/tasks/actions/create-task.ts

@@ -9,7 +9,8 @@ import {
 } from "../server/tasks/store.js";
 
 export default defineAction({
-  description: "Create a new task with a title.",
+  description:
+    "Create an incomplete task directly on the task list. Use create-inbox-item for a quick capture to triage later.",
   schema: z.object({
     title: z.string().min(1).describe("Task title"),
   }),

package/corpus/templates/tasks/actions/delete-inbox-item.ts

@@ -3,12 +3,14 @@ import { z } from "zod";
 
 import { deleteInboxItem, requireUserEmail } from "../server/inbox/store.js";
 
+export const deleteInboxItemSchema = z.object({
+  inboxItemId: z.string().describe("Inbox item id"),
+});
+
 export default defineAction({
   description:
-    "Delete an inbox item permanently. Ask the user to confirm before calling.",
-  schema: z.object({
-    inboxItemId: z.string().describe("Inbox item id"),
-  }),
+    "Delete one inbox item permanently. Use bulk-delete-inbox-items for multiple items. Ask the user to confirm before calling.",
+  schema: deleteInboxItemSchema,
   run: async (args, ctx) => {
     const ownerEmail = requireUserEmail(ctx?.userEmail);
     await deleteInboxItem({ ownerEmail, id: args.inboxItemId });

package/corpus/templates/tasks/actions/delete-task.ts

@@ -5,7 +5,7 @@ import { deleteTask, requireUserEmail } from "../server/tasks/store.js";
 
 export default defineAction({
   description:
-    "Delete a task permanently. Ask the user to confirm before calling.",
+    "Delete one task permanently. Use bulk-delete-tasks for multiple tasks. Ask the user to confirm before calling.",
   schema: z.object({
     taskId: z.string().describe("Task id"),
   }),

package/corpus/templates/tasks/actions/list-inbox-items.ts

@@ -3,9 +3,11 @@ import { z } from "zod";
 
 import { listInboxItems, requireUserEmail } from "../server/inbox/store.js";
 
+export const listInboxItemsSchema = z.object({});
+
 export default defineAction({
-  description: "List inbox items for the current user (not-ready capture).",
-  schema: z.object({}),
+  description: "List not-ready inbox items awaiting triage.",
+  schema: listInboxItemsSchema,
   http: { method: "GET" },
   readOnly: true,
   run: async (_args, ctx) => {

package/corpus/templates/tasks/actions/list-visible-task-fields.ts

@@ -4,10 +4,12 @@ import { z } from "zod";
 import { requireUserEmail } from "../server/custom-fields/store.js";
 import { getTaskCardFieldIds } from "../server/user-config/store.js";
 
+export const listVisibleTaskFieldsSchema = z.object({});
+
 export default defineAction({
   description:
     "List custom field ids currently shown on task cards for the current user.",
-  schema: z.object({}),
+  schema: listVisibleTaskFieldsSchema,
   http: { method: "GET" },
   readOnly: true,
   run: async (_args, ctx) => {