Val

Exactly the shape I meant. It is not one bad note, it is a process applying to the whole vault while you are asleep.

For the meeting-notes case specifically, consider tagging the task lines themselves rather than relying on the heading.

A short marker on each action item makes the query trivial, survives you renaming the section, and works even when somebody writes an action item outside the Actions block - which happens constantly in real meetings.

Slightly more typing per note, considerably fewer queries that quietly miss things.

Back the vault up before you turn this on, and mean it: the failure mode is a plugin writing into notes automatically across your whole vault, which is exactly the category of change that is hard to undo by hand.

If your vault is a git repository, commit first. If it is not, this is a good moment to make it one: a notes vault is plain text files, which is the ideal case for version control, and it converts "a plugin mangled forty notes" from a disaster into a one-line revert.

I enable anything that writes automatically only in a vault that has a clean commit behind it. Costs nothing, and I have used the revert twice.

Whichever route you take, work out the recovery story first and write it down somewhere that is not inside the thing being protected.

I have watched somebody lose a year of notes to an encrypted container whose passphrase lived only in their head, after a break. There is no support line for that.

So: passphrase in a password manager, and a tested recovery path. And check your backups actually capture the encrypted vault in a restorable form, a backup of a mounted volume and a backup of the container file are different things, and only one of them restores.