@plinth-music/cli 0.23.1 → 0.23.3

package/CHANGELOG.md

@@ -2,6 +2,97 @@
 
 Notable changes to `@plinth-music/cli`. Grouped by what a user notices, not by PR.
 
+## 0.23.3 - 2026-10-07
+
+Three code PRs since `0.23.2` (`v0.23.2..64c6759`: #222, #223, #224; #221 docs).
+A patch: fixes only, no new command or sync surface.
+
+⚠️ **Saves made in quick succession are no longer lost** (#222). When a document was
+saved twice within about a second, as an agent often does, the daemon's own pull could
+write an earlier version back over the later saves. Those edits were then gone from the
+laptop and from Plinth alike, and `plinth status` showed nothing wrong. On the test
+workspace, 9 of 50 saves made 0.6 seconds apart were lost before this fix and none in
+the runs after it. The pull now leaves a file alone while it holds a save that has not
+been sent yet, and lets the save go up first. This covers documents, tasks, projects and
+meetings. **Artists are not covered yet**: their two files share one version, and that
+needs its own fix first.
+
+⚠️ **A file you save under `files/` survives a pull or a restore** (#224). A save made
+while the daemon was pulling or restoring the same file could be overwritten with no copy
+kept. The save now stays where it is for its own upload; if a teammate's change wins,
+your version is kept in `_conflicts/`. A teammate deleting a file in Plinth no longer
+removes a newer copy you hold.
+
+**`plinth status` lists what the daemon is holding back** (#224). A new **Held** section
+names each file the daemon kept rather than overwrote or deleted - a copy that could not
+be made, a download that failed its integrity check, or a file kept after a teammate
+deleted it - with what to do about each. An unchanged held file is not downloaded again.
+
+**A crafted file header can no longer pin your CPU** (#223). The YAML reader inside the
+frontmatter library moves to 3.15.2, which fixes four advisories where a header with
+chained merge keys took quadratic time to read. A teammate's crafted header, or a
+compromised account, could otherwise stall the daemon of every member who pulled it.
+This is the other half of 0.23.2's header fix.
+
+**What is not proven.**
+
+- Artists still use the old pull path, as above.
+- A save landing during a conflict round trip, about a second, can still end up in
+  neither place. That belongs to the Sync Conflicts work.
+- For a kept file over 4 MB, Held says it goes back into Plinth the next time the daemon
+  starts. A restart uploaded nothing. The file is safe on disk; the wording is wrong.
+- A kept file logs the same line on every poll for up to an hour. Nothing is downloaded,
+  written or sent.
+- #224 was proved live with two isolated daemons on the test workspace; the ambient
+  pull's own download window is proved in tests only.
+
+## 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).

package/dist/build-stamp.json

@@ -1,5 +1,5 @@
 {
-  "sha": "9dd9f6493dc707acce22c95ce564d8b189dbf27d",
+  "sha": "e6eaa1b6b2068e06d059fada822e201e983e1de6",
   "dirty": false,
-  "built_at": "2026-09-29T22:26:55.840Z"
+  "built_at": "2026-10-07T17:31:25.749Z"
 }