v1.9.4 — say where a wipe's removed lines are

The history tool stops sending agents to the wrong field.

Fixed

• knag_history never said where a wipe's removed lines are (#251). Its description ended on "it snapshots the page as it stood before, so its own diff is empty by construction and the cleared lines are the record" — which points a reader at cleared, a checked-only set, as though it were the contents of the wiped page, and stops exactly where the useful half begins. It never said the lines are on the entry after the one that seals the wipe.

  An agent read it the way it was written, found 19 checked lines where the page had held 29, and reported a workout's notes and intensity rating as lost. They were in the same response, on the following entry's disappeared. Nothing had been lost and nothing was broken: the tool described itself badly enough to talk a reader out of data it was handing over.

  The description now states the shape — a wipe writes two entries on one timestamp, the removed lines are the second one's disappeared, cleared answers what was finished and its revision_id names the seal rather than the entry carrying the lines. Entries are addressed by id, since local_time is not unique by design. The output schema says the same things field by field, for a reader that never sees the prose.

  No data, no shape, no route changed. spec §5 already said "reading cleared_items instead would silently drop the unfinished lines", and the client's own toDays carries the pairing rule in a comment. The MCP consumer was the one surface never told.

  Two tests pin it — one on the description's claims, one on the shape those claims describe — because prose is the entire fix and nothing else fails when it drifts.

Note: a connector re-reads tool descriptions on reconnect, so this reaches claude.ai at the next handshake rather than at deploy.

Full changelog: v1.9.3...v1.9.4