Both are solvable and both come down to understanding what the plugin has actually indexed, which is worth ten minutes because it makes every future query obvious.
First problem: equality versus containment.
A field written as a list — several values on one key — is indexed as an array, not a string. Comparing an array to a single value with equals is false, always, which is why you get nothing back rather than an error.
The function you want is the containment one. It works on both arrays and strings, which is what makes it the right default:
- on an array, it asks whether any element matches
- on a string, it asks whether the value appears as a substring
That second behaviour is a trap worth knowing: a substring match means searching for a short project name will also match a longer one containing it. There is a stricter variant that only does exact element matching on arrays — use that when your values are things like admin and admin-review where a substring match would be wrong.
The general shape is a table query, selecting the columns you want, sourced from a tag or folder, with a where clause using the containment function on your field.
Second problem: tasks under a heading.
This is the one people give up on, and it is easy once you know the plugin records where each task was:
Every indexed task carries a reference to the section it appeared in — effectively a link to that heading in that file. So you filter the task query on that section reference rather than trying to parse the document yourself.
Use a task query, sourced from wherever your meeting notes live, filtered on the section reference containing your heading name, and add a condition to exclude completed ones. That is the whole query.
Two details that will bite you here:
- The heading has to be spelled consistently. "Actions", "Action items" and "Actions:" are three different sections. If your older notes vary, either normalise them or make the filter tolerant.
- Subtasks are nested, not flat. A task with indented children is indexed as one task with a list of subtasks. If your action items are nested, a plain filter returns only the parents. There is a flatten operation for exactly this — apply it to the subtasks field to get one row per child.
The general debugging method, which is more valuable than either query: make a scratch note and render the raw metadata of one file. Every serious query plugin has a way to dump what it indexed for a page or a task. Look at that once and you will immediately see whether your field is a string or an array, how the section reference is spelled, and whether your field was parsed at all.
Most failed queries are a field the plugin never indexed, usually because the metadata is in a format it does not recognise. Checking the index first turns guessing into reading.