@rubytech/create-maxy-code 0.1.299 → 0.1.301

package/payload/platform/plugins/admin/skills/public-agent-manager/SKILL.md

@@ -49,7 +49,7 @@ Each agent lives at `{accountDir}/agents/{slug}/`:
 
 ### Toolless by construction
 
-The public agent has no tools (Task 615). It cannot search the graph, read files, run commands, or load skills mid-conversation. Everything it knows is the KNOWLEDGE.md and SOUL assembled into its system prompt at spawn time. There is no operator toggle for this — it is the fixed posture for every public agent on every channel. If the agent needs to surface graph content created after deployment, refresh its KNOWLEDGE.md (see Update knowledge below); the agent itself never reaches the live graph.
+The public agent has no tools. It cannot search the graph, read files, run commands, or load skills mid-conversation. Everything it knows is the KNOWLEDGE.md and SOUL assembled into its system prompt at spawn time. There is no operator toggle for this — it is the fixed posture for every public agent on every channel. If the agent needs to surface graph content created after deployment, refresh its KNOWLEDGE.md (see Update knowledge below); the agent itself never reaches the live graph.
 
 ### knowledgeKeywords
 
@@ -99,7 +99,7 @@ SOUL.md answers "what does this agent feel like to talk to, and what is it here
 
 KNOWLEDGE.md is the public agent's baked, static knowledge surface — the facts the agent should always have on hand without a tool call. It is assembled into the system prompt at invocation time.
 
-Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. The public agent is toolless (Task 615): KNOWLEDGE.md is its **only** knowledge source. There is no graph access mid-conversation. Every gap in KNOWLEDGE.md is a question the agent cannot answer, so the KNOWLEDGE.md you build below is the whole of what the agent will know — populate it thoroughly.
+Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. The public agent is toolless: KNOWLEDGE.md is its **only** knowledge source. There is no graph access mid-conversation. Every gap in KNOWLEDGE.md is a question the agent cannot answer, so the KNOWLEDGE.md you build below is the whole of what the agent will know — populate it thoroughly.
 
 The `memory-search` calls described below are **your** admin-time tool for populating KNOWLEDGE.md, not something the public agent ever runs. All `memory-search` queries for knowledge population use admin permissions — do not pass `agentSlug`. The `agentSlug` parameter is a runtime enforcement mechanism for the public agent's MCP server, not an admin-time discovery tool. At creation time, the agent may have zero tagged nodes — searching with `agentSlug` would return nothing.
 
