v0.2.7

TASK IDS ARE NOW STABLE across every move -- inbox to project, project to inbox, project to project, and inbox-triage. An id you hold before a move is still valid after it, so task-move followed by task-update on the same id works, and a triage plan built from an inbox dump keeps working once the items are routed.

There was never a reason for it to be otherwise. Ids are globally unique random hex with no per-project id space; project-add-task! simply called generate-task-id unconditionally and ignored any id handed to it, while move-task-in-store! stripped the id out of the metadata on the way in. The asymmetry is what gave it away as an oversight rather than a decision: project to inbox already passed metadata through untouched, and only inbox to project destroyed the id.

folio/task-move-batch moves many tasks in one call, either {ids, project} for a shared target or {moves: [{id, project}]} to fan out across many. It reports per id, so a partial failure is visible rather than swallowed. Triaging 227 inbox items on 2026-08-02 cost 226 individual round trips; that cost is a large part of why the inbox went untriaged from April to August.

NOT IN THIS RELEASE, and named because a companion branch was withdrawn: the multi-line inbox burial is still live. A capture containing newlines still lands with its id on the last line and still gets a phantom fresh id grafted onto the headless first line. Two adversarial review rounds found sixteen defects in the attempted fix, four of them introduced by the previous round's fixes, all in the write path. The diagnosis is that an item's extent is inferred and destructive operations must not depend on an inference; the fix is to make extent syntactic rather than heuristic, which is a design change and is tracked separately.