@rubytech/create-maxy-code 0.1.282 → 0.1.283

package/package.json

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

package/payload/platform/config/brand.json

@@ -55,7 +55,6 @@
   },
 
   "externalPlugins": [
-    { "name": "telegram", "marketplace": "claude-plugins-official", "channelPlugin": true },
     { "name": "discord",  "marketplace": "claude-plugins-official", "channelPlugin": true },
     { "name": "imessage", "marketplace": "claude-plugins-official", "channelPlugin": true },
     { "name": "superpowers", "marketplace": "claude-plugins-official" },

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:add28451435be577d674216c86cd03078f5b25d03ce6def9fc61962971c8e9ed
+content-hash: sha256:5dae80dcc0e3d36e755dcf26570c4d7c8893b6198b8cd769b3e5c6c1c79169f5
 brand: maxy-code
 product-name: Maxy
 ---
@@ -1728,13 +1728,13 @@ 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 Maxy: "Set up Telegram" or "Configure the Telegram bot." Setup runs entirely in the admin chat — there is no settings page.
 
-Maxy will ask for your bot token, then save it and activate the plugin. The bot is now connected.
+Maxy asks for your bot token, then asks whether this is an **admin bot** (only your numeric Telegram IDs may message it) or a **public bot** (customer-facing, with a DM policy). It verifies the token, registers the bot's webhook on your brand's edge, stores the token under your brand's config (never in a shared system directory), and — for a public bot — sets the agent that will answer. 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.
+In Telegram, open your bot and send `/start`, then a message. Maxy receives it and replies in the same chat. Admin-bot messages from your registered IDs reach the admin agent; public-bot messages reach the public agent you selected.
 
 ## Sending Messages via Maxy
 

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

@@ -1,6 +1,6 @@
 {
   "name": "cloudflare",
-  "description": "Cloudflare operations — tunnel setup/reset, DNS, Pages hosting, D1 data capture, and dashboard guidance. Zero agent-facing MCP tools; every operation is the agent invoking `cloudflared` or `wrangler` directly via Bash, calling the Cloudflare API with a minted narrow token, or quoting a dashboard click-path the operator performs themselves.",
+  "description": "Cloudflare operations — tunnel setup/reset, DNS, Pages hosting, D1 data capture, and dashboard guidance. Zero agent-facing MCP tools; every operation is the agent invoking `cloudflared` or `wrangler` directly via Bash, calling the Cloudflare API with a reused per-scope narrow token, or quoting a dashboard click-path the operator performs themselves.",
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"

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

@@ -1,13 +1,13 @@
 ---
 name: cloudflare
-description: Cloudflare operations — tunnel setup/reset, DNS, Pages hosting, D1 data capture, and dashboard guidance. Zero agent-facing MCP tools; every operation is the agent invoking `cloudflared` or `wrangler` directly via Bash, calling the Cloudflare API with a minted narrow token, or quoting a dashboard click-path the operator performs themselves.
+description: Cloudflare operations — tunnel setup/reset, DNS, Pages hosting, D1 data capture, and dashboard guidance. Zero agent-facing MCP tools; every operation is the agent invoking `cloudflared` or `wrangler` directly via Bash, calling the Cloudflare API with a reused per-scope narrow token, or quoting a dashboard click-path the operator performs themselves.
 tools: []
 mcp-manifest: skip
 ---
 
 # Cloudflare Tunnel
 
-Each installation has its own Cloudflare account. Two auth paths serve two operation classes. **Tunnel** auth is OAuth: the operator signs in via `cloudflared tunnel login` (issued by the agent through Bash); `cloudflared` writes `cert.pem` to the brand-scoped config directory. **API** auth (DNS, zones, Pages, D1, Access, token mint) is the master token: the operator provisions one fully-scoped master token in the dashboard (an advanced, operator-guided step the agent never automates), stored at the account-scoped secrets file; the agent reads it only to mint a narrowly-scoped, short-lived token per operation and exports that ephemeral token for the one call. Account state is brand-isolated and the master token never leaves the secrets file — see `references/api.md`.
+Each installation has its own Cloudflare account. Two auth paths serve two operation classes. **Tunnel** auth is OAuth: the operator signs in via `cloudflared tunnel login` (issued by the agent through Bash); `cloudflared` writes `cert.pem` to the brand-scoped config directory. **API** auth (DNS, zones, Pages, D1, Access, token management) is the master token: the operator provisions one fully-scoped master token in the dashboard (an advanced, operator-guided step the agent never automates), stored at the account-scoped secrets file; the agent reads it only to provision **one stable narrow token per scope** — minting it once if absent, persisting it to the secrets file, reusing it thereafter — and periodically reconciles strays. Account state is brand-isolated and the master token never leaves the secrets file — see `references/api.md`.
 
 ## When to activate
 
@@ -25,7 +25,7 @@ Each installation has its own Cloudflare account. Two auth paths serve two opera
 
 ## Operator-facing surface
 
-The plugin registers no agent-facing MCP tools. Every Cloudflare operation is the agent invoking `cloudflared` or `wrangler` directly via Bash, or calling the Cloudflare API with a minted narrow token, with stdout/stderr streamed verbatim into the PTY chat (secrets redacted). The OAuth URL printed by `cloudflared tunnel login` is linkified by the native PTY; the operator clicks it in their own browser. There is no shell-script wrapper, no orchestrator state machine, no MCP-tool surface.
+The plugin registers no agent-facing MCP tools. Every Cloudflare operation is the agent invoking `cloudflared` or `wrangler` directly via Bash, or calling the Cloudflare API with a reused per-scope narrow token, with stdout/stderr streamed verbatim into the PTY chat (secrets redacted). The OAuth URL printed by `cloudflared tunnel login` is linkified by the native PTY; the operator clicks it in their own browser. There is no shell-script wrapper, no orchestrator state machine, no MCP-tool surface.
 
 ### Skills
 
@@ -38,7 +38,7 @@ The plugin registers no agent-facing MCP tools. Every Cloudflare operation is th
 | Reference | Topics |
 |---|---|
 | [manual-setup.md](references/manual-setup.md) | Tunnel runbook — Steps 0–7 with isolated `cloudflared` command blocks. The agent reads the relevant step before issuing each command. |
-| [api.md](references/api.md) | Cloudflare API library — canonical docs URL + curated endpoint map (DNS, zones, tunnels, token create/verify), the advanced master-token creation walkthrough, the account-scoped secrets-file storage convention, and the agent's mint-narrow-token discipline. |
+| [api.md](references/api.md) | Cloudflare API library — canonical docs URL + curated endpoint map (DNS, zones, tunnels, token list/create/verify/revoke), the advanced master-token creation walkthrough, the account-scoped secrets-file storage convention, the agent's reuse-a-stable-per-scope-token discipline, and the standing reconcile pass that revokes strays. |
 | [d1-data-capture.md](references/d1-data-capture.md) | Form → Pages Function → D1 store → read/sweep. The Pages-Edit **and** D1-Edit token-scope requirement, `wrangler d1 create`/`execute --remote`, the `swept` column. |
 | [hosting-sites.md](references/hosting-sites.md) | Deploy a static or Next.js site to Cloudflare Pages via `wrangler pages deploy`. |
 | [web-analytics.md](references/web-analytics.md) | Why a registered site reports 0 visitors — the RUM API is blocked (no permission group), registered ≠ collecting, edge auto-injection is impossible for a Pages-only custom domain, and the beacon must be injected into the site HTML, rebuilt, and redeployed. Outcome: beacon present in live HTML. |
@@ -59,4 +59,4 @@ The setup-done claim only fires when `curl -I https://<hostname>` issued from ou
 
 ## Discipline
 
-The agent's permitted surfaces are: direct `cloudflared` and `wrangler` invocations via Bash following the references; Cloudflare API calls authenticated by a freshly-minted narrow token (the master token stays in the secrets file, never on a command line that echoes, never in chat); the reference files; and live verification (`curl -I` for tunnels, the deployed URL for hosting, a `SELECT` for D1). Out of bounds: Playwright or Chrome DevTools driving the dashboard, browser-automating master-token creation, WebSearch-for-CF-recipes, ad-hoc `cloudflared` flag invention not in the runbook, and writing or echoing any token. When a step fails, the agent reports the exact output (secrets redacted), cites the recovery step from `references/reset-guide.md`, and stops.
+The agent's permitted surfaces are: direct `cloudflared` and `wrangler` invocations via Bash following the references; Cloudflare API calls authenticated by a reused per-scope narrow token, minted once if absent and persisted to the secrets file (the master token stays in that same file, never on a command line that echoes, never in chat); the reference files; and live verification (`curl -I` for tunnels, the deployed URL for hosting, a `SELECT` for D1). Out of bounds: Playwright or Chrome DevTools driving the dashboard, browser-automating master-token creation, WebSearch-for-CF-recipes, ad-hoc `cloudflared` flag invention not in the runbook, and writing or echoing any token. When a step fails, the agent reports the exact output (secrets redacted), cites the recovery step from `references/reset-guide.md`, and stops.

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

@@ -1,19 +1,19 @@
-# Cloudflare API — master token, minted narrow tokens, endpoint map
+# Cloudflare API — master token, reused per-scope narrow tokens, endpoint map
 
-The Cloudflare REST API is a permitted surface on this install. It is how the agent does DNS edits, Pages deploys, D1 queries, Access policies, and apex-CNAME creation without driving the dashboard. This reference is the library: where the canonical docs live, how auth works (one operator-provisioned master token; the agent mints short-lived narrow tokens from it), where the master is stored, and the curated endpoints worth knowing.
+The Cloudflare REST API is a permitted surface on this install. It is how the agent does DNS edits, Pages deploys, D1 queries, Access policies, and apex-CNAME creation without driving the dashboard. This reference is the library: where the canonical docs live, how auth works (one operator-provisioned master token; the agent mints **one narrow token per scope**, persists it to the secrets file, and reuses it), where the master is stored, and the curated endpoints worth knowing — including how to list and revoke tokens, and the standing reconcile pass that keeps the account from accumulating strays.
 
 Canonical reference (always the source of truth for request shapes, never mirror it wholesale here): **https://developers.cloudflare.com/api/**
 
 ---
 
-## Auth model — one master, many minted narrow tokens
+## Auth model — one master, reused per-scope narrow tokens
 
 There are two distinct tokens in play. Keep them separate.
 
-- **Master token** — fully-scoped, long-lived, provisioned **once** by the operator in the dashboard (see § Provisioning the master token, below). Broad enough to manage Pages, D1, DNS, **and** create API tokens. The agent reads it only to mint narrow tokens. It is never passed to `wrangler`, never put on a command line that gets echoed, never printed.
-- **Minted narrow token** — scoped to exactly one operation class (a single-zone DNS edit, a one-project Pages deploy, a D1 query), short-lived, created by the agent via the API call below. Exported into the environment for the one `wrangler` / API call, then discarded. Never written to disk, never committed, never echoed into chat.
+- **Master token** — fully-scoped, long-lived, provisioned **once** by the operator in the dashboard (see § Provisioning the master token, below). Broad enough to manage Pages, D1, DNS, **and** create API tokens. The agent reads it only to mint per-scope tokens. It is never passed to `wrangler`, never put on a command line that gets echoed, never printed.
+- **Per-scope narrow token** — scoped to exactly one operation class (a single-zone DNS edit, a one-project Pages deploy, a D1 query), with a **deterministic name** (`<brand>-pages-d1`, `<brand>-dns`, `<brand>-access`). There is **one** such token per scope. The agent loads it from the secrets file; **if absent, it mints it once** from the master — correctly scoped, **no expiry — permanent and reused** — and persists it back to the secrets file. Thereafter it is loaded and reused, never re-minted. Exported into the environment for the one `wrangler` / API call; never echoed into chat, never written into a project tree.
 
-Why mint instead of hand-rolling: the operator provisions the master once; every per-operation token is minted by the agent on demand, so the operator never hand-crafts scoped tokens and no broad token is ever exported to a tool that could log it.
+Why one-per-scope instead of one-per-operation: the operator provisions the master once; the agent provisions each narrow token once and reuses it, so the account never fills with throwaway tokens, no broad token is ever exported to a tool that could log it, and decay is handled structurally by the reconcile pass (§ Reconcile) rather than by per-token TTL. The narrow token persists alongside the master in the same `600`-mode secrets file but is **strictly narrower** than the master — so the binding "never export the master to `wrangler`" is preserved while the narrow token gains reuse.
 
 ---
 
@@ -38,7 +38,7 @@ Rationale (binding):
 
 1. **Account-isolated** — under `data/accounts/<accountId>/`, consistent with brand isolation; one account's master never sits where another account's flow can read it.
 2. **Outside every deployable/git project tree** — so the god-token can never be committed or shipped in a Pages upload. This is the failure mode a project-root `.env` invites: a `.env` next to a site's source gets swept into the `wrangler pages deploy` upload or a `git add .`.
-3. **Sourced on demand for the master only** — `set -a; . <file>; set +a` to load `CLOUDFLARE_API_TOKEN` + `CLOUDFLARE_ACCOUNT_ID` into the environment for the mint call; per-operation narrow tokens go into the ephemeral environment of their single command, never into this file.
+3. **Sourced on demand** — `set -a; . <file>; set +a` to load `CLOUDFLARE_API_TOKEN` (master) + `CLOUDFLARE_ACCOUNT_ID` into the environment. The reused per-scope narrow tokens (`<brand>-pages-d1`, etc.) persist **in this same file** as additional keys (e.g. `CF_PAGES_D1_TOKEN=`), minted once if absent and loaded thereafter; each is strictly narrower than the master that already lives here, so persisting it adds no exposure the master did not already carry. A per-scope token is exported only into the single command that uses it, never echoed.
 
 Create it once (mode 600, parent dirs 700):
 
@@ -116,49 +116,55 @@ Cross-type calls fail with a stable, recognizable signal: a `cfat_…` token at
 
 ---
 
-## Minting a narrow token
+## Provisioning and reusing a stable per-scope token
 
-The agent mints a per-operation token from the master via `POST /accounts/{account_id}/tokens` (`cfat_…` master) or `POST /user/tokens` (`cfut_…` master — see § Token type — route endpoints by prefix). Scope it to the single operation, give it a short TTL, export it for the one call, discard it.
+Per operation class there is **one** deterministically-named narrow token, reused across runs. On each run the agent **loads it from the secrets file; if it is absent, it mints it once** (correctly scoped, **no expiry**) and persists it back to the secrets file. There is no per-operation throwaway and no `unset` — the token is permanent and reused. Mint via `POST /accounts/{account_id}/tokens` (`cfat_…` master) or `POST /user/tokens` (`cfut_…` master — see § Token type — route endpoints by prefix).
 
 ```bash
-set -a; . "${SECRETS_DIR}/cloudflare.env"; set +a   # loads the master + account id
-
-# Example: a one-project Pages-deploy token. Adjust the policy for the operation.
-MINTED=$(curl -sS -X POST \
-  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
-  -H "Content-Type: application/json" \
-  "https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/tokens" \
-  --data @- <<'JSON' | jq -r '.result.value'
+set -a; . "${SECRETS_DIR}/cloudflare.env"; set +a   # loads the master + account id (+ any persisted per-scope tokens)
+: "${CLOUDFLARE_API_TOKEN:?credentials not loaded}"; : "${CLOUDFLARE_ACCOUNT_ID:?account id not loaded}"
+
+# Example: the stable Pages-deploy token. One deterministic name + secrets key per scope.
+TOKEN_KEY="CF_PAGES_D1_TOKEN"      # the persisted key in cloudflare.env
+SCOPE_NAME="<brand>-pages-d1"      # the deterministic, reused token name on the account
+PAGES_D1=$(grep -m1 "^${TOKEN_KEY}=" "${SECRETS_DIR}/cloudflare.env" 2>/dev/null | cut -d= -f2-)
+
+if [ -z "${PAGES_D1}" ]; then       # absent → mint once, scoped, no expiry, then persist
+  PAGES_D1=$(curl -sS -X POST \
+    -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
+    -H "Content-Type: application/json" \
+    "https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/tokens" \
+    --data @- <<JSON | jq -r '.result.value'
 {
-  "name": "ephemeral-pages-deploy",
+  "name": "${SCOPE_NAME}",
   "policies": [{
     "effect": "allow",
-    "resources": { "com.cloudflare.api.account.<accountId>": "*" },
+    "resources": { "com.cloudflare.api.account.${CLOUDFLARE_ACCOUNT_ID}": "*" },
     "permission_groups": [{ "id": "<pages-edit-permission-group-id>", "name": "Pages Write" }]
-  }],
-  "expires_on": "<iso8601-a-few-minutes-out>"
+  }]
 }
 JSON
-)
+  )
+  ( umask 077; printf '%s=%s\n' "${TOKEN_KEY}" "${PAGES_D1}" >> "${SECRETS_DIR}/cloudflare.env" )
+fi
 
-# Use it for exactly one command, in this command's environment only:
-CLOUDFLARE_API_TOKEN="${MINTED}" wrangler pages deploy ./dist --project-name <project> --branch=main
-
-unset MINTED   # discard; never written to disk, never echoed
+# Reused thereafter — exported only into the one command's environment, never echoed:
+CLOUDFLARE_API_TOKEN="${PAGES_D1}" wrangler pages deploy ./dist --project-name <project> --branch=main
 ```
 
-Look up `<pages-edit-permission-group-id>` (and the ids for DNS Edit, D1 Edit, etc.) once via `GET /accounts/{account_id}/tokens/permission_groups`; they are stable per account.
+No `expires_on`: the per-scope token is permanent and reused, so decay is the job of the **reconcile pass** (§ Reconcile), not a per-token TTL — the old short-TTL guidance was never honored in practice and produced only never-expiring strays. Look up `<pages-edit-permission-group-id>` (and the ids for DNS Edit, D1 Edit, etc.) once via `GET /accounts/{account_id}/tokens/permission_groups`; they are stable per account. Before reusing or before reconciling, `GET …/tokens` (§ Curated endpoint map) shows what already exists, so a scope is never minted twice under different names.
 
 **Redaction is binding.** Every example above pipes the token into a variable or an `Authorization` header and never to stdout. The agent surfaces the operation as verb + target — "minting a Pages-deploy token", "creating CNAME `chat.example.com`" — never the secret. A failure surfaces the API error body with any `Authorization` value masked.
 
 ### A freshly-minted token is not instantly usable — verify with backoff
 
-A just-minted token returns `10000 Authentication error` for a few seconds before it becomes active. Do not fire a fresh token's first real call blind; **verify it first**, retrying on a transient `10000` with backoff and giving up after ~30s. Route `${VERIFY_URL}` by the master's prefix (account- vs user-scoped — see § Token type):
+This applies only on the **mint-once path** (the absent branch above) — a reused token loaded from secrets is already active and needs no wait. A just-minted token returns `10000 Authentication error` for a few seconds before it becomes active. Do not fire a fresh token's first real call blind; **verify it first**, retrying on a transient `10000` with backoff and giving up after ~30s. Route `${VERIFY_URL}` by the master's prefix (account- vs user-scoped — see § Token type):
 
 ```bash
-# ${MINTED} = the token just minted; ${VERIFY_URL} = the prefix-correct verify endpoint.
+# Run this inside the mint-once (absent) branch, before persisting/using the token.
+# ${PAGES_D1} = the per-scope token just minted; ${VERIFY_URL} = the prefix-correct verify endpoint.
 for i in $(seq 1 10); do
-  s=$(curl -sS -H "Authorization: Bearer ${MINTED}" "${VERIFY_URL}" \
+  s=$(curl -sS -H "Authorization: Bearer ${PAGES_D1}" "${VERIFY_URL}" \
         | jq -r '.result.status // (.errors[0].code | tostring)')
   [ "$s" = "active" ] && break
   [ "$s" = "10000" ] && { sleep 3; continue; }   # transient post-mint window — expected
@@ -172,12 +178,14 @@ Proceed to the operation only once verify returns `active`. The `10000` window i
 
 ## Curated endpoint map
 
-Request/response shapes live at the canonical docs URL; this is the index of what to reach for. `${ACC}` = `CLOUDFLARE_ACCOUNT_ID`, `${ZONE}` = the zone id, `${TOKEN}` = a **minted narrow** token.
+Request/response shapes live at the canonical docs URL; this is the index of what to reach for. `${ACC}` = `CLOUDFLARE_ACCOUNT_ID`, `${ZONE}` = the zone id, `${TOKEN}` = a **reused per-scope narrow** token.
 
-### Token create / verify
+### Token list / create / verify / revoke
 The endpoints below are the **account-scoped** (`cfat_…`) family — the common case. For a **user-scoped** (`cfut_…`) master, swap to the `/user/tokens/…` family per § Token type — route endpoints by prefix; the account endpoints return `9109` for that token type.
-- `GET  /accounts/${ACC}/tokens/verify` — confirm an **account-scoped** (`cfat_…`) token is active. This is the endpoint for the master and every minted narrow token here, all of which are account-scoped. **`/user/tokens/verify` is user-scoped only** and returns `Invalid API Token` for a `cfat_…` token even when it is valid — do not use it to verify an account token.
-- `POST /accounts/${ACC}/tokens` — mint a narrow token (see above).
+- `GET  /accounts/${ACC}/tokens/verify` — confirm an **account-scoped** (`cfat_…`) token is active. This is the endpoint for the master and every per-scope narrow token here, all of which are account-scoped. **`/user/tokens/verify` is user-scoped only** and returns `Invalid API Token` for a `cfat_…` token even when it is valid — do not use it to verify an account token.
+- `GET  /accounts/${ACC}/tokens` — list all tokens on the account (id, name, status, `expires_on`). Use it to find a per-scope token to reuse and to enumerate strays before a reconcile. User-scoped twin: `GET  /user/tokens`.
+- `POST /accounts/${ACC}/tokens` — mint a per-scope token (see § Provisioning and reusing a stable per-scope token). Mint only when the list above shows the scope absent.
+- `DELETE /accounts/${ACC}/tokens/{id}` — revoke a token by id (the reconcile/cleanup verb). User-scoped twin: `DELETE /user/tokens/{id}`. Route by the master's prefix exactly as verify/mint do — `cfat_…` → `/accounts/${ACC}/tokens…`, `cfut_…` → `/user/tokens…`; the cross-type call returns `9109`.
 - `GET  /accounts/${ACC}/tokens/permission_groups` — resolve permission-group ids for scoping.
 
 ### DNS records (zone-scoped; needs **Zone · DNS · Edit**)
@@ -205,10 +213,41 @@ curl -sS -X POST -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: applicati
 
 ---
 
+## Reconcile — the standing cleanup check
+
+Token accumulation **emits no event and does not reproduce on demand**, so the decay mechanism is a standing reconcile pass, run **periodically and before a deploy** — not a one-off. It lists every token, keeps the known-good set, and revokes the rest. The known-good set is: the **master**, the stable per-scope operation tokens (`<brand>-pages-d1`, `<brand>-dns`, `<brand>-access`), and the **tunnel** tokens. Everything else — throwaway, duplicate-named, stray — is revoked.
+
+```bash
+set -a; . "${SECRETS_DIR}/cloudflare.env"; set +a
+: "${CLOUDFLARE_API_TOKEN:?credentials not loaded}"; : "${CLOUDFLARE_ACCOUNT_ID:?account id not loaded}"
+LIST_URL="https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/tokens"  # /user/tokens for a cfut_ master
+
+# Names kept verbatim — adjust to this account's stable set + tunnel token names.
+KEEP="<brand>-pages-d1 <brand>-dns <brand>-access maxy-api-master maxy-pages Maxy"
+
+# 1. List; for each token whose name is NOT in KEEP, revoke it by id.
+curl -sS -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" "${LIST_URL}?per_page=100" \
+  | jq -r '.result[] | [.id, .name] | @tsv' \
+  | while IFS=$'\t' read -r id name; do
+      case " ${KEEP} " in *" ${name} "*) echo "keep  ${name}";;
+        *) curl -sS -X DELETE -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" "${LIST_URL}/${id}" >/dev/null
+           echo "revoke ${name}";; esac
+    done
+
+# 2. Post-condition — re-list and confirm the revoked names are gone. Do not trust the DELETE exit code.
+curl -sS -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" "${LIST_URL}?per_page=100" | jq -r '.result[].name'
+```
+
+`?per_page=100` returns the first page only; an account that has accumulated **more than 100 tokens** — the exact failure this pass exists to undo — needs `&page=2`, `&page=3`, … until a short page returns. Reconcile is the accumulation-survival mechanism, so it must walk every page, not just the first.
+
+The tally is **names only** — a token value is never printed (the redaction binding in § Provisioning applies). "Revoked N" is a claim only once the follow-up list (step 2) shows those names absent, never an inference from the DELETE call's exit code.
+
+---
+
 ## When to use which path
 
 - **Tunnel create/route/run** → `cloudflared` (OAuth cert), per `manual-setup.md`. The API can manage tunnels too, but the cert path is the established one.
 - **Apex CNAME** → API (above) or dashboard (`dashboard-guide.md`). Either flattens correctly.
-- **Pages deploy** → `wrangler` with a minted Pages-Edit token, per `hosting-sites.md`.
-- **D1 read/write** → `wrangler d1 execute --remote` with a minted D1-Edit token, per `d1-data-capture.md`.
-- **Inspecting account state** (which zones, which tunnels) → API `GET` with a read-scoped minted token, or the dashboard.
+- **Pages deploy** → `wrangler` with the reused `<brand>-pages-d1` token, per `hosting-sites.md`.
+- **D1 read/write** → `wrangler d1 execute --remote` with the reused D1-Edit token, per `d1-data-capture.md`.
+- **Inspecting account state** (which zones, which tunnels) → API `GET` with a read-scoped token (reused), or the dashboard.

package/payload/platform/plugins/cloudflare/references/d1-data-capture.md

@@ -2,7 +2,7 @@
 
 This is the established pattern for turning a static site's contact / waitlist form into durable, queryable leads: the form POSTs to a **Pages Function**, the Function inserts a row into a **Cloudflare D1** database, and the agent reads and sweeps new rows with `wrangler d1 execute --remote`. It is live on `realagent.pages.dev` today — the worked example below is that deployment, generalized with placeholders.
 
-Pair this with `hosting-sites.md` (how the site itself gets deployed) and `api.md` (the master token + mint-narrow discipline that authenticates every `wrangler` call).
+Pair this with `hosting-sites.md` (how the site itself gets deployed) and `api.md` (the master token + reused per-scope token discipline that authenticates every `wrangler` call).
 
 ---
 
@@ -13,47 +13,53 @@ A Pages-only token **cannot touch D1**. The deploy succeeds, the form renders, a
 - **Account · Cloudflare Pages · Edit**
 - **Account · D1 · Edit**
 
-Mint a narrow token that includes both permission groups (see `api.md` § Minting a narrow token) before any `wrangler d1` or D1-backed deploy command. This was observed live in the session that built `realagent.pages.dev`; it is the first thing to check when captures stop arriving.
+Use the stable `<brand>-pages-d1` token that includes both permission groups (see `api.md` § Provisioning and reusing a stable per-scope token, and § 0 below) before any `wrangler d1` or D1-backed deploy command. This was observed live in the session that built `realagent.pages.dev`; it is the first thing to check when captures stop arriving.
 
 **Even a read-only `SELECT` needs D1 *Edit*.** The `wrangler d1 execute --remote` query path goes through the D1 **query** endpoint, which **rejects a D1-Read token** — a token scoped to D1 *Read* fails the `SELECT`, not just the `INSERT`/`UPDATE`. Use the **D1-Edit**-scoped token (or the both-Pages-Edit-and-D1-Edit token above) for every `wrangler d1 execute`, reads included. A separately-minted "D1 Read" token for the sweep `SELECT`s is wrong guidance: it is rejected at the query endpoint.
 
 ---
 
-## 0. Mint the Pages-+-D1 token
+## 0. Load (or mint once) the stable Pages-+-D1 token
 
-Every command below uses `${MINTED_PAGES_D1}` — a narrow token scoped to **both** Pages Edit and D1 Edit, minted from the master per `api.md` § Minting a narrow token. Mint it once at the start of the session and export it; it is never written to disk or echoed:
+Every command below uses `${PAGES_D1}` — the **stable, reused** per-scope token (`<brand>-pages-d1`) scoped to **both** Pages Edit and D1 Edit. Provision it the way `api.md` § Provisioning and reusing a stable per-scope token prescribes: **load it from the secrets file; mint it once only if absent** (no expiry), persist it, and reuse it thereafter. It is never written into a project tree or echoed:
 
 ```bash
