From 601fc98a49847c1ba702640d390b63c83a5aab3e Mon Sep 17 00:00:00 2001 From: Joakim Persson Date: Tue, 8 Sep 2026 22:09:31 +0200 Subject: [PATCH] docs(changelog): release v1.8.14 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Converts the Unreleased section and records what this build carries beyond it: the mempalace-toolkit bump that makes closing replies reach the mailbox (deriveClosed, 21023e7 -> e45f6b4), and the L0-L4 subtask documentation landing via pi-toolkit adfb553 + pi-extensions c64c122. Notes the mechanism that makes the toolkit fix land at all — the resolved toolkit SHA is folded into the content-addressed base tag, so the toolkit moving forces a base rebuild rather than waiting for one — and the consequence for the amd64 item already in this section: v1.8.13's base was cached, so Dockerfile.base:607's agent-browser assertion never ran. This base is not cached, so the native-amd64 proof is finally collected instead of discarded. --- CHANGELOG.md | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index e8a1d11..c60f716 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,7 +11,7 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`). --- -## Unreleased +## v1.8.14 — 2026-09-08 **A test that was quietly checking nothing, and a version number that was wrong.** Both found by delegating a read-only audit of this repo to a headless worker @@ -79,6 +79,60 @@ therefore asking for the impossible, while CI already had the answer and was discarding it. `Dockerfile.base:607` does assert it (`agent-browser --version &&`), but only when the base actually rebuilds — and v1.8.13's base was cached. +**The mailbox now announces replies that CLOSE your own asks.** `mempalace-toolkit` +`21023e7` → `e45f6b4`, which adds `deriveClosed()` alongside `deriveOwed()`. The old +path queried `status: open` and joined for a reply, which by construction can only +surface asks *you owe someone else*; a terminal reply carries `status: applied` +(or `blocked`/`failed`), so **the answer to your own question was structurally +invisible** — the one notification a human actually wants. Measured: `emb-7kj4vr4g` +closed the v1.8.13 rollout ask at 18:31Z with `status=applied`, the operator +reasonably expected to hear about it, and the mailbox stayed silent while being +correct by its own definition. Nine closed correlations were sitting unannounced. +Shares the 1-hour resurface floor, so a close is announced once and is news rather +than a nag. + +This lands **because the base rebuilds**, which is worth stating explicitly: the +CI-resolved `mempalace-toolkit` SHA is folded into the content-addressed base tag +(`base-decide`), precisely so a toolkit-only fix cannot silently fail to land +behind an unchanged `Dockerfile.base`. The floating `main` ref was left alone on +purpose — the toolkit moving *forces* the rebuild rather than waiting for one. + +**A consequence worth noting for the amd64 item above: this release actually +collects that proof.** v1.8.13's base was cached, which is why +`Dockerfile.base:607`'s `agent-browser --version &&` never ran. v1.8.14's base is +not cached, so both that assertion and the new `EXPECTED_NODE_MAJOR` gate execute +on a native `linux/amd64` runner. The fleet's first *kept* amd64 runtime proof for +the `linux-x64` ELF should be an artefact of this build rather than something +asked of a device that cannot supply it. + +**Subtask delegation is documented — including the rung nobody built.** The image +picks these up through their resolved refs (`pi-toolkit` `adfb553`, +`pi-extensions` `c64c122`, the latter also refreshing the baked fallback skill): + +- an operator-facing decision guide in pi-toolkit's `README.md`, built on the + L0–L4 context ladder — how much of the parent session a child can see is the + axis that explains nearly every observed good and bad behaviour; +- the canonical `pi-extensions` skill gains the same ladder next to *Boundary + discipline*, which until now diagnosed why an inherited transcript defeats a + brief without offering any alternative to "don't fork that"; +- one bullet in the global `AGENTS.md`, so the choice is visible without loading + a skill, and naming `pi-task` as a **CLI** — an agent hunting for a `pi_task` + tool finds none and concludes it is unavailable. + +What the ladder records: **L0/L1/L2 exist** in `pi-task` (`context.facts` / +`.files` / `.commands`), **L4** is `fork`'s only behaviour (`getHeader()` + +`getBranch()`, no offset or limit anywhere in the call chain), and **L3** — a +truncated branch — **is not implemented by anything**, which is now written down +instead of being a design idea somebody remembers. + +Also recorded, found while writing the above: `pi-fork/src/runner.ts:188` reads +`if (extensions !== null) args.push("--no-extensions")`. So `extensions: []` turns +the capability floor **on** and `null` turns it **off** — and `null` is the +documented way to "restore normal extension loading", so tidying `[]` to `null` +as a no-op re-arms palace writes inside every fork child. `pi-task` hardcodes the +flag and cannot drift this way. Documented in three places because the edit that +triggers it looks harmless. + --- ## v1.8.13 — 2026-09-06