From 20a17b7feb02b5c1dd8ec3b961583ade9ea82a7d Mon Sep 17 00:00:00 2001 From: Benjamin Borbe Date: Sat, 25 Jul 2026 16:35:51 +0200 Subject: [PATCH] pass goal in wikilink form to task list --goal --- CHANGELOG.md | 4 ++++ agents/work-on-goal-assistant.md | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 4a51461..2ae97de 100644 --- a/CHANGELOG.md +++ b/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. diff --git a/agents/work-on-goal-assistant.md b/agents/work-on-goal-assistant.md index 8c4c14e..7a235c8 100644 --- a/agents/work-on-goal-assistant.md +++ b/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 "" 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.