-set -a; . "${SECRETS_DIR}/cloudflare.env"; set +a   # loads master + account id
-MINTED_PAGES_D1=$(curl -sS -X POST \
-  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
-  -H "Content-Type: application/json" \
-  "https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/tokens" \
-  --data @- <<'JSON' | jq -r '.result.value'
+set -a; . "${SECRETS_DIR}/cloudflare.env"; set +a   # loads master + account id + persisted per-scope tokens
+: "${CLOUDFLARE_API_TOKEN:?credentials not loaded}"; : "${CLOUDFLARE_ACCOUNT_ID:?account id not loaded}"
+
+TOKEN_KEY="CF_PAGES_D1_TOKEN"; SCOPE_NAME="<brand>-pages-d1"
+PAGES_D1=$(grep -m1 "^${TOKEN_KEY}=" "${SECRETS_DIR}/cloudflare.env" 2>/dev/null | cut -d= -f2-)
+if [ -z "${PAGES_D1}" ]; then        # absent → mint once, scoped to BOTH Pages Edit + D1 Edit, no expiry
+  PAGES_D1=$(curl -sS -X POST \
+    -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
+    -H "Content-Type: application/json" \
+    "https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/tokens" \
+    --data @- <<JSON | jq -r '.result.value'
 {
-  "name": "ephemeral-pages-d1",
+  "name": "${SCOPE_NAME}",
   "policies": [{
     "effect": "allow",
-    "resources": { "com.cloudflare.api.account.<accountId>": "*" },
+    "resources": { "com.cloudflare.api.account.${CLOUDFLARE_ACCOUNT_ID}": "*" },
     "permission_groups": [
       { "id": "<pages-edit-permission-group-id>", "name": "Pages Write" },
       { "id": "<d1-edit-permission-group-id>", "name": "D1 Write" }
     ]
-  }],
-  "expires_on": "<iso8601-a-few-minutes-out>"
+  }]
 }
 JSON
