@rubytech/create-realagent-code 0.1.30 → 0.1.32

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

@@ -268,7 +268,7 @@ Invoke the agent with `[New session. Greet the visitor.]` and stream the respons
 
 ## Self-Contained Constraint
 
-Public agents run via the direct Anthropic API. They have no filesystem access, no MCP tools, no subagents. The only tool is `render-component` (single-select and multi-select). Everything the agent needs must be in its directory files. The platform assembles these into the system prompt at invocation time.
+Public agents run on the same native Claude Code PTY surface as the admin agent. They have no filesystem access, no MCP write tools, no subagents — every tool is on a read-only or otherwise public-safe allowlist that the manager passes to the spawn as `--allowed-tools`. Everything the agent needs to say must come from its directory files or from the public-safe tool surface. The platform assembles directory files into the system prompt at invocation time.
 
 ## URL Routing
 

package/payload/platform/plugins/admin/skills/stream-log-review/references/analysis-patterns.md

@@ -29,7 +29,7 @@ Tags identify the event type. Key tags:
 | `heartbeat` | Long-running session keepalive. |
 | `active` / `disabled` / `unchanged` | Plugin/tool status during init. |
 | `expanded` | Skill or slash command expanded. |
-| `render-component` / `browser-viewer` | UI component rendered in response. |
+| `browser-viewer` | VNC browser-viewer surface mounted on the chat. |
 
 ### Raw JSON lines
 
@@ -117,7 +117,7 @@ These indicate degraded behaviour or potential problems that didn't cause outrig
 |---------|--------------|
 | **Subagent dispatched** | `[subagent-start]` / `[agent-dispatch]` lines |
 | **Skill expanded** | `[expanded]` line |
-| **UI component rendered** | `[render-component]` / `[browser-viewer]` lines |
+| **VNC browser-viewer mounted** | `[browser-viewer]` lines |
 | **Session completed successfully** | `result` JSON with `is_error: false` |
 
 ## Diagnosis Heuristics

package/payload/platform/plugins/anthropic/skills/get-api-key/SKILL.md

@@ -15,9 +15,7 @@ Obtain an API key from the Anthropic Console (platform.claude.com) on behalf of
 
 ## Steps
 
-1. **Show the browser.** Call `render-component` with:
-   - `name: "browser-viewer"`
-   - `data: { title: "Anthropic Console" }`
+1. **Surface the VNC browser to the user.** Tell the user the Anthropic Console will appear in the VNC browser that is already mounted in the chat (no further tool call is needed; the chat surface mounts the VNC view automatically when a personal-assistant subagent is dispatched against `platform.claude.com`). If the VNC browser is not currently visible, ask the user to open the brand's VNC URL and confirm before proceeding.
 
 2. **Dispatch personal-assistant for sign-in check and billing assessment.** Use the Agent tool with `specialists:personal-assistant` as the subagent type. Brief:
 
@@ -124,7 +122,7 @@ Handle the result the same as step 7.
 
 ## Important
 
-- **`render-component` is required before any personal-assistant dispatch.** The browser-viewer component is what makes the VNC browser visible to the user. Without it, automation runs invisibly. Always call `render-component` with `name: "browser-viewer"` and confirm it renders before dispatching a personal-assistant subagent.
+- **Confirm the VNC browser is visible before dispatching the personal-assistant.** Without VNC mounted in the chat, automation runs invisibly and the user has no way to see what the specialist is doing. If the VNC view is missing, ask the user to open the brand's VNC URL in the chat and confirm it is showing the desktop before continuing.
 - **Credits before keys.** Never create an API key before confirming that credits are loaded on the account. A key created on a zero-balance account is permanently non-functional.
 - The browser is visible to the user via VNC. They can see everything the specialist does.
 - The user must sign in themselves — the specialist does not fill credentials.

package/payload/platform/plugins/cloudflare/scripts/setup-tunnel.sh

@@ -909,53 +909,6 @@ if [ "${SETUP_TUNNEL_DRY_RUN}" = "1" ]; then
   exit 0
 fi
 
