@rubytech/create-maxy-code 0.1.461 → 0.1.463

package/payload/platform/lib/storage-broker/src/cf-exec.ts

@@ -52,6 +52,8 @@ export interface CfExec {
   r2ObjectGet(bucket: string, key: string): Promise<Uint8Array>;
   r2ObjectPut(bucket: string, key: string, body: Uint8Array): Promise<void>;
   r2ObjectDelete(bucket: string, key: string): Promise<void>;
+  pagesProjectList(): Promise<{ name: string }[]>;
+  pagesDeploy(dir: string, project: string, branch?: string): Promise<{ url: string }>;
 }
 
 // An object key carries `/` as a real path separator (the data portal's
@@ -301,6 +303,72 @@ export function makeCfExec(
       await run("npx", ["wrangler", "r2", "bucket", "create", name], env);
     },
 
+    // --- Pages (Task 1728) -------------------------------------------------
+    //
+    // Publishing is house-run: a client account's secrets carry no master after
+    // the 1631 remediation, and cf-token.sh refuses to mint the pages scope for
+    // a non-house caller. These two run under the house credential only.
+    async pagesProjectList() {
+      // `wrangler pages project list` has no --json flag and emits human prose,
+      // so it can neither be parsed nor honour the "never grep a CLI's prose"
+      // doctrine — the same reason r2List uses the API. Paginate to exhaustion:
+      // a single request returns one page, and the audit would read the missing
+      // remainder as "absent", reporting live projects as orphans. per_page is
+      // deliberately never sent (default and maximum unconfirmed).
+      const base = `https://api.cloudflare.com/client/v4/accounts/${cred.accountId}/pages/projects`;
+      const projects: { name: string }[] = [];
+      const seen = new Set<string>();
+      let cursor: string | undefined;
+      for (;;) {
+        const url = cursor === undefined ? base : `${base}?cursor=${encodeURIComponent(cursor)}`;
+        const { parsed } = await cfApiJson(
+          fetchFn,
+          url,
+          { method: "GET", headers: { Authorization: `Bearer ${cred.apiToken}` } },
+          "pages project list",
+        );
+        const page = parsed as {
+          result?: { name: string }[];
+          result_info?: { cursor?: string | null };
+        };
+        for (const p of page.result ?? []) projects.push({ name: p.name });
+        const next = page.result_info?.cursor;
+        if (!next) return projects;
+        // A repeated cursor means the API is cycling rather than advancing;
+        // surface it instead of looping forever (mirrors r2List).
+        if (seen.has(next)) {
+          throw new Error(
+            `storage-broker: pages project list returned a repeated pagination cursor: ${next}`,
+          );
+        }
+        seen.add(next);
+        cursor = next;
+      }
+    },
+    async pagesDeploy(dir, project, branch) {
+      // wrangler is the only supported Pages upload path (it hashes the tree and
+      // uploads only what is missing); the API has no single-call equivalent.
+      const args = ["wrangler", "pages", "deploy", dir, "--project-name", project];
+      if (branch !== undefined) args.push("--branch", branch);
+      const { stdout } = await run("npx", args, env);
+      // The deployment URL is what the caller relays, so parse it strictly.
+      // Strip ANSI first: wrangler colours its output when it thinks it has a
+      // terminal, and a colour reset adjacent to the URL would otherwise be
+      // swallowed by the host character class and returned as part of it.
+      const plain = stdout.replace(/\[[0-9;]*m/g, "");
+      // Take the LAST match, not the first: wrangler prints the deployment URL
+      // on its closing line, and any earlier .pages.dev mention (an alias or a
+      // progress line) would otherwise win and hand back the wrong address.
+      const urls = plain.match(/https:\/\/[A-Za-z0-9._-]+\.pages\.dev/g);
+      const url = urls?.[urls.length - 1];
+      // wrangler exits 0 on some partial paths, so a url-less success is an
+      // anomaly to surface with its output, never a silent "deployed".
+      if (!url) {
+        throw new Error(`storage-broker: pages deploy returned no deployment url: ${stdout}`);
+      }
+      return { url };
+    },
+
     // --- R2 objects (Task 1691) -------------------------------------------
     //
     // The v4 REST API exposes the object surface under
@@ -418,3 +486,26 @@ export async function makeHouseCfExec(
   const scoped = await resolveHouseScopedToken("storage", houseEnvPath, cfTokenSh, run);
   return makeCfExec({ apiToken: scoped, accountId: cred.accountId }, run, fetchFn);
 }
+
+/**
+ * The Pages twin of makeHouseCfExec (Task 1728). Same house minter, different
+ * scope: "pages" resolves CF_PAGES_D1_TOKEN rather than CF_STORAGE_TOKEN.
+ *
+ * The minter is handed the HOUSE env, which carries a master, so cf-token.sh's
+ * house-fallback branch never runs and caller_is_house() is never consulted.
+ * That is exactly why this works from the ui-server process regardless of its
+ * ACCOUNT_ID, while a client session shelling cf-token.sh directly is denied
+ * reason=not-house. Separate from makeHouseCfExec so hosting never widens the
+ * storage token's scope, and storage never gains Pages Write.
+ */
+export async function makeHousePagesExec(
+  platformRoot: string,
+  run: RunFn = defaultRun,
+  fetchFn: FetchFn = defaultFetch,
+): Promise<CfExec> {
+  const cred = readHouseCredential(platformRoot);
+  const houseEnvPath = join(platformRoot, "config", "cloudflare-house.env");
+  const cfTokenSh = join(platformRoot, "plugins/cloudflare/bin/cf-token.sh");
+  const scoped = await resolveHouseScopedToken("pages", houseEnvPath, cfTokenSh, run);
+  return makeCfExec({ apiToken: scoped, accountId: cred.accountId }, run, fetchFn);
+}

package/payload/platform/lib/storage-broker/src/house-scoped-token.ts

@@ -66,6 +66,9 @@ function keyForScope(scope: string): string {
       return "CF_STORAGE_TOKEN";
     case "calendar-d1":
       return "CF_CALENDAR_D1_TOKEN";
+    case "pages":
+      // cf-token.sh's scope table maps pages and d1 to the same minted token.
+      return "CF_PAGES_D1_TOKEN";
     default:
       return "";
   }

package/payload/platform/lib/storage-broker/src/registry.ts

@@ -22,7 +22,11 @@ export interface SessionLike {
   ): PromiseLike<{ records: Array<{ get(key: string): any }> }>;
 }
 