@@ -155,7 +155,7 @@ After creation, no template metadata persists in the agent's files. The resultin
 1. **Pre-creation check** — verify the target directory (`agents/{slug}/`) does not exist or is empty before proceeding. If remnant files exist from a prior incomplete deletion, flag the issue to the user: show what files remain and offer to clean them up before starting fresh. Do not silently inherit stale files — a leftover `config.json` from a previous agent would bypass the creation gate.
 2. Ask for the agent's name (becomes the slug) and role description
 3. **Knowledge discovery** — search the graph with admin permissions (no `agentSlug` — the agent doesn't exist yet) to find available knowledge. Present available content grouped by category for the user to select.
-4. **Install `IDENTITY.md`** — copy the Rubytech-controlled template verbatim to `agents/{slug}/IDENTITY.md`. It is fixed (the toolless public directive — Task 615) and is never drafted, edited, or presented for review.
+4. **Install `IDENTITY.md`** — copy the Rubytech-controlled template verbatim to `agents/{slug}/IDENTITY.md`. It is fixed (the toolless public directive) and is never drafted, edited, or presented for review.
 5. Present `SOUL.md` via document-editor with `filePath: "agents/{slug}/SOUL.md"` (draft personality and the operator-defined role from user conversation — tone plus the role the operator describes for the agent). Write on approval. Must be non-empty; an empty SOUL is refused at spawn.
 6. Present agent configuration via a single `form` component with these fields:
    - `knowledgeKeywords` (`text`): label "Knowledge keywords (max 5, comma-separated)", placeholder with examples relevant to the agent's role
@@ -249,7 +249,7 @@ Invoke the agent with `[New session. Greet the visitor.]` and stream the respons
 
 ## Runtime Surface
 
-Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. They are toolless by construction (Task 615): no filesystem access, no MCP tools, no subagents, no `memory-search`. Every public spawn resolves an empty `--allowed-tools`, runs in `dontAsk`, and carries a per-spawn `permissions.deny` covering every native, harness, and memory-MCP tool on every channel. Everything the agent needs to say comes from its directory files (IDENTITY.md, SOUL.md, KNOWLEDGE.md) assembled into the system prompt at invocation time — nothing else is reachable.
+Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. They are toolless by construction: no filesystem access, no MCP tools, no subagents, no `memory-search`. Every public spawn resolves an empty `--allowed-tools`, runs in `dontAsk`, and carries a per-spawn `permissions.deny` covering every native, harness, and memory-MCP tool on every channel. Everything the agent needs to say comes from its directory files (IDENTITY.md, SOUL.md, KNOWLEDGE.md) assembled into the system prompt at invocation time — nothing else is reachable.
 
 ## URL Routing
 

package/payload/platform/plugins/aeo/PLUGIN.md

@@ -68,7 +68,7 @@ The audit nodes carry `accountId`, `target` (URL or `(inline html)`), `score`, `
 
 ## What this plugin does not do
 
-- No LLM API calls. No citation monitor — out of scope. Multi-engine answer harvesting doesn't fit maxy-code's no-API-key architecture, and the monitor was archived without sprinting (Task 363). The audit plus the structured-answer template are the surface; check citation manually when needed.
+- No LLM API calls. No citation monitor — out of scope. Multi-engine answer harvesting doesn't fit maxy-code's no-API-key architecture, and the monitor was archived without sprinting. The audit plus the structured-answer template are the surface; check citation manually when needed.
 - No automatic emission. `aeo-emit-jsonld` returns a script block; wiring it into the platform's page render path is per-renderer work, also filed as a follow-up.
 - No prose authoring. AEO audits structure; it does not rewrite content. Writer-craft owns voice.
 

package/payload/platform/plugins/business-assistant/skills/e-sign/SKILL.md

@@ -18,7 +18,7 @@ It composes two patterns you must read alongside it:
 - **`cloudflare/references/d1-data-capture.md`** — the form → Pages Function → D1 → sweep mechanics, and the token-scope breakage (§ 0). Everything about minting the Pages-+-D1 token, `wrangler.toml`, and `wrangler d1 execute --remote` lives there; this skill does not repeat it. Note its rule that the D1 **query** endpoint rejects a D1-Read token — every `wrangler d1 execute` here uses a **D1-Edit** token, reads included.
 - **`business-assistant/references/invoicing.md`** — PDF generation via `browser-navigate` + `browser-pdf-save` (its step 4). The **deploy-time base render** (§ 5) uses that exact pattern. Dispatch (§ 6) does **not** — it stamps the persisted base with a PDF library, no browser and no network.
 
-Auth for every `wrangler`/API call is the **reused per-scope narrow token** of `cloudflare/references/api.md` (one deterministic token per scope — minted once if absent, persisted to the secrets file, then loaded and reused; Task 732), routed by the master's type (`cfat_…` account-scoped vs `cfut_…` user-scoped) by prefix per that reference. Deploy mechanics are `cloudflare/references/hosting-sites.md`.
+Auth for every `wrangler`/API call is the **reused per-scope narrow token** of `cloudflare/references/api.md` (one deterministic token per scope — minted once if absent, persisted to the secrets file, then loaded and reused), routed by the master's type (`cfat_…` account-scoped vs `cfut_…` user-scoped) by prefix per that reference. Deploy mechanics are `cloudflare/references/hosting-sites.md`.
 
 ---
 
@@ -51,7 +51,7 @@ Do **not** deploy until all three pass. Each failure has one exact remediation;
    On `missing`, stop:
    > "The account directory isn't set, so I can't attach the signed PDF or persist the base render. `ACCOUNT_DIR` is normally set at spawn; if it's missing, this session was started without an account context — restart the account's session so the spawn seam sets it, then ask me again."
 
-   (`ACCOUNT_DIR` is the spawn-seam guarantee of Task 714; this pre-flight only asserts it, it does not set it.)
+   (`ACCOUNT_DIR` is a spawn-seam guarantee; this pre-flight only asserts it, it does not set it.)
 
 ---
 
@@ -491,7 +491,7 @@ Dispatch runs **only** inside a live operator session on the account's own devic
      - once to the **business owner's configured address** (read from configured business identity — never hard-code a recipient in this workflow);
      - once to the **signer's captured `email`** — this copy is the **statutory record provided to the signer**, the evidentiary copy the legal basis (intro) relies on.
 
-     **Owner-copy visibility.** The owner copy only *arrives* if the agent's mailbox actually receives mail addressed to the business address. A recipient-filter that drops mail to the business address (the bug fixed in Task 700 / `rubytech-shared-catchall-mailbox`) makes the owner copy vanish while the signer copy arrives — check that filter first if the owner reports a missing confirmation.
+     **Owner-copy visibility.** The owner copy only *arrives* if the agent's mailbox actually receives mail addressed to the business address. A recipient-filter that drops mail to the business address (the bug fixed in `rubytech-shared-catchall-mailbox`) makes the owner copy vanish while the signer copy arrives — check that filter first if the owner reports a missing confirmation.
 
    - **Mark this row — and only this row — swept, once both sends return a verified result**, keyed by its `id`:
 
@@ -658,7 +658,7 @@ grep -q "__cf_access_message" "$DIST/index.html" \
 
 Two distinct regressions of the § 1a neutral portal, both caught by the § 8.10 grep of the local output dir:
 
-- **Document-specific root (single-document regression).** The root redirects to or embeds **one** document's slug/path/content (the Task 720 design this supersedes), so it is wrong for every other document on the host and breaks silently the moment a second document is added — no event, until a signer for document B logs out and lands on document A. Signature: any `location.replace(`/meta-refresh or document path in the root. The fix is the neutral portal — no document-specific path, no document content.
+- **Document-specific root (single-document regression).** The root redirects to or embeds **one** document's slug/path/content (the earlier design this supersedes), so it is wrong for every other document on the host and breaks silently the moment a second document is added — no event, until a signer for document B logs out and lands on document A. Signature: any `location.replace(`/meta-refresh or document path in the root. The fix is the neutral portal — no document-specific path, no document content.
 - **Sticky-param interstitial.** The root **branches on `__cf_access_message=logged_out`** — showing a "signed out" interstitial when the param is present. Because Cloudflare preserves that param through the **entire re-login redirect**, a re-authenticated signer is landed back on `/` with the **stale** param and shown a logged-out screen *while logged in*. Signature: any reference to `__cf_access_message` in the root. The fix is the neutral portal — it makes no auth-state claim, so it is correct in every state.
 
 The neutral portal must therefore contain **no** document-specific path **and no** auth-state claim; it shows the same content unconditionally.

package/payload/platform/plugins/cloudflare/references/manual-setup.md

@@ -2,18 +2,19 @@
 
 Step-by-step recovery path for when the Maxy automation fails or is unavailable. Every command below is isolated in its own code block — nothing to parse from prose. Every path is brand-scoped so multiple brands can coexist on the same Linux user.
 
-Prerequisites: `cloudflared` installed; the brand's VNC running on its own X display + rfbport + websockify + CDP port (per `brand.json`'s `vncDisplay`/`rfbPort`/`websockifyPort`/`cdpPort` fields — Tasks 553 + 924; defaults Maxy=`:99`/`5900`/`6080`/`9222`, Real Agent=`:100`/`5901`/`6081`/`9223`, Maxy-2=`:101`/`5902`/`6082`/`9224`, Maxy-3=`:102`/`5903`/`6083`/`9225`, Maxy-4=`:103`/`5904`/`6084`/`9226`); SSH access to the device. The defaults table is historical — runtime readers (`paths.ts`, admin/MCP, `vnc.sh`, `test-laptop-vnc-boot.sh`) loud-fail with `reason=cdp-port-unresolved` if any of `rfbPort`/`websockifyPort`/`cdpPort` is missing from the live `brand.json`; the values above show what each brand's `brand.json` contains, not what the readers fall back to.
+Prerequisites: `cloudflared` installed; the brand's VNC running on its own X display + rfbport + websockify + CDP port (per `brand.json`'s `vncDisplay`/`rfbPort`/`websockifyPort`/`cdpPort` fields — defaults Maxy=`:99`/`5900`/`6080`/`9222`, Real Agent=`:100`/`5901`/`6081`/`9223`, Maxy-2=`:101`/`5902`/`6082`/`9224`, Maxy-3=`:102`/`5903`/`6083`/`9225`, Maxy-4=`:103`/`5904`/`6084`/`9226`); SSH access to the device. The defaults table is historical — runtime readers (`paths.ts`, admin/MCP, `vnc.sh`, `test-laptop-vnc-boot.sh`) loud-fail with `reason=cdp-port-unresolved` if any of `rfbPort`/`websockifyPort`/`cdpPort` is missing from the live `brand.json`; the values above show what each brand's `brand.json` contains, not what the readers fall back to.
 
 ---
 
-## Why two hostnames (admin and public)
+## Why several hostnames (admin, public, operator)
 
-Each Maxy installation exposes two distinct surfaces from the same device and the same local port. The platform UI distinguishes them by the inbound `Host:` header.
+Each Maxy installation exposes distinct surfaces from the same device and the same local port. The platform UI distinguishes them by the inbound `Host:` header.
 
 - **admin hostname** — the operator's private chat + admin panel. PIN-protected. Only the owner uses it.
 - **public hostname** — the public-facing agent (customer chat, marketing agent, WhatsApp webhook target). Reachable by anyone on the internet.
+- **operator hostname** (optional) — a trimmed admin dashboard (sessions, chat, data — no graph, no browser). Admin-gated like the admin host, recognised by membership in `operator-domains.json`. See § "Operator dashboard ingress".
 
-Two tunnel hostnames, one connector, one local service. The tunnel's `ingress:` block routes each hostname to `http://localhost:${PORT}`; the platform UI handles the rest.
+Several tunnel hostnames, one connector, one local service. The tunnel's `ingress:` block routes each hostname to `http://localhost:${PORT}`; the platform UI classifies the host (operator → public → admin) and serves the matching surface.
 
 ---
 
@@ -236,7 +237,7 @@ ingress:
 EOF
 ```
 
-**Why:** Tells cloudflared at startup which tunnel to run, where its credentials are, and how to route each hostname to the brand's local service port. The trailing `http_status:404` line is the mandatory catch-all. `no-autoupdate: true` stops the connector downloading a new binary and replacing itself (which exits the running process); the cloudflared version is installer-owned and bumped deliberately. This is belt-and-braces with the `--no-autoupdate` flag `resume-tunnel.sh` already passes on the spawn argv — the flag covers every existing install on its next service restart, this line covers a connector started any other way from a freshly-provisioned config. Task 757.
+**Why:** Tells cloudflared at startup which tunnel to run, where its credentials are, and how to route each hostname to the brand's local service port. The trailing `http_status:404` line is the mandatory catch-all. `no-autoupdate: true` stops the connector downloading a new binary and replacing itself (which exits the running process); the cloudflared version is installer-owned and bumped deliberately. This is belt-and-braces with the `--no-autoupdate` flag `resume-tunnel.sh` already passes on the spawn argv — the flag covers every existing install on its next service restart, this line covers a connector started any other way from a freshly-provisioned config.
 
 **Success:** Confirm with:
 
@@ -428,7 +429,7 @@ A non-530 response means the tunnel is live.
 
 The correct production pattern is already in place on every Maxy device: the brand's platform UI itself is a **user-space systemd service** at `~/.config/systemd/user/<brand>.service`, and that service spawns the cloudflared connector as an `ExecStartPre=` via `platform/scripts/resume-tunnel.sh`. The connector runs as the Linux user (not root), its config is read from `${CFG_DIR}/config.yml` (brand-scoped, never `/etc`), and multiple brands coexist because each has its own unit file (`maxy.service`, `realagent.service`, etc.).
 
-**The connector is a supervised, self-healing unit (Task 602 + Task 757).** `resume-tunnel.sh` does not run cloudflared as a child of the brand service. It spawns it into its own transient systemd **service** — `cloudflared-<brand>.service` under `cloudflared.slice` — with `Restart=always`. Two consequences: a brand-service restart no longer reaps the connector (Task 602's cgroup decoupling), and systemd resurrects the connector on **any** exit — crash, OOM, manual kill (Task 757). The connector also runs with `--no-autoupdate`, so it never downloads a new binary and replaces itself; the version is installer-owned (pinned in the installer, bumped deliberately). `StartLimitIntervalSec=300`/`StartLimitBurst=5` mean a genuinely broken binary surfaces as a `failed` unit instead of looping forever.
+**The connector is a supervised, self-healing unit.** `resume-tunnel.sh` does not run cloudflared as a child of the brand service. It spawns it into its own transient systemd **service** — `cloudflared-<brand>.service` under `cloudflared.slice` — with `Restart=always`. Two consequences: a brand-service restart no longer reaps the connector (the cgroup decoupling), and systemd resurrects the connector on **any** exit — crash, OOM, manual kill. The connector also runs with `--no-autoupdate`, so it never downloads a new binary and replaces itself; the version is installer-owned (pinned in the installer, bumped deliberately). `StartLimitIntervalSec=300`/`StartLimitBurst=5` mean a genuinely broken binary surfaces as a `failed` unit instead of looping forever.
 
 **Observability.** A connector death is now a logged, countable event, not an invisible gap:
 
@@ -439,9 +440,13 @@ journalctl --user -u cloudflared-<brand>.service | grep "Scheduled restart job"
 
 # Confirm auto-update is off — cloudflared prints its effective settings at startup:
 grep "no-autoupdate:true" "${CFG_DIR}/logs/cloudflared.log"
+
+# Single-connector census — resume-tunnel logs a reap on every brand-service start:
+grep "\[tunnel-supervise\] op=reap" "${CFG_DIR}/logs/cloudflared.log"
+# (each completed start ends in "found=<n> killed=<m> survivor=<pid>"; healthy steady state is found=1)
 ```
 
-`no-autoupdate:true` in cloudflared's startup `Settings:` line is the per-box rollout acceptance signal. A unit that has tripped its start limit shows `Active: failed` under `systemctl --user status cloudflared-<brand>.service` — investigate the binary rather than restarting blindly.
+`no-autoupdate:true` in cloudflared's startup `Settings:` line is the per-box rollout acceptance signal. A unit that has tripped its start limit shows `Active: failed` under `systemctl --user status cloudflared-<brand>.service` — investigate the binary rather than restarting blindly. A reap census whose final line shows `found>1` after a completed start, or any per-kill `target=<pid> tunnel=<id>` line whose tunnel id is not this brand's, is the failure signature (a stray survived, or a co-resident brand's connector was matched); `ps -eo pid,etime,args | grep '[c]loudflared.*tunnel run'` should then show exactly one connector, carrying `--no-autoupdate`.
 
 **Durability prerequisites (one-time per device):**
 
@@ -471,7 +476,7 @@ systemctl --user restart "cloudflared-${BRAND}.service"
 
 With `Restart=always` this is a clean reload: systemd starts a fresh connector under the same unit, reading the edited `config.yml`. The brief ~1s blip is the same one every cloudflared upgrade incurs.
 
-**Why not the brand service?** Since Task 602 decoupled the connector into its own unit (and Task 757 made it a supervised `Restart=always` service), `systemctl --user restart "${BRAND}.service"` no longer reaps the connector. Its `ExecStartPre=resume-tunnel.sh` runs, sees the connector already `is-active`, and skips by design (`resume-tunnel.sh` line 65) — so the brand-service restart succeeds while the old connector keeps serving the old ingress. That is a silent no-op, not an error. Restarting the brand service only spawns a connector when none is running (the first-provision case in Step 6).
+**Why not the brand service?** Since the connector was decoupled into its own unit (and made a supervised `Restart=always` service), a `systemctl --user restart "${BRAND}.service"` does not replace the running connector: its `ExecStartPre=resume-tunnel.sh` sees the supervised connector already `is-active` and does not respawn it, so the edited `config.yml` is not picked up by a brand-service restart. Restart the connector unit directly (above) to apply a config change. What the brand-service restart *does* do now is **reap strays**: before the skip, `resume-tunnel.sh` terminates every bare or stale `cloudflared … tunnel run` bound to this brand's cert/config/tunnel-id, leaving exactly the one supervised connector. So the two operations are distinct — restart the connector unit to load new ingress; restart the brand service to clear a duplicate connector. Restarting the brand service still only *spawns* a connector when none is running (the first-provision case in Step 6).
 
 **Success:**
 
@@ -564,6 +569,8 @@ systemctl --user restart "cloudflared-${BRAND}.service"
 
 Cloudflared does not watch `config.yml` for changes (the brand service unit launches it without `--config-watch`). Restart is the deterministic way to pick up the new rule; the brief ~1s connector blip is the same one every cloudflared upgrade incurs.
 
+**Single-connector guarantee.** Restarting `cloudflared-${BRAND}.service` replaces the *supervised* connector in place. It does **not** touch a bare `cloudflared … tunnel run` started outside systemd (a manual run, a stale process serving old ingress) — so a bare stray keeps answering with its own `http_status:404` catch-all and Cloudflare can route requests to it, the exact intermittent-404 failure this guarantee closes. If `ps -eo pid,args | grep '[c]loudflared.*tunnel run'` shows more than one connector for this brand, restart the brand service (`systemctl --user restart "${BRAND}.service"`, with the `systemd-run` indirection from Step 6 when you are the admin agent): its `ExecStartPre=resume-tunnel.sh` reaps every stray bound to this brand's cert/config/tunnel-id and leaves exactly one. The reap is brand-scoped — a co-resident brand's connector (different cert path, different tunnel id) is never touched. Never start a second `cloudflared … tunnel run` by hand to apply a change; that stacks the duplicate this guarantee exists to prevent.
+
 ### Verification
 
 ```
@@ -596,36 +603,50 @@ systemctl --user restart "cloudflared-${BRAND}.service"
 
 ---
 
-## Operator dashboard ingress (`operator.<host>`)
+## Operator dashboard ingress (operator host)
+
+The operator dashboard is a trimmed admin surface (sessions, chat, WhatsApp reader, data — no graph, no browser). It routes to the **same brand UI port** as the admin host (`${MAXY_UI_PORT}`) and is gated by the **same admin gate** (Cloudflare Access / remote-auth + PIN + Claude OAuth) — it is not a public host. A request to the operator host that is unauthenticated hits the identical login flow as the bare admin host; the UI server then classifies the host and serves the operator shell.
 
-Task 822 adds a trimmed operator dashboard served on `operator.<BRAND_HOSTNAME>`. Unlike a prototype surface, it routes to the **same brand UI port** as the admin host (`${MAXY_UI_PORT}`) and is gated by the **same admin gate** (Cloudflare Access / remote-auth + PIN + Claude OAuth) — it is not a public host. A request to `operator.<host>` that is unauthenticated hits the identical login flow as the bare admin host; the UI server classifies the host and serves the operator shell (sessions, chat, WhatsApp reader, data — no graph, no browser).
+**The operator hostname is arbitrary** — any FQDN the operator chooses (e.g. `glsops.siteoffice.online`). There is no `operator.` prefix rule: the UI classifies a host as operator **only** when the host is listed in `~/.${BRAND}/operator-domains.json`. Provisioning therefore has two scripted parts — the tunnel ingress (so the host reaches the brand UI) and the operator-domains.json write (so the UI serves the operator shell instead of the full admin shell).
 
-Add it with the same Multi-ingress flow above, using `SURFACE=operator` and `PORT=${MAXY_UI_PORT}` (the brand UI port, not a separate dev server):
+Take the operator FQDN from chat:
 
 ```
-SURFACE="operator"
-PORT="${MAXY_UI_PORT}"          # the brand UI port — same service as admin/public
-HOSTNAME="operator.${BRAND_HOSTNAME}"
+OPERATOR_HOSTNAME="glsops.siteoffice.online"   # the operator's chosen FQDN
+PORT="${MAXY_UI_PORT}"                          # the brand UI port — same service as admin/public
 ```
 
-Then run the awk append (step 1), validate (step 2), create the DNS row (step 3), and reload the connector (step 4) exactly as documented above. After the edit the ingress block carries the operator row before the catch-all:
+### 1. Ingress + DNS
+
+Run the Multi-ingress flow above with `HOSTNAME="${OPERATOR_HOSTNAME}"` and `PORT="${MAXY_UI_PORT}"`: the awk append (step 1), validate (step 2), create the DNS row (step 3), reload the connector (step 4). After the edit the ingress block carries the operator row before the catch-all (hostnames are illustrative — yours are whatever the operator registered):
 
 ```yaml
 ingress:
-  - hostname: admin.<BRAND_HOSTNAME>
+  - hostname: glsmith.siteoffice.online   # admin (primary)
     service: http://localhost:<MAXY_UI_PORT>
-  - hostname: public.<BRAND_HOSTNAME>
+  - hostname: gls.siteoffice.online       # public (also in alias-domains.json)
     service: http://localhost:<MAXY_UI_PORT>
-  - hostname: operator.<BRAND_HOSTNAME>
+  - hostname: glsops.siteoffice.online    # operator (also in operator-domains.json)
     service: http://localhost:<MAXY_UI_PORT>
   - service: http_status:404
 ```
 
-When a provisioning script adds this row it logs `[tunnel-install] operator-ingress added host=operator.<BRAND_HOSTNAME> → :${MAXY_UI_PORT}`; the absence of an `operator.` ingress on a brand that should have one is the failure signature.
+### 2. Classify the host as operator
+
+The ingress only gets the request to the brand UI; without this write the UI serves the **full admin shell** on the operator host. Append the hostname to `operator-domains.json` at the **brand root** (not `${CFG_DIR}` — the platform UI watches the brand root and hot-reloads within ~2 s, no restart):
+
+```
+F="${HOME}/.${BRAND}/operator-domains.json"
+[ -f "$F" ] || echo '[]' > "$F"
+jq --arg H "${OPERATOR_HOSTNAME}" 'if index($H) then . else . + [$H] end' "$F" > /tmp/op.json && mv /tmp/op.json "$F"
+cat "$F"
+```
+
+The UI logs `[operator-domains] reloaded <n> operator domain(s): …` within ~2 s of the write. A configured brand whose boot/reload log shows `0 operator domain(s)` while an operator host is expected means the file was written to the wrong path (e.g. under `cloudflared/`).
 
-**Verification.** `curl -I https://operator.<BRAND_HOSTNAME>` returns the admin login (not a 404, not the public agent page). After login the dashboard shows the sessions list and WhatsApp reader, the header menu carries only Dashboard / Chat / Data, and `https://operator.<BRAND_HOSTNAME>/graph` returns 404.
+**Verification.** `curl -I https://${OPERATOR_HOSTNAME}` returns the admin login (not a 404, not the public agent page). After login the dashboard shows the sessions list and WhatsApp reader, the header menu carries only Dashboard / Chat / Data, and `https://${OPERATOR_HOSTNAME}/graph` returns 404. The standing serve signal is `[host-class] host=${OPERATOR_HOSTNAME} class=operator served=operator.html`; `class=admin served=index.html` for a configured operator host is the full-shell leak signature (the operator-domains.json write was missed or written to the wrong path).
 
-> Installer auto-provisioning of this row is out of scope for Task 822 (documented manual/scripted add only); a follow-up task owns wiring it into the installer.
+> Installer auto-provisioning of this host is out of scope here (documented manual/scripted add only); wiring it into the installer is tracked separately.
 
 ---
 
@@ -668,7 +689,7 @@ If `admin.<yourdomain>` is rendering the public-agent UI, the tunnel is fine but
 - the hostname starts with `public.`, or
 - the hostname appears in `${HOME}/.${BRAND}/alias-domains.json` (note: brand root, **not** `${CFG_DIR}` — `alias-domains.json` lives one level above `cloudflared/`, because that's where the platform UI watches).
 
-Pre-Task-548 sessions populated this file via the now-deleted `tunnel-add-hostname` MCP tool, which wrote every routed hostname — including `admin.*` — into the alias set. The pollution persists across installs.
+Earlier sessions populated this file via the now-deleted `tunnel-add-hostname` MCP tool, which wrote every routed hostname — including `admin.*` — into the alias set. The pollution persists across installs.
 
 **Diagnose:**
 

package/payload/platform/plugins/cloudflare/references/reset-guide.md

@@ -14,7 +14,7 @@ Ask three questions in order. The first `yes` determines the action.
 2. **Is `config.yml` referencing a tunnel UUID that no longer exists on the account, or a hostname that the account no longer owns?**
    → Full reset. The tunnel the config names is unreachable; recovering per-step is slower than starting clean.
 
-3. **Is the only problem a stray CNAME in the dashboard, a rogue token-mode connector process, or an out-of-date `alias-domains.json` entry?**
+3. **Is the only problem a stray CNAME in the dashboard, a rogue token-mode connector process, or an out-of-date `alias-domains.json` / `operator-domains.json` entry?**
    → Patch (see § Patching below). Reset would destroy correct local state alongside the bad record.
 
 When no question reaches `yes`, the state is probably recoverable per-step via `references/manual-setup.md`. Re-run the relevant manual setup steps before reaching for reset.
@@ -102,6 +102,24 @@ jq --arg H "admin.<yourdomain>" 'map(select(. != $H))' "${HOME}/.${BRAND}/alias-
 
 Replace `<yourdomain>` with the actual domain. The platform UI watches the file and reloads without a restart.
 
+### Remove a rogue entry from `operator-domains.json`
+
+`operator-domains.json` controls which hostnames the platform UI classifies as **operator** (serving the trimmed operator dashboard — sessions, chat, data, no graph/browser) rather than admin or public. It lives at `${HOME}/.${BRAND}/operator-domains.json` — the brand root, **not** `${CFG_DIR}` — for the same reason as `alias-domains.json`: the platform UI watches the brand root.
+
+A host wrongly listed here serves the operator shell instead of the full admin shell (or instead of the public agent, since operator wins over public). Remove it manually:
+
+```
+cat "${HOME}/.${BRAND}/operator-domains.json"
+```
+
+If the wrong host is listed, strip it:
+
+```
+jq --arg H "<host-to-remove>" 'map(select(. != $H))' "${HOME}/.${BRAND}/operator-domains.json" > /tmp/op.json && mv /tmp/op.json "${HOME}/.${BRAND}/operator-domains.json"
+```
+
+The platform UI watches the file and reloads without a restart; the next request to the host routes to its corrected surface.
+
 ### Fix a single wrong DNS record without tearing everything down
 
 If a hostname's CNAME is pointing at the wrong tunnel (e.g. after an account switch left old records), `cloudflared` can overwrite it once the correct cert is in place:

package/payload/platform/plugins/cloudflare/skills/cloudflare/SKILL.md

@@ -36,7 +36,21 @@ Every Cloudflare operation proves itself with a live behavioural signal surfaced
 
 ## Inputs (tunnel)
 
-Four inputs come from the operator in chat: the admin FQDN, optional public FQDN, optional apex FQDN, and the admin password. `BRAND` is derived from disk — never hardcoded — with `BRAND=$(jq -r .hostname ~/.<configDir>/brand.json)`. The same install can host different brands on different ports; `brand.json.hostname` is the only authoritative source.
+Five inputs come from the operator in chat: the admin FQDN, optional public FQDN, optional operator-dashboard FQDN, optional apex FQDN, and the admin password. `BRAND` is derived from disk — never hardcoded — with `BRAND=$(jq -r .hostname ~/.<configDir>/brand.json)`. The same install can host different brands on different ports; `brand.json.hostname` is the only authoritative source.
+
+The operator always names the hostnames; the agent never invents one. When the operator asks for a suggestion, propose a **sibling** of the existing admin/public hosts — a new label at the same parent domain, not a label nested under another host. E.g. admin `glsmith.siteoffice.online` + public `gls.siteoffice.online` → suggest `glsops.siteoffice.online` (a peer under `siteoffice.online`), never `ops.glsmith.siteoffice.online` or `desk.gls.siteoffice.online` (nested under the admin/public host). Any hostname the operator picks is valid — this only shapes the default suggestion.
+
+## Host classes — three peers on one brand UI port
+
+A brand serves three peer host classes, all routed to the **same brand UI port** (`${MAXY_UI_PORT}`); the platform UI classifies each request by its `Host` header. The hostnames are arbitrary — there is no required `admin.`/`public.`/`operator.` prefix.
+
+| Class | How the UI recognises it | What it serves |
+|---|---|---|
+| **admin** (default) | the bare primary host — in neither domains file | full admin shell (chat, data, graph, browser) — admin-gated |
+| **public** | host starts with `public.` **or** is listed in `~/.${BRAND}/alias-domains.json` | the public agent page only — no admin surfaces |
+| **operator** | host is listed in `~/.${BRAND}/operator-domains.json` | the trimmed operator dashboard (sessions, chat, data — no graph, no browser) — admin-gated |
+
+Precedence is operator → public → admin: a host listed in `operator-domains.json` is operator even if it also matches a public rule. Both domains files live at the **brand root** `~/.${BRAND}/` (not under `cloudflared/`) because the platform UI watches the brand root and hot-reloads within ~2 s. Provisioning admin needs no domains-file write; public writes `alias-domains.json`; operator writes `operator-domains.json`. See `references/manual-setup.md` § "Operator dashboard ingress".
 
 ## Execution
 
@@ -48,7 +62,9 @@ Tunnel mutations the agent performs from `references/manual-setup.md` (each one
 - `cloudflared tunnel --origincert <cert> create <name>` — produces `<tunnelId>.json` credentials.
 - Write `~/.${BRAND}/cloudflared/config.yml` (ingress block per the runbook).
 - `cloudflared tunnel --origincert <cert> route dns <tunnelId> <hostname>` — one call per non-apex hostname.
-- For non-admin hostnames not starting with `public.`, append to `~/.${BRAND}/alias-domains.json` so `isPublicHost()` treats them as public.
+- For a public hostname not starting with `public.`, append it to `~/.${BRAND}/alias-domains.json` so `isPublicHost()` treats it as public.
+- For an operator-dashboard hostname, append it to `~/.${BRAND}/operator-domains.json` so the UI serves the trimmed operator shell (admin-gated). See `references/manual-setup.md` § "Operator dashboard ingress".
+- To apply an ingress change (a new operator or public host), relay a **reload to the supervised connector** — `systemctl --user restart "cloudflared-${BRAND}.service"` — which replaces the connector in place reading the edited `config.yml`. **Never** launch a bare `cloudflared … tunnel run` to pick up a change: that stacks a second connector on the tunnel (one on stale config), Cloudflare then routes some requests to the stale one, and the new host serves an intermittent 404. `resume-tunnel.sh` reaps such strays on the next brand-service start, but the correct provisioning path is the supervised reload, never a raw spawn.
 - Install + start the `${BRAND}-cloudflared.service` user unit (`systemctl --user daemon-reload && systemctl --user enable --now ${BRAND}-cloudflared.service`).
 
 After the service is up, the agent runs `curl -I https://<admin-hostname>` and pastes the response. The setup-done claim only fires when a `200` line appears in that response.
@@ -67,7 +83,7 @@ When the operator's request touches Cloudflare, the agent's permitted actions ar
 
 - Invoke `cloudflared` via Bash, following `references/manual-setup.md`.
 - Invoke `wrangler` and the Cloudflare API via Bash, following `references/api.md`, `references/hosting-sites.md`, and `references/d1-data-capture.md`, using the reused per-scope narrow token (minted once if absent, then reused).
-- Write `config.yml` and `alias-domains.json` per the runbook.
+- Write `config.yml`, `alias-domains.json`, and `operator-domains.json` per the runbook.
 - Install and start the brand's cloudflared user service.
 - Quote `references/manual-setup.md`, `references/reset-guide.md`, or `references/dashboard-guide.md` verbatim when a dashboard click-path is the right tool.
 - Verify reachability via `curl -I https://<hostname>` and surface the response.

package/payload/platform/plugins/contacts/PLUGIN.md

@@ -57,6 +57,6 @@ Tools are available via the `contacts` MCP server.
 
 `contact-create` writes a `:Person` node, which is one of the action-provenance-gated labels in `writeNodeWithEdges`. The write should carry an inbound `:PRODUCED` edge from `:Task`, `:Conversation`, or `:Message`. There is no agent-visible field for this — the admin server stamps `SESSION_NODE_ID` (the `sessionId` UUID of the active `:AdminConversation`) at MCP spawn time, and the wrapper auto-injects the `:PRODUCED` edge via `injectConversationProvenance`. The helper MATCHes `(c:Conversation {sessionId, accountId})` — account isolation is enforced inside the natural key, not as a separate gate, so a cross-account env-stamp returns zero rows and never injects.
 
-The agent passes whichever organic relationships are appropriate (`PARTICIPATES_IN` to a Conversation, `WORKS_FOR` to an Organization, `KNOWN_VIA` to a referral source) — the provenance edge is composed automatically and is not an agent concern. When the env-stamp resolution fails (loud `[mcp:contacts] [provenance-missing] reason=<...>`), the downstream gate emits a `[graph-write] warn reason=missing-provenance labels=<csv> agent=<agentLabel>` line and the write proceeds (Task 580 relaxed this from a hard reject). The warn carries the labels and agent so operators can quantify how often the gap fires; the upstream `[provenance-missing]` line names the resolution failure that caused it.
+The agent passes whichever organic relationships are appropriate (`PARTICIPATES_IN` to a Conversation, `WORKS_FOR` to an Organization, `KNOWN_VIA` to a referral source) — the provenance edge is composed automatically and is not an agent concern. When the env-stamp resolution fails (loud `[mcp:contacts] [provenance-missing] reason=<...>`), the downstream gate emits a `[graph-write] warn reason=missing-provenance labels=<csv> agent=<agentLabel>` line and the write proceeds (this was relaxed from a hard reject). The warn carries the labels and agent so operators can quantify how often the gap fires; the upstream `[provenance-missing]` line names the resolution failure that caused it.
 
 See [.docs/neo4j.md § Process provenance doctrine](../../../.docs/neo4j.md) for the doctrine and observability surface.

package/payload/platform/plugins/docs/references/admin-identity-gate.md

@@ -4,8 +4,8 @@ Admin identity is carried by the surface a session arrives on. It is never gated
 by a per-session step, and nothing a non-interactive channel cannot satisfy ever
 blocks a tool.
 
-The PIN identity gate (Task 619) — a universal PreToolUse hook that denied every
-tool until the operator submitted a PIN — was retired in Task 681. It deadlocked
+The PIN identity gate — a universal PreToolUse hook that denied every
+tool until the operator submitted a PIN — was retired. It deadlocked
 non-interactive surfaces: a WhatsApp channel session can never enter a PIN, so the
 channel reply tool was permanently unreachable. The hook, its `admin-identity-authenticate`
 submit tool, the `/api/admin/identity/validate` loopback endpoint, and the standing
@@ -34,14 +34,14 @@ sessions skip it.
 On a channel (WhatsApp today), the inbound sender phone is bound to a person's
 `userId` via `users.json` (`UserEntry.phone`), confirmed against the account's
 `admins[]`. The channel admin session carries that `userId` — graph writes and
-the `${USER_ID}` MCP env attribute to the actual sender (Task 682). An unbound
+the `${USER_ID}` MCP env attribute to the actual sender. An unbound
 sender (the owner's self-phone, or an `adminPhones` entry with no `users.json`
 phone) falls back to the boot-time owner `userId`.
 
 A WhatsApp admin whose inbound arrives as an unresolved LID (a cold mapping
 cache) resolves to their own `userId` via a runtime LID cache
 (`whatsapp-lid-map.json`), populated the first time their LID resolves to their
-phone (Task 686). A LID that has never resolved has no cache entry and still
+phone. A LID that has never resolved has no cache entry and still
 falls back to the owner `userId` — visible as the `op=admin-identity …
 userId=owner-fallback` log line.
 
@@ -49,9 +49,9 @@ On loopback (claude.ai/code), multiple admins resolve to the right *profile*
 conversationally but share the owner's `userId` at the env/MCP layer.
 Deterministic per-admin `userId` on loopback is deliberately out of scope:
 making it deterministic again means a per-session identity step, which is exactly
-the deadlock Task 681 removed.
+the deadlock the retirement removed.
 
-## Boot-time binding drift gate (Task 687)
+## Boot-time binding drift gate
 
 The channel-admin binding is reassembled at read time from three independently
 operator-maintained sources: `adminPhones` (role allowlist), `admins[]`

package/payload/platform/plugins/docs/references/admin-session.md

@@ -83,22 +83,22 @@ The Hono route `POST /api/admin/claude-sessions` at [`platform/ui/server/routes/
 
 **Body schema.** `{channel?, permissionMode?, initialMessage?, specialist?, model?}`, cookie-auth only (`hidden: false`). `permissionMode` accepts one of five values matching Claude Code's CLI: `'default'`, `'acceptEdits'`, `'plan'`, `'auto'`, `'bypassPermissions'`. The wrapper rejects nothing structurally — string fields are coerced or defaulted (`channel` → `'browser'`, `permissionMode` → undefined, `initialMessage` → null if empty/whitespace).
 
-**Auth surface.** One: `cookie` — `requireAdminSession` validates `session_key` and resolves `senderId` from the in-memory session store. Task 626 removed the turn-recorder loopback bypass; there is no loopback caller and no `adminSessionId` body field.
+**Auth surface.** One: `cookie` — `requireAdminSession` validates `session_key` and resolves `senderId` from the in-memory session store. The turn-recorder loopback bypass was removed; there is no loopback caller and no `adminSessionId` body field.
 
-**Forwarded endpoint.** One upstream call per spawn-with-message: `POST {managerBase}/public-spawn` (enriched body, with `initialMessage` inlined when set). The manager appends `initialMessage` as the trailing positional argv to `claude` so the CLI processes it as the session's first user turn at PTY startup — the JSONL first `role=user` line equals `initialMessage` verbatim. No follow-up `/<sessionId>/input` call, no bracketed-paste. The HTTP response streams the spawn upstream body straight through. (Task 153.)
+**Forwarded endpoint.** One upstream call per spawn-with-message: `POST {managerBase}/public-spawn` (enriched body, with `initialMessage` inlined when set). The manager appends `initialMessage` as the trailing positional argv to `claude` so the CLI processes it as the session's first user turn at PTY startup — the JSONL first `role=user` line equals `initialMessage` verbatim. No follow-up `/<sessionId>/input` call, no bracketed-paste. The HTTP response streams the spawn upstream body straight through.
 
-**Caller.** `Sidebar.tsx`'s "+ New session" click opens the `NewSessionModal` (Task 223) — no POST fires on click. Modal submit POSTs `{channel:'browser', permissionMode, model, initialMessage}` where `initialMessage` is the operator's typed text verbatim; `permissionMode` and `model` are per-session overrides local to the modal. The sidebar's own mode trigger persists across refresh, new tab, and new device under `(accountId, userId)` via `/api/admin/session-defaults` (Task 239) — a single `:SpawnPreference` node MERGEd on the composite key with `permissionMode` and `model`. The on-the-wire signal that the contract held is the `[claude-session-manager:wrapper] spawn-request-in surface=cookie` log line followed by `forward-spawn-done`; it always carries `initialMessage=yes`, which a regressed client gate would flip to `no`.
+**Caller.** `Sidebar.tsx`'s "+ New session" click opens the `NewSessionModal` — no POST fires on click. Modal submit POSTs `{channel:'browser', permissionMode, model, initialMessage}` where `initialMessage` is the operator's typed text verbatim; `permissionMode` and `model` are per-session overrides local to the modal. The sidebar's own mode trigger persists across refresh, new tab, and new device under `(accountId, userId)` via `/api/admin/session-defaults` — a single `:SpawnPreference` node MERGEd on the composite key with `permissionMode` and `model`. The on-the-wire signal that the contract held is the `[claude-session-manager:wrapper] spawn-request-in surface=cookie` log line followed by `forward-spawn-done`; it always carries `initialMessage=yes`, which a regressed client gate would flip to `no`.
 
-## Session identifiers (Task 135)
+## Session identifiers
 
-The metadata pane surfaces two distinct identifier values. Task 141 collapsed the three-id model that Task 135 introduced back to Task 080's single-identity contract: claude's bridge suffix and the JSONL basename UUID are two phases of one claude-side identity, not two operator-visible identifiers. The manager resolver accepts either phase on any route. The wire emits one canonical `sessionId` — whichever phase is current — and the pane shows one row.
+The metadata pane surfaces two distinct identifier values. The three-id model was collapsed back to a single-identity contract: claude's bridge suffix and the JSONL basename UUID are two phases of one claude-side identity, not two operator-visible identifiers. The manager resolver accepts either phase on any route. The wire emits one canonical `sessionId` — whichever phase is current — and the pane shows one row.
 
 | Operator label | What it is | Manager wire field | Log key |
 |---|---|---|---|
-| `sessionId` | Claude's session. Two phases: bridge suffix (`session_xxx`, the URL segment in `claude.ai/code/<session_xxx>`, set when claude prints the `/remote-control` URL) and JSONL basename UUID (claude's intrinsic id on disk, bound when the first turn flushes the JSONL). Both phases coexist on a live row after URL capture; the manager wire emits the bridge form when set, falling back to the JSONL basename in the pre-URL-capture window. The resolver routes either phase to the same row, so callers never need to choose. | `sessionId` (collapsed from the earlier three-field surface (see Task 141) `sessionId` + `claudeSessionId` + `bridgeSessionId`) | `sessionId=` |
+| `sessionId` | Claude's session. Two phases: bridge suffix (`session_xxx`, the URL segment in `claude.ai/code/<session_xxx>`, set when claude prints the `/remote-control` URL) and JSONL basename UUID (claude's intrinsic id on disk, bound when the first turn flushes the JSONL). Both phases coexist on a live row after URL capture; the manager wire emits the bridge form when set, falling back to the JSONL basename in the pre-URL-capture window. The resolver routes either phase to the same row, so callers never need to choose. | `sessionId` (collapsed from the earlier three-field surface `sessionId` + `claudeSessionId` + `bridgeSessionId`) | `sessionId=` |
 | `accountId` | Account / workspace UUID. For the admin channel, the value the manager carries as `senderId` IS the accountId; for non-admin channels the same wire field carries a phone / email / chat-id (the channel-level sender), so its log key on those paths is still `senderId=`. | `senderId` (channel-agnostic) | `accountId=` in admin-flow emit sites; `senderId=` in channel-bridge sites |
 
-## Memory MCP write-path outcome lines (Task 166)
+## Memory MCP write-path outcome lines
 
 Every write-path tool in the memory plugin MCP emits one structured line per invocation to `server.log` via the loopback `/api/admin/log-ingest` route. The operator can answer "did this write succeed?" from a single greppable surface — no need to cross-reference the per-process `mcp-memory-stderr-<date>.log`.
 
@@ -111,7 +111,7 @@ Line shapes:
 
 Enumerated `reason` slugs (failure path): `invalid-input | schema-unknown-label | schema-property-naming | account-isolation | producedby-task-not-found | constraint-violation | conflicting-element-id | invalid-target-node-id | gate-blocked | neo4j-driver-error`. Free-form error text remains in the `detail` field. New slugs are added only by amending the helper's union type; nothing silently falls through to a generic `unknown`.
 
-Wired tools: `memory-write`, `memory-update`, `memory-delete`, `memory-restore`, `memory-empty-trash`, `memory-archive-write`, `memory-ingest`, `memory-ingest-extract`, `memory-ingest-web`, `memory-reindex`, `memory-edit-attachment`, `memory-rename-attachment`, `profile-update`, `profile-delete`, `graph-prune-denylist-add`, `graph-prune-denylist-remove`, `conversation-archive-derive-insights`, `conversation-archive-enrich-rejection`, `conversation-memory-expunge`. Read-path tools (`memory-search`, etc.) are intentionally out of scope — reads do not change state and their failures already reach the caller. (Task 424 removed `memory-rank` and `memory-classify`.)
+Wired tools: `memory-write`, `memory-update`, `memory-delete`, `memory-restore`, `memory-empty-trash`, `memory-archive-write`, `memory-ingest`, `memory-ingest-extract`, `memory-ingest-web`, `memory-reindex`, `memory-edit-attachment`, `memory-rename-attachment`, `profile-update`, `profile-delete`, `graph-prune-denylist-add`, `graph-prune-denylist-remove`, `conversation-archive-derive-insights`, `conversation-archive-enrich-rejection`, `conversation-memory-expunge`. Read-path tools (`memory-search`, etc.) are intentionally out of scope — reads do not change state and their failures already reach the caller. (`memory-rank` and `memory-classify` were removed.)
 
 Diagnostic grep:
 
@@ -130,9 +130,9 @@ grep '\[mcp:memory\] log-ingest-failed' ~/.${brand}/logs/mcp-memory-stderr-*.log
 
 The existing `mcp-memory-stderr-<date>.log` capture is unchanged on error paths — the new structured line is additive, not a relocation. Crash-mode debugging continues to read the stderr log; routine "did it land?" questions read `server.log`.
 
-**Test contract (Task 168).** Each of the 20 wired tools carries a `*-emit.test.ts` fixture under `platform/plugins/memory/mcp/src/tools/__tests__/` that mocks `fetch` and asserts the wire body. A refactor that drops `withWriteEvent` from any tool fails the matching tool's tests with a clear `expected "vi.fn()" to be called 1 times, but got 0 times` error, naming the tool. A shared helper at `__tests__/_helpers/emit-capture.ts` standardises the fetch capture + Neo4j Session stub so each tool test stays a few lines of mocks + one happy + one error assertion. Drift between the helper's body shape and the route's validator is pinned by an end-to-end test at `platform/ui/server/routes/admin/__tests__/log-ingest-mcp-end-to-end.test.ts`, which routes the helper's POST through the real Hono `log-ingest` route with a loopback `remoteAddress` shim.
+**Test contract.** Each of the 20 wired tools carries a `*-emit.test.ts` fixture under `platform/plugins/memory/mcp/src/tools/__tests__/` that mocks `fetch` and asserts the wire body. A refactor that drops `withWriteEvent` from any tool fails the matching tool's tests with a clear `expected "vi.fn()" to be called 1 times, but got 0 times` error, naming the tool. A shared helper at `__tests__/_helpers/emit-capture.ts` standardises the fetch capture + Neo4j Session stub so each tool test stays a few lines of mocks + one happy + one error assertion. Drift between the helper's body shape and the route's validator is pinned by an end-to-end test at `platform/ui/server/routes/admin/__tests__/log-ingest-mcp-end-to-end.test.ts`, which routes the helper's POST through the real Hono `log-ingest` route with a loopback `remoteAddress` shim.
 
-## Diagnosing missing tools in production (Task 183)
+## Diagnosing missing tools in production
 
 When a database-operator spawn fails to call any of its 11 tools, the question is which of two layers dropped them:
 
@@ -147,13 +147,13 @@ Three log-line shapes, all keyed on the same database-operator `sessionId`, dist
 [recorder-turn]            sessionId=<id> turnIndex=<n> stopReason=<r> textBytes=<n> text=<full json-escaped> toolUseNames=<csv|—> containsToolCallText=true|false
 ```
 
-- `[pty-spawn-tool-inventory]` (Task 178) measures the **framework** layer — the argv built and the MCP servers' published tools. Argv-tools count must be 11; mcp-listed-tools must be ≥ 11.
-- `[recorder-session-init]` (Task 183 — emitted by the JSONL tail in `claude-session-manager`) measures the **CLI/SDK** layer — what the SDK actually exposed to the model. The `source=` field names the data path; `toolsArgvMissingFromExposed` is the Outcome A fingerprint:
+- `[pty-spawn-tool-inventory]` measures the **framework** layer — the argv built and the MCP servers' published tools. Argv-tools count must be 11; mcp-listed-tools must be ≥ 11.
+- `[recorder-session-init]` (emitted by the JSONL tail in `claude-session-manager`) measures the **CLI/SDK** layer — what the SDK actually exposed to the model. The `source=` field names the data path; `toolsArgvMissingFromExposed` is the Outcome A fingerprint:
   - `source=system.init` / `command_permissions` / `deferred_tools_delta` ⇒ the SDK wrote an init record to the JSONL and the tail matched one of the three known shapes. The bridge-attached `--remote-control` mode writes `attachment.deferred_tools_delta`; the headless SDK init record (`system.subtype=init`) is what `claude -p --output-format=stream-json` modes write.
-  - `source=headless-argv-fallback` ⇒ Task 185 finding (2026-05-20): headless `claude --verbose` PTY mode (which headless database-operator spawns use) does **not** write any tool-list record to the JSONL — none of the three probe shapes ever appears. The tail falls back to the spawner's `--allowed-tools` argv as the exposed set, independently verified by `[pty-spawn-tool-inventory]`'s `exposed=` field. Treat this source identically to a positive JSONL match: the argv set is authoritative for headless spawns.
+  - `source=headless-argv-fallback` ⇒ a finding (2026-05-20): headless `claude --verbose` PTY mode (which headless database-operator spawns use) does **not** write any tool-list record to the JSONL — none of the three probe shapes ever appears. The tail falls back to the spawner's `--allowed-tools` argv as the exposed set, independently verified by `[pty-spawn-tool-inventory]`'s `exposed=` field. Treat this source identically to a positive JSONL match: the argv set is authoritative for headless spawns.
   - `toolsArgvMissingFromExposed=—` ⇒ all argv tools made it through; Outcome A is ruled out.
   - Any non-`—` value enumerates the names the SDK dropped and is the diagnosis. Only meaningful when `source` is JSONL-derived; under `headless-argv-fallback` the exposed set equals argv by construction, so this field is always `—`.
-- `[recorder-turn]` measures the **model** layer — Haiku's verbatim words (Task 213: full `text=`, not the prior 240-char `textHead`) and the tool names it actually called (`toolUseNames`). `toolUseNames=—` paired with `toolsArgvMissingFromExposed=—` is the Outcome B signature: tools present, model abstained. `containsToolCallText=true` flags any assistant text that contains `<tool_call>`, `<function_calls>`, or `</invoke>` — the recorder model copying the tool-call shape into prose (the regression Task 213 closed).
+- `[recorder-turn]` measures the **model** layer — Haiku's verbatim words (full `text=`, not the prior 240-char `textHead`) and the tool names it actually called (`toolUseNames`). `toolUseNames=—` paired with `toolsArgvMissingFromExposed=—` is the Outcome B signature: tools present, model abstained. `containsToolCallText=true` flags any assistant text that contains `<tool_call>`, `<function_calls>`, or `</invoke>` — the recorder model copying the tool-call shape into prose (the regression that was closed).
 
 The three lines are emitted into `server.log` via the platform UI's `/api/admin/log-ingest` loopback route, so a single grep against `server.log` answers the question for any past, present, or future recorder spawn:
 
@@ -166,7 +166,7 @@ grep -E "\[(pty-spawn-tool-inventory|recorder-session-init|recorder-turn|mcp:(me
 
 1. The single `[pty-spawn-tool-inventory]` line proves what the framework provisioned. If `argv-tools < 11`, the bug is upstream of this evidence chain — the agent file or the spawn site.
 2. The single `[recorder-session-init]` line proves what the model received. If `toolsArgvMissingFromExposed` is non-`—`, the named tools were dropped by the CLI/SDK; that is Outcome A and the fix lives in the `--mcp-config` resolution or the CLI/SDK handshake.
-3. Each `[recorder-turn]` line records one assistant turn. If `toolUseNames=—` across every turn AND `toolsArgvMissingFromExposed=—`, the model could call the tools and chose not to; `text=` carries the model's verbatim reasoning (Task 213 dropped the 240-char head cap so the whole turn is observable from server.log) and is the next surface to read. A `containsToolCallText=true` row is the recorder-relapse signature: the model emitted tool-call shape as prose instead of a real `tool_use` block.
+3. Each `[recorder-turn]` line records one assistant turn. If `toolUseNames=—` across every turn AND `toolsArgvMissingFromExposed=—`, the model could call the tools and chose not to; `text=` carries the model's verbatim reasoning (the 240-char head cap was dropped so the whole turn is observable from server.log) and is the next surface to read. A `containsToolCallText=true` row is the recorder-relapse signature: the model emitted tool-call shape as prose instead of a real `tool_use` block.
 
 **Loopback gate.** The `/api/admin/log-ingest` route is loopback-only on both the socket address and (when present) the `X-Forwarded-For` header. A LAN client whose request reaches the route via a proxy still gets a 403 because XFF tokens are required to be loopback when XFF is set. Without this gate the evidence chain would be worthless — any LAN client could forge `[recorder-session-init]` lines under a spoofed sessionId.