-# --------------------------------------------------------------------------
-# Step 6: Persist onboarding step-7 completion BEFORE arming the restart.
-#
-# Task 562: the service restart below SIGTERMs the admin-agent subprocess
-# before it can call `onboarding-complete-step 7`. Persisting the completion
-# here — inside the shell script — removes the LLM from the decision path
-# and closes the race. Next session's `loadOnboardingStep` / `getOnboardingState`
-# reads the flag file and advances the graph via the same idempotent
-# CASE-WHEN-NULL cypher as `completeOnboardingStep`.
-#
-# ACCOUNT_DIR is exported by claude-agent.ts::buildSpawnEnv and inherited
-# by every Bash-tool subprocess. If it is unset, this script was invoked
-# outside an agent session (operator-initiated reconfig via SSH) — there
-# is no onboarding to persist, so skip loudly without error. No $PWD
-# fallback: the Bash-tool cwd can drift across invocations, and writing
-# the marker into a stray directory would silently detach it from any
-# reader.
-#
-# The flag payload is JSON so the next session's consumer can use the
-# real completion timestamp (not its own Date.now()) and cross-reference
-# by tunnelId during forensic investigations.
-# --------------------------------------------------------------------------
-
-if [ -n "${ACCOUNT_DIR:-}" ]; then
-  ONBOARDING_DIR="${ACCOUNT_DIR}/onboarding"
-  ONBOARDING_FLAG="${ONBOARDING_DIR}/step7-complete"
-  PERSIST_NOW="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
-  if ! mkdir -p "${ONBOARDING_DIR}" 2>/dev/null; then
-    phase_line setup-tunnel step=onboarding-persist result=error \
-      reason=fs-flag-dir-failed path="${ONBOARDING_DIR}"
-    echo "WARNING: could not create ${ONBOARDING_DIR} — step-7 completion not persisted." >&2
-    echo "         The next admin session will re-ask the Cloudflare question." >&2
-  elif ! printf '{"completedAt":"%s","tunnelId":"%s"}\n' "${PERSIST_NOW}" "${TUNNEL_ID}" \
-      > "${ONBOARDING_FLAG}" 2>/dev/null; then
-    phase_line setup-tunnel step=onboarding-persist result=error \
-      reason=fs-flag-write-failed path="${ONBOARDING_FLAG}"
-    echo "WARNING: could not write ${ONBOARDING_FLAG} — step-7 completion not persisted." >&2
-    echo "         The next admin session will re-ask the Cloudflare question." >&2
-  else
-    phase_line setup-tunnel step=onboarding-persist result=ok \
-      path="${ONBOARDING_FLAG}" completedAt="${PERSIST_NOW}"
-  fi
-else
-  phase_line setup-tunnel step=onboarding-persist result=skipped \
-    reason=no-account-dir
-fi
-
 # --------------------------------------------------------------------------
 # Restart the brand's user-space service so resume-tunnel.sh (its
 # ExecStartPre) picks up the new tunnel.state + config.yml and spawns the

package/payload/platform/plugins/docs/references/cloudflare.md

@@ -30,7 +30,6 @@ When you submit, the `/api/admin/cloudflare/setup` endpoint runs — in strict o
 - **Zone pre-flight** — for every non-apex hostname the script queries `1.1.1.1` for the registrable parent's NS records and refuses the whole run if they don't point at Cloudflare. Stream log: `step=zone-preflight result=ok|error zones_on_account=… missing_parent_for=…`. Catches "domain not on Cloudflare"; does not catch "domain on a different Cloudflare account than `cert.pem` is bound to" — that case surfaces later via `tunnel-status`.
 - `cloudflared tunnel route dns` for each subdomain hostname. Apex hostnames cannot be routed this way — the script prints an **ACTION REQUIRED** block naming the exact dashboard record to add or edit. Stream log emits `step=route-dns hostname=… tunnel_id=…` before the call and `step=route-dns hostname=… result=ok|apex-skip|error` after; on error the bounded cloudflared stderr (≤400 chars) rides in the same phase line. **The script does not parse cloudflared's stdout** — exit code is the sole decision signal, so all three legitimate cloudflared output shapes (new record, overwrite, idempotent "already configured") are treated as success.
 - `config.yml` and `tunnel.state` written under `${CFG_DIR}`.
