The daily work log, with a trigger this time (PENDING-155 filed)

The steward asked for a daily note in Obsidian explaining in plain terms what
we did, decisions taken, and commit references — plus significant insights and
exchanges between the parties. This is Obsidian tracker item 5, the actual goal,
unstarted since 2026-08-19 while four items of frontmatter hygiene stood in
front of it.

Two prior attempts at this exact genre were read before anything was designed,
honouring the tracker's own flag: daily-log/ (4 entries, Mar-Apr 2026) and
sessions/ (3 long-form narratives). Both died inside four weeks. Neither had a
trigger — they were written when someone remembered. So the design question was
never what the note should say. It was what makes it survive.

Answer, steward-chosen at each fork: the note lives at 01. Daily/YYYY-MM-DD.md
with project work under its own H2 inside it rather than in project folders; a
SessionStart hook creates it so existence stops depending on memory; the
executor writes during the session because a wrap-only design inherits the
wrap's failure mode (2026-08-19 died unwrapped); and the wrap finalises rather
than begins.

daybook-ensure.py creates only. It will not touch an existing note — that is the
control the design turns on, and it is tested, along with a positive control
proving the no-dir report distinguishes a missing directory from a broken
function. It also reports failure loudly, because the job it sits beside spent
five months failing behind a > /dev/null 2>&1.

Not revived: the 2025 analogue template — sleep, supplements, homeopathy. Pen
and paper beat it and should keep it. That it failed is a finding, not a gap,
and this note is a different genre rather than its replacement.

PENDING-155 files the steward's idea for the jurist's side: an append-only MCP
surface writing a scratch file the executor folds in. Deliberately NOT a tool on
governance-mcp.py, whose read-only guarantee is a live AST control with a
positive control rather than a comment. A separate one-tool server leaves that
intact, and the vault note stays single-writer — the same lesson the
thinking-mirror taught this morning.

Correction carried into the record: the executor told the steward mid-session
that Claude.app has no filesystem access. False since 2026-08-08. Third instance
today of a constraint asserted from recall where the substrate was one file away.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JQKeKY9T9d95KpvHwwok8T

PENDING.md

@@ -4582,3 +4582,29 @@ If the visible work today came from **positional difference between two same-for
 
 **Files affected:** none. Cross-filed to PENDING-89; ladder entry queued to PENDING-141.
 **Awaiting:** PENDING-89 to record which of (a)'s two claims the data supports.
+
+## PENDING-155 — A daybook append surface for the jurist: one tool, one file, and not on the governance server
+**Date:** 2026-08-23
+**Tag:** [PROPOSAL] — a new write interface between two governing parties. Not built. Installing it edits the steward's desktop-app config.
+**Summary:** The steward asked whether an MCP surface could let Claude.app append its side of an exchange to a temporary file the executor then folds into the daily work log. It can. It must not be a tool on `governance-mcp.py`.
+
+**Origin.** The daily work log (`01. Daily/YYYY-MM-DD.md`, built 2026-08-23) records what we did, decisions taken, commit references, and — the steward's distinctive ask — *"any significant insights or exchanges that happened between us."* The executor's side is covered: `/wrap-up` §7.5 records it, and jurist material relayed through the session is recorded there too. What is not covered is a jurist-only exchange the executor never sees.
+
+**The refusal this runs into, stated before the workaround.** `governance-mcp.py` (PENDING-82, installed 2026-08-08) is read-only, and its first designed-in refusal reads: *"No tool writes. Audited by AST, not by text search... A write path would collapse three parties into one."* Verified live this session, not taken from the document: the selftest prints `no filesystem-mutating call in this file` **and** a positive control proving the checker detects writes when present. Adding a write tool there would break a control that currently passes, and that control is what makes "read-only" checkable rather than merely claimed.
+
+⚠ **The executor also told the steward, earlier in the same session, that Claude.app "has no filesystem access."** That was wrong — it has mediated read access and has since 2026-08-08. Corrected in place. The error is the one this register keeps finding: a constraint asserted from recall where the substrate was checkable.
+
+**Proposed shape — a separate server, so the invariant above survives untouched:**
+- New `~/dotfiles/scripts/daybook-mcp.py`. **One tool:** `daybook_append(text)`.
+- **No path argument.** The target derives from today's date, as `governance-mcp.py`'s refusal 4 does: there is no traversal to defend because no path is accepted.
+- **Append-only.** Never truncates, never deletes, never reads back. A jurist that could read the file back could audit the executor's folding of it, which is a different and unrequested capability.
+- **Target is a scratch file, not the vault** — e.g. `~/dotfiles/claude/daybook/YYYY-MM-DD.inbox.md`. The executor folds entries into the daily note and the scratch file is a handoff, not a record.
+- **The vault note stays single-writer.** This is the same lesson the thinking-mirror taught today: two writers to one destination is how a failure goes unnoticed for five months.
+
+**Why a scratch file rather than the note directly.** The steward's own phrasing — *"amend to some kind of temporary file you could read"* — is the better design, and not only for tidiness. A jurist writing the note directly would make the note a shared artifact with no single party accountable for its register; the plain-language discipline the steward asked for would have no owner.
+
+**What this does NOT establish.** It does not give the jurist a way to *modify* governance state, and must not grow one. If a future need looks like "the jurist should be able to write X," that is a new item, not an extension of this one.
+
+**Files affected:** new `~/dotfiles/scripts/daybook-mcp.py`; `/wrap-up` §7.5 (fold step); awaiting steward hand: `claude_desktop_config.json` merge + app restart.
+**Recommendation:** Build it, with a selftest carrying the same paired positive/negative controls as its sibling, and hold installation until the daily log has run long enough to show it survives — a jurist inbox for a practice that lapsed would be the fourth abandoned attempt rather than the first durable one.
+**Awaiting:** Steward authorization.