@plinth-music/cli 0.23.0 → 0.23.2

package/CHANGELOG.md

@@ -2,6 +2,92 @@
 
 Notable changes to `@plinth-music/cli`. Grouped by what a user notices, not by PR.
 
+## 0.23.2 - 2026-10-04
+
+Two code PRs since `0.23.1` (`v0.23.1..ea615a2`: #217, #218; #215, #216 and #219 docs).
+A patch: fixes only, no new command or sync surface.
+
+⚠️ **Text from Plinth can no longer run as code on your laptop** (#218). A document,
+artist, project or task body that opened with a `---js` or `---javascript` block was
+executed by the daemon of every member who pulled it, because the frontmatter library
+the CLI uses evaluates JavaScript frontmatter. The daemon now refuses that engine
+everywhere in the process and never reads a body as frontmatter when it writes a file,
+so such a body lands in the mirror as plain text. This is the laptop half of a security
+fix whose server half is already live: it protects a machine only once that machine
+runs this version.
+
+⚠️ **One save that removes most of a large file is now held for `plinth confirm`**
+(#217). A single save that keeps at most half of a file and removes at least 5,000
+characters of body (100 KB under `files/`) is held on its own, the way a large batch
+already was. Before, a 139,194-character roster file was cut to 7,554 characters and
+synced unheld. Small single edits and deletes still sync straight through.
+
+⚠️ **A file whose frontmatter cannot be read is held and said, never sent mangled**
+(#217). Before, the first save stayed on the laptop while `plinth status` reported
+every write synced, and the next change sent the whole raw file to Plinth as the body
+with its fields emptied. Now nothing is sent, `plinth status` lists it under Rejected
+with the fix, and the record clears when the file is fixed, moved or deleted. One
+broken file no longer stops the daemon starting.
+
+**A body that opens with `---` is no longer corrupted on pull** (#218). Any such file
+is rewritten correctly once, on the first pull after updating. Every other file is
+written byte for byte as before.
+
+**Extracted texts stuck as "local edits" heal on their own** (#217). A file under
+`views/extracted/` that the daemon had re-rendered itself was reported as a member's
+edit. It is now recognised as the daemon's own and repaired on the next pass.
+
+**What is not proven.**
+
+- The code-execution hole was reproduced locally only, never against production. The
+  fix is covered by tests that drive the pull for every entity type that carries a
+  body (forced red on the previous code: 28 of 31 fail) and by a spawned built binary.
+- #217 was driven live on the test workspace on a build one review round older than
+  the merged code.
+- Two saves under about a second apart can still be overwritten by the daemon's own
+  earlier push. Not fixed here; it belongs to the Sync Conflicts work.
+- A thread file whose frontmatter cannot be read still makes the pull fail loudly,
+  rather than being held.
+
+## 0.23.1 - 2026-09-29
+
+Two code PRs since `0.23.0` (`v0.23.0..0dd34dc`: #212, #213; #209, #210 and #211 docs).
+A patch: fixes only, no new command or sync surface.
+
+⚠️ **A file you delete from the mirror stays deleted** (#213). A poll landing in the
+second or so between your `rm` and the daemon's delete hold could write the file back,
+and the delete was then dropped; four of seven documents came back this way on 26 Sept.
+The daemon now leaves a path it saw you remove alone for five minutes, and waits one
+poll before restoring a file that is missing for a reason it has not seen yet. A file
+missing for any other reason is still restored, about one poll later than before.
+
+⚠️ **One slow calendar no longer freezes every calendar view** (#212). A calendar whose
+read fails or times out now shows as not read, with no entries, until the next refresh.
+Before, the whole refresh failed and every `views/calendar/` file kept its old contents.
+A read that did not complete is described as incomplete, not as Google refusing access.
+
+**The daemon stops re-downloading what has not changed** (#213). Since 0.22.0 every
+poll fetched every memory fact in full, left `_freshness.md` reporting memory as
+`unknown` / `incomplete_apply`, and re-fetched the extracted text of every PDF. Both now
+happen once. Feeds ask from the server's high-water mark instead of re-reading their
+last page; a full read from the cursor still runs at boot, on `plinth sync` and once an
+hour, so nothing is missed. On the release commit, over 47 minutes after the first pass:
+no full memory-fact downloads, no text re-fetches, no inconsistent trails.
+
+**Each calendar view says what it covers** (#212). A view holds only its window and now
+says so, naming the Plinth tool `list_calendar_events` for any other date. A truncated
+read says why it was cut short.
+
+**What is not proven.**
+
+- The delete fix was driven live on the release commit (a delete inside a poll, and a
+  held batch left 13 minutes past the window: neither came back). A delete within about
+  1.6 s of the lid closing has one exposed poll on wake.
+- The calendar changes were not exercised live: the test workspace has no mapped
+  calendar. They are covered by tests and are checked on a real workspace after release.
+- A sync request that hangs can still stall the poll loop for minutes (seen once, 4 min
+  7 s, in the release check). Pre-existing; not fixed here.
+
 ## 0.23.0 - 2026-09-23
 
 One code PR since `0.22.0` (`v0.22.0..f3334fb`, #207; #204, #205 and #206 docs). A

package/dist/build-stamp.json

@@ -1,5 +1,5 @@
 {
-  "sha": "38edb48dcebc2bbe3f1609c939e93143a8946037",
+  "sha": "0c1d5fec200fb36f10135b8fbe4d34fdb064af94",
   "dirty": false,
-  "built_at": "2026-09-23T22:08:55.967Z"
+  "built_at": "2026-10-04T16:58:56.340Z"
 }