Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Tasks Upstream Feature Audit

This page inventories the remaining gap between the vendored @lapis-notes/tasks package and the upstream TaskNotes plugin, then turns that gap into an ordered implementation roadmap.

It is based on upstream TaskNotes documentation and source references, especially:

  • tasknotes.dev/core-concepts/
  • tasknotes.dev/features/inline-tasks/
  • tasknotes.dev/features/time-management/
  • tasknotes.dev/features/calendar-integration/
  • tasknotes.dev/views/
  • tasknotes.dev/views/default-base-templates/
  • tasknotes.dev/views/kanban-view/
  • tasknotes.dev/views/calendar-views/
  • tasknotes.dev/views/pomodoro-view/
  • tasknotes.dev/settings/task-properties/
  • tasknotes.dev/settings/modal-fields/
  • upstream source in callumalpass/tasknotes, including src/editor/TaskLinkWidget.ts, src/editor/InstantConvertButtons.ts, src/bases/KanbanView.ts, src/bases/CalendarView.ts, src/views/PomodoroView.ts, and src/templates/defaultBasesFiles.ts

Current Lapis Coverage

The current vendored package covers only the first TaskNotes slice families:

  • markdown-first note-per-task storage
  • folder and frontmatter-role mapping
  • strict validation for the current minimal model
  • a first-party Tasks list view using shared @lapis-notes/ui components
  • a core-lite conformance bridge for the current markdown model and operation subset

That leaves most upstream user-facing surfaces still missing.

Missing Feature Families

Task-Note Editor Surfaces

Upstream TaskNotes augments task notes and task links directly inside Markdown views:

  • interactive task-link overlays in reading mode and live preview
  • task-file widgets in task notes, including the relationships widget backed by relationships.base
  • task-aware quick actions that can mutate status, dates, and metadata at the link location

Lapis Notes now has a reusable task-row family across task-note widgets and task-note links in reading mode, source mode, and live preview. The current slice exposes an upstream-shaped single-row contract with checkbox completion, priority selection, scheduled-date quick options plus a custom date-time picker entry point, metadata pills, and an overflow menu through the existing Markdown widget mount paths. Relationship-model groundwork now also parses projects and blockedBy links into runtime lookups, the task-row menus now mutate those mapped relationship fields directly through the task-note frontmatter write path, the browse/task-row surfaces now show reminder metadata together with blocked/ready/blocking dependency state, the overflow menu now exposes explicit due-date, day-before-due, scheduled-date, and picked reminder actions through the mapped reminders field, the note-widget variant now renders a dedicated Reminders panel that lists each mapped reminder plus a dedicated Relationships panel with summary counts, nested blocked-by and blocking task cards, an Open relationships base entrypoint, linked projects, and recursive child-task rows inline, and inline task-link overlays now surface a compact relationship summary, direct related-task pills, and the same Open relationships entrypoint. The remaining gap is rollout depth rather than feature existence: broader relationship/dependency widgets are still missing, and the full note-widget family still needs broader parity polish.

Audit note: future upstream-parity passes for task rows must verify the upstream implementation surface, not just static tokens or control presence. The previous passes matched the visible shell of the row but missed that upstream behavior is split across styles/task-card-bem.css, TaskCard runtime wiring, taskCardProperties metadata renderers, the DateContextMenu popup structure, status and priority settings vocabularies, and the task context menu action set. That gap is why later audits had to rediscover inner-hover hit areas, metadata text sizing/color, markdown-tag rendering, none/open/in-progress/done status cycling, priority none, toast feedback, menu breadth, and the scheduled-date popup grouping after the initial visual parity pass looked superficially close.

The next durable rollout order for relationship-driven task rows is:

  1. broaden the current Relationships panel into fuller upstream-style relationship/dependency widgets
  2. finish broader upstream parity polish for the note-widget family

Task IDs: TASK-PLUGIN-007, TASK-PLUGIN-011

Inline Task Capture And Conversion

Upstream TaskNotes integrates with the editor so checklist lines and plain content can be promoted into TaskNotes files:

  • Create inline task command from the current line
  • per-line convert affordances next to checkboxes and other supported line shapes
  • bulk conversion of all checkbox tasks in a note
  • formatting-preserving replacement of the source line with a task link
  • metadata extraction and optional natural-language parsing during conversion

