@rubytech/create-maxy-code 0.1.467 → 0.1.468

package/package.json

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

package/payload/platform/plugins/google/references/auth.md

@@ -1,6 +1,25 @@
 # Google Auth Reference
 
-## Status: Phase 0 spike — documentation-backed, not yet token-verified
+## Status: Phase 0 gate CLOSED — token-verified 2026-07-18
+
+The round-trip was run against the live `sitedesk-code` client and succeeded. Recorded
+outcome (values themselves deliberately not recorded):
+
+| Check | Result |
+|---|---|
+| Calendar scope granted via browser consent | **yes** — `scope=https://www.googleapis.com/auth/calendar` returned on the redirect and echoed in the token response |
+| Refresh token issued (`access_type=offline`, `prompt=consent`) | **yes** — `refresh_token` present |
+| Access-token lifetime | `expires_in: 3599` (1 hour) |
+| Refresh-token lifetime in **Testing** | `refresh_token_expires_in: 604799` — **6.99 days**, confirming the predicted 7-day Testing cap empirically |
+| Device-code refusal (Verdict 1) | not run empirically; rests on Google's published allowlist. Optional, changes no decision (see the live-test section) |
+
+The 604799 figure is the concrete argument for completing brand verification: in Testing,
+every connected account silently re-consents weekly. Verification removes it.
+
+Phases 1–2 may now proceed against the flow below, with one caveat: the client-secret
+storage location is an **open Phase 1 decision** (see "Open Phase 1 decision" below).
+
+## Original spike verdict (documentation-backed, now confirmed)
 
 This is the Phase 0 deliverable: the OAuth-flow verdict for a per-account
 **Google Calendar** plugin on a headless install where the operator consents from a phone
@@ -184,12 +203,32 @@ on that brand, exactly as `outlookClientId` does. The client id ships as the bra
 `GOOGLE_CLIENT_ID` and inherited down the spawn chain (manager unit env → PTY → MCP child).
 
 Divergence from Outlook: the recommended Web-application flow (Option B) also needs a
-**client secret**. It ships **not** as a plaintext brand default but is held in the brand's
-secret store and stamped as `GOOGLE_CLIENT_SECRET` the same way Cloudflare tokens are held
-(never written to a project tree, never echoed). A brand that ships `googleClientId` empty
-has the plugin inert with an actionable signal (`clientIdConfigured=false`), register
-refuses, and no operator action makes it work until the vendor client exists — mirroring
-Outlook's inert behaviour.
+**client secret**, and where that secret lives is an **open Phase 1 decision**, not a
+settled one. A brand that ships `googleClientId` empty has the plugin inert with an
+actionable signal (`clientIdConfigured=false`), register refuses, and no operator action
+makes it work until the vendor client exists — mirroring Outlook's inert behaviour.
+
+### Open Phase 1 decision: there is no brand-level secret store
+
+An earlier draft of this file said the secret is "held in the brand's secret store, the same
+way Cloudflare tokens are held". That was wrong, and Phase 1 must resolve it before the
+register path is built. The two stores that actually exist are:
+
+- **`brands/<brand>/brand.json`** — ships inside the published npm package. It can carry the
+  client **id** (public, non-secret, exactly like `outlookClientId`) and must never carry a
+  secret.
+- **`~/<brand>-code/data/accounts/<accountId>/secrets`** — where the Cloudflare master token
+  lives (`platform/plugins/cloudflare/references/api.md`). This is **account-scoped**, one
+  per install.
+
+The mismatch: the Google client secret is **per-brand** (one vendor app serves every install
+of that brand), but the only real secret store is **per-account**. Outlook never hit this
+because its device-code flow is secret-less, so there is no precedent to copy. Phase 1 must
+choose and record one of: replicate the brand secret into each install's account-scoped
+secrets at provisioning time; introduce a genuine brand-scoped secret store; or drop to
+Option A (Desktop client), whose installed-app secret Google documents as non-confidential
+and which therefore needs no confidential store at all. Do not assume a brand secret store
+exists — nothing implements one today.
 
 ---
 
@@ -211,8 +250,15 @@ follow-up once the plugin lands (mirroring Outlook 1479/1485).
    - **Option B (recommended):** application type **Web application**. Add the authorized
      redirect URI `https://<brand-public-host>/api/google/oauth/callback` (the `/api/`
      prefix is required — see Option B above). Copy the **Client ID**
-     (→ `brand.json#googleClientId`) and **Client secret** (→ brand secret store as
-     `GOOGLE_CLIENT_SECRET`; never paste a secret into a chat transcript or the repo).
+     (→ `brand.json#googleClientId`).
+
+     **The client secret is shown exactly once and cannot be retrieved afterwards.** The
+     console displays only the last four characters from then on ("Viewing and downloading
+     client secrets is no longer available. If you have lost the secret below, please add a
+     new one."). Capture it at creation into its final destination, or plan to rotate. It is
+     never pasted into a chat transcript, a shell command that lands in history, or the repo.
+     Rotation is free and has no downtime: **Add secret**, store the new one, delete the old.
+     Where it should finally live is an open Phase 1 decision — see above.
    - **Option A (fallback):** application type **Desktop app**. Copy the **Client ID**.
 5. Set `googleClientId` in the brand's `brand.json` and re-bundle:
    ```jsonc
@@ -338,8 +384,13 @@ met and Phases 1–2 (the plugin build) proceed against the confirmed flow.
 
 | Brand | Client type | Redirect URI | Client ID | Status |
 |---|---|---|---|---|
-| `sitedesk-code` | Web application | `https://public.sitedesk.online/api/google/oauth/callback` | `1032860640027-p61l59fnog4mad5o7grginpaps9jnu8c.apps.googleusercontent.com` | Testing — test users pending, round-trip not yet run |
+| `sitedesk-code` | Web application | `https://public.sitedesk.online/api/google/oauth/callback` | `1032860640027-p61l59fnog4mad5o7grginpaps9jnu8c.apps.googleusercontent.com` | **Testing** — round-trip verified 2026-07-18; brand verification not started; secret pending rotation into its Phase 1 home |
 
 The public host was confirmed live and routing to the `platform/ui` server (it serves the
-brand's public page). Secrets are not recorded here; the client secret lives only in the
-brand secret store on the device.
+brand's public page). No secret or token is recorded here. The secret minted at creation was
+exposed to shell history during the manual round-trip and should be rotated (**Add secret** →
+store → delete old) when Phase 1 decides where it lives.
+
+Per-brand next step for `sitedesk-code`: start **brand/consent-screen verification** to lift
+the 100-test-user cap and the 7-day re-consent measured above. That review is the slow part;
+everything else is minutes.