Task management improvements

[NunonuN]

• Add support for partially completed tasks, for example using / as a marker.
• Automatically mark a parent task as partially completed when some of its subtasks have been completed.

[adibhanna]

Thanks for this. Both halves are good ideas, and they turned out to be very different in size, so here is where each one landed.

Partially completed tasks: done, shipping in 2.21.0

- [/] is now a real task state everywhere a task is recognized. It follows the Obsidian Tasks convention, so it joins the states that were already there: [ ] open, [x] done, [>] forwarded, [-] cancelled.

What makes it different from forwarded and cancelled is that in-progress is still open work:

• It stays in Today rather than collecting under a group of its own, and stays on the calendar and the Kanban board.
• It rolls forward with your unfinished tasks when a daily note rolls over, / and all. A half-done task is exactly the one you want in front of you tomorrow.

The editor and the reading view both draw it as a half-filled box. Set it by typing - [/], by running "Mark Task In Progress" from the command palette with the cursor on a task, or by pressing i on a task in the Tasks list (press i again to set it back to open). It round-trips as plain markdown across the zn CLI, the MCP server and the self-hosted Go server. A whole-note task file uses status: in-progress in its frontmatter, and doing, started and wip are read the same way.

Two fixes rode along, because your request landed right on top of them:

• [/], [-] and [>] all used to render as literal text in the reading view, since GFM only understands [ ] and [x]. All three now draw the same marker they do in the editor, including in exported HTML and PDF and in a note shared by link.
• The reading view numbered its checkboxes without counting the states that have no checkbox, so in a note that opened with a cancelled or forwarded task, clicking a checkbox could toggle the wrong line. It counts every task line now.

Automatic parent rollup: I need one decision from you

This one hinges on a question the request does not settle, and it changes the whole shape:

Do you want the parent's text on disk rewritten, or the parent shown as partial?

If ZenNotes writes [/] into the parent line, the state survives into Obsidian and anything else reading the files. But ZenNotes is not the only writer of your notes: Obsidian, vim, the phone, the sync server can all check a subtask off, and none of those would fire the rollup, so the parent would quietly go stale and the file would contradict itself.

If instead the parent's progress is derived and displayed (2/5 next to it, no write), it is always right no matter who edited the file, un-checking a child needs no un-write, and nothing gets written that you did not type. The cost is that the progress lives in ZenNotes rather than in the markdown.

I lean to the second, since plain files you can trust is the whole point of the vault. But you asked for the first, so tell me which you actually want and I will build that one.

[NunonuN]

Thank you very much for considering my suggestion and for implementing it so quickly!

Regarding the parent rollup, I would personally prefer the second option, mainly because I use ZenNotes as my main environment for managing notes and tasks. So, from a personal workflow perspective, having the progress displayed dynamically would already solve my use case. Combining both approaches would probably be the ideal scenario, but I understand from your explanation that this is not really possible without compromising the consistency of the vault.

Thanks again for the great work.

[adibhanna]

Built, on the release branch for 2.21.0.

A parent task with subtasks now shows how far along its children are: a 2/5 chip at the end of the line, in the editor and in the reading view, turning green once every child is done. It is derived at render time and never written into the markdown, exactly per the trade-off above: check a child off in Obsidian or vim and the chip is right the next time ZenNotes renders the file, and un-checking a child needs no un-write.

The counting rules, so nothing surprises you: direct children only, one level down, and a grandchild rolls into its own parent, which shows its own chip. Cancelled ([-]) and forwarded ([>]) children leave the denominator entirely, since they are no longer that list's work. An in-progress child ([/]) counts toward the total but not toward done. The editor and the reading view count with one shared implementation, so the two surfaces can never disagree about the number.

On combining both approaches: writing the marker into the parent stays off the table for the staleness reason above, but the derived chip carries the display half of it everywhere ZenNotes renders, including exported HTML and PDF and notes shared by link. The Tasks list and Kanban deliberately stay flat, so the chip lives where the hierarchy does: the note itself.