-)
+  )
+  ( umask 077; printf '%s=%s\n' "${TOKEN_KEY}" "${PAGES_D1}" >> "${SECRETS_DIR}/cloudflare.env" )
+fi
 ```
 
-Resolve the two permission-group ids once via `GET /accounts/{account_id}/tokens/permission_groups` (see `api.md`). When the work is done, `unset MINTED_PAGES_D1`.
+Resolve the two permission-group ids once via `GET /accounts/{account_id}/tokens/permission_groups` (see `api.md`). There is **no `unset`** — `${PAGES_D1}` is the reused per-scope token, not a throwaway; the reconcile pass in `api.md` § Reconcile keeps the account from accumulating strays.
 
 ---
 
 ## 1. Create the database
 
 ```bash
-CLOUDFLARE_API_TOKEN="${MINTED_PAGES_D1}" wrangler d1 create <db-name>
+CLOUDFLARE_API_TOKEN="${PAGES_D1}" wrangler d1 create <db-name>
 # worked example: wrangler d1 create realagent-leads
 ```
 
@@ -78,7 +84,7 @@ database_id = "<database_id>"      # from step 1
 Apply the schema to the remote database (`--remote` targets the live D1, not a local replica):
 
 ```bash
-CLOUDFLARE_API_TOKEN="${MINTED_PAGES_D1}" wrangler d1 execute <db-name> --remote --command \
+CLOUDFLARE_API_TOKEN="${PAGES_D1}" wrangler d1 execute <db-name> --remote --command \
   "CREATE TABLE IF NOT EXISTS leads (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT,
