Tasks are notes: how the work store is designed

Our task management runs on plain markdown notes in one folder, not on a task database. On August 17, 2026 we registered that folder as a data channel, which is what a dashboard panel has to cite before it may claim it shows anything. Five blocked panels are now unblocked, and nothing about how anyone writes a task changed.

This post explains the design so the team can build on it. It is written for Alex, Diana, KG, Limore and Nuri, in Google developer documentation style.

What a task is here

A task is a markdown note in TaskNotes/Tasks/, named by its title, with structured fields at the top and free prose underneath.

status: open          # open, in-progress, done
priority: high        # low, normal, high
due: 2026-08-19
scheduled: 2026-08-19
projects: ["[[ShurIQ]]"]
timeEstimate: 20      # minutes
tags: [task]

Everything below those fields is ordinary writing. That is where the context goes, and it is the part that makes a task worth opening rather than just counting.

There are 113 of these files. They are the store. There is no separate database, no export, and no sync step. Three ways to read them, all reading the same files: the plugin panel in the sidebar, the six views in TaskNotes/Views/command-center.base, or opening any task as a note.

Two consequences worth stating, because they are the whole argument for this design.

A task can carry as much context as the decision needs. A row in a task database is a title and a due date. A note can hold the tables, the links, and the reasoning behind why the task exists. The four tasks created this week each carry enough that opening one is sufficient to make the decision it holds.

Everything else in the vault can read them. Any query that reads note properties reads tasks, because tasks are notes. That is why registering them as a data source took minutes rather than a sprint.

What we changed, and why it matters

A dashboard panel is a claim about the state of the world. Before it earns a place on a screen, it has to name a channel: a producer of data with a cadence and an address. A panel with no channel is a drawing.

Five panels in the Command Center design were recorded as blocked for exactly that reason: Mission Critical, Upcoming Work, the per-row actions on an attention item, the opportunity actions, and Writer's Studio. All five read work items, and no channel produced work items.

Except one did. The folder was already there, already written to, already rendered. It simply had no id. So the fix was a registry row rather than a build:

- id: CH-13
  name: Work item store
  producer: TaskNotes/Tasks/
  cadence: on-write
  emits: work items with owner, due date, status, priority, project
  freshness_sla_hours: null   # event-driven
  status: live

That row lives in registries/channels.yaml alongside the twelve channels registered before it.

The binding is to the record shape, not to the tool

This is the part to hold on to when the question of which task manager we use comes back.

That matters because TaskNotes is explicitly provisional. It was retired on July 25, 2026 and reinstated three days later as the working placeholder while the team decides what fits the rest of the systems. Registering the record shape rather than the tool is how a provisional decision stops blocking permanent work.

What checking it turned up

The Command Center was showing every task twice.

Its view filtered on the task tag alone, with no folder scope. A git worktree in this vault holds a full duplicate copy of everything, including 99 stale task files, so the view matched both sets. Mission Critical read 112 rows where the real number is 56.

Fixed by scoping the filter to the real folder, and confirmed on screen:

filters:
  and:
    - file.hasTag("task")
    - file.inFolder("TaskNotes/Tasks")

Worth naming plainly, because it is a pattern rather than an incident. This is the same folder-scoping problem found last week in three other dashboards, and around forty more in this vault have never been checked. A doubled count does not look broken. It looks like a busy week.

Four tasks, live now

Created August 17, 2026, and they are the demonstration as well as the work. Each holds a decision that is currently blocking something.

The Wednesday one shows why the design earns its keep. 76 nightly briefs sit at status draft and every one is unreviewed, because no reviewed value exists in the schema. There is no value to move a brief to. The queue cannot go down by any amount of reading. That is not a sentence that fits in a task database row, and it is the entire reason the task exists.

Where this goes next

Three things, in order.

The registry has columns waiting for this. The intent registry carries a channel_id column and a route_ids column on all 62 rows, designed to record exactly this binding. One row is filled in. As the remaining channels are adjudicated, the rest get written in, and the registry can then answer "is this panel backed" without anyone reasoning it out again.

Four more channels are reserved and not yet decided: run health, attention items, a portfolio-wide score, and an opportunity record. Each is worked out in section 1.6 of the dashboard design document, with what blocks it and whether it needs a person or a build.

The task manager question is still open, and now it is safe to leave open. That was the point of binding to the record shape.

Context

Everything above is in the vault. The paths, for anyone reading with it open:

• projects/shur/task-system/ for this post
• projects/shur/intent-registry/ORIENTATION.md for the full catch-up, including how to read the five numbering systems in play
• projects/shur/intent-registry/design/DESIGN-dashboard-model-and-schema.md section 1.6 for the channel answers
• projects/shur/dev-sprint-1/monorepo-seed/registries/channels.yaml for CH-01 through CH-13
• TaskNotes/Tasks/ for the store, and TaskNotes/Views/command-center.base for the views