From dc14609de40782ba687e4e4c060fc3b332fcb7f3 Mon Sep 17 00:00:00 2001 From: Benjamin Borbe Date: Thu, 15 Oct 2026 19:15:15 +0200 Subject: [PATCH] fix: unfold the sync-progress changelog entry the v0.169.2 release folded The v0.169.2 release commit was the first parent of the merge that carried this change, so GitHub's merge combined the branch's ## Unreleased bullet with master's rename cleanly and left the bullet under the already-released ## v0.169.2. git tag --contains the merge is empty and the tagged tree lacks the fix, while master carries it at the same version number. Restore ## Unreleased above ## v0.169.2 and move the bullet back into it. The released section is left byte-identical to its own tag. --- CHANGELOG.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index bbe16b6..ac23223 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -8,9 +8,12 @@ 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. -## v0.169.2 +## Unreleased - fix: `/vault-cli:sync-progress` § Phase 2 reaches its `already synced — no writes this run` short-circuit for an `in_progress` anchor, instead of reporting failure for a record it can verify as present. The short-circuit added in `v0.168.6` was gated *"When a completion was established above"*, so the state the command is most often run in — an anchor that is still open — fell past it to `No task completion or PR detected. Use /update instead for in-progress work.` and STOP. Measured 2026-10-15: the operator ran the command **four times in one session** against an `in_progress` anchor whose daily-note entry already existed; all four stopped at the same line, each costing a full Phase 1–2 sweep (vault config read, session-transcript scan, git probes) and producing an identical report. The gate now reads *"whenever a completion was established above **or** the anchor is `in_progress`"*, and an explicit `in_progress` arm precedes the STOP bullet so the representation check runs first. Still keyed on the representation check rather than on the status alone: an `in_progress` anchor with **no** daily-note entry falls through to the STOP line unchanged. Out of scope: the Phase 1–2 sweep itself (the short-circuit still runs after the completion analysis, so the sweep is not removed — the false failure report and the operator's reason to re-run are) and the close-family loop in `/vault-cli:session-close`. + +## v0.169.2 + - fix: `/vault-cli:create-task` and its `task-creator` agent no longer fall back silently to the configured default vault. `commands/create-task.md` documented `--vault` as optional with an implicit default, and `agents/task-creator.md` stated it outright (`Defaults: MODE = interactive, VAULT = configured default vault`) — so a task belonging to one vault was placed in another by inference, and the silent fallback is a **third** vault again, wrong for work belonging to any other. Both now resolve the vault from `--vault` or from the cwd, and **ask** when neither determines it — the convention `commands/reflect.md` (*"If cwd is not inside any vault path, ask the user which vault to write to"*) and `agents/graph-auditor.md` (*"ask user which vault to audit; do not guess"*) already carry, so this brings the pair in line with their siblings rather than adding a new rule. Observed 2026-10-15: a task belonging to `seibert-personal` was created in `seibert-brogrammers` by inference and had to be deleted and re-created, costing two `task-creator` runs (~105k tokens). ## v0.169.1