@@ -132,14 +138,14 @@ Deploy via `hosting-sites.md`. The binding in `wrangler.toml` is what wires the
 Read everything not yet ingested:
 
 ```bash
-CLOUDFLARE_API_TOKEN="${MINTED_PAGES_D1}" wrangler d1 execute <db-name> --remote --json --command \
+CLOUDFLARE_API_TOKEN="${PAGES_D1}" wrangler d1 execute <db-name> --remote --json --command \
   "SELECT id, name, email, message, created_at FROM leads WHERE swept = 0 ORDER BY id;"
 ```
 
 After ingesting those rows (e.g. writing them into the graph), mark them swept so the next read returns only newer ones:
 
 ```bash
-CLOUDFLARE_API_TOKEN="${MINTED_PAGES_D1}" wrangler d1 execute <db-name> --remote --command \
+CLOUDFLARE_API_TOKEN="${PAGES_D1}" wrangler d1 execute <db-name> --remote --command \
   "UPDATE leads SET swept = 1 WHERE swept = 0;"
 ```
 
@@ -152,7 +158,7 @@ D1 capture is done when a **test POST to the live form** appears in the unswept
 ```bash
 curl -sS -X POST -d "email=test@example.com&name=verify" "https://<project>.pages.dev/api/contact" -i | head -1
 # then:
-CLOUDFLARE_API_TOKEN="${MINTED_PAGES_D1}" wrangler d1 execute <db-name> --remote --command \
+CLOUDFLARE_API_TOKEN="${PAGES_D1}" wrangler d1 execute <db-name> --remote --command \
   "SELECT email FROM leads WHERE swept = 0;"
 ```
 

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

