@rubytech/create-maxy-code 0.1.473 → 0.1.475

package/dist/__tests__/google-client-id-env.test.js

@@ -1,5 +1,6 @@
-// acceptance gate for GOOGLE_CLIENT_ID / GOOGLE_PUBLIC_BASE stamping in the
-// claude-session-manager systemd unit (Task 1761).
+// acceptance gate for GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET stamping in the
+// claude-session-manager systemd unit (Task 1761; Task 1791 replaced
+// GOOGLE_PUBLIC_BASE with GOOGLE_CLIENT_SECRET and asserts the former is gone).
 //
 // This test exists because the first fix stamped only the darwin `.env` mirror
 // and missed this Linux unit, so on the actual (Ubuntu) install the google

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.473",
+  "version": "0.1.475",
   "description": "Install Maxy — AI for Productive People",
   "bin": {
     "create-maxy-code": "./dist/index.js"

package/payload/platform/neo4j/schema.cypher

@@ -1655,7 +1655,10 @@ FOR (cr:Credit) ON (cr.accountId);
 // ----------------------------------------------------------
 // :VoiceProfile holds the distilled style card for one (AdminUser, format).
 // Task 462: one profile per (accountId, userId, format); format ∈
-// {text, email, social-post, article, marketing-copy, note}.
+// {formal, informal, text, email, social-post, article, marketing-copy, note}.
+// Task 1795 added the broad `formal`/`informal` buckets. No constraint or
+// index change was needed — they resolve through the same `n.format =
+// $format` equality, and the uniqueness constraint already admits them.
 // The old (accountId, adminUserId) unique constraint is dropped and replaced.
 //
 // :VoiceEdit captures operator edits on agent drafts as feedback,

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 Maxy 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:c15214d349505b6337668b0362b849c9c5301fd25304800cf7384888a6a21435
+content-hash: sha256:3f1095125f80c4f095ed4fbe31bf54975c3ef99332fc3958138af6ad9e82b04e
 brand: maxy-code
 product-name: Maxy
 ---
@@ -2215,7 +2215,7 @@ Source: https://docs.getmaxy.com/google-guide.md
 # Google Calendar
 
 Live Google Calendar for one account: read the user's real events, and create,
-update, cancel, respond to and check availability against them. Eleven tools,
+update, cancel, respond to and check availability against them. Twelve tools,
 admin agent only.
 
 There is deliberately no Gmail surface here. Mail runs on the `email` plugin's
@@ -2228,14 +2228,23 @@ force Google's annual third-party security assessment. Calendar is only a
 `google-account-register` returns a consent URL. Relay it to the user: they open
 it on any device, sign in, and approve.
 
-Their browser then lands on a page that **fails to load**. That is expected, not
-a fault — the vendor app is a Desktop client, so Google redirects to a loopback
-address on the user's own device where nothing is listening. The address bar
-carries the code. Ask them to copy it and pass it to
+What happens next depends on where they approved.
+
+**If they approved on the machine this install runs on**, the connection
+completes by itself and their browser shows a page naming the connected account.
+Nothing is pasted. That page asks them to return to the chat and say so — do
+that, then call `google-account-register-poll` to confirm.
+
+**If they approved on another device**, such as a phone, their browser lands on
+a page that **fails to load**. That is expected, not a fault: the vendor app is
+a Desktop client, so Google redirects to a loopback address on the install, and
+a phone has no route to it. The address bar still carries the code. Ask them to
+copy the **whole URL** from the address bar and pass it to
 `google-account-register-submit`, which completes the connection.
 
-If they paste the whole `code=...` fragment, or a value containing `%2F`, the
-tool handles it. `google-account-register-poll` reports the outcome at any point.
+Paste the entire URL — the tool pulls the code out. A bare code, a `code=...`
+fragment, and a value containing `%2F` all work too.
+`google-account-register-poll` reports the outcome at any point.
 
 The register tool does not block and does not wait. A second register while one
 is already live is refused rather than overwriting it; that refusal names how
@@ -2271,9 +2280,12 @@ granted.
 
 ## When something is wrong
 
-**"GOOGLE_CLIENT_ID is not configured"** — this brand has no Google vendor app
-yet. Nothing the operator does on the device fixes it; the brand needs its own
-Google Cloud OAuth client. See `platform/plugins/google/references/auth.md`.
+**"GOOGLE_CLIENT_ID is not configured"**, or the same for
+`GOOGLE_CLIENT_SECRET` — this brand has no Google vendor app yet. Nothing the
+operator does on the device fixes it, and no file placed on the device fixes it
+either: the id and secret ship in the brand's `brand.json` and reach the device
+through an installer publish. The brand needs its own Google Cloud Desktop OAuth
+client. See `platform/plugins/google/references/auth.md`.
 
 **A 403 naming insufficient scope** — the connected account approved something
 narrower than the full calendar scope. Re-run `google-account-register` so they
@@ -2285,8 +2297,9 @@ Testing, where Google caps refresh tokens at seven days and limits the app to
 property of the vendor app, not a fault in the connection.
 
 **A registration never completes** — the consent URL was opened but not
-approved, or the callback could not be reached. `google-account-register-poll`
-reports `expired` once the pending entry outlives Google's code lifetime.
+approved, or the code was never copied back to
+`google-account-register-submit`. `google-account-register-poll` reports
+`expired` once the pending entry outlives Google's code lifetime.
 
 ---
 # QuickBooks Online
@@ -2817,7 +2830,7 @@ 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.
 
 - **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.
+- **Documents and posts** — paginated 10 at a time. Maxy shows each item with its source, date, recipient or topic, and a one-line preview. You name the format on every command — Maxy never guesses it. Reach for the broad buckets, `formal` or `informal`, unless a narrower one (`email`, `article`, `note`, `social-post`, `marketing-copy`, `text`) genuinely fits. 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).
 
 Skip a batch if none qualify, or stop at any time — the next session resumes where you left off.
 
