@rubytech/create-realagent 1.0.825 → 1.0.828

package/payload/platform/plugins/admin/skills/stream-log-review/SKILL.md

@@ -10,7 +10,7 @@ description: >
 
 # Stream Log Review
 
-Analyse Claude agent stream logs — the `claude-agent-stream-{conversationId}.log` files generated by the platform (Task 532). Each file is scoped to exactly one conversation; a resumed conversation accumulates in one file across multiple process lifetimes, delimited by `[spawn]` / `[process-exit]`. Pre-conversation events (CDP auth-poll, module-init warnings) live in `preconversation-claude-agent-stream-{YYYY-MM-DD}.log` — a separate file per UTC day, read only when investigating boot-time failures.
+Analyse Claude agent stream logs — the `claude-agent-stream-{conversationId}.log` files generated by the platform. Each file is scoped to exactly one conversation; a resumed conversation accumulates in one file across multiple process lifetimes, delimited by `[spawn]` / `[process-exit]`. Pre-conversation events (CDP auth-poll, module-init warnings) live in `preconversation-claude-agent-stream-{YYYY-MM-DD}.log` — a separate file per UTC day, read only when investigating boot-time failures.
 
 Parse the log, identify problems, attempt diagnosis, and produce a structured report.
 
@@ -35,7 +35,7 @@ Parse the log, identify problems, attempt diagnosis, and produce a structured re
 On the Pi, use the `logs-read` MCP tool with `conversationId` to retrieve a single conversation's log. From the dev machine (SSH), use the shell counterpart:
 
 ```bash
-# Read a single conversation's stream log (primary mode — Task 532)
+# Read a single conversation's stream log (primary mode)
 sshpass -p 'password' ssh admin@<hostname>.local "~/<installDir>/platform/scripts/logs-read.sh <conversationId> system"
 
 # Tail the most-recently-active stream log (any conversation)
@@ -53,11 +53,11 @@ The `conversationId` is visible in the admin UI and appears on every `[spawn]` /
 - `[tool-wait-diag]` at 15 / 30 / 45 / 60 s — confirms DNS/TCP/HTTP health across a stall window (not just at the timeout moment).
 - `[tool-wait-proc]` at 30 s — subprocess open FDs, sockets by TCP state, RSS.
 - `[subproc-stderr]` — line from the main Claude Code subprocess's stderr. Today the CLI is a bundled Bun binary that ignores Node's `NODE_DEBUG`, so this channel is normally silent — see `[subproc-debug-unavailable]` below. MCP server stderr lines arrive separately as `[mcp:<server>]`.
-- `[subproc-stderr-tee-attached]` / `[subproc-stderr-tee-detached]` (Task 535) — lifecycle of the main-subprocess stderr tee. `bytes=0 lines=0` on detach means the tee worked but the subprocess emitted nothing. Absence of both markers next to a `[spawn]` means the tee infrastructure is broken — escalate.
-- `[subproc-debug-unavailable]` (Task 535) — one line per spawn, `reason=bundled-bun-binary-ignores-node-debug`. This is the documented reason `[subproc-stderr]` lines are normally absent for the main subprocess. Treat its absence as a regression, not its presence as a problem.
-- `[tool-failure-diag]` — one-shot probe on the failure path (Task 530); complements the mid-flight `[tool-wait-diag]` with end-of-wait network state.
+- `[subproc-stderr-tee-attached]` / `[subproc-stderr-tee-detached]` — lifecycle of the main-subprocess stderr tee. `bytes=0 lines=0` on detach means the tee worked but the subprocess emitted nothing. Absence of both markers next to a `[spawn]` means the tee infrastructure is broken — escalate.
+- `[subproc-debug-unavailable]` — one line per spawn, `reason=bundled-bun-binary-ignores-node-debug`. This is the documented reason `[subproc-stderr]` lines are normally absent for the main subprocess. Treat its absence as a regression, not its presence as a problem.
+- `[tool-failure-diag]` — one-shot probe on the failure path; complements the mid-flight `[tool-wait-diag]` with end-of-wait network state.
 - `[mcp-tee-attach]` / `[mcp-tee-skip]` / `[mcp:<server>]` — MCP server stderr routed into the stream log; a missing attach marker explains missing server diagnostics.
-- `[tool-result] error=true output="WEBFETCH_CANNOT_READ_JS_SPA: …"` — a WebFetch dispatch was short-circuited by the SPA preflight hook (Task 536). The URL is a JS-SPA shell that WebFetch cannot extract content from. The agent should have responded to the user naming the failure and asking for a paste or screenshot; if instead an `[agent-dispatch]` (Playwright, research-assistant) follows immediately, the loud-failure guidance in IDENTITY.md did not land. The hook's per-invocation decision trail lives in `{accountDir}/logs/webfetch-preflight.log` (one `[webfetch-preflight] verdict=…` line per probe).
+- `[tool-result] error=true output="WEBFETCH_CANNOT_READ_JS_SPA: …"` — a WebFetch dispatch was short-circuited by the SPA preflight hook. The URL is a JS-SPA shell that WebFetch cannot extract content from. The agent should have responded to the user naming the failure and asking for a paste or screenshot; if instead an `[agent-dispatch]` (Playwright, research-assistant) follows immediately, the loud-failure guidance in IDENTITY.md did not land. The hook's per-invocation decision trail lives in `{accountDir}/logs/webfetch-preflight.log` (one `[webfetch-preflight] verdict=…` line per probe).
 
 ## Boundaries
 

package/payload/platform/plugins/admin/skills/unzip-attachment/references/safety.md

@@ -78,4 +78,4 @@ All of these are from `unzip` (InfoZIP) + `coreutils` — installed on every Pi
 
 ## Why this is a skill, not a tool
 
-Doctrine (Task 664 precedent): the admin agent has `Bash`; the security-critical code path is a sequence of shell commands whose determinism is enforced by the shell primitives themselves, not by LLM reasoning. Wrapping this in an MCP tool would add a translation layer without adding enforcement — and per [feedback_deterministic_means_remove_llm.md](../../../../../.claude/projects/-Users-neo-getmaxy/memory/feedback_deterministic_means_remove_llm.md), a tool wrapper is still LLM-mediated at the decision boundary. The shell script is the deterministic primitive; the skill tells the agent which primitive to invoke, in which order, against which argument.
+Doctrine: the admin agent has `Bash`; the security-critical code path is a sequence of shell commands whose determinism is enforced by the shell primitives themselves, not by LLM reasoning. Wrapping this in an MCP tool would add a translation layer without adding enforcement — a tool wrapper is still LLM-mediated at the decision boundary. The shell script is the deterministic primitive; the skill tells the agent which primitive to invoke, in which order, against which argument.

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

@@ -217,7 +217,7 @@ cloudflared --origincert "${CFG_DIR}/cert.pem" tunnel route dns --overwrite-dns
 2. Overwritten: `Added CNAME <hostname> which will route to this tunnel` (same shape as new; `--overwrite-dns` makes overwrite transparent)
 3. Idempotent no-op: `<timestamp> INF <hostname> is already configured to route to your tunnel tunnelID=<UUID>`
 
-Shape 3 is what a second clean run of setup-tunnel.sh against an already-configured hostname emits. Historically the shell script's stdout parser rejected this shape and exited 1 on the idempotent case (session `25674fe3`, Task 559 fix); the script now relies on cloudflared's exit code exclusively.
+Shape 3 is what a second clean run of setup-tunnel.sh against an already-configured hostname emits. Historically the shell script's stdout parser rejected this shape and exited 1 on the idempotent case; the script now relies on cloudflared's exit code exclusively.
 
 **If it fails with `zone not found`:** the hostname's parent domain isn't on this brand's Cloudflare account. Either add it in the dashboard (Websites → Add a site) and re-run, or sign into the account that already owns the domain.
 
@@ -325,14 +325,14 @@ You do **not** run `cloudflared` manually. The brand's existing user-space syste
 systemctl --user restart "${BRAND}.service"
 ```
 
