Pass goal in wikilink form to task list --goal

CHANGELOG.md

@@ -8,6 +8,10 @@ Please choose versions by [Semantic Versioning](http://semver.org/).
 * MINOR version when you add functionality in a backwards-compatible manner, and
 * PATCH version when you make backwards-compatible bug fixes.
 
+## Unreleased
+
+- fix(agent): `work-on-goal-assistant`'s batch status call now passes the goal in wikilink form (`--goal "[[Name]]"`). `task list --goal` matches the task's `goals:` frontmatter verbatim, so the bare name shipped in v0.102.1 returned `null` for every real goal — silently, since `null` is not an error. Correctness was preserved by the per-task fallback, but the batch path never fired, so the "one call instead of N reads" claim in v0.102.1 did not hold. Also documents the asymmetry with `goal set`, which takes the bare name, and tells the agent to treat `null` on a goal that lists task refs as a failed call rather than an empty goal.
+
 ## v0.102.1
 
 - fix(agent): `work-on-task-assistant` and `work-on-goal-assistant` now resolve task status through the CLI instead of reading it out of frontmatter. Both already used the CLI for writes; only reads bypassed it. `work-on-task-assistant` had no `# Prerequisites` handling at all, so the check was improvised per-run and reported an already-`completed` blocking task as `in_progress`. `work-on-goal-assistant` free-read `status` / `defer_date` / `priority` for every child task, silently feeding the grouping, the `X/Y completed` count, and the task recommendation — it now fetches all of them in one `task list --goal ... --all --output json` call, which is also cheaper than N file reads. Unresolvable tasks render as `unverified` rather than guessed.

agents/work-on-goal-assistant.md

@@ -104,9 +104,13 @@ For each task ref:
 Fetch `status`, `defer_date`, and `priority` for ALL child tasks in one call — never read them from frontmatter directly:
 
 ```bash
-vault-cli task list --goal "{goal_name}" --all --output json
+vault-cli task list --goal "[[{goal_name}]]" --all --output json
 ```
 
+⚠️ `--goal` matches the task's `goals:` frontmatter value verbatim, so it needs the **wikilink form** — `"[[Some Goal]]"`, not `"Some Goal"`. This is the opposite of `vault-cli goal set "{goal_name}"` above, which takes the bare name. Passing the bare name here returns `null`, not an error, so a wrong form looks exactly like "this goal has no tasks."
+
+If the call returns `null` or `[]` while the goal file does list task refs, treat that as a failed call — not as an empty goal — and fall through to the per-task path below.
+
 Use the returned values for the defer filter, the grouping, the progress line, and the recommendation. For any task ref the call does not return, resolve it individually via `vault-cli task get "<name>" status --output json`; if that errors, render the task as `status: unverified` rather than guessing.
 
 These values drive which task gets recommended and the `X/Y completed` count, so a wrong read is silent — it changes the recommendation with no visible symptom. The CLI is authoritative; one call is also cheaper than N file reads.