# agent-native-tasks

Task-list-first agent-native app. Default home is `/tasks`; chat handles capture and agent operations.

## TODO

- [ ] **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.
- [ ] **`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`.
- [ ] **`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.