-export type ResourceKind = "d1" | "r2";
+// "pages" (Task 1728) is an ownership record, not a storage resource: it binds a
+// Cloudflare Pages project to the account allowed to publish it. It shares this
+// registry because the ownership question ("may this caller act on this named
+// thing?") and its answer (resolveOwner + authorizeAccess) are identical.
+export type ResourceKind = "d1" | "r2" | "pages";
 
 export interface StorageResource {
   accountId: string;

package/payload/platform/plugins/admin/lib/mcp-spawn-tee/index.js

@@ -13,14 +13,15 @@
  *
  *   Claude Code CLI → shim (this file) = node running <real-entry> in-process
  *        stdin/stdout : untouched (JSON-RPC channel)
- *        stderr       : process.stderr.write teed → per-date + per-session + passthrough
+ *        stderr       : process.stderr.write teed → raw sink + passthrough
  *
- * Destinations (Task 706) — unchanged:
- *   - `${LOG_DIR}/mcp-<name>-stderr-<date>.log`  — per-date raw (back-compat;
- *     the in-process mcp-stderr-tee and the [mcp-init-error] probe read it).
- *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — per-session raw + lifecycle
- *     lines. Authoritative sink. Absent when SESSION_ID is unset (enumeration
- *     spawn) — then the per-date file is the fallback.
+ * Destinations:
+ *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — raw stderr + lifecycle lines.
+ *     The sole raw sink. Task 1721 retired the per-date twin: its date was
+ *     pinned at spawn, no reader ever parsed it, and mcp-stderr-tee wrote the
+ *     same file, so every line landed twice.
+ *   - `${LOG_DIR}/mcp-<name>-nosession.log`      — the same, for a spawn with
+ *     no SESSION_ID (enumeration). One fixed file per server.
  *   - `server.log` via the loopback log-ingest route — best-effort mirror of
  *     the [mcp-helper] lifecycle lines.
  *
@@ -49,13 +50,13 @@ const PLATFORM_PORT = process.env.PLATFORM_PORT;
 const ENTRY = process.argv[2];
 const SESSION_ID8 = SESSION_ID ? SESSION_ID.slice(0, 8) : "—";
 const spawnStamp = Date.now();
-// Per-session raw + lifecycle log (Task 706). Empty SESSION_ID (enumeration
-// spawn) → undefined, and the per-date file is the fallback.
-const perSessionPath = LOG_DIR && SESSION_ID
-    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-${SESSION_ID}.log`)
-    : undefined;
-const perDatePath = LOG_DIR
-    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-stderr-${new Date(spawnStamp).toISOString().slice(0, 10)}.log`)
+// The one raw sink (Task 1721). A sessionless spawn (rc-daemon stamps
+// SESSION_ID='' — rc-daemon.ts:513 — while still stamping LOG_DIR) shares one
+// fixed file per server rather than a date-named one: the date was never read
+// by any reader and named a process lifetime, not a day. Interleaved spawns in
+// the nosession file are separated by the [mcp-helper] op=spawn pid= lines.
+const rawSinkPath = LOG_DIR
+    ? (0, node_path_1.resolve)(LOG_DIR, SESSION_ID ? `mcp-${SERVER_NAME}-${SESSION_ID}.log` : `mcp-${SERVER_NAME}-nosession.log`)
     : undefined;
 // Rolling tail of entry stderr for op=exit. Capped so a chatty server cannot
 // grow the buffer without bound.
@@ -66,7 +67,7 @@ let exitEmitted = false;
 let exitSignal;
 // The real stderr writer, captured before the tee replaces it. Lifecycle lines
 // and stderr passthrough both go through this so they are never re-teed into
-// the per-date sink nor recursed back into the patched writer.
+// the raw sink nor recursed back into the patched writer.
 const rawStderrWrite = process.stderr.write.bind(process.stderr);
 // LOG_DIR is created once, lazily, on the first successful append — not per
 // chunk. teeWrite runs on the server's own stderr hot path now, so a per-call
