@rubytech/create-siteoffice-code 0.1.263 → 0.1.265

package/payload/platform/plugins/admin/skills/superpowers-sprint/SKILL.md

@@ -38,7 +38,7 @@ Invoke `superpowers:using-git-worktrees`. The skill creates an isolated git work
 
 After entering the worktree, install dependencies before building. Worktrees only contain tracked files, so `node_modules`, build artifacts, and untracked configuration are absent. Run `npm install` in every directory you plan to build from.
 
-`getmaxy` is one repo with two parallel installer trees living as plain directories — `packages/create-maxy/` ships `@rubytech/create-maxy`, and `maxy-code/packages/create-maxy-code/` ships `@rubytech/create-maxy-code`. Neither is a submodule, subtree, or sibling repo. Build only the tree the sprint touches; if a build needs `platform/` deps, install in the matching tree (`platform/` at the root for legacy work, `maxy-code/platform/` for Maxy Code work). If the sprint depends on recent main-branch work, merge main into the worktree branch at the start.
+`getmaxy` is one repo with two parallel installer trees living as plain directories — `packages/create-maxy/` ships `@rubytech/create-maxy`, and `maxy-code/packages/create-maxy-code/` ships `@rubytech/create-maxy-code`. Neither is a submodule, subtree, or sibling repo. Build only the tree the sprint touches; if a build needs `platform/` deps, install in the matching tree (`platform/` at the root for legacy work, `maxy-code/platform/` for SiteOffice Code work). If the sprint depends on recent main-branch work, merge main into the worktree branch at the start.
 
 If already in a worktree (resuming a sprint), skip — but verify `node_modules` is present.
 
@@ -271,8 +271,8 @@ If any row is ⏳, render the commands the operator runs when ready. Publish-tre
 
 | Installer tree | Installer directory | Brands directory | Default brand | Default package |
 |---|---|---|---|---|
-| Repo root (legacy Maxy) | `packages/create-maxy/` | `brands/` | `maxy` | `@rubytech/create-maxy` |
-| `maxy-code/` (Maxy Code) | `maxy-code/packages/create-maxy-code/` | `maxy-code/brands/` | `maxy-code` | `@rubytech/create-maxy-code` |
+| Repo root (legacy SiteOffice) | `packages/create-maxy/` | `brands/` | `maxy` | `@rubytech/create-maxy` |
+| `maxy-code/` (SiteOffice Code) | `maxy-code/packages/create-maxy-code/` | `maxy-code/brands/` | `maxy-code` | `@rubytech/create-maxy-code` |
 
 ```bash
 git push

package/payload/platform/plugins/admin/skills/upgrade/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: upgrade
-description: "Upgrade Maxy to the latest published version by re-running the brand's installer when the operator asks."
+description: "Upgrade SiteOffice to the latest published version by re-running the brand's installer when the operator asks."
 ---
 
 # Upgrade
 
-The operator wants to upgrade Maxy. Re-run the installer for the active brand; it is idempotent, brings the install to the latest published version, and restarts the brand service when it finishes.
+The operator wants to upgrade SiteOffice. Re-run the installer for the active brand; it is idempotent, brings the install to the latest published version, and restarts the brand service when it finishes.
 
 ## Resolve the brand package
 

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

@@ -52,7 +52,7 @@ The setup-done claim only fires when `curl -I https://<hostname>` issued from ou
 
 ## Identity model
 
-- **Product identity** (Maxy vs Real Agent) — known from `brand.json` (`productName`, `configDir`).
+- **Product identity** (SiteOffice vs Real Agent) — known from `brand.json` (`productName`, `configDir`).
 - **Cloudflare account identity** — `cert.pem` from OAuth. One account per brand per device.
 - **Account binding drift** — `~/{configDir}/cloudflared/account-binding.json` is a historical drift marker. Reset by `rm -rf ~/.${BRAND}/cloudflared/` per `references/reset-guide.md` when switching accounts.
 

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

@@ -1,14 +1,14 @@
 # Manual Cloudflare tunnel setup — human runbook
 
-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.
+Step-by-step recovery path for when the SiteOffice 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 — Tasks 553 + 924; defaults SiteOffice=`:99`/`5900`/`6080`/`9222`, Real Agent=`:100`/`5901`/`6081`/`9223`, SiteOffice-2=`:101`/`5902`/`6082`/`9224`, SiteOffice-3=`:102`/`5903`/`6083`/`9225`, SiteOffice-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)
 
-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 SiteOffice installation exposes two 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.
@@ -26,14 +26,14 @@ You have a Cloudflare account and a domain already on that account. You run ever
 - `admin.<yourdomain>`
 - `public.<yourdomain>`
 
-### Mode B — you don't own a domain (Maxy-provided subdomain)
+### Mode B — you don't own a domain (SiteOffice-provided subdomain)
 
-First-time users without a Cloudflare account or domain use a subdomain of the Maxy-operated domain (`maxy.bot`). Maxy owns the CF account and issues each user a token for a pre-created tunnel. Hostnames are:
+First-time users without a Cloudflare account or domain use a subdomain of the SiteOffice-operated domain (`maxy.bot`). SiteOffice owns the CF account and issues each user a token for a pre-created tunnel. Hostnames are:
 
 - `<username>.maxy.bot` — admin surface (e.g. `neo.maxy.bot`, `joel.maxy.bot`)
-- public surface is optional and, when enabled, uses a second Maxy-issued subdomain.
+- public surface is optional and, when enabled, uses a second SiteOffice-issued subdomain.
 
-Mode B skips Steps 1–5 of this runbook entirely — the user receives a token from Maxy and only runs Step 6 (the connector) with `--token <X>`. Mode B is documented separately in `managed-tunnel-setup.md`.
+Mode B skips Steps 1–5 of this runbook entirely — the user receives a token from SiteOffice and only runs Step 6 (the connector) with `--token <X>`. Mode B is documented separately in `managed-tunnel-setup.md`.
 
 **The rest of this runbook covers Mode A only.**
 
@@ -53,7 +53,7 @@ Apex hostnames (e.g. `maxy.chat`) cannot be routed by `cloudflared tunnel route
 
 Run this once per shell session. Every subsequent step reads these variables. The `BRAND` value determines the on-disk directory (`${HOME}/.${BRAND}/cloudflared/`) so multiple brands on the same Linux user do not collide.
 
-For Maxy:
+For SiteOffice:
 
 ```
 export BRAND=maxy
@@ -365,7 +365,7 @@ cat "${CFG_DIR}/tunnel.state" | jq .tunnelId
 
 Prints the UUID from Step 3. If it prints empty or null, the heredoc's env expansion failed — re-run the fail-fast guard.
 
-**If you skip this step:** `systemctl --user status maxy.service` will show `ExecStartPre=resume-tunnel.sh (code=exited, status=0/SUCCESS)` (no error) but `ps -ef | grep '[c]loudflared'` will show no Maxy connector. Silent failure — the exact gap this step closes.
+**If you skip this step:** `systemctl --user status maxy.service` will show `ExecStartPre=resume-tunnel.sh (code=exited, status=0/SUCCESS)` (no error) but `ps -ef | grep '[c]loudflared'` will show no SiteOffice connector. Silent failure — the exact gap this step closes.
 
 ---
 
@@ -424,7 +424,7 @@ A non-530 response means the tunnel is live.
 
 **Do NOT use `sudo cloudflared service install`.** It writes `/etc/systemd/system/cloudflared.service`, copies your config to `/etc/cloudflared/config.yml` (a system-wide path), and runs the connector as root — breaking brand isolation on any device that hosts more than one brand under the same Linux user. We tried this path on 2026-04-19; it created a duplicate connector parallel to the existing user-space one and required an explicit uninstall to undo.
 