@@ -109,8 +109,9 @@ Use this when you need to audit which hostnames are pointing at which `<UUID>.cf
 
 When the agent adds an SSH or SMB ingress hostname (per `references/manual-setup.md`),
 the Access policy must exist before off-LAN clients can reach the Pi. There are two
-paths: the agent can author it via the Cloudflare API with a minted Access-scoped
-token (see `references/api.md` § Access), or the operator can author it by hand in the
+paths: the agent can author it via the Cloudflare API with the reused Access-scoped
+token (`<brand>-access`, minted once if absent — see `references/api.md` § Access and
+§ Provisioning and reusing a stable per-scope token), or the operator can author it by hand in the
 dashboard with the click-path below. `cloudflared` CLI has no Access-application create
 subcommand, so the dashboard path is the manual alternative to the API.
 

package/payload/platform/plugins/cloudflare/references/hosting-sites.md

@@ -1,6 +1,6 @@
 # Deploying a site to Cloudflare Pages
 
-How to put a static or Next.js site on Cloudflare Pages via `wrangler`, the way `realagent.pages.dev` is deployed. This covers the build → deploy → verify loop and the Next.js specifics. Auth is a minted narrow token per `api.md`; if the site also captures form data, read `d1-data-capture.md` for the dual Pages-Edit **and** D1-Edit scope.
+How to put a static or Next.js site on Cloudflare Pages via `wrangler`, the way `realagent.pages.dev` is deployed. This covers the build → deploy → verify loop and the Next.js specifics. Auth is the reused per-scope token per `api.md`; if the site also captures form data, read `d1-data-capture.md` for the dual Pages-Edit **and** D1-Edit scope.
 
 This is distinct from `references/serving-published-sites.md`, which serves a platform-published site at a custom domain through the brand's **cloudflared tunnel**. This reference is about **Cloudflare Pages** — Cloudflare hosts the build, not the install device.
 
@@ -31,19 +31,21 @@ compatibility_flags = ["nodejs_compat"]  # required for next-on-pages and most F
 
 If the site captures form data, add the `[[d1_databases]]` binding from `d1-data-capture.md` here.
 
-## 3. Mint a deploy token
+## 3. Load the reused deploy token
 
-A Pages deploy needs **Account · Cloudflare Pages · Edit**. If the site has Pages Functions hitting D1, the token also needs **Account · D1 · Edit** (the single most common breakage — see `d1-data-capture.md`). Mint it per `api.md` § Minting a narrow token:
+A Pages deploy needs **Account · Cloudflare Pages · Edit**. If the site has Pages Functions hitting D1, the token also needs **Account · D1 · Edit** (the single most common breakage — see `d1-data-capture.md`). Load the stable per-scope token — minting it once only if absent — per `api.md` § Provisioning and reusing a stable per-scope token:
 
 ```bash
 set -a; . "${SECRETS_DIR}/cloudflare.env"; set +a
