Skip to content

v1.11.0 — annotate a past history entry, append-only

Choose a tag to compare

@danjamk danjamk released this 07 Sep 12:44
· 3 commits to main since this release
e2085bd

A past history entry can be annotated. It still cannot be changed.

Added

  • knag_annotate(entry_id, note, page?) (#253), the fifth MCP tool and the first write in this server that is not a whole-page write. Details surface after the wipe — watch data syncs late, an intensity rating gets reconsidered, a substitution is remembered an hour on — and until now the choice was to lose them or keep a shadow record elsewhere, which defeats the point of the wipe history being the only log.

    🔴 Append-only, and that is the feature rather than a first cut. There is no edit path and no delete path — not in the tool list, and not in store.ts, which has an insert and a read and nothing else. The record is worth something because it is evidence of what happened; a tool that can rewrite a past snapshot lets a bad session be quietly laundered into a good one with nothing downstream able to tell. A correction is another note. Tests assert both the behaviour and the absence.

    Deliberately not in scope: setting a header field on a past entry as a typed value (intensity=4). That is editing wearing a costume, and it gets its own feature with its own provenance if it turns out to be needed.

  • annotations on a history entry, oldest first so a correction reads after the thing it corrects. Beside the entry, never merged into it. Both surfaces carry them — unlike snapshot, the browser will need these.

  • Migration 0014, additive. No owner_id on the table: an annotation belongs to a revision, a revision to a page, and a page to an owner, so the owner is reachable by join. Denormalizing it would put the answer in two places, which is the shape of the bug where one person reads another's page.

Changed

  • The server instructions said "whole-page write is the only write", and this release made that false. Corrected in the same change — a rule an agent reads and acts on is worth more than one release of tidiness.

  • deleteUserHard takes annotations with everything else a person owns. Append-only holds while the record is theirs to keep; deletion on request is not an edit to it.

Not in this release

The history pane does not show annotations yet — this is the server half. How a note reads against a wiped line is a visual decision and goes to the design session first (#257). Until that lands, a note added through the connector is readable through the connector and not in the app.

Note: a connector re-reads the tool list on reconnect, so knag_annotate appears at the next handshake rather than at deploy.

Full changelog: v1.10.0...v1.11.0