@plinth-music/cli 0.6.0 → 0.8.0

package/CHANGELOG.md

@@ -2,6 +2,70 @@
 
 Notable changes to `@plinth-music/cli`. Grouped by what a user notices, not by PR.
 
+## 0.8.0 — 2026-08-23
+
+Two PRs and two direct commits since `0.7.0` (`v0.7.0..af83c59`). The daemon
+survives a failed confirm gate, and the map it writes tells an agent which
+command answers which question. No server prerequisite: both changes are
+client-side, and a 0.7.0 client is unaffected.
+
+### A failing confirm gate no longer takes the daemon down with it
+
+Both destructive gates fire their settle window fire-and-forget, so a rejecting
+`onSettle` surfaced as an unhandled rejection and **terminated the long-running
+daemon** — with the batch already lifted out of the gate's pending buffer, so its
+remaining operations were neither pushed nor quarantined. Work disappeared behind
+a process that had simply stopped.
+
+Three layers now catch it. The gate reports a settle failure through a new
+`onError` callback instead of rejecting into the void. The under-threshold flush
+catches per-operation failures, logs the same `[PUSH_FAILED]` / `[FILE_PUSH_FAILED]`
+lines the watch path already used, and hands recordable ones to the unsynced net
+so the poll tick re-drives them — one operation failing no longer skips its
+siblings. And a failed quarantine write warns on the banner rather than rejecting.
+
+### Every mirror's `CLAUDE.md` says how to traverse the corpus
+
+A new **Navigating the corpus** section: three lookup lines mapping a traversal
+question to the surface that answers it — what points at X (`plinth backlinks`),
+what this file links to (grep `[[`), and how to find a file by name, text inside a
+PDF, or an entity by field.
+
+`plinth backlinks` shipped in `0.6.0` and appeared in no generated context.
+Measured on the live mirror, the generated text carried no `backlinks`, no
+`wikilink` and no `[[`, while the command answered a real query with 7 files and
+16 occurrences. A/B on the live mirror, same question in two fresh sessions: with
+the section, the first tool call was `plinth backlinks`; without it, `grep -ril`.
+
+The generated file's line bound moves 51 → 56. Its schema-version stamp does not —
+the section is inline literal text, and none of the five constants the stamp hashes
+changed.
+
+## 0.7.0 — 2026-08-23
+
+One PR and one docs commit since `0.6.0` (`v0.6.0..71c775c`). The mirror gains a
+calendar the agent can read without opening one.
+
+### Each artist's calendar is projected into the mirror
+
+`plinth start` now runs a second loop on its own 15-minute timer
+(`PLINTH_CALENDAR_INTERVAL_MS`, one run at boot), writing `views/calendar/` into the
+mirror: a file per mapped artist plus an `upcoming.md` across all of them.
+Deliberately not the 15-second pull loop — one tick fans out to one Google call per
+mapped calendar, which would breach the server route's 20/min limit inside a minute.
+
+`/plinth:start` gains a step that reads one of those files. It still does not open a
+calendar, and the generated text says so.
+
+**An empty cache and a clear diary are not allowed to look alike.** `events: []` means
+exactly one thing and is refused on any row that did not actually fetch; a failed
+refresh keeps every body and rewrites only the header, so a stale view says it is
+stale rather than saying nothing is on; an artist with no mapped calendar is named in
+`upcoming.md` rather than silently absent.
+
+**Requires the server's `GET /api/sync/calendar`** (`plinth` #257), live in
+production. A 0.6.0 client is unaffected: it never calls it.
+
 ## 0.6.0 — 2026-08-20
 
 Eleven PRs since `0.5.0` (`v0.5.0..af8c7df`). A session in a mirror now opens and

package/README.md

@@ -24,7 +24,7 @@ plinth start                      # run the daemon: continuous pull + watch + pu
 
 - `plinth login --workspace <slug>` — issue a personal access token in the browser, paste it back, store it in the OS keychain (macOS Keychain / Linux Secret Service / Windows Credential Manager).
 - `plinth sync [--workspace <slug>]` — one-shot pull into `~/Plinth/<workspace>/`. Also generates the workspace-root `CLAUDE.md` (a thin TOC + entity model + skill pointers), an empty `CLAUDE.local.md` stub on first sync, and the two session-boundary commands (below), and silently refreshes `CLAUDE.md` on a schema-version change. Defaults to the active workspace if `--workspace` is omitted.
-- `plinth start` — run the long-running sync daemon: pull the latest, then watch the mirror for local edits and push them. Logs to `~/.plinth/daemon.log`.
+- `plinth start` — run the long-running sync daemon: pull the latest, then watch the mirror for local edits and push them. It also projects each mapped artist's Google calendar into `views/calendar/` in the mirror — a file per artist plus an `upcoming.md` — on its own 15-minute timer (`PLINTH_CALENDAR_INTERVAL_MS`), with one run at boot. That is deliberately not the 15-second pull cadence: one tick makes a Google call per mapped calendar, which would breach the server route's rate limit inside a minute. A refresh that fails keeps the last known bodies and rewrites only the header, so a stale view says it is stale rather than reading as an empty diary. Logs to `~/.plinth/daemon.log`.
 - `plinth status` — local sync state: daemon liveness, last sync and per-type counts, and any destructive batches being held. Warns when a source install's `dist/` is behind its checkout.
 - `plinth confirm` — review and release destructive batches the daemon has quarantined (apply, or `--discard`).
 - `plinth refresh-context [--workspace <slug>]` — force-regenerate the workspace-root `CLAUDE.md` **and the two generated commands** from the current Plinth schema + workspace. The user-customisable block between the `<!-- BEGIN: user-customisable -->` / `<!-- END -->` markers is always preserved verbatim in every generated file; `CLAUDE.local.md` is never touched.

package/dist/build-stamp.json

@@ -1,5 +1,5 @@
 {
-  "sha": "8ae75780594f0715a00b4ee07af7d49ec055c3fd",
+  "sha": "4a3be5d977539351a0cc5c0adc5617cb706b676b",
   "dirty": false,
-  "built_at": "2026-08-20T17:35:39.314Z"
+  "built_at": "2026-08-23T20:04:35.148Z"
 }