-# MINTED = a narrow token scoped to Pages Edit (+ D1 Edit if the site uses D1)
+: "${CLOUDFLARE_API_TOKEN:?credentials not loaded}"; : "${CLOUDFLARE_ACCOUNT_ID:?account id not loaded}"
+# PAGES_D1 = the reused per-scope token (Pages Edit, + D1 Edit if the site uses D1),
+# loaded from cloudflare.env and minted once if absent — see api.md § Provisioning and reusing.
 ```
 
 ## 4. Deploy
 
 ```bash
-CLOUDFLARE_API_TOKEN="${MINTED}" wrangler pages deploy <output-dir> \
+CLOUDFLARE_API_TOKEN="${PAGES_D1}" wrangler pages deploy <output-dir> \
   --project-name <project> --branch=main
 ```
 

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

@@ -295,8 +295,9 @@ rather than failing.
 
 **Access policy — API or dashboard.** `cloudflared` CLI has no
 Access-application create subcommand, so author the policy either via
-the Cloudflare API with a minted Access-scoped token (see
-`references/api.md` § Access) or by hand in the dashboard. After the
+the Cloudflare API with the reused Access-scoped token (`<brand>-access`,
+minted once if absent — see `references/api.md` § Access) or by hand in
+the dashboard. After the
 ingress is in place, the dashboard path is:
 
 ```