Lapis Notes now supports command-driven line, selection, and note-wide conversion plus reading-mode, source-mode, and live-preview convert affordances for supported prefixed Markdown task candidates. The current conversion path preserves list and blockquote structure while replacing source content with task-note links, and it extracts hashtags plus explicit ISO due dates into the mapped frontmatter model.

Task Schema, Settings, And Modal Parity

The upstream plugin exposes a much richer configurable task schema and task-editing surface than the current Lapis implementation:

  • title storage in filename or frontmatter with multiple filename strategies and templates
  • custom status and priority vocabularies with labels, colors, icons, and completion semantics
  • richer property coverage for scheduled dates, projects, contexts, reminders, recurrence, time estimates, blocked-by links, time entries, archive tags, and feature-specific keys
  • custom user fields with typed defaults and autosuggestion filters
  • configurable modal field groups, ordering, visibility, and required flags
  • NLP trigger configuration and capture-oriented defaults

Lapis Notes now ships a dedicated Tasks-view settings surface for the managed folder, marker tag, title storage, filename strategy, default status/priority/date presets, task-detection rules, status and priority vocabularies, and JSON-backed custom fields. Modal field-group editing, richer typed custom-field editors, and deeper filename-template parity are still missing.

Task ID: TASK-PLUGIN-009

Bases-Backed View Suite And Default Templates

Upstream TaskNotes v4 uses Bases as the main view system for task-focused navigation. The documented view suite includes:

  • Task List views
  • Agenda views
  • Kanban views with grouping, swimlanes, drag-and-drop, and manual ordering
  • Mini Calendar views
  • full Calendar views with day/week/month/year/list/custom-day modes
  • Relationships views backed by generated .base files
  • generated default .base templates with formulas, filters, ordering, and command-to-file mappings derived from TaskNotes settings

Lapis Notes now generates and opens TaskNotes-style .base files for Task List, Kanban Board, Fizzy, Mini Calendar, and Fizzy Calendar under the managed task views folder, and it registers matching custom Bases renderers (tasknotesTaskList, tasknotesKanban, tasknotesFizzy, tasknotesMiniCalendar, tasknotesFizzyCalendar) through the public Plugin.registerBasesView() path. The Fizzy renderer adds a first-pass Basecamp-Fizzy-style status board with drag-and-drop lane moves, persisted pinning, shared search controls, keyboard navigation, and optional entropy moves into a configured Not Now lane. These task-specific renderers intentionally use the Tasks plugin’s indexed markdown task-note dataset as the source of truth so the generated views stay browser-safe and do not depend on upstream Obsidian-only Bases internals.

The remaining gap in this feature family is upstream parity depth rather than feature existence: Agenda, full Calendar, and Relationships Bases views are intentionally out of scope for the current generated suite, the Fizzy base now covers a first-pass triage-board surface, but Kanban and Fizzy do not yet implement persisted manual ordering, richer swimlanes, comments, or boosts, and the remaining calendar renderers do not yet cover the full upstream mode set.

Task ID: TASK-PLUGIN-010

Lapis Planner Workflow

The Things-like planner is a Lapis-specific workflow layer rather than direct TaskNotes upstream parity. It should sit on top of the same markdown-backed task-note runtime and keep the existing Tasks table, generated Bases views, task-card widgets, recurrence/reminder/dependency behavior, and Fizzy workflows intact.

The planner should start with a pure bucket model and mapped when metadata, then add a dedicated planner view, Things-style planning actions, Inbox capture and triage, area links, manual ordering, settings controls, project sections, a generated Planner Base companion, and an optional review workflow. The dedicated planner view is the primary daily workflow; the generated Planner Base is a later query/customization companion.

Task IDs: TASK-PLUGIN-054, TASK-PLUGIN-055, TASK-PLUGIN-056, TASK-PLUGIN-057, TASK-PLUGIN-058, TASK-PLUGIN-059, TASK-PLUGIN-060, TASK-PLUGIN-061, TASK-PLUGIN-062, TASK-PLUGIN-063