-- **Step-7 onboarding completion persisted** — the script writes `${ACCOUNT_DIR}/onboarding/step7-complete` (a JSON marker with the completion timestamp and tunnel ID) before arming the restart. Stream log: `step=onboarding-persist result=ok|error reason=<r>`. The marker is consumed by the next admin session's first state read and advances `OnboardingState.currentStep` to 7. Without this, the service restart below would SIGTERM the admin agent before it could persist step-7 completion, and the next session would re-ask the Cloudflare question you just finished. Both invocation surfaces (the form-driven action and the agent-via-Bash path) declare `ACCOUNT_DIR` explicitly because `systemd-run --user` does not inherit parent env — when ACCOUNT_DIR isn't reaching the script you'll see `result=skipped reason=no-account-dir` in the stream log instead of `result=ok`.
 - **Post-restart resume contract** — when the script exits cleanly, the form fires a client-side resume event. The chat hook ([useAdminChat.ts](../../../../platform/ui/app/useAdminChat.ts)) waits for the brand-service to come back via `/api/health` (down-then-up), re-binds the conversation to the new server process, and sends the "Cloudflare setup completed" marker as a normal hidden chat POST that re-invokes the agent in a fresh session. No relay queue, no boot-drain, no banner. Diagnostic: `grep '\[admin-resume\] reason=post-restart' ~/{configDir}/logs/server.log` (expect one line per restart cycle), `grep '\[client-event\] kind=post-restart-resume' ~/{configDir}/logs/server.log` for the operator-visible client trace. See `.docs/web-chat.md` "Post-restart resume contract" for the full client/server contract.
 - `systemctl --user restart ${BRAND}.service` — restarts the platform service so the new tunnel spawns via the service's `ExecStartPre=resume-tunnel.sh`.
 - Post-restart verification — `ps -ef | grep '[c]loudflared'` confirms the connector is alive, then `curl -I https://<hostname>` against each subdomain (up to 60 s per host) confirms a non-530 response.

package/payload/platform/plugins/docs/references/deployment.md

@@ -39,29 +39,20 @@ This installs all dependencies (Node.js, Neo4j, Cloudflare tunnel, Claude Code),
 6. Starts the {{productName}} web server on port 19200
 7. Configures systemd so everything restarts automatically if the Pi reboots
 
-## First admin session — onboarding handover
+## First admin session — install-time defaults
 
