CHANGELOG.md — folio

1# Changelog

3All notable changes to **folio** are documented in this file.

5The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),

6and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

8## [0.2.7] - 2026-08-02

10### Fixed

12- **Moving a task no longer renumbers it.** Ids are preserved in every

13 direction — inbox → project, project → inbox, project → project, and

14 `folio/inbox-triage`. An id you hold before a move is still valid after it,

15 so `task-move` → `task-update <same-id>` chains correctly and a triage plan

16 built from an inbox dump keeps working once the items are routed.

18 This was never a design constraint. Ids are globally unique random hex with

19 no per-project id space, so nothing required a new one on move.

20 `project-add-task!` simply called `generate-task-id` unconditionally and

21 ignored any id handed to it, while `move-task-in-store!` stripped the id out

22 on the way in. The asymmetry gave it away as an oversight: project → inbox

23 passed metadata through untouched, and only inbox → project destroyed the id.

25- **A task can no longer end up carrying two `id` entries.** Moving a task from

26 a project back to the inbox prepended a fresh id without removing the

27 existing one, leaving both on the line; lookups silently resolved the first.

29### Added

31- **`folio/task-move-batch`** — move many tasks in one call, either

32 `{ids: [...], project: "x"}` for a shared target or

33 `{moves: [{id, project}, ...]}` to fan a single call out across many

34 projects. An entry with no `project` moves that task to the inbox.

36 Returns a result line per id so partial failures are visible rather than

37 swallowed, and the header counts successes rather than attempts. Because ids

38 are now stable, the reported id is the one the task landed under.

40 Triaging 227 inbox items on 2026-08-02 cost 226 individual round-trips, which

41 is a large part of why that inbox went untriaged for four months.

43### Changed

45- Toolchain moved to sigil 0.18 (`sigil ^0.18`, `sigil-run ^0.18.0`,

46 `sigil-http ^0.18.0`, `sigil-sxml ^0.15.0`), with runtime core resolving to

47 0.18.1. `sigil-test` / `sigil-test-runner` remain pinned at `^0.17` (0.17.16):

48 bumping them aborts the install because sigil-http, sigil-tls, sigil-crypto

49 and sigil-web-styles each declare a dev-dependency on `sigil-test ^0.17` and

50 the resolver unifies across the graph. That affects the test harness only,

51 not the shipped runtime, and clears once those four repos move their dev-dep.

53### Known issues

55- **A capture containing newlines is still stored in a shape folio cannot read

56 back.** `folio/inbox-add` accepts multi-line text, but the `{id: ...}`

57 metadata is appended to the END of the text, so on a multi-line capture it

58 lands on the item's last line. The parser sees only the first line, which has

59 no id, and `backfill-ids!` then mints a fresh id onto it — the real item and

60 its metadata become unreachable and a phantom one-line duplicate appears in

61 its place. Six items were hidden this way between April and August 2026.

63 This is not fixed in 0.2.7. A block-parsing fix was written and withdrawn: it

64 cured the burial but introduced worse defects, because it inferred where an

65 item ends and then let destructive operations act on that inference. The

66 redesign makes an item's extent syntactic rather than inferred.

68 Until it lands, **capture multi-line content as a note and reference it from

69 a single-line inbox item**, rather than putting the body in the item itself.