mercury-agent 0.18.2 → 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/rehearsal-bench/decisions.md

@@ -205,17 +205,55 @@
   the owner and a second WhatsApp account, with the snapshot/restore
   procedure of §5. The bench does not try to make this list empty.
 - **Alternatives considered:** a Baileys stub; a second bot number in
-  shadow mode.
+  shadow mode; **a test bot** — a snapshot restored on another host
+  (M1.6), the candidate Mercury version installed, linked to WhatsApp with
+  its *own* number, and driven from the owner's phone (owner's question,
+  2026-09-06).
 - **Reasoning:** the memory `mercury-member-role-cannot-be-simulated` and
   the F5 debug doc both record the same wall: `isSelfJid` reads a live socket.
   D-003 moves the *decisions* out from behind that wall; the socket itself is
   not our code and is not worth stubbing. A private lab group with a second
   account is cheap and is what the football space already is until the real
   group is linked.
+
+  The test bot is **complementary, not a replacement**, and it is not safe
+  as described. It exercises what the shadow cannot — the socket list
+  above — but a snapshot linked to a different number breaks on identity:
+  every space is reached through `conversations.external_id`, the live
+  chat JID (`src/storage/db.ts`, `conversations`), so the copied groups
+  belong to a bot that is not a member of them and the copied `main` space
+  points at the owner's real number. Three consequences, each of which
+  the shadow avoids by having no adapter at all: (1) a copied scheduled
+  task whose space resolves to the owner's DM **sends from the test number
+  to the owner's real phone**, and one bound to a group the test bot has
+  been added to reaches the group; (2) the test bot cannot be added to the
+  real groups without reaching real people, so it needs its own groups,
+  whose JIDs differ, so the copied roles, tasks, config and workspace no
+  longer apply until the snapshot's space→chat links are remapped; (3) D-002
+  makes "adapter on" mean "live", so every refusal of D-005 (broker,
+  publish, billing, deliver) is off — a copied task with a broker action is
+  real. What a test bot cannot do at all: act *as* a specific existing
+  member (a non-admin quoting a bot message is the F5 shape), which
+  `shadow say --as <member>` replays from the copied `space_roles`. What it
+  does better: everything in §5, plus a candidate version on a real socket
+  before `promote` (D-013). Where it is redundant: a migration rehearsal
+  (apply → diff) needs no socket and is the shadow's own job (M1.4, M3.2).
 - **Revisit if:** the owner does not want to hold a second number — then the
   §5 list becomes the standing content of `pending-verification.md` and the
