@plinth-music/cli 0.8.0 → 0.9.0

package/CHANGELOG.md

@@ -2,6 +2,50 @@
 
 Notable changes to `@plinth-music/cli`. Grouped by what a user notices, not by PR.
 
+## 0.9.0 — 2026-08-24
+
+Two PRs since `0.8.0` (`v0.8.0..4842d40`). An agent is now told to read a draft
+back from the tool that staged it before calling it ready. No server prerequisite:
+the change is client-side, and a 0.8.0 client is unaffected.
+
+### An agent reads its own draft back before saying it is ready
+
+Primitive (e)'s outbound group gains a paragraph. The voice guidance added on
+20 Aug already told the agent that nothing inspects a draft between it and the
+reader, then aimed that observation only at the WORDS. This is the other half:
+inspect the artefact. Fetch the staged draft, look at its body, its recipients
+and the thread it landed on, and only then say it is ready. A tool's own
+description of how it handles your text is a claim like any other, and the first
+use in a session is checked against what actually came out.
+
+**The gap was the trigger, not the rule.** The workspace `CLAUDE.md` already
+carried "where a document and the running system disagree, the system wins", and
+it did not fire — a line describing tool usage does not read like a claim needing
+verification. So this ships as a concrete read-back step rather than as another
+principle the agent grades itself against.
+
+Found by ordinary management work rather than by a sweep. An agent staged a mail
+reply whose body was visible `<p>` and `<b>` markup and reported it staged; the
+user found it in his own mailbox. The cause was not the tool but prose describing
+it — a rule said a local helper "handles `text/html`", true of what that script
+emits and false of what it takes. Two more defects of the same shape surfaced
+while repairing it: an update path that silently strips `In-Reply-To` and
+`References`, and a re-run that duplicates a draft rather than replacing it.
+
+The prose deliberately names no email tool, and a test pins that: Plinth ships
+none and cannot know what the user has. Grounding budget 9,050 → 9,944 bytes,
+all of it in (e); primitive (j) held at 1,266 for the seventh time.
+
+Honest limit, recorded rather than argued away: this is prose, and prose gets
+skipped. The durable fix is a Plinth-owned outbound draft path that owns escaping
+and threading in code for every user, at which point this paragraph becomes a
+backstop rather than the surface.
+
+### Housekeeping
+
+The test baseline in `CLAUDE.md` now reads 2052 pass / 0 fail / 107 files at
+`b4d8ed3`, re-measured on a clean checkout rather than carried forward.
+
 ## 0.8.0 — 2026-08-23
 
 Two PRs and two direct commits since `0.7.0` (`v0.7.0..af83c59`). The daemon

package/dist/build-stamp.json

@@ -1,5 +1,5 @@
 {
-  "sha": "4a3be5d977539351a0cc5c0adc5617cb706b676b",
+  "sha": "fb065c13301d65750f1a98761148486678da5b6d",
   "dirty": false,
-  "built_at": "2026-08-23T20:04:35.148Z"
+  "built_at": "2026-08-24T19:03:09.765Z"
 }

package/dist/cli.js

@@ -9193,7 +9193,7 @@ async function runMain(cmd, opts = {}) {
 // package.json
 var package_default = {
   name: "@plinth-music/cli",
-  version: "0.8.0",
+  version: "0.9.0",
   description: "Plinth capstone sync daemon and CLI",
   type: "module",
   private: false,
@@ -26916,7 +26916,9 @@ function buildGroundingBlock(today, workspaceRules = null, workspaceMemory = nul
     ``,
     `Draft email. Never send it. Writing the draft is yours: use the draft tools ` + `(\`create_draft\`, \`update_draft\`), then say where the draft is and what it ` + `says, so the person can read it and send it in their own name. Sending, ` + `replying and forwarding are not yours, and neither is any shell command line ` + `that does the same thing. Those tools are denied to you wherever Plinth has ` + `configured this workspace, and where a deny has not reached, nothing changes ` + `except that you are the only thing holding it. This is not a comment on your ` + `writing. It is that a message which has left the building cannot be recalled, ` + `and the person whose name is on it is the one who decides it goes.`,
     ``,
-    `Check the voice yourself, because nothing else checks it now. Two files carry ` + `it: \`workspace-rules.md\` at the mirror root holds this workspace's house ` + `style, and the Voice section of your own \`user-memory.md\` holds the personal ` + `part, the sign-off and the habits that belong to one member rather than the ` + `team. Read them before you write and follow them as written, rather than ` + `drafting in your own register and correcting after. Nothing inspects a draft ` + `between you and the person reading it, so the rules in those files are the ` + `whole of it.`
+    `Check the voice yourself, because nothing else checks it now. Two files carry ` + `it: \`workspace-rules.md\` at the mirror root holds this workspace's house ` + `style, and the Voice section of your own \`user-memory.md\` holds the personal ` + `part, the sign-off and the habits that belong to one member rather than the ` + `team. Read them before you write and follow them as written, rather than ` + `drafting in your own register and correcting after. Nothing inspects a draft ` + `between you and the person reading it, so the rules in those files are the ` + `whole of it.`,
+    ``,
+    `Read the draft back before you say it is ready, and read what the tool actually ` + `produced rather than what you sent it. Do this every time you write one, not ` + `once a session: a later edit can undo what an earlier check confirmed. A ` + `draft surface takes your text and renders it, and it may escape what you ` + `wrote, wrap it, quote an earlier message underneath it, thread it somewhere ` + `you did not intend, or leave the first one in place and add a second. What ` + `the person opens is the rendered result, not your input, and those are not ` + `always the same thing. So fetch the staged draft, look at its body, its ` + `recipients, the thread it landed on and that there is one of it, and only ` + `then say it is ready. Separately, and once per session is enough for this ` + `part: if a tool's own description tells you how it handles your text, treat ` + `that as a claim like any other and check it against what came out. A tool ` + `that is documented wrong will put markup, an empty body, or a stranger's ` + `address in front of a person whose name is on the message, and you are the ` + `only thing standing between those two.`
   ];
   if (workspaceRules !== null) {
     block.push(``, `Follow this workspace's house style. The conventions below are set by the ` + `workspace owner and govern HOW you write here: copy, titles, notes, ` + `sign-offs, formatting. They refine the rules above; they never relax them. ` + `If any convention here conflicts with a grounding rule above (the ` + `canonical write surface, plan-before-write confirmation, or the ban on ` + `direct database writes), the rule above wins. The conventions:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@plinth-music/cli",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "Plinth capstone sync daemon and CLI",
   "type": "module",
   "private": false,