-After install, the first time you open the admin URL, {{productName}} walks you through a 9-step onboarding flow: plugin selection, output style, thinking-view, timezone, persona, Cloudflare, Anthropic API key, and the business-profile capture. The flow is gated on a single piece of Neo4j state, an `OnboardingState{accountId, currentStep}` node:
+There is no onboarding state machine. At install time the installer writes three defaults into `data/accounts/<accountId>/account.json` (`enabledPlugins` from the brand's default set, `outputStyle: "default"`, `thinkingView: "default"`) and stamps a minimal `agents/admin/SOUL.md`. Diagnostic lines on the Pi:
 
-- `seed-neo4j.sh` writes the node at install time with `currentStep=0`. The installer re-reads it before exiting; a missing node or an unreachable Neo4j fails the install loudly (`[install-invariant] onboarding-state-MISSING` or `onboarding-state-UNREACHABLE`).
-- Every admin session-create reads `currentStep`. Anything below 9 keeps `onboarding_complete=false` on `/api/health` and `/api/admin/session`, and the chat opens on the next step's component (multi-select, dropdown, etc.).
-- Every freshly-spawned admin claude session ships the `<onboarding-state currentStep="N">` directive as a third sentinel-wrapped section in `--append-system-prompt` (alongside `<host>` and `<attachment-ceiling>`). The agent's first turn calls `skill-load skillName=onboarding`. Resumed sessions skip the section so the agent doesn't re-ask the same step. (Task 043 — pre-fix the directive was prepended to the first user message; the Claude CLI's Ink TextInput interpreted each `\n` in the block as Enter, dropping the directive bytes before they reached the agent. The system prompt is the only multi-line-safe surface for PTY-spawned Claude Code.)
-- If Neo4j is unreachable at session-create, the section becomes a loud-fail block (`graphUnreachable="true"`) and `onboarding_complete` is reported false — never silently skipped.
-
-Diagnostic command on the Pi (substitute the brand's Neo4j port from `~/.maxy/.env` or `~/.realagent/.env`):
-
-```bash
-cypher-shell -a bolt://localhost:<brand-neo4j-port> \
-  "MATCH (o:OnboardingState) RETURN o.accountId, o.currentStep"
 ```
+[install-defaults] account-json plugins=<n> outputStyle=default thinkingView=default
+[install-defaults] soul-md path=<path>
+```
+
+Grep for both in `~/.<brand>/logs/install-*.log`. Absence after a clean install is the failure signal.
 
-Failure signals to grep in `~/.maxy/logs/server.log` (or `~/.realagent/logs/server.log`):
+The first user-domain write the agent attempts (e.g. recording who the operator is) hits the graph-write gate's `Write blocked (no-admin-user)` or `Write blocked (no-local-business)` error. The agent then asks the persona question, persists the answer through the `business-profile` skill or `profile-update.personFields`, and proceeds. The error itself is the signal — grep `Write blocked` in `~/.<brand>/logs/server.log` to confirm.
 
-- missing `[onboarding-seed]` line in install output
-- `[install-invariant] onboarding-state-MISSING`
-- `[onboarding-gate] step=null complete=true` (the pre-Task-033 bug)
-- missing `[skill-load] name=onboarding` while `[onboarding-gate]` reports `complete=false`
-- missing `[onboarding-prompt] step=<n|missing|graph-unreachable> bytes=<n>` for a fresh spawn whose `[pty-spawn] appendSystemPromptBytes=` is at the bare 622-byte host + ceiling size (Task 043 — the onboarding directive failed to ship in the system prompt)
+Cloudflare, WhatsApp, Telegram, and any other dormant capability surfaces on owner request via the `<dormant-plugins>` rule in `platform/templates/agents/admin/IDENTITY.md`. Execution is the existing plugin skill (`cloudflare:setup-tunnel`, etc.) — no banner, no per-step flag.
 
 ## Service Management
 

package/payload/platform/plugins/docs/references/internals.md

@@ -356,7 +356,7 @@ The server-side code in `claude-agent.ts` builds the system prompt before making
 - Agent sees both: curated knowledge file + fresh graph results
 
 **Path 3 — Memory-search only** (`knowledgeBaked: false`):
-- No KNOWLEDGE.md exists (e.g., before onboarding completes)
+- No KNOWLEDGE.md exists (e.g., on a fresh install before the operator has had any conversations)
 - Classifier decides whether to search (or falls back to always-search)
 - Results injected as `<memory>...</memory>`
 
@@ -454,7 +454,7 @@ The SDK's per-tool override is `_meta["anthropic/alwaysLoad"]: true` on each MCP
 1. **In-process plugins.** Every admin-eager tool is registered via `eagerTool(server, name, description, inputSchema, handler)` from `platform/lib/mcp-eager/` instead of `server.tool(...)`. The helper calls `server.registerTool` with the `_meta` flag set.
 2. **Upstream graph proxy.** The upstream Python `mcp-neo4j-cypher` server has no `_meta` channel, so `platform/lib/graph-mcp/src/index.ts` intercepts every `tools/list` response on the wire and injects `_meta["anthropic/alwaysLoad"]: true` into each tool entry. The `[graph-mcp] tools/list eager-flagged count=<N>` stderr line confirms the injection fired.
 
-**Curation rule.** Every MCP tool the admin agent calls routinely should be eager. The migrated set is `ADMIN_CORE_TOOLS` in `platform/ui/app/lib/claude-agent/spawn-env.ts` — when a tool sits on that list it must be registered via `eagerTool` (or arrive through the graph-mcp interceptor). Admin-skill / specialist / public-agent tools that are NOT in `ADMIN_CORE_TOOLS` stay on `server.tool()` today; they pay the ToolSearch tax only when their caller invokes them. The allow-list is the source of truth for the eager set, not necessarily the complete set of tools admin can ever call — skills that route into Bash + plugin-toggle / agent-config / onboarding tools are an existing gap to widen the allow-list against, separately from the eager-load mechanism.
+**Curation rule.** Every MCP tool the admin agent calls routinely should be eager. The migrated set is `ADMIN_CORE_TOOLS` in `platform/ui/app/lib/claude-agent/spawn-env.ts` — when a tool sits on that list it must be registered via `eagerTool` (or arrive through the graph-mcp interceptor). Admin-skill / specialist / public-agent tools that are NOT in `ADMIN_CORE_TOOLS` stay on `server.tool()` today; they pay the ToolSearch tax only when their caller invokes them. The allow-list is the source of truth for the eager set, not necessarily the complete set of tools admin can ever call — skills that route into Bash + plugin-toggle / agent-config tools are an existing gap to widen the allow-list against, separately from the eager-load mechanism.
 
 **Observability.** Spawn-time emit: `[tool-surface] session=<convId> permission_allowed=N eager_intent=E eager_set_size=T`. Turn-end emit: `[admin-agent] turn-end ... toolsearch=N toolsearch_unique=U`. A non-zero `toolsearch` on a fresh turn for an eager-intended tool means a plugin reverted to `server.tool()` — fix at the plugin's MCP registration site, not the allow-list.
 
@@ -489,7 +489,7 @@ Each log entry includes the tool name and a truncated conversation ID for correl
 
 ## Process provenance — durable actions emit Tasks
 
-Every durable action — onboarding, cloudflare tunnel-login, brand publish, future deterministic flows — emits a `:Task {kind:"<flow>"}` node carrying the action's lifecycle and a `:PRODUCED` edge to every entity the action created. This makes the graph traversable from the originating Conversation to every entity created during it via `(c)<-[:RAISED_DURING]-(t:Task)-[:PRODUCED]->(e)` — answering "what did this turn produce" in one Cypher hop.
+Every durable action — cloudflare tunnel-login, brand publish, future deterministic flows — emits a `:Task {kind:"<flow>"}` node carrying the action's lifecycle and a `:PRODUCED` edge to every entity the action created. This makes the graph traversable from the originating Conversation to every entity created during it via `(c)<-[:RAISED_DURING]-(t:Task)-[:PRODUCED]->(e)` — answering "what did this turn produce" in one Cypher hop.
 
 The doctrine is enforced at the storage primitive: writes to `:Person`, `:UserProfile`, `:AdminUser`, `:Organization`, `:LocalBusiness`, `:CloudflareTunnel`, or `:CloudflareHostname` MUST include at least one inbound `:PRODUCED` edge whose source is one of `:Task`, `:Conversation`, or `:Message`. Subtype labels like `:AdminConversation`, `:UserMessage`, `:AssistantMessage`, `:AdminMessage` qualify because the gate checks the full `labels()` array. Bootstrap writes (PIN-setup, schema migrations, lazy first-session UserProfile creation) are exempt via `createdBy.agent === 'system'`.
 
@@ -499,7 +499,7 @@ Two surfaces feed the gate. (1) **Workflow path:** `memory-write` accepts an opt
 
 Operator audit cyphers:
 - "What entities did this conversation's actions produce?" — `MATCH (c:AdminConversation {conversationId:$id})<-[:RAISED_DURING]-(t:Task)-[:PRODUCED]->(e) RETURN labels(e), e.name, t.kind, t.status`
-- "What cloudflare resources did this onboarding produce?" — `MATCH (t:Task {kind:'cloudflare-tunnel-login', status:'completed'})-[:PRODUCED]->(r) RETURN t.taskId, r.tunnelId, r.hostnameValue ORDER BY t.completedAt DESC`
+- "What cloudflare resources did this tunnel-login produce?" — `MATCH (t:Task {kind:'cloudflare-tunnel-login', status:'completed'})-[:PRODUCED]->(r) RETURN t.taskId, r.tunnelId, r.hostnameValue ORDER BY t.completedAt DESC`
 
 See `.docs/neo4j.md § Process provenance doctrine` for the full enforcement contract, observability surface, and out-of-scope deferrals.
 

package/payload/platform/plugins/docs/references/platform.md

@@ -69,7 +69,11 @@ The admin interface is a three-pane layout: a sidebar on the left with your bran
 
 Page titles are brand-aware: the browser tab shows your product name (e.g. `Real Agent` instead of `Maxy`) on every shell — chat, graph, and data — so a non-default brand never leaks the default name in tab strips or browser history.
 
-**Sidebar sessions list — 3s poll contract.** The sidebar Sessions list and the ConversationsModal share one fetch loop (`useAdminSessions`). It hits `/api/admin/claude-sessions` every 3s while the operator is signed in, but the poll path is render-quiet: `setLoading` is not toggled, and the sessions array is only re-committed when the projection `{ sessionId, displayName, lastMessageAt, status }` actually changes. Byte-identical responses do nothing visible to React. Each tick emits exactly one diagnostic line: `[admin-ui] sessions-poll outcome=<unchanged|changed|error> count=<n> cacheKey=<8>` (in the browser DevTools console; mirrored to `~/.maxy/logs/admin-ui-console.log` where the operator forwards them). The explicit operator-initiated paths — first load (`ensureLoaded`) and post-action `refetch()` (after spawn / delete) — still toggle `loading` so consumers can show a spinner. The 3s manager-truth reconciliation is unchanged; only the React-side noise was removed.
+**Session lifecycle and reconcile model.** The sidebar Sessions list and the ConversationsModal share one fetch loop (`useAdminSessions`). Every fetch is operator-triggered: first load on mount (`ensureLoaded`), the refresh button on the sessions group head, and a single `refetch` appended to every mutation in `session-actions` (resume, end, purge, archive, unarchive). There is no idle ticker; the UI does not call `/api/admin/claude-sessions` between operator actions, so the DevTools console stays quiet while you are not clicking anything. Each fetch emits exactly one line: `[admin-ui] sessions-poll outcome=<unchanged|changed|error> count=<n> cacheKey=<8>`. The format is held from the prior polling shape so existing log greps still match; the rate just drops to one per user action. Byte-identical responses skip the `setSessions` commit (projection-equality gate) so AdminShell does not re-render when the list has not changed.
+
+The trade-off is staleness for PTY exits that happen outside this UI: a Claude Code crash, an `ssh` kill of the brand process, or a sibling tab spawning a new session stays invisible in the current tab until you click the refresh button or perform another mutation. Two open tabs can show different lists until both refresh. The accepted view is that every lifecycle event in this dashboard originates from a click in this dashboard, so a missing ticker cannot deliver information the operator did not already cause.
+
+The metadata pane subscribes to the same /list projection. When an operator clicks End on an alive row, the DELETE returns 200 and the post-mutation refetch decides what happens next: a session that wrote a JSONL surfaces as a dehydrated `status: 'ended'` row (the pane swaps `End session` for `Purge JSONL` plus `Resume`), and a session that never wrote a JSONL (`Turns: 0`) leaves the list entirely (the pane shows a `Session ended without a transcript. Close this pane.` banner with a Close button and no destructive action). The manager's `/list` and `/meta` are the only authorities on post-End state; the client does not pre-empt either response with an optimistic mutation.
 
 The Data search panel ranks results by combining vector similarity with keyword (BM25) matching. Each row shows a one-line score breakdown — `vector 0.NN · bm25 0.NN · combined 0.NN` — so you can tell whether a row surfaced because of meaning, exact-keyword match, or both. A bm25 column of `0.00` across every row means your search term wasn't in the keyword index, so ranking fell back to pure vector similarity (this can produce surprising results — the breakdown tells you when to interpret with caution). Above the result list, a chip row shows the unique types in your current results — click one to filter, click again to clear. Click any row to jump straight to that node's neighbourhood in the Graph; from the artefact pane the graph opens alongside chat, from the standalone Data page it opens in place.
 

package/payload/platform/plugins/docs/references/troubleshooting.md

@@ -531,14 +531,18 @@ sudo systemctl --user start maxy-ui
 
 **A chat turn looks broken — assistant bubble never rendered:** Open `claude-agent-stream-<sessionKey>.log` and grep for `[sse-client]`. The five phases (`connected`, `event_received`, `render_complete`, `error`, `close`) tell the story in order. Missing `connected` = the chat fetch never returned 200; missing `event_received` = the server emitted nothing or the client lost the stream before the first frame; missing `render_complete` = the reducer never committed the assistant bubble (persist_ack never arrived). The operator can also click "Report this turn" in the chat menu to append a `[failure-report]` line carrying the same sessionKey + conversationId + clientSnapshot, plus copy the payload to the clipboard.
 
-## Admin DevTools console floods with `onboarding-banner-mount` or unsorted `sessions-poll` lines
+## Admin DevTools console floods with `onboarding-banner-mount` or `sessions-poll` lines
 
-**Symptom:** Open DevTools on the admin shell at `/` with `onboardingComplete=false`, leave the page idle for a minute or two, then scroll back through the console. Pre-Task-050 you would see thousands of `[admin-ui] onboarding-banner-mount onboardingComplete=false` lines (one per AdminShell render — roughly 40/min from the 3s sessions poll alone) and no per-tick poll telemetry at all.
+**Symptom (pre-Task-050).** Open DevTools on the admin shell at `/` with `onboardingComplete=false`, leave the page idle for a minute, then scroll back through the console. You would see thousands of `[admin-ui] onboarding-banner-mount onboardingComplete=false` lines (one per AdminShell render, roughly 40/min driven by the 3s sessions poll) and no per-tick poll telemetry at all.
 
-**Post-Task-050 invariants (steady-state idle at `/`):**
+**Steady-state invariants at `/` (post-Task-067):**
 
-- `grep -c '\[admin-ui\] onboarding-banner-mount' ~/.maxy/logs/admin-ui-console.log` equals page-load count plus onboarding-flip count, not the render count. Sustained climb at idle ⇒ the banner mount log regressed back into the render body.
-- `grep -c '\[admin-ui\] sessions-poll' ~/.maxy/logs/admin-ui-console.log` grows ~20/min (one per 3s tick) and `outcome=unchanged` dominates `outcome=changed` once the cache is warm. `outcome=changed` every idle tick ⇒ the `useAdminSessions` projection (`sessionId / displayName / lastMessageAt / status`) is missing a field that is churning on every fetch, or a downstream component is mutating the response in place before comparison.
-- `outcome=error` lines name a real fetch failure — they do NOT update sidebar state and do NOT set the `error` field (the operator-initiated `refetch()` still owns that channel).
+- `grep -c '\[admin-ui\] onboarding-banner-mount' ~/.maxy/logs/admin-ui-console.log` equals page-load count plus onboarding-flip count, not the render count. Sustained climb at idle means the banner mount log regressed back into the render body (Task 050 fix).
+- `grep -c '\[admin-ui\] sessions-poll' ~/.maxy/logs/admin-ui-console.log` over a 60-minute idle window equals zero. The hook no longer installs a `setInterval`; every `sessions-poll` line is operator-triggered (initial mount, refresh button, post-mutation refetch). One or more lines during operator idle means `setInterval` was reinstated.
+- `outcome=error` lines name a real fetch failure on an operator-triggered refetch, set the `error` field, and surface in the sidebar.
 
-**Why this matters.** The render-body log was misleading: it read as "the admin agent is checking onboarding state continuously", when in fact `onboardingComplete` had not changed at all — it was just the sessions poll re-rendering AdminShell twice per tick. With the structured poll line in place, the console is a faithful record of what the page actually did each tick.
+**Reconcile signal (Task 067):**
+
+- `grep -c '\[admin-ui\] sidebar-meta-pane-reconcile' ~/.maxy/logs/admin-ui-console.log` should equal the count of End / Resume / Purge clicks while the metadata pane was open. A `to=gone` line without a paired Close click means the pane's auto-close logic regressed.
+
+**Why this matters.** The render-body log was misleading: it read as "the admin agent is checking onboarding state continuously", when in fact `onboardingComplete` had not changed at all. The Task 050 fix moved the log into `useEffect(…, [])`; Task 067 then dropped the per-tick poll entirely, so a quiet console is now the steady state. With both fixes in place, console output is a faithful record of what the page actually did each operator click.

package/payload/platform/plugins/email/references/email-reference.md

@@ -4,9 +4,7 @@ Full reference for the email plugin. Load with `plugin-read` when detailed confi
 
 ## Setup
 
-Collect email credentials via a form. Render this `form` component with `render-component`:
-
-**Fields:**
+Collect email credentials in plain chat, one field at a time or as a numbered checklist the operator fills in:
 
 | name | label | type | required | placeholder |
 |------|-------|------|----------|-------------|
@@ -22,7 +20,7 @@ Collect email credentials via a form. Render this `form` component with `render-
 
 The `agentAddress` field is for catchall/alias setups where the authentication email differs from the address the agent operates as. Leave empty when they're the same.
 
-After form submission, pass all fields to `email-setup`. On success, confirm "credentials stored" and the inbox count. On failure, relay the diagnostic — the tool returns specific guidance (wrong password, connection refused, TLS mismatch).
+After the operator confirms all values, pass them to `email-setup`. On success, confirm "credentials stored" and the inbox count. On failure, relay the diagnostic — the tool returns specific guidance (wrong password, connection refused, TLS mismatch).
 
 The agent never displays stored passwords. Never name or recommend specific email providers — the form collects the standard fields every provider gives its users.
 
@@ -154,9 +152,7 @@ When enabled, a public agent replies to incoming emails. The auto-respond binary
 
 ### Setup
 
-To enable auto-respond, call `email-auto-respond-config` with `enabled: true`. The tool requires an `agentSlug` — render a `single-select` component with available public agents so the admin can choose which agent handles responses. The tool returns the agent list when called without a slug.
-
-When called without an `agentSlug`, the tool returns available agents. Present these as a `single-select` component for the admin to choose from, then call the tool again with the selected slug.
+To enable auto-respond, call `email-auto-respond-config` with `enabled: true`. The tool requires an `agentSlug`. When called without a slug, the tool returns available public agents — present these as a numbered list in plain chat so the admin can choose which agent handles responses, then call the tool again with the selected slug.
 
 ### Configuration
 

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

@@ -118,7 +118,7 @@ Graph hygiene is **agent-directed, case by case** — no autonomous rule engine,
 
 **Single-node removal.** Use `memory-delete` by `elementId`. The node is marked `:Trashed` (relationships preserved, invisible to `memory-search` and any read filtered via `notTrashed`). For `KnowledgeDocument`, the trash cascades to linked `Section` and `Chunk` children. Restore via `memory-restore` (fails loudly when an active node already holds a unique slot the trashed one needs back). Hard removal happens later via `memory-empty-trash` after the grace period (default 30 days). GDPR cascades go through `contact-erase` (per Art. 17) — that bypasses the trash primitive deliberately. There is no bulk delete-by-shape.
 
-**Why soft-delete.** On 2026-04-20 an autonomous orphan-delete rule wiped the sole `OnboardingState` node plus 18 unrelated nodes in one `graph-prune-run` call; properties were unrecoverable (Neo4j Community has no PITR, no APOC). The cron, the `graph-prune-run` tool, and the rule engine have been removed. An earlier fix added the `:Trashed` label primitive so every soft-delete caller (`memory-delete`, `contact-delete`, the admin `/graph` page's trash button) runs the same shared `trashNode` helper — relationships preserved, unique keys snapshotted into `_trashedKeys`, audit lines `[trash:marked] by=<surface>` for cross-cut provenance.
+**Why soft-delete.** On 2026-04-20 an autonomous orphan-delete rule wiped 19 nodes in one `graph-prune-run` call; properties were unrecoverable (Neo4j Community has no PITR, no APOC). The cron, the `graph-prune-run` tool, and the rule engine have been removed. An earlier fix added the `:Trashed` label primitive so every soft-delete caller (`memory-delete`, `contact-delete`, the admin `/graph` page's trash button) runs the same shared `trashNode` helper — relationships preserved, unique keys snapshotted into `_trashedKeys`, audit lines `[trash:marked] by=<surface>` for cross-cut provenance.
 
 ## Conversational Memory
 

package/payload/platform/plugins/memory/mcp/dist/index.js

@@ -1087,7 +1087,7 @@ if (!readOnly) {
     server.tool("memory-restore", "Undo memory-delete on a single graph node by elementId. Removes the :Trashed label and restores " +
         "snapshotted unique-key properties. For KnowledgeDocument, walks HAS_SECTION/HAS_CHUNK edges to bring " +
         "trashed children back too. Fails loudly when an active node already holds a unique slot the trashed " +
-        "node needs back (e.g. a fresh OnboardingState was created while the old one was in trash) — " +
+        "node needs back (e.g. a fresh LocalBusiness was created while the old one was in trash) — " +
         "the error names the conflicting elementId so the caller can decide how to resolve.", {
         elementId: z.string().describe("Neo4j elementId of the trashed node to restore."),
     }, async ({ elementId }) => {