-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`. When the user-space service restarts, the connector restarts with it. 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 correct production pattern is already in place on every SiteOffice 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`. When the user-space service restarts, the connector restarts with it. 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.).
 
 **Durability prerequisites (one-time per device):**
 

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

@@ -60,7 +60,7 @@ Re-run the setup flow from `references/manual-setup.md` § Step 1 with the opera
 
 ### Stop a token-mode connector
 
-Token-mode tunnels are created by a central operator (e.g. Maxy-provided subdomains under `maxy.bot`). The connector runs with `--token <X>` and does not consult `cert.pem`, so the full-reset flow above (which authorises via cert.pem) cannot stop or delete it. Kill the process directly:
+Token-mode tunnels are created by a central operator (e.g. SiteOffice-provided subdomains under `maxy.bot`). The connector runs with `--token <X>` and does not consult `cert.pem`, so the full-reset flow above (which authorises via cert.pem) cannot stop or delete it. Kill the process directly:
 
 ```
 pkill -f 'cloudflared.*tunnel run --token'

package/payload/platform/plugins/docs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "docs",
-  "description": "Comprehensive user guide and platform documentation for Maxy. Load references when users ask how-to, setup, or troubleshooting questions. Also contains platform architecture references for admin use.",
+  "description": "Comprehensive user guide and platform documentation for SiteOffice. Load references when users ask how-to, setup, or troubleshooting questions. Also contains platform architecture references for admin use.",
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"

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

@@ -1,23 +1,23 @@
 ---
 name: docs
 surface: platform
-description: "Comprehensive user guide and platform documentation for Maxy. Load references when users ask how-to, setup, or troubleshooting questions. Also contains platform architecture references for admin use."
+description: "Comprehensive user guide and platform documentation for SiteOffice. Load references when users ask how-to, setup, or troubleshooting questions. Also contains platform architecture references for admin use."
 metadata: {"platform":{"always":true,"embed":["public","admin"],"pluginKey":"docs"}}
 ---
 
-# Maxy Documentation
+# SiteOffice Documentation
 
-This plugin is the single source of truth for Maxy documentation. It ships with every install and is always the version the user has installed.
+This plugin is the single source of truth for SiteOffice documentation. It ships with every install and is always the version the user has installed.
 
 Load the relevant reference when the user asks a how-to question, requests help with setup, reports an issue, or wants to understand how something works.
 
 ## User Guide
 
-Load these when users ask about Maxy features or need guidance:
+Load these when users ask about SiteOffice features or need guidance:
 
-- **Getting started** → `references/getting-started.md` — first run, what Maxy is, how to use it
+- **Getting started** → `references/getting-started.md` — first run, what SiteOffice is, how to use it
 - **Plugins** → `references/plugins-guide.md` — what plugins are, how to install/remove them, the marketplace
-- **Memory** → `references/memory-guide.md` — how Maxy remembers things, what is stored, privacy
+- **Memory** → `references/memory-guide.md` — how SiteOffice remembers things, what is stored, privacy
 - **Graph view** → `references/graph.md` — the admin `/graph` page: node/edge display, zoom-adaptive Conversation labels, filter chips, trashed nodes
 - **Contacts** → `references/contacts-guide.md` — adding, looking up, and managing contacts
 - **Telegram** → `references/telegram-guide.md` — Telegram setup, the bot, daily use

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

@@ -28,7 +28,7 @@ The HMAC secret lives at `~/.${brand}/credentials/admin-session-secret` (mode `0
 
 ## SDK-resume contract on PIN-rebind
 
-The Anthropic SDK is stateless against its own JSONL: every cold-create with `resume: <agentSessionId>` reads `${CLAUDE_CONFIG_DIR}/projects/<encoded-cwd>/<agentSessionId>.jsonl` verbatim. The Maxy graph (`Conversation.agentSessionId`) is just the pointer into the JSONL, not a parallel transcript. The PIN-rebind contract preserves this:
+The Anthropic SDK is stateless against its own JSONL: every cold-create with `resume: <agentSessionId>` reads `${CLAUDE_CONFIG_DIR}/projects/<encoded-cwd>/<agentSessionId>.jsonl` verbatim. The SiteOffice graph (`Conversation.agentSessionId`) is just the pointer into the JSONL, not a parallel transcript. The PIN-rebind contract preserves this:
 
 1. **Rehydrate** restores `(accountId, userId)` into the in-memory session. `sessionId` and `agentSessionId` are empty.
 2. **Chat-route first POST** (`platform/ui/server/routes/admin/chat.ts`):

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

@@ -11,7 +11,7 @@ SDK-resume contract). This file is the index that points at them.
 
 The `maxy-code/` tree does **not** ship a `.docs/platform.md` developer
 doc. The legacy root tree (`getmaxy/`) carries one at
-`.docs/platform.md` for the original Maxy installer; the Maxy Code tree
+`.docs/platform.md` for the original SiteOffice installer; the SiteOffice Code tree
 keeps its architecture surface in two places:
 
 - `maxy-code-prd.md` at the repo root — product requirements and the
@@ -232,7 +232,7 @@ chat stays live.
   SOUL / KNOWLEDGE) auto-save on type via
   `POST /api/admin/sidebar-artefact-save`.
 - Read-only artefacts (specialist agent templates) cannot be edited
-  because they ship with Maxy and would be overwritten on the next
+  because they ship with SiteOffice and would be overwritten on the next
   install.
 - PDF artefacts render inline; non-PDF binaries fall back to a Download
   button when the browser has no native viewer.

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

@@ -6,7 +6,7 @@ Each installation has its own Cloudflare account. The **tunnel** sign-in is OAut
 
 | Concept | Source |
 |------|--------|
-| **Product identity** (Maxy vs Real Agent) | `brand.json` (`productName`, `configDir`) — known at install. |
+| **Product identity** (SiteOffice vs Real Agent) | `brand.json` (`productName`, `configDir`) — known at install. |
 | **Cloudflare account identity** | `cert.pem` from OAuth. One account per brand per device. |
 | **Domain scope** (which zones the operator can route) | The operator picks the zone in the dashboard during OAuth or names it in chat; the agent can also enumerate zones via the API with a minted read-scoped token. |
 | **Local tunnel state** | `~/{configDir}/cloudflared/` — `cert.pem`, `<UUID>.json`, `config.yml`, `alias-domains.json`. |

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

@@ -108,7 +108,7 @@ Diagnostic line per spawn (`~/.<brand>/logs/server.log`):
 
 The `pty-spawn-start` line additionally carries `hooksResolved=<event1,event2,…>` — the hook event names Claude Code would actually load for that PTY (resolved by walking the same `$CLAUDE_CONFIG_DIR/settings.json` plus the cwd-to-.git path Claude Code itself uses). A Stop hook registered in a settings file outside the loader's scope shows up as a missing event in this list.
 
-Zero `aboutOwnerBytes` on any admin spawn is a regression: the upstream resolver dropped the field entirely. The prose body always carries the unconditional MAXIMISE imperative on line two, so the byte count is positive even on a fresh-account spawn whose line one is `NOTHING`. Zero `dormantPluginsBytes` on a Maxy install with `cloudflare` not enabled is likewise a regression. Zero `pluginManifestBytes` on any account with enabled plugins means the upstream walker failed silently.
+Zero `aboutOwnerBytes` on any admin spawn is a regression: the upstream resolver dropped the field entirely. The prose body always carries the unconditional MAXIMISE imperative on line two, so the byte count is positive even on a fresh-account spawn whose line one is `NOTHING`. Zero `dormantPluginsBytes` on a SiteOffice install with `cloudflare` not enabled is likewise a regression. Zero `pluginManifestBytes` on any account with enabled plugins means the upstream walker failed silently.
 
 The manager also runs a boot-time self-test that renders a fixture compose call against synthetic inputs and refuses to start if any sentinel is missing:
 