@@ -115,7 +116,7 @@ function postToServerLog(suffix, level) {
 // log-ingest route rejects newlines).
 function emitLifecycle(suffix, level) {
     const line = `[mcp-helper] ${suffix}\n`;
-    appendSafe(perSessionPath, line);
+    appendSafe(rawSinkPath, line);
     try {
         rawStderrWrite(line);
     }
@@ -127,12 +128,11 @@ if (!ENTRY) {
     process.exit(2);
 }
 // Replace process.stderr.write with a tee: mirror every server stderr byte to
-// the per-date and per-session sinks, keep a rolling tail for op=exit, emit
+// the raw sink, keep a rolling tail for op=exit, emit
 // op=boot on the first bytes, then pass the write through to the real stderr.
 const teeWrite = ((...args) => {
     const chunk = args[0];
-    appendSafe(perDatePath, chunk); // per-date raw (back-compat)
-    appendSafe(perSessionPath, chunk); // per-session raw (Task 706)
+    appendSafe(rawSinkPath, chunk); // raw sink (Task 1721)
     const text = typeof chunk === "string" ? chunk : Buffer.from(chunk).toString("utf8");
     stderrTail = (stderrTail + text).slice(-TAIL_CAP);
     if (!bootEmitted) {

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:c7d0d9f383f8d9ee8ed50b8869ce43477e3cb5ebf62305a39041c072e34bfeb1
+content-hash: sha256:ddd3d65ece37d8e4ddcc7094ade79a1113d56ec2b0ca43e7d36e7f40c3f00efb
 brand: maxy-code
 product-name: Maxy
 ---
@@ -485,7 +485,9 @@ import { initStderrTee } from "../../../../lib/mcp-stderr-tee/dist/index.js";
 initStderrTee("your-plugin-name");
 ```
 
-After this, every `console.error("[your-tool]...")` from any tool in the plugin appears as `[<iso-ts>] [mcp:your-plugin-name] [your-tool]...` in the per-conversation stream log `claude-agent-stream-{sessionId}.log`, alongside the usual agent events. The raw per-server file `mcp-your-plugin-name-stderr-{date}.log` is still produced for deep-dive grep.
+After this, every `console.error("[your-tool]...")` from any tool in the plugin is captured in the raw per-server file `mcp-your-plugin-name-{sessionId}.log`, written by the `mcp-spawn-tee` wrapper. That is where you grep.
+
+`initStderrTee` is *intended* to also mirror each line into the per-conversation stream log `claude-agent-stream-{sessionId}.log` as `[<iso-ts>] [mcp:your-plugin-name] [your-tool]...`, alongside the usual agent events. It does not currently do so: that destination is gated on `STREAM_LOG_PATH`, which no spawner sets, so the call is a no-op in production. Do not expect `[mcp:<name>]` lines in a conversation's stream log, and do not read their absence as the server having emitted nothing. Tracked as [`.tasks/1736-*.md`](../../../.tasks/1736-nothing-sets-stream-log-path-so-the-per-conversation-mcp-stream-log-does-not-exist.md).
 
 **Premium plugins.** Source lives at `premium-plugins/<bundle>/plugins/<name>/mcp/src/` — deeper than platform plugins, so the source-relative import to `platform/lib/mcp-stderr-tee/dist/index.js` uses more `../` segments. The bundler rewrites the compiled output to the canonical `../../../../lib/mcp-stderr-tee/dist/index.js` at staging time and ships `platform/lib/mcp-stderr-tee/{dist,package.json}` into `premium-plugins/<bundle>/lib/mcp-stderr-tee/` so the import resolves at deployed depth. The bundler fails loudly if `platform/lib/mcp-stderr-tee/package.json` is missing (it must pin `type` so install-location parent walks cannot mis-classify the dist file) or if any lib referenced by a rewritten import has no source dist.
 
@@ -496,7 +498,7 @@ After this, every `console.error("[your-tool]...")` from any tool in the plugin
 **Retrieve MCP diagnostic lines for a conversation:**
 
 - All servers: `logs-read { type: "system", sessionId: "..." }` → grep `[mcp:<name>]` on the returned stream log.
-- One server raw feed: `logs-read { type: "mcp" }` → tails the most recent `mcp-<name>-stderr-*.log` (per-plugin, not per-conversation).
+- One server raw feed: `logs-read { type: "mcp" }` → tails the most recent `mcp-<name>-*.log` (per-plugin, not per-conversation).
 
 **Tee-state markers** land in the stream log: `[platform] [mcp-tee-attach] server=<name> streamLogPath=...` when the tee wires up, `[platform] [mcp-tee-skip] server=<name> destination=... reason=...` when a destination fails (missing `LOG_DIR`, unwritable path, `STREAM_LOG_PATH` not set, etc.), `[platform] [mcp-tee-detach] server=<name>` on graceful shutdown. If a server invoked tools but no `[mcp:<name>]` lines appear in the conversation's log, look for the skip marker first.
 
@@ -504,17 +506,17 @@ After this, every `console.error("[your-tool]...")` from any tool in the plugin
 
 ## Failure-path observability contract (earlier platform fixes + earlier platform fixes)
 
-The `initStderrTee` wrapper writes to the per-conversation stream log and per-server raw file via `createWriteStream` — async, buffered. Any diagnostic `console.error(…)` followed by an immediate `process.exit(…)` is lost: the event loop never drains the WriteStream before the process terminates. Same race for any synchronous module-load throw: Node's uncaught-exception handler writes the stack to raw fd 2 and exits before the patched async stream flushes. The platform's `[mcp-init-error] tail="(no stderr file)"` line — operationally useless — is the public symptom of this race.
+The `initStderrTee` wrapper writes to the per-conversation stream log via `createWriteStream` — async, buffered. Any diagnostic `console.error(…)` followed by an immediate `process.exit(…)` is lost from *that* destination: the event loop never drains the WriteStream before the process terminates. Same race for any synchronous module-load throw: Node's uncaught-exception handler writes the stack to raw fd 2 and exits before the patched async stream flushes. The raw sink does not have this race — removed `initStderrTee`'s own raw file, and `mcp-spawn-tee` writes the sink with `appendFileSync`, which returns once the kernel has queued the write and so survives an immediate exit.
 
 **Two layers now close the gap, each load-bearing on its own:**
 
 1. **Plugin-side sync-write discipline.** Plugins that call `process.exit` during module load (rare — `graph-mcp` is the in-tree example; it spawns a child at boot to proxy upstream stdio) use `fs.appendFileSync` at every named exit path to guarantee the cause lands in both log destinations before exit. Lines follow the `[mcp:<name>] [<plugin-prefix>] <cause>` format so existing `grep '[mcp:<name>]'` investigator paths work. Each destination is wrapped in its own try/catch — an unwritable log must not mask the primary failure. This is the discipline propagated to any plugin author who knows their failure paths.
 
-2. **Parent-side `mcp-spawn-tee` wrapper.** Every node-based core MCP server is spawned via the `lib/mcp-spawn-tee` wrapper rather than `node <entry>` directly. The wrapper spawns the real entry with `stdio: ['inherit', 'inherit', 'pipe']` and writes child stderr chunks to `${LOG_DIR}/mcp-${name}-stderr-<date>.log` via `appendFileSync` while passing the same chunks through to its own stderr (Claude Code's consumer is unchanged). Synchronous `appendFileSync` survives `process.exit`, so the per-server file captures even (a) module-load throws before `initStderrTee` runs, (b) `MODULE_NOT_FOUND` on the entry script itself, and (c) anything else a plugin author missed. The wrapper writes `[mcp-spawn-tee-attached] server=<name> pid=<n>` on attach and forwards SIGTERM/SIGINT to the child. This is the layer that makes capture independent of plugin discipline. Playwright stays unwrapped because it spawns via `npx`, not `node`.
+2. **Parent-side `mcp-spawn-tee` wrapper.** Every node-based core MCP server is spawned via the `lib/mcp-spawn-tee` wrapper rather than `node <entry>` directly. The wrapper runs the real entry in its own process and writes stderr chunks to `${LOG_DIR}/mcp-${name}-${SESSION_ID}.log` (or `mcp-${name}-nosession.log` when `SESSION_ID` is unset) via `appendFileSync` while passing the same chunks through to its own stderr (Claude Code's consumer is unchanged). It is the only writer of that raw sink: retired the `mcp-${name}-stderr-<date>.log` twin, which `mcp-stderr-tee` also wrote, so every line used to land there twice. Synchronous `appendFileSync` survives `process.exit`, so the sink captures even (a) module-load throws before `initStderrTee` runs, (b) `MODULE_NOT_FOUND` on the entry script itself, and (c) anything else a plugin author missed. The wrapper writes `[mcp-spawn-tee-attached] server=<name> pid=<n>` on attach and forwards SIGTERM/SIGINT to the child. This is the layer that makes capture independent of plugin discipline. Playwright stays unwrapped because it spawns via `npx`, not `node`.
 
-A third layer closes the same gap from the platform side: when `claude-agent.ts` observes an `init` event with any MCP server reporting `status:"failed"`, it reads the last 512 bytes of `${LOG_DIR}/mcp-<name>-stderr-<date>.log` and emits `[mcp-init-error] server=<name> tail=<quoted>` into the stream log. Absent file → `tail="(no stderr file)"`; empty file → `tail="(empty)"`. With the spawn-tee wrapper now interposing on every core MCP, `tail="(no stderr file)"` means the wrapper itself is broken — file follow-up.
+A `[mcp-init-error]` probe on the platform side used to read the retired per-date file and tail it into the stream log. found no such probe in live code — `claude-agent.ts` has not carried one for some time — so the wrapper's own `[mcp-helper] op=boot` and `op=exit` lines are the record of a failed MCP boot.
 
-**Signal inventory after a failed session:** `[init] FAILED MCP servers: <names>` (names), `[mcp-init-error] server=<name> tail=…` (cause for each, from the platform's tail probe), `[mcp-spawn-tee-attached] server=<name> pid=<n>` (proof the wrapper attached), `[mcp-spawn-tee-exit] server=<name> code=<n>|signal=<s>` (proof the wrapper saw the exit), and optionally `[mcp:<name>] [<plugin>] …` from plugin-side sync-writes. Their union gives the investigator three independent sources for the same failure.
+**Signal inventory after a failed session:** `[init] FAILED MCP servers: <names>` (names), `[mcp-spawn-tee-attached] server=<name> pid=<n>` (proof the wrapper attached), `[mcp-spawn-tee-exit] server=<name> code=<n>|signal=<s>` (proof the wrapper saw the exit), and optionally `[mcp:<name>] [<plugin>] …` from plugin-side sync-writes. Their union gives the investigator independent sources for the same failure. (The two `[mcp-spawn-tee-*]` names are stale — the shim emits `[mcp-helper] op=spawn|boot|exit`; see [`.tasks/1737-*.md`](../../../.tasks/1737-mcp-spawn-tee-docs-promise-lifecycle-markers-and-a-child-process-that-task-989-removed.md).)
 
 **Boot-smoke as publish-time gate.** The memory MCP carries `scripts/boot-smoke.sh` that spawns `dist/index.js` with stub env, sleeps 2s, asserts `kill -0 <pid>`, and reports `[boot-smoke] memory ok|FAILED tail=<n-lines>`. Wired to `prepublish` in `plugins/memory/mcp/package.json`. The pattern is propagatable to other plugin MCPs — it's deliberately not generalised yet because each plugin's stub-env requirements differ (memory needs ACCOUNT_ID + PLATFORM_ROOT + NEO4J_URI + SESSION_ID; others differ).
 
@@ -1146,6 +1148,8 @@ Source: https://docs.getmaxy.com/cloudflare.md
 
 Each installation has its own Cloudflare account. The **tunnel** sign-in is OAuth: the agent invokes `cloudflared tunnel login` via Bash; the Cloudflare Authorize URL streams into the admin chat PTY and the native terminal renders it as a clickable link. Click it, authorise in your own browser, and `cloudflared` writes `cert.pem` to the brand's config directory. For **everything else** (DNS, Pages, D1, Access) the agent uses the Cloudflare API, authenticated by a short-lived narrow token it mints from a master token you provision once in the dashboard (an advanced step the agent never automates). Some account-side jobs — adding a domain, switching accounts — are still easiest in your browser, and the agent relays those click-paths; the rest it can do directly via the API.
 
+Where one installation serves several client accounts from one Cloudflare account, that master is held by the house account alone, and a client account cannot mint from it — it is account-wide, so handing it to one client would hand them every other client's data. Publishing a client's website therefore runs house-side on the client's behalf: the client's session asks, the house does the deploy, and no Cloudflare token ever enters the client's account. Which website belongs to which client is recorded once by the house and is never inferred from folder names, so a site nobody has recorded cannot be published by anyone until it is.
+
 ## Identity model
 
 | Concept | Source |
@@ -2072,7 +2076,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 | `outlook-mailbox-info` | Health probe for one mailbox — auth state, refresh-window, folder count. Name the mailbox with `mailbox` when several are attached. |
 | `outlook-mailbox-list` | Every connected mailbox with its email, scopes, and token health. Local only — no network — so it also flags a mailbox whose stored credentials cannot be read. |
 | `outlook-mail-send` | Send a message. No attachments → `POST /me/sendMail`; with attachments → draft, attach, send (`/me/sendMail` carries attachments inline and cannot fit a large file). to/cc/bcc arrays, subject, body, isHtml, attachments (account-dir paths, 25 MB/file). Success asserted on Graph 202; no message id on either route. Needs `Mail.Send` (+ `Mail.ReadWrite` to attach). |
-| `outlook-draft` | Create a draft in Drafts (`POST /me/messages`). Same body model, including attachments — files are attached before the id is returned, so the draft is ready to send. Returns the draft id. Needs `Mail.ReadWrite`. |
+| `outlook-draft` | Create a draft in Drafts, either a new message or a threaded reply. Returns the draft id; never sends. Attachments are attached before the id is returned, so the draft is ready to send. Needs `Mail.ReadWrite`. **New message** (no `replyToMessageId`): `POST /me/messages`, requires `to` + `subject`, same body model as `outlook-mail-send`, threads under nothing. **Threaded reply** (`replyToMessageId` = the id of the message being answered): `POST /me/messages/{id}/createReply` — the draft carries the parent's conversationId, so it lands under the original. This is the only way to draft a reply without sending it: `outlook-mail-reply` threads but always sends. Graph sets the recipients and `RE:` subject from the original and composes the body above its own quote, matching what `outlook-mail-reply` sends, so the threaded path is **plain text only** — `to`, `subject`, and `isHtml: true` are **refused** (not ignored) when replying. `replyAll` includes everyone on the original; `cc`/`bcc` add recipients. |
 | `outlook-draft-edit` | Update an existing draft in place (`PATCH /me/messages/{draftId}`) and/or add and remove attachments. Graph drafts are mutable — pass draftId plus the fields to change (to/cc/bcc/subject/body/isHtml/attachments/removeAttachments). `attachments` adds; `removeAttachments` takes files off by name or attachment id; both together replace a file in one call. Sent messages cannot be edited. Needs `Mail.ReadWrite`. |
 | `outlook-draft-send` | Send an existing draft by id (`POST /me/messages/{id}/send`). Graph consumes the draft, returns 202. Needs `Mail.Send`. |
 
@@ -2114,9 +2118,9 @@ All log lines start with `[outlook-mcp]` and write to `server.log`. They are key
 | Send args | `send-args account=<id> recipients=<N> hasBody=<bool>` |
 | Sent | `sent account=<id> status=202 messageId=<id-or-null>` |
 | Send failed | `send-failed account=<id> error=<msg>` |
-| Draft request | `draft-request account=<id>` |
-| Draft created | `draft-created account=<id> id=<draftId>` |
-| Draft failed | `draft-failed account=<id> error=<msg>` |
+| Draft request | `draft-request account=<id> threaded=<bool>` |
+| Draft created | `draft-created account=<id> id=<draftId> threaded=<bool> convId=<id\|null>` |
+| Draft failed | `draft-failed account=<id> threaded=<bool> error=<msg>` |
 | Draft-send request | `draft-send-request account=<id> id=<draftId>` |
 | Draft sent | `draft-sent account=<id> id=<draftId> status=202` |
 | Draft-send failed | `draft-send-failed account=<id> id=<draftId> error=<msg>` |
@@ -2129,8 +2133,15 @@ ssh laptop 'grep -E "^\[outlook-mcp\]" ~/.maxy/logs/server.log | grep "account=<
 
 # Token-leak audit — must always return zero
 grep -rn -iE "Bearer |access_token=" ~/.maxy/logs/server.log | head
+
+# Threading audit — a threaded write that reports no conversation LOST its thread.
+# Must always return zero. Covers both outbound threaded paths (mail-reply and draft-created).
+grep -E "^\[outlook-mcp\] (mail-reply|draft-created)" ~/.maxy/logs/server.log \
+  | grep -E "threaded=true|op=reply" | grep -E "convId=(null)?( |$)" | head
 ```
 
+Threading triage: **absence of a `convId` on a threaded write means threading was lost.** `draft-created threaded=false convId=null` is correct and expected — a new message has no parent conversation. `draft-created threaded=true convId=null` is a fault: Graph returned a reply draft that names no conversation, and the reply will land detached from the original.
+
 Latency triage: `mail-list count=0 elapsedMs<200` consistent → permissions issue; `elapsedMs > 5000` → Graph slowness or DNS.
 
 ## Failure modes
@@ -3941,7 +3952,7 @@ Standing rules the operator gives over a channel are `Preference` nodes. Two mec
 
 **Inject the active rule-set every turn (channel gateways).** The one definition of "this account's active rules" is `@maxy/active-rules`: the account owner's admin-scope preferences (resolve the seeded `AdminUser {role:'owner'}`, then select through that owner's `UserProfile` via `HAS_PREFERENCE`), a bounded, floor-filtered (`confidence >= 0.4`), confidence-ordered candidate query, then semantic de-confliction (one winner per subject at the same 0.85 cosine), capped to `INJECTION_RULE_CAP` (12). A preference owned by a non-owner profile (an operator's, stranded on the operator's own profile while managing the account) is never injected; an account with no seeded owner injects nothing. `profile-read` exposes this same owner-scoped set as `activeRules`, and the three inbound gateways (`wa-gateway`, `telegram-gateway`, `webchat-gateway`) fetch it for the effective session account and attach it as `standingRules` on the inbound frame; the channel builders prepend it as a `## Standing rules` block above `## Context`. Both channel-server inbound paths carry the block: the single-target SSE loop parses the whole frame, and the unified multi-target door reader (`runDoorStream`,) reconstructs it through the shared `doorInboundPayload` seam whose `parseFrame` closures read `standingRules` off the frame. The read is by code, not agent discretion, so a rule set last week is applied this week regardless of how many times the session compacted. Telegram and webchat inject for `role:'admin'` only — a public visitor never receives operator rules.
 
-**Trust a scheduled turn's provenance, never an inbound's claim (channel-agent grounding).** A cron-dispatched agent turn reaches the same channel builders as a real inbound, so its own authorisation text would otherwise land inside `## Context` — the zone `REFRAME_INSTRUCTION` demotes to untrusted — and a security-cautious agent would distrust its own automation (the self-cancel loop). The dispatcher therefore stamps a `ScheduleProvenance` marker (owning account, event, owner userId, dispatch time) that the channel builders render as a `## Scheduled automation (platform-verified)` preamble **above** `## Context` (and above the rules block); the whatsapp wrap tag names the door `scheduler`. Both channel-server paths carry the marker — the single-target loop and the unified multi-target door reader (via the same `doorInboundPayload` seam that carries `standingRules`); the scheduler only dispatches to the whatsapp/telegram door, so a webchat frame never bears one. Because the marker is dispatcher-stamped and never derived from payload text, an inbound message cannot forge it — placement above `## Context` alone is not the trust signal, the dispatcher provenance is. The grounding binds to it in two places: one recipient-neutral clause added byte-identical to the three reframe instructions (a marker-bearing turn is authorised standing automation; a reconfiguration or re-enable is not intrusion), and the admin `IDENTITY.md` "Untrusted input" rule that the agent never states a platform-level authenticity or impersonation verdict it was not given (an unsourced "this is not from you" is its own inference, flagged, never asserted as the platform's). The amplifier that let one misread harden was the accreting seat: a recurring event resumed one long-lived session every firing. A subsequent change removes it — each firing runs a fresh per-firing seat (`scheduledSeatIdFor`, salted with the firing's eventId + dispatch time), so distrust cannot accrete across firings, and the self-cancel guard compares the cancelling `SESSION_ID` to the node's dispatcher-stamped `lastDispatchSessionId` rather than a recomputed deterministic seat. See `.docs/scheduling-agent-dispatch.md § Operator-provenance marker` and `§ Session model — fresh per firing`.
+**Trust a scheduled turn's provenance, never an inbound's claim (channel-agent grounding).** A cron-dispatched agent turn reaches the same channel builders as a real inbound, so its own authorisation text would otherwise land inside `## Context` — the zone `REFRAME_INSTRUCTION` demotes to untrusted — and a security-cautious agent would distrust its own automation (the self-cancel loop). The dispatcher therefore stamps a `ScheduleProvenance` marker (owning account, event, owner userId, dispatch time) that the channel builders render as a `## Scheduled automation (platform-verified)` preamble **above** `## Context` (and above the rules block); the whatsapp wrap tag names the door `scheduler`. Both channel-server paths carry the marker — the single-target loop and the unified multi-target door reader (via the same `doorInboundPayload` seam that carries `standingRules`); the scheduler only dispatches to the whatsapp/telegram door, so a webchat frame never bears one. Because the marker is dispatcher-stamped and never derived from payload text, an inbound message cannot forge it — placement above `## Context` alone is not the trust signal, the dispatcher provenance is. The grounding binds to it in two places: one recipient-neutral clause added byte-identical to the three reframe instructions (a marker-bearing turn is authorised standing automation; a reconfiguration or re-enable is not intrusion), and the admin `IDENTITY.md` "Untrusted input" rule that the agent never states a platform-level authenticity or impersonation verdict it was not given (an unsourced "this is not from you" is its own inference, flagged, never asserted as the platform's). A sender has exactly one session: every inbound, real or scheduled, resolves to the deterministic `adminSessionIdFor(effectiveAccount, destination)`. An earlier change gave each firing its own salted seat so distrust could not accrete across firings, but the inbound hub keys on `senderId` and replaces its subscriber outright, so a seat's channel server attached under the sender's own key and swallowed the sender's REAL messages until it detached — splitting one conversation across two sessions that each denied what the other held. The seat is removed; the authoritative `agentPrompt`, this provenance marker, and the injected standing rules ground each firing without one. Self-cancel attribution is disarmed while that model beds in: the guard used to compare the cancelling turn's session id to a dispatcher stamp, which discriminated only because each firing ran its own seat, so with one session per sender it would report an autonomous loop on every operator cancel. It now always reports false — under-counting a real loop rather than inventing one — until the discriminator is rebuilt from the turn's own dispatched eventId. See `.docs/scheduling-agent-dispatch.md § Operator-provenance marker`, `§ Session model — one session per sender`, and `§ Self-cancel attribution — disarmed`.
 
 **Observability.** `[preference-write] op=reconcile … mode=<reinforce|update|contradict|new> similarity=…` — a stream of `mode=new` for subjects that already exist is the duplicate-minting signature. `[preference-inject] op=inject channel=<wa|tg|web> injected=<N> owner=<8> source=<owner|no-owner|owner-error|fetch-error>` — injection selects only the account owner's admin preferences, so `source=owner injected=0` is a genuinely empty owner, `source=no-owner` is an account with no seeded owner (injects nothing, a missed owner seeding), and `injected=0 source=owner` on an account whose owner holds rules is the write-only regression re-appearing. `[preference-audit] op=drift accountId=… storedActive=… injectedActive=… duplicateClusters=…` — the standing reconciliation audit (claude-session-manager, 5-minute tick) flags any account whose store holds more active rows than injection would surface, the no-event detector for drift.
 

package/payload/platform/plugins/aeo/lib/mcp-spawn-tee/index.js

@@ -13,14 +13,15 @@
  *
  *   Claude Code CLI → shim (this file) = node running <real-entry> in-process
  *        stdin/stdout : untouched (JSON-RPC channel)
- *        stderr       : process.stderr.write teed → per-date + per-session + passthrough
+ *        stderr       : process.stderr.write teed → raw sink + passthrough
  *
- * Destinations (Task 706) — unchanged:
- *   - `${LOG_DIR}/mcp-<name>-stderr-<date>.log`  — per-date raw (back-compat;
- *     the in-process mcp-stderr-tee and the [mcp-init-error] probe read it).
- *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — per-session raw + lifecycle
- *     lines. Authoritative sink. Absent when SESSION_ID is unset (enumeration
- *     spawn) — then the per-date file is the fallback.
+ * Destinations:
+ *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — raw stderr + lifecycle lines.
+ *     The sole raw sink. Task 1721 retired the per-date twin: its date was
+ *     pinned at spawn, no reader ever parsed it, and mcp-stderr-tee wrote the
+ *     same file, so every line landed twice.
+ *   - `${LOG_DIR}/mcp-<name>-nosession.log`      — the same, for a spawn with
+ *     no SESSION_ID (enumeration). One fixed file per server.
  *   - `server.log` via the loopback log-ingest route — best-effort mirror of
  *     the [mcp-helper] lifecycle lines.
  *
@@ -49,13 +50,13 @@ const PLATFORM_PORT = process.env.PLATFORM_PORT;
 const ENTRY = process.argv[2];
 const SESSION_ID8 = SESSION_ID ? SESSION_ID.slice(0, 8) : "—";
 const spawnStamp = Date.now();
-// Per-session raw + lifecycle log (Task 706). Empty SESSION_ID (enumeration
-// spawn) → undefined, and the per-date file is the fallback.
-const perSessionPath = LOG_DIR && SESSION_ID
-    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-${SESSION_ID}.log`)
-    : undefined;
-const perDatePath = LOG_DIR
-    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-stderr-${new Date(spawnStamp).toISOString().slice(0, 10)}.log`)
+// The one raw sink (Task 1721). A sessionless spawn (rc-daemon stamps
+// SESSION_ID='' — rc-daemon.ts:513 — while still stamping LOG_DIR) shares one
+// fixed file per server rather than a date-named one: the date was never read
+// by any reader and named a process lifetime, not a day. Interleaved spawns in
+// the nosession file are separated by the [mcp-helper] op=spawn pid= lines.
+const rawSinkPath = LOG_DIR
+    ? (0, node_path_1.resolve)(LOG_DIR, SESSION_ID ? `mcp-${SERVER_NAME}-${SESSION_ID}.log` : `mcp-${SERVER_NAME}-nosession.log`)
     : undefined;
 // Rolling tail of entry stderr for op=exit. Capped so a chatty server cannot
 // grow the buffer without bound.
@@ -66,7 +67,7 @@ let exitEmitted = false;
 let exitSignal;
 // The real stderr writer, captured before the tee replaces it. Lifecycle lines
 // and stderr passthrough both go through this so they are never re-teed into
-// the per-date sink nor recursed back into the patched writer.
+// the raw sink nor recursed back into the patched writer.
 const rawStderrWrite = process.stderr.write.bind(process.stderr);
 // LOG_DIR is created once, lazily, on the first successful append — not per
 // chunk. teeWrite runs on the server's own stderr hot path now, so a per-call
@@ -115,7 +116,7 @@ function postToServerLog(suffix, level) {
 // log-ingest route rejects newlines).
 function emitLifecycle(suffix, level) {
     const line = `[mcp-helper] ${suffix}\n`;
-    appendSafe(perSessionPath, line);
+    appendSafe(rawSinkPath, line);
     try {
         rawStderrWrite(line);
     }
@@ -127,12 +128,11 @@ if (!ENTRY) {
     process.exit(2);
 }
 // Replace process.stderr.write with a tee: mirror every server stderr byte to
-// the per-date and per-session sinks, keep a rolling tail for op=exit, emit
+// the raw sink, keep a rolling tail for op=exit, emit
 // op=boot on the first bytes, then pass the write through to the real stderr.
 const teeWrite = ((...args) => {
     const chunk = args[0];
-    appendSafe(perDatePath, chunk); // per-date raw (back-compat)
-    appendSafe(perSessionPath, chunk); // per-session raw (Task 706)
+    appendSafe(rawSinkPath, chunk); // raw sink (Task 1721)
     const text = typeof chunk === "string" ? chunk : Buffer.from(chunk).toString("utf8");
     stderrTail = (stderrTail + text).slice(-TAIL_CAP);
     if (!bootEmitted) {

package/payload/platform/plugins/browser/lib/mcp-spawn-tee/index.js

@@ -13,14 +13,15 @@
  *
  *   Claude Code CLI → shim (this file) = node running <real-entry> in-process
  *        stdin/stdout : untouched (JSON-RPC channel)
- *        stderr       : process.stderr.write teed → per-date + per-session + passthrough
+ *        stderr       : process.stderr.write teed → raw sink + passthrough
  *
- * Destinations (Task 706) — unchanged:
- *   - `${LOG_DIR}/mcp-<name>-stderr-<date>.log`  — per-date raw (back-compat;
- *     the in-process mcp-stderr-tee and the [mcp-init-error] probe read it).
- *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — per-session raw + lifecycle
- *     lines. Authoritative sink. Absent when SESSION_ID is unset (enumeration
- *     spawn) — then the per-date file is the fallback.
+ * Destinations:
+ *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — raw stderr + lifecycle lines.
+ *     The sole raw sink. Task 1721 retired the per-date twin: its date was
+ *     pinned at spawn, no reader ever parsed it, and mcp-stderr-tee wrote the
+ *     same file, so every line landed twice.
+ *   - `${LOG_DIR}/mcp-<name>-nosession.log`      — the same, for a spawn with
+ *     no SESSION_ID (enumeration). One fixed file per server.
  *   - `server.log` via the loopback log-ingest route — best-effort mirror of
  *     the [mcp-helper] lifecycle lines.
  *
@@ -49,13 +50,13 @@ const PLATFORM_PORT = process.env.PLATFORM_PORT;
 const ENTRY = process.argv[2];
 const SESSION_ID8 = SESSION_ID ? SESSION_ID.slice(0, 8) : "—";
 const spawnStamp = Date.now();
-// Per-session raw + lifecycle log (Task 706). Empty SESSION_ID (enumeration
-// spawn) → undefined, and the per-date file is the fallback.
-const perSessionPath = LOG_DIR && SESSION_ID
-    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-${SESSION_ID}.log`)
-    : undefined;
-const perDatePath = LOG_DIR
-    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-stderr-${new Date(spawnStamp).toISOString().slice(0, 10)}.log`)
+// The one raw sink (Task 1721). A sessionless spawn (rc-daemon stamps
+// SESSION_ID='' — rc-daemon.ts:513 — while still stamping LOG_DIR) shares one
+// fixed file per server rather than a date-named one: the date was never read
+// by any reader and named a process lifetime, not a day. Interleaved spawns in
+// the nosession file are separated by the [mcp-helper] op=spawn pid= lines.
+const rawSinkPath = LOG_DIR
+    ? (0, node_path_1.resolve)(LOG_DIR, SESSION_ID ? `mcp-${SERVER_NAME}-${SESSION_ID}.log` : `mcp-${SERVER_NAME}-nosession.log`)
     : undefined;
 // Rolling tail of entry stderr for op=exit. Capped so a chatty server cannot
 // grow the buffer without bound.
@@ -66,7 +67,7 @@ let exitEmitted = false;
 let exitSignal;
 // The real stderr writer, captured before the tee replaces it. Lifecycle lines
 // and stderr passthrough both go through this so they are never re-teed into
-// the per-date sink nor recursed back into the patched writer.
+// the raw sink nor recursed back into the patched writer.
 const rawStderrWrite = process.stderr.write.bind(process.stderr);
 // LOG_DIR is created once, lazily, on the first successful append — not per
 // chunk. teeWrite runs on the server's own stderr hot path now, so a per-call
@@ -115,7 +116,7 @@ function postToServerLog(suffix, level) {
 // log-ingest route rejects newlines).
 function emitLifecycle(suffix, level) {
     const line = `[mcp-helper] ${suffix}\n`;
-    appendSafe(perSessionPath, line);
+    appendSafe(rawSinkPath, line);
     try {
         rawStderrWrite(line);
     }
@@ -127,12 +128,11 @@ if (!ENTRY) {
     process.exit(2);
 }
 // Replace process.stderr.write with a tee: mirror every server stderr byte to
-// the per-date and per-session sinks, keep a rolling tail for op=exit, emit
+// the raw sink, keep a rolling tail for op=exit, emit
 // op=boot on the first bytes, then pass the write through to the real stderr.
 const teeWrite = ((...args) => {
     const chunk = args[0];
-    appendSafe(perDatePath, chunk); // per-date raw (back-compat)
-    appendSafe(perSessionPath, chunk); // per-session raw (Task 706)
+    appendSafe(rawSinkPath, chunk); // raw sink (Task 1721)
     const text = typeof chunk === "string" ? chunk : Buffer.from(chunk).toString("utf8");
     stderrTail = (stderrTail + text).slice(-TAIL_CAP);
     if (!bootEmitted) {

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

@@ -44,7 +44,7 @@ The plugin registers no agent-facing MCP tools. Every Cloudflare operation is th
 | [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, plus the establishment discipline: `<accountId>-<purpose>` naming, one store per purpose, and the canonical `acceptances` schema. |
 | [r2-object-storage.md](references/r2-object-storage.md) | R2 buckets under the same establishment discipline as D1: `<accountId>-<purpose>` naming via `cf-store-name.sh`, one bucket per purpose, `wrangler r2 bucket create`, and the store-provision breadcrumb. |
-| [hosting-sites.md](references/hosting-sites.md) | Deploy a static or Next.js site to Cloudflare Pages via `wrangler pages deploy`. |
+| [hosting-sites.md](references/hosting-sites.md) | Deploy a static or Next.js site to Cloudflare Pages via `wrangler pages deploy`. House/single-tenant path: on a multi-tenant install a client account is denied the `pages` scope (`reason=not-house`) and publishes with `storage-broker:storage-pages-deploy` instead. |
 | [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. |
 | [dashboard-guide.md](references/dashboard-guide.md) | Click-paths for operations the operator prefers to do by hand — sign in, switch accounts, add a site, edit an apex CNAME, verify nameservers, delete a tunnel, manage CNAME records, author an Access policy. |
 | [reset-guide.md](references/reset-guide.md) | Decision tree for reset vs. patch, the exact `pkill` incantation for token-mode connectors, and the dashboard cleanup paths for stray records and rogue entries. |

package/payload/platform/plugins/cloudflare/mcp/dist/index.js

@@ -1,14 +1,14 @@
-import { initStderrTee } from "../../../../lib/mcp-stderr-tee/dist/index.js";
-initStderrTee("cloudflare");
 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 // The Cloudflare plugin exposes zero agent-facing tools. Every
 // Cloudflare operation is the agent invoking `cloudflared` directly via
 // the Bash tool, following the runbook in
 // platform/plugins/cloudflare/references/manual-setup.md, with
-// cloudflared stdout/stderr streamed verbatim into the PTY. The MCP
-// server process still spawns for lifecycle and stderr-tee consistency
-// with other plugins, but its tool list is empty by design.
+// cloudflared stdout/stderr streamed verbatim into the PTY. The plugin
+// declares `mcp-manifest: skip` and no `mcp:` block, so this entry is never
+// spawned as an MCP server: only the generated .claude-plugin/plugin.json
+// mcpServers block makes Claude Code spawn one (tool-registration-drift.ts).
+// Task 1721 removed its unreachable stderr-tee call.
 const server = new McpServer({
     name: "cloudflare",
     version: "0.4.0",

package/payload/platform/plugins/cloudflare/mcp/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAC7E,aAAa,CAAC,YAAY,CAAC,CAAC;AAE5B,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AAEjF,+DAA+D;AAC/D,wEAAwE;AACxE,0CAA0C;AAC1C,+DAA+D;AAC/D,oEAAoE;AACpE,uEAAuE;AACvE,4DAA4D;AAE5D,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;IAC3B,IAAI,EAAE,YAAY;IAClB,OAAO,EAAE,OAAO;CACjB,CAAC,CAAC;AAEH,KAAK,UAAU,IAAI;IACjB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC;AAED,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC,GAAG,EAAE,EAAE;IACnB,OAAO,CAAC,KAAK,CAAC,2BAA2B,GAAG,EAAE,CAAC,CAAC;IAChD,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AAEjF,+DAA+D;AAC/D,wEAAwE;AACxE,0CAA0C;AAC1C,+DAA+D;AAC/D,uEAAuE;AACvE,4EAA4E;AAC5E,0EAA0E;AAC1E,6EAA6E;AAC7E,qDAAqD;AAErD,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;IAC3B,IAAI,EAAE,YAAY;IAClB,OAAO,EAAE,OAAO;CACjB,CAAC,CAAC;AAEH,KAAK,UAAU,IAAI;IACjB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC;AAED,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC,GAAG,EAAE,EAAE;IACnB,OAAO,CAAC,KAAK,CAAC,2BAA2B,GAAG,EAAE,CAAC,CAAC;IAChD,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}

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

@@ -33,6 +33,8 @@ If the site captures form data, add the `[[d1_databases]]` binding from `d1-data
 
 ## 3. Load the reused deploy token
 
+> **On a multi-tenant install, a client account does not run this step at all.** After the 1631 storage isolation, a client's `cloudflare.env` carries no master, and `cf-token.sh` denies it the `pages` scope (`reason=not-house`) — correctly, since that master is account-wide. A client account publishes with the `storage-pages-deploy` tool, which runs the deploy house-side; the project must already be recorded to the account by the house (`storage-pages-adopt`), because the project-to-folder mapping is not derivable and is never guessed. The rest of this section applies to the **house account and single-tenant installs**, where the master still lives in the account secrets file. If you are a client account and you reached a `not-house` denial here, that is this branch, not a broken token: use the tool.
+
 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`). The `pages` scope resolves the stable `<brand>-pages-d1` token, which carries both. Resolve it with the deterministic helper, which mints it once only if absent and reuses it thereafter. This is the one command; do not source the secrets file and hand the resulting `CLOUDFLARE_API_TOKEN` to `wrangler` — that variable holds the **master**, not the per-scope token, and `wrangler pages` then returns `Authentication error [code: 10000]`:
 
 ```bash

package/payload/platform/plugins/cloudflare/skills/calendar-site/SKILL.md

@@ -56,7 +56,7 @@ The booking-specific schema ships with the template: `schema.sql` creates both t
 
 ## Deploy through site-deploy
 
-Hand the assembled tree to `cloudflare:site-deploy`: it builds nothing for a static tree, runs `wrangler pages deploy public --project-name <project> --branch=main`, attaches the booking domain (creating the DNS record with the `<brand>-dns` token when the attach leaves validation pending), and reuses the same per-scope token. Everything in `site-deploy`'s auth, custom-domain, and DNS guidance applies unchanged.
+Hand the assembled tree to `cloudflare:site-deploy`: it builds nothing for a static tree, runs `wrangler pages deploy public --project-name <project> --branch=main`, attaches the booking domain (creating the DNS record with the `<brand>-dns` token when the attach leaves validation pending), and reuses the same per-scope token. Everything in `site-deploy`'s auth, custom-domain, and DNS guidance applies unchanged — including its multi-tenant branch: "admin-run" means a `role:"admin"` session, which on a multi-tenant install is **not** the same thing as the house. A client account's admin session is denied the `pages` scope (`reason=not-house`) and publishes with `storage-pages-deploy` instead.
 
 ## Done-gate
 

package/payload/platform/plugins/cloudflare/skills/site-deploy/SKILL.md

@@ -33,6 +33,8 @@ There is never a `sites/<brand>/` versus `output/<brand>-site/` pair, a `.bak` c
 
 ## Auth: reuse the per-scope token, never mint ad hoc
 
+> **Client accounts on a multi-tenant install do not use this section.** Post-1631 their secrets carry no master and `cf-token.sh` denies them the `pages` scope (`reason=not-house`). They publish with `storage-pages-deploy`, which deploys house-side against a project the house has recorded to them (`storage-pages-adopt`). A `not-house` denial here is that boundary working, not a token fault — do not try to mint around it. Everything below is the **house/single-tenant** path.
+
 Resolve the Pages-and-D1 token with the deterministic helper **before** any token `curl`, never a hand-built one:
 
 ```bash