@@ -2857,7 +2870,7 @@ Voice mirror is on by default for every drafting skill. To opt out for one, set
 
 ## Status
 
-Voice mirror is live end-to-end. Six corpus formats (text, email, social-post, article, note, marketing-copy), five tools (`voice-tag-content`, `voice-distil-profile`, `voice-retrieve-conditioning`, `voice-record-feedback`, `voice-ingest-session-text`), on-demand session-turn capture, and wiring into the three live drafting surfaces (email composition, property brochures, investor data room) are all live. When no voice profile exists on the account for a given format, every drafting skill degrades gracefully — the output matches what it was before voice mirror was installed.
+Voice mirror is live end-to-end. Eight corpus formats (the broad buckets `formal` and `informal`, plus the narrower `text`, `email`, `social-post`, `article`, `note`, `marketing-copy`), five tools (`voice-tag-content`, `voice-distil-profile`, `voice-retrieve-conditioning`, `voice-record-feedback`, `voice-ingest-session-text`), on-demand session-turn capture, and wiring into the three live drafting surfaces (email composition, property brochures, investor data room) are all live. When no voice profile exists on the account for a given format, every drafting skill degrades gracefully — the output matches what it was before voice mirror was installed.
 
 ---
 # Admin UI Reference
@@ -2921,7 +2934,7 @@ either is a regression.
 |---|---|---|
 | `/session` | Admin cookie session: PIN-gated mint, validate, rotate. | `GET /`, `POST /` |
 | `/sessions` | Legacy admin-server conversation routes. No UI consumer remains after the ConversationsModal was retired; the surviving handlers are deletion candidates and not described here. | (legacy, no live caller) |
-| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. Each row also carries its sidecar `senderId`. For a WhatsApp/Telegram row with a `senderId` and no operator rename or ai-title (`titleSource:'prefix'`), the route resolves a contact `personName` and the sidebar renders the reader panel's `"<name>  <number>"` label via the shared `operatorConvName`, degrading to the number alone then the stripped title on a miss, so a Sessions row and that conversation's reader-panel row read identically. The name comes from the shared `resolveOperatorNamesBySender` helper the WhatsApp reader also calls, so the two surfaces cannot drift; a renamed or ai-titled channel row keeps its own title. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> channelNameCandidates=<n> channelNamesResolved=<n> unknownChannel=<n> excludedPublicWebchat=<n>`, and each unresolved channel name logs one `[admin-sessions-list] op=channel-name-unresolved sessionId=<id8> channel=<whatsapp\|telegram> senderId=<id> reason=<no-senderId\|classify-miss\|neo4j-down>` line so a persistent `channelNamesResolved` shortfall is never silent. | `GET /` |
+| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. Each row also carries its sidecar `senderId`. For a WhatsApp/Telegram row with a `senderId` and no operator rename or ai-title (`titleSource:'prefix'`), the route resolves a contact `personName` and the sidebar renders the reader panel's `"<name>  <number>"` label via the shared `operatorConvName`, degrading to the number alone then the stripped title on a miss, so a Sessions row and that conversation's reader-panel row read identically. A channel row name has two sources, in precedence order. First the shared `resolveOperatorNamesBySender` helper the WhatsApp reader also calls, which matches the sender phone against the account's admins — that names an admin WhatsApp session and every Telegram session. Second, for a `whatsapp` row only, the WhatsApp pushName from the account's on-disk message store (`storePushNamesBySender` over `readConversationSummaries`, keyed by `normalizeE164` of the counterparty phone so a `+44 7…` sender matches a `447…` store key). The store is consulted only when the resolver reports **no binding** for that sender. That is typically a public WhatsApp customer, the case this exists for — such a sender has no admin record and so can only be named by the store, and without it those rows degraded to the bare number while the reader panel named them — though an admin missing from `users.json` qualifies too. A resolver miss caused by Neo4j being unreachable deliberately does NOT qualify: that is an outage rather than an absent binding, so the row degrades to the number and still logs `reason=neo4j-down`, keeping the outage signal intact. Telegram has no message store and is never looked up. The store read is guarded: a corrupt or absent store degrades to no pushName and logs `op=store-unreadable`, never 500s the list. Both sources are the ones the reader itself uses, so the two surfaces cannot drift; a renamed or ai-titled channel row keeps its own title. The Sessions list reads the viewed account's own store only. An account-manager's thread persists under the house account rather than the sub-account it manages, so on a multi-account install viewing a sub-account that row is not named here even though the reader panel names it — the reader additionally consults the house store, filtered to manager phones bound to that sub. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> channelNameCandidates=<n> channelNamesResolved=<n> (operator=<n> store=<n>) unknownChannel=<n> excludedPublicWebchat=<n>`, and each unresolved channel name logs one `[admin-sessions-list] op=channel-name-unresolved sessionId=<id8> channel=<whatsapp\|telegram> senderId=<id> reason=<no-senderId\|classify-miss\|neo4j-down>` line — emitted only when **both** sources miss, so a residual shortfall means a genuinely nameless sender rather than the expected public-customer floor, and the `operator=`/`store=` split says which source is carrying the names. | `GET /` |
 | `/session-delete` | POST `{ sessionId }`. Thin proxy over the manager: POST `/:id/stop` (idempotent) then DELETE `/:id`. Sends **no** accountId. The manager resolves the session by scanning every slug under `projects/` for its JSONL (`slugForExistingJsonl`, covering `archive/`), exactly as the sidebar list enumerates rows, and gates on file existence alone — so any session the operator can see is deletable. This replaces the earlier accountId-derived slug and the `!row` term, which narrowed resolution below the list and left a session under a non-house slug with no watcher row (e.g. a legacy `-home-admin` session on a single-account install) listed yet un-deletable. Account scope is a view filter, not a delete gate — admin access is install-wide, so there is nothing to scope against. The sibling `/session-stop` (the standalone End control) resolves identically and also forwards no accountId. | `POST /` |
 | `/session-rc-spawn` | POST `{ sessionId?, name? }`. Fire-and-forget `claude --remote-control [name] [--session-id <sid>]`. Present `sessionId` resumes; absent starts a fresh session (also used by the sidebar's "New session" button — it no longer opens claude.ai/code directly). Proxies to the manager's `/rc-spawn`, which waits up to **60 s** (raised from 12 s) for the spawned PTY to bind and returns `{ spawnedPid, sessionId, bridgeSessionId, slug, outcome, reason }`. For a webchat-bound spawn (every admin-gated host's "New session", returning a same-origin `/chat?session=<id>` target — `resolveRcSpawnOutcome` → `sameOrigin:true`) the Sidebar navigates the **current** tab via `window.location.assign`, replacing the dashboard in place (back returns to it); only a claude.ai/code slug (`sameOrigin:false`, the bare-admin resume bridge, never a new-session outcome) navigates a separately-opened tab. On `timeout` or `spawn-failed` it shows an error modal (reason + sessionId) and **never** opens a bare claude.ai/code tab. The new process registers itself as its own Remote Control entry in claude.ai/code. | `POST /` |
 | `/claude-sessions` | **Spawn surface only**. `POST /` is the Sidebar new-session-with-prompt path, cookie-auth only (the recorder loopback caller was removed; LinkedIn ingest moved to `/rc-spawn`). The former UI-facing handlers (SSE row feed, list, resume, stop, rename, archive, delete, `/:id/meta`, `/:id/input`, `/:id/log`) were removed — the maxy dashboard no longer manages or displays sessions. | `POST /` |

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

@@ -56,7 +56,7 @@ either is a regression.
 |---|---|---|
 | `/session` | Admin cookie session: PIN-gated mint, validate, rotate. | `GET /`, `POST /` |
 | `/sessions` | Legacy admin-server conversation routes. No UI consumer remains after the ConversationsModal was retired; the surviving handlers are deletion candidates and not described here. | (legacy, no live caller) |
-| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. Each row also carries its sidecar `senderId`. For a WhatsApp/Telegram row with a `senderId` and no operator rename or ai-title (`titleSource:'prefix'`), the route resolves a contact `personName` and the sidebar renders the reader panel's `"<name>  <number>"` label via the shared `operatorConvName`, degrading to the number alone then the stripped title on a miss, so a Sessions row and that conversation's reader-panel row read identically. The name comes from the shared `resolveOperatorNamesBySender` helper the WhatsApp reader also calls, so the two surfaces cannot drift; a renamed or ai-titled channel row keeps its own title. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> channelNameCandidates=<n> channelNamesResolved=<n> unknownChannel=<n> excludedPublicWebchat=<n>`, and each unresolved channel name logs one `[admin-sessions-list] op=channel-name-unresolved sessionId=<id8> channel=<whatsapp\|telegram> senderId=<id> reason=<no-senderId\|classify-miss\|neo4j-down>` line so a persistent `channelNamesResolved` shortfall is never silent. | `GET /` |
+| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. Each row also carries its sidecar `senderId`. For a WhatsApp/Telegram row with a `senderId` and no operator rename or ai-title (`titleSource:'prefix'`), the route resolves a contact `personName` and the sidebar renders the reader panel's `"<name>  <number>"` label via the shared `operatorConvName`, degrading to the number alone then the stripped title on a miss, so a Sessions row and that conversation's reader-panel row read identically. A channel row name has two sources, in precedence order. First the shared `resolveOperatorNamesBySender` helper the WhatsApp reader also calls, which matches the sender phone against the account's admins — that names an admin WhatsApp session and every Telegram session. Second, for a `whatsapp` row only, the WhatsApp pushName from the account's on-disk message store (`storePushNamesBySender` over `readConversationSummaries`, keyed by `normalizeE164` of the counterparty phone so a `+44 7…` sender matches a `447…` store key). The store is consulted only when the resolver reports **no binding** for that sender. That is typically a public WhatsApp customer, the case this exists for — such a sender has no admin record and so can only be named by the store, and without it those rows degraded to the bare number while the reader panel named them — though an admin missing from `users.json` qualifies too. A resolver miss caused by Neo4j being unreachable deliberately does NOT qualify: that is an outage rather than an absent binding, so the row degrades to the number and still logs `reason=neo4j-down`, keeping the outage signal intact. Telegram has no message store and is never looked up. The store read is guarded: a corrupt or absent store degrades to no pushName and logs `op=store-unreadable`, never 500s the list. Both sources are the ones the reader itself uses, so the two surfaces cannot drift; a renamed or ai-titled channel row keeps its own title. The Sessions list reads the viewed account's own store only. An account-manager's thread persists under the house account rather than the sub-account it manages, so on a multi-account install viewing a sub-account that row is not named here even though the reader panel names it — the reader additionally consults the house store, filtered to manager phones bound to that sub. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> channelNameCandidates=<n> channelNamesResolved=<n> (operator=<n> store=<n>) unknownChannel=<n> excludedPublicWebchat=<n>`, and each unresolved channel name logs one `[admin-sessions-list] op=channel-name-unresolved sessionId=<id8> channel=<whatsapp\|telegram> senderId=<id> reason=<no-senderId\|classify-miss\|neo4j-down>` line — emitted only when **both** sources miss, so a residual shortfall means a genuinely nameless sender rather than the expected public-customer floor, and the `operator=`/`store=` split says which source is carrying the names. | `GET /` |
 | `/session-delete` | POST `{ sessionId }`. Thin proxy over the manager: POST `/:id/stop` (idempotent) then DELETE `/:id`. Sends **no** accountId. The manager resolves the session by scanning every slug under `projects/` for its JSONL (`slugForExistingJsonl`, covering `archive/`), exactly as the sidebar list enumerates rows, and gates on file existence alone — so any session the operator can see is deletable. This replaces the earlier accountId-derived slug and the `!row` term, which narrowed resolution below the list and left a session under a non-house slug with no watcher row (e.g. a legacy `-home-admin` session on a single-account install) listed yet un-deletable. Account scope is a view filter, not a delete gate — admin access is install-wide, so there is nothing to scope against. The sibling `/session-stop` (the standalone End control) resolves identically and also forwards no accountId. | `POST /` |
 | `/session-rc-spawn` | POST `{ sessionId?, name? }`. Fire-and-forget `claude --remote-control [name] [--session-id <sid>]`. Present `sessionId` resumes; absent starts a fresh session (also used by the sidebar's "New session" button — it no longer opens claude.ai/code directly). Proxies to the manager's `/rc-spawn`, which waits up to **60 s** (raised from 12 s) for the spawned PTY to bind and returns `{ spawnedPid, sessionId, bridgeSessionId, slug, outcome, reason }`. For a webchat-bound spawn (every admin-gated host's "New session", returning a same-origin `/chat?session=<id>` target — `resolveRcSpawnOutcome` → `sameOrigin:true`) the Sidebar navigates the **current** tab via `window.location.assign`, replacing the dashboard in place (back returns to it); only a claude.ai/code slug (`sameOrigin:false`, the bare-admin resume bridge, never a new-session outcome) navigates a separately-opened tab. On `timeout` or `spawn-failed` it shows an error modal (reason + sessionId) and **never** opens a bare claude.ai/code tab. The new process registers itself as its own Remote Control entry in claude.ai/code. | `POST /` |
 | `/claude-sessions` | **Spawn surface only**. `POST /` is the Sidebar new-session-with-prompt path, cookie-auth only (the recorder loopback caller was removed; LinkedIn ingest moved to `/rc-spawn`). The former UI-facing handlers (SSE row feed, list, resume, stop, rename, archive, delete, `/:id/meta`, `/:id/input`, `/:id/log`) were removed — the maxy dashboard no longer manages or displays sessions. | `POST /` |

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

@@ -1,7 +1,7 @@
 # Google Calendar
 
 Live Google Calendar for one account: read the user's real events, and create,
-update, cancel, respond to and check availability against them. Eleven tools,
+update, cancel, respond to and check availability against them. Twelve tools,
 admin agent only.
 
 There is deliberately no Gmail surface here. Mail runs on the `email` plugin's
@@ -14,14 +14,23 @@ force Google's annual third-party security assessment. Calendar is only a
 `google-account-register` returns a consent URL. Relay it to the user: they open
 it on any device, sign in, and approve.
 
-Their browser then lands on a page that **fails to load**. That is expected, not
-a fault — the vendor app is a Desktop client, so Google redirects to a loopback
-address on the user's own device where nothing is listening. The address bar
-carries the code. Ask them to copy it and pass it to
+What happens next depends on where they approved.
+
+**If they approved on the machine this install runs on**, the connection
+completes by itself and their browser shows a page naming the connected account.
+Nothing is pasted. That page asks them to return to the chat and say so — do
+that, then call `google-account-register-poll` to confirm.
+
+**If they approved on another device**, such as a phone, their browser lands on
+a page that **fails to load**. That is expected, not a fault: the vendor app is
+a Desktop client, so Google redirects to a loopback address on the install, and
+a phone has no route to it. The address bar still carries the code. Ask them to
+copy the **whole URL** from the address bar and pass it to
 `google-account-register-submit`, which completes the connection.
 
-If they paste the whole `code=...` fragment, or a value containing `%2F`, the
-tool handles it. `google-account-register-poll` reports the outcome at any point.
+Paste the entire URL — the tool pulls the code out. A bare code, a `code=...`
+fragment, and a value containing `%2F` all work too.
+`google-account-register-poll` reports the outcome at any point.
 
 The register tool does not block and does not wait. A second register while one
 is already live is refused rather than overwriting it; that refusal names how
@@ -57,9 +66,12 @@ granted.
 
 ## When something is wrong
 
-**"GOOGLE_CLIENT_ID is not configured"** — this brand has no Google vendor app
-yet. Nothing the operator does on the device fixes it; the brand needs its own
-Google Cloud OAuth client. See `platform/plugins/google/references/auth.md`.
+**"GOOGLE_CLIENT_ID is not configured"**, or the same for
+`GOOGLE_CLIENT_SECRET` — this brand has no Google vendor app yet. Nothing the
+operator does on the device fixes it, and no file placed on the device fixes it
+either: the id and secret ship in the brand's `brand.json` and reach the device
+through an installer publish. The brand needs its own Google Cloud Desktop OAuth
+client. See `platform/plugins/google/references/auth.md`.
 
 **A 403 naming insufficient scope** — the connected account approved something
 narrower than the full calendar scope. Re-run `google-account-register` so they
@@ -71,5 +83,6 @@ Testing, where Google caps refresh tokens at seven days and limits the app to
 property of the vendor app, not a fault in the connection.
 
 **A registration never completes** — the consent URL was opened but not
-approved, or the callback could not be reached. `google-account-register-poll`
-reports `expired` once the pending entry outlives Google's code lifetime.
+approved, or the code was never copied back to
+`google-account-register-submit`. `google-account-register-poll` reports
+`expired` once the pending entry outlives Google's code lifetime.

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

@@ -30,7 +30,7 @@ In the admin chat, ask: **"Start the voice-mirror backfill."**
 {{productName}} 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. {{productName}} 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. {{productName}} 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, {{productName}} polished). Override the detected format if one is wrong.
+- **Documents and posts** — paginated 10 at a time. {{productName}} shows each item with its source, date, recipient or topic, and a one-line preview. You name the format on every command — {{productName}} never guesses it. Reach for the broad buckets, `formal` or `informal`, unless a narrower one (`email`, `article`, `note`, `social-post`, `marketing-copy`, `text`) genuinely fits. 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, {{productName}} polished).
 
 Skip a batch if none qualify, or stop at any time — the next session resumes where you left off.
 
@@ -70,4 +70,4 @@ Voice mirror is on by default for every drafting skill. To opt out for one, set
 
 ## Status
 
-Voice mirror is live end-to-end. Six corpus formats (text, email, social-post, article, note, marketing-copy), five tools (`voice-tag-content`, `voice-distil-profile`, `voice-retrieve-conditioning`, `voice-record-feedback`, `voice-ingest-session-text`), on-demand session-turn capture, and wiring into the three live drafting surfaces (email composition, property brochures, investor data room) are all live. When no voice profile exists on the account for a given format, every drafting skill degrades gracefully — the output matches what it was before voice mirror was installed.
+Voice mirror is live end-to-end. Eight corpus formats (the broad buckets `formal` and `informal`, plus the narrower `text`, `email`, `social-post`, `article`, `note`, `marketing-copy`), five tools (`voice-tag-content`, `voice-distil-profile`, `voice-retrieve-conditioning`, `voice-record-feedback`, `voice-ingest-session-text`), on-demand session-turn capture, and wiring into the three live drafting surfaces (email composition, property brochures, investor data room) are all live. When no voice profile exists on the account for a given format, every drafting skill degrades gracefully — the output matches what it was before voice mirror was installed.

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

@@ -1,6 +1,6 @@
 {
   "name": "google",
-  "description": "Live Google Calendar for one account via the Google Calendar API v3 — read plus control. Per-account OAuth authorization-code + PKCE; the consent URL is minted by the plugin and the code is exchanged by platform/ui, which holds the house-only client secret. One account can connect several Google accounts; every operational tool takes an optional account selector (the email address) and refuses ambiguously when two or more are connected and none is named. There is deliberately no Gmail surface — mail runs on the `email` plugin's IMAP/SMTP path, and Gmail's restricted scopes would force Google's annual third-party security assessment, whereas Calendar is only a sensitive scope. Tools — google-account-register / google-account-register-submit / google-account-register-poll: connect a Google Calendar (returns a consent URL; the user approves, lands on a page that fails to load by design, and pastes the code back to submit); google-calendar-list: events in the next rangeDays days, recurring series expanded; google-calendar-event: one event by id; google-calendar-create / google-calendar-update / google-calendar-cancel: control events, attendees notified, update changes only the fields named; google-calendar-respond: accept, decline or tentatively accept an invitation, leaving other attendees' responses untouched; google-calendar-freebusy: busy blocks for this or named calendars; google-account-info: auth state for one connected Google account; google-account-list: every connected Google account with its own status.",
+  "description": "Live Google Calendar for one account via the Google Calendar API v3 — read plus control. Per-account OAuth authorization-code + PKCE against a Desktop client whose id and secret ship in brand config; the plugin mints the consent URL and exchanges the code in-process, and nothing in platform/ui participates. One account can connect several Google accounts; every operational tool takes an optional account selector (the email address) and refuses ambiguously when two or more are connected and none is named. There is deliberately no Gmail surface — mail runs on the `email` plugin's IMAP/SMTP path, and Gmail's restricted scopes would force Google's annual third-party security assessment, whereas Calendar is only a sensitive scope. Tools — google-account-register / google-account-register-submit / google-account-register-poll: connect a Google Calendar (returns a consent URL; approving on the install machine completes by itself and the browser confirms it, while approving on another device lands on a page that fails to load by design and the user pastes the address-bar URL back to submit); google-calendar-list: events in the next rangeDays days, recurring series expanded; google-calendar-event: one event by id; google-calendar-create / google-calendar-update / google-calendar-cancel: control events, attendees notified, update changes only the fields named; google-calendar-respond: accept, decline or tentatively accept an invitation, leaving other attendees' responses untouched; google-calendar-freebusy: busy blocks for this or named calendars; google-account-info: auth state for one connected Google account; google-account-list: every connected Google account with its own status.",
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"

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

@@ -1,6 +1,6 @@
 ---
 name: google
-description: Live Google Calendar for one account via the Google Calendar API v3 — read plus control. Per-account OAuth authorization-code + PKCE; the consent URL is minted by the plugin and the code is exchanged by platform/ui, which holds the house-only client secret. One account can connect several Google accounts; every operational tool takes an optional account selector (the email address) and refuses ambiguously when two or more are connected and none is named. There is deliberately no Gmail surface — mail runs on the `email` plugin's IMAP/SMTP path, and Gmail's restricted scopes would force Google's annual third-party security assessment, whereas Calendar is only a sensitive scope. Tools — google-account-register / google-account-register-submit / google-account-register-poll: connect a Google Calendar (returns a consent URL; the user approves, lands on a page that fails to load by design, and pastes the code back to submit); google-calendar-list: events in the next rangeDays days, recurring series expanded; google-calendar-event: one event by id; google-calendar-create / google-calendar-update / google-calendar-cancel: control events, attendees notified, update changes only the fields named; google-calendar-respond: accept, decline or tentatively accept an invitation, leaving other attendees' responses untouched; google-calendar-freebusy: busy blocks for this or named calendars; google-account-info: auth state for one connected Google account; google-account-list: every connected Google account with its own status.
+description: Live Google Calendar for one account via the Google Calendar API v3 — read plus control. Per-account OAuth authorization-code + PKCE against a Desktop client whose id and secret ship in brand config; the plugin mints the consent URL and exchanges the code in-process, and nothing in platform/ui participates. One account can connect several Google accounts; every operational tool takes an optional account selector (the email address) and refuses ambiguously when two or more are connected and none is named. There is deliberately no Gmail surface — mail runs on the `email` plugin's IMAP/SMTP path, and Gmail's restricted scopes would force Google's annual third-party security assessment, whereas Calendar is only a sensitive scope. Tools — google-account-register / google-account-register-submit / google-account-register-poll: connect a Google Calendar (returns a consent URL; approving on the install machine completes by itself and the browser confirms it, while approving on another device lands on a page that fails to load by design and the user pastes the address-bar URL back to submit); google-calendar-list: events in the next rangeDays days, recurring series expanded; google-calendar-event: one event by id; google-calendar-create / google-calendar-update / google-calendar-cancel: control events, attendees notified, update changes only the fields named; google-calendar-respond: accept, decline or tentatively accept an invitation, leaving other attendees' responses untouched; google-calendar-freebusy: busy blocks for this or named calendars; google-account-info: auth state for one connected Google account; google-account-list: every connected Google account with its own status.
 tools:
   - name: google-account-register
     publicAllowlist: false
@@ -50,8 +50,7 @@ mcp:
     ACCOUNT_ID: ${ACCOUNT_ID}
     SESSION_ID: ${SESSION_ID}
     GOOGLE_CLIENT_ID: ${GOOGLE_CLIENT_ID}
-    GOOGLE_PUBLIC_BASE: ${GOOGLE_PUBLIC_BASE}
-    MAXY_UI_INTERNAL_PORT: ${MAXY_UI_INTERNAL_PORT}
+    GOOGLE_CLIENT_SECRET: ${GOOGLE_CLIENT_SECRET}
 mcp-manifest: auto
 ---
 
@@ -75,16 +74,31 @@ Authorization-code + PKCE, not device-code. Google's device flow serves a fixed
 scope allowlist that excludes Calendar, and the out-of-band paste-a-code flow
 has been blocked since 31 January 2023, so consent must land on a real redirect.
 
-`google-account-register` mints the PKCE pair and a `state` nonce, persists them
-single-slot per account, and returns a consent URL. The user opens it on any
-device and approves. Google redirects to `/api/google/oauth/callback` on this
-install's public host, which verifies `state`, exchanges the code, resolves the
-account's email from its primary calendar, and writes encrypted tokens.
-`google-account-register-poll` then reports the outcome from local state.
+The vendor app is a **Desktop (installed app)** client, the one type whose
+secret Google sanctions shipping in distributed software. Its id and secret come
+from `brand.json` and are stamped by the installer together or not at all.
 
-The client secret never enters this MCP process. A Web-application client must
-present it to refresh, so refresh is delegated to `platform/ui`, which holds it
-at `${PLATFORM_ROOT}/config/google-house.env`.
+`google-account-register` mints the PKCE pair, binds a single-shot listener on
+`127.0.0.1` at an OS-assigned port, and returns a consent URL carrying that
+port. The host is always the IP literal, never `localhost` — Google's
+port-agnostic loopback matching applies only to the literal.
+
+Consent on the install's own machine reaches that listener, which verifies
+`state`, completes the exchange, and renders a page naming the account. Consent
+on another device cannot reach it, so the redirect fails to load and the user
+pastes the address-bar URL into `google-account-register-submit`. Both paths
+exchange in-process with the stored verifier, resolve the email from the primary
+calendar, and write encrypted tokens. `google-account-register-poll` reports the
+outcome from local state.
+
+The pending entry stores the redirect it issued, because the port varies per
+registration and Google compares the exchange's `redirect_uri` byte for byte
+against the one that issued the code. A failed bind falls back to
+`http://127.0.0.1:8571`, leaving the paste path exactly as it was.
+
+Token refresh also runs in-process against Google. Nothing in `platform/ui`
+mints, exchanges or refreshes a Google credential; its only Google surface is the
+standing pending audit below, which reads a file's age and never decrypts.
 
 ## Scope
 
@@ -97,8 +111,53 @@ requesting `openid`/`email`/`profile`, so consent stays minimal.
 | Variable | Source | Effect when unset |
 |---|---|---|
 | `GOOGLE_CLIENT_ID` | `brand.json#googleClientId` | Plugin inert; register refuses with an actionable message |
-| `GOOGLE_PUBLIC_BASE` | install's public host origin | Register refuses; the redirect cannot be built |
-| `MAXY_ADMIN_BASE` | loopback `platform/ui` base | Defaults to `http://127.0.0.1:19301` |
+| `GOOGLE_CLIENT_SECRET` | `brand.json#googleClientSecret` | Plugin inert; register refuses. Stamped with `GOOGLE_CLIENT_ID` or not at all |
+
+Both reach this process by env inheritance from the session-manager unit, which
+is why they are declared in the self-named `${FOO}` form (see
+`mcp-descriptor-resolve.ts`). Boot reports `clientIdConfigured` and
+`clientSecretConfigured`; either reading `false` on a brand that ships both is
+the mis-stamp signature.
+
+## Observability
+
+Two failures here emit no event and do not reproduce on demand: a registration
+the operator abandons, and a refresh token that expires. Nothing touches either;
+they simply stop being true at some future date. Two standing audits report them
+without anything polling.
+
+| Audit | Where it runs | Interval | Per-finding line | Heartbeat |
+|---|---|---|---|---|
+| Stranded pending registration | in-process in `platform/ui` | 5 min | `[google-oauth] op=pending-stranded account=<id> ageSec=<N>` | `[google-oauth] op=pending-audit scanned=<N> stranded=<M>` |
+| Refresh-token TTL | spawned `mcp/dist/scripts/account-audit.js` | 1 hour | `[google-account-audit] account=<id> email=<addr> refreshTtlDays=<D> status=<ok\|expiring\|expired>` | `[google-account-audit] op=heartbeat accounts=<N> ok=<A> expiring=<B> expired=<C>` |
+
+They run on different mechanisms deliberately. The pending audit needs no
+decrypt — file age alone is conclusive — so it runs in-process and stays
+independent of whether any spawn is healthy. The refresh audit must decrypt the
+token blob with the per-account key, so it runs where `TokenStore` lives.
+
+**The heartbeat is the point.** Each audit emits its heartbeat on every cycle,
+including cycles that find nothing, because an audit that has stopped running is
+otherwise indistinguishable from one reporting all-clear. The absence of a
+heartbeat over more than one interval is the documented signal that the audit is
+down — not silence meaning healthy. A failed pending cycle logs
+`op=pending-audit-error`, deliberately a different token from the heartbeat so a
+broken cycle can never be counted as a clean one.
+
+`refreshTtlDays` is days left on Google's 180-day **inactivity** revocation
+clock, measured from `lastRefresh`. Google publishes no refresh-token expiry and
+the stored blob holds none, so this is the only bounded, locally-computable
+clock. It does not predict the user revoking access or changing their password,
+neither of which is observable from here. A connection holding no refresh token
+at all reports `expired` with zero days regardless of how recently it was
+written, because it dies when its access token lapses about an hour out.
+
+Diagnostic path:
+
+```
+~/<brand>-code/platform/scripts/logs-read.sh --tail server 200 \
+  | grep -E '\[google-oauth\]|\[google-account-audit\]'
+```
 
 ## Out of scope
 

package/payload/platform/plugins/google/mcp/dist/__tests__/account-audit.test.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=account-audit.test.d.ts.map

package/payload/platform/plugins/google/mcp/dist/__tests__/account-audit.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"account-audit.test.d.ts","sourceRoot":"","sources":["../../src/__tests__/account-audit.test.ts"],"names":[],"mappings":""}