@@ -196,9 +196,9 @@ A separate operator-side harness at `platform/scripts/installer-device-verify.sh
 
 ## Plugin registration at install time
 
-The installer registers Claude Code plugins on the device as the last step before the brand service starts. After registration, `claude plugin list` on the Pi shows every Maxy platform plugin shipped by the brand, every premium sub-plugin shipped by the brand, and any external plugins the brand declares (e.g. Telegram, Discord, iMessage from `claude-plugins-official`). Spawned `claude` sessions inherit those plugins from `~/.claude/` — the session manager passes no `--mcp-config` argv.
+The installer registers Claude Code plugins on the device as the last step before the brand service starts. After registration, `claude plugin list` on the Pi shows every SiteOffice platform plugin shipped by the brand, every premium sub-plugin shipped by the brand, and any external plugins the brand declares (e.g. Telegram, Discord, iMessage from `claude-plugins-official`). Spawned `claude` sessions inherit those plugins from `~/.claude/` — the session manager passes no `--mcp-config` argv.
 
-**Where the manifests come from.** The Maxy plugin source tree uses `PLUGIN.md` (YAML frontmatter) for plugin metadata, not Claude Code's native `.claude-plugin/plugin.json`. At bundle time, `scripts/generate-plugin-manifests.mjs` walks the payload and synthesises a Claude-Code-native `plugin.json` per plugin plus a `marketplace.json` at each tree root. The generator runs in `packages/create-maxy-code/scripts/bundle.js` after platform + premium plugins are copied into the payload, so the deployed install directory carries:
+**Where the manifests come from.** The SiteOffice plugin source tree uses `PLUGIN.md` (YAML frontmatter) for plugin metadata, not Claude Code's native `.claude-plugin/plugin.json`. At bundle time, `scripts/generate-plugin-manifests.mjs` walks the payload and synthesises a Claude-Code-native `plugin.json` per plugin plus a `marketplace.json` at each tree root. The generator runs in `packages/create-maxy-code/scripts/bundle.js` after platform + premium plugins are copied into the payload, so the deployed install directory carries:
 
 - `<INSTALL_DIR>/platform/plugins/<name>/.claude-plugin/plugin.json` per platform plugin
 - `<INSTALL_DIR>/platform/plugins/.claude-plugin/marketplace.json` (marketplace `maxy-platform`)
@@ -247,17 +247,17 @@ External channel plugins (telegram, discord) are installed but not configured at
 
 ## Running multiple brands on one device
 
-A single Pi or laptop can host more than one brand (for example Maxy and Real Agent) side by side. Each brand runs as its own service on its own port, with its own install directory and its own data. Installing one brand does not touch the other.
+A single Pi or laptop can host more than one brand (for example SiteOffice and Real Agent) side by side. Each brand runs as its own service on its own port, with its own install directory and its own data. Installing one brand does not touch the other.
 
-- **Separate:** each brand has its own install folder (`~/maxy/`, `~/realagent/`), its own config folder (`~/.maxy/`, `~/.realagent/`), its own web port, its own Cloudflare tunnel state, its own edge systemd unit (`maxy-edge.service` vs `realagent-edge.service`), and by default its own Neo4j database (Maxy on bolt port 7687, Real Agent on 7688). Action runner units are transient and per-invocation, not per-brand, so no naming conflict is possible.
+- **Separate:** each brand has its own install folder (`~/maxy/`, `~/realagent/`), its own config folder (`~/.maxy/`, `~/.realagent/`), its own web port, its own Cloudflare tunnel state, its own edge systemd unit (`maxy-edge.service` vs `realagent-edge.service`), and by default its own Neo4j database (SiteOffice on bolt port 7687, Real Agent on 7688). Action runner units are transient and per-invocation, not per-brand, so no naming conflict is possible.
 - **Brand-isolated Neo4j:** when a brand provisions a dedicated Neo4j instance (any port other than 7687), the installer stops and disables the apt-package's system `neo4j.service` after enabling the brand-dedicated unit, so only one Neo4j process holds the shared `/var/lib/neo4j/run/` PID file. The seed step receives the brand-correct `NEO4J_URI` and `NEO4J_PASSWORD` as explicit environment variables — the seed script no longer carries a `bolt://localhost:7687` default. A failed dedicated start aborts the install loudly with a journalctl tail; there is no silent fallback to the system instance. Stop/disable targets the literal `neo4j.service` only, so peer brands running their own `neo4j-{brand}.service` are unaffected.
-- **Peer-aware system-unit guard:** before stopping the system `neo4j.service`, the installer checks whether any other brand on the device still depends on it — that is, has `NEO4J_URI=bolt://localhost:7687` in its `~/.<peer>/.env`. If so, the system unit is left enabled and active, and the install log shows `[neo4j] system unit kept active — peer brand <name> depends on port 7687` instead of the usual `[neo4j] disabling system unit` line. This prevents a `create-realagent` install from disabling Maxy's database on a host where Maxy still uses the shared system instance (the earlier platform fixes reproducer on Neo's laptop, 2026-04-28). On single-brand hosts and on multi-brand hosts where every peer runs a dedicated port, behaviour is unchanged. The dedicated unit exports `NEO4J_HOME=<per-brand-data-dir>` alongside `NEO4J_CONF`, so `server.directories.run`, `server.directories.plugins`, and `server.directories.import` resolve per-brand — no collision with `/var/lib/neo4j/run/neo4j.pid`. The conf sed-overrides, mkdir-p, chown, and unit-write are idempotent and re-run on every install, so a host whose prior install left a broken unit recovers on retry.
+- **Peer-aware system-unit guard:** before stopping the system `neo4j.service`, the installer checks whether any other brand on the device still depends on it — that is, has `NEO4J_URI=bolt://localhost:7687` in its `~/.<peer>/.env`. If so, the system unit is left enabled and active, and the install log shows `[neo4j] system unit kept active — peer brand <name> depends on port 7687` instead of the usual `[neo4j] disabling system unit` line. This prevents a `create-realagent` install from disabling SiteOffice's database on a host where SiteOffice still uses the shared system instance (the earlier platform fixes reproducer on Neo's laptop, 2026-04-28). On single-brand hosts and on multi-brand hosts where every peer runs a dedicated port, behaviour is unchanged. The dedicated unit exports `NEO4J_HOME=<per-brand-data-dir>` alongside `NEO4J_CONF`, so `server.directories.run`, `server.directories.plugins`, and `server.directories.import` resolve per-brand — no collision with `/var/lib/neo4j/run/neo4j.pid`. The conf sed-overrides, mkdir-p, chown, and unit-write are idempotent and re-run on every install, so a host whose prior install left a broken unit recovers on retry.
 - **Shared:** both brands share the system Chromium/VNC stack, the Ollama model server, and the `cloudflared` command itself. Browser automation is serialised — one admin session at a time across both brands.
 
 To install a second brand on a device that already runs the first, just run the other installer. No flags needed for isolation:
 
 ```bash
-# Already running Maxy on port 20000. Install Real Agent on a different port:
+# Already running SiteOffice on port 20000. Install Real Agent on a different port:
 npx -y @rubytech/create-realagent --port 19500
 ```
 

package/payload/platform/plugins/docs/references/linkedin-extension.md

@@ -1,6 +1,6 @@
 # LinkedIn Extension — operator guide
 
-Capture a LinkedIn profile or DM thread to your Maxy graph with one click. The plugin ships a small Chrome extension; the admin already knows how to receive its payloads.
+Capture a LinkedIn profile or DM thread to your SiteOffice graph with one click. The plugin ships a small Chrome extension; the admin already knows how to receive its payloads.
 
 ## Install (one time)
 
