mercury-agent 0.19.0 → 0.20.0

package/docs/goals/football-reporter-profile/decisions.md

@@ -616,3 +616,82 @@
 - **Used by:** football-reporter-profile roadmap (M2.2 row),
   `docs/bugs/model-switch-disables-fallback.md` (the reset-verb constraint),
   `docs/ideas/scheduled-task-model-leg-policy.md`
+
+## D-023: The club markers are the owner's 2026-09-03 set, a marker may be two emoji, and Maccabi Tel Aviv is standing coverage (decided 2026-09-03)
+- **Category:** editorial standard / process (applies [D-020](#d-020-live-tuning-is-adopted-into-the-repo-not-reverted--and-scans-carry-a-fixed-club-emoji-decided-2026-08-31) a second time)
+- **Decided:** (1) The scan markers are now מנצ'סטר יונייטד 👹, ברצלונה ❤️💙,
+  ריאל מדריד 🤍, הפועל תל אביב ❤️, בית"ר ירושלים 💛🖤, מכבי חיפה 💚 and
+  מכבי תל אביב 💛💙 — seven clubs, chosen by the owner in the football chat on
+  2026-09-03 between 12:35 and 12:55 IDT (messages #4210–#4223) and written by
+  the bot into the live `AGENTS.md` and `MEMORY.md` at 12:55. The repo adopts
+  the live text verbatim, as D-020 says; the diff was exactly the two owner
+  changes and the file contradicts itself nowhere. (2) A marker is the **whole
+  emoji run that opens the line**, compared as one unit and without variation
+  selectors. That is what keeps a bare ❤️ (Hapoel) from passing as half of
+  ❤️💙 (Barcelona), and what keeps a phone that drops or adds U+FE0F from
+  turning a correct post into a finding. (3) Maccabi Tel Aviv joins the
+  standing coverage (`## תפקיד`) with a seeded notebook, the same shape as the
+  five seeded on 2026-08-21; the live space already had one, opened by napkin
+  on 2026-08-31, so `apply` writes nothing there.
+- **Alternatives considered:**
+  - *Revert the box with `apply`.* Rejected by D-020: the edit is the owner's,
+    dated, and the first post under it went out at 14:04 IDT the same day.
+  - *Keep single-emoji markers and ask the owner to pick seven singles.*
+    Rejected: the owner chose pairs deliberately ("תן גם רצפים של אמוג'י") and
+    the lint is the thing that has to follow the standard, not the reverse.
+  - *Compare markers with their selectors.* Rejected: the bot wrote ❤ with
+    U+FE0F and 🖤 without in the same line, and nothing guarantees the next
+    model or phone does the same. Two fixtures pin the normalisation in both
+    directions (`scan-marker-without-selector`, `scan-marker-with-extra-selector`)
+    because a mutation that removed it passed every other fixture.
+  - *Add Maccabi Tel Aviv as a ninth article research topic.* Not done: the
+    article checklist already names מכבי ת"א under item 5 and the standard's
+    coverage line is the authority for what the space covers; if the club's
+    league news stops reaching the article once its European run is over,
+    that is a task-prompt change on its own evidence.
+- **Reasoning:** `space-profile check` reported the drift within the hour and
+  an `apply` would have written the 2026-08-31 emoji back over the owner's
+  decision — the same shape as the `feed-watch.terms` clobber of 2026-08-31.
+  The lint allowlist compared one emoji at a time, so every two-emoji marker
+  would have been reported twice (not allowed, and two emoji on one line) the
+  moment the fixtures caught up with the standard. The invisible selector is
+  the CLAUDE.md carrier trap in a new coat: it is spelled as an escape in
+  `standard.json`, the fixtures and the tests, and a consistency test fails if
+  the literal character ever appears in the JSON.
+- **Revisit if:** the owner changes a marker again from chat — then the
+  repo-side steps are the same four files (`AGENTS.md`, `standard.json`,
+  `cases.json`, the seeded `MEMORY.md` list) and this entry's date moves; or
+  the lint ever needs a marker of three emoji, which `leadingEmoji` already
+  accepts but no fixture pins.
+- **Used by:** football-reporter profile (`AGENTS.md` § תפקיד and § פורמט,
+  `standard.json`, `config.yaml` `workspace_seed`), `src/text/reporter-lint.ts`
+  (`leadingEmoji`, `emojiKey`), M4.1 regression map (F7c), `MEMORY.md` seed
+
+## D-024: `feed-watch.max_per_hour` is 3, with the 15-minute batch kept (decided 2026-09-03)
+- **Category:** run budget / process (applies [D-020](#d-020-live-tuning-is-adopted-into-the-repo-not-reverted--and-scans-carry-a-fixed-club-emoji-decided-2026-08-31) a third time)
+- **Decided:** The scan cap is **3 runs per hour**, not the 1 set on
+  2026-08-31. The owner set it from the dashboard on 2026-09-03 at 01:19 IDT
+  and confirmed it in writing the same afternoon ("I want max_per_hour=3").
+  `batch_minutes` stays at 15, so at most four batches an hour can open and
+  the cap only bites on a burst. The repo adopts the value; `apply` no longer
+  reverts it and the sync's profile check goes clean.
+- **Alternatives considered:**
+  - *Keep 1/hour and treat the dashboard write as an experiment.* Rejected: it
+    had been live for a day, the owner was asked and chose 3, and D-020 says the
+    repo follows the box, not the reverse.
+  - *Raise the cap and shrink the batch back to 4 minutes.* Not done: the
+    15-minute batch is what merges several outlets carrying one story into one
+    run, and that is the cheaper half of the 2026-08-31 change. The cap and the
+    batch are separate levers; only the cap moved.
+- **Reasoning:** the owner's; no reason was given and none is recorded here.
+  What the numbers say: the cost law is runs × prefix, the 2026-08-31 cut was
+  aimed at the ~70 % of runs answering NO_UPDATE, and the 15-minute batch is
+  the half of that change that merges one story's outlets into one run. Spend
+  under 3/hour with the 15-minute batch on 2026-09-03 was $4.92 by 14:04 IDT
+  for 18 runs (10 posted), in line with the two days before, so the cap was
+  not the binding factor that day.
+- **Revisit if:** a day passes 30 runs or the NO_UPDATE share climbs back
+  above half — then the batch, not the cap, is the first lever; or the real
+  group is linked and the owner wants a quieter feed.
+- **Used by:** football-reporter profile (`config.yaml`), profile README,
+  `space-profile check` on every sync

package/docs/goals/release-gate/decisions.md

@@ -111,10 +111,42 @@
   then it is a Mercury feature, planned as one.
 - **Used by:** smoke-runner, release-gate-rules
 
-## G-007: Whether Mercury publishes its own agent image — OPEN, owner's call
+## G-007: Mercury publishes its own agent image; visibility stays private for now
 - **Category:** architecture / distribution
-- **Status:** **Open.** R0.3 is blocked on it; R0.1, R0.2 and R0.5 are not.
-- **Question:** Mercury's release workflow publishes the npm package and
+- **Status:** **Decided 2026-09-06/07 by the owner in two parts.** *Publish:*
+  yes — `release.yml` builds and pushes the image (R0.3, landed).
+  *Visibility:* **private, for now** — the owner's pushback on 2026-09-07
+  was right that nothing forces public: both consoles already pull private
+  GHCR images with a PAT, so private is proven, and a package inherits the
+  repo's private visibility on first push, so private is also the
+  zero-action outcome. The earlier "public" wording here was written from
+  the first half of the answer before the second was given; it is amended,
+  and the record of both branches is kept below.
+- **What this commits to:** `release.yml` pushes
+  `ghcr.io/avishai-tsabari/mercury-agent:<version>` and `:latest` after
+  npm publish (R0.3). The package is NOT flipped to public. A third-party
+  install path therefore still does not exist, and the README must say so
+  honestly rather than imply one — that is the follow-up private incurs.
+  R0.4 may pin the default tag to `:${pkg.version}` once per-version tags
+  are being pushed; a pull token stays a requirement of every box, as it
+  is today.
+- **What public would buy, recorded for the revisit:** not disclosure — the
+  image is built from a tarball anyone can already `npm pack`, and the moat
+  is the profiles, in neither artifact. It buys the deletion of a
+  credential class from the owner's own fleet: no PAT base64-embedded in
+  cloud-init userdata (readable back from the Hetzner metadata service),
+  no plaintext copy in the node `.env` for Watchtower, no root-0600 token
+  file kept on every box for its lifetime, no manual per-box rotation
+  runbook, and no "PAT expired silently, box looks healthy until first
+  use" failure class — each of which the two consoles document about
+  themselves. Against that: a support surface outsiders can use and will
+  expect to keep working, and the end of "the agent image is a private
+  product" as a positioning stance.
+- **Do regardless of visibility:** the PAT in `mercury-cloud-console`'s
+  userdata and node `.env` reads every package on the account. A dedicated
+  machine user with `read:packages` on this one package shrinks the blast
+  radius; the fleet's own 2026-08-13 note already recommends it.
+- **Question (as it stood):** Mercury's release workflow publishes the npm package and
   nothing else. The agent image every fleet box runs is built and pushed by
   `agent-image.yml` in **tagula-agents**, from Mercury's published npm
   tarball. Mercury's own `ghcr.io/avishai-tsabari/mercury-agent` is pushed
@@ -136,17 +168,31 @@
 - **The two answers, and what each commits to:**
   - **Public.** One publishing path, third-party installs work, R0.4's
     version pin becomes safe, `agent-image.yml`'s version-linking half
-    retires. Commits to publishing a built artifact of a private repo —
-    the same reason the fleet image is private — so it is an open-core
-    boundary decision, not a CI one.
+    retires. It is still an open-core boundary decision rather than a CI
+    one — but the disclosure half of that objection does not survive the
+    evidence. **Verified 2026-09-06, unauthenticated:** `npm pack
+    mercury-agent@0.18.2` returns a 378-entry tarball carrying all of
+    `src/`, `container/Dockerfile` and every source its `COPY` list names.
+    The image is built *from that tarball*, so publishing it discloses
+    nothing npm already publishes to anyone who asks. The moat is the
+    profiles, and they are in neither artifact. What public does commit to
+    is a **support surface**: an install path outsiders can use, and will
+    therefore expect to keep working.
   - **Private (or no change).** Nothing outside the fleet can install
     Mercury. Then say so: `docs/container-lifecycle.md:225` currently
     claims "Images are published on each release", which is false today
     either way, and the README's install steps imply an independent
     install that does not exist.
+- **Reasoning (publish half):** one publishing path beats two, and the
+  path belongs with the artifact it publishes. **(visibility half):** the
+  cost private carries is one the fleet already pays for its own image, so
+  keeping it costs nothing new today; public is reversible with one click
+  later, and the moment to decide it with full information is when
+  `agent-image.yml` retires — that is when the pull token could actually
+  become deletable.
 - **Not in scope of this decision:** the fleet's idle check, database
   snapshot, rollback and stagger. Those are topology and stay in
   tagula-agents whatever is decided here (G-006).
-- **Revisit if:** a second operator appears, or Mercury is open-sourced.
+- **Revisit if:** `agent-image.yml` in tagula-agents retires (decide visibility then, with the token's future known); a second operator appears; or Mercury is open-sourced.
 - **Used by:** mercury-publishes-image (R0.3), image-refresh-and-visibility (R0.4)
 

package/docs/goals/release-gate/roadmap.md

@@ -1,7 +1,7 @@
 # Roadmap: Release Gate
 
 **Goal**: [release-gate](goal.md)
-**Last updated**: 2026-09-06 (R0 added: the image supply side R1.1(c) reads from, and nobody owned)
+**Last updated**: 2026-09-07 (G-007 amended: publish yes, private for now. R0.1–R0.3 Mercury side landed; lint drift cleared, release path green)
 
 > Order is by leverage against the live risk, not by size: R1 protects the
 > customer box within a session or two and depends on nothing; R2 is the
@@ -32,10 +32,10 @@
 
 | ID | Story | Slug | Depends on | Status |
 |----|-------|------|------------|--------|
-| R0.1 | **The image describes itself.** `container/Dockerfile` + `container/build.sh` stamp, at build time, (a) `org.opencontainers.image.version` and a mercury-namespaced version label taken from `package.json`, not hand-typed, and (b) the **`COPY`-source manifest** R1.1(c) checks against — generated from the Dockerfile's own `COPY` list so the two cannot drift. `build.sh` tags `:<version>` as well as `:latest`. Labels are inherited by the derived `mercury-agent-ext-*` image with no builder change (verified on the tagula box 2026-09-05: derived and base both report `0.18.0-beta.0`), so the host-side check works through the image actually executing | image-self-describing | — | backlog — **blocks R1.1(c)** | 
-| R0.2 | **The build-integrity gate moves into this repo.** `agent-image.yml` in tagula-agents verifies Mercury's artifact — every `COPY` source present in the tarball, `bun build container-entry.ts` resolves inside the image — and that check is what would have caught 0.17.0. It belongs in `release.yml` (or `bun run check`) so every consumer building the image gets it, not only this one fleet. The fleet keeps its copy or drops it; either is fine once this exists | build-integrity-in-mercury | — | backlog |
-| R0.3 | **Mercury publishes its own image.** A job in `release.yml`, after `publish-npm`, that installs the published tarball, builds, verifies (R0.2) and pushes `:<version>` + `:latest` with the R0.1 labels. Needs `packages: write`, which no job has today. **Gated on the G-007 decision** (public or private): the answer changes whether this closes the third-party install path or only tidies the internal one. Makes `agent-image.yml`'s *version-linking* half redundant; its nightly updater, idle check, snapshot, rollback and stagger stay where they are | mercury-publishes-image | R0.1, R0.2, G-007 | backlog — **decision first** |
-| R0.4 | **A floating tag stops meaning "frozen at first pull".** `ensureImage()` returns the moment `docker image inspect` succeeds, so the default `:latest` is never refreshed and a host upgraded by npm keeps yesterday's container silently — the trap the owner hit on 2026-09-05. Either pin the default to `:${pkg.version}` (safe **only** after R0.3, or every fresh install fails on a tag nobody published) or re-pull a floating tag on a version change. Either way boot logs the resolved image ref, digest and version label so drift is visible without asking | image-refresh-and-visibility | R0.3 | backlog |
+| R0.1 | **The image describes itself.** `container/Dockerfile` + `container/build.sh` stamp, at build time, (a) `org.opencontainers.image.version` and a mercury-namespaced version label taken from `package.json`, not hand-typed, and (b) the **`COPY`-source manifest** R1.1(c) checks against — generated from the Dockerfile's own `COPY` list so the two cannot drift. `build.sh` tags `:<version>` as well as `:latest`. Labels are inherited by the derived `mercury-agent-ext-*` image with no builder change (verified on the tagula box 2026-09-05: derived and base both report `0.18.0-beta.0`), so the host-side check works through the image actually executing | image-self-describing | — | **landed 2026-09-06** — `src/agent/image-manifest.ts` generates the manifest inside the build from the Dockerfile that is building, `container/Dockerfile` stamps `org.opencontainers.image.version` + `com.mercury.version` from an `ARG` and writes `/app/image-manifest.json`, `build.sh` reads the version from package.json and tags `:<version>` + `:latest`. Parser and the host-side `diffImageManifest` are unit-tested; **the build itself is unverified** — four checks in `docs/pending-verification.md` |
+| R0.2 | **The build-integrity gate moves into this repo.** `agent-image.yml` in tagula-agents verifies Mercury's artifact — every `COPY` source present in the tarball, `bun build container-entry.ts` resolves inside the image — and that check is what would have caught 0.17.0. It belongs in `release.yml` (or `bun run check`) so every consumer building the image gets it, not only this one fleet. The fleet keeps its copy or drops it; either is fine once this exists | build-integrity-in-mercury | — | **landed 2026-09-06** — split by what it needs: `scripts/check-image-sources.ts` runs in `bun run check` with no Docker and proves the source contract (every COPY source exists, is inside the npm `files` allowlist, and every local module reachable from a copied `.ts` is itself copied — verified to reproduce the 0.17.0 miss by deleting the `sanitize-text.ts` COPY); `smoke:image` gained the artifact half from `agent-image.yml` — toolchains, the pi binary, the version label, and `bun build` resolving `container-entry.ts` and `mrctl.ts` inside the image |
+| R0.3 | **Mercury publishes its own image.** A job in `release.yml`, after `publish-npm`, that installs the published tarball, builds, verifies (R0.2) and pushes `:<version>` + `:latest` with the R0.1 labels. Needs `packages: write`, which no job has today. **G-007 is decided: publish yes, visibility private for now** (2026-09-07), so this tidies the internal path; the third-party install path stays closed until visibility is revisited. Makes `agent-image.yml`'s *version-linking* half redundant; its nightly updater, idle check, snapshot, rollback and stagger stay where they are. **Move that workflow rather than rewriting it** — it already builds from the published tarball, which is the shape wanted here — and carry three traps across with it, all read out of it on 2026-09-06: (i) it derives the image name from `GITHUB_REPOSITORY`, which under this repo yields a different path than the fleet's, so set the name explicitly instead of inheriting it; (ii) a GHCR package takes the repo's visibility on first push, so a *public* answer to G-007 needs the package flipped by hand after the first run — it cannot be expressed in the YAML; (iii) the job runs **after** `publish-npm`, so a failed image push leaves npm ahead of the image, which is the 0.17.0 ordering inverted — keep boxes following the image (R0.4/R0.5) and make the job required so the gap is loud rather than latent | mercury-publishes-image | R0.1, R0.2 | **landed 2026-09-06 (Mercury side)** — `release.yml` gained a `publish-image` job with `packages: write`: builds from the published tarball, verifies with `smoke:image`, pushes `:<version>` and (stable only) `:latest`, image name set explicitly so it is not derived from `GITHUB_REPOSITORY`. Inert until the next `v*` tag. **One thing it cannot do itself**: retire `agent-image.yml` in tagula-agents — the owner's call. The package stays private (G-007), which is what it inherits by default, so no visibility step is pending |
+| R0.4 | **A floating tag stops meaning "frozen at first pull".** `ensureImage()` returns the moment `docker image inspect` succeeds, so the default `:latest` is never refreshed and a host upgraded by npm keeps yesterday's container silently — the trap the owner hit on 2026-09-05. Either pin the default to `:${pkg.version}` (safe **only** after R0.3, or every fresh install fails on a tag nobody published) or re-pull a floating tag on a version change. Either way boot logs the resolved image ref, digest and version label so drift is visible without asking. Filed as `docs/bugs/ensure-image-never-refreshes-a-floating-tag.md`; take `docs/bugs/health-reports-stale-env-version.md` with it — `/health` reports `MERCURY_VERSION` from the environment and never the installed `package.json`, so the host half of "what is actually running here" lies for the same reason the image half does, and fixing one without the other leaves the console's version badge still wrong | image-refresh-and-visibility | R0.3 | backlog |
 | R0.5 | **`mercury upgrade` owns both halves.** `upgradeAction` contains no Docker call at all: it stops the service, npm-installs and restarts, leaving the image behind. It should pull the matching image first and refuse when that tag does not exist — image first, host second, the rule the fleet updater already follows and the one 0.17.0 broke | upgrade-pulls-image | R0.1 | backlog |
 
 ### Milestone R1: Preflight
@@ -45,7 +45,7 @@
 
 | ID | Story | Slug | Depends on | Status |
 |----|-------|------|------------|--------|
-| R1.1 | `mercury preflight [--json] [--space <id>]`: one command that runs, on the production launch shape and the pulled image, (a) the bwrap probe and the runsc host-uds probe (folded from `probeBwrapSandbox` / `probeRunscHostUds`, one implementation, boot calls the same function); (b) an `mrctl whoami` round trip from inside a container; (c) the **host-vs-image contract** — the image carries every file the host version's `container/Dockerfile` `COPY` list names, checked by a manifest baked at build time, and the image's recorded mercury version matches the host's; (d) the model chain's first leg resolves a credential *the way the runtime resolves it* (the `modelProvider` default vs `models.json` gateway case); (e) host deps — `pi` on `PATH` when any host-side pi spawn is configured, timezone not UTC-by-accident when any active task has `timezone:null`, swap present on ≤4 GB; (f) an extension load report with the reason for every skip (the silent `gws` case). Exit non-zero on any *blocked* verdict, zero with warnings otherwise; JSON report with per-check verdict, evidence and remedy. Runs in shadow mode too | preflight | — | backlog — **first** |
+| R1.1 | `mercury preflight [--json] [--space <id>]`: one command that runs, on the production launch shape and the pulled image, (a) the bwrap probe and the runsc host-uds probe (folded from `probeBwrapSandbox` / `probeRunscHostUds`, one implementation, boot calls the same function); (b) an `mrctl whoami` round trip from inside a container; (c) the **host-vs-image contract** — the image carries every file the host version's `container/Dockerfile` `COPY` list names, checked by a manifest baked at build time, and the image's recorded mercury version matches the host's; (d) the model chain's first leg resolves a credential *the way the runtime resolves it* (the `modelProvider` default vs `models.json` gateway case); (e) host deps — `pi` on `PATH` when any host-side pi spawn is configured, timezone not UTC-by-accident when any active task has `timezone:null`, swap present on ≤4 GB; (f) an extension load report with the reason for every skip (the silent `gws` case). Exit non-zero on any *blocked* verdict, zero with warnings otherwise; JSON report with per-check verdict, evidence and remedy. Runs in shadow mode too | preflight | — | in-progress — **first** |
 | R1.2 | `mercury doctor` calls `loadConfig` and delegates its environment checks to R1.1 so there is one implementation; boot logs the same report once; a *blocked* verdict at boot refuses spawns with the diagnosis (already the case for the two probes — generalised) | doctor-delegates-to-preflight | R1.1 | backlog |
 
 **Checkpoint:** on the tagula box (with the owner's approval and in a cron
@@ -123,7 +123,7 @@ manual check in `pending-verification.md` is replaced by the reports.
 ```
 R0.1 ─┬─ R1.1(c)
       ├─ R0.5
-      └─ R0.3 ◄─ G-007 (decision) ─ R0.4
+      └─ R0.3 ─ R0.4          (G-007: publish yes, private for now)
 R0.2 ─── R0.3
 R1.1 ─┬─ R1.2
       ├─ R2.1 ─ R2.2
@@ -135,7 +135,7 @@ rehearsal-bench M2.2 (function half) ─► R3.2
 ```
 
 R0.1 is the true first story: it is small, depends on nothing, and R1.1(c)
-cannot be built without it. R0.3 waits on a decision, not on code.
+cannot be built without it. R0.3 no longer waits on anything but R0.1 and R0.2.
 R1.1 otherwise first, alone. R2 and R4 can run beside R3.1 in separate worktrees.
 R3.2 is the join with the bench. R5 last.
 

package/docs/live-testing.md

@@ -243,6 +243,22 @@ restarting, applying, deleting — whoever runs them, agent or owner.
 
 ## 7. Until the bench exists — what to do today
 
+- **`mercury preflight` is today's gate.** One command, run from
+  `~/whatsapp-bot`, that proves this box can run a turn: both boot probes on
+  demand, an `mrctl` round trip in a container on the production launch shape,
+  the host-vs-image contract, the first model leg's credential, host deps and
+  the extension load report. Exit 1 on any blocker, 0 with warnings. It makes
+  no model call and costs no tokens, writes nothing but its report, and never
+  sends to a person — so it is safe on the live box at any hour. Run it after
+  every deploy, before declaring one done, and read the JSON report rather
+  than the terminal. The check-by-check table — what each id proves and
+  which verdict class it can return — is in `docs/container-lifecycle.md`
+  § "`mercury preflight`". It needs no configuration of its own: since
+  2026-09-06 the round trip falls back to header identity when no
+  `MERCURY_CALLER_TOKEN_KEY` is set, and names the mode it used in the
+  evidence (`callerAuth`) — a `headers` pass proves transport, `API_SECRET`
+  and identity but not the caller-token leg, so set the key when you want
+  that leg covered too.
 - **Send-free, admin-only, DM-only:** `mercury chat -s <space>` /
   `POST /chat` runs the real pipeline and returns the reply as JSON; it never
   sends. It seeds the caller as admin (`routes/chat.ts:241`) and forces
@@ -327,6 +343,12 @@ The doctrine still holds, whoever implements it:
    connection open`; once a day, `SELECT MAX(created_at) FROM token_usage`
    — a bot that has not billed a run in a day is a bot nobody is talking
    to or a bot that is down, and only a person can tell which.
+6. **The evidence has a file.** `mercury preflight` writes
+   `<dataDir>/preflight/<timestamp>.json` and a `latest.json` beside it. That
+   file, not the terminal scrollback, is what a deploy attaches — a gate whose
+   evidence was not persisted did not pass. It answers "can this box run a
+   turn", never "is the customer's scenario still working": that second
+   question is the functional harness's, and it is still open.
 
 ## 9. Known gaps (kept honest)
 

package/docs/pending-verification.md

@@ -9,6 +9,89 @@ once every line under it is ticked.
 
 ---
 
+## history window cap 2026-09-03 — deploy-gated re-measure
+
+`context.history_max_chars` (default 2,000) clips older messages in the
+`context`-mode window before they reach the container. The projection against
+the live corpus says football's window drops 30.8% on average and 38% at the
+tail; the point of these lines is that the *continuity* did not pay for it.
+The cap itself, its config keys and the dashboard row are host-side — a
+restart deploys them. The 400 KB backstop reader that came with the same
+commit is **not**: `3884506` also edits `src/agent/container-entry.ts`
+(`history_budget_dropped_turns`), which `container/Dockerfile` bakes into the
+agent image, so that half needs a base rebuild
+(`docs/debug/major/2026-09-03-history-window-dominates-the-run-prefix.md`).
+Corrected on top of `dev` @ `7b7bc5f` — S1 of
+`docs/notes/2026-09-06-audit-fix-plan.md`; S4 ticks against this text.
+
+- [ ] After the restart, `task_runs.prompt_prefix_tokens` for `football-friends`
+      over a full day is below the 2026-09-03 baseline (21 runs, avg 33,343,
+      max 53,273). Compare the same query, not a trace.
+- [ ] `mercury service logs` carries `History window: older messages clipped`
+      with a non-zero `savedChars` — the operator's half of the reader. If it
+      never appears, the cap is not reaching the call site.
+      *Not yet seen, and not yet expected: the line fires only when a history
+      row exceeds the per-message cap (2,000 chars). The first run on the new
+      image (task 436, 2026-09-06 13:33 IDT, `mercury-agent-ext:a5a60d5b20c9`)
+      had only short scan posts in its window — `prompt_prefix_tokens` 27,510
+      against the 33,343 baseline average. Re-check after the next 09:00
+      article is inside the window.*
+- [ ] The dashboard's Context panel for `football-friends` shows a
+      `context.history_max_chars` row with the effective value, and setting it
+      there changes the next run's window (the key is per-space; a row the
+      runtime ignored would be the same invisible limit this fix removes).
+- [ ] A run whose window contains a clipped post shows the
+      `[truncated: N of M characters omitted from this older message]` line
+      inside `<history>` in that run's trace, and **not** inside
+      `<reply_anchor>`.
+- [ ] Continuity did not regress: ask the bot in the football group about
+      something it published the *previous* evening (not the newest turn) and
+      confirm it still knows what it posted. This is the check the bug doc
+      warned about — shrinking the window blind trades a cost problem for a
+      memory problem.
+- [ ] A swipe-reply to a long bot post still quotes the post in full; the
+      anchor is never clipped.
+- [x] The derived image carries the backstop reader:
+      `docker run --rm --entrypoint grep mercury-agent-ext:<hash> -c
+      history_budget_dropped_turns /app/src/agent/container-entry.ts` prints
+      `1`. Grep the image, never the repo — a restart alone leaves this at `0`.
+      *Verified 2026-09-06 13:10 IDT (S4): `dev` `631c3b5` synced, base rebuilt
+      13:00–13:05, derived image `mercury-agent-ext:a5a60d5b20c9` built by the
+      service at 13:10; the grep printed `1` inside it (and `2` for
+      `shouldOverridePiSystemPrompt`, `2` for `EPISODE_MIN_STEM_CHARS`).*
+
+## club markers 2026-09-03 (D-023) — repo adopts the owner's chat edit; deploy-gated
+
+The owner changed the seven club markers and added Maccabi Tel Aviv to the
+standing coverage from the football chat on 2026-09-03 (12:35–12:55 IDT); the
+bot wrote the live `AGENTS.md` and `MEMORY.md` itself, so **nothing changes on
+the box at deploy** — the deploy only stops `apply` from reverting it.
+
+- [x] After the merge is deployed: `space-profile check` against `dev` reports
+      **no** `AGENTS.md` drift. The only expected line is
+      `feed-watch.max_per_hour` (live `3`, set from the dashboard 2026-09-03
+      01:19 IDT; profile `1`) — the owner's call, not this change's.
+      *Verified 2026-09-03 14:50 IDT: `dev` merged locally as `6aff14f`, synced
+      to the box; the sync's own check printed exactly one difference, the
+      `max_per_hour` line. Base image rebuilt (the deploy also carried
+      `e8b50e4`/`b9b5c94`, which touch baked files), derived image
+      `mercury-agent-ext:eac63950bd82` verified by grep at 14:55.*
+      *Post-`0e0a4e0` check, 2026-09-06 12:59 IDT (S4, `dev` `631c3b5`): the
+      sync's check printed exactly the two drifts the women's-football fix
+      introduced (`AGENTS.md` coverage line, `feed-watch.exclude` five terms)
+      and nothing else — `max_per_hour` no longer drifts since the profile
+      adopted `3` (D-024). `space-profile apply` at 13:10 wrote both; check
+      after apply: clean. Seed addendum (`52eaf67`) copied by hand into the
+      live `distill.md`; `diff` against the repo seed is empty.*
+- [ ] The next scan post that names Barcelona or Beitar opens with the pair
+      (❤️💙 / 💛🖤) as one marker, and the harness (`bun run check` offline
+      lint) reports no `emoji-allowlist` on it. First live post under the new
+      set: message #4228, 2026-09-03 14:04 IDT, 👹 for United — already clean.
+- [ ] A Maccabi Tel Aviv item in a scan opens with 💛💙. None has posted yet
+      (the club's last item, message #4226 at 13:43 IDT, was a Real Madrid one
+      that posted with no marker at all — a separate, pre-existing miss).
+
+
 ## Verification pass, 2026-08-31 — what the box could answer on its own
 
 Everything below was read from the live box (DB, journal, traces, images,
@@ -820,3 +903,98 @@ Host-side only: deploy = service restart, **no image rebuild** (`container-runne
 Host-side only: deploy = service restart, **no image rebuild** (`handler.ts` and `debounce.ts` are not baked).
 
 - [ ] MANUAL-VERIFY(2026-09-03): **A reply lands in the chat it was asked in.** On the VPS (`tagula-assistant`, space `tomer-ohana` has three linked groups), restart the service, then as one caller address the bot in group A with something slow, and while it is running address it in group B. Expect one reply in each group, each answering that group's own message. In `journalctl --user -u mercury.service`, the `Debounce: message queued behind an in-flight flush` line must now carry the thread in `key=` (`space:caller:thread`), and each `WhatsApp outbound chatJid=` must match the group its question came from.
+
+## credential-alert-misses-owner-dm-linked-to-named-space (2026-09-03)
+
+Host-side only: deploy = service restart, **no image rebuild** (`src/core/direct-send.ts` is not baked).
+
+- [x] MANUAL-VERIFY(2026-09-03): **A direct send to the owner's JID lands in the owner's DM.** Checked 2026-09-03 15:09 IDT on `dev` `0e0a4e0` (mirror reset 15:08, process started 15:08:41): `POST /api/send` with the bearer secret **plus** `X-Mercury-Caller: whatsapp:<owner-jid>` and `X-Mercury-Space: main` (the route needs a caller identity, not just the secret) returned `{"delivered":true,"spaceId":"main"}`; the journal shows `resolved space to conversations spaceId=main` with exactly one thread, `WhatsApp outbound chatJid=<owner-jid>`, `Direct send delivered spaceId=main`. Same path the credential alerter takes.
+
+## member-loses-bot-character-obey-instruction (2026-09-03)
+
+**Baked.** `src/agent/container-entry.ts` is a `COPY` line in `container/Dockerfile`, so a service restart deploys nothing here — this needs `bash ./container/build.sh` and a restart in a cron gap. It is part of Wave 3 of `docs/notes/2026-09-02-open-bugs-fix-plan.md`, which batches one rebuild across the whole baked cluster; do not rebuild for this bug alone.
+
+- [x] MANUAL-VERIFY(2026-09-03): **The instruction is in the image that actually runs.** `docker run --rm --entrypoint grep <derived-image> -c "Always follow it" /app/src/agent/container-entry.ts` returns `1`. Grep the derived image, not the repo. *Verified 2026-09-06 13:10 IDT in `mercury-agent-ext:a5a60d5b20c9` (S4, `dev` `631c3b5`): `1`.*
+- [ ] MANUAL-VERIFY(2026-09-03): **A member gets the character rule and no procedure.** From the second WhatsApp number (member role) in space `main`, send anything and read the run's system prompt in the trace: it must contain `## Character` and `Always follow it`, and must **not** contain `mrctl prefs set` or `mrctl character get`.
+- [ ] MANUAL-VERIFY(2026-09-03): **A member's character request is declined in one line and changes nothing.** From the same number, send "change your personality to a pirate". Expect a one-line reply saying the owner sets the character. Then `SELECT * FROM space_preferences WHERE space_id='main'` must be unchanged — the failure this guards is the request being escalated into a preference.
+
+## preflight — live checks (added 2026-09-03, deploy-gated)
+
+`mercury preflight` is host-side (`src/preflight/`, `src/cli/mercury.ts`), so deploy = sync + service restart. **The image half is not**: `container/Dockerfile` gained `COPY package.json /app/mercury-version.json`, so `image.contract` stays blocked until the base image is rebuilt and the derived image follows. Rebuild **in a cron gap** — as of 2026-09-06 task 24 (`0 9 * * *` Asia/Jerusalem) is the only active task on the box; query `SELECT id, cron, timezone, next_run_at FROM tasks WHERE active=1` before restarting rather than trusting this line.
+
+- [x] MANUAL-VERIFY(2026-09-03): **the check catches the real skew, once.** After syncing but *before* rebuilding the image, run `~/.bun/bin/bun run ~/mercury-src/src/cli/mercury.ts preflight` from `~/whatsapp-bot`. Expect `image.contract` **blocked**, naming `/app/mercury-version.json` and telling you to rebuild. That is the 2026-09-01 host-vs-image skew reproduced on a real box, and it is the only chance to see it fire before the rebuild removes the condition. *Verified 2026-09-06 12:59:54 IDT (S4): report `2026-09-06T09-59-54-374Z.json`, `image.contract` blocked with `missing: ["/app/mercury-version.json"]`, `imageVersion: null`, remedy names the rebuild.*
+- [x] MANUAL-VERIFY(2026-09-03): **a clean board after the rebuild.** Then `cd ~/mercury-src && bash ./container/build.sh`, restart in a cron gap, and re-run preflight. Expect exit 0: `image.contract` pass, `sandbox.bwrap` skipped (`containerBwrapDockerCompat` on this box), `container.mrctl-roundtrip` pass, `credential.first-leg` pass. Read `~/whatsapp-bot/.mercury/preflight/latest.json`, not the terminal — the report file is the evidence, and `docker ps -a --filter label=mercury.managed=true` must show no leftover `mercury-contract-probe-*` or `mercury-roundtrip-probe-*` container. *Run 2026-09-06 13:10:26 IDT after the rebuild (report `2026-09-06T10-10-26-466Z.json`): 8 pass · 0 warn · **1 blocked** · 2 skipped, exit 1. `image.contract` **pass**, `sandbox.bwrap` skipped, `credential.first-leg` pass, no leftover probe container — but `container.mrctl-roundtrip` blocked with `401 Invalid or expired caller token`: this box has no `MERCURY_CALLER_TOKEN_KEY`, so the preflight process signs with its own per-process random key and the service verifies with another. Not a wrong `.env` and not fixable by re-running — filed as `docs/bugs/preflight-roundtrip-cannot-pass-without-configured-caller-token-key.md`. Left unticked until that bug is fixed or the owner sets the key.* **Ticked 2026-09-06 18:20 IDT:** the owner set `MERCURY_CALLER_TOKEN_KEY` in the box's `.env` (one line, value never displayed) and restarted at 18:19:58; `latest.json` at 18:20:34 reads exit 0, **9 pass · 0 warn · 0 blocked · 2 skipped**, `container.mrctl-roundtrip` pass with `answeredCallerId: "preflight"`, `answeredSpaceId: "main"`, `role: "member"`, image `a5a60d5b20c9`; `docker ps -a --filter label=mercury.managed=true` empty. The bug stays open for boxes that never set the key.*
+
+The three below close audit findings 1, 2 and 3 (2026-09-06). Each is a one-liner on the box and each fails on the *live* shape the unit tests can only fake.
+
+- [x] MANUAL-VERIFY(2026-09-06): **`--json` is parseable on a box that loads extensions.** `cd ~/whatsapp-bot && ~/.bun/bin/bun run ~/mercury-src/src/cli/mercury.ts preflight --json | python3 -m json.tool > /dev/null && echo PARSED`. This box loads real extensions and the fixture only loads one, so it is the honest version of the test. A `Loaded extension` line anywhere in stdout means the `configureLogger({ level: "warn" })` did not take. *Verified 2026-09-06 13:11 IDT: stdout 4,945 bytes, stderr 0 bytes, no non-JSON line, `JSON.parse` in bun returns the ten top-level keys (`schema … reportPath`). `python3 -m json.tool` exits 0 on the same output; the one "NOT PARSEABLE" seen first was `set -o pipefail` surfacing preflight's own exit 1 (the round-trip blocker), not a parse failure.*
+- [x] MANUAL-VERIFY(2026-09-06): **the round trip leaves no member row.** Before the run: `SELECT COUNT(*) FROM space_roles WHERE platform_user_id='preflight'` → whatever it is now (it may be non-zero from runs before the fix — clean those up with `DELETE FROM space_roles WHERE platform_user_id='preflight'` and say so). Run preflight, then the same query → **0**. Also `mrctl roles list` and the dashboard members table must not show `preflight`. *2026-09-06: count was 0 before and 0 after both runs — but the probe was refused at the token check (401, see the round-trip line) before any role resolution ran, so this proves nothing yet; re-check once the round trip actually completes.* **Re-checked 2026-09-06 18:20 IDT after the key was set:** the round trip completed (`answeredCallerId: preflight`, `role: member`) and `SELECT COUNT(*) FROM space_roles WHERE platform_user_id='preflight'` → **0**.*
+- [x] MANUAL-VERIFY(2026-09-06): **the credential source names the passthrough mode.** In `latest.json`, `credential.first-leg` evidence carries `envPassthrough` matching this box's `agent.env_passthrough` (`claimed` here), and — since the leg is Anthropic OAuth — `source` reads `env:MERCURY_ANTHROPIC_OAUTH_TOKEN (parsed, not refreshed)`. The qualifier is the point: preflight does not spend a refresh, so a pass here is "a usable credential is present", not "it works". *Verified 2026-09-06 13:10 IDT, with one correction to this line's premise: evidence `{"envPassthrough":"claimed","credentialEnvVar":"ANTHROPIC_OAUTH_TOKEN","source":"auth.json:oauth","authPath":"…/.mercury/global/auth.json","leg":"anthropic:claude-opus-5"}`. `envPassthrough` matches the box; `source` reads `auth.json:oauth` rather than the `env:…` form because on this box the token lives in `auth.json`, not in the environment — the check named the real source, the expectation here assumed the wrong one.*
+
+## env_passthrough default flipped to `claimed` 2026-09-06
+
+Host-side only (`src/config.ts`, `src/main.ts`) — a restart deploys it, no
+image rebuild. This box already pins `agent.env_passthrough: claimed` in
+`~/whatsapp-bot/mercury.yaml`, so the flip is a **no-op here**; that is exactly
+why the default itself has to be proven rather than assumed.
+
+- [ ] MANUAL-VERIFY(2026-09-06): **the default is `claimed` with no config saying so.** Comment out the `env_passthrough: claimed` line in `~/whatsapp-bot/mercury.yaml`, confirm by name only that `MERCURY_CONTAINER_ENV_PASSTHROUGH` is absent from `~/whatsapp-bot/.env` (`grep -c` — never print the file), restart **in a cron gap** (`SELECT id, cron, timezone, next_run_at FROM tasks WHERE active=1`), then read `mercury service logs` for the startup line. Expect `Container env passthrough: claimed` with a `withheld=` field naming the unscoped `MERCURY_*` vars (names only — a value in that log is itself a bug). Restore the yaml line and restart, again in a gap.
+- [ ] MANUAL-VERIFY(2026-09-06): **the escape hatch still logs the old warning.** With `agent.env_passthrough: all` set explicitly, the startup line reads ``Container env passthrough: explicit `all` override`` with a `vars=` field. This is the only branch a deployment relying on blind passthrough will ever see, so it has to name the vars it is carrying.
+
+## override_pi_system_prompt parsed strictly 2026-09-06
+
+Host-side only (`src/config.ts`, `src/agent/container-runner.ts`) — a restart
+deploys it, no image rebuild. This box sets `override_pi_system_prompt: true` in
+`~/whatsapp-bot/mercury.yaml` and no env var, so the change is a **no-op here**:
+the point of the line below is that it stayed one.
+
+- [ ] MANUAL-VERIFY(2026-09-06): **the container still gets `true`.** After the restart, during a live run: `docker inspect $(docker ps -q --filter label=mercury.managed=true | head -1) --format '{{range .Config.Env}}{{println .}}{{end}}' | grep OVERRIDE` prints `OVERRIDE_PI_SYSTEM_PROMPT=true`. Read it off the running container, not off `mercury.yaml` — the value the container was handed is the only thing that decides which prompt mode pi runs in.
+- [ ] MANUAL-VERIFY(2026-09-06): **a typo now stops startup instead of taking the bot down quietly.** Add `MERCURY_OVERRIDE_PI_SYSTEM_PROMPT=no` to `~/whatsapp-bot/.env`, restart **in a cron gap** (`SELECT id, cron, timezone, next_run_at FROM tasks WHERE active=1`), and expect the service to fail to start: `mercury service logs` carries `Startup failed` with an error naming `override_pi_system_prompt` (`main.ts:715` turns a `loadConfig` throw into exit 1) — not a bot that boots and answers every message with a 400. Remove the line and restart, again in a gap.
+
+## swipe-reply to media keeps its quote block 2026-09-06
+
+Host-side only (`src/core/reply-context.ts`, `src/core/runtime.ts`) — a restart
+deploys it, no image rebuild. The de-duplication that drops a swipe-reply's
+`<reply_to>` block now makes an exception for a quote whose opening tag carries
+`media_type=`, because that attribute is the only place in the whole prompt
+where the quoted message's media is named. The tests cover the branch; what
+they cannot cover is that a real WhatsApp voice-note quote actually produces the
+attribute in the stanza.
+
+- [ ] MANUAL-VERIFY(2026-09-06): **a swipe-reply to a voice note still names the audio.** In the private `main` space (never the football group), send a voice note, then swipe-reply to it with `מה אמרתי בהודעה הקולית?`. The newest `messages` row with `role='user'` contains `media_type="voice"` and `[voice note]`, and the bot's answer addresses the recording rather than an empty quote.
+- [ ] MANUAL-VERIFY(2026-09-06): **a text quote is still de-duplicated.** In the same space, swipe-reply to one of the bot's own text messages. The stored user row is the question alone — no `<reply_to` — so the exception did not widen into "never strip".
+
+## preflight round trip without a caller-token key 2026-09-06
+
+Host-side only (`src/preflight/checks/roundtrip.ts`) — a sync + restart deploys
+it, no image rebuild. **This box now has `MERCURY_CALLER_TOKEN_KEY` set** (the
+owner added it at 18:19 IDT as the workaround), so the default path the fix
+exists for is *not* the path this box takes by default. The first line below is
+therefore the whole point: it has to be checked with the key temporarily out of
+the way, or it proves nothing.
+
+- [ ] MANUAL-VERIFY(2026-09-06): **the round trip passes with no caller-token key.** From `~/whatsapp-bot`, run preflight with the key blanked for that one process only — `MERCURY_CALLER_TOKEN_KEY= ~/.bun/bin/bun run ~/mercury-src/src/cli/mercury.ts preflight` (an env var beats `mercury.yaml`, and an empty value is read as unconfigured). Never edit the `.env`. In the report, `container.mrctl-roundtrip` must be **pass** with evidence `callerAuth: "headers"` and `answeredCallerId: "preflight"`, and its title must say the token leg was not exercised. Read `~/whatsapp-bot/.mercury/preflight/latest.json`, not the terminal.
+- [ ] MANUAL-VERIFY(2026-09-06): **the configured key is still used.** Run preflight normally (no env override). Same check must be **pass** with evidence `callerAuth: "token"` — the fallback must not have swallowed the real path on a box that has a key.
+- [ ] MANUAL-VERIFY(2026-09-06): **the header round trip still leaves no member row.** After the first run above, `SELECT COUNT(*) FROM space_roles WHERE platform_user_id='preflight'` → **0**, and `mrctl roles list` must not show `preflight`. The ephemeral-caller rule is keyed on the caller id, not on how it was asserted, so this should hold in both modes — which is exactly why it is worth checking once on the mode that never ran on a box before.
+
+## image-self-describing (R0.1, 2026-09-06)
+
+Image-side: the Dockerfile changed, so nothing here is live until the image is
+rebuilt. The checks below are the only proof the stamping works — the unit
+tests cover the parser, not the build.
+
+- [x] VERIFIED(2026-09-07, dev box, Docker 29.5.3 linux/amd64): built from the tip of `dev` with `--build-arg MERCURY_VERSION=0.19.0` under a scratch tag; `com.mercury.version` and `org.opencontainers.image.version` both read `0.19.0`. Original check: **the build stamps a real version.** On a machine with Docker and this checkout, `bash container/build.sh`, then `docker image inspect mercury-agent:$(bun -e 'console.log(require("./package.json").version)') -f '{{index .Config.Labels "com.mercury.version"}}'` — expect the package.json version, never `unknown`. `unknown` means the `--build-arg` did not reach the `ARG`, and the whole R0.4/R0.5 version check would be reading a constant.
+- [x] VERIFIED(2026-09-07): `/app/image-manifest.json` present, version `0.19.0`, 16 `copySources` including `src/agent/container-entry.ts` and `container/Dockerfile`, zero `--from=` paths; the copied Dockerfile's sha256 matches the repo's LF-normalised file. `bun run smoke:image` against the same image passed all four checks, including the two R0.2 added (version label; `container-entry.ts` and `mrctl.ts` both `bun build` inside the image). Original check: **the manifest is inside the image and describes it.** `docker run --rm --entrypoint cat mercury-agent:latest /app/image-manifest.json` — expect the same version, a `dockerfileSha256`, and `copySources` listing `src/agent/container-entry.ts` and `container/Dockerfile`. Nothing from a `COPY --from=` stage (`/usr/local/bin/bun`, `/usr/local/go`) may appear.
+- [ ] MANUAL-VERIFY(2026-09-06): **the derived image inherits the label.** After a space with extensions has built `mercury-agent-ext-*`, `docker image inspect <derived> -f '{{index .Config.Labels "com.mercury.version"}}'` must report the same version as the base. Verified once by hand on the tagula box 2026-09-05 for the old labels; this re-checks it for the ones the build now sets, because R0.4's host-side check reads the version through the derived image, not the base.
+- [ ] MANUAL-VERIFY(2026-09-06): **both tags point at one image.** `docker image inspect mercury-agent:latest -f '{{.Id}}'` and the same for `:<version>` — identical ids. If they differ, `build.sh` built twice and `:latest` is not the version it claims.
+
+## mercury-publishes-image (R0.3, 2026-09-06)
+
+CI-side: `release.yml`'s new `publish-image` job does not run until the next
+`v*` tag, so none of this is proven yet. The first release after this is the
+test.
+
+- [ ] MANUAL-VERIFY(2026-09-06): **the job runs and pushes.** On the next `v*` tag, watch the `publish-image` job. It runs after `publish-npm`, so if it fails npm is ahead of GHCR — safe (boxes follow the image) but the release is not finished. Expect `ghcr.io/avishai-tsabari/mercury-agent:<version>` in the repo's Packages.
+- [ ] MANUAL-VERIFY(2026-09-06): **a prerelease does not move `:latest`.** If the next tag is a prerelease, confirm the job log says `:latest untouched` and that `:latest` still resolves to the previous stable id.
+- [ ] MANUAL-VERIFY(2026-09-06): **the package landed private, and the fleet token can read it.** G-007 keeps visibility private. After the first push, GitHub → Packages → `mercury-agent` should show Private (it inherits the repo's visibility; nothing here changes it). Then from a box, or any shell with the fleet's `REGISTRY_PULL_TOKEN`: `docker login ghcr.io -u x-access-token --password-stdin` and `docker pull ghcr.io/avishai-tsabari/mercury-agent:<version>` — must succeed, since that token is what `box-upgrade.ts` will use once it points here.
+- [ ] MANUAL-VERIFY(2026-09-06): **retire the fleet's duplicate.** Once a Mercury-published image exists for a version, `agent-image.yml` in tagula-agents is building the same thing into a different namespace. Decide deliberately: point `box-upgrade.ts` at the Mercury image and delete that workflow, or keep the fleet image and accept two publishers. Do not leave both running unexamined — two images with the same version label and different contents is worse than either.

package/docs/permissions.md

@@ -57,7 +57,7 @@ Custom roles can be created by assigning permissions to any role name.
 | `spaces.rename` | Rename a space and link/unlink conversations |
 | `spaces.delete` | Delete current space and all related DB data |
 | `model.list` | List the configured model chain (`mrctl model list`, chat `/model list`) |
-| `model.switch` | Switch the active model for the space (`mrctl model switch`, chat `/model switch`) — takes effect on the next agent run |
+| `model.switch` | Pin the space to one model leg (`mrctl model switch`, chat `/model switch`) or clear that pin (`mrctl model reset`, chat `/model reset`) — takes effect on the next agent run. A pinned space has no fallback; reset is refused while the space has an active scheduled task |
 | `media.receive` | Incoming attachments are saved to `inbox/` and shown to the agent |
 | `media.send` | Outbox files produced on this caller's turn are delivered back to the chat |
 

package/docs/profile-guide.md

@@ -203,10 +203,15 @@ win by being specific:
 - *Presenting tool results* — "simple lists, never commands/JSON". A
   reporter who must not answer in lists: say so; a profile whose users *are*
   developers: say the opposite.
-- *Character → "set a preference"* — a standing instruction from a member
-  becomes "only an admin can set that", which in a friends' group reads as
-  refusing a joke. Say what the bot does with a standing request from a
-  member (relay, decline in one line, or treat as banter).
+- *Character → "set a preference"* — a standing instruction from an
+  admin becomes "only an admin can set that", which in a friends' group reads
+  as refusing a joke. A member never sees that procedure at all: from the
+  2026-09 image rebuild (`7d242e2`) the `## Character` heading and its "Always
+  follow it" / "only the bot owner can change it" sentences ship to every
+  caller, while the `mrctl` procedure under them stays gated on `prefs.set`, so
+  a member's request gets the one-line decline. Say what the bot does with a
+  standing request from a member (relay, decline in one line, or treat as
+  banter).
 - *"Be concise"*, *"Ask for clarification"* from the pi preamble and the
   default global `AGENTS.md` — a reporter that must give a full factual
   answer, or a bot that must not ask before acting, says so.
@@ -360,10 +365,25 @@ What that means for a profile:
    bot an explicit rule for when to update it. The three DM spaces on the
    live bot that have one use it; the football space, which needed it most,
    never had one.
-3. **Episodes need keywords that will recur.** An episode about "Abu Fani's
-   transfer" with `keywords: ["אבו פאני","hapoel","transfer"]` surfaces on
-   the next message containing one of those words; without keywords it never
-   surfaces. Prefer a notebook the bot reads by rule over relying on scoring.
+3. **Episodes need keywords that will recur, one word each.** An episode
+   about "Abu Fani's transfer" with `keywords: ["פאני","fani","hapoel",
+   "transfer"]` surfaces on the next message containing one of those words;
+   without keywords it never surfaces. The message is split on whitespace,
+   ASCII punctuation, the hyphen and the maqaf, so a keyword with a space, an
+   apostrophe or a dash — `"אבו פאני"`, `"מנצ'סטר"`, `"man-united"` — can
+   never match anything (a geresh or gershayim *inside* a word in the message
+   is dropped rather than split, so `לבית"ר` does reach the keyword `ביתר`;
+   the keyword itself is never rewritten). A Hebrew prefix on the word still
+   matches (`ליונייטד`, `וכשיונייטד`) as long as four letters remain once it
+   is stripped — five after a leading `מ`, which also opens whole words. So
+   list the bare word once — every extra keyword lowers the note's score —
+   and before choosing a short keyword, read it back with each of
+   `ו/ה/ב/ל/ש/כ` in front: if that spells a different everyday word, the
+   note will surface on that word too, so pick another keyword. Mem is the
+   one the host handles itself — it turned `שוער` (goalkeeper) into `משוער`
+   (projected) — and the extra letter it costs is deliberate: `מחיפה` no
+   longer reaches a note keyed `חיפה`, while `חיפה` and `בחיפה` still do.
+   Prefer a notebook the bot reads by rule over relying on scoring.
 4. **Do not let distillation stand in for a notebook.** On the live bot
    napkin distils every space daily and has written *zero* entity files for
    the football space — group banter does not meet its "lasting signal"

package/examples/extensions/archive/backends/local.ts

@@ -13,7 +13,6 @@
 
 import { randomBytes } from "node:crypto";
 import {
-  copyFileSync,
   existsSync,
   mkdirSync,
   readdirSync,
@@ -22,6 +21,7 @@ import {
   statSync,
   unlinkSync,
 } from "node:fs";
+import { copyFile } from "node:fs/promises";
 import { dirname, join } from "node:path";
 import { type ArchiveBackend, ArchiveConfigError } from "./types.js";
 
@@ -84,7 +84,9 @@ export class LocalArchiveBackend implements ArchiveBackend {
     // hash that claims to describe complete content.
     const tmp = `${dest}.${randomBytes(4).toString("hex")}.tmp`;
     try {
-      copyFileSync(srcPath, tmp);
+      // Awaited: blobs run to the 25 MB outbox cap and this backend is on the
+      // host delivery path — a sync copy stalls every other space.
+      await copyFile(srcPath, tmp);
       renameSync(tmp, dest);
     } catch (err) {
       // Leave nothing behind on failure; the queue will retry.
@@ -122,7 +124,8 @@ export class LocalArchiveBackend implements ArchiveBackend {
     // attached to a reply and sent to the customer as if it were whole.
     const tmp = `${destPath}.${randomBytes(4).toString("hex")}.tmp`;
     try {
-      copyFileSync(src, tmp);
+      // Awaited, same reason as `put`.
+      await copyFile(src, tmp);
       renameSync(tmp, destPath);
     } catch (err) {
       try {