5 Commits

Author	SHA1	Message	Date
joakimp	a2846a5f7e	release: adopt pi 0.84.4 + pi-atelier v0.10.0, and fix the doc claim the pi bump invalidates ... pi 0.84.3 -> 0.84.4 (no Breaking Changes / Removed heading in that section, grepped). Adopted for three fixes that land on machinery this fleet runs: #6879 (large tool results crossing the auto-compaction threshold were sent to the provider before compacting), #8345 (a resumed session corrupted its next appended entry when the JSONL lacked a trailing newline -- that file is the memory feeder's input; measured 49/49 clean here beforehand), and #8537 (triggerTurn:false messages sent mid-run were inserted between a tool call and its result). The mempalace mailbox is outside #8537's precondition: it delivers at agent_settled with deliverAs:"steer" and no triggerTurn, and 0.84.4 leaves the documented steer semantics unchanged. pi-atelier v0.8.2 -> v0.10.0: two minor releases, both UI-only, no BREAKING notice. v0.9.0 raises its minimum pi to 0.84.0 and, unlike the 0.7.1-under-pi-0.84 startup-hang precedent, encodes it in peerDependencies (>=0.84.0). Satisfied by PI_VERSION=0.84.4. Both executable floors compare with sort -V, so 0.10.0 >= 0.7.1 evaluates correctly. docs/observational-memory.md: pi's own compaction.md gained one paragraph in 0.84.4 -- autoCompact is now also checked mid-run, after a tool batch's results are appended. Our text said compaction is checked only when pi goes idle and so "never interrupts a turn"; that was only ever true of the OM trigger. The section now states both entry points into session_before_compact and the diagram carries the second edge (mermaid checker re-run: 6 blocks, 44 labels, 0 soft-wrapped, no cut glyphs at 1280px and 800px). README: the version-pin table had been wrong since v1.8.6 -- 93f986e moved ARG PI_VERSION to 0.84.3 and MEMPALACE_VERSION to 3.8.0 and neither table row, so it advertised pi 0.84.2 / mempalace 3.7.1. Corrected, plus the --expected-version example that would now fail against a 0.84.4 image. CHANGELOG: Unreleased retitled v1.8.12 (2026-08-31) with the audits above and a dependency-audit table -- every other component measured SAME (skillset snapshot --check OK at a12fe5e, 0 commits since baked).	2026-08-31 07:08:41 +02:00
Joakim Persson	8a673ec143	docs: unclip the diagrams, and answer what compaction leaves behind ... Two problems reported against docs/observational-memory.md, one cosmetic and one substantive. Both turned out to be worth more than the fix. Clipping. Several boxes lost their bottom line of text in the viewer, and neither the source nor my own render showed it. Cause: Mermaid measures a node label with its own font metrics, commits to a box size, then renders that label as real HTML in a <foreignObject> — so any host stylesheet touching line-height or font-size inflates the text past a box that is already fixed, and the overflow is clipped. The error accumulates per line, which is why it always eats the last line of the tallest labels. Rejected the obvious fix after testing it rather than assuming it: %%{init: {'flowchart': {'htmlLabels': false}}}%% *is* honoured (labels switch from 16 foreignObject to 7 tspan) and clips identically, because inflated font-size inherits into SVG text too. The fix that works is a hard limit of two short lines per node, with the detail moved into prose under each diagram — one- and two-line boxes have the vertical slack to absorb inflation, three- and four-line boxes do not. The nodes were carrying paragraph-sized text; the diagrams are better for losing it. Regression harness: render every block with line-height: 1.7 !important forced onto the label HTML, screenshot, read it. That caught two survivors of the rewrite that looked fine in the clean render — a long unbreakable /opt path wrapping to a third line, and a cylinder shape whose curved bottom leaves less room than a rectangle for the same two lines. New §4, because the document explained that compaction folds the ledger and never said what that leaves in the context. Asked directly: is the session back to knowing nothing? No. A verbatim tail survives, sized by keepRecentTokens (20k) and cut only at turn boundaries; the system prompt and AGENTS.md were never in the compacted region because they are rebuilt from disk each request; nothing is deleted from disk, since compaction appends a compaction entry rather than rewriting lines; and recall keeps resolving ids whose sources left the context because it reads the full branch via sessionManager.getBranch() and never consults the context window. Repeated compaction renders from live records, not from the previous summary's prose, so there is no generation-loss spiral. Also corrects this repo's own "compaction calls no model" to the steady-state claim it actually is: with an empty ledger the hook returns nothing and explicitly declines ownership, and pi's native model-based summariser runs. Snippet quoted in the doc. And a bug shipped in the first version: §9 said the ledger entries are custom_message and specifically not custom. Exactly backwards, so the one grep that section existed to get right was the one it got wrong. Verified empirically against the live session file — 11 om.observations.recorded and 6 om.reflections.recorded, all "type":"custom", next to "type":"custom_message" entries whose customType is mempalace-mailbox and mempalace-wakeup. That is where the confusion came from, and the distinction is load-bearing rather than cosmetic: the mailbox uses the context-visible append API, om's ledger uses the invisible one. Which makes it a feature the doc now advertises — the ledger costs zero context until it is folded.	2026-08-27 14:24:19 +02:00
Joakim Persson	14371e2da6	docs: explain the memory that runs itself, and fix a claim the mailbox falsified ... `pi-observational-memory` is baked, registered in the seeded settings.json, and handed a cheaper model than the session it serves — and the only description in this repo was five words in a feature list. Someone meeting `/om:status` or a "compacted memory" block had nothing to read that said whether to leave any of it on. New docs/observational-memory.md, 272 lines and five diagrams. Scoped by who is authoritative, so there is one copy of each claim: - Upstream (/opt/pi-observational-memory/docs/) already documents the mechanism well — concepts.md, how-it-works.md, configuration.md, including a v3 lifecycle diagram that matches the deployed code. Linked, not re-derived. - This document takes the four facts pi-devbox owns and can change: the pinned commit it bakes (v3.0.4 ce9fc98, matching build-manifest.json), the packages[] entry that decides which copy loads, the Haiku-workers-vs-Opus-session split, and the devbox-pi-config volume that makes the ledger outlive the container. - Plus the confusion this image creates by shipping two things called memory: a section contrasting it with MemPalace, on the line "observational memory keeps a session coherent, the palace keeps the fleet coherent". Placement follows the split fleet-ops states for itself — reusable mechanism is not deployment data — so a "why is this in my container" document belongs in the repo that pins and wires the component. Linked twice from the README, because until this commit the README referenced docs/ zero times and the file already sitting there was reachable only by listing the directory. Numbers were read out of the live container and the baked tree rather than out of release notes, which caught one thing the pi-extensions skill still has wrong: the dropper is gated on a successful same-turn reflection, not on a token threshold of its own. Also fixes a README sentence that v1.8.9 made false. § Cross-machine agent coordination ended with "Nothing in this image polls the log on the agent's behalf"; the mailbox has shipped since aac4a1c. Replaced with the three knobs and their defaults, derived-not-read owed-ness, and the queued-into-the-next-turn delivery measured on two devices — and dated to "as baked in v1.8.9 (mempalace-toolkit 5b8d78f)", pointing at RFC 003 §7.11–§7.12 for the mechanism, because toolkit main is already ahead (a92c75d pings the human who is not looking) and describing that here would trade a stale-behind claim for a stale-ahead one. The cause is worth more than the fix: the behaviour arrived through the floating MEMPALACE_TOOLKIT_REF, so no diff in this repo ever touched the paragraph making the claim. v1.8.9's own rule fired for the CHANGELOG and nobody swept the README. The CHANGELOG records what changed, the README asserts what is true, and only the first is reviewed at release time — so the rule now extends to grepping the README for absolute claims (nothing, never, does not, only) about a component whose SHA moved. Diagrams were verified by rendering, not by parsing. Both comparison diagrams parsed clean and rendered with their meaning reversed: Mermaid laid the second declared subgraph out first, putting "with observational memory" before "without" and MemPalace before observational memory in the diagram whose entire job was that contrast. Rebuilt as declaration-ordered chains and re-rendered at mermaid@11 — the version pi-studio pins — in the baked headless browser, then read back as an image. mermaid.parse() proves syntax and says nothing about layout.	2026-08-27 13:55:55 +02:00
pi	f8da7890df	docs(mempalace-broker): clarify engine vs shim — what the image must still ship	2026-06-14 18:20:39 +02:00
pi	b17dc1fa1f	docs: add single-writer MemPalace broker design (RFC, queue #4)	2026-06-14 18:06:47 +02:00