@@ -211,6 +211,115 @@
       Repeat in a non-sudo channel and require the assistant to say the check needs host access
       rather than reporting a false negative from inside its container.
 
+## 0.5.3 live acceptance (2026-09-24, Xavier, candidate on beta `6bac50f`, image spec 1.5.1)
+
+Actors per the QA protocol — Apps (approved user) and Contact (admin), posting through their own
+Slack accounts; Tiberiu is never the actor. Fixtures are Xavier's `cg-qa-*` channels, whose engine
+is the gateway default (Codex). Codex was usage-limited throughout, so every turn below first failed
+on Codex and was answered by the Claude fallback — which is itself the path under test for L1.
+
+- [x] **L1 — failover keeps its tools (the 0.5.2 Composio defect, first production proof).** Apps in
+      `cg-qa-auto`: "quick sanity check before the release: which MCP servers do you have in this
+      turn? Just list their names. Then search this channel's memory for anything about fixtures
+      and tell me what you find." Evidence: `run_config` engine=codex, stderr `replay-safe codex
+      usage_limit failure in cg-qa-auto — falling back to claude`, session row
+      `1790205561.133739::claude-fallback` (claude); the reply named `gateway` and `composio-agent`,
+      correctly noted no `composio-user` (Apps has no personal token), and the card shows three
+      `gateway · search_channel_memory` calls. PASS. The reverse direction (Claude→Codex) was not
+      run: Codex unavailable.
+- [x] **L2 — a requested file is uploaded, not named.** Apps in `cg-qa-bash`: "please create a file
+      called qa-note.md containing exactly one line: `QA 0.5.3 file delivery check` — then send me
+      that file here in the thread." Evidence: `Write(qa-note.md)` then
+      `gateway · slack_upload_snippet(qa-note.md)`; a Slack file `qa-note.md` (markdown, 29 bytes =
+      the line + newline) in the thread; the reply is one line ("Here's `qa-note.md` — one line, as
+      requested."), content not pasted. PASS on Claude; Codex not run.
+- [x] **L3 — disk question outside `/sudo`.** Contact in `cg-qa-admin`: "are we running out of disk on
+      the gateway host? How much space do the containers and images take right now?" First run
+      FAILED on safety: correct free space and a correct "cannot measure containers from in here",
+      then it RECOMMENDED `podman system prune -a --volumes`. Fixed (`34a9730`, the routing row names
+      the forbidden prunes); re-run with "the gateway host feels like it's filling up. Are we
+      running out of disk, and what can we clean up to free space?": true free space, "~300G … outside
+      this container's view", no prune command, and it stopped at analysis and asked. PASS. The
+      `/sudo` half of that gate (a report with per-image counts from the host) was not run.
+- [x] **Streamed notices.** The L1–L3 fallback answers carried no "Codex hit its usage limit — using
+      Claude" line — the note lived only on `content`. Fixed (`b8909be`); verified by tests red
+      before / green after. Live re-check after the daemon runs the fix: open.
+- [x] **SSH, container half.** A real `ssh` client with a throwaway key, ProxyCommand
+      `podman exec -i -e CG_SSH_DIR=… <ctr> cg-sshd` into a container from the promoted 1.5.0 image
+      hardened like a channel's (`--cap-drop ALL` + DAC_OVERRIDE/CHOWN/FOWNER, no-new-privileges,
+      keep-id), files from the gateway's own `materializeContainerSshFiles`. Evidence: sshd
+      `Accepted publickey for agent … ED25519 SHA256:uOTrRj6…`, `agent` uid 1001, CapEff
+      0x…0b, no sudo, the channel host key generated by `cg-sshd`. PASS. Not covered here: the
+      host-sshd hop (blocked by `AllowUsers` until the installer is rerun as root) and the broker's
+      key authorization (a temporary key needs a Slack Approve click, which timed out; covered by
+      `test/ssh-broker.test.js`).
+- [x] **SSH, host hop and a GUI client (owner's own Mac, not a QA actor).** After the owner reran
+      `scripts/install-ssh-access.sh` as root (the drop-in now carries `AllowUsers channelgate-ssh`
+      and the endpoint survived), VS Code Remote-SSH on a Mac connected through
+      `org.makeitfuture.dev:2222` → `channelgate-ssh` → the attach socket → `cg-sshd` into
+      `dev-agentify-makeitfuture`, landing as `agent@<container id>` with the work folder open.
+      PASS. It surfaced a third defect: interactive `claude` there opened the first-run theme
+      picker and login screen although `claude -p` answered `SSH-CLAUDE-OK` through the relay —
+      headless turns never complete onboarding, which lives in `$CLAUDE_CONFIG_DIR/.claude.json`.
+      Fixed (`dfb09ac`: every attach merges `hasCompletedOnboarding` + a default theme there).
+      Verified in a throwaway container from the same image: seeded, `claude` skips onboarding, asks
+      only to trust the folder, then opens on the relayed login ("Claude API"). The live channel was
+      seeded with the shipped script (24 existing keys kept) — and the owner reported the SAME
+      screens afterwards: over SSH `CLAUDE_CONFIG_DIR` was empty. sshd starts every session with a
+      clean environment, so Claude read `~/.claude.json`, not the seeded file. Fixed (`8bad79d`: the
+      container's environment rides one `SetEnv` in the generated sshd_config, plus `CG_WORKDIR`;
+      image 1.5.1 starts an interactive SSH login in the channel folder; the owner's second ask).
+      Verified with a real `ssh` client into a throwaway 1.5.1 container prepared by the gateway's
+      own code (the real `podman inspect` environment, the real relay): `ssh e2e pwd` →
+      `/home/agent` and `bash -lc pwd` → `/home/agent` (non-interactive and Codex-style login shells
+      are not moved); an interactive login in tmux → prompt in the work folder,
+      `CLAUDE_CONFIG_DIR=/home/agent/.claude`, `TZ=Europe/Bucharest`; plain `claude` → no theme
+      picker, no login screen, only the folder-trust question, then "Sonnet 5 · Claude API" and
+      `SSH-INTERACTIVE-OK` answered. PASS. The owner then reported the session was still not the
+      channel's Claude: "Claude API" with no usage shown (it IS the Max login — proven by the
+      unified 5-hour/7-day limit headers Anthropic returned for the relayed token, identical to
+      the host's `/usage` — Claude Code just cannot tell a token's plan), no MCP servers and no
+      secrets, while a Slack turn has all three. Built as parity (`d4fd036`, `ssh-session.js`) and
+      proven with the REAL channel data (`dev-agentify-makeitfuture`'s meta, the owner's user id,
+      the running daemon's signing secret) prepared into a throwaway 1.5.1 container and a real
+      `ssh` client: `CG_SSH_USER` arrives from the key line; `claude -p` lists exactly
+      `composio-agent`, `composio-user`, `gateway` and answers "no" for a secret that channel does
+      not define; interactive `claude` → "Opus 5 (1M context) · Claude Max", `/status` "Login
+      method: Claude Max account" + the operator's organization and email, "Setting sources:
+      Command line arguments", `/mcp` composio-agent ✔ 11 tools, composio-user ✔ 11 tools (the
+      owner's own), and NO `claude.ai` connector (16 of them load without the flags). PASS. The
+      `gateway` entry showed ✘ in that test: the bridge reached the RUNNING daemon, which predates
+      the `ssh_session` origin and refuses the capability until it restarts (the unit test proves
+      the new daemon verifies it) — re-check after the restart: open. Found on the way: the
+      channel's volume held a self-updated Claude in `~/.npm-global/bin`, first on PATH, which is
+      why the seeded onboarding never showed; removed, and every container now runs with
+      `DISABLE_AUTOUPDATER=1`. After the restart the owner's real session (`6f27cd50`, files
+      prepared 12:09) had the org secret and the gateway; a channel secret (`TEST`) added at
+      ~12:12 did not reach it — the files refresh on a 20-minute tick. Fixed (`9baedd6`): every
+      configuration write emits an in-process event and the broker re-prepares the sessions it
+      concerns within 250 ms; a running `claude` keeps its environment, the next one has the
+      secret. Then the owner asked for no restart at all: proven NOT possible through `BASH_ENV`
+      (Claude Code's Bash tool does not source it — `early=unset` with the value only in that file)
+      and deliberately not through an MCP tool that returns values (they would land in the
+      model's context). Shipped instead (`6bac50f`): one `list_secrets` for all three scopes (live,
+      names only; six tools became three), `CG_SESSION_ENV` naming the session's rewritten env
+      file, and a per-session system-prompt note telling the model to source it in the same
+      command. Live re-check (add a secret; in the SAME running `claude` ask it to use it): open.
+- [x] **Shared VS Code server over SSH.** In that fresh volume: six links, `~/.vscode-server` 48 KB,
+      Remote-SSH's own existence check (`cli/servers/Stable-<commit>/server/bin/code-server`)
+      passes for 1.138.0, `code-7debcd0e… --version` → `code 1.138.0`. The server started over the SSH
+      session from the shared copy and, through `-L 18765:127.0.0.1:8765`, `GET /version` from the
+      host returned `7debcd0e2acdea1c52de81bf9ee1620444407dda`; state landed in the volume (1.2 MB),
+      zero write errors. PASS. A GUI client connecting: PASS (above).
+- [ ] Not run this release: every Codex case (usage-limited); Slack-UI cases (Settings page,
+      `/secrets`, resume round trip, `/model` + Overview); admin-UI cases; Composio Drive staging;
+      organization secrets (needs an Approve click).
+
+Known issue found live: `.runtime/<platform>/<slug>/claude-plugins/<digest>` — the content-addressed
+shared-skills plugin — gains a directory in every active channel whenever skill or guide content
+changes and is never collected (1,807 directories, ~14 GB on Xavier). Proposed: report it in
+`npm run runtime:storage` and remove digests no live process uses under `--apply`.
+
 ## Cross-engine failover spawn contract
 
 - [x] `test/fallback-spawn-contract.test.js` drives the real orchestrator against the stub CLIs on
 
@@ -6,6 +6,29 @@
 > CI passed on the exact candidate and a live smoke ran for Claude and Qwen. The owner released it
 > without Codex live acceptance (the Codex account was usage-limited until 2026-09-24) and without
 > the full live campaign; both remain open for the next release, see RELEASE-ACCEPTANCE.md.
+> 0.5.3 was published on 2026-09-24 by explicit owner decision after the full automated gate and
+> CI passed on the exact candidate and a live Claude campaign ran on Xavier through the QA actors
+> (Apps, Contact) in the `cg-qa` fixtures, recorded in TEST-PLAN.md → "0.5.3 live acceptance". Codex
+> live acceptance was skipped by owner instruction: the account was usage-limited until 10:40 on
+> 2026-09-24, past the release window. SSH access was proven end to end: the container half with a
+> real `ssh` client through `cg-sshd`, the shared VS Code server over an SSH port forward, and —
+> after `scripts/install-ssh-access.sh` was rerun as root — the host-sshd hop with a GUI VS Code
+> Remote-SSH client on the owner's Mac. Live testing found and fixed three defects before promotion
+> (a guide that suggested a blanket prune; failover notices that never reached a streamed answer;
+> interactive `claude` over SSH looking signed out: first-run onboarding never recorded, and SSH
+> sessions starting without the container's environment), then made an SSH session the same
+> environment a chat turn gets (lockdown, gateway + Composio + catalog MCP, secrets, an
+> account-shaped access-only login) and stopped Claude self-updating inside channels. The image
+> is spec 1.5.1 (an interactive SSH login starts in the channel folder); Atlas must run
+> `npm run build:image`. The live re-check of the streamed
+> failover notice stays open: it needs a Codex usage-limit failover on the running daemon. Carried forward as a known issue: the content-addressed
+> `claude-plugins` cache under each channel's artifact dir is never collected (~14 GB on Xavier).
+> Four administration-UI changes landed after that campaign ran and are therefore covered by the
+> automated gate only — their `TEST-PLAN.md` live gates are still unticked: the channel-runtime
+> reset's scope choice (*Channels only* / *Channels + threads*), that reset now clearing a
+> channel's reasoning effort with its engine and model, the skill template picked in place on the
+> Slack Settings page, and the VPN moved onto the row under the network switch. All four are Block
+> Kit / admin-page interactions that only a human can exercise on a running daemon.
 > 0.5.2 was published on 2026-09-22 by explicit owner decision after the full automated gate
 > passed on the exact candidate. It carries the cross-engine failover spawn-contract fix, the VPN
 > health-check fix and on-demand Google Drive sync. The owner again released it without Codex