@@ -8,7 +8,7 @@ Capture a LinkedIn profile or DM thread to your Maxy graph with one click. The p
 2. Toggle **Developer mode** on (top right).
 3. Click **Load unpacked**.
 4. Select `platform/plugins/linkedin-extension/extension/` on disk.
-5. Click the puzzle icon → pin **Maxy LinkedIn Ingest** → open its options.
+5. Click the puzzle icon → pin **SiteOffice LinkedIn Ingest** → open its options.
 6. Paste two values:
    - **Admin host** — your tunnel URL, e.g. `https://your-tunnel.example.com`.
    - **Session key** — open your admin browser, copy the value of `session_key` from the cookie. (Same key the admin uses to authenticate every other admin request.)
@@ -16,7 +16,7 @@ Capture a LinkedIn profile or DM thread to your Maxy graph with one click. The p
 
 ## Use
 
-- **Profile** — open any `https://www.linkedin.com/in/<slug>/` page. An **Add to Maxy** pill appears in the top section. Click it. Within a few seconds the pill turns green: the profile is in your graph.
+- **Profile** — open any `https://www.linkedin.com/in/<slug>/` page. An **Add to SiteOffice** pill appears in the top section. Click it. Within a few seconds the pill turns green: the profile is in your graph.
 - **DM thread** — open any `https://www.linkedin.com/messaging/thread/<id>/` conversation. The same pill appears. Click it; the full transcript is captured plus the participants and any explicit commitments (meetings booked, actions promised, prices discussed).
 - **Re-click** — the pill is idempotent. Re-clicking the same URL refreshes the document body and regenerates the summary; identities and entities `MERGE` rather than duplicate.
 