package/payload/platform/plugins/cloudflare/skills/cloudflare/SKILL.md

@@ -14,7 +14,7 @@ This is the entry point for every Cloudflare task on the install. Pick the opera
 | Stand up / diagnose / reset a tunnel so a hostname is reachable | `references/manual-setup.md` | external `curl -I https://<hostname>` → `200` |
 | Switch accounts, edit an apex CNAME by hand, or other dashboard-only clicks | `references/dashboard-guide.md` | the click-path completed in the operator's browser |
 | Tear down corrupt tunnel state and start clean | `references/reset-guide.md` | a fresh `manual-setup.md` run reaches `200` |
-| Call the Cloudflare API (DNS, zones, tunnels, Access, token mint) | `references/api.md` | the API call returns success and the change is observable |
+| Call the Cloudflare API (DNS, zones, tunnels, Access, token list/reuse/revoke) | `references/api.md` | the API call returns success and the change is observable |
 | Deploy a static / Next.js site to Cloudflare Pages | `references/hosting-sites.md` | the deployed URL serves the new build |
 | Capture form/waitlist submissions into a database | `references/d1-data-capture.md` | a test POST appears in `SELECT … WHERE swept = 0` |
 | Diagnose / enable Web Analytics on a site (0 visitors, no data) | `references/web-analytics.md` | beacon present in live HTML (`curl -s https://<host>/ \| grep cloudflareinsights`) |
@@ -22,9 +22,9 @@ This is the entry point for every Cloudflare task on the install. Pick the opera
 ## Two auth paths, by operation class
 
 - **Tunnel auth is OAuth.** `cloudflared tunnel login` writes `cert.pem`; the operator clicks the linkified OAuth URL in their own browser. This is the only path for tunnel create/route/run. See `references/manual-setup.md`.
-- **API auth is the master token.** The operator provisions one fully-scoped master token once (an **advanced**, operator-guided dashboard step — the agent does not automate it) and stores it at the account-scoped secrets file. The agent reads the master only to **mint a narrowly-scoped, short-lived token** for each operation — a single-zone DNS edit, a one-project Pages deploy, a D1 query — and exports that ephemeral token for the one call. See `references/api.md` for the storage convention, the mint flow, and the binding redaction discipline.
+- **API auth is the master token.** The operator provisions one fully-scoped master token once (an **advanced**, operator-guided dashboard step — the agent does not automate it) and stores it at the account-scoped secrets file. The agent reads the master only to **provision one stable narrow token per scope** — `<brand>-pages-d1`, `<brand>-dns`, `<brand>-access` — loading it from the secrets file, minting it once if absent (no expiry), persisting it, and reusing it for every later operation in that scope. A standing **reconcile** pass revokes strays. See `references/api.md` for the storage convention, the provisioning-and-reuse flow, the reconcile pass, and the binding redaction discipline.
 
