@rubytech/create-siteoffice-code 0.1.263 → 0.1.265

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what SiteOffice ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:1a53491b6e8b0d6ee4c3e7d648e48e6599de88d5280e7b8b5851c7d2ce3f4b44
+content-hash: sha256:4689ef665b110bf635cf207902292849ab66cb6af548410fe5b49f1364c64d86
 brand: siteoffice-code
 product-name: SiteOffice
 ---
@@ -15,27 +15,27 @@ This skill is generated. Its body is the concatenated source markdown for every
 When you load this skill to ground a factual claim, cite the `Source:` URL printed above the block you drew from. The URL is the canonical public docs page (https://siteoffice.online); relay it as a markdown link in your reply. Training-data recall is not a permitted source — the body below is.
 
 ---
-# Maxy Documentation — full corpus
+# SiteOffice Documentation — full corpus
 
-Concatenated source markdown for every public Maxy docs page. Pages are separated by `---` and labelled with their canonical URL.
+Concatenated source markdown for every public SiteOffice docs page. Pages are separated by `---` and labelled with their canonical URL.
 
 ---
 # Getting Started
 Source: https://docs.getmaxy.com/getting-started.md
 
-# Getting Started with Maxy
+# Getting Started with SiteOffice
 
-## What Maxy Is
+## What SiteOffice Is
 
-Maxy is your Operations Manager — an operations layer that runs on a device on your premises. It plays four roles: follows through on your commitments, responds to your customers at any hour, handles your finances (quotes, invoices, chasing), and manages your picture — what's overdue, what's at risk, what needs a decision.
+SiteOffice is your Operations Manager — an operations layer that runs on a device on your premises. It plays four roles: follows through on your commitments, responds to your customers at any hour, handles your finances (quotes, invoices, chasing), and manages your picture — what's overdue, what's at risk, what needs a decision.
 
-You don't adopt a new system. You just talk, and the organisation happens. Maxy connects to your services — WhatsApp, Telegram, email, your contacts, your calendar — and acts proactively. It remembers context across conversations and takes action on your behalf.
+You don't adopt a new system. You just talk, and the organisation happens. SiteOffice connects to your services — WhatsApp, Telegram, email, your contacts, your calendar — and acts proactively. It remembers context across conversations and takes action on your behalf.
 
-Because Maxy runs locally, your data stays in your home. It never passes through someone else's cloud.
+Because SiteOffice runs locally, your data stays in your home. It never passes through someone else's cloud.
 
 ## The Two Interfaces
 
-**Admin (you)** — accessed at your local address (e.g. `maxy.local:19200`) or remotely via your Cloudflare domain. The admin interface is protected by a PIN. This is where you manage Maxy: configure settings, manage contacts, review activity, and have full conversations. The admin agent has access to all your plugins and can take action.
+**Admin (you)** — accessed at your local address (e.g. `maxy.local:19200`) or remotely via your Cloudflare domain. The admin interface is protected by a PIN. This is where you manage SiteOffice: configure settings, manage contacts, review activity, and have full conversations. The admin agent has access to all your plugins and can take action.
 
 **Public (visitors)** — anyone who reaches your public URL gets the public agent. It handles product enquiries, collects prospect details, and answers questions about your business. It cannot read or write your private data.
 
@@ -44,7 +44,7 @@ Because Maxy runs locally, your data stays in your home. It never passes through
 If your device has no WiFi configured and no ethernet cable connected, it creates a temporary WiFi network for setup:
 
 1. Power on the device and wait about 60 seconds
-2. On your phone, look for a WiFi network called **{ProductName}-Setup** (e.g. `Maxy-Setup`)
+2. On your phone, look for a WiFi network called **{ProductName}-Setup** (e.g. `SiteOffice-Setup`)
 3. Connect to that network — a setup page opens automatically
 4. Select your home WiFi network from the list and enter the password
 5. The device connects to your WiFi and the temporary network disappears
@@ -59,15 +59,15 @@ If you already have ethernet connected, the temporary WiFi network does not appe
 When you first open the admin interface:
 
 1. Set your PIN — this protects access to the admin interface
-2. Connect to Claude — Maxy will guide you through connecting to your Claude account
+2. Connect to Claude — SiteOffice will guide you through connecting to your Claude account
 3. Enter your PIN to log in
-4. Maxy walks you through onboarding: choosing which plugins to activate, connecting to WiFi (skip if already configured via the setup network above), setting up remote access, and configuring your account
+4. SiteOffice walks you through onboarding: choosing which plugins to activate, connecting to WiFi (skip if already configured via the setup network above), setting up remote access, and configuring your account
 
-This setup is resumable — if you close the browser mid-setup, Maxy picks up where you left off next time.
+This setup is resumable — if you close the browser mid-setup, SiteOffice picks up where you left off next time.
 
 After install, a live admin terminal is available inside the Software Update window — your Pi's shell, accessible through the admin UI, for upgrades and any other shell work without needing to SSH.
 
-## How to Use Maxy
+## How to Use SiteOffice
 
 Conversation is the only interface. Type or speak what you need:
 
@@ -77,23 +77,23 @@ Conversation is the only interface. Type or speak what you need:
 - "Send a Telegram message to the team: standup in 10 minutes"
 - "Create a one-pager PDF about our new product launch"
 
-Maxy understands plain language. You don't need to learn commands or navigate menus.
+SiteOffice understands plain language. You don't need to learn commands or navigate menus.
 
 ### Voice Notes
 
-When the text field is empty, a microphone button appears in place of the send button. Tap it to record a voice note — speak naturally and tap send when done. Maxy transcribes your voice note and responds to what you said, the same as if you had typed it. You can also pause and resume recording, or tap the trash icon to discard and start over.
+When the text field is empty, a microphone button appears in place of the send button. Tap it to record a voice note — speak naturally and tap send when done. SiteOffice transcribes your voice note and responds to what you said, the same as if you had typed it. You can also pause and resume recording, or tap the trash icon to discard and start over.
 
-Voice recording requires a secure connection (HTTPS). When accessing Maxy over the local network via HTTP, use the tunnel URL for voice notes.
+Voice recording requires a secure connection (HTTPS). When accessing SiteOffice over the local network via HTTP, use the tunnel URL for voice notes.
 
-You can also drop, paste, or pick an audio file (`.opus`, `.ogg`, `.m4a`, `.mp3`, `.wav`, `.webm`) into the chat composer — for example a voice note forwarded from WhatsApp. The file is transcribed the same way the in-browser recording is, and only the transcript reaches Maxy; the audio itself is discarded after transcription.
+You can also drop, paste, or pick an audio file (`.opus`, `.ogg`, `.m4a`, `.mp3`, `.wav`, `.webm`) into the chat composer — for example a voice note forwarded from WhatsApp. The file is transcribed the same way the in-browser recording is, and only the transcript reaches SiteOffice; the audio itself is discarded after transcription.
 
-## What Maxy Remembers
+## What SiteOffice Remembers
 
-Maxy maintains a memory graph of everything important: contacts, conversations, preferences, relationships, and context. When you tell Maxy something, it stores it. When you ask about something later, it retrieves it.
+SiteOffice maintains a memory graph of everything important: contacts, conversations, preferences, relationships, and context. When you tell SiteOffice something, it stores it. When you ask about something later, it retrieves it.
 
-You can always tell Maxy to remember or forget specific things: "Remember that I prefer morning calls" or "Forget what I said about the Johnson account."
+You can always tell SiteOffice to remember or forget specific things: "Remember that I prefer morning calls" or "Forget what I said about the Johnson account."
 
-## Reaching Your Data When Maxy Is Unavailable
+## Reaching Your Data When SiteOffice Is Unavailable
 
 If the AI is ever unreachable — network outage, API provider down — you can still access your own data through the **Data** item in the admin header menu. It opens a page with two panels:
 
@@ -104,21 +104,21 @@ Everything on this page works without calling any AI service. It's there so your
 
 ## Getting Help
 
-Ask Maxy anything. If you want to know what it can do, just ask: "What can you help me with?" or "How do I set up Telegram?"
+Ask SiteOffice anything. If you want to know what it can do, just ask: "What can you help me with?" or "How do I set up Telegram?"
 
 ---
-# How Maxy Works
+# How SiteOffice Works
 Source: https://docs.getmaxy.com/platform.md
 
-# How Maxy Works
+# How SiteOffice Works
 
 ## The Short Version
 
-Maxy runs on a Raspberry Pi in your home. It uses Claude (Anthropic's AI) as its brain and extends it with plugins — modular capabilities like contacts, Telegram, and memory. Everything stays local: your data, your conversations, your memory graph.
+SiteOffice runs on a Raspberry Pi in your home. It uses Claude (Anthropic's AI) as its brain and extends it with plugins — modular capabilities like contacts, Telegram, and memory. Everything stays local: your data, your conversations, your memory graph.
 
 ## The Raspberry Pi
 
-Maxy is a server that lives on your local network. It's always on, always available, and accessible:
+SiteOffice is a server that lives on your local network. It's always on, always available, and accessible:
 
 - **Locally:** `maxy.local:19200` (or the IP address of your Pi)
 - **Remotely:** via your personal domain, routed through a Cloudflare tunnel
@@ -127,7 +127,7 @@ The Pi runs the web interface, the AI agent, and all the plugin servers. When yo
 
 ## The Two Agents
 
-Maxy runs two agents simultaneously:
+SiteOffice runs two agents simultaneously:
 
 **Admin agent (you)** — full access to all tools and plugins. This is the agent you interact with at your local or remote URL. It can read and write contacts, send Telegram messages, manage your account, and perform any task you have plugins for. Protected by your PIN. Your admin agent runs through your own Claude Code OAuth session — it never bills the Anthropic API. Authentication and SDK details are documented in the developer doc `.docs/platform.md` admin-agent section.
 
@@ -135,7 +135,7 @@ Maxy runs two agents simultaneously:
 
 ## Plugins
 
-Everything Maxy can do is provided by a plugin. Each plugin is a self-contained package:
+Everything SiteOffice can do is provided by a plugin. Each plugin is a self-contained package:
 
 - Behaviour instructions (how the agent should act)
 - Tools (specific actions the agent can take, exposed via MCP servers)
@@ -145,13 +145,13 @@ Everything Maxy can do is provided by a plugin. Each plugin is a self-contained
 
 **Where premium bundle subs live.** Bundle subs (`loop`, `property-data`, `brochures`, etc. inside `real-agent`) live exclusively at `premium-plugins/<bundle>/plugins/<sub>/` and are registered via the resolver's bundle-descent walk. Standalone premiums (no `BUNDLE.md`, e.g. `writer-craft`, `teaching`, `venture-studio`) live exclusively at `premium-plugins/<name>/` and are registered via the resolver's dual-root scan (`platform/plugins/` and `premium-plugins/` are both `pluginsRoots`). Neither shape is flat-copied into `platform/plugins/<name>/`. A divergent flat copy of a bundle sub is treated as an operator override: the resolver refuses to boot with `boot-failed reason=mcp-plugin-duplicate <plugin> declared by more than one plugins root: <pathA> (sha=…) vs <pathB> (sha=…)` so the operator can `sha256sum` both paths and remove the stale one. Byte-identical bundle-sub flat copies left over from installer versions that flat-copied bundle subs are reaped on the first post-upgrade boot (`[premium-auto-deliver] reaped sub=<name> reason=duplicate-of-premium-tree`). Standalone flat copies (leaked by the pre-fix `autoDeliverPremiumPlugins` standalone branch) are reaped unconditionally — there is no documented override path for standalones at `platform/plugins/<name>/` — and the reaper logs `[premium-auto-deliver] reaped standalone=<name> matches-source=<true|false>` so divergent reaps leave a forensic trail.
 
-Plugins are installed and managed through conversation. You can add marketplace plugins (like Stripe) or use Maxy's built-in ones (contacts, memory, Telegram).
+Plugins are installed and managed through conversation. You can add marketplace plugins (like Stripe) or use SiteOffice's built-in ones (contacts, memory, Telegram).
 
 ## Roles
 
-Maxy ships twelve roles it can dispatch for specific tasks — like members of your team. You don't need to configure or manage them — Maxy decides when to use each role and handles everything automatically. You may see activity like "Dispatching personal-assistant..." in the chat timeline when this happens.
+SiteOffice ships twelve roles it can dispatch for specific tasks — like members of your team. You don't need to configure or manage them — SiteOffice decides when to use each role and handles everything automatically. You may see activity like "Dispatching personal-assistant..." in the chat timeline when this happens.
 
-The catalogue below is what the platform ships. It is not evidence of what is installed on the current account. For the live install set on this account, ask Maxy to call `capabilities-here`.
+The catalogue below is what the platform ships. It is not evidence of what is installed on the current account. For the live install set on this account, ask SiteOffice to call `capabilities-here`.
 
 | Role | What it does |
 |------|-------------|
@@ -168,13 +168,13 @@ The catalogue below is what the platform ships. It is not evidence of what is in
 | Research Assistant | Researches topics online, manages your knowledge graph, and produces supporting visuals. |
 | Typed Edge Classifier | Reads recently-written prose nodes and writes typed edges from a closed allowlist. |
 
-Roles are installed during setup and listed when Maxy introduces itself. Some premium bundles add their own specialists (e.g. the `real-agent` bundle adds a listing curator, negotiator, valuer, compliance officer, and buyer-enquiry public agent). Roles installed mid-session become active from the next session.
+Roles are installed during setup and listed when SiteOffice introduces itself. Some premium bundles add their own specialists (e.g. the `real-agent` bundle adds a listing curator, negotiator, valuer, compliance officer, and buyer-enquiry public agent). Roles installed mid-session become active from the next session.
 
 ## Memory
 
-Maxy maintains a graph database (Neo4j) of everything you've told it. People, conversations, preferences, and context are stored as connected nodes. When you ask Maxy something, it searches this graph to retrieve relevant context before responding.
+SiteOffice maintains a graph database (Neo4j) of everything you've told it. People, conversations, preferences, and context are stored as connected nodes. When you ask SiteOffice something, it searches this graph to retrieve relevant context before responding.
 
-**The recording loop.** Maxy dispatches `database-operator` inline at its own discretion when a write must complete before the assistant response ends. The full graph-completeness sweep runs on demand: when you invoke the `/insight` admin skill, it runs a four-pass instruction and Maxy walks the session for any node, edge, or commitment that was discussed but not written in-flight, dispatches one `database-operator` Task per candidate write, then carries on in the same session.
+**The recording loop.** SiteOffice dispatches `database-operator` inline at its own discretion when a write must complete before the assistant response ends. The full graph-completeness sweep runs on demand: when you invoke the `/insight` admin skill, it runs a four-pass instruction and SiteOffice walks the session for any node, edge, or commitment that was discussed but not written in-flight, dispatches one `database-operator` Task per candidate write, then carries on in the same session.
 
 The memory graph is stored on your Pi. It never leaves your network.
 
@@ -192,9 +192,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.
 
@@ -292,7 +292,7 @@ Messages you write yourself (e.g. typing directly in WhatsApp) are not marked
 
 ## Session Slot Safeguards
 
-Maxy runs each chat — yours and every visitor's — as a separate `claude` process on your Pi. Three safeguards keep these processes from piling up:
+SiteOffice runs each chat — yours and every visitor's — as a separate `claude` process on your Pi. Three safeguards keep these processes from piling up:
 
 - **Specialist cap.** Background specialists (`database-operator`, `content-producer`, etc.) are limited to three running at once. If you ask for a fourth while three are still working, the oldest idle one is shut down first. If all three are actively running, the request is rejected with `specialist-cap-reached`.
 - **Operator reserve.** Two slots are always held back for *you* — your own chats and one-off tasks. Specialist work that would consume the last reserved slot is rejected with `operator-slots-reserved`. Your interactive chats are never blocked.
@@ -314,17 +314,17 @@ Source: https://docs.getmaxy.com/plugins-guide.md
 
 ## What a Plugin Is
 
-A plugin extends what Maxy can do. Each plugin adds a focused capability — contacts management, Telegram messaging, scheduling, email, research. Plugins are modular: you enable only what you need.
+A plugin extends what SiteOffice can do. Each plugin adds a focused capability — contacts management, Telegram messaging, scheduling, email, research. Plugins are modular: you enable only what you need.
 
-Maxy's own capabilities are plugins too. Marketplace plugins (like Stripe) work the same way — Maxy manages all of them through conversation.
+SiteOffice's own capabilities are plugins too. Marketplace plugins (like Stripe) work the same way — SiteOffice manages all of them through conversation.
 
-The tables below are the install catalogue — every plugin the platform can ship. They are not evidence of what is enabled on the current account. For the live install set, ask Maxy to call `capabilities-here`.
+The tables below are the install catalogue — every plugin the platform can ship. They are not evidence of what is enabled on the current account. For the live install set, ask SiteOffice to call `capabilities-here`.
 
 ## Plugin Groups
 
 ### Core (always active)
 
-These are part of Maxy's foundation and cannot be disabled:
+These are part of SiteOffice's foundation and cannot be disabled:
 
 | Plugin | What it does |
 |--------|-------------|
@@ -341,7 +341,7 @@ These are part of Maxy's foundation and cannot be disabled:
 | `prompt-optimiser` | Prompt optimiser — two modes. Chat-app mode turns a rough draft or task description into a single finished, copy-pasteable prompt tuned for Opus 4.7 adaptive thinking (claude.ai, Mac, iOS). In-session mode is applied automatically: a standing `UserPromptSubmit` directive hook (`admin/hooks/prompt-optimiser-directive.sh`) injects context every turn telling the admin agent to restate each non-trivial prompt through this skill and act on the restatement, skipped for one-word confirmations, slash-commands, and direct continuations. Compliance is behavioural — the hook steers the agent, it cannot force the skill call. |
 | `url-get` | Faithful page retrieval — fetches a server-rendered page, writes a verbatim markdown copy to an account-scoped reference file (no model in the path, so no copyright refusal), and returns the cleaned page text (capped) plus the file path. No summary and no subprocess: a caller that wants a summary invokes url-get from a delegated subagent. Use instead of WebFetch when a faithful copy is needed (e.g. ingesting your own published writing). |
 
-### Maxy Plugins (user-selectable)
+### SiteOffice Plugins (user-selectable)
 
 These are enabled during onboarding and can be added or removed at any time. Some plugins enhance a specific specialist role — when enabled, that specialist gains additional capabilities.
 
@@ -390,9 +390,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.
 
@@ -403,39 +403,39 @@ There is no per-account purchase record; the brand decides the shipping set.
 | `writer-craft` | Skills + Agent | Manuscript review and writing craft — story architecture, reader engagement, prose craft, editorial practice, and multi-level review | No — writing craft serves the author |
 | `venture-studio` | Skills + Agent | Founding-a-business workflow — office-hours discovery, brand pack, zero-to-prototype validation, and the full investor data room (business plan, prospectus, term sheet, deck blueprint, A4 print pipeline). Pre-seeds a `Project` with one `Task` per artefact so nothing gets forgotten. | No — founder-facing only |
 
-**How it works:** Every boot Maxy delivers the brand's premium plugins from staging into `platform/plugins/` and stamps `enabledPlugins` against what is actually on disk. No conversation needed — the brand's full set is active from the first turn after install. Updates and reinstalls re-deliver from staging.
+**How it works:** Every boot SiteOffice delivers the brand's premium plugins from staging into `platform/plugins/` and stamps `enabledPlugins` against what is actually on disk. No conversation needed — the brand's full set is active from the first turn after install. Updates and reinstalls re-deliver from staging.
 
 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 Maxy about a tool from a plugin your brand does not ship (for example, a Maxy install asking about a Real Agent Loop CRM tool), Maxy 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 SiteOffice about a tool from a plugin your brand does not ship (for example, a SiteOffice install asking about a Real Agent Loop CRM tool), SiteOffice 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.
 
-Some premium plugins include specialist helpers that Maxy can dispatch for specific tasks (e.g. the writer-craft plugin includes a manuscript reviewer). These are activated automatically when the plugin is enabled.
+Some premium plugins include specialist helpers that SiteOffice can dispatch for specific tasks (e.g. the writer-craft plugin includes a manuscript reviewer). These are activated automatically when the plugin is enabled.
 
-Some premium plugins include pre-built public agent templates — ready-made configurations for customer-facing agents. When you enable the plugin, Maxy shows you what templates are available and offers to create agents from them. You review and approve every file before the agent is created. The template is a starting point — you can edit the identity, personality, plugins, and settings to make it yours. The result is a standard public agent, indistinguishable from one you created from scratch.
+Some premium plugins include pre-built public agent templates — ready-made configurations for customer-facing agents. When you enable the plugin, SiteOffice shows you what templates are available and offers to create agents from them. You review and approve every file before the agent is created. The template is a starting point — you can edit the identity, personality, plugins, and settings to make it yours. The result is a standard public agent, indistinguishable from one you created from scratch.
 
 Some premium plugins ship pre-built workflows that are created when the plugin is enabled. These workflows are fully yours — you can inspect, edit, run, and manage them through conversation, exactly like workflows you create yourself. The plugin provides the starting point; you own the result.
 
-**If a premium plugin ever stops working** — `documents`, `teaching`, anything else you've paid for — and Maxy responds as if it doesn't have those tools, the platform's health check (`/api/health.missingPlugins`) will name the affected plugin. Tell Maxy "deliver the {{plugin}} plugin" — it re-runs the same delivery step that fires automatically at session start. If the plugin isn't in the device's staging area, re-run the installer for this brand.
+**If a premium plugin ever stops working** — `documents`, `teaching`, anything else you've paid for — and SiteOffice responds as if it doesn't have those tools, the platform's health check (`/api/health.missingPlugins`) will name the affected plugin. Tell SiteOffice "deliver the {{plugin}} plugin" — it re-runs the same delivery step that fires automatically at session start. If the plugin isn't in the device's staging area, re-run the installer for this brand.
 
 ## Choosing Plugins
 
-During first-time setup, Maxy presents a plugin selection screen where you choose which plugins to activate. Core plugins are pre-selected and locked. Recommended plugins are pre-selected but optional. You can change your mind later.
+During first-time setup, SiteOffice presents a plugin selection screen where you choose which plugins to activate. Core plugins are pre-selected and locked. Recommended plugins are pre-selected but optional. You can change your mind later.
 
 ## Adding or Removing Plugins
 
-Tell Maxy:
+Tell SiteOffice:
 
 - "Enable the Telegram plugin"
 - "Add the Stripe plugin"
 - "Disable the deep-research plugin"
 
-Maxy handles the installation or removal. If the plugin requires any setup (API keys, bot tokens, configuration), Maxy will walk you through it.
+SiteOffice handles the installation or removal. If the plugin requires any setup (API keys, bot tokens, configuration), SiteOffice will walk you through it.
 
 ## Viewing Your Plugins
 
-Ask Maxy: "What plugins do I have?" or "List my plugins."
+Ask SiteOffice: "What plugins do I have?" or "List my plugins."
 
 ## Operator-Authored Plugins (skill-builder output)
 
@@ -443,15 +443,15 @@ Skills you create at runtime through the admin `skill-builder` skill are saved o
 
 These operator-authored plugins survive reinstall because the installer's wipe zone excludes `data/`. At admin session start the platform mirrors `data/accounts/{accountId}/plugins/*` into the runtime plugins directory so the same `parsePluginFrontmatter` / `assemblePublicPluginContent` / `loadEmbeddedPlugins` loaders that read shipped and premium plugins also pick up operator-authored ones — no special-case loader path. The admin agent sees every operator skill by default; per-skill `publicEmbed: true|false` controls which skills surface to the public agent.
 
-To edit an operator-authored skill later, ask Maxy to update it — the admin agent re-runs `store-skill` for the same `pluginName`/`skillName` and the new content overwrites in place. To remove one, delete the directory under `data/accounts/{accountId}/plugins/{pluginName}/skills/{skillName}/` (or the whole plugin) — the next session start re-mirrors the remaining skills only.
+To edit an operator-authored skill later, ask SiteOffice to update it — the admin agent re-runs `store-skill` for the same `pluginName`/`skillName` and the new content overwrites in place. To remove one, delete the directory under `data/accounts/{accountId}/plugins/{pluginName}/skills/{skillName}/` (or the whole plugin) — the next session start re-mirrors the remaining skills only.
 
 `pluginName` collisions with shipped plugin names are refused by `store-skill` with a structured error. See [.docs/agents.md](../../../../.docs/agents.md) § "Operator-authored skills as plugin files" for the full contract.
 
 ## 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 `Maxy` 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 `SiteOffice` 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 `Maxy` 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 `SiteOffice` 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.
 
@@ -472,7 +472,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:**
 
@@ -503,9 +503,9 @@ A third layer closes the same gap from the platform side: when `claude-agent.ts`
 # Install Overview
 Source: https://docs.getmaxy.com/install.md
 
-# Installing Maxy Code
+# Installing SiteOffice Code
 
-Maxy Code installs from one npm one-liner on every supported host. The host you choose determines the supervisor (systemd vs launchd), the Cloudflare flow (provisioned vs operator-opt-in), and the VNC requirement (Pi/cloud VM only).
+SiteOffice Code installs from one npm one-liner on every supported host. The host you choose determines the supervisor (systemd vs launchd), the Cloudflare flow (provisioned vs operator-opt-in), and the VNC requirement (Pi/cloud VM only).
 
 | Host | Doc | Supervisor | Cloudflare tunnel | Hostname flag |
 |---|---|---|---|---|
@@ -521,7 +521,7 @@ Engineers reading the codebase should also see [../deployment.md](../deployment.
 # macOS Install
 Source: https://docs.getmaxy.com/install/macos.md
 
-# Installing Maxy Code on macOS
+# Installing SiteOffice Code on macOS
 
 End-to-end install for a fresh macOS account on Apple Silicon (M-series). Every command is copy-pasteable and uses auto-yes flags so nothing prompts interactively.
 
@@ -653,7 +653,7 @@ macOS is the lightweight surface. Compared with the Pi install, the macOS path d
 
 The full operator-side fresh-Mac smoke is tracked separately (see `.tasks/339-macos-installer-smoke-task-297.md`). The headline pass criteria:
 
-1. Install on a clean account with no prior Maxy footprint completes and prints an admin URL.
+1. Install on a clean account with no prior SiteOffice footprint completes and prints an admin URL.
 2. The admin UI opens at that URL and the chat surface is interactive.
 3. Reboot — the URL is reachable again after login without any manual action.
 4. Run `--hostname <name>` on a second install path; the URL switches to `<name>.local`.
@@ -665,7 +665,7 @@ If any step fails, attach `$HOME/.<brand>/logs/create-maxy-<timestamp>.log` to t
 # Raspberry Pi Install
 Source: https://docs.getmaxy.com/install/pi.md
 
-# Installing Maxy Code on a Raspberry Pi
+# Installing SiteOffice Code on a Raspberry Pi
 
 End-to-end install for a fresh Raspberry Pi 5 (16GB) on Ubuntu Server 24.04 (64-bit). Every command is copy-pasteable and uses auto-yes flags so nothing prompts interactively. The same flow works on a Pi 4 (8GB). For a Hetzner Cloud install (CAX31 ARM64 ~€13/mo), see [hetzner.md](hetzner.md) — same installer, slightly different bootstrap for the Cloudflare tunnel because there is no LAN to the operator.
 
@@ -807,7 +807,7 @@ npx -y @rubytech/create-realagent-code@latest --uninstall
 
 Fresh-Pi smoke pass criteria:
 
-1. Install on a clean Ubuntu Server 24.04 image with no prior Maxy footprint completes, prints a LAN URL, and the systemd user-service is `active (running)`.
+1. Install on a clean Ubuntu Server 24.04 image with no prior SiteOffice footprint completes, prints a LAN URL, and the systemd user-service is `active (running)`.
 2. The LAN URL `http://<hostname>.local:<port>` opens the admin UI and the chat surface is interactive.
 3. Cloudflare setup driven by the `cloudflare` plugin's `cloudflare` skill ends with `curl -I https://<hostname>.<your-zone>` returning `HTTP/2 200` from outside the LAN.
 4. Reboot — both URLs are reachable again after boot without any manual action.
@@ -820,7 +820,7 @@ If any step fails, attach `$HOME/.<brand>/logs/install-<timestamp>.log` to the r
 # Hetzner Cloud Install
 Source: https://docs.getmaxy.com/install/hetzner.md
 
-# Installing Maxy Code on a Hetzner Cloud server
+# Installing SiteOffice Code on a Hetzner Cloud server
 
 End-to-end install for a fresh Hetzner Cloud server on the **CAX31** tier (8 vCPU Ampere Altra ARM64, 16 GB RAM, 160 GB NVMe, ~€13/mo). CAX is the right tier because it is ARM64, identical chip family to the Raspberry Pi 5, so every binary built by the installer compiles the same way it does on the Pi. Every command is copy-pasteable and uses auto-yes flags so nothing prompts interactively.
 
@@ -1025,7 +1025,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`. |
@@ -1141,15 +1141,15 @@ Each public agent has one of two access modes:
 
 ## How to Set It Up
 
-Tell Maxy: "Set my public agent to gated access" or "Make the coaching agent invitation-only."
+Tell SiteOffice: "Set my public agent to gated access" or "Make the coaching agent invitation-only."
 
-Maxy flips the agent's access mode. The next visitor to your public URL sees a sign-in screen instead of the chat.
+SiteOffice flips the agent's access mode. The next visitor to your public URL sees a sign-in screen instead of the chat.
 
 ## Inviting Visitors
 
-Tell Maxy: "Invite sarah@client.co to the coaching agent."
+Tell SiteOffice: "Invite sarah@client.co to the coaching agent."
 
-Maxy creates an invitation and emails the visitor a magic link. At creation time the invitation is stamped with a one-off `sliceToken` — that token is what binds every per-visitor memory write to this specific invitation for the life of the invite.
+SiteOffice creates an invitation and emails the visitor a magic link. At creation time the invitation is stamped with a one-off `sliceToken` — that token is what binds every per-visitor memory write to this specific invitation for the life of the invite.
 
 Only email invitations are supported. Phone, OTP, and password flows are not part of the current build.
 
@@ -1170,7 +1170,7 @@ You can read what's in a visitor's slice via the cypher tools in conversation
 
 ## Managing Access
 
-All access management is done through conversation with Maxy:
+All access management is done through conversation with SiteOffice:
 
 - "Who has access to my coaching agent?" — lists active visitors and their `sliceToken`.
 - "Revoke Sarah's access" — flips her grant to revoked AND immediately drops her active session, so she cannot continue talking on a live cookie. Her slice's historical memory stays in the graph; you can purge it separately if needed.
@@ -1185,19 +1185,19 @@ When a visitor is authenticated, your public agent knows their name and contact
 
 ## Action Approval
 
-External-facing actions — sending emails, WhatsApp messages, Telegram messages, and erasing contacts — require your approval before Maxy executes them. This is human oversight as required by the EU AI Act.
+External-facing actions — sending emails, WhatsApp messages, Telegram messages, and erasing contacts — require your approval before SiteOffice executes them. This is human oversight as required by the EU AI Act.
 
-When Maxy needs to send a message or perform a consequential action, it drafts the action and queues it for your review. You'll see it in your next chat turn:
+When SiteOffice needs to send a message or perform a consequential action, it drafts the action and queues it for your review. You'll see it in your next chat turn:
 
-- "Approve it" — Maxy executes the action immediately
+- "Approve it" — SiteOffice executes the action immediately
 - "Reject it" — the action is cancelled
-- "Change the subject to X" — Maxy modifies the action and executes the edited version
+- "Change the subject to X" — SiteOffice modifies the action and executes the edited version
 
 Internal operations (creating tasks, updating contacts, searching memory) execute automatically without approval.
 
 ### Changing the Policy
 
-Tell Maxy to change which actions require approval:
+Tell SiteOffice to change which actions require approval:
 
 - "Auto-send follow-up emails from now on" — emails execute without approval
 - "Require approval for all WhatsApp messages" — restores the default gating
@@ -1207,7 +1207,7 @@ Changes are per-account and take effect immediately.
 
 ## Filesystem Access (SMB Share)
 
-Brand isolation extends to the device filesystem. Every Maxy install provisions an SMB share scoped to that brand's install folder, credentialled by the brand's install owner and the Maxy PIN. A device that hosts more than one brand carries one share per brand; tearing one brand down never exposes another brand's files. See [Samba Share](./samba.md) for the credential model, per-OS mount syntax, and peer-brand lifecycle.
+Brand isolation extends to the device filesystem. Every SiteOffice install provisions an SMB share scoped to that brand's install folder, credentialled by the brand's install owner and the SiteOffice PIN. A device that hosts more than one brand carries one share per brand; tearing one brand down never exposes another brand's files. See [Samba Share](./samba.md) for the credential model, per-OS mount syntax, and peer-brand lifecycle.
 
 ---
 # Settings
@@ -1217,36 +1217,36 @@ Source: https://docs.getmaxy.com/settings.md
 
 ## Output Style
 
-Controls how Maxy communicates with you.
+Controls how SiteOffice communicates with you.
 
 | Style | Behaviour |
 |-------|-----------|
 | `default` | Concise, direct responses — gets to the point |
 | `explanatory` | More detailed responses with educational context — explains reasoning and trade-offs |
 
-**Changing output style:** Tell Maxy "Switch to explanatory mode" or "Use default output style."
+**Changing output style:** Tell SiteOffice "Switch to explanatory mode" or "Use default output style."
 
 Changes take effect on the next session. The current session continues with the existing style.
 
 ## Effort Level
 
-Controls how much work Maxy puts into each task — specifically, how many steps it takes before stopping and checking with you.
+Controls how much work SiteOffice puts into each task — specifically, how many steps it takes before stopping and checking with you.
 
 | Level | Max turns | Use when |
 |-------|-----------|----------|
 | `low` | 5 | Quick questions, simple lookups |
 | `medium` | 10 | Standard tasks — most daily use |
 | `high` | 20 | Complex multi-step tasks |
-| `auto` | 20 | Let Maxy decide (same ceiling as high) |
+| `auto` | 20 | Let SiteOffice decide (same ceiling as high) |
 | `max` | 40 | Long autonomous workflows |
 
-**Changing effort level:** Tell Maxy "Set effort to high" or "Use low effort mode."
+**Changing effort level:** Tell SiteOffice "Set effort to high" or "Use low effort mode."
 
 Changes take effect on the next session.
 
 ## Thinking View
 
-Controls how Maxy's thinking process is displayed in the chat.
+Controls how SiteOffice's thinking process is displayed in the chat.
 
 | Mode | Behaviour |
 |------|-----------|
@@ -1254,25 +1254,25 @@ Controls how Maxy's thinking process is displayed in the chat.
 | `expanded` | Everything shown expanded — thinking, tool use, and results |
 | `collapsed` | Everything collapsed — compact view, expand on tap |
 
-**Changing thinking view:** Tell Maxy "Show thinking by default", "Show everything expanded", or "Hide thinking."
+**Changing thinking view:** Tell SiteOffice "Show thinking by default", "Show everything expanded", or "Hide thinking."
 
 Changes take effect on the next session.
 
 ## Viewing Current Settings
 
-Ask Maxy: "What are my current settings?" or "What output style am I using?"
+Ask SiteOffice: "What are my current settings?" or "What output style am I using?"
 
 ## Default Agent
 
 Controls which public agent serves the root URL (`/`). Visitors who go to your public site without specifying an agent slug see this agent.
 
-**Changing the default agent:** Tell Maxy "Make sales the default agent" or "Set the default to support."
+**Changing the default agent:** Tell SiteOffice "Make sales the default agent" or "Set the default to support."
 
 The change takes effect on the next page load. The previous default agent remains accessible at its `/{slug}` URL.
 
 ## Account Preferences
 
-You can ask Maxy to show or change any of the following:
+You can ask SiteOffice to show or change any of the following:
 
 - Default agent (which public agent serves the root URL)
 - Admin model (which Claude model powers the admin agent)
@@ -1282,19 +1282,19 @@ You can ask Maxy to show or change any of the following:
 - Context mode
 - Enabled plugins
 
-Tell Maxy what you want to change and it handles the rest.
+Tell SiteOffice what you want to change and it handles the rest.
 
 ## PIN
 
-Your admin PIN is set during initial setup. To change it, ask Maxy: "Change my admin PIN."
+Your admin PIN is set during initial setup. To change it, ask SiteOffice: "Change my admin PIN."
 
-Maxy will ask for your current PIN to verify, then set the new one.
+SiteOffice will ask for your current PIN to verify, then set the new one.
 
 ## Adding admins
 
-To add another admin to your account, tell Maxy: "Add {name} as an admin with PIN {pin}." Maxy creates the device-level user entry (`users.json`), the account-level role entry (`account.json` admins[]), and the graph identity (Neo4j AdminUser node) — the three stores stay in lockstep. If any leg fails, Maxy returns an error naming exactly which store is dirty and what was already written; the admin record is partial and may need manual reconciliation. PINs are unique across all users on the device — a new admin needs a PIN no one else on the device is using.
+To add another admin to your account, tell SiteOffice: "Add {name} as an admin with PIN {pin}." SiteOffice creates the device-level user entry (`users.json`), the account-level role entry (`account.json` admins[]), and the graph identity (Neo4j AdminUser node) — the three stores stay in lockstep. If any leg fails, SiteOffice returns an error naming exactly which store is dirty and what was already written; the admin record is partial and may need manual reconciliation. PINs are unique across all users on the device — a new admin needs a PIN no one else on the device is using.
 
-If you ask Maxy to add an admin with a specific PIN and it returns a tier-cap or PIN-collision error, repeat the request with the same PIN every time you retry — otherwise Maxy auto-generates a different 4-digit PIN, silently substituting what you asked for.
+If you ask SiteOffice to add an admin with a specific PIN and it returns a tier-cap or PIN-collision error, repeat the request with the same PIN every time you retry — otherwise SiteOffice auto-generates a different 4-digit PIN, silently substituting what you asked for.
 
 ---
 # Contacts
@@ -1304,17 +1304,17 @@ Source: https://docs.getmaxy.com/contacts-guide.md
 
 ## What a Contact Is
 
-A contact is a Person node in Maxy's memory graph. Each person has a first name and at least one identifier — email address, phone number, or both. Optional fields include last name and job title. Contacts are linked to conversations, other people, and business context.
+A contact is a Person node in SiteOffice's memory graph. Each person has a first name and at least one identifier — email address, phone number, or both. Optional fields include last name and job title. Contacts are linked to conversations, other people, and business context.
 
 ## Adding a Contact
 
-Tell Maxy naturally:
+Tell SiteOffice naturally:
 
 - "Add John Smith to my contacts — he's a potential client I met at the conference"
 - "Create a contact for sarah@acme.com, her name is Sarah Chen, she's the head of procurement at Acme"
 - "Add Hazel to contacts, phone +27747309676, she's a virtual assistant"
 
-Maxy will extract the details and confirm the record before saving.
+SiteOffice will extract the details and confirm the record before saving.
 
 Required: first name and at least one of email or phone number. Everything else is optional but useful.
 
@@ -1327,11 +1327,11 @@ Ask naturally:
 - "Find the contact from Acme procurement"
 - "Look up +27747309676"
 
-Maxy searches by name, email, phone number, or any detail you provide.
+SiteOffice searches by name, email, phone number, or any detail you provide.
 
 ## Updating a Contact
 
-Tell Maxy what changed:
+Tell SiteOffice what changed:
 
 - "Update John Smith's email to john@newcompany.com"
 - "Add a note to Sarah Chen's record: prefers evening calls"
@@ -1351,27 +1351,27 @@ To remove a single contact from the graph:
 - "Remove the duplicate contact for Sarah Chen"
 - "Delete the contact with email dan@example.com"
 
-Maxy will confirm which Person record matches, then remove the Person node and its direct relationships (e.g. links to conversations, other people) using a graph detach-delete. The contact is gone after confirmation — this cannot be undone.
+SiteOffice will confirm which Person record matches, then remove the Person node and its direct relationships (e.g. links to conversations, other people) using a graph detach-delete. The contact is gone after confirmation — this cannot be undone.
 
 This is different from GDPR erasure (`contact-erase`). Deleting a contact removes the Person node from the graph only. GDPR erasure cascades across all data stores — access credentials, conversations, messages, and emails — to satisfy an Article 17 right-to-erasure request. Use "delete" for routine contact cleanup; use "erase all data" when fulfilling a data subject's erasure request.
 
 ## Exporting Contact Data (GDPR Subject Access)
 
-When a person requests a copy of all data held about them, ask Maxy:
+When a person requests a copy of all data held about them, ask SiteOffice:
 
 - "Export all data we hold on john@example.com"
 - "Show me everything we know about +447700900123"
 
-Maxy gathers the Person record, access credentials, conversation history, and emails into a single structured document. The output is self-contained — it can be handed directly to the data subject to satisfy an Article 15 request.
+SiteOffice gathers the Person record, access credentials, conversation history, and emails into a single structured document. The output is self-contained — it can be handed directly to the data subject to satisfy an Article 15 request.
 
 ## Erasing Contact Data (GDPR Right to Erasure)
 
-When a person requests deletion of all their data, ask Maxy:
+When a person requests deletion of all their data, ask SiteOffice:
 
 - "Delete all data we hold on john@example.com"
 - "Erase everything for Sarah Chen"
 
-Maxy first shows a preview of what would be deleted (counts per data type). Confirm the deletion to proceed. The erasure cascade covers:
+SiteOffice first shows a preview of what would be deleted (counts per data type). Confirm the deletion to proceed. The erasure cascade covers:
 
 - The Person record itself
 - All access credentials (AccessGrant nodes)
@@ -1407,24 +1407,24 @@ The graph is the brain, and every turn that needs to know something runs the sam
 
 ## How Memory Works
 
-Maxy maintains a graph of everything you've told it. Contacts, conversations, preferences, relationships, business context — all stored as connected nodes in a local Neo4j database on your Raspberry Pi.
+SiteOffice maintains a graph of everything you've told it. Contacts, conversations, preferences, relationships, business context — all stored as connected nodes in a local Neo4j database on your Raspberry Pi.
 
-When you ask Maxy about something, it searches this graph first. It retrieves relevant context before responding, which is why Maxy can pick up where you left off even across separate sessions.
+When you ask SiteOffice about something, it searches this graph first. It retrieves relevant context before responding, which is why SiteOffice can pick up where you left off even across separate sessions.
 
 The graph lives entirely on your hardware. Nothing is sent to the cloud.
 
 ## What Gets Remembered
 
-Maxy stores:
+SiteOffice stores:
 
 - **Contacts** — people, companies, relationships between them
 - **Conversations** — key decisions, commitments, follow-ups mentioned in chat
-- **Preferences** — things you've told Maxy about how you like to work
+- **Preferences** — things you've told SiteOffice about how you like to work
 - **Context** — project status, ongoing threads, background you've shared
 
-Maxy remembers details you mention naturally: "I'm meeting with Sarah on Thursday" creates a memory that Thursday has a meeting with Sarah.
+SiteOffice remembers details you mention naturally: "I'm meeting with Sarah on Thursday" creates a memory that Thursday has a meeting with Sarah.
 
-## Telling Maxy to Remember Something
+## Telling SiteOffice to Remember Something
 
 Just say it naturally:
 
@@ -1432,13 +1432,13 @@ Just say it naturally:
 - "Note that the Johnson account is on hold until March"
 - "My wife's name is Emma, keep that in mind"
 
-Maxy will confirm and store it.
+SiteOffice will confirm and store it.
 
-## How Maxy learns how you work
+## How SiteOffice learns how you work
 
-Maxy also learns how you work without you having to teach it deliberately. Six broad areas cover the way most operators run a business — communication, scheduling, decisions, workflow, content, and interaction. Inside each area sits a small set of concrete fields (Maxy tracks around 28 in total) such as your preferred channel, quiet hours, workday start time, risk tolerance, content tonality, or address form. Maxy tracks which of these specific fields you have spoken into and which are still empty. While any are empty, it folds one organic question per turn into the conversation aimed at the next gap — never a list, never a form, never the same question twice. If you tell Maxy a field doesn't apply to you ("I work weekends, weekend availability isn't a thing for me"), it marks that field as covered and never re-asks. Once every field is either set or marked not-applicable, the proactive questions stop and Maxy answers what you ask without volunteering more. This is why session 300 should feel sharper than session 3: the longer you work together, the less Maxy needs to ask.
+SiteOffice also learns how you work without you having to teach it deliberately. Six broad areas cover the way most operators run a business — communication, scheduling, decisions, workflow, content, and interaction. Inside each area sits a small set of concrete fields (SiteOffice tracks around 28 in total) such as your preferred channel, quiet hours, workday start time, risk tolerance, content tonality, or address form. SiteOffice tracks which of these specific fields you have spoken into and which are still empty. While any are empty, it folds one organic question per turn into the conversation aimed at the next gap — never a list, never a form, never the same question twice. If you tell SiteOffice a field doesn't apply to you ("I work weekends, weekend availability isn't a thing for me"), it marks that field as covered and never re-asks. Once every field is either set or marked not-applicable, the proactive questions stop and SiteOffice answers what you ask without volunteering more. This is why session 300 should feel sharper than session 3: the longer you work together, the less SiteOffice needs to ask.
 
-## Telling Maxy to Forget Something
+## Telling SiteOffice to Forget Something
 
 Be direct:
 
@@ -1447,7 +1447,7 @@ Be direct:
 - "Clear what you know about my pricing preferences"
 - "Delete that pricing guide I uploaded"
 
-Maxy will confirm before deleting anything significant. Documents are soft-deleted first (excluded from search but recoverable for 7 days). Say "permanently delete" to remove immediately.
+SiteOffice will confirm before deleting anything significant. Documents are soft-deleted first (excluded from search but recoverable for 7 days). Say "permanently delete" to remove immediately.
 
 ## Managing Documents
 
@@ -1455,27 +1455,27 @@ Maxy will confirm before deleting anything significant. Documents are soft-delet
 
 Ask: "What files do I have stored?" or "List my attachments"
 
-Maxy shows all uploaded files with their ingestion status — whether they've been processed into the knowledge graph.
+SiteOffice shows all uploaded files with their ingestion status — whether they've been processed into the knowledge graph.
 
-When you upload something for ingestion, Maxy emits a one-line size estimate before it starts: short documents (<5K chars) classify in ~10s; mid-size (10K–20K chars) take ~45–90s; very large (>20K) up to ~3 minutes. If the classifier exceeds its 3-minute ceiling Maxy aborts loudly with a "Classifier unavailable — timeout" blocker and writes nothing — you can re-upload or split the document.
+When you upload something for ingestion, SiteOffice emits a one-line size estimate before it starts: short documents (<5K chars) classify in ~10s; mid-size (10K–20K chars) take ~45–90s; very large (>20K) up to ~3 minutes. If the classifier exceeds its 3-minute ceiling SiteOffice aborts loudly with a "Classifier unavailable — timeout" blocker and writes nothing — you can re-upload or split the document.
 
 ### Reading files
 
 Ask: "Show me what's in the pricing guide" or "Read the quarterly report"
 
-Maxy returns the full content of text and markdown files, extracted text from PDFs, and metadata for images.
+SiteOffice returns the full content of text and markdown files, extracted text from PDFs, and metadata for images.
 
 ### Editing files
 
 Ask: "Update the pricing in that document" or "Change the introduction paragraph"
 
-Maxy reads the file, makes the edit, and prepares it for re-ingestion into the knowledge graph. Only text and markdown files can be edited — PDFs and images cannot.
+SiteOffice reads the file, makes the edit, and prepares it for re-ingestion into the knowledge graph. Only text and markdown files can be edited — PDFs and images cannot.
 
 ### Renaming files
 
 Ask: "Rename that file to quarterly-report-q1.pdf"
 
-Maxy updates the filename in both the stored metadata and the knowledge graph.
+SiteOffice updates the filename in both the stored metadata and the knowledge graph.
 
 ### Deleting documents
 
@@ -1495,15 +1495,15 @@ Ask naturally:
 
 Three slash commands that apply analysis to what's already in your graph:
 
-**`/challenge <claim>`** — stress-tests an assertion. Maxy searches your graph for nodes that contradict or qualify the claim — nodes that assert the opposite, name exceptions, or add significant caveats — and presents the strongest counter-case it finds. If nothing in your graph challenges the claim, it says so rather than inventing one. Results cite node IDs and relevance scores so you can inspect the sources directly.
+**`/challenge <claim>`** — stress-tests an assertion. SiteOffice searches your graph for nodes that contradict or qualify the claim — nodes that assert the opposite, name exceptions, or add significant caveats — and presents the strongest counter-case it finds. If nothing in your graph challenges the claim, it says so rather than inventing one. Results cite node IDs and relevance scores so you can inspect the sources directly.
 
-**`/connect <topic-A> <topic-B>`** — finds the bridge. Maxy searches both topics, collects their immediate graph neighborhoods, and looks for nodes they share. If a direct bridge exists it names it in one sentence. If not, it surfaces the closest approach — the two nodes that are semantically nearest across the two sides — and proposes the connection you could draw.
+**`/connect <topic-A> <topic-B>`** — finds the bridge. SiteOffice searches both topics, collects their immediate graph neighborhoods, and looks for nodes they share. If a direct bridge exists it names it in one sentence. If not, it surfaces the closest approach — the two nodes that are semantically nearest across the two sides — and proposes the connection you could draw.
 
-**`/emerge`** — names the unnamed clusters. Maxy retrieves your KnowledgeDocument and Section nodes that are not yet connected to a Concept node, groups them by shared theme, and proposes a Concept name for each cluster. You approve or skip each proposal one at a time; nothing is written without your confirmation. Clusters of fewer than three nodes are listed at the end as "too small to cluster."
+**`/emerge`** — names the unnamed clusters. SiteOffice retrieves your KnowledgeDocument and Section nodes that are not yet connected to a Concept node, groups them by shared theme, and proposes a Concept name for each cluster. You approve or skip each proposal one at a time; nothing is written without your confirmation. Clusters of fewer than three nodes are listed at the end as "too small to cluster."
 
 ## Listing and counting
 
-Maxy answers relational questions — "list all my people", "how many tasks do I have", "find the person with email X", "show me the 20 most recently created nodes" — via direct read-only Cypher against your Neo4j. This is faster and more precise than semantic search when the question is "the exact set where", not "things similar to".
+SiteOffice answers relational questions — "list all my people", "how many tasks do I have", "find the person with email X", "show me the 20 most recently created nodes" — via direct read-only Cypher against your Neo4j. This is faster and more precise than semantic search when the question is "the exact set where", not "things similar to".
 
 You can also open a visual view of your graph at any time from the burger menu → **Graph**. Click the **Filter** button in the toolbar to open the filter menu — it lists only the top-level entity types in your schema (Conversation, Person, Task, KnowledgeDocument, …), one row per type, showing your per-type node count and sorted so the most-connected types sit at the top. Child types (messages inside a conversation, sections inside a document), conversation channel variants (admin vs public), message role variants (user vs assistant), and workflow execution plumbing (`ToolCall`, `WorkflowRun`, `WorkflowStep`, `StepResult`) never appear as filter rows — you reach children by clicking the parent and exploring its neighbourhood. Active rows render a force-directed map, coloured by label. Click a node to pivot into its 1-hop neighbourhood; click another node inside that neighbourhood to pivot again. Clicking a Message shows its details in the side panel; the Conversation view stays put — you read sibling messages without losing the chain on canvas. A breadcrumb strip above the canvas shows where you are (`Filter › Conversation › AssistantMessage`). The **Back** control pops one level — three clicks in always undoes with three Back presses; the filter view is the irreducible root. Click the **×** inside the filter menu to clear your chip selection. Type in the search box to highlight matches; submitting a search also widens the filter to include any node types the hits belong to, so relevant matches render instead of disappearing into a "not in current view" banner.
 
@@ -1511,17 +1511,17 @@ Conversations and Messages carry role/channel sublabels so you can read the chat
 
 **Save a default view:** once you have the rows you want, click **Set default view** in the filter menu. Next time you open **Graph**, those rows are pre-selected and your data renders immediately. The default is per-admin, per-account — each admin on each account has their own.
 
-**Delete a node:** drag it to the trash icon top-right of the canvas. No confirmation — deletes are reversible for 30 days. To restore, toggle **Show trashed** inside the filter menu and click **Restore** on the node, or ask Maxy in chat ("restore the <label> I just deleted"). Deleting a conversation also trashes its messages in the same step, so they reappear together on restore.
+**Delete a node:** drag it to the trash icon top-right of the canvas. No confirmation — deletes are reversible for 30 days. To restore, toggle **Show trashed** inside the filter menu and click **Restore** on the node, or ask SiteOffice in chat ("restore the <label> I just deleted"). Deleting a conversation also trashes its messages in the same step, so they reappear together on restore.
 
-**Bulk cleanup of conversations in chat:** when you ask Maxy 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, Maxy reports "no candidates" and nothing happens.
+**Bulk cleanup of conversations in chat:** when you ask SiteOffice 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, SiteOffice 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 Maxy 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 Maxy 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 Maxy 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.
+**Typo-proof cypher.** When SiteOffice 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 SiteOffice 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 SiteOffice 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.
 
 ## Bi-temporal timeline events
 
-Every factual statement Maxy extracts from your conversations is stored as a `:TimelineEvent` node. Each event carries two separate timestamps:
+Every factual statement SiteOffice extracts from your conversations is stored as a `:TimelineEvent` node. Each event carries two separate timestamps:
 
 - **`occurredAt`** (valid-time) — when the fact was true in the world. Set from the text itself; can reference a date in the past ("Alice joined in 1990" stores `occurredAt = 1990-01-01`).
 - **`learnedAt`** (transaction-time) — when the system ingested this event. Always the wall-clock time of the write; never back-dated.
@@ -1529,7 +1529,7 @@ Every factual statement Maxy extracts from your conversations is stored as a `:T
 This distinction lets you ask two qualitatively different questions:
 
 - *"What happened to Alice in 1990?"* — query by `occurredAt`.
-- *"What did Maxy learn about Alice last Tuesday?"* — query by `learnedAt`.
+- *"What did SiteOffice learn about Alice last Tuesday?"* — query by `learnedAt`.
 
 `memory-compiled-truth-history` returns both fields for every timeline event on an entity under the `timelineEvents` array, alongside the compiled-truth revision history in the `revisions` array.
 
@@ -1537,31 +1537,31 @@ This distinction lets you ask two qualitatively different questions:
 
 ## Write doctrine
 
-Every new node in Maxy's graph is created with at least one connection to an existing node. A contact connects to the conversation or organisation it came from; a task connects to the session that raised it or the entities it will affect; a session summary connects to the conversation it summarises. A node with no connection is noise — it cannot be attributed, traversed, or explained — so the graph refuses to create one. If Maxy ever tries to record something without a link, the write is rejected and Maxy asks you to clarify where it belongs.
+Every new node in SiteOffice's graph is created with at least one connection to an existing node. A contact connects to the conversation or organisation it came from; a task connects to the session that raised it or the entities it will affect; a session summary connects to the conversation it summarises. A node with no connection is noise — it cannot be attributed, traversed, or explained — so the graph refuses to create one. If SiteOffice ever tries to record something without a link, the write is rejected and SiteOffice asks you to clarify where it belongs.
 
 Every node also carries a provenance stamp — which agent wrote it, in which session, via which tool. You never see these fields, but they are how operators trace unusual growth back to the code path that produced it, and why your graph stays clean over time.
 
-**Two write surfaces, one substrate.** General agents write through schema-aware helpers — Maxy can record a new contact, a new commitment, a new preference without ever typing a database query, and the helper enforces the connection-and-provenance rule above structurally. The graph-steward role (the specialist Maxy dispatches when you ask for graph hygiene — "merge those two duplicate contacts," "wire those four tasks to the meeting," "rename the legacy label across the graph") additionally has a raw Cypher write tool for the multi-step operations the helpers cannot express. The steward role internalises the same connection-and-provenance discipline in its prompt; a post-write audit emits a warning on every breach so the same rules apply to both surfaces. Both paths feed the same hourly orphan trend and the same forensic provenance fields — read-side, you cannot tell the two apart, and that is the point.
+**Two write surfaces, one substrate.** General agents write through schema-aware helpers — SiteOffice can record a new contact, a new commitment, a new preference without ever typing a database query, and the helper enforces the connection-and-provenance rule above structurally. The graph-steward role (the specialist SiteOffice dispatches when you ask for graph hygiene — "merge those two duplicate contacts," "wire those four tasks to the meeting," "rename the legacy label across the graph") additionally has a raw Cypher write tool for the multi-step operations the helpers cannot express. The steward role internalises the same connection-and-provenance discipline in its prompt; a post-write audit emits a warning on every breach so the same rules apply to both surfaces. Both paths feed the same hourly orphan trend and the same forensic provenance fields — read-side, you cannot tell the two apart, and that is the point.
 
 ## 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
 
-Some entities in your graph are knowable by people outside your team — companies you work with, projects you've delivered, the business itself. For those entities (Maxy treats `:Organization`, `:Concept`, `:Project`, and `:LocalBusiness` this way), Maxy maintains two summaries: a private one only you and your specialist agents see, and a customer-facing public one your public agents are allowed to surface.
+Some entities in your graph are knowable by people outside your team — companies you work with, projects you've delivered, the business itself. For those entities (SiteOffice treats `:Organization`, `:Concept`, `:Project`, and `:LocalBusiness` this way), SiteOffice maintains two summaries: a private one only you and your specialist agents see, and a customer-facing public one your public agents are allowed to surface.
 
-Whenever Maxy updates the private summary on one of these entities, it automatically rewrites the public summary in the same step using a separate prompt that strips operator-voice ("needs follow-up", "action: chase next week"), internal sentiment, and anything that reads like a note-to-self. The two summaries stay in lockstep without you doing anything.
+Whenever SiteOffice updates the private summary on one of these entities, it automatically rewrites the public summary in the same step using a separate prompt that strips operator-voice ("needs follow-up", "action: chase next week"), internal sentiment, and anything that reads like a note-to-self. The two summaries stay in lockstep without you doing anything.
 
-If you want to write the public summary yourself — for instance, because the auto-generated version misses something you want customers to see — just tell Maxy the wording you want for the public summary on that entity, and Maxy will write it directly. It stays locked in for seven days; after that, the next automatic refresh can take over again, unless you re-pin it.
+If you want to write the public summary yourself — for instance, because the auto-generated version misses something you want customers to see — just tell SiteOffice the wording you want for the public summary on that entity, and SiteOffice will write it directly. It stays locked in for seven days; after that, the next automatic refresh can take over again, unless you re-pin it.
 
 People entries (`:Person`) are deliberately excluded from this dual-summary system. Notes about contacts are private by definition and never get a public-facing form.
 
 ## Privacy
 
-All memory is stored on your local Raspberry Pi. The Neo4j database never leaves your network. Maxy does not sync memory to any cloud service or third party.
+All memory is stored on your local Raspberry Pi. The Neo4j database never leaves your network. SiteOffice does not sync memory to any cloud service or third party.
 
-If you want to wipe everything and start fresh, ask: "Reset my memory graph." Maxy will ask for confirmation before doing so.
+If you want to wipe everything and start fresh, ask: "Reset my memory graph." SiteOffice will ask for confirmation before doing so.
 
 ---
 # Projects
@@ -1577,13 +1577,13 @@ Projects are ideal when the user has work involving multiple people, sequential
 
 ## Creating a Project
 
-Tell Maxy naturally:
+Tell SiteOffice naturally:
 
 - "Create a project for Mrs. Chen's kitchen refit — strip the old kitchen, plumbing first fix, electrical first fix, install units, then tiling and finishing"
 - "Set up a project for the bathroom renovation, standard tier, due by end of June"
 - "Start a project: boiler install for Sarah Thompson, quick job, just order parts, install, and test"
 
-Maxy creates the project and all work items in one step. Dependencies between steps (e.g., "install units after plumbing and electrical") are set up automatically based on the order and relationships you describe.
+SiteOffice creates the project and all work items in one step. Dependencies between steps (e.g., "install units after plumbing and electrical") are set up automatically based on the order and relationships you describe.
 
 Each project has a tier that reflects its complexity:
 - **Quick** — straightforward, few steps (e.g., boiler install)
@@ -1599,32 +1599,32 @@ Ask naturally:
 - "Show me the Davies bathroom project"
 - "What should I focus on?"
 
-Maxy shows project health at a glance:
+SiteOffice shows project health at a glance:
 - **Green** — on track, no issues
 - **Amber** — warning signs (overdue task or blocker)
 - **Red** — at risk (multiple overdue, critical blocker, or stale)
 
-When you start a new conversation, Maxy automatically shows active project summaries so you know where things stand without asking.
+When you start a new conversation, SiteOffice automatically shows active project summaries so you know where things stand without asking.
 
 ## Updating a Project
 
-Tell Maxy when things change:
+Tell SiteOffice when things change:
 
 - "Move the kitchen refit to the active phase"
 - "The materials for the kitchen refit are delayed by a week"
 - "Update the Davies bathroom target date to July 15th"
 - "Change the boiler install to a standard tier — it's more complex than we thought"
 
-Maxy records phase changes and issues as part of the project's history, creating an audit trail.
+SiteOffice records phase changes and issues as part of the project's history, creating an audit trail.
 
 ## Completing a Project
 
-Tell Maxy:
+Tell SiteOffice:
 
 - "Mark the boiler install as done"
 - "Complete the kitchen refit project"
 
-If any work items are still pending, Maxy will let you know and ask how to handle them — cancel, defer, or keep working on them.
+If any work items are still pending, SiteOffice will let you know and ask how to handle them — cancel, defer, or keep working on them.
 
 ## Abandoning a Project
 
@@ -1633,24 +1633,24 @@ If a project is no longer needed:
 - "Abandon the Davies bathroom — client cancelled"
 - "Stop the kitchen refit project"
 
-Maxy records the reason and marks the project as abandoned.
+SiteOffice records the reason and marks the project as abandoned.
 
 ## Projects vs. Tasks
 
 Use a **task** for standalone work — a single action, a reminder, a follow-up. Use a **project** when the work has multiple steps that depend on each other, a client or stakeholder, and a lifecycle that progresses through phases.
 
-When you describe multi-step work, Maxy will ask if you'd like to structure it as a project. Over time, it learns your preference and stops asking.
+When you describe multi-step work, SiteOffice will ask if you'd like to structure it as a project. Over time, it learns your preference and stops asking.
 
 ## Working a Task End to End
 
-Ask Maxy naturally:
+Ask SiteOffice naturally:
 
 - "What's outstanding?"
 - "What's on my plate?"
 - "What should I work on next?"
 - "Pick something to do"
 
-Maxy reads the ready set for your account, groups the open Tasks under their parent Projects, and asks you to pick one. You pick — it never auto-selects.
+SiteOffice reads the ready set for your account, groups the open Tasks under their parent Projects, and asks you to pick one. You pick — it never auto-selects.
 
 Once you pick, the loop runs end to end:
 
@@ -1660,7 +1660,7 @@ Once you pick, the loop runs end to end:
 
 This means you can always trace a finished piece of work back to the Task that asked for it, and a Task that says "complete" always has its output attached.
 
-Cross-account access is refused. A Task that belongs to a different account on the same install is invisible to this loop — Maxy will not read it, name it, or surface it.
+Cross-account access is refused. A Task that belongs to a different account on the same install is invisible to this loop — SiteOffice will not read it, name it, or surface it.
 
 ---
 # Slides
@@ -1706,11 +1706,11 @@ Source: https://docs.getmaxy.com/telegram-guide.md
 
 ## What the Telegram Plugin Does
 
-The Telegram plugin connects Maxy to a Telegram bot. Once set up, you can:
+The Telegram plugin connects SiteOffice to a Telegram bot. Once set up, you can:
 
-- Send messages to individuals or groups via Maxy ("Send a message to the team: standup in 10 minutes")
-- Receive messages from your Telegram bot and have Maxy respond
-- Use Telegram as a channel for Maxy notifications and alerts
+- Send messages to individuals or groups via SiteOffice ("Send a message to the team: standup in 10 minutes")
+- Receive messages from your Telegram bot and have SiteOffice respond
+- Use Telegram as a channel for SiteOffice notifications and alerts
 
 ## Setup
 
@@ -1723,39 +1723,39 @@ The Telegram plugin connects Maxy to a Telegram bot. Once set up, you can:
 
 ### Step 2: Connect the plugin
 
-Tell Maxy: "Set up Telegram" or "Configure the Telegram bot."
+Tell SiteOffice: "Set up Telegram" or "Configure the Telegram bot."
 
-Maxy will ask for your bot token, then save it and activate the plugin. The bot is now connected.
+SiteOffice will ask for your bot token, then save it and activate the plugin. The bot is now connected.
 
 ### Step 3: Start the bot
 
 In Telegram, open your bot and send `/start`. The bot is now active and listening.
 
-## Sending Messages via Maxy
+## Sending Messages via SiteOffice
 
-Once connected, tell Maxy to send messages on your behalf:
+Once connected, tell SiteOffice to send messages on your behalf:
 
 - "Send a Telegram message to John: I'll be 10 minutes late"
 - "Message the team channel: server maintenance at 11pm"
 - "Tell Sarah via Telegram that the proposal is ready"
 
-Maxy needs a chat ID or username to target a specific person or group. For groups, you'll need to add the bot to the group first.
+SiteOffice needs a chat ID or username to target a specific person or group. For groups, you'll need to add the bot to the group first.
 
 ## Getting a Chat ID
 
-To message a specific person or group, Maxy needs their chat ID. The easiest way:
+To message a specific person or group, SiteOffice needs their chat ID. The easiest way:
 
 1. Have the person (or yourself) send any message to your bot
-2. Ask Maxy: "What chat IDs have messaged the bot recently?"
-3. Maxy will look up the message history and show you the IDs
+2. Ask SiteOffice: "What chat IDs have messaged the bot recently?"
+3. SiteOffice will look up the message history and show you the IDs
 
 ## Message History
 
-Ask Maxy: "What messages has the bot received?" or "Show recent Telegram activity."
+Ask SiteOffice: "What messages has the bot received?" or "Show recent Telegram activity."
 
 ## Troubleshooting
 
-**Bot not responding:** Check that the bot token is correct — ask Maxy "What's my Telegram bot token configured as?" and verify it matches BotFather.
+**Bot not responding:** Check that the bot token is correct — ask SiteOffice "What's my Telegram bot token configured as?" and verify it matches BotFather.
 
 **Can't send to a group:** The bot must be a member of the group. Add it via the group settings in Telegram, then try again.
 
@@ -1771,7 +1771,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.
@@ -1841,7 +1841,7 @@ Source: https://docs.getmaxy.com/linkedin-extension.md
 
 # 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)
 
@@ -1849,7 +1849,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.)
@@ -1857,7 +1857,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.
 
@@ -1877,7 +1877,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
 
@@ -2145,7 +2145,7 @@ Source: https://docs.getmaxy.com/voice-mirror-guide.md
 
 ## What It Does
 
-Maxy reads emails, posts, documents, and your own chat messages, and uses them to make sure agent-drafted copy reads like you wrote it — not like generic AI prose.
+SiteOffice reads emails, posts, documents, and your own chat messages, and uses them to make sure agent-drafted copy reads like you wrote it — not like generic AI prose.
 
 Anthropic models cannot be fine-tuned. Voice mirror works by feeding the model two things alongside every drafting task:
 
@@ -2156,24 +2156,24 @@ The model conditions on both and produces copy that reads as yours.
 
 Voice mirror maintains a separate profile for each type of content you write: plain text, email, social posts, articles, notes, and marketing copy. The right profile is applied automatically based on what you're drafting.
 
-When Maxy produces anything that will go out under your name (a document, public-facing copy, anything you will send onward), it applies your voice before it writes the first line, not after you ask for a rewrite. You do not have to request it.
+When SiteOffice produces anything that will go out under your name (a document, public-facing copy, anything you will send onward), it applies your voice before it writes the first line, not after you ask for a rewrite. You do not have to request it.
 
 ## How Your Voice Is Captured
 
 ### Automatically — from chat
 
-Every admin chat session feeds your writing into the `text` profile automatically. When the session ends, Maxy reads the transcript, filters out slash commands, system messages, and large paste blocks, and adds each genuine turn as a corpus entry. This happens in the background with no action needed from you.
+Every admin chat session feeds your writing into the `text` profile automatically. When the session ends, SiteOffice reads the transcript, filters out slash commands, system messages, and large paste blocks, and adds each genuine turn as a corpus entry. This happens in the background with no action needed from you.
 
 ### Via backfill — from historical content
 
-Use the backfill flow to teach Maxy your writing from emails, documents, and social posts you've already written.
+Use the backfill flow to teach SiteOffice your writing from emails, documents, and social posts you've already written.
 
 In the admin chat, ask: **"Start the voice-mirror backfill."**
 
-Maxy asks which stream to backfill first — discrete documents (emails, posts, PDFs) or chat archives (WhatsApp, Telegram, etc.). **Pick chat archives first if you have any imported.** Chat is where your unguarded voice lives; email is the same voice in dress clothes.
+SiteOffice asks which stream to backfill first — discrete documents (emails, posts, PDFs) or chat archives (WhatsApp, Telegram, etc.). **Pick chat archives first if you have any imported.** Chat is where your unguarded voice lives; email is the same voice in dress clothes.
 
-- **Chat archives** — tag a whole conversation in one click. Maxy doesn't ask about individual messages because chunks within a conversation almost always share the same voice. Options per conversation: yours, mixed (multiple authors on your side — rare), or not yours (e.g. a Slack channel where you only forwarded other people's messages).
-- **Documents and posts** — paginated 10 at a time. Maxy shows each item with its detected format (email, article, note, social-post). Tag the whole batch, a subset by number, or per-item if you want a precise label like `human-led-agent-assisted` (you wrote the content, Maxy polished). Override the detected format if one is wrong.
+- **Chat archives** — tag a whole conversation in one click. SiteOffice doesn't ask about individual messages because chunks within a conversation almost always share the same voice. Options per conversation: yours, mixed (multiple authors on your side — rare), or not yours (e.g. a Slack channel where you only forwarded other people's messages).
+- **Documents and posts** — paginated 10 at a time. SiteOffice shows each item with its detected format (email, article, note, social-post). Tag the whole batch, a subset by number, or per-item if you want a precise label like `human-led-agent-assisted` (you wrote the content, SiteOffice polished). Override the detected format if one is wrong.
 
 Skip a batch if none qualify, or stop at any time — the next session resumes where you left off.
 
@@ -2181,13 +2181,13 @@ Skip a batch if none qualify, or stop at any time — the next session resumes w
 
 Once you have corpus entries tagged (or after automatic PTY ingestion fills the `text` profile), ask: **"Build my voice profile."**
 
-Maxy reads the corpus for each format, summarises your style as a YAML card, and saves it to the graph. It picks up your sentence rhythms, the constructions you reach for, the words you avoid — separately for email, articles, social posts, and so on.
+SiteOffice reads the corpus for each format, summarises your style as a YAML card, and saves it to the graph. It picks up your sentence rhythms, the constructions you reach for, the words you avoid — separately for email, articles, social posts, and so on.
 
 The profile re-runs automatically when your corpus grows by ≥20% for any format or every 30 days, whichever comes first.
 
 ## Feedback Loop
 
-When you edit an agent draft before sending — shorten a sentence, change a sign-off, swap a phrase — Maxy captures the edit and feeds it into the next distillation. The more you edit, the closer the voice gets.
+When you edit an agent draft before sending — shorten a sentence, change a sign-off, swap a phrase — SiteOffice captures the edit and feeds it into the next distillation. The more you edit, the closer the voice gets.
 
 This happens silently as part of the edit-loop in any drafting skill (email composition is the first wired surface).
 
@@ -2200,7 +2200,7 @@ Voice mirror is on by default for every drafting skill. To opt out for one, set
 - **Blend voices** — one profile set per person, no "Joel + Neo combined".
 - **Copy public figures** — voice mirror only learns from your own writing.
 - **Clone audio** — text only, no speech synthesis.
-- **Guess** — historical content stays `unknown` until you mark it. Maxy never auto-classifies your writing. (Automatic ingestion applies only to your live PTY sessions where authorship is certain.)
+- **Guess** — historical content stays `unknown` until you mark it. SiteOffice never auto-classifies your writing. (Automatic ingestion applies only to your live PTY sessions where authorship is certain.)
 
 ## Status
 
@@ -2223,7 +2223,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
@@ -2444,7 +2444,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.
@@ -2658,7 +2658,7 @@ Source: https://docs.getmaxy.com/neo4j.md
 
 # Neo4j edge types — operator reference
 
-How Maxy's graph wires itself.
+How SiteOffice's graph wires itself.
 
 ## Typed-edge auto-extraction
 
@@ -2726,9 +2726,9 @@ Source: https://docs.getmaxy.com/internals.md
 
 # Platform Internals — Retrieval Architecture
 
-Technical architecture reference for the retrieval pipeline, knowledge delivery, and supporting infrastructure. This document covers how information moves from the Neo4j graph into an agent's context — the mechanics behind "Maxy searches this graph to retrieve relevant context."
+Technical architecture reference for the retrieval pipeline, knowledge delivery, and supporting infrastructure. This document covers how information moves from the Neo4j graph into an agent's context — the mechanics behind "SiteOffice searches this graph to retrieve relevant context."
 
-Use this reference when assessing capabilities, diagnosing retrieval behaviour, or answering questions about how the platform works internally. When a question asks "does Maxy have X?" — check here before asserting a gap.
+Use this reference when assessing capabilities, diagnosing retrieval behaviour, or answering questions about how the platform works internally. When a question asks "does SiteOffice have X?" — check here before asserting a gap.
 
 ---
 
@@ -3051,13 +3051,13 @@ This tool is read-only and available to both public and admin agents.
 
 ### When conversations are created
 
-`:Conversation` nodes on webchat (admin login, "New conversation" in the burger, a new public visitor) are created lazily. Opening the chat or logging in does not write anything to the graph — Maxy only records the conversation once the user sends a second message. This keeps `conversation-search` and the Conversations modal free of one-turn abandoned threads. WhatsApp and Telegram take the opposite posture: every inbound — DM or group, allowed or activation-off, agent-invoked or gated — MERGEs the `:Conversation` and writes a forensic `:Message:WhatsAppMessage` row before any access-control decision. The graph is the durable record of every message the device received, not just the ones the agent replied to. See `.docs/web-chat.md` "Deferred conversation persistence" and `.docs/whatsapp.md` "Session continuity" for the full contract.
+`:Conversation` nodes on webchat (admin login, "New conversation" in the burger, a new public visitor) are created lazily. Opening the chat or logging in does not write anything to the graph — SiteOffice only records the conversation once the user sends a second message. This keeps `conversation-search` and the Conversations modal free of one-turn abandoned threads. WhatsApp and Telegram take the opposite posture: every inbound — DM or group, allowed or activation-off, agent-invoked or gated — MERGEs the `:Conversation` and writes a forensic `:Message:WhatsAppMessage` row before any access-control decision. The graph is the durable record of every message the device received, not just the ones the agent replied to. See `.docs/web-chat.md` "Deferred conversation persistence" and `.docs/whatsapp.md` "Session continuity" for the full contract.
 
 Each row in the Conversations modal exposes a `View logs` row-action that opens a popover with three links — **Stream**, **Errors**, **SSE** — each of which targets `/api/admin/logs?type={stream|error|sse}&sessionId={full-id}` in a new tab. The row's 8-char id chip is click-to-copy; hover reveals the full `sessionId` as a tooltip. See `.docs/web-chat.md` "In-chat retrieval" for the route contract and `console.debug` observability.
 
 ### Static publish surface — `/sites/*`
 
-Maxy hosts a generic per-account static-tree publish surface at `https://public.<brand>/sites/<...>/<file>`. The route serves files from `<accountDir>/sites/<...>` with URL=disk mirroring — operator drops the tree on disk, no upload API. Extended MIME covers HTML/CSS/JS/woff2/fonts on top of images. Path traversal (`..`, encoded `..`, segments failing `SAFE_SEG_RE`) returns 403; symlinks escaping the sites root are rejected via a `realpathSync` re-check. `.html` responses carry `Content-Security-Policy: default-src 'self' https: data:; script-src 'none'` and `Cache-Control: no-cache`; assets are cached for an hour; every response carries `X-Content-Type-Options: nosniff`. Per-account isolation comes from `resolveAccount` — every brand's install sees only its own tree.
+SiteOffice hosts a generic per-account static-tree publish surface at `https://public.<brand>/sites/<...>/<file>`. The route serves files from `<accountDir>/sites/<...>` with URL=disk mirroring — operator drops the tree on disk, no upload API. Extended MIME covers HTML/CSS/JS/woff2/fonts on top of images. Path traversal (`..`, encoded `..`, segments failing `SAFE_SEG_RE`) returns 403; symlinks escaping the sites root are rejected via a `realpathSync` re-check. `.html` responses carry `Content-Security-Policy: default-src 'self' https: data:; script-src 'none'` and `Cache-Control: no-cache`; assets are cached for an hour; every response carries `X-Content-Type-Options: nosniff`. Per-account isolation comes from `resolveAccount` — every brand's install sees only its own tree.
 
 **Directory canonicalisation.** A request whose disk target is a directory is `301`'d to the trailing-slash form (query string preserved) before any body is served — RFC 3986 §5.3 base resolution requires the trailing slash so relative refs in the served HTML resolve under the directory, not its parent. After the redirect the route serves `<dir>/index.html` if it exists on disk; otherwise `404`. There is **no** implicit-`index.html` invention for missing paths — the publisher owns canonical URLs. A brochure shipped without `index.html` is reached at `/sites/<slug>/<file>.html`, and the admin skill `publish-site` is the sanctioned surface that moves the extracted tree under `<accountDir>/sites/<slug>/` and emits the canonical path slug. Operator-side: drop a brochure at `<accountDir>/sites/properties/<id>/brochure/output/` and it serves at `<public-host>/sites/properties/<id>/brochure/output/brochure.html` (or `<public-host>/sites/properties/<id>/brochure/output/` if that directory contains an `index.html`). See `.docs/web-chat.md` `/sites/*` route entry for the wire contract and `[sites]` log lines (`serve|redirect-trailing-slash|not-found|path-traversal-rejected|symlink-escape-rejected|no-account`).
 
@@ -3065,7 +3065,7 @@ Maxy hosts a generic per-account static-tree publish surface at `https://public.
 
 ### Cross-tab session rotation
 
-When you click "New conversation" in the chat tab, Maxy mints a fresh admin session key on the server and clears the old one. Sibling admin tabs (`/graph`, `/data`) opened in the same browser keep working without re-login: the chat tab broadcasts the new key on a same-origin channel so each sibling tab updates its captured key instantly, and any in-flight admin request that 401s with the rotation-orphan code retries once after re-reading the latest key from per-tab storage. If neither path recovers (browser locked down, second 401 after retry, session expired), the tab shows a single banner — "Your admin session was renewed in another tab. Click to reload." — and one click sends you back through login. No silent 401s; no re-clicking through the same trash icon hoping it sticks. See `.docs/web-chat.md` "Cross-tab rotation contract" for the wire-level `code` taxonomy and observability surfaces.
+When you click "New conversation" in the chat tab, SiteOffice mints a fresh admin session key on the server and clears the old one. Sibling admin tabs (`/graph`, `/data`) opened in the same browser keep working without re-login: the chat tab broadcasts the new key on a same-origin channel so each sibling tab updates its captured key instantly, and any in-flight admin request that 401s with the rotation-orphan code retries once after re-reading the latest key from per-tab storage. If neither path recovers (browser locked down, second 401 after retry, session expired), the tab shows a single banner — "Your admin session was renewed in another tab. Click to reload." — and one click sends you back through login. No silent 401s; no re-clicking through the same trash icon hoping it sticks. See `.docs/web-chat.md` "Cross-tab rotation contract" for the wire-level `code` taxonomy and observability surfaces.
 
 ---
 
@@ -3227,7 +3227,7 @@ Each ToolCall record contains:
 | startedAt / completedAt | Timestamps for the invocation |
 | sessionId | Links back to the originating conversation |
 
-Records persist indefinitely and are queryable by the admin agent. Ask Maxy "what tools ran in the last session?" or "show me all tool calls from today" to review the audit trail.
+Records persist indefinitely and are queryable by the admin agent. Ask SiteOffice "what tools ran in the last session?" or "show me all tool calls from today" to review the audit trail.
 
 Workflow-dispatched tool calls are tracked separately via `StepResult` nodes (part of the workflow execution system) and are not duplicated as ToolCall nodes.
 
@@ -3258,7 +3258,7 @@ See `.docs/neo4j.md § Process provenance doctrine` for the full enforcement con
 
 ## Context compaction
 
-When an admin turn crosses 75% of the model's context window, Maxy runs a silent compaction turn that asks the agent to call the `session-compact` MCP tool with a structured briefing (what you asked for, what was done, decisions made, work-in-progress, things you've shared about yourself). The briefing is written to Neo4j; the next admin turn injects it back into the system prompt, so continuity survives across the compaction boundary without re-sending the full transcript.
+When an admin turn crosses 75% of the model's context window, SiteOffice runs a silent compaction turn that asks the agent to call the `session-compact` MCP tool with a structured briefing (what you asked for, what was done, decisions made, work-in-progress, things you've shared about yourself). The briefing is written to Neo4j; the next admin turn injects it back into the system prompt, so continuity survives across the compaction boundary without re-sending the full transcript.
 
 The compaction runs against a transient one-shot pool entry separate from the long-lived admin Query. Operator-visible side effects:
 - Compaction logs land in `claude-agent-compaction-stream-YYYY-MM-DD.log` alongside the main stream log. Look for `[compaction-start]`, `[compaction-summary-captured]`, `[compaction-failed]`, `[compaction-timeout]`, `[compaction-crashed]`, or `[compaction-spawn-error]` to triage. Subprocess stderr is captured inline as `[subproc-stderr] <line>` — there is no longer a separate `claude-agent-compaction-stderr-…log` file.
@@ -3290,7 +3290,7 @@ npx -y @rubytech/create-realagent-code       # realagent brand
 
 **Hostname / printed URL.** Without `--hostname`, the installer reads `scutil --get LocalHostName` and prints the completion URL as `http://<that-name>.local:<port>`. No sudo, no system change — your Mac's existing local network name is what mDNS will resolve. With `--hostname <h>`, the installer sets `HostName` / `LocalHostName` / `ComputerName` to `<h>` via `sudo scutil` (one password prompt, all-or-nothing rollback within the three-call batch) so the URL becomes `http://<h>.local:<port>`. Grep `~/.<brand>/logs/install-*.log` for `[create-maxy] darwin-hostname-mode=` to confirm which path ran (`scutil-get`, `scutil-set`, or `brand-fallback`).
 
-**LaunchAgent.** The installer registers `Maxy` as a launchd LaunchAgent at `~/Library/LaunchAgents/com.rubytech.<brand-hostname>.plist` — for example `com.rubytech.maxy-code.plist`. Survives logout/login and reboot via `KeepAlive=true` and `RunAtLoad=true`. Two brands on the same Mac get two distinct plists (brand-hostname-keyed), so install order is independent. Use `launchctl print gui/$UID/com.rubytech.<brand-hostname>` for service state. The `[create-maxy] launchd-plist=<path> loaded=true` line in the install log confirms `launchctl bootstrap` accepted the plist; `loaded=false exit=<n>` is the failure signal (run `plutil -lint <path>` to diagnose).
+**LaunchAgent.** The installer registers `SiteOffice` as a launchd LaunchAgent at `~/Library/LaunchAgents/com.rubytech.<brand-hostname>.plist` — for example `com.rubytech.maxy-code.plist`. Survives logout/login and reboot via `KeepAlive=true` and `RunAtLoad=true`. Two brands on the same Mac get two distinct plists (brand-hostname-keyed), so install order is independent. Use `launchctl print gui/$UID/com.rubytech.<brand-hostname>` for service state. The `[create-maxy] launchd-plist=<path> loaded=true` line in the install log confirms `launchctl bootstrap` accepted the plist; `loaded=false exit=<n>` is the failure signal (run `plutil -lint <path>` to diagnose).
 
 **Cloudflare on darwin.** The installer brew-installs the `cloudflared` binary so it is on PATH, but does not invoke `cloudflared service install` or `cloudflared tunnel route dns` — public reach is opt-in. After install, the operator runs `cloudflared tunnel login` (browser-driven) followed by the existing tunnel-setup flow if they want a public address. Grep `[create-maxy] darwin-cloudflare-skip=true` in the install log to confirm the installer took the documented skip path.
 
@@ -3309,7 +3309,7 @@ Every successful Mac install contains, in order: `platform=darwin`, `darwin-host
 
 ## Initial Setup
 
-The Maxy installer handles the full setup. Run it on your Pi:
+The SiteOffice installer handles the full setup. Run it on your Pi:
 
 ```bash
 npx -y @rubytech/create-maxy
@@ -3324,7 +3324,7 @@ This installs all dependencies (Node.js, Neo4j, Cloudflare tunnel, Claude Code),
 3. Installs and starts Neo4j (the memory database)
 4. Installs and configures the Cloudflare tunnel for remote access
 5. Creates your account and sets your PIN
-6. Starts the Maxy web server on port 19200
+6. Starts the SiteOffice web server on port 19200
 7. Configures systemd so everything restarts automatically if the Pi reboots
 
 ## First admin session — install-time defaults
@@ -3378,7 +3378,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:
 
@@ -3398,9 +3398,9 @@ Companion lint: `platform/scripts/check-no-esm-require.mjs` rejects `require(` c
 
 ## Service Management
 
-Maxy runs via systemd and starts automatically on boot. You don't need to start it manually. To check if it's running, ask Maxy "Check system status."
+SiteOffice runs via systemd and starts automatically on boot. You don't need to start it manually. To check if it's running, ask SiteOffice "Check system status."
 
-If you need to restart the service manually (rare), ask Maxy to do it for you.
+If you need to restart the service manually (rare), ask SiteOffice to do it for you.
 
 ## Browsing the brand filesystem on your LAN (SMB)
 
@@ -3408,23 +3408,23 @@ Every install provisions a per-brand SMB share against the brand's install folde
 
 ## Remote Access via Cloudflare
 
-Maxy uses a Cloudflare tunnel to make your local Pi accessible from anywhere without opening router ports. The tunnel is configured during setup and runs as a background service.
+SiteOffice uses a Cloudflare tunnel to make your local Pi accessible from anywhere without opening router ports. The tunnel is configured during setup and runs as a background service.
 
-Setting it up: say "Set up remote access." Maxy walks you through signing into Cloudflare, picking your domain (if you have more than one on your Cloudflare account), and then shows a form where you pick a short name that becomes your admin address. For example, entering `joel` gives you `https://joel.your-domain.com` for admin access. You can also pick a separate address for the public chat, or leave it blank to skip public access. The form only accepts valid address characters (lowercase letters, numbers, hyphens) — Maxy never asks you to type your full URL in chat.
+Setting it up: say "Set up remote access." SiteOffice walks you through signing into Cloudflare, picking your domain (if you have more than one on your Cloudflare account), and then shows a form where you pick a short name that becomes your admin address. For example, entering `joel` gives you `https://joel.your-domain.com` for admin access. You can also pick a separate address for the public chat, or leave it blank to skip public access. The form only accepts valid address characters (lowercase letters, numbers, hyphens) — SiteOffice never asks you to type your full URL in chat.
 
 Your admin URL looks like: `https://joel.maxy.chat` (the short name is whatever you picked in the form).
 
-To check the tunnel status: ask Maxy "Check Cloudflare tunnel status."
+To check the tunnel status: ask SiteOffice "Check Cloudflare tunnel status."
 
-To restart the tunnel: ask Maxy "Restart the Cloudflare tunnel."
+To restart the tunnel: ask SiteOffice "Restart the Cloudflare tunnel."
 
 ## Checking Service Status
 
-Ask Maxy: "Check system status."
+Ask SiteOffice: "Check system status."
 
 The `system-status` tool reports the health of all services: Neo4j, the web server, the Cloudflare tunnel, and all active MCP servers.
 
-## If Maxy Won't Start
+## If SiteOffice Won't Start
 
 From the Pi directly:
 
@@ -3466,9 +3466,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`)
@@ -3517,17 +3517,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
 ```
 
@@ -3560,13 +3560,13 @@ Empty output from step 3 = brand.json resolved cleanly and the badge reflects th
 
 ## Upgrading
 
-To upgrade Maxy to the latest version, ask Maxy: "Upgrade Maxy." The platform checks the current device identity (hostname and port via `system-status`), then re-runs the installer with explicit `--hostname` and `--port` flags to preserve them across the upgrade.
+To upgrade SiteOffice to the latest version, ask SiteOffice: "Upgrade SiteOffice." The platform checks the current device identity (hostname and port via `system-status`), then re-runs the installer with explicit `--hostname` and `--port` flags to preserve them across the upgrade.
 
 The docs plugin (this plugin) is upgraded in the same step — you always have the documentation that matches your installed version.
 
 ### Automatic upgrade alert
 
-Maxy checks for new releases on every admin session start — whenever you log in, reload the page, or return to the admin chat. When a newer version is available, the Software Update window opens automatically showing your current and the latest version, with a one-click Upgrade button. Dismissing the window (click outside or the close button) defers the alert until your next login or reload; no alert is shown when you are already on the latest version.
+SiteOffice checks for new releases on every admin session start — whenever you log in, reload the page, or return to the admin chat. When a newer version is available, the Software Update window opens automatically showing your current and the latest version, with a one-click Upgrade button. Dismissing the window (click outside or the close button) defers the alert until your next login or reload; no alert is shown when you are already on the latest version.
 
 The upgrade runs inside a live terminal embedded in the Software Update window — you see each installation step stream as it happens, and any password prompts from `sudo` appear directly in the terminal for you to answer. Closing the window does not cancel the upgrade; re-opening it reattaches to the same shell so you can see what happened while disconnected.
 
@@ -3578,7 +3578,7 @@ Source: https://docs.getmaxy.com/samba.md
 
 # Samba Share
 
-Every Maxy install provisions a per-brand SMB network share so you can read and write the brand's install folder from Finder, File Explorer, the Files app on iOS, or any SMB-capable client on Android or Linux. No client install required — every modern OS speaks SMB natively.
+Every SiteOffice install provisions a per-brand SMB network share so you can read and write the brand's install folder from Finder, File Explorer, the Files app on iOS, or any SMB-capable client on Android or Linux. No client install required — every modern OS speaks SMB natively.
 
 The share lives next to the rest of the brand. On a device that runs more than one brand, each brand gets its own stanza, its own credentials, and its own lifecycle. Tearing one brand down never touches another brand's share.
 
@@ -3610,7 +3610,7 @@ If `<hostname>.local` does not resolve from your client (some networks do not ro
 ## Credentials
 
 - **Username** — the Unix user that owns the install on the device. On a Pi or Hetzner box this is `admin`; on a self-hosted Linux laptop it is whatever Linux user ran the installer (for example `neo`). The installer persists this value to `~/.<brand>/.install-owner` so every later read uses the same identity the installer wrote.
-- **Password** — your current Maxy PIN. The same PIN that unlocks the admin UI unlocks the SMB share.
+- **Password** — your current SiteOffice PIN. The same PIN that unlocks the admin UI unlocks the SMB share.
 
 Both halves are required. SMB never accepts a guest connection; `map to guest = bad user` is set in the global stanza.
 
@@ -3760,8 +3760,8 @@ tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
 **Symptom:** You send a message and nothing comes back, or the response never arrives.
 
 **Check:**
-1. Ask Maxy: "Check system status" — the `system-status` tool will report whether all services are running
-2. Check the platform logs: ask Maxy "Show me the recent logs"
+1. Ask SiteOffice: "Check system status" — the `system-status` tool will report whether all services are running
+2. Check the platform logs: ask SiteOffice "Show me the recent logs"
 3. If the admin agent itself won't start: restart the platform (see below)
 
 **Common causes:**
@@ -3769,17 +3769,17 @@ tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
 - Platform process has stopped — restart it
 - Network issue if accessing remotely — check your Cloudflare tunnel is running
 
-**If the chat shows a single `[agent-loop-stop] same error twice — aborting` line and stops:** Maxy hit the same structured tool failure twice in a row inside one turn (e.g. a permission gate refused the same write twice, or two `Read` calls hit the same missing file). The runtime aborted the turn after the second occurrence to save tokens instead of running until the SDK turn budget exhausted. The blocker text names the tool and the first line of the error. Resolve the underlying cause (re-run the named skill, fix the missing prerequisite, etc.) and tap "Continue" — the next turn truly resumes the prior SDK session via the synthetic-tool-result contract, so Maxy picks up where it aborted instead of cold-querying its own session list. To see the diagnostic, ask Maxy: "Show me the most recent stall-recovery log line." Greppable post-deploy invariants: `[agent-loop-stop] reason=identical-tool-failure tool=<name> errorSignature=<sha8> toolInputDigest=<sha8>` followed by `[stall-recovery] kind=agent_loop_stop … handoff=resume-first` and on the next turn `[stall-resume] consumed kind=agent_loop_stop toolUseId=<8> priorSessionId=<8>`. The fallback path (when the SDK session id was lost) emits `handoff=metadata-only` + `[recovery-handoff] generated/consumed reason=agent-loop-stop` and the chat button reads "Start over" instead of "Continue". A `[recovery-handoff] WARN missing-on-cold-create` line means the fallback briefing wasn't persisted — surface to support.
+**If the chat shows a single `[agent-loop-stop] same error twice — aborting` line and stops:** SiteOffice hit the same structured tool failure twice in a row inside one turn (e.g. a permission gate refused the same write twice, or two `Read` calls hit the same missing file). The runtime aborted the turn after the second occurrence to save tokens instead of running until the SDK turn budget exhausted. The blocker text names the tool and the first line of the error. Resolve the underlying cause (re-run the named skill, fix the missing prerequisite, etc.) and tap "Continue" — the next turn truly resumes the prior SDK session via the synthetic-tool-result contract, so SiteOffice picks up where it aborted instead of cold-querying its own session list. To see the diagnostic, ask SiteOffice: "Show me the most recent stall-recovery log line." Greppable post-deploy invariants: `[agent-loop-stop] reason=identical-tool-failure tool=<name> errorSignature=<sha8> toolInputDigest=<sha8>` followed by `[stall-recovery] kind=agent_loop_stop … handoff=resume-first` and on the next turn `[stall-resume] consumed kind=agent_loop_stop toolUseId=<8> priorSessionId=<8>`. The fallback path (when the SDK session id was lost) emits `handoff=metadata-only` + `[recovery-handoff] generated/consumed reason=agent-loop-stop` and the chat button reads "Start over" instead of "Continue". A `[recovery-handoff] WARN missing-on-cold-create` line means the fallback briefing wasn't persisted — surface to support.
 
-**If a background task goes silent and the chat shows "A background task went silent — K of M completed":** Maxy's subagent stopped emitting progress for over 2 minutes. Tap "Continue" — the next turn resumes the prior session and reads a synthetic tool_result describing what completed before the pause, so the agent re-plans without losing the work it had done. Most stalls are upstream API latency rather than the subagent's approach failing — the resume-first path treats both correctly. Greppable post-deploy invariants: `[stall-recovery] kind=subagent_stalled … completed=<K>/? handoff=resume-first` followed by `[stall-resume] consumed kind=subagent_stalled toolUseId=<8>` on the next turn. If the button reads "Start over" instead, the parent's pending tool_use_id was not captured — the fallback path took over; the prior conversation is preserved as a `<recovery-context>` block in the cold-started session.
+**If a background task goes silent and the chat shows "A background task went silent — K of M completed":** SiteOffice's subagent stopped emitting progress for over 2 minutes. Tap "Continue" — the next turn resumes the prior session and reads a synthetic tool_result describing what completed before the pause, so the agent re-plans without losing the work it had done. Most stalls are upstream API latency rather than the subagent's approach failing — the resume-first path treats both correctly. Greppable post-deploy invariants: `[stall-recovery] kind=subagent_stalled … completed=<K>/? handoff=resume-first` followed by `[stall-resume] consumed kind=subagent_stalled toolUseId=<8>` on the next turn. If the button reads "Start over" instead, the parent's pending tool_use_id was not captured — the fallback path took over; the prior conversation is preserved as a `<recovery-context>` block in the cold-started session.
 
 **Agent searches the filesystem after uploading a zip.** If you uploaded a zip and the agent burns several turns running `find` / `Glob` instead of unzipping, that is the symptom of the recovery-retry attachment-context regression (now closed by the recovery context preservation contract in `.docs/agents.md`). Greppable confirmation is the `[context-overflow-recovery] retry … attachmentsCarried=<n>` line in the conversation stream log. If you see `[context-overflow-recovery] WARN attachment-context-lost`, the regression has returned — surface to support.
 
-**Turn budget exhausted with a horizontal rule separating two assistant turns.** When Maxy reaches its turn budget and the doubled retry also runs out, the chat now shows a one-paragraph assistant message that opens with `error_max_turns turns=A→B` (initial budget → final budget) followed by the recovery copy: "I reached my turn budget of N before I could finish this request. Try sending a smaller or more focused request, or ask me to use higher effort." That message is persisted to the graph, so the next page-refresh still shows it. The thin horizontal rule labelled "Session restored after timeout." that appears above your following turn signals that the prior turn forced a cold SDK-session restart inside the same conversation (pool eviction) — the agent's response after the rule is from a fresh SDK session even though the conversation thread is unchanged. Greppable post-deploy invariants: `[context-overflow-recovery] exhausted cause=max-turns-interrupted` count equals `[admin-persist] writer=persistMessageExhaust outcome=ok` count for the same sessionId window, and one `[session-store] storeAgentSessionId` line marks the cold-restart that drove the on-screen rule.
+**Turn budget exhausted with a horizontal rule separating two assistant turns.** When SiteOffice reaches its turn budget and the doubled retry also runs out, the chat now shows a one-paragraph assistant message that opens with `error_max_turns turns=A→B` (initial budget → final budget) followed by the recovery copy: "I reached my turn budget of N before I could finish this request. Try sending a smaller or more focused request, or ask me to use higher effort." That message is persisted to the graph, so the next page-refresh still shows it. The thin horizontal rule labelled "Session restored after timeout." that appears above your following turn signals that the prior turn forced a cold SDK-session restart inside the same conversation (pool eviction) — the agent's response after the rule is from a fresh SDK session even though the conversation thread is unchanged. Greppable post-deploy invariants: `[context-overflow-recovery] exhausted cause=max-turns-interrupted` count equals `[admin-persist] writer=persistMessageExhaust outcome=ok` count for the same sessionId window, and one `[session-store] storeAgentSessionId` line marks the cold-restart that drove the on-screen rule.
 
 
 **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).
@@ -3795,15 +3795,15 @@ tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
 
 ## Memory Not Working
 
-**Symptom:** Maxy doesn't remember things you've told it, or search returns nothing.
+**Symptom:** SiteOffice doesn't remember things you've told it, or search returns nothing.
 
 **Check:**
-1. Ask Maxy: "Check the Neo4j connection"
-2. Ask Maxy: "Search memory for [something you know was stored]"
+1. Ask SiteOffice: "Check the Neo4j connection"
+2. Ask SiteOffice: "Search memory for [something you know was stored]"
 
 **Common causes:**
 - Neo4j service stopped — restart the platform, which restarts Neo4j
-- Memory index is stale — ask Maxy: "Reindex memory"
+- Memory index is stale — ask SiteOffice: "Reindex memory"
 
 ---
 
@@ -3812,12 +3812,12 @@ tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
 **Symptom:** You send a message to the bot and nothing happens.
 
 **Check:**
-1. Confirm the bot token is correct: ask Maxy "What Telegram bot token is configured?"
+1. Confirm the bot token is correct: ask SiteOffice "What Telegram bot token is configured?"
 2. Verify the bot is running: send `/start` to the bot in Telegram
-3. Check the MCP server logs: ask Maxy "Show Telegram plugin logs"
+3. Check the MCP server logs: ask SiteOffice "Show Telegram plugin logs"
 
 **Common causes:**
-- Bot token changed (if you regenerated it in BotFather) — update it by telling Maxy "Update my Telegram bot token"
+- Bot token changed (if you regenerated it in BotFather) — update it by telling SiteOffice "Update my Telegram bot token"
 - Webhook not connected — restart the platform
 
 ---
@@ -3827,11 +3827,11 @@ tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
 **Symptom:** A tool fails with an error, or a plugin says it can't connect.
 
 **Check:**
-1. Ask Maxy: "Show me recent errors"
-2. Ask Maxy: "Restart the [plugin name] plugin"
+1. Ask SiteOffice: "Show me recent errors"
+2. Ask SiteOffice: "Restart the [plugin name] plugin"
 
 **Common causes:**
-- Missing environment variable (API key, token) — the error message will name it; ask Maxy to help configure it
+- Missing environment variable (API key, token) — the error message will name it; ask SiteOffice to help configure it
 - MCP server crashed — restarting the platform restarts all MCP servers
 
 ---
@@ -3842,7 +3842,7 @@ tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
 
 **Check:**
 1. Confirm you have set a PIN in the admin UI at least once. On a fresh Pi or Hetzner box the `smbpasswd` entry does not exist until the first set-pin runs — mounts before that point always fail.
-2. Use the install owner as the username (`admin` on a Pi or Hetzner box; the Linux user that ran the installer on a self-hosted laptop) and the current Maxy PIN as the password. The SMB password is not stored separately — it is the PIN.
+2. Use the install owner as the username (`admin` on a Pi or Hetzner box; the Linux user that ran the installer on a self-hosted laptop) and the current SiteOffice PIN as the password. The SMB password is not stored separately — it is the PIN.
 3. If `<hostname>.local` does not resolve from your client, mount by LAN IP instead (`smb://192.168.1.50` on macOS, `\\192.168.1.50\<brand>` on Windows).
 4. Rotate the PIN in the admin UI. That re-triggers the `smbpasswd` sync on the device. If the resync log line reads `[set-pin] smbpasswd sync failed owner=<unknown> rc=-1 reason=install-owner-file-missing`, restore `~/.<brand>/.install-owner` from the installer log.
 
@@ -3852,35 +3852,35 @@ See [Samba Share](./samba.md) for the full credential model and per-OS mount syn
 
 ## Restarting the Platform
 
-From the admin interface, ask Maxy: "Restart the platform."
+From the admin interface, ask SiteOffice: "Restart the platform."
 
-If Maxy itself isn't responding (the page loads but the agent won't connect), try refreshing the browser. If the page itself won't load, the platform process may have stopped — power-cycle the Raspberry Pi by unplugging and reconnecting power, then wait a minute for services to restart automatically.
+If SiteOffice itself isn't responding (the page loads but the agent won't connect), try refreshing the browser. If the page itself won't load, the platform process may have stopped — power-cycle the Raspberry Pi by unplugging and reconnecting power, then wait a minute for services to restart automatically.
 
 ---
 
 ## Checking Logs
 