@@ -36,7 +36,7 @@ The plugin will never create `:Communication`, `:ConversationArchive` rows (i.e.
 
 ## When the pill turns amber
 
-The pill shows **Sign in to Maxy** when your session key has expired. Click it to open the options page; paste a fresh `session_key` from your admin browser; save. The next click on the LinkedIn pill will succeed.
+The pill shows **Sign in to SiteOffice** when your session key has expired. Click it to open the options page; paste a fresh `session_key` from your admin browser; save. The next click on the LinkedIn pill will succeed.
 
 ## When the pill turns red
 

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

@@ -114,7 +114,7 @@ Conversations and Messages carry role/channel sublabels so you can read the chat
 
 **Bulk cleanup of conversations in chat:** when you ask {{productName}} to clean up conversations in bulk ("trash all empty conversations," "clean up the single-assistant tests"), the agent uses a deterministic selector with a fixed set of filter names — it cannot author custom delete queries. The server re-runs the same filter on every candidate before it trashes, so a stale list can't destroy something the filter wouldn't match now. If the filter matches nothing, {{productName}} reports "no candidates" and nothing happens.
 
-The page reads only your own brand's Neo4j — a Maxy device and a Real Agent device share no graph state even when on the same laptop. No credentials are required; the view inherits your admin session.
+The page reads only your own brand's Neo4j — a SiteOffice device and a Real Agent device share no graph state even when on the same laptop. No credentials are required; the view inherits your admin session.
 
 **Typo-proof cypher.** When {{productName}} runs direct Cypher to answer a relational question, the query is checked against your Neo4j's live label and relationship-type taxonomy before it executes. Cypher that references an unknown name (an edge or label that does not exist in your graph) is rejected for writes and flagged with a warnings header for reads, so {{productName}} never silently acts on a query that targeted the wrong set of nodes. You should not see this — it runs invisibly — but it is the safety net that stops a fabricated edge name from producing "empty" results that are really just unreachable. Before acting on a bulk operation {{productName}} surfaces the result count and a sample; if it ever describes a cypher rejection, that means its first attempt was malformed and it corrected itself.
 
@@ -144,7 +144,7 @@ Every node also carries a provenance stamp — which agent wrote it, in which se
 
 ## Vertical schemas
 
-On top of the base graph, each brand boots one optional **vertical** — an extra set of entity types tailored to a trade. The vertical is named by `brand.json#vertical` and defined in a `schema-<name>.md` reference; the memory plugin loads it at startup and validates every write against base + the active vertical. Real Agent boots `schema-estate-agent` (Listing, Property, Viewing, Offer). SiteOffice boots `schema-construction`, which adds the building-contractor entities — `Job`, `LineItem`, `Valuation`, `Milestone`, `QuoteDocument`, `VariationNote`, `InboundInvoice`, `SubContractor`, `TimeLog`, `SubInvoice`, `WhatsAppGroup` — grounded in real builder job folders so a job's quote, valuations, variations, supplier invoices, and subcontractor timesheets all hang off one `Job` node. The default Maxy brand boots no vertical (base graph only).
+On top of the base graph, each brand boots one optional **vertical** — an extra set of entity types tailored to a trade. The vertical is named by `brand.json#vertical` and defined in a `schema-<name>.md` reference; the memory plugin loads it at startup and validates every write against base + the active vertical. Real Agent boots `schema-estate-agent` (Listing, Property, Viewing, Offer). SiteOffice boots `schema-construction`, which adds the building-contractor entities — `Job`, `LineItem`, `Valuation`, `Milestone`, `QuoteDocument`, `VariationNote`, `InboundInvoice`, `SubContractor`, `TimeLog`, `SubInvoice`, `WhatsAppGroup` — grounded in real builder job folders so a job's quote, valuations, variations, supplier invoices, and subcontractor timesheets all hang off one `Job` node. The default SiteOffice brand boots no vertical (base graph only).
 
 ## Public-facing summaries for customer-readable subjects
 

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

@@ -1,6 +1,6 @@
 # Neo4j edge types — operator reference
 
-How Maxy's graph wires itself.
+How SiteOffice's graph wires itself.
 
 ## Typed-edge auto-extraction
 

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

@@ -4,7 +4,7 @@ The `outlook` plugin gives the admin agent read-only access to Microsoft 365 / O
 
 ## Quickstart
 
-1. **Register an Entra app once per Maxy install** — see `platform/plugins/outlook/references/auth.md` for full steps. Set `OUTLOOK_CLIENT_ID` (and `OUTLOOK_TENANT_ID`, default `common`) in the operator's environment.
+1. **Register an Entra app once per SiteOffice install** — see `platform/plugins/outlook/references/auth.md` for full steps. Set `OUTLOOK_CLIENT_ID` (and `OUTLOOK_TENANT_ID`, default `common`) in the operator's environment.
 2. **Per account: register the Outlook account** — in admin chat, ask the agent to "register my Outlook account". The agent runs `outlook-account-register`, which prints an authorization URL.
 3. **Open the URL in the VNC browser** — sign in to your Microsoft account, consent to the requested scopes (`offline_access`, `User.Read`, `Mail.Read`, `Calendars.Read`, `Contacts.Read`).
 4. **Done.** Subsequent tool calls (mail, calendar, contacts) use the persisted refresh token transparently.

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

@@ -80,9 +80,9 @@ There is no dashboard, no settings panel, no menus. Everything is done through c
 
 The chat input auto-grows as you type — it expands to fit your message and shrinks back when you delete text. You can also drag the resize handle above the input to set a custom height.
 
-The admin interface is a three-pane layout: a sidebar on the left with navigation (Sessions, People, Agents, Projects, Tasks, Artefacts) and your recent conversations; the chat in the middle; and an artefact pane on the right that opens when you select a document, click a project, or open Browser, Data, or Graph from the menu, holding the surface side-by-side with the conversation so the chat stays live while you work in it. At the very top of the sidebar — above the nav rows — a borderless row holds two controls: a "+ New session" button on the left that spawns a fresh Claude Code session, and a Mode trigger on the right showing the current permission mode (Ask, Accept edits, Plan, or Auto). The sidebar's vertical order is: new-session strip first, then the nav (Sessions, People, Agents, Projects, Tasks, Artefacts), then the sessions list, then the footer. Both controls render as plain text-plus-icon affordances with no surrounding rectangle. The "+ New session" button is a text-width hit target — its clickable area is exactly the icon plus label, not the whole row — and shows no hover fill; the only hover feedback is the pointer cursor. The Mode trigger is pushed flush to the right edge of the row. Clicking the Mode trigger opens a popover downward from the row whose header reads "Mode" and lists the four permission modes with the current selection check-marked. The sidebar's nav rows swap the list view in place: Sessions shows recent conversations, Projects shows your active work projects, and Artefacts lists every KnowledgeDocument plus this account's agent templates (your admin agent's IDENTITY, SOUL, and KNOWLEDGE files plus one entry per enabled specialist). Each recent session row carries a three-state indicator: three pulsing dots when the session is busy (currently processing a turn), a solid sage dot when it is idle (live PTY waiting for input), and a hollow ring when it is archived (PTY exited, JSONL on disk for audit). The list itself splits into three views via a segmented control above the rows: **Active** shows every live session, **Archived** shows every JSONL on disk whose PTY has exited, and **All** shows both. The view choice persists across reloads. An "Include subagents" toggle inside the Active view surfaces specialist spawns (database-operator, premium-plugin agents, anything spawned with a `--agent` flag) which are hidden by default so the list reflects what you started directly. Each row also carries a small uppercase badge — `admin` for operator-driven sessions, the specialist name (for example `db-op`) for background work — so the source of any row is unambiguous at a glance. The People, Agents, and Tasks rows are graph shortcuts: clicking each opens the artefact-pane Graph filtered to every Person, every public Agent, or every Task in your account respectively, with no side-list, because the graph itself is the result. Public agents become first-class graph entities the moment you create them, with edges to their IDENTITY/SOUL/KNOWLEDGE files, edges to every knowledge document they have access to, and edges from every conversation they have handled, so a single Agents click reveals the whole shape of who knows what and who has been talking to whom. Click an artefact row to open the document. KnowledgeDocuments and your admin agent's templates are editable: type in the document and changes save automatically; specialist agent templates are read-only because they ship with Maxy and your edits would be overwritten on the next install. PDF artefacts render inline so you can read them without leaving the pane. If your browser doesn't have a built-in PDF viewer, a Download button appears instead. Artefacts that have no readable file backing them (orphan rows, files removed from disk, unsupported content types) show a one-line banner explaining the skip instead of opening to a blank pane. Click a project row to open the Graph view focused on that project's neighbourhood; clicking a second project swaps the focus rather than stacking on top. The sidebar's right edge is drag-resizable on every admin page (Sessions root, Graph, and Data): drag the handle to widen or narrow the sidebar, and your chosen width is remembered across reloads and shared across all three pages. The drag handle is mounted by each AdminShell consumer rather than by AdminShell itself, so any new admin route must include `<SidebarSplitter />` as a direct child of its `<AdminShell>` to pick up the shared width. The chat and artefact divider is also drag-resizable: drag the line between the columns to make either side wider; double-click it to reset to half of the available width (viewport minus sidebar), clamped to the chat and artefact min-width floors. Your chosen width is remembered across reloads. On wider screens (>1280px) all three panes are visible. The sidebar narrows at 1280px, the artefact pane hides at 1080px (Browser, Data, and Graph then open as full-window pages instead), and the sidebar collapses to a 56px icon rail at 820px. On every viewport the chat header reads left to right as a triptych: a dedicated sidebar toggle (the panel-right icon, which swaps to panel-right-open when the sidebar is showing), the brand mark next to the title in the centre, and the menu burger on the right. This header toggle is the sole sidebar-toggle button; the sidebar itself no longer carries a duplicate. Tap the sidebar toggle to show or hide the sidebar: on phones (<720px) it slides the drawer in or out, on wider screens it collapses or expands the sidebar column. The brand mark in the centre is decorative; clicks go through the dedicated toggle so the affordance is unambiguous. The drawer animation only fires on tap (220ms slide in or out); resizing your window across the 720px boundary snaps the layout without animation, so you never see a half-open flash. At ≤640px the session metadata pane stacks each label above its value instead of the desktop two-column grid, and the row of action buttons (Open in new tab / Download JSONL / View JSONL / Rename / Pin / Archive / End or Purge) collapses behind a single Actions trigger that opens a popover upward from the foot of the pane. Breakpoint summary: >1280px = full sidebar + chat + artefact pane (drag-resizable divider); 1280px→1080px = sidebar narrows; 1080px→820px = artefact pane hides (Browser/Data/Graph open as full-window pages instead); 820px→720px = sidebar collapses to 56px icon rail; ≤720px = sidebar becomes off-canvas drawer (vertical stack of nav, recents list, foot, the same shape as the desktop sidebar, just on top of the chat instead of beside it).
+The admin interface is a three-pane layout: a sidebar on the left with navigation (Sessions, People, Agents, Projects, Tasks, Artefacts) and your recent conversations; the chat in the middle; and an artefact pane on the right that opens when you select a document, click a project, or open Browser, Data, or Graph from the menu, holding the surface side-by-side with the conversation so the chat stays live while you work in it. At the very top of the sidebar — above the nav rows — a borderless row holds two controls: a "+ New session" button on the left that spawns a fresh Claude Code session, and a Mode trigger on the right showing the current permission mode (Ask, Accept edits, Plan, or Auto). The sidebar's vertical order is: new-session strip first, then the nav (Sessions, People, Agents, Projects, Tasks, Artefacts), then the sessions list, then the footer. Both controls render as plain text-plus-icon affordances with no surrounding rectangle. The "+ New session" button is a text-width hit target — its clickable area is exactly the icon plus label, not the whole row — and shows no hover fill; the only hover feedback is the pointer cursor. The Mode trigger is pushed flush to the right edge of the row. Clicking the Mode trigger opens a popover downward from the row whose header reads "Mode" and lists the four permission modes with the current selection check-marked. The sidebar's nav rows swap the list view in place: Sessions shows recent conversations, Projects shows your active work projects, and Artefacts lists every KnowledgeDocument plus this account's agent templates (your admin agent's IDENTITY, SOUL, and KNOWLEDGE files plus one entry per enabled specialist). Each recent session row carries a three-state indicator: three pulsing dots when the session is busy (currently processing a turn), a solid sage dot when it is idle (live PTY waiting for input), and a hollow ring when it is archived (PTY exited, JSONL on disk for audit). The list itself splits into three views via a segmented control above the rows: **Active** shows every live session, **Archived** shows every JSONL on disk whose PTY has exited, and **All** shows both. The view choice persists across reloads. An "Include subagents" toggle inside the Active view surfaces specialist spawns (database-operator, premium-plugin agents, anything spawned with a `--agent` flag) which are hidden by default so the list reflects what you started directly. Each row also carries a small uppercase badge — `admin` for operator-driven sessions, the specialist name (for example `db-op`) for background work — so the source of any row is unambiguous at a glance. The People, Agents, and Tasks rows are graph shortcuts: clicking each opens the artefact-pane Graph filtered to every Person, every public Agent, or every Task in your account respectively, with no side-list, because the graph itself is the result. Public agents become first-class graph entities the moment you create them, with edges to their IDENTITY/SOUL/KNOWLEDGE files, edges to every knowledge document they have access to, and edges from every conversation they have handled, so a single Agents click reveals the whole shape of who knows what and who has been talking to whom. Click an artefact row to open the document. KnowledgeDocuments and your admin agent's templates are editable: type in the document and changes save automatically; specialist agent templates are read-only because they ship with SiteOffice and your edits would be overwritten on the next install. PDF artefacts render inline so you can read them without leaving the pane. If your browser doesn't have a built-in PDF viewer, a Download button appears instead. Artefacts that have no readable file backing them (orphan rows, files removed from disk, unsupported content types) show a one-line banner explaining the skip instead of opening to a blank pane. Click a project row to open the Graph view focused on that project's neighbourhood; clicking a second project swaps the focus rather than stacking on top. The sidebar's right edge is drag-resizable on every admin page (Sessions root, Graph, and Data): drag the handle to widen or narrow the sidebar, and your chosen width is remembered across reloads and shared across all three pages. The drag handle is mounted by each AdminShell consumer rather than by AdminShell itself, so any new admin route must include `<SidebarSplitter />` as a direct child of its `<AdminShell>` to pick up the shared width. The chat and artefact divider is also drag-resizable: drag the line between the columns to make either side wider; double-click it to reset to half of the available width (viewport minus sidebar), clamped to the chat and artefact min-width floors. Your chosen width is remembered across reloads. On wider screens (>1280px) all three panes are visible. The sidebar narrows at 1280px, the artefact pane hides at 1080px (Browser, Data, and Graph then open as full-window pages instead), and the sidebar collapses to a 56px icon rail at 820px. On every viewport the chat header reads left to right as a triptych: a dedicated sidebar toggle (the panel-right icon, which swaps to panel-right-open when the sidebar is showing), the brand mark next to the title in the centre, and the menu burger on the right. This header toggle is the sole sidebar-toggle button; the sidebar itself no longer carries a duplicate. Tap the sidebar toggle to show or hide the sidebar: on phones (<720px) it slides the drawer in or out, on wider screens it collapses or expands the sidebar column. The brand mark in the centre is decorative; clicks go through the dedicated toggle so the affordance is unambiguous. The drawer animation only fires on tap (220ms slide in or out); resizing your window across the 720px boundary snaps the layout without animation, so you never see a half-open flash. At ≤640px the session metadata pane stacks each label above its value instead of the desktop two-column grid, and the row of action buttons (Open in new tab / Download JSONL / View JSONL / Rename / Pin / Archive / End or Purge) collapses behind a single Actions trigger that opens a popover upward from the foot of the pane. Breakpoint summary: >1280px = full sidebar + chat + artefact pane (drag-resizable divider); 1280px→1080px = sidebar narrows; 1080px→820px = artefact pane hides (Browser/Data/Graph open as full-window pages instead); 820px→720px = sidebar collapses to 56px icon rail; ≤720px = sidebar becomes off-canvas drawer (vertical stack of nav, recents list, foot, the same shape as the desktop sidebar, just on top of the chat instead of beside it).
 