The current core-lite bridge intentionally stops short of the richer TaskNotes model surface. Dependency and project link mutations now exist in the task-row surface, the note-widget now includes dedicated Reminders and Relationships panels, the relationship widget now renders fuller blocked-by and blocking task cards. The interactive runtime now also supports preset recurrence rules plus recurrence-aware completion or skip-forward actions that roll the managed due or scheduled field forward while recording completeInstances or skippedInstances, and the browse/task-row surfaces now expose mapped reminder metadata together with explicit due-date, day-before-due, scheduled-date, and picked reminder actions plus lightweight blocked/ready/blocking state, but the remaining missing behavior still includes:

  • custom recurrence rules and richer per-instance completion/skip state UX
  • broader reminder defaults and automation semantics
  • deeper dependency graphs (blockedBy, blocking, relationship tabs, richer readiness checks)
  • link semantics and richer note/task relationship handling
  • extended conformance profiles beyond core-lite

Task IDs: TASK-PLUGIN-006, TASK-PLUGIN-011

Time Tracking And Productivity Views

Upstream TaskNotes includes time-management features that cut across task cards, views, and dedicated productivity surfaces:

  • start/stop task timers writing to timeEntries
  • auto-stop of active timers when tasks complete
  • calendar-driven time-entry editing
  • timeblocking flows
  • Pomodoro timer view
  • Pomodoro statistics/history view

Lapis Notes now has an initial task-card start/stop timer surface that writes timeEntries, renders tracked-duration pills, and auto-stops active timers when tasks complete. Calendar time-entry editing, timeblocking flows, Pomodoro views, and richer time-policy settings are still missing.

Task ID: TASK-PLUGIN-012

Calendar And External Calendar Services

Upstream TaskNotes blends task scheduling with external calendar systems:

  • Calendar and Mini Calendar Bases views
  • OAuth-backed Google Calendar and Microsoft Outlook sync
  • ICS subscriptions
  • drag-and-drop calendar scheduling and event rescheduling
  • time-entry editor and timeblocking flows from calendar interactions

In Lapis Notes this area is partly a product gap and partly a runtime-capability decision, because browser-only delivery cannot safely absorb credential handling or background sync in the same shape as upstream Obsidian.

Task ID: TASK-PLUGIN-013

Automation And External APIs

Upstream TaskNotes also exposes automation-oriented surfaces:

  • HTTP API
  • webhooks
  • CLI-oriented flows
  • MCP-style and service-backed automation surfaces in the repo

These do not map directly onto the current browser-first Lapis host. They need an explicit capability decision before they can be sensibly vendored.

Task ID: TASK-PLUGIN-014

Proposed Sequence

  1. Implement schema/settings parity first so later view, editor, and conversion work target the right frontmatter model and configurable fields. (TASK-PLUGIN-009)
  2. Add inline task capture and editor/read-preview integration on top of that schema so task promotion and task-note widgets share one model. (TASK-PLUGIN-007, TASK-PLUGIN-008)
  3. Build the Bases-backed view suite and generated default templates once the schema and field mapping are broad enough to drive task list, kanban, agenda, calendar, and relationships views. (TASK-PLUGIN-010)
  4. Add the Lapis planner foundation after the markdown task runtime and reusable task-row surfaces are stable, starting with the bucket model plus when metadata and first-class planner view before later ordering, areas, project sections, generated Base, and review slices. (TASK-PLUGIN-054 through TASK-PLUGIN-063)
  5. Expand the model into recurrence, reminders, dependencies, and link semantics, then promote conformance beyond core-lite. (TASK-PLUGIN-006, TASK-PLUGIN-011)
  6. Add time-tracking and Pomodoro surfaces after task-card actions, dependency handling, and calendar entry points exist. (TASK-PLUGIN-012)
  7. Tackle calendar-provider and ICS integrations only after runtime capability boundaries for auth, secrets, and background synchronization are explicitly decided. (TASK-PLUGIN-013)
  8. Tackle external automation surfaces last, because they depend on the settled task model, view suite, and host-capability story. (TASK-PLUGIN-014)

Implementation Constraints

  • Visible UI should continue to use Svelte components backed by shared @lapis-notes/ui primitives where possible.
  • Upstream Obsidian internals should be replaced with Lapis Notes editor, Markdown, workspace, and Bases APIs rather than copied directly.
  • Browser-only delivery is the default assumption. Features that require secrets, background sync, local OS integration, or long-running services should be capability-gated and may need future desktop or service companions.
  • Any deviation from upstream TaskNotes behavior that changes user-facing semantics should be documented in the Tasks package page and linked back to the relevant task id when one exists.