-Ask Maxy: "Show me the logs" or "Show errors from the last hour."
+Ask SiteOffice: "Show me the logs" or "Show errors from the last hour."
 
 For specific plugin logs: "Show Telegram logs" or "Show contacts plugin logs."
 
-Maxy has access to all platform logs and can filter them for you.
+SiteOffice has access to all platform logs and can filter them for you.
 
 ---
 
 ## Cloudflare Tunnel Down (Remote Access Broken)
 
-**Symptom:** You can reach Maxy on your local network but not via your public domain.
+**Symptom:** You can reach SiteOffice on your local network but not via your public domain.
 
-**Check:** Ask Maxy "Check the Cloudflare tunnel status."
+**Check:** Ask SiteOffice "Check the Cloudflare tunnel status."
 
-**Fix:** Ask Maxy "Restart the Cloudflare tunnel."
+**Fix:** Ask SiteOffice "Restart the Cloudflare tunnel."
 
-If the tunnel won't reconnect, re-run the Cloudflare setup: ask Maxy "Reconnect Cloudflare."
+If the tunnel won't reconnect, re-run the Cloudflare setup: ask SiteOffice "Reconnect Cloudflare."
 
-If the initial Cloudflare login fails during setup, Maxy will fall back to asking you for a connection key. You can create one in the Cloudflare dashboard (Maxy will guide you through this in the browser).
+If the initial Cloudflare login fails during setup, SiteOffice will fall back to asking you for a connection key. You can create one in the Cloudflare dashboard (SiteOffice will guide you through this in the browser).
 