-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.
+Page titles are brand-aware: the browser tab shows your product name (e.g. `Real Agent` instead of `SiteOffice`) on every shell — chat, graph, and data — so a non-default brand never leaks the default name in tab strips or browser history.
 
 **Session lifecycle and reconcile model.** The sidebar Sessions list is driven by a single Server-Sent Events feed at `/api/admin/claude-sessions/events`. The session manager watches the two directories Claude Code writes (`${CLAUDE_CONFIG_DIR}/sessions/<pid>.json` for live state, `${CLAUDE_CONFIG_DIR}/projects/<slug>/<sid>.jsonl` for transcripts) and emits `row-created`, `row-updated`, `row-archived`, or `row-removed` deltas to every connected browser tab. Three real delete shapes map to deltas — there is no fourth: PID file gone with JSONL surviving demotes the row to `row-archived`; PID file gone with no JSONL ever written (a hidden spawn that exits before writing a JSONL) emits `row-removed` against the unindexed sessionId; a JSONL deletion against an already-unindexed row also emits `row-removed`. This branch reconciles transient hidden spawns — without it, ghost rows persist after a hidden spawn exits. On connect the manager replays the current row index so a freshly-opened tab catches up without polling, then streams deltas as files change on disk. Two open tabs see the same list within ~300ms of any spawn, status flip, or exit; no refresh button required for state to be current. The legacy `/list` fetch and `useAdminSessions` hook stay mounted to serve the ConversationsModal and the post-action reconcile path in `session-actions`, but the sidebar's visible rows come from the row store, not from `/list`. Each EventSource open emits `[admin-events] client-connected ip=<…> seeded-rows=<n>` server-side and `[admin-ui] session-row-store connected events-received=<n>` in the browser console; transport drops log `[admin-ui] session-row-store reconnect trigger=<auto|manual> attempt=<n> delay-ms=<n>` until the EventSource reattaches. The small dot at the right edge of the Active/Archived/All segmented control is the live-updates indicator: sage when the SSE feed is connected, grey when the feed has dropped. The grey state is an actionable button — clicking it cancels any pending backoff and re-opens the feed immediately, with the click logged as `trigger=manual` so manual retries are distinguishable from automatic ones in the console. The refresh icon at the top of the Sessions list is the operator-recoverable reconcile path against any SSE gap: it fetches `/api/admin/claude-sessions` and passes the authoritative id set to the row store, which evicts any indexed row that the server no longer reports. SSE replay only re-asserts currently-indexed rows and never emits `row-removed` for a row that vanished while disconnected, so without this manual surface a stale row can persist until the operator reloads the tab. Each click logs `[admin-ui] session-row-store reconcile evicted=<n> kept=<n>` when at least one row is evicted, and is silent otherwise.
 

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

@@ -78,9 +78,9 @@ Install verbatim:
 
 Brand decides which premium plugins ship. The brand's `shipsPremiumBundles` field in `brand.json` is the gate; three shapes are supported:
 
-- **omitted / false** — ship nothing from `premium-plugins/` (the legacy Maxy default).
+- **omitted / false** — ship nothing from `premium-plugins/` (the legacy SiteOffice default).
 - **`true`** — ship every bundle under `premium-plugins/*` (Real Agent / `realagent-code`).