-**Why the script dispatches the restart via `systemd-run` instead of a direct `systemctl restart` (Task 558):** when the admin agent invokes `setup-tunnel.sh` via the Bash tool, the script runs *inside* `${BRAND}.service`'s cgroup. A direct `systemctl --user restart ${BRAND}.service` from that cgroup tells systemd to SIGTERM the entire cgroup — the node server, the claude subprocess, the Bash child, and the script itself all die simultaneously. cgroup membership is inherited: `setsid`, `nohup`, `disown`, and `&` all stay in the caller's cgroup, and `systemd-run --scope` runs in the caller's scope. Only `systemd-run --user --unit=<name> --on-active=<N>s` creates a genuinely new transient unit with its own cgroup. The script uses that primitive to arm the restart a few seconds after its own exit:
+**Why the script dispatches the restart via `systemd-run` instead of a direct `systemctl restart`:** when the admin agent invokes `setup-tunnel.sh` via the Bash tool, the script runs *inside* `${BRAND}.service`'s cgroup. A direct `systemctl --user restart ${BRAND}.service` from that cgroup tells systemd to SIGTERM the entire cgroup — the node server, the claude subprocess, the Bash child, and the script itself all die simultaneously. cgroup membership is inherited: `setsid`, `nohup`, `disown`, and `&` all stay in the caller's cgroup, and `systemd-run --scope` runs in the caller's scope. Only `systemd-run --user --unit=<name> --on-active=<N>s` creates a genuinely new transient unit with its own cgroup. The script uses that primitive to arm the restart a few seconds after its own exit:
 
 ```
 systemd-run --user --unit=maxy-tunnel-restart-<nonce>.service --on-active=3s --collect \
   /bin/systemctl --user restart "${BRAND}.service"
 ```
 