-**If you switched Cloudflare accounts or are stuck on the wrong one:** ask Maxy "Reset my Cloudflare login and start over." This is a clean reset — Maxy clears every stored credential, then opens a fresh browser sign-in. The next sign-in binds to whichever Cloudflare account you choose, with no risk of the previous account's stored credentials silently coming back.
+**If you switched Cloudflare accounts or are stuck on the wrong one:** ask SiteOffice "Reset my Cloudflare login and start over." This is a clean reset — SiteOffice clears every stored credential, then opens a fresh browser sign-in. The next sign-in binds to whichever Cloudflare account you choose, with no risk of the previous account's stored credentials silently coming back.
 
 ---
 
@@ -3888,9 +3888,9 @@ If the initial Cloudflare login fails during setup, Maxy will fall back to askin
 
 `maxy-edge.service` (always-on front door) classifies upstream errors and serves a brand-aware response. There are two distinct user-visible shapes; the right one depends on what failed.
 
-**Branded holding page (brand logo + "Starting") for ~10 s during an upgrade — this is expected and self-healing.** The edge process binds the public port immediately, but `maxy.service` (the upstream UI) takes ~10 s after restart to apply the neo4j schema and mount its 11 routes. Any browser navigation that lands during that window gets a self-contained HTML holding page that polls `/api/health` and reloads automatically once the upstream binds. The page renders the brand logo (inlined as a base64 data URI at edge boot from `<install>/server/public/brand/<assets.logo>`) and the brand display/body fonts (loaded from fonts.googleapis.com) — both paths bypass the unavailable upstream so the page never makes a same-origin asset fetch. When `brand.logoContainsName` is true the logo replaces the productName text; otherwise the page falls back to "Maxy is starting". No operator action required. The diagnostic line in `~/.maxy/logs/edge.log` is `[edge] upstream http error path=… err=connect ECONNREFUSED 127.0.0.1:<UPSTREAM_PORT> err-class=econnrefused-coldstart upstream=…` and disappears as soon as upstream binds. Boot-time confirmation that the logo resolved: `[edge] brand=<name> holding-logo=inlined assets-dir=<path>` — `holding-logo=missing` means the logo file wasn't found at `assets-dir`, the page degrades to text-only.
+**Branded holding page (brand logo + "Starting") for ~10 s during an upgrade — this is expected and self-healing.** The edge process binds the public port immediately, but `maxy.service` (the upstream UI) takes ~10 s after restart to apply the neo4j schema and mount its 11 routes. Any browser navigation that lands during that window gets a self-contained HTML holding page that polls `/api/health` and reloads automatically once the upstream binds. The page renders the brand logo (inlined as a base64 data URI at edge boot from `<install>/server/public/brand/<assets.logo>`) and the brand display/body fonts (loaded from fonts.googleapis.com) — both paths bypass the unavailable upstream so the page never makes a same-origin asset fetch. When `brand.logoContainsName` is true the logo replaces the productName text; otherwise the page falls back to "SiteOffice is starting". No operator action required. The diagnostic line in `~/.maxy/logs/edge.log` is `[edge] upstream http error path=… err=connect ECONNREFUSED 127.0.0.1:<UPSTREAM_PORT> err-class=econnrefused-coldstart upstream=…` and disappears as soon as upstream binds. Boot-time confirmation that the logo resolved: `[edge] brand=<name> holding-logo=inlined assets-dir=<path>` — `holding-logo=missing` means the logo file wasn't found at `assets-dir`, the page degrades to text-only.
 
-**Branded plain-text 502 ("Bad Gateway (Maxy unavailable)") — real upstream failure, not cold-start.** Any error class other than `ECONNREFUSED` (timeouts, resets, host-unreachable) returns the existing 502 path. The diagnostic line carries `err-class=other`. Read the log with `tail -200 ~/.maxy/logs/edge.log | rg 'err-class=other'` and check `~/.maxy/logs/server.log` for upstream stack traces — the upstream itself is the source.
+**Branded plain-text 502 ("Bad Gateway (SiteOffice unavailable)") — real upstream failure, not cold-start.** Any error class other than `ECONNREFUSED` (timeouts, resets, host-unreachable) returns the existing 502 path. The diagnostic line carries `err-class=other`. Read the log with `tail -200 ~/.maxy/logs/edge.log | rg 'err-class=other'` and check `~/.maxy/logs/server.log` for upstream stack traces — the upstream itself is the source.
 
 **Continuous `err-class=econnrefused-coldstart` for >30 s past the last `[edge] listening` line** indicates the upstream never binds — the upgrade or boot has stalled. Recover via `sudo systemctl --user status maxy.service` and check the action runner log per the next section. Permanent-failure UI escalation (turning the holding page into an error after N seconds) is intentionally deferred.