-- **`["bundle-a", "bundle-b"]`** — ship only the named bundle directories (Maxy Code's `["venture-studio"]`). Names with no matching directory on disk are silently dropped; non-allowlisted bundles are stripped from any account that was previously stamped with them.
+- **`["bundle-a", "bundle-b"]`** — ship only the named bundle directories (SiteOffice Code's `["venture-studio"]`). Names with no matching directory on disk are silently dropped; non-allowlisted bundles are stripped from any account that was previously stamped with them.
 
 There is no per-account purchase record; the brand decides the shipping set.
 
@@ -95,7 +95,7 @@ There is no per-account purchase record; the brand decides the shipping set.
 
 Some premium plugins are **bundles** — multiple sub-plugins shipped under one directory in `premium-plugins/`, each independently activatable. For example, Real Agent ships 10 sub-plugins covering different aspects of estate agency work. They are all enabled by default. Sub-plugins you don't want active can be turned off individually with "disable <name>"; enabling or disabling individual sub-plugins does not affect the others.
 
-If you ask {{productName}} about a tool from a plugin your brand does not ship (for example, a Maxy install asking about a Real Agent Loop CRM tool), {{productName}} responds with a structured `<tool-surface-error>` envelope naming the missing plugin and the remedy, rather than improvising with a generic alternative.
+If you ask {{productName}} about a tool from a plugin your brand does not ship (for example, a SiteOffice install asking about a Real Agent Loop CRM tool), {{productName}} responds with a structured `<tool-surface-error>` envelope naming the missing plugin and the remedy, rather than improvising with a generic alternative.
 
 **Public agent embedding:** Premium plugins marked as public-eligible have their full content (skills and reference knowledge) embedded in public agent prompts. This means a public agent for a Real Agent member can handle buyer enquiries, book viewings, deliver coaching content, and onboard new applicants — all powered by the premium plugin's domain knowledge. Plugins marked admin-only (listings, vendors, leads, business) are only available to the account owner's admin agent.
 
@@ -137,9 +137,9 @@ To edit an operator-authored skill later, ask {{productName}} to update it — t
 
 ## Brand Templating (for plugin and skill authors)
 
-Skill content, plugin manifests, agent templates, and reference files reference the operator-visible brand name only via the literal `{{productName}}` placeholder. The platform substitutes from `brand.json.productName` at read time — Maxy installs render `Maxy`, Real Agent installs render `Real Agent`, all from the same source content.
+Skill content, plugin manifests, agent templates, and reference files reference the operator-visible brand name only via the literal `{{productName}}` placeholder. The platform substitutes from `brand.json.productName` at read time — SiteOffice installs render `SiteOffice`, Real Agent installs render `Real Agent`, all from the same source content.
 
-**Author rule:** never write the literal string `Maxy` (or any brand name) in shipped skill, plugin, or template content. Use `{{productName}}` whenever the operator should see the brand name. The audit grep `grep -rn "\bMaxy\b" platform/plugins/admin/skills/ platform/plugins/*/skills/ platform/templates/agents/` must return zero matches; a literal brand name is a defect, not a stylistic choice.
+**Author rule:** never write the literal string `SiteOffice` (or any brand name) in shipped skill, plugin, or template content. Use `{{productName}}` whenever the operator should see the brand name. The audit grep `grep -rn "\bMaxy\b" platform/plugins/admin/skills/ platform/plugins/*/skills/ platform/templates/agents/` must return zero matches; a literal brand name is a defect, not a stylistic choice.
 
 The runtime substitution happens at every read site that flows content into a system prompt or operator-visible UI: the admin agent's `plugin-read` tool (references + `PLUGIN.md`), the `skill-load` tool (SKILL.md by skill name — one-call resolver+reader, the canonical primitive for SKILL.md), the public agent's recursive plugin assembly, and `IDENTITY` / `SOUL` / `AGENTS` / `KNOWLEDGE` markdown reads. Missing or empty `productName` hard-fails — there is no fallback to a default brand string. See [.docs/agents.md](../../.docs/agents.md) § "Brand templating" for the full contract.
 
@@ -160,7 +160,7 @@ After this, every `console.error("[your-tool]...")` from any tool in the plugin
 
 **How the tee decides which file to write to:** the platform sets `STREAM_LOG_PATH` as an environment variable on every MCP server spawn, pointing to the conversation-scoped stream log. The MCP server does not know about conversations — it just trusts `STREAM_LOG_PATH`. Multiple concurrent conversations produce multiple concurrent MCP server processes, each teeing to its own file; no cross-conversation leakage.
 
-**Bash commands stream straight into the PTY.** Maxy Code's admin and public chat run on the native Claude Code PTY (Task 287). The per-conversation server-side stream log that the retired web-UI dispatcher tailed is gone; agent-invoked Bash commands (including direct `cloudflared` invocations for Cloudflare setup — Task 288) print their stdout and stderr directly, and the PTY renders the output in chat verbatim.
+**Bash commands stream straight into the PTY.** SiteOffice Code's admin and public chat run on the native Claude Code PTY (Task 287). The per-conversation server-side stream log that the retired web-UI dispatcher tailed is gone; agent-invoked Bash commands (including direct `cloudflared` invocations for Cloudflare setup — Task 288) print their stdout and stderr directly, and the PTY renders the output in chat verbatim.
 
 **Retrieve MCP diagnostic lines for a conversation:**
 

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

@@ -116,7 +116,7 @@ tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
 
 
 **A turn rendered in chat is missing on next page-refresh.** Pre-the 2026-05-07 mandate this was a class of silent failure — Neo4j persists were wrapped in a no-op error catch and a write that threw left the artefact "rendered then disappeared on resume". The 2026-05-07 mandate makes JSONL canonical: the resume route reads the SDK transcript file at `~/.claude/projects/<project-key>/<sessionId>.jsonl` first, supplements from Neo4j, and triggers async heal-on-resume writes for any turn the JSONL has but Neo4j does not. So a refreshed conversation always renders what the SDK saw, regardless of write outcome. If a heal write itself fails, the chat shows a top-of-conversation banner naming the count; if every heal succeeds the resume is silent and the missing rows are quietly restored to Neo4j. Greppable post-deploy invariants in the per-session stream log (`logs/claude-agent-stream-<sessionKey>.log`): `[admin-resume] reason=<…> source=<jsonl|jsonl-missing|neo4j-only>` (one per resume), `[admin-persist] convId=<8> writer=<…> outcome=<ok|fail|skip>` (per persist site), `[admin-persist-heal] convId=<8> turnIndex=<n> outcome=<ok|fail>` (per heal write). To force-audit a specific conversation against its Neo4j projection without re-executing it, run `tsx platform/scripts/admin-persist-audit.ts --conversation-id=<uuid> --account-id=<uuid> --session-id=<uuid>` — non-zero exit + per-divergence `[admin-persist-audit] expected=<message|component> missing reason=neo4j-row-absent` lines name what would have been silently lost pre-mandate.
-**Wrong Claude account answering on a multi-brand device.** On a host running both Maxy and Real Agent, each brand's admin agent reads its own `~/${brand.configDir}/.claude/.credentials.json`; there is no longer a shared `~/.claude/` thrashing them against one another. If a brand reports auth failures or appears to be operating against the wrong subscription, check three things:
+**Wrong Claude account answering on a multi-brand device.** On a host running both SiteOffice and Real Agent, each brand's admin agent reads its own `~/${brand.configDir}/.claude/.credentials.json`; there is no longer a shared `~/.claude/` thrashing them against one another. If a brand reports auth failures or appears to be operating against the wrong subscription, check three things:
 1. `grep "\[claude-auth\] init" ~/.${brand}/logs/server.log | tail -1` — the resolved path must end with `~/.${brand}/.claude/.credentials.json`. If a `[claude-auth] WARN cross-brand-path-detected` line is present, the runtime is still pointing at `~/.claude/`; the brand main service did not pick up the `Environment=CLAUDE_CONFIG_DIR=` setting (re-run the brand installer to refresh the unit file).
 2. `diff <(jq .claudeAiOauth.accessToken ~/.maxy/.claude/.credentials.json) <(jq .claudeAiOauth.accessToken ~/.realagent/.claude/.credentials.json)` — must be non-empty after each brand's operator has run `claude /login` against distinct Anthropic accounts; if it's empty, both brands are still logged in to the same account (operator action, not a code bug).
 3. `grep "\[install\] claude-creds pickup" ~/.${brand}/logs/install-*.log` — fires once on the first post-Task-923 install of any brand and moves the legacy `~/.claude/.credentials.json` into that brand's path. Subsequent brands install with no credentials and require a fresh `claude /login` inside that brand's chat (which writes to the brand-scoped path because the systemd unit env is in scope).

package/payload/platform/plugins/linkedin-extension/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "linkedin-extension",
-  "description": "One-click LinkedIn ingest. Ships a manifest-v3 Chrome extension that injects an Add-to-Maxy pill into `linkedin.com/in/*` profiles and `linkedin.com/messaging/thread/*` DM threads. Each click scrapes the page DOM, POSTs to the admin `linkedin-ingest` route, which dispatches `database-operator` against the generic `document-ingest` skill. The plugin is the **first consumer** of the generic communication-ingest path; every future communication surface (email, Telegram, WhatsApp, group chats, voice memos) plugs into the same backend. Opt-in per brand.",
+  "description": "One-click LinkedIn ingest. Ships a manifest-v3 Chrome extension that injects an Add-to-SiteOffice pill into `linkedin.com/in/*` profiles and `linkedin.com/messaging/thread/*` DM threads. Each click scrapes the page DOM, POSTs to the admin `linkedin-ingest` route, which dispatches `database-operator` against the generic `document-ingest` skill. The plugin is the **first consumer** of the generic communication-ingest path; every future communication surface (email, Telegram, WhatsApp, group chats, voice memos) plugs into the same backend. Opt-in per brand.",
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"

package/payload/platform/plugins/linkedin-extension/PLUGIN.md

@@ -1,6 +1,6 @@
 ---
 name: linkedin-extension
-description: "One-click LinkedIn ingest. Ships a manifest-v3 Chrome extension that injects an Add-to-Maxy pill into `linkedin.com/in/*` profiles and `linkedin.com/messaging/thread/*` DM threads. Each click scrapes the page DOM, POSTs to the admin `linkedin-ingest` route, which dispatches `database-operator` against the generic `document-ingest` skill. The plugin is the **first consumer** of the generic communication-ingest path; every future communication surface (email, Telegram, WhatsApp, group chats, voice memos) plugs into the same backend. Opt-in per brand."
+description: "One-click LinkedIn ingest. Ships a manifest-v3 Chrome extension that injects an Add-to-SiteOffice pill into `linkedin.com/in/*` profiles and `linkedin.com/messaging/thread/*` DM threads. Each click scrapes the page DOM, POSTs to the admin `linkedin-ingest` route, which dispatches `database-operator` against the generic `document-ingest` skill. The plugin is the **first consumer** of the generic communication-ingest path; every future communication surface (email, Telegram, WhatsApp, group chats, voice memos) plugs into the same backend. Opt-in per brand."
 tools: []
 always: false
 embed: false

package/payload/platform/plugins/linkedin-extension/extension/README.md

@@ -1,4 +1,4 @@
-# Maxy LinkedIn Ingest — Chrome Extension
+# SiteOffice LinkedIn Ingest — Chrome Extension
 
 Unpacked-extension dev build. No Chrome Web Store publication.
 
@@ -7,16 +7,16 @@ Unpacked-extension dev build. No Chrome Web Store publication.
 1. `chrome://extensions`
 2. Enable **Developer mode** (top right).
 3. **Load unpacked** → select this `extension/` directory.
-4. Click the new puzzle icon → open **Maxy LinkedIn Ingest** options.
+4. Click the new puzzle icon → open **SiteOffice LinkedIn Ingest** options.
 5. Paste your admin host (e.g. `https://your-tunnel.example.com`) and your admin **session key** (the value of `session_key` on the cookie or query in your admin browser). Save.
 
 ## Use
 
 - Open any `https://www.linkedin.com/in/<slug>/` profile or `https://www.linkedin.com/messaging/thread/<id>/` thread.
-- Click the **Add to Maxy** pill at the top of the page.
+- Click the **Add to SiteOffice** pill at the top of the page.
 - The pill turns green and writes one `:KnowledgeDocument` plus the entities the body assertively states.
 
-If the pill turns amber and shows **Sign in to Maxy**, your session key has expired — open the options page and paste a fresh one.
+If the pill turns amber and shows **Sign in to SiteOffice**, your session key has expired — open the options page and paste a fresh one.
 
 ## File layout
 

package/payload/platform/plugins/linkedin-extension/extension/assets/pill.css

@@ -1,4 +1,4 @@
-/* "Add to Maxy" pill injected into LinkedIn profile and DM thread pages. */
+/* "Add to SiteOffice" pill injected into LinkedIn profile and DM thread pages. */
 
 #maxy-linkedin-pill.maxy-pill {
   position: relative;

package/payload/platform/plugins/linkedin-extension/extension/content/profile.js

@@ -48,7 +48,7 @@
       const detail = (reply && reply.detail) || ''
       console.error(TAG_ERROR + ' reason=' + reason + ' detail=' + detail)
       if (reason === 'auth') {
-        setState(pill, 'auth', 'Sign in to Maxy')
+        setState(pill, 'auth', 'Sign in to SiteOffice')
         pill.onclick = function () { chrome.runtime.openOptionsPage() }
         return
       }
@@ -67,7 +67,7 @@
     pill.id = PILL_ID
     pill.className = 'maxy-pill'
     pill.type = 'button'
-    pill.textContent = 'Add to Maxy'
+    pill.textContent = 'Add to SiteOffice'
     pill.dataset.state = 'idle'
     pill.addEventListener('click', function () { onClick(pill) })
     anchor.prepend(pill)

package/payload/platform/plugins/linkedin-extension/extension/content/thread.js

@@ -50,7 +50,7 @@
       const detail = (reply && reply.detail) || ''
       console.error(TAG_ERROR + ' reason=' + reason + ' detail=' + detail)
       if (reason === 'auth') {
-        setState(pill, 'auth', 'Sign in to Maxy')
+        setState(pill, 'auth', 'Sign in to SiteOffice')
         pill.onclick = function () { chrome.runtime.openOptionsPage() }
         return
       }
@@ -69,7 +69,7 @@
     pill.id = PILL_ID
     pill.className = 'maxy-pill'
     pill.type = 'button'
-    pill.textContent = 'Add to Maxy'
+    pill.textContent = 'Add to SiteOffice'
     pill.dataset.state = 'idle'
     pill.addEventListener('click', function () { onClick(pill) })
     anchor.prepend(pill)

package/payload/platform/plugins/linkedin-extension/extension/manifest.json

@@ -1,8 +1,8 @@
 {
   "manifest_version": 3,
-  "name": "Maxy LinkedIn Ingest",
+  "name": "SiteOffice LinkedIn Ingest",
   "version": "0.1.0",
-  "description": "Add an Add-to-Maxy pill to LinkedIn profiles and DM threads. One click captures the page and posts to your Maxy admin.",
+  "description": "Add an Add-to-SiteOffice pill to LinkedIn profiles and DM threads. One click captures the page and posts to your SiteOffice admin.",
   "permissions": ["storage", "activeTab"],
   "host_permissions": ["https://www.linkedin.com/*"],
   "background": {
@@ -27,6 +27,6 @@
     "open_in_tab": true
   },
   "action": {
-    "default_title": "Maxy LinkedIn Ingest — open options"
+    "default_title": "SiteOffice LinkedIn Ingest — open options"
   }
 }

package/payload/platform/plugins/linkedin-extension/extension/options/options.html

@@ -2,7 +2,7 @@
 <html lang="en">
   <head>
     <meta charset="utf-8" />
-    <title>Maxy LinkedIn Ingest — Options</title>
+    <title>SiteOffice LinkedIn Ingest — Options</title>
     <style>
       body { font: 14px/1.5 -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; max-width: 480px; margin: 32px auto; padding: 0 16px; color: #111; }
       h1 { font-size: 18px; margin: 0 0 12px; }
@@ -16,8 +16,8 @@
     </style>
   </head>
   <body>
-    <h1>Maxy LinkedIn Ingest</h1>
-    <p>Point the extension at your Maxy admin host and paste your admin session key. The pill on LinkedIn will then post one-click captures to your admin.</p>
+    <h1>SiteOffice LinkedIn Ingest</h1>
+    <p>Point the extension at your SiteOffice admin host and paste your admin session key. The pill on LinkedIn will then post one-click captures to your admin.</p>
 
     <label for="admin-host">Admin host</label>
     <input id="admin-host" type="url" placeholder="https://your-tunnel.example.com" />

package/payload/platform/plugins/linkedin-import/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "linkedin-import",
-  "description": "Import a LinkedIn Basic Data Export into the Maxy Neo4j graph. Skill-only plugin owned by the librarian specialist. Opt-in per brand — not enabled by default.",
+  "description": "Import a LinkedIn Basic Data Export into the SiteOffice Neo4j graph. Skill-only plugin owned by the librarian specialist. Opt-in per brand — not enabled by default.",
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"