-The script then emits `[script:setup-tunnel] step=service-restart-dispatched` and `step=service-restart-armed exit=0` in the per-conversation stream log so operators see exactly when the restart was scheduled, exits 0, and the transient timer fires from outside the service's cgroup — semantically identical to this manual runbook's `systemctl --user restart`. (The `script:` prefix is Task 605's chat-surface namespace — see `_stream-log.sh` header.)
+The script then emits `[script:setup-tunnel] step=service-restart-dispatched` and `step=service-restart-armed exit=0` in the per-conversation stream log so operators see exactly when the restart was scheduled, exits 0, and the transient timer fires from outside the service's cgroup — semantically identical to this manual runbook's `systemctl --user restart`. (The `script:` prefix is the chat-surface namespace — see `_stream-log.sh` header.)
 
 When walking through manually you do **not** need `systemd-run` — your SSH shell already lives in a separate user-scope cgroup (`user@<uid>.service`), so the direct `systemctl restart` does not kill the caller. The script's extra indirection only matters when the caller *is* the service being restarted.
 

package/payload/platform/plugins/cloudflare/skills/setup-tunnel/SKILL.md

@@ -20,9 +20,9 @@ Any Cloudflare action outside these four surfaces is a discipline violation —
 
 ## 1. Autonomous path — `setup-tunnel.sh`
 
-Use this when the operator wants Cloudflare set up (or re-set up) end-to-end on the device. The script handles OAuth login, tunnel creation, DNS routing for each subdomain, config.yml + tunnel.state, and dispatches the `${BRAND}.service` restart to a transient `systemd-run` unit (Task 558) — all in one invocation. The restart fires a few seconds after the script exits so the script does not kill its own cgroup when invoked via the Bash tool; the chat UI receives a `server_shutdown` SSE frame and reconnects automatically. Post-restart hostname verification is out of scope for the script (connector is not up when the script exits) — verify via the next admin turn or manually with `curl -I https://<hostname>`. Apex hostnames cannot be routed by the CLI; when one is passed, the script prints an `ACTION REQUIRED` block naming the exact dashboard record to edit.
+Use this when the operator wants Cloudflare set up (or re-set up) end-to-end on the device. The script handles OAuth login, tunnel creation, DNS routing for each subdomain, config.yml + tunnel.state, and dispatches the `${BRAND}.service` restart to a transient `systemd-run` unit — all in one invocation. The restart fires a few seconds after the script exits so the script does not kill its own cgroup when invoked via the Bash tool; the chat UI receives a `server_shutdown` SSE frame and reconnects automatically. Post-restart hostname verification is out of scope for the script (connector is not up when the script exits) — verify via the next admin turn or manually with `curl -I https://<hostname>`. Apex hostnames cannot be routed by the CLI; when one is passed, the script prints an `ACTION REQUIRED` block naming the exact dashboard record to edit.
 
-Step 1's OAuth flow is a state machine over two observable variables: the brand-scoped cert path (`${CFG_DIR}/cert.pem`) and the OAuth-default cert path (`~/.cloudflared/cert.pem`). When the brand-scoped cert is missing but the default-path cert is present from any prior partial run, the wrapper promotes it (`mv`) and emits `step=oauth-login result=ok reason=cert-promoted-from-default-path` without re-spawning cloudflared. When both are missing, the wrapper spawns `cloudflared tunnel login`, extracts the argotunnel URL from its stdout, and the instant the URL surfaces, mechanically opens it on the Pi's VNC chromium (`DISPLAY=${DISPLAY:-:99} /usr/bin/chromium <url> &`) — emitting `step=browser-spawn result=ok` and `step=browser-drive mode=operator-click`. The operator clicks the zone row + Authorize on the VNC; cloudflared's callback writes `~/.cloudflared/cert.pem`; the wrapper's cert-poll (180 s budget) picks it up and `mv`s it to the brand-scoped path. There is no CDP auto-click, no DOM matcher, no consent-page driver — the wrapper's job is to faithfully relay `cloudflared tunnel login`, never to layer automation on top (Task 858, doctrine `feedback_wrappers_faithfully_relay_third_party_cli`).
+Step 1's OAuth flow is a state machine over two observable variables: the brand-scoped cert path (`${CFG_DIR}/cert.pem`) and the OAuth-default cert path (`~/.cloudflared/cert.pem`). When the brand-scoped cert is missing but the default-path cert is present from any prior partial run, the wrapper promotes it (`mv`) and emits `step=oauth-login result=ok reason=cert-promoted-from-default-path` without re-spawning cloudflared. When both are missing, the wrapper spawns `cloudflared tunnel login`, extracts the argotunnel URL from its stdout, and the instant the URL surfaces, mechanically opens it on the Pi's VNC chromium (`DISPLAY=${DISPLAY:-:99} /usr/bin/chromium <url> &`) — emitting `step=browser-spawn result=ok` and `step=browser-drive mode=operator-click`. The operator clicks the zone row + Authorize on the VNC; cloudflared's callback writes `~/.cloudflared/cert.pem`; the wrapper's cert-poll (180 s budget) picks it up and `mv`s it to the brand-scoped path. There is no CDP auto-click, no DOM matcher, no consent-page driver — the wrapper's job is to faithfully relay `cloudflared tunnel login`, never to layer automation on top.
 
 ### How inputs reach the script
 
@@ -52,7 +52,7 @@ The agent does not invoke the script directly during onboarding — the endpoint
 
 The endpoint returns `{ ok: false, field: "script", message, output }` and the form surfaces the error inline. Relay the output to the user, name the exit code, and cite `references/reset-guide.md` for the next action. Offer to re-render the form after any manual steps the script's error output named. Do not attempt a second invocation outside the form, a Playwright-driven dashboard inspection, or an alternative `cloudflared` command sequence. The discipline rule below applies.
 
-When the failure reason is `timeout-waiting-cert` (Task 858 — operator did not click Authorize within the 180 s budget), the form surfaces the timeout and the operator can re-submit. The page is still on the Pi VNC; the operator can click Authorize there and the next form submit will complete via the cert-promotion pre-flight (the cert lands in `~/.cloudflared/cert.pem` after consent, and the wrapper's `mv` runs on the next invocation). Do not suggest `~/reset-tunnel.sh` — the cert path is intact and a fresh attempt is the only remediation needed.
+When the failure reason is `timeout-waiting-cert` (operator did not click Authorize within the 180 s budget), the form surfaces the timeout and the operator can re-submit. The page is still on the Pi VNC; the operator can click Authorize there and the next form submit will complete via the cert-promotion pre-flight (the cert lands in `~/.cloudflared/cert.pem` after consent, and the wrapper's `mv` runs on the next invocation). Do not suggest `~/reset-tunnel.sh` — the cert path is intact and a fresh attempt is the only remediation needed.
 
 ---
 
@@ -90,7 +90,7 @@ Example:
 
 Use this when the operator needs to do something only the Cloudflare dashboard can do: sign in, switch accounts, add a site, edit an apex CNAME, verify zone nameservers, delete a tunnel after stopping its replicas. The guide has one numbered click-path per operation. Quote the relevant click-path verbatim — the operator follows it in the browser. The agent does not drive dashboard mutations via Playwright or Chrome DevTools.
 
-The single exception is `list-cf-domains.sh` (Task 589), which reads the domains attached to the logged-in account to populate the `cloudflare-setup-form` dropdowns. That script is deterministic (bash + raw CDP, no LLM in the decision path), invoked only by the `/api/admin/cloudflare/domains` route, and produces only a JSON `string[]` on stdout; no dashboard state is changed. Any dashboard scrape that is not this exact script is forbidden — the agent does not extend this carve-out to new scripts it writes, hypothesises, or finds. Adding a new sanctioned scrape surface requires a code change reviewed as a doctrine change, not an inline agent decision.
+The single exception is `list-cf-domains.sh`, which reads the domains attached to the logged-in account to populate the `cloudflare-setup-form` dropdowns. That script is deterministic (bash + raw CDP, no LLM in the decision path), invoked only by the `/api/admin/cloudflare/domains` route, and produces only a JSON `string[]` on stdout; no dashboard state is changed. Any dashboard scrape that is not this exact script is forbidden — the agent does not extend this carve-out to new scripts it writes, hypothesises, or finds. Adding a new sanctioned scrape surface requires a code change reviewed as a doctrine change, not an inline agent decision.
 
 ---
 

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

@@ -22,7 +22,7 @@ Ask the agent to set up Cloudflare. The agent first confirms the domain is alrea
 - **Proxy apex** — optional bare-domain hostname (e.g. `yourdomain.com`) that should also serve the public agent.
 - **Admin password** — the password used to gate remote access to the admin surface.
 
-When you submit, the `/api/admin/cloudflare/setup` endpoint runs — in strict order — `setRemotePassword`, launches a `cloudflare-setup` action (earlier platform fixes: `systemd-run --user` transient unit wrapping `setup-tunnel.sh <brand> <port> <hostname...>`), and registers a post-exit handler to write alias-domains for every non-`public.*` public or apex hostname (so e.g. `chat.yourdomain.com` is classified as public by `isPublicHost`). The script runs end-to-end:
+When you submit, the `/api/admin/cloudflare/setup` endpoint runs — in strict order — `setRemotePassword`, launches a `cloudflare-setup` action (earlier platform fixes: `systemd-run --user` transient unit wrapping `setup-tunnel.sh <brand> <port> <hostname...>`), and registers a post-exit handler that writes alias-domains for every non-`public.*` public or apex hostname (so e.g. `chat.yourdomain.com` is classified as public by `isPublicHost`) and closes the audit Task. When the post-exit handler observes the systemd-run unit gone before its terminal status was sampled (a known systemd-run cgroup race), it consults `tunnel.state` on disk and verifies the tunnel identity matches the form you submitted; if so, the audit Task closes `completed` despite the missed observation. Otherwise it closes `failed` with `endpoint-died-pre-reconcile` and the boot reconciler may still recover the Task at next restart. The script runs end-to-end:
 
 - `cloudflared tunnel login` — OAuth browser sign-in. The VNC browser opens the Cloudflare authorize page; pick the account that owns your domain, click Authorize. `cert.pem` lands.
 - Tunnel resolution from operator-supplied identity (operator-selected-tunnel fix). The form populates a tunnel-select dropdown from `GET /api/admin/cloudflare/tunnels` (which calls `cloudflared tunnel list --output json` on your logged-in account). You either pick an existing tunnel from the list or type a name to create a new one. The form posts EXACTLY ONE of `{tunnelId, tunnelName}`; the script enforces the same constraint as defence in depth. Pre-fix the script derived `${BRAND}-$(hostname -s)` locally; that broke the operator-state-is-authoritative doctrine and silently created orphan tunnels whenever the device hostname changed. Stream log emits `step=tunnel-resolve source=operator-selected|operator-created tunnel_id=… tunnel_name=…` once the UUID is known.
@@ -30,7 +30,7 @@ When you submit, the `/api/admin/cloudflare/setup` endpoint runs — in strict o
 - `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 form's ActionLogPanel reports `code=0`, the form dispatches the `admin-chat:post-restart-resume` window CustomEvent with `{actionId, message}`. The chat hook ([useAdminChat.ts](../../../../platform/ui/app/useAdminChat.ts)) waits for the brand-service down-then-up cycle on `/api/health`, calls `POST /api/admin/sessions/<cid>/resume?session_key=<sk>` (cookie-bridge-rehydrates the wiped sessionStore via the surviving `__remote_session` cookie and binds the conversation), then sends the captured "Cloudflare setup completed (actionId: <id>)." marker as a normal hidden chat POST that re-invokes the agent. No relay queue, no boot-drain, no banner, no rebind endpoint. 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.
+- **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/internals.md

@@ -471,9 +471,9 @@ Each log entry includes the tool name and a truncated conversation ID for correl
 
 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.
 
-The doctrine is enforced at the storage primitive: writes to `:Person`, `:UserProfile`, `:AdminUser`, `:Organization`, `:LocalBusiness`, `:CloudflareTunnel`, or `:CloudflareHostname` MUST include exactly one inbound `:PRODUCED` edge whose source is a `:Task`. Bootstrap writes (PIN-setup, schema migrations, lazy `loadUserProfile`) are exempt via `createdBy.agent === 'system'`.
+The doctrine is enforced at the storage primitive: writes to `:Person`, `:UserProfile`, `:AdminUser`, `:Organization`, `:LocalBusiness`, `:CloudflareTunnel`, or `:CloudflareHostname` MUST include exactly one inbound `:PRODUCED` edge whose source is a `:Task`. Bootstrap writes (PIN-setup, schema migrations, lazy first-session UserProfile creation) are exempt via `createdBy.agent === 'system'`.
 
-Two surfaces emit the lifecycle: agent-driven actions call `task-create`/`task-update`/`task-complete` over MCP (`task-create` accepts `kind`, `inputsProvided` — names only, never values — and `raisedDuringConversationKey` to resolve the `RAISED_DURING` edge). Shell-driven actions wrap their script invocation in [platform/ui/app/lib/cloudflare-task-tracker.ts](../../../ui/app/lib/cloudflare-task-tracker.ts) (cloudflare is the first; installer / brand-publish / OAuth-login deferred). Both surfaces emit the same `[task] action-start|step|done` log lines so operators can grep one channel uniformly.
+Two surfaces emit the lifecycle: agent-driven actions call `task-create`/`task-update`/`task-complete` over MCP (`task-create` accepts `kind`, the canonical `inputsProvided` call-shape record, `inputs` + `inputSchema` for the operator-meaningful form payload, and `raisedDuringConversationKey` to resolve the `RAISED_DURING` edge). Shell-driven actions wrap their script invocation in [platform/ui/app/lib/cloudflare-task-tracker.ts](../../../ui/app/lib/cloudflare-task-tracker.ts) (cloudflare is the first; installer / brand-publish / OAuth-login deferred). Both surfaces emit the same `[task] action-start|step|done` log lines so operators can grep one channel uniformly. Both also call the central `redactSecrets` primitive ([platform/lib/task-secrets/](../../../lib/task-secrets/)) to strip schema-tagged secret keys before persisting `inputs.<field>` props on the Task — see `.docs/neo4j.md § Audit Task input contract` for the contract that replaces per-kind allow-lists.
 
 `memory-write` accepts an optional `producedByTaskId` parameter. When set, an inbound `:PRODUCED` edge from that Task is composed into the write's relationships before the gate runs — the typical agent-side pattern is to call `task-create` at the start of a flow, capture `taskId`, and pass it as `producedByTaskId` on every subsequent `memory-write` for an action-provenance-gated label. The gate verifies Task and write share the same `accountId`; mismatch is rejected loud.
 

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

@@ -40,7 +40,7 @@ These are enabled during onboarding and can be added or removed at any time. Som
 | `waitlist` | Waitlist lifecycle — extract sign-ups from conversations, review | — |
 | `replicate` | Image generation — three models for photorealistic, design, and fast draft images | Content producer, Research assistant |
 | `linkedin-import` | Import a LinkedIn Basic Data Export — Profile and Connections today, more CSVs as references land | Database operator |
-| `whatsapp-import` | Import a WhatsApp `_chat.txt` export. Two-phase contract: **Phase 1 (load)** is a single Bash entry — `bash platform/plugins/whatsapp-import/bin/whatsapp-ingest.sh <archive> --owner-element-id <id> --subject-person-id <id> --scope <admin\|public> --filter <chosen>` runs parse → operator-supplied filter → archive-write in one process (LLM-FREE), landing `:Conversation:WhatsAppConversation` + `:Message:WhatsAppMessage` with NEXT chain. The writer is bound to the operator-confirmed `{owner, subject}` `:Person` pair (bound-pair sender contract): any parsed senderName outside the closed canonical-name set LOUD-FAILs with `parser-miss`; the script does not auto-create participants. **Phase 2 (enrich)** is operator-driven: ask "enrich the X chat" / "wire observations from yesterday's import" and the database-operator runs the `whatsapp-import-enrich` skill — runs the chunked Haiku insight pass `mcp__memory__whatsapp-export-insight-pass` (parallel cap=8 chunks at a time, ≤90s wall for a 1700-message DM), then walks the auto-extracted observations row-by-row and writes operator-confirmed wiring (`:MENTIONS`/`:RELATED_TO` edges with evidence, `:Task` and `:Preference` nodes). Idempotent — re-running surfaces only items still in `observationStatus='auto-extracted'`. Distinct from the live `whatsapp` plugin which is a Baileys QR-pairing channel. | Database operator |
+| `whatsapp-import` | Import a WhatsApp `_chat.txt` export as a chunked `:ConversationArchive` shape (the chunked-archive contract — supersedes the prior two-phase load+enrich contract). Single Bash entry — `bash platform/plugins/whatsapp-import/bin/whatsapp-ingest.sh <archive> --owner-element-id <id> --participant-person-ids <csv> --scope <admin\|public>` — runs parse → operator-confirms owner + every distinct sender → sessionize at gap-hours boundaries (default 12h) → classify each session via Haiku (`memory-classify` with `mode='chat'`) into topic-bounded `:Section:Conversation` chunks → memory-ingest with `parentLabel='ConversationArchive'`. The parent MERGEs on `conversationIdentity = sha256(accountId + ":" + sortedParticipantElementIds)` — stable across re-exports, identical for DM and group. Re-imports are delta-append: prior chunks never touched, only messages after `lastIngestedMessageHash` flow through. Auto-creating participants is forbidden — any parsed senderName outside the operator-confirmed closed set LOUD-FAILs with `parser-miss`. Phase 2 insight derivation (`:Observation` / `:Task` / `:Preference` / `:MENTIONS` against chunks) is deferred to a separate follow-up task. Distinct from the live `whatsapp` plugin which is a Baileys QR-pairing channel. | Database operator |
 
 ### Claude Official (marketplace)
 

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

@@ -192,7 +192,7 @@ The transient unit was auto-collected by systemd before the client subscribed. R
 
 **Cloudflare-setup auto-relays "completed" but the next chat turn 502s.**
 
-Earlier platform fixes (relay queue + boot-drain) replaced an even earlier `awaitAdminReachable` holdback that polled the non-restarting edge surface. The current contract is a single client-driven resume: the form dispatches the `admin-chat:post-restart-resume` window CustomEvent on `exit{code:0}`, the chat hook waits for `/api/health` to fail then succeed (down-then-up cycle, `waitForRestartCycle`), calls `POST /api/admin/sessions/<cid>/resume?session_key=<sk>` (cookie-bridge-rehydrates the wiped sessionStore via the surviving `__remote_session` cookie and binds the conversation), then sends the marker as a normal hidden chat POST that re-invokes the agent under the operator's real session. No relay queue, no boot-drain, no banner, no rebind endpoint.
+The current contract is a single client-driven resume: when the setup script exits cleanly, the form fires a resume event, the chat hook waits for `/api/health` to fail then succeed (the brand-service down-then-up cycle), re-binds the conversation to the new server process, and sends the "completed" marker as a normal hidden chat POST that re-invokes the agent in the operator's real session. No relay queue, no boot-drain, no banner.
 
 Diagnostic recipe:
 
@@ -207,6 +207,7 @@ Failure modes:
 - `[client-event] kind=post-restart-resume phase=start` absent: form's CustomEvent never reached the chat hook (regression in form `onExit` or chat-listener mount).
 - `[client-event] phase=start` present, `[admin-resume] reason=post-restart` absent: `waitForRestartCycle` exhausted its bound (brand never restarted) or `/resume` rejected — check `phase=health-timeout` / `phase=resume-rejected`.
 - All four present except `[persist] role=user … Cloudflare setup completed`: marker chat POST failed — check the chat surface for an inline error or a `phase=resume-error` line.
+- Refresh after a successful Cloudflare setup shows a visible `Cloudflare setup completed (actionId: …)` user bubble: the resume mappers' synthetic-marker suppression broke or the marker shape drifted. Server-side `[admin-resume] syntheticHidden=<n>` field on the same line counts user rows the client should hide (`_componentDone` envelopes, `_lifecycle` envelopes, and the `Cloudflare setup completed (actionId: …)` literal) — a count of 0 against a refresh that should have hidden one means the helper at `platform/ui/app/lib/synthetic-marker.ts` no longer recognises the producing literal (check `CloudflareSetupForm.tsx` and `useAdminChat.ts` for shape drift).
 
 ---
 

package/payload/platform/plugins/linkedin-import/skills/linkedin-import/SKILL.md

@@ -51,7 +51,7 @@ When the owner is an external Person (non-operator archive), the anchor is the c
    - LinkedIn skills → `:DefinedTerm` with `category: 'linkedin-skill'`.
    - LinkedIn articles → `:CreativeWork` with `category: 'linkedin-article'`.
    - LinkedIn recommendations → `:Review`.
-   - LinkedIn DMs → `:Message:LinkedInMessage` + `:Conversation:LinkedInConversation` (sublabels on the existing labels, per Task 633 pattern).
+   - LinkedIn DMs → `:Message:LinkedInMessage` + `:Conversation:LinkedInConversation` (sublabels on the existing labels).
    - Certifications → `:Credential` (genuinely new — no existing {{productName}} label fits `schema:EducationalOccupationalCredential`).
 5. **Schema-base property names.** `givenName` / `familyName` / `telephone` / `dateSent` — not `firstName` / `phone` / `sentAt`. See [`platform/plugins/memory/references/schema-base.md`](../../../../plugins/memory/references/schema-base.md).
 6. **Schema-base edge names.** `(:Person)-[:WORKS_FOR]->(:Organization)` for positions. Custom LinkedIn edges (`CONNECTED_ON_LINKEDIN`, `ENDORSED`) only where schema-base has no canonical name.
@@ -68,7 +68,7 @@ When the owner is an external Person (non-operator archive), the anchor is the c
 
 **Doctrine:** raw Cypher and `cypher-shell` invocations are forbidden in this skill and its references. Writes route through `mcp__memory__memory-archive-write` (bulk archives) or `mcp__memory__memory-write` / `mcp__memory__memory-update` (single-node enrichments like `profile.md`). If a CSV needs a write shape no current MCP tool supports, file a task to extend `memory-archive-write` with a new `archiveType` handler — never improvise via Bash. See [database-operator's LOUD-FAIL prerogative](../../../../templates/specialists/agents/database-operator.md#prerogatives).
 
-**LOUD-FAIL on parse errors (structurally enforced, Task 846).** When LinkedIn parser tools land that follow the `mcp__*__*-import-parse` naming convention, the harness-level `platform/plugins/admin/hooks/archive-ingest-gate.sh` will record an `isError: true` response and block every subsequent tool call this turn until the operator submits the next prompt. The hook also denies edits to `platform/plugins/*/lib/*` and JavaScript test runners (`vitest`, `bun test`, `npm test`, `npx jest`) unconditionally. The skill's "no Bash improvisation" doctrine above is the contract; the hook is the enforcement. See [.docs/hooks.md](../../../../../.docs/hooks.md) for the full gate surface.
+**LOUD-FAIL on parse errors (structurally enforced).** When LinkedIn parser tools land that follow the `mcp__*__*-import-parse` naming convention, the harness-level `platform/plugins/admin/hooks/archive-ingest-gate.sh` will record an `isError: true` response and block every subsequent tool call this turn until the operator submits the next prompt. The hook also denies edits to `platform/plugins/*/lib/*` and JavaScript test runners (`vitest`, `bun test`, `npm test`, `npx jest`) unconditionally. The skill's "no Bash improvisation" doctrine above is the contract; the hook is the enforcement. See [.docs/hooks.md](../../../../../.docs/hooks.md) for the full gate surface.
 
 ## Selective-ingest threshold (bulk archives)
 

package/payload/platform/plugins/linkedin-import/skills/linkedin-import/references/connections.md

@@ -28,7 +28,7 @@ The real column header is **line 4**. Either skip the first three lines before p
 | URL | `Person.linkedinUrl` (natural key) |
 | Email Address | `Person.email` (only when non-empty) |
 | Company | `Organization.name` |
-| Position | `[:WORKS_FOR].title` AND `Person.currentTitle` (denormalised — Task 753) |
+| Position | `[:WORKS_FOR].title` AND `Person.currentTitle` (denormalised) |
 | Connected On | `[:CONNECTED_ON_LINKEDIN].connectedOn` (ISO 8601) |
 
 The `Position` column is written **twice**: once on the `[:WORKS_FOR]` edge as the source of truth (preserves the per-employer history when a connection later moves), and again as `Person.currentTitle` so Neo4j's `entity_search` BM25 index reaches it. Edge properties are invisible to a node-only fulltext index, so without the denormalisation an operator searching "director" against 5K connections returns near-zero hits regardless of how many directors are in the graph. The SET is unconditional — re-importing a row with an empty Position clears `currentTitle`, matching the LinkedIn export's "current snapshot" semantics. To filter your import to a specific role before writing, use the [Selective-ingest threshold](#selective-ingest-threshold) gate.

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

@@ -1,6 +1,6 @@
 ---
 name: memory
-description: "Graph memory plugin. Provides memory-search, memory-rank, memory-write, and memory-update tools for reading from, writing to, and updating the Neo4j knowledge graph. Includes conversational memory — organic preference learning, evidence-backed recall, and transparent 'what do you know about me?' responses."
+description: "Graph memory plugin. Provides memory-search, memory-rank, memory-write, and memory-update tools for reading from, writing to, and updating the Neo4j knowledge graph. Includes conversational memory — organic preference learning, evidence-backed recall, and transparent 'what do you know about me?' responses. Document ingestion (memory-classify + memory-ingest) supports two modes: `document` (default) for unstructured PDF/web content → KnowledgeDocument + Section, and `chat` for chat archives → ConversationArchive + Section:Conversation chunks (the chunked-archive contract)."
 tools:
   - memory-search
   - memory-rank

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

@@ -16,7 +16,7 @@ import { memoryArchiveWrite } from "./tools/memory-archive-write.js";
 import { whatsappExportParse } from "./tools/whatsapp-export-parse.js";
 import { whatsappExportInsightWrite } from "./tools/whatsapp-export-insight-write.js";
 import { whatsappExportPreview } from "./tools/whatsapp-export-preview.js";
-import { whatsappExportInsightPass } from "./tools/whatsapp-export-insight-pass.js";
+// Task 891: whatsapp-export-insight-pass deleted (Phase 2 deferred).
 import { memoryIngestWeb } from "./tools/memory-ingest-web.js";
 import { memoryClassify } from "./tools/memory-classify.js";
 import { memoryUpdate } from "./tools/memory-update.js";
@@ -1019,46 +1019,11 @@ if (!readOnly) {
             };
         }
     });
-    server.tool("whatsapp-export-insight-pass", "Phase 2 chunked-Haiku insight extraction over an already-loaded WhatsApp Conversation (Task 871). " +
-        "Walks the Messages of `:Conversation:WhatsAppConversation {conversationId}` in chronological order, " +
-        "chunks them at 50 messages with 5-message overlap, runs Haiku per chunk, and MERGE-keys " +
-        "`:Observation` nodes (kind ∈ {mention, task, preference, observed-relationship}) connected " +
-        "`:OBSERVED_IN`→Conversation. Server-side gates: confidence>=0.8 per item (lower-confidence items rejected before write). " +
-        "Idempotent — re-running collapses identical (conversationId, sourceMessageRef, kind, contentHash) into the same row. " +
-        "Phase 1 (`whatsapp-ingest.sh`) writes ZERO observations; this tool is the only sanctioned LLM entry for " +
-        "WhatsApp ingest. Operator triggers consciously via the `whatsapp-import-enrich` skill — never automatic on Phase 1 completion.", {
-        conversationId: z
-            .string()
-            .min(1)
-            .describe("conversationId of the already-loaded :Conversation:WhatsAppConversation. Phase 1 must have completed (`c.lastImportedAt IS NOT NULL`)."),
-        sessionId: z
-            .string()
-            .optional()
-            .describe("Skill-run UUID for provenance. Falls back to SESSION_ID env var when absent."),
-    }, async (params) => {
-        try {
-            const result = await whatsappExportInsightPass({
-                conversationId: params.conversationId,
-                accountId,
-                sessionId: resolveSessionId(params.sessionId),
-            });
-            return {
-                content: [{
-                        type: "text",
-                        text: JSON.stringify(result),
-                    }],
-            };
-        }
-        catch (err) {
-            return {
-                content: [{
-                        type: "text",
-                        text: `whatsapp-export-insight-pass failed: ${err instanceof Error ? err.message : String(err)}`,
-                    }],
-                isError: true,
-            };
-        }
-    });
+    // Task 891: `whatsapp-export-insight-pass` retired. Insight derivation
+    // (:Observation / :Task / :Preference / :MENTIONS) is deferred to a
+    // follow-up task that operates on :Section:Conversation chunks rather than
+    // raw :Message rows. The tool source and the `whatsapp-import-enrich` skill
+    // were deleted in the same commit; the surface gate's allow-list was updated.
     server.tool("memory-ingest-web", "Adapter for web-content ingestion (Task 737). Accepts a URL and its pre-fetched readable content " +
         "(the agent calls WebFetch first, then passes the text here), writes content to a temp file, and delegates " +
         "to memory-ingest-extract — caching the text under a freshly-generated attachmentId. The skill then drives " +