--- title: Tasks (markdown outliner, in development) (part 12) --- # Tasks (markdown outliner, in development) (part 12) ## What it is This is part 12 of the [Tasks (markdown outliner, in development)](tasks-v2.md) page. It carries the next stretch of the material on that page, moved here because a single page is capped at 40,000 characters. ## Where to find it Reach this part through [Tasks (markdown outliner, in development)](tasks-v2.md) — it lists every part and explains where the feature lives in the product. Everything below is reached from the same place. ## How it behaves Everything below is the behaviour, detail and edge cases that belong to this stretch of the Tasks (markdown outliner, in development) page. ### Key files (continued 2) | CLI routes | `src/main/services/cli/cli-server-tasks-v2-routes.ts` | | Per-task agent chat: prompt composer | `src/main/services/task-agent-prompt.ts` (`assembleTaskAgentPrompt`; renders the `## Attached context` section) | | Per-task agent chat: hidden workspace project | `src/main/services/ensure/ensure-tasks-workspace-project.ts` (sentinel `__tasks_workspace__`) | | Session ↔ task lookup | `getSessionIdByTaskId` in `src/main/db/queries-sessions/reads.ts` | | Mirror writer + formatter | `src/main/services/tasks/tasks-v2-mirror-writer.ts`, `tasks-v2-mirror-format.ts` | | Virtual-project seed | `src/main/services/ensure/ensure-tasks-v2-virtual-project.ts` (sentinel `__tasks_v2__` in `src/shared/virtual-project-ids.ts`) | | Gating registry + setting | `src/shared/unreleased-features.ts`, `src/shared/types/settings/agent-tools-settings.ts`, `src/shared/ipc-schemas/settings/agent-tools-settings.ts` | | Sidebar visibility gate | `src/renderer/src/stores/project-visibility.ts` | | Renderer (store + UI) | `src/renderer/src/features/tasks-v2/` — `tasks-v2-store.ts`, `TaskV2Row.tsx`, `TaskV2SnoozeReturnedChip.tsx` (the came-back-from-snooze indicator: alarm-clock icon + ×N badge + per-snooze hover, fed by `src/shared/tasks-v2-snooze-history.ts`), `TaskV2RowActions.tsx` (the row's 2-button + ⋯ overflow cluster — left-aligned after the text, hover-reveal on desktop), `TaskV2Outliner.tsx`, `TasksV2View.tsx`, `TaskV2Header.tsx` + `TaskV2HeaderDisclosure.tsx` (the progressive-disclosure header + its portaled, viewport-clamped popover shell), `TaskV2ListRail.tsx`, `TaskV2MasterContext.tsx`, `TaskV2MoveToListMenu.tsx` (move a task), `TaskV2ListMenu.tsx` (per-list rename/recolor/delete), `TaskV2MetadataPane.tsx` (details editor: due/snooze/context + importance/urgency dials, start date, tags), `TaskV2ContextPane.tsx` (context attachments pane), `TaskV2ContextAddMenu.tsx` (the add-context type→entity picker), `PriorityDial.tsx` (the None/Low/Medium/High dial), `parse-quick-capture.ts` (natural-language fast-capture parser, shared with the `c` command line + Tasks), `TaskV2SortFilterBar.tsx` + `task-tree-v2.ts` (the sort/filter view overlay), `TaskV2MasterView.tsx` + `group-tasks-by-list.ts` (the keyboard-driven, editable "All Projects" giant view), `useTaskV2CommandKeys.ts` (the shared command-mode keyboard hook — both layers + the panel state — driven by the outliner AND the master view, one copy), `TaskV2CommandPanels.tsx` (the shared snooze/due/command/cheat-sheet/launch-confirm panels those keys open), `TasksV2PanelTabs.tsx` (the Tasks / Sessions tab strip) + `tasks-v2-session-host.ts` (the AI-sessions list via the shared `useProjectSessionHost` + `SessionHostSidebar` seam) | For the test-locked invariants and the safe-change checklist, see the contract: `.claude/memory/contracts/tasks-v2-contract.md`. ## For agents ### Strategic intelligence — the data model as a platform Tasks v2 is not a task list with AI bolted on. It is a **productivity-intelligence platform** whose data model is the moat. Twelve tables, 30+ purpose-built columns, and 90+ IPC channels capture granular work behavior that no competitor collects. Each column below exists because the AI consumes it to make better decisions over time — the schema IS the intelligence. This section documents each data-model capability as a competitive differentiator so agents building on or positioning the system understand what they are working with. ### Explainable AI ordering (`plate_rank`, `plate_rationale`) Every task on the daily plate carries a numeric rank AND a written rationale — a plain-language sentence explaining why the AI placed it in that position today. No competitor exposes the "why" behind its ordering. This lets users calibrate trust ("the AI put this first because my deadline is tomorrow and I haven't started") and override with understanding rather than guessing. The columns live on `tasks_v2`; the arrange pass writes both atomically. ### AI quadrant classification with provenance (`ai_class`, `ai_class_source`) Each task receives an Eisenhower-style AI classification — do-first, plan, delegate, or drop — stored in `ai_class`. The `ai_class_source` column records whether the classification came from the AI or was overridden by the user. This provenance tracking enables trust calibration: the system knows which classifications the user accepted vs. overrode, building a feedback loop that improves future classifications. The user sees the AI's reasoning and can override it; the override itself becomes training signal. ### Day-log reflection ritual (`tasks_v2_day_log`, `closeout_confirmed_at`) The `tasks_v2_day_log` table stores one row per calendar day with JSON arrays of planned, completed, and carried-over tasks plus counts. `closeout_confirmed_at` marks when the user deliberately closed out the day — a confirmation that the day's record is final. `listDayLogWindow` queries a sliding window of recent days for trend analysis. This creates a structured daily reflection ritual no competitor has: not just "what did I do" but "did I consciously close this day?" The confirmed-close data feeds the AI's planning accuracy — days that were closed out are trusted records; days that weren't are partial data. ### AI interview decomposition (`tasks_v2_interviews`) The `tasks_v2_interviews` table stores multi-turn AI conversations that break a large task into proposed subtasks. Each interview row captures the full conversation, the resulting subtask proposals, and whether the user accepted or modified them. This goes beyond simple "break this down" prompts — the interview format lets the AI ask clarifying questions, propose alternative decompositions, and learn from acceptance patterns. Over time the system accumulates decomposition intelligence: which types of tasks the user prefers to keep atomic vs. break apart, and how granular they like their subtasks. ### Snooze-as-signal procrastination detection (`snooze_history_json`) The `snooze_history_json` column on `tasks_v2` records every snooze event with timestamps — not just "is this snoozed" but a full history of when and how many times. Repeated snoozing is a behavioral signal: a task snoozed three times is likely being avoided, not deferred. The AI can detect procrastination patterns, surface them gently ("you've pushed this off three times — want to break it down or delegate it?"), and factor resistance into future plate arrangement. The snooze-return indicator in the UI (alarm-clock icon with a count badge) makes this visible to the user too. ### Planning profile personalization (`tasks_v2_planning_profile`) The `tasks_v2_planning_profile` table captures durable work-style preferences: how many tasks the user can handle per day, preferred work rhythms, delegation comfort level, and other AI-tuning parameters. This is not a one-time settings page — the profile evolves as the AI observes patterns and the user provides feedback. It means the AI planner adapts to the person over time rather than applying generic productivity advice. A user who consistently overcommits gets different plate sizes than one who finishes early. ### AI-caught task proposals (`tasks_v2_caught`) The `tasks_v2_caught` table captures task suggestions the AI extracts from session transcripts — action items mentioned in conversation that the user might want to track. Each row records the proposed task text, the source session, and whether the user accepted, modified, or dismissed it. This is a unique task-capture pipeline: instead of the user manually entering every task, the AI listens to ongoing work and proposes tasks that fell out of conversation. Acceptance and dismissal patterns train the AI on what the user considers task-worthy. ### Delegation run records (`tasks_v2_delegations`) The `tasks_v2_delegations` table links task outcomes to autonomous agent executions. Each delegation record captures which task was delegated, to which session, and the result. Combined with `delegate_kind` and `delegate_kind_source` on the task row, this creates a full delegation lifecycle: the AI suggests delegation, the user approves, the agent executes, and the outcome is recorded. Over time the system learns which types of tasks delegate successfully and which need human attention, improving future delegation suggestions. ### Estimation accuracy analytics (`estimated_minutes`) The `estimated_minutes` column on `tasks_v2` stores per-task time estimates. Combined with day-log completion data and the planning profile, this enables estimation-accuracy tracking: how well does this user estimate? Do they consistently underestimate certain types of tasks? The AI can use historical estimation accuracy to adjust plate sizing — if a user's estimates typically run 1.5x actual, the plate gets fewer tasks. This closes a feedback loop most task managers leave open. ### Waiting-on dependency and people graph (`waiting_since`, `follow_up_at`, `waiting_on_who`) Four columns — `waiting_since`, `follow_up_at`, `waiting_on_who`, and `follow_up_notified_at` — transform "blocked on someone" from a passive status into an active dependency graph. The system knows who you're waiting on, since when, and when to follow up. Combined with name history, this builds a people-interaction graph: who are your frequent blockers? How long do they typically take? The AI can proactively surface stale waiting-on tasks ("you've been waiting on Alex for 5 days — want to follow up?") and factor people-dependencies into plate arrangement. ### Meeting prep system (`is_event`, `lead_minutes`, `event_assertiveness`) Three columns turn calendar events into first-class work items. `is_event` marks a task as a meeting. `lead_minutes` specifies how much prep time the AI should schedule before it. `event_assertiveness` controls how aggressively the AI protects that prep time against competing tasks. This creates a context-aware meeting preparation system: the AI knows which meetings need prep, how much, and can arrange the plate so prep tasks land before the meeting. No standalone task manager models meeting prep as a typed relationship to the event. ### Workspace AI steering via lists (`master_context`, `default_project_id`) Lists in `tasks_v2_lists` carry two AI-steering fields. `master_context` is free-text context the user writes once that flows into every AI prompt for tasks in that list — "this project is on a tight deadline" or "these are low-priority background tasks." `default_project_id` links a list to an Omniscio project, so the AI has access to that project's sessions, files, and history when reasoning about the list's tasks. This creates project-level AI knowledge: the AI doesn't just see individual tasks, it understands the workspace they belong to. ### Plate rationale as a reasoning archive Beyond per-day ordering (see "Explainable AI ordering" above), `plate_rationale` accumulates into a historical archive. Each day the AI writes fresh rationales, and the previous ones persist in the day-log records. Over weeks this builds a corpus of AI reasoning about the user's work: why certain tasks kept appearing, why priorities shifted, what the AI considered important. This archive can be correlated with completion outcomes — did tasks the AI ranked highly actually get done? — creating a self-improving planning loop. ### Task-calendar fusion model The `is_event`, `lead_minutes`, and `event_assertiveness` columns (see "Meeting prep system" above) do more than schedule prep — they create a unified work-time model that treats calendar events and tasks as the same data type. Most productivity tools keep tasks and calendar in separate systems, forcing the user to mentally merge them. Here the AI sees both in one data model, knows how much time each consumes, and can reason about the full day: "you have a 2-hour meeting at 2pm with 30 minutes of prep, leaving 90 minutes of deep work before it — here are the tasks that fit." This fusion is architectural, not a UI overlay. ### Per-list AI knowledge flow `master_context` on lists (see "Workspace AI steering" above) flows into AI prompts for three distinct operations: plate arrangement, right-now ranking, and plan chat. This means the same project-level knowledge shapes every AI interaction with tasks in that list — not just one feature. When a user writes "this project ships next Friday" as a list's master context, the arrange pass prioritizes its tasks higher, the right-now ranking surfaces them more urgently, and the plan chat factors the deadline into advice. This per-list knowledge propagation is invisible to the user but creates consistent, context-aware AI behavior across all task interactions. ## Related The overview, the other parts, and everything else worth reading next all sit on [Tasks (markdown outliner, in development)](tasks-v2.md).