-Neither the master token nor any minted token is ever written into a project tree, committed, or echoed into chat.
+Neither the master token nor any per-scope token is ever written into a project tree, committed, or echoed into chat — the per-scope tokens persist only in the account-scoped secrets file, never in a deployable project tree.
 
 ## Outcome contracts — what "done" means
 
@@ -55,7 +55,7 @@ After the service is up, the agent runs `curl -I https://<admin-hostname>` and p
 
 ## Apex hostnames
 
-The `cloudflared` CLI cannot route apex records (e.g. `maxy.chat`) — standard DNS forbids a CNAME at the zone apex. There are now two ways to create the apex record: the operator edits the apex CNAME in the dashboard (`references/dashboard-guide.md` § "Edit an apex CNAME"), or the agent creates it via the Cloudflare API with a minted DNS-scoped token (`references/api.md` § DNS records). Either reaches the same flattened-CNAME result; pick the dashboard path when the operator prefers to click, the API path when an end-to-end agent run is wanted.
+The `cloudflared` CLI cannot route apex records (e.g. `maxy.chat`) — standard DNS forbids a CNAME at the zone apex. There are now two ways to create the apex record: the operator edits the apex CNAME in the dashboard (`references/dashboard-guide.md` § "Edit an apex CNAME"), or the agent creates it via the Cloudflare API with the reused DNS-scoped token (`<brand>-dns`, minted once if absent — `references/api.md` § DNS records). Either reaches the same flattened-CNAME result; pick the dashboard path when the operator prefers to click, the API path when an end-to-end agent run is wanted.
 
 ## Reset
 
@@ -66,10 +66,10 @@ When local Cloudflare state is corrupt or the operator wants to start from a kno
 When the operator's request touches Cloudflare, the agent's permitted actions are:
 
 - Invoke `cloudflared` via Bash, following `references/manual-setup.md`.
-- Invoke `wrangler` and the Cloudflare API via Bash, following `references/api.md`, `references/hosting-sites.md`, and `references/d1-data-capture.md`, using a freshly-minted narrow token per operation.
+- Invoke `wrangler` and the Cloudflare API via Bash, following `references/api.md`, `references/hosting-sites.md`, and `references/d1-data-capture.md`, using the reused per-scope narrow token (minted once if absent, then reused).
 - Write `config.yml` and `alias-domains.json` per the runbook.
 - Install and start the brand's cloudflared user service.
 - Quote `references/manual-setup.md`, `references/reset-guide.md`, or `references/dashboard-guide.md` verbatim when a dashboard click-path is the right tool.
 - Verify reachability via `curl -I https://<hostname>` and surface the response.
 
-The agent does not drive the dashboard via Playwright or Chrome DevTools, and does not browser-automate master-token creation. It does not synthesise `cloudflared` flag combinations from web search or training — every command comes from the runbook. It never writes a token to disk in a project tree, commits one, or prints one into chat. When a step fails, the agent reports the exact output, names the recovery step from `references/reset-guide.md`, and stops. Improvisation — "let me try a different flag" or "let me drive the dashboard myself" — is the behaviour this rule exists to prevent.
+The agent does not drive the dashboard via Playwright or Chrome DevTools, and does not browser-automate master-token creation. It does not synthesise `cloudflared` flag combinations from web search or training — every command comes from the runbook. **Cloudflare API calls are made with `curl` + `jq` only — never a Python or node script.** It never writes a token to disk in a project tree, commits one, or prints one into chat. When a step fails, the agent reports the exact output, names the recovery step from `references/reset-guide.md`, and stops. Improvisation — "let me try a different flag", "let me drive the dashboard myself", or "let me write a quick Python script for this API call" — is the behaviour this rule exists to prevent.

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

@@ -19,13 +19,13 @@ The Telegram plugin connects {{productName}} to a Telegram bot. Once set up, you
 
 ### Step 2: Connect the plugin
 
-Tell {{productName}}: "Set up Telegram" or "Configure the Telegram bot."
+Tell {{productName}}: "Set up Telegram" or "Configure the Telegram bot." Setup runs entirely in the admin chat — there is no settings page.
 
-{{productName}} will ask for your bot token, then save it and activate the plugin. The bot is now connected.
+{{productName}} asks for your bot token, then asks whether this is an **admin bot** (only your numeric Telegram IDs may message it) or a **public bot** (customer-facing, with a DM policy). It verifies the token, registers the bot's webhook on your brand's edge, stores the token under your brand's config (never in a shared system directory), and — for a public bot — sets the agent that will answer. 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.
+In Telegram, open your bot and send `/start`, then a message. {{productName}} receives it and replies in the same chat. Admin-bot messages from your registered IDs reach the admin agent; public-bot messages reach the public agent you selected.
 
 ## Sending Messages via {{productName}}
 

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

@@ -44,10 +44,15 @@ Walks users through connecting Telegram bots. Covers bot creation, token configu
 - Multi-bot support — separate admin and public bots with different access policies
 - Admin routing — restrict a bot to admin-only access via numeric user ID bindings
 
+## Setup
+
+Connecting a Telegram bot runs through the `telegram:configure` skill (`skills/configure/SKILL.md`) — the brand-aware, PTY-only setup flow. It is the maxy `telegram:configure`; on `-code` brands the upstream `claude-plugins-official/telegram` plugin is not installed, so there is no shadowing (Task 727). The skill stores the BotFather token under the brand install, registers the webhook on the `/api/telegram/` edge path, sets access policy, and selects the responding agent.
+
 ## References
 
 | Task | When to use | Reference |
 |------|-------------|-----------|
-| Guided setup | User wants help connecting Telegram | `references/setup-guide.md` |
+| Guided setup | User wants help connecting Telegram | `skills/configure/SKILL.md` |
+| BotFather / user-ID / admin-vs-public detail | Operator needs the underlying detail | `references/setup-guide.md` |
 
-Load the reference and follow its instructions.
+Load the skill and follow its instructions.