-  bench's coverage is everything else.
-- **Used by:** lab-space-procedure
+  bench's coverage is everything else. **Or** the owner wants the test bot —
+  then it is M4.2 and lands only with all three preconditions, each denying
+  on absence: a new opt-in mode value (never "`MERCURY_SHADOW` unset plus a
+  list" — absence is live, D-002) that keeps every D-005 refusal while
+  constructing the adapter; a **recipient allowlist** of literal chat JIDs
+  on the send side (none exists today — `direct-send.ts` resolves a
+  recipient, it does not restrict one), checked at the bridge so all
+  fifteen send sites of `docs/live-testing.md` §3 are behind it, empty
+  list = nothing leaves; and a `shadow snapshot --remap <live-jid>=<test-jid>`
+  that rewrites `conversations.external_id` (and `message_platform_ids`)
+  so the copied spaces point at the test groups, refusing any live JID left
+  unmapped. Tasks whose space maps to nothing are deactivated in the copy,
+  not left to fail silently.
+- **Used by:** lab-space-procedure; test-bot-instance (M4.2, if chosen)
 
 ## D-008: No injection route on the live instance in this goal
 - **Category:** scope

package/docs/goals/rehearsal-bench/roadmap.md

@@ -1,7 +1,7 @@
 # Roadmap: Rehearsal Bench
 
 **Goal**: [rehearsal-bench](goal.md)
-**Last updated**: 2026-09-03 (re-scope after the VPS cutover review, [note](../../notes/2026-09-03-release-gate-and-test-environment.md):
+**Last updated**: 2026-09-06 (M4.2 `test-bot-instance` added as an owner's-decision story after the "why not a test bot on a snapshot?" review — D-007 extended with the identity/egress/remap analysis; nothing else moved). Earlier: 2026-09-03 (re-scope after the VPS cutover review, [note](../../notes/2026-09-03-release-gate-and-test-environment.md):
 M1.3 gains the instance-label prerequisite and the fleet-box shape; M1.6
 `snapshot-across-hosts` added; M3.2 extended to tagula's space-sync path;
 M3.3 `sync-rehearse` **moved** to [`release-gate`](../release-gate/roadmap.md)
@@ -99,6 +99,7 @@ in `pending-verification.md` for that fix is replaced by the transcript.
 | ID | Story | Slug | Depends on | Status |
 |----|-------|------|------------|--------|
 | M4.1 | `lab` space: private group of bot + owner + second account; `mercury lab snapshot|restore` = `VACUUM INTO` + tar before, `messages`/`space_roles`/`token_usage` window delete + workspace restore after; `restore` proves itself by re-running `shadow diff` against the pre-snapshot and requiring an empty report | lab-space-procedure | M1.4 | backlog (needs a second WhatsApp number — owner's decision) |
+| M4.2 | **Test-bot instance** (added 2026-09-06, D-007 revisit): a snapshot restored on another host (M1.6) and linked to WhatsApp with its own number, driven from the owner's phone — the socket-only list of §5 on a candidate version, before `promote`. Complementary to the shadow, never a replacement (it cannot act *as* an existing member; a migration rehearsal needs no socket). Lands only with three guards, each denying on absence: a new opt-in mode that constructs the adapter but keeps every D-005 refusal (absence is still live, D-002); a send-side **recipient allowlist** of literal chat JIDs checked at the bridge behind all §3 send sites, empty = nothing leaves; `shadow snapshot --remap <live-jid>=<test-jid>` rewriting `conversations.external_id` + `message_platform_ids`, refusing an unmapped live JID and deactivating tasks whose space maps to nothing. Without the remap a copied task delivers from the test number to the owner's real DM | test-bot-instance | M1.6, M1.4 | backlog (needs a second bot number and a host — owner's decision) |
 
 **Checkpoint:** the §5 list of `docs/live-testing.md` is walked once in the
 lab space and every item is either ticked with the date or moved into M2 as
@@ -153,6 +154,7 @@ M1.1 ─ M1.5         │
 M2.1 ──────┬─ M2.2 ─┴─ M2.3 ─ M2.4
 M1.3 ──────┘   └────────────────────► release-gate R3 (smoke runner)
 M1.4 ─ M4.1
+M1.6 ─ M4.2 (owner's decision)
 release-gate R5 (sync-rehearse, ex-M3.3) ◄─ M3.1, M2.3
 ```
 

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

@@ -110,3 +110,89 @@
 - **Revisit if:** a second operator (not tagula) needs the same policy —
   then it is a Mercury feature, planned as one.
 - **Used by:** smoke-runner, release-gate-rules
+
+## G-007: Mercury publishes its own agent image; visibility stays private for now
+- **Category:** architecture / distribution
+- **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
+  by hand (`docs/runbooks/publish-checklist.md`, "manual — CI does not do
+  this"), is stale, and returned 401/403 unauthenticated on 2026-09-05.
+  Should Mercury publish its own image from `release.yml`, and public or
+  private?
+- **Evidence (2026-09-05):** `container/Dockerfile` has zero `LABEL` lines;
+  `container/build.sh:20` tags `:latest` only; `release.yml` has no
+  `packages: write`; `src/config.ts:59` defaults to
+  `ghcr.io/avishai-tsabari/mercury-agent:latest`;
+  `container-runner.ts:1131-1136` never refreshes a tag that exists locally;
+  `container-runner.ts:1104-1117` skips validation for exactly the
+  `/mercury-agent:` names that broke. A fresh outside install therefore
+  fails `ensureImage()` and must fall back to a ~2.8 GB local `mercury build`
+  the README's install steps never mention. The tagula box could not perform
+  that fallback: 2 vCPU, 3 GB RAM and 1.9 GB free before the 2026-09-05
+  cleanup.
+- **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. 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:** `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-03 (created from the VPS cutover review; story slugs are `/f-feature-planning` inputs)
+**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
@@ -11,6 +11,33 @@
 
 ## Milestones
 
+### Milestone R0: The agent image is a published, self-describing artifact
+
+> R1.1(c) asks the image what mercury version it is and which `COPY`
+> sources it carries. **Nothing puts either there today**, and nothing in
+> this repo publishes the image at all, so R1.1(c) has no artifact to read
+> and no milestone owned the gap. This is that milestone. It is small,
+> it depends on nothing, and R1.1(c) is blocked without R0.1.
+>
+> Established 2026-09-05 while releasing 0.18.1/0.18.2 (evidence in
+> [`decisions.md` G-007](decisions.md)):
+> `container/Dockerfile` has **zero** `LABEL` lines; `container/build.sh`
+> tags `:latest` only, never a version; `release.yml` has no image job and
+> no `packages: write` anywhere; the image every fleet box actually 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 by hand per
+> `docs/runbooks/publish-checklist.md` ("CI does not do this"), is stale,
+> and is **not anonymously pullable** (401/403 verified 2026-09-05).
+
+| 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 | — | **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
 > After this, a box that cannot run a container says so at boot and on
 > demand, with one diagnosis per blocker, and the nightly updater has
@@ -18,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
@@ -94,6 +121,10 @@ manual check in `pending-verification.md` is replaced by the reports.
 ## Dependency Graph
 
 ```
+R0.1 ─┬─ R1.1(c)
+      ├─ R0.5
+      └─ R0.3 ─ R0.4          (G-007: publish yes, private for now)
+R0.2 ─── R0.3
 R1.1 ─┬─ R1.2
       ├─ R2.1 ─ R2.2
       ├─ R4.1 ─ R5.2
@@ -103,7 +134,9 @@ R3.1 ─ R3.2 ─┬─ R3.3
 rehearsal-bench M2.2 (function half) ─► R3.2
 ```
 
-R1.1 first, alone. R2 and R4 can run beside R3.1 in separate worktrees.
+R0.1 is the true first story: it is small, depends on nothing, and R1.1(c)
+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.
 
 ## Cost note

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 |