@rubytech/create-sitedesk-code 0.1.512 → 0.1.514

package/payload/platform/docs/superpowers/specs/2026-07-27-task-2028-declared-file-write-deny-design.md

@@ -0,0 +1,127 @@
+# Task 2028 — the write guard tells a declared file from an operator bucket
+
+Design, 2026-07-27. Lane: Platform / account schema · write guard.
+
+## The fault
+
+`fs-schema-guard.sh` is the PreToolUse guard for `Write`, `Edit` and `NotebookEdit`.
+It parses the account's ```` ```allowed-top-level ```` fence and blocks a write whose
+first path segment is absent from it. The standing reconcile parses the same fence
+to decide what is not a stray. One list, two meanings.
+
+Task 1902 declared eight control-plane files so the reconcile would stop naming
+them. Because names union into that one fence, the guard began allowing
+agent writes to them: measured, the same envelope returns exit 2 against the
+pre-merge schema and exit 0 against the merged one for `wa-channel-bindings.json`,
+`telegram-channel-bindings.json`, `webchat-channel-bindings.json`,
+`canonical-webchat-session.json`, `session-titles.json`, `agents-disabled.json`,
+`calendar-availability.json` and `data-portal.json`.
+
+The fence already permits `account.json`, `SCHEMA.md`, `secrets/` and `.claude/` on
+the untouched shipped template, so it is a layout guard, not a trust boundary. This
+task makes the guard enforce the intent the generated region already states: a
+declared file "is written whole by its owner. Neither is operator data."
+
+## Design
+
+### 1. A second fence, emitted by the merge
+
+`account-schema-owned-dirs.py` `merge()` gains a third generated region, written
+with the same strip-then-append shape as the two that exist, so a re-merge is
+idempotent:
+
+```
+<!-- declared-files:start -->
+## Declared files (written by platform code, owned by a plugin)
+
+...one paragraph of prose...
+
+```declared-files
+webchat-channel-bindings.json	admin
+wa-channel-bindings.json	admin
+data-portal.json	cloudflare
+```
+<!-- declared-files:end -->
+```
+
+One line per platform-written declared file, in `resolve()` order, as
+`name<TAB>owning-plugin`. The region is emitted only when at least one such file
+is declared.
+
+**Two of the eight declared files are agent-written, and are excluded.** The
+review established that `calendar-availability.json` and `data-portal.json` have
+no writer in platform code: `publish-availability.ts:151` and
+`portal-index-push.mjs:52,380` only read them, and the `calendar-site` and
+`data-portal` skills instruct the agent to author them with `Write`
+("there is no separate editor"). Denying them would break the only path that
+creates them. A file declaration may therefore carry `"writtenBy": "agent"`,
+which keeps the name in `allowed-top-level` (so the reconcile still never calls
+it a stray) and out of the declared-files fence (so the guard never denies it).
+The two declarations gain that key, and their descriptions are corrected: both
+named a writer that only reads.
+
+The owner column names the *declaring* plugin, which is where the declaration
+lives rather than necessarily the module that writes the file — Task 1902 moved
+declarations onto plugins no brand excludes for reach, so a shared service may
+write a file declared on `admin`. The block message therefore points at the
+owning code and does not promise a plugin tool. `allowed-top-level` is
+not touched, so the reconcile keeps reading exactly what it reads today, and the two
+existing region readers (`platform/lib/account-schema-regions`, the cloudflare
+`schema-exposed-dirs.mjs` copy) both anchor on their own markers and on the
+`allowed-top-level` fence by name, so an appended region is invisible to them.
+
+The owning-plugin column exists because the block message has to name the owner,
+and the descriptive region carries the plugin's own description, not its name.
+
+### 2. The guard denies
+
+`fs-schema-guard.sh` parses the new fence with one awk expression, the same shape it
+already uses for the allowed set. After the top-level check passes and before the
+depth check, a target whose first path segment matches a declared name is blocked:
+
+```
+[fs-guard] blocked path=<rel> reason=declared-file
+```
+
+plus an operator-visible line naming the owning plugin and pointing the agent at it.
+An account whose SCHEMA.md carries no `declared-files` fence denies nothing, which is
+the same fail-open posture the guard already takes on a missing or empty schema.
+
+The match is on the first path segment, not on the whole relative path, so a write to
+`wa-channel-bindings.json/anything` is blocked for the same reason.
+
+### 3. The Bash post-hook stays quiet
+
+A Bash command that creates a declared file emits no stray feedback. That is the
+behaviour Task 1902 produced and it is kept deliberately, not inherited: the post
+hook fires only on a name that appeared during the command, and a declared file
+already exists on any live account, so a Bash edit to one is invisible there
+regardless of the allowed set. A signal that catches only the first creation and
+misses every subsequent edit is not a boundary. The decision is written into the
+hook's header comment and pinned by a test, so a future edit has to argue with it
+rather than flip it silently.
+
+## Testing
+
+- `fs-schema-guard.test.sh`: one case per declared file asserting exit 2 with
+  `reason=declared-file` and the owner name in the message; an operator bucket write
+  under the same schema asserting exit 0; a declared name under an account that
+  carries it in `allowed-top-level` but has no `declared-files` fence asserting
+  exit 0, which pins the deny to the fence rather than to a list baked into the
+  hook.
+- `fs-schema-guard-bash.test.sh`: a Bash command that creates a declared file
+  asserting exit 0 and no `[fs-guard-bash]` line.
+- `account-schema-owned-dirs.test.sh`: the merge emits the fence with
+  `name<TAB>plugin` for each declared file, emits nothing when no file is declared,
+  and a second merge leaves the file byte-identical.
+- Mutation check: remove the guard's deny branch and confirm the per-file cases fail.
+- The reconcile's own suite still reports no declared file as a stray.
+
+## Out of scope
+
+- The fence's pre-existing permissiveness for `account.json`, `secrets/` and
+  `.claude/`. It predates Task 1902 and is a separate decision, filed as
+  `.tasks/archive/2052-the-allowed-fence-permits-agent-writes-to-the-account-s-own-machinery.md`
+  (renumbered from 2048; landed 2026-07-27).
+- The reconcile. It reads the fence correctly and needs no change.
+- Adding or removing declarations. Task 1902 settled the set.

package/payload/platform/docs/superpowers/specs/2026-07-27-task-2052-account-machinery-write-fence-design.md

@@ -0,0 +1,150 @@
+# Task 2052 — the write guard denies the account's own machinery
+
+Design, 2026-07-27. Lane: Platform / account schema · write guard.
+
+## The fault
+
+`fs-schema-guard.sh` allows a `Write`, `Edit` or `NotebookEdit` whose first path
+segment is in the account's ```` ```allowed-top-level ```` fence. The shipped
+template lists `account.json`, `SCHEMA.md`, `secrets/`, `.claude/` and `.git`, so
+each is agent-writable. Measured against the untouched shipped template, an
+envelope targeting `account.json` returns exit 0.
+
+None of the five is operator data:
+
+- `account.json` carries the account identity, role, tier and enabled plugins.
+  `admin-user-management/SKILL.md:39` states the position already: "Direct `Edit`
+  or `Write` on `account.json` is forbidden by IDENTITY.md doctrine — there is no
+  server-side gate, so the doctrine line is the only thing standing between an
+  agent slip and a silently corrupted account file." Mutations have dedicated
+  tools (`account-update`, `plugin-toggle-enabled`, `admin-add`, `admin-remove`).
+- `SCHEMA.md` is the schema the guard itself parses. A write to it widens the
+  fence the guard reads on the next call.
+- `.claude/` holds the account's project-level `settings.json`, which is where
+  `provision-account-dir.sh:62,77-143` registers this guard and both Bash hooks. A
+  write to it can delete the guard's own registration.
+- `secrets/` holds provisioned credentials.
+- `.git` is the account directory's git repository, created at
+  `provision-account-dir.sh:59` so Claude Code discovers `.claude/`.
+
+## Decision per name
+
+All five are denied to the agent's write tools. No legitimate agent
+`Write`/`Edit`/`NotebookEdit` path exists for any of them:
+
+| Name | Who writes it |
+|---|---|
+| `account.json` | `provision-account-dir.sh:310-349` and the account MCP tools |
+| `SCHEMA.md` | `provision-account-dir.sh:40-41` and the owned-dirs merge |
+| `secrets/` | the code that mints each credential; the one skill-instructed path is a Bash append (`cloudflare/skills/data-portal/SKILL.md:161`), which this guard never sees |
+| `.claude/` | `provision-account-dir.sh:26,61-143` |
+| `.git` | git itself |
+
+## Design
+
+### 1. A third fence, shipped in the template
+
+`platform/templates/account-schema/SCHEMA.md` gains a fenced block below the
+allowed-top-level section:
+
+````
+```agent-denied-top-level
+account.json	the account's identity and settings, changed through the account and admin tools
+SCHEMA.md	the schema this guard reads, so a hand edit widens the guard's own fence
+secrets	provisioned credentials, written by the code that mints each one
+.claude	the agent's own settings and hooks, seeded when the account is provisioned
+.git	the account directory's git internals
+```
+````
+
+One line per name as `name<TAB>reason`, the same shape as the `declared-files`
+fence. The reason column exists because there is no owning plugin to name here,
+so the block message needs the schema to supply its own explanation.
+
+The block is authored in the template rather than generated. The owned-dirs merge
+(`account-schema-owned-dirs.py`) rewrites only its three marker-delimited regions
+and the `allowed-top-level` fence in place, so a fence in the template body
+survives a re-merge untouched. `allowed-top-level` is not modified, so the
+standing reconcile keeps reading exactly what it reads today and still never
+names any of the five as a stray — the one-list-two-meanings fault Task 2028
+fixed is not reintroduced.
+
+### 2. The guard denies
+
+`fs-schema-guard.sh` parses the new fence with one awk expression, the same shape
+it uses for the other two. The check sits after the top-level check and before
+the declared-file check, and matches on the first path segment, so
+`.claude/settings.json` and `secrets/cloudflare.env` are both blocked. No name is
+in both fences (the declared set is the six platform-written `*.json` files the
+merge emits), so the ordering never changes which reason is reported.
+
+```
+[fs-guard] blocked path=<rel> reason=account-machinery
+```
+
+The operator-visible line names the segment and carries that name's reason from
+the fence, then points at the code that owns it. No task numbers or internal refs
+appear in it, per the guard's existing rule.
+
+An account whose `SCHEMA.md` carries no `agent-denied-top-level` fence denies
+nothing. That is the same fail-open posture the guard already takes on a missing
+schema and on a missing `declared-files` fence.
+
+Which accounts lack it is not uniform, and the split matters. The fence lives in
+the template body, and only `provision_account_dir` copies that body
+(`provision-account-dir.sh:40-41`, an unconditional `cp` of the whole template).
+`setup-account.sh:59` calls it once, for the house account. The standing
+all-accounts reconcile merges only the marker-delimited regions. So the house
+account gains the fence on the next install, and a client sub-account, which is
+provisioned once at creation, keeps a fence-less schema indefinitely. Closing
+that is filed as `.tasks/pending/2056-the-account-machinery-deny-fence-never-reaches-an-existing-sub-account.md`,
+following the durable-backfill pattern Task 1683 and Task 1929 already
+established in `setup-account.sh`.
+
+### 3. Provision and reconcile are unaffected
+
+Both write `SCHEMA.md` and `account.json`, and neither goes through the agent's
+write tools: provisioning is bash (`provision-account-dir.sh`) and the standing
+reconcile is Node (`account-dir-schema-reconcile.ts`). The guard is a PreToolUse
+hook on `Write`/`Edit`/`NotebookEdit` only, so it never sees either writer.
+
+### 4. The Bash post-hook stays unchanged
+
+`fs-schema-guard-bash-post.sh` reads `allowed-top-level` and the `declared-files`
+fence. This change touches neither, and all five names stay in `allowed-top-level`,
+so the post hook keeps not flagging them. That is the deliberate choice, not an
+inherited one: the post hook fires only on a top-level name that appeared during
+the command, and `account.json`, `SCHEMA.md`, `.claude` and `.git` all exist from
+provision onward, so a signal there would catch nothing on a live account.
+
+## Testing
+
+`fs-schema-guard.test.sh` gains:
+
+- one case per name asserting exit 2 with `reason=account-machinery` and that
+  name's reason text present in the message;
+- a nested case for `.claude/settings.json` and `secrets/cloudflare.env`
+  asserting exit 2, pinning the segment-0 match;
+- an operator bucket write under the same schema asserting exit 0;
+- a case under a schema that lists the five in `allowed-top-level` but carries no
+  `agent-denied-top-level` fence asserting exit 0, which pins the deny to the
+  fence rather than to a list baked into the hook;
+- the existing template-parity assertion extended so the shipped fence contents
+  are pinned.
+
+Mutation check: remove the deny branch and confirm the per-name cases fail.
+Revert.
+
+The reconcile suite and `fs-schema-guard-bash.test.sh` must both still pass
+unchanged, which is the evidence that `allowed-top-level` was not disturbed.
+
+## Out of scope
+
+- The `declared-files` fence and the plugin-declaration mechanism. Task 2028
+  settled both.
+- `.quarantine`, which is historical and already documented as never authored
+  into directly.
+- `AGENTS.md`, which is in the allowed fence but outside the five names this task
+  names. The same overwritten-on-provision rationale may apply to it; that
+  decision is filed as
+  `.tasks/backlog/2057-agents-md-is-refreshed-every-provision-but-stays-agent-writable.md`.

package/payload/platform/lib/account-schema-regions/dist/index.d.ts

@@ -15,6 +15,11 @@
  *   ontology roots:  - `jobs/` - one folder per Job record.      (ASCII hyphen)
  *   plugin-owned:    - `pages/` — Owned by the … plugin.         (em dash)
  *
+ * merge() writes a fourth structure, the ```declared-files fence, which is not
+ * parsed here: its only reader is the write guard (fs-schema-guard.sh), which
+ * needs the declared-FILE set apart from the bucket set. Both consumers of this
+ * module group and audit directories, so the fence is deliberately out of scope.
+ *
  * .docs/data-portal-folder-index.md records that parsing the ontology region on
  * the wrong separator matches nothing and reads as "this account has no
  * deliverables". This parser sidesteps that failure entirely by anchoring on the

package/payload/platform/lib/account-schema-regions/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,eAAO,MAAM,UAAU,EAAE,SAAS,MAAM,EAEtC,CAAA;AAiBF,MAAM,WAAW,aAAa;IAC5B,0EAA0E;IAC1E,aAAa,EAAE,MAAM,EAAE,CAAA;IACvB,iEAAiE;IACjE,WAAW,EAAE,MAAM,EAAE,CAAA;IACrB,gEAAgE;IAChE,eAAe,EAAE,MAAM,EAAE,CAAA;IACzB;;;;;;;OAOG;IACH,MAAM,EAAE,OAAO,CAAA;IACf;;;;OAIG;IACH,MAAM,EAAE,IAAI,GAAG,eAAe,GAAG,cAAc,CAAA;CAChD;AAiCD,wBAAgB,kBAAkB,CAAC,QAAQ,EAAE,MAAM,GAAG,IAAI,GAAG,aAAa,CAazE"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AAEH;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,eAAO,MAAM,UAAU,EAAE,SAAS,MAAM,EAEtC,CAAA;AAiBF,MAAM,WAAW,aAAa;IAC5B,0EAA0E;IAC1E,aAAa,EAAE,MAAM,EAAE,CAAA;IACvB,iEAAiE;IACjE,WAAW,EAAE,MAAM,EAAE,CAAA;IACrB,gEAAgE;IAChE,eAAe,EAAE,MAAM,EAAE,CAAA;IACzB;;;;;;;OAOG;IACH,MAAM,EAAE,OAAO,CAAA;IACf;;;;OAIG;IACH,MAAM,EAAE,IAAI,GAAG,eAAe,GAAG,cAAc,CAAA;CAChD;AAiCD,wBAAgB,kBAAkB,CAAC,QAAQ,EAAE,MAAM,GAAG,IAAI,GAAG,aAAa,CAazE"}

package/payload/platform/lib/account-schema-regions/dist/index.js

@@ -16,6 +16,11 @@
  *   ontology roots:  - `jobs/` - one folder per Job record.      (ASCII hyphen)
  *   plugin-owned:    - `pages/` — Owned by the … plugin.         (em dash)
  *
+ * merge() writes a fourth structure, the ```declared-files fence, which is not
+ * parsed here: its only reader is the write guard (fs-schema-guard.sh), which
+ * needs the declared-FILE set apart from the bucket set. Both consumers of this
+ * module group and audit directories, so the fence is deliberately out of scope.
+ *
  * .docs/data-portal-folder-index.md records that parsing the ontology region on
  * the wrong separator matches nothing and reads as "this account has no
  * deliverables". This parser sidesteps that failure entirely by anchoring on the

package/payload/platform/lib/account-schema-regions/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;;;AAmGH,gDAaC;AA9GD;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACU,QAAA,UAAU,GAAsB,MAAM,CAAC,MAAM,CAAC;IACzD,UAAU,EAAE,UAAU,EAAE,WAAW,EAAE,QAAQ,EAAE,WAAW,EAAE,WAAW,EAAE,OAAO,EAAE,SAAS;CAC5F,CAAC,CAAA;AAEF,MAAM,SAAS,GAAG,iCAAiC,CAAA;AACnD,MAAM,OAAO,GAAG,+BAA+B,CAAA;AAC/C,MAAM,YAAY,GAAG,kCAAkC,CAAA;AACvD,MAAM,UAAU,GAAG,gCAAgC,CAAA;AACnD,MAAM,aAAa,GAAG,sBAAsB,CAAA;AAE5C;;;;;;GAMG;AACH,MAAM,QAAQ,GAAG,mBAAmB,CAAA;AA0BpC,SAAS,WAAW,CAAC,IAAY,EAAE,KAAa,EAAE,GAAW;IAC3D,MAAM,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,CAAC,CAAA;IAChC,IAAI,IAAI,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IAC1B,MAAM,EAAE,GAAG,IAAI,CAAC,OAAO,CAAC,GAAG,EAAE,IAAI,CAAC,CAAA;IAClC,IAAI,EAAE,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IACxB,OAAO,IAAI,CAAC,KAAK,CAAC,IAAI,GAAG,KAAK,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,CAAA;AACxD,CAAC;AAED,SAAS,MAAM,CAAC,KAAe;IAC7B,MAAM,GAAG,GAAa,EAAE,CAAA;IACxB,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;QACzB,MAAM,CAAC,GAAG,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,CAAC,CAAA;QACpC,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;YAAE,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;IAC9C,CAAC;IACD,OAAO,GAAG,CAAA;AACZ,CAAC;AAED,SAAS,YAAY,CAAC,IAAY;IAChC,MAAM,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,CAAA;IACxC,IAAI,IAAI,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IAC1B,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,IAAI,EAAE,IAAI,CAAC,CAAA;IAC1C,IAAI,SAAS,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IAC/B,MAAM,EAAE,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,SAAS,CAAC,CAAA;IACzC,IAAI,EAAE,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IACxB,OAAO,IAAI;SACR,KAAK,CAAC,SAAS,GAAG,CAAC,EAAE,EAAE,CAAC;SACxB,KAAK,CAAC,IAAI,CAAC;SACX,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;SACpB,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAA;AAChC,CAAC;AAED,SAAgB,kBAAkB,CAAC,QAAuB;IACxD,IAAI,QAAQ,KAAK,IAAI,IAAI,QAAQ,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC/C,OAAO,EAAE,aAAa,EAAE,EAAE,EAAE,WAAW,EAAE,EAAE,EAAE,eAAe,EAAE,EAAE,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,EAAE,eAAe,EAAE,CAAA;IAC5G,CAAC;IACD,MAAM,eAAe,GAAG,YAAY,CAAC,QAAQ,CAAC,CAAA;IAC9C,MAAM,MAAM,GAAG,eAAe,CAAC,MAAM,GAAG,CAAC,CAAA;IACzC,OAAO;QACL,aAAa,EAAE,MAAM,CAAC,WAAW,CAAC,QAAQ,EAAE,SAAS,EAAE,OAAO,CAAC,CAAC;QAChE,WAAW,EAAE,MAAM,CAAC,WAAW,CAAC,QAAQ,EAAE,YAAY,EAAE,UAAU,CAAC,CAAC;QACpE,eAAe;QACf,MAAM;QACN,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,cAAc;KACvC,CAAA;AACH,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;;;AAmGH,gDAaC;AA9GD;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACU,QAAA,UAAU,GAAsB,MAAM,CAAC,MAAM,CAAC;IACzD,UAAU,EAAE,UAAU,EAAE,WAAW,EAAE,QAAQ,EAAE,WAAW,EAAE,WAAW,EAAE,OAAO,EAAE,SAAS;CAC5F,CAAC,CAAA;AAEF,MAAM,SAAS,GAAG,iCAAiC,CAAA;AACnD,MAAM,OAAO,GAAG,+BAA+B,CAAA;AAC/C,MAAM,YAAY,GAAG,kCAAkC,CAAA;AACvD,MAAM,UAAU,GAAG,gCAAgC,CAAA;AACnD,MAAM,aAAa,GAAG,sBAAsB,CAAA;AAE5C;;;;;;GAMG;AACH,MAAM,QAAQ,GAAG,mBAAmB,CAAA;AA0BpC,SAAS,WAAW,CAAC,IAAY,EAAE,KAAa,EAAE,GAAW;IAC3D,MAAM,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,CAAC,CAAA;IAChC,IAAI,IAAI,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IAC1B,MAAM,EAAE,GAAG,IAAI,CAAC,OAAO,CAAC,GAAG,EAAE,IAAI,CAAC,CAAA;IAClC,IAAI,EAAE,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IACxB,OAAO,IAAI,CAAC,KAAK,CAAC,IAAI,GAAG,KAAK,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,CAAA;AACxD,CAAC;AAED,SAAS,MAAM,CAAC,KAAe;IAC7B,MAAM,GAAG,GAAa,EAAE,CAAA;IACxB,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;QACzB,MAAM,CAAC,GAAG,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,CAAC,CAAA;QACpC,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;YAAE,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;IAC9C,CAAC;IACD,OAAO,GAAG,CAAA;AACZ,CAAC;AAED,SAAS,YAAY,CAAC,IAAY;IAChC,MAAM,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,CAAA;IACxC,IAAI,IAAI,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IAC1B,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,IAAI,EAAE,IAAI,CAAC,CAAA;IAC1C,IAAI,SAAS,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IAC/B,MAAM,EAAE,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,SAAS,CAAC,CAAA;IACzC,IAAI,EAAE,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,CAAA;IACxB,OAAO,IAAI;SACR,KAAK,CAAC,SAAS,GAAG,CAAC,EAAE,EAAE,CAAC;SACxB,KAAK,CAAC,IAAI,CAAC;SACX,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;SACpB,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAA;AAChC,CAAC;AAED,SAAgB,kBAAkB,CAAC,QAAuB;IACxD,IAAI,QAAQ,KAAK,IAAI,IAAI,QAAQ,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC/C,OAAO,EAAE,aAAa,EAAE,EAAE,EAAE,WAAW,EAAE,EAAE,EAAE,eAAe,EAAE,EAAE,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,EAAE,eAAe,EAAE,CAAA;IAC5G,CAAC;IACD,MAAM,eAAe,GAAG,YAAY,CAAC,QAAQ,CAAC,CAAA;IAC9C,MAAM,MAAM,GAAG,eAAe,CAAC,MAAM,GAAG,CAAC,CAAA;IACzC,OAAO;QACL,aAAa,EAAE,MAAM,CAAC,WAAW,CAAC,QAAQ,EAAE,SAAS,EAAE,OAAO,CAAC,CAAC;QAChE,WAAW,EAAE,MAAM,CAAC,WAAW,CAAC,QAAQ,EAAE,YAAY,EAAE,UAAU,CAAC,CAAC;QACpE,eAAe;QACf,MAAM;QACN,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,cAAc;KACvC,CAAA;AACH,CAAC"}

package/payload/platform/lib/account-schema-regions/src/index.ts

@@ -15,6 +15,11 @@
  *   ontology roots:  - `jobs/` - one folder per Job record.      (ASCII hyphen)
  *   plugin-owned:    - `pages/` — Owned by the … plugin.         (em dash)
  *
+ * merge() writes a fourth structure, the ```declared-files fence, which is not
+ * parsed here: its only reader is the write guard (fs-schema-guard.sh), which
+ * needs the declared-FILE set apart from the bucket set. Both consumers of this
+ * module group and audit directories, so the fence is deliberately out of scope.
+ *
  * .docs/data-portal-folder-index.md records that parsing the ontology region on
  * the wrong separator matches nothing and reads as "this account has no
  * deliverables". This parser sidesteps that failure entirely by anchoring on the

package/payload/platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh

@@ -154,6 +154,20 @@ mkdir -p "$K/contacts/acme"; : > "$K/contacts/.DS_Store"
 run_post "$K" "$(env_json PostToolUse Bash "$SID")" "$ef"
 check "post ignores dot-prefixed new-bucket child" 0 $? "" "$(cat "$ef")"
 
+# --- 14. Bash creating a plugin-declared file -> silent, by decision ---------
+# A declared file is in the allowed set, so the diff never flags it. That is
+# deliberate, not inherited: this hook fires only on a name that APPEARED during
+# the command, and a declared file already exists on any live account, so a Bash
+# edit to one is invisible here regardless. Catching only the first creation and
+# missing every edit is not a boundary. The Write/Edit guard blocks the writes it
+# can actually identify; this hook stays quiet. This case pins the silence.
+L=$(new_acct)
+awk '1; /^```allowed-top-level$/{print "wa-channel-bindings.json"}' "$L/SCHEMA.md" > "$L/SCHEMA.md.tmp" && mv "$L/SCHEMA.md.tmp" "$L/SCHEMA.md"
+run_pre "$L" "$(env_json PreToolUse Bash "$SID")" "$ef"
+printf '{}' > "$L/wa-channel-bindings.json"
+run_post "$L" "$(env_json PostToolUse Bash "$SID")" "$ef"
+check "post silent on declared file" 0 $? "" "$(cat "$ef")"
+
 rm -f "$ef"
 echo "----- $PASS passed, $FAIL failed -----"
 [ $FAIL -eq 0 ]

package/payload/platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh

@@ -87,11 +87,90 @@ run_case "domain bucket deep allow" "$(mkenv Write file_path 'jobs/5-oaktree/Quo
 run_case "domain bucket file allow"  "$(mkenv Write file_path 'jobs/5-oaktree/notes.md')"           0 "" "$ACCT_D"
 run_case "undeclared still blocks"   "$(mkenv Write file_path 'invoices/x.pdf')"                     2 "reason=top-level" "$ACCT_D"
 
+# Declared files: a plugin-declared account-root file is written whole by its
+# owner, so an agent write to it blocks even though the merge unions its name
+# into the allowed set. $ACCT_F models a merged schema (names in the allowed set
+# AND in the declared-files fence); $ACCT_L models the state before this guard
+# existed (names in the allowed set, no fence), which pins the deny to the fence
+# rather than to a list baked into the hook.
+DECLARED_FILES="webchat-channel-bindings.json wa-channel-bindings.json telegram-channel-bindings.json canonical-webchat-session.json session-titles.json agents-disabled.json"
+# Declared but AGENT-written: the calendar-site and data-portal skills author
+# these two with Write and there is no other writer, so they are in the allowed
+# set (and out of the reconcile's stray report) but never in the deny fence.
+AGENT_WRITTEN_FILES="data-portal.json calendar-availability.json"
+owner_of() { echo admin; }
+seed_declared() { # $1=acct  $2=emit fence (yes|no)
+  cp "$TEMPLATE" "$1/SCHEMA.md"
+  for f in $DECLARED_FILES $AGENT_WRITTEN_FILES; do
+    awk -v n="$f" '1; /^```allowed-top-level$/{print n}' "$1/SCHEMA.md" > "$1/SCHEMA.md.tmp" && mv "$1/SCHEMA.md.tmp" "$1/SCHEMA.md"
+  done
+  [ "$2" = "yes" ] || return 0
+  { echo; echo '<!-- declared-files:start -->'; echo '```declared-files'
+    for f in $DECLARED_FILES; do printf '%s\t%s\n' "$f" "$(owner_of "$f")"; done
+    echo '```'; echo '<!-- declared-files:end -->'; } >> "$1/SCHEMA.md"
+}
+ACCT_F=$(mktemp -d); ACCT_L=$(mktemp -d)
+trap 'rm -rf "$ACCT" "$ACCT_D" "$ACCT_F" "$ACCT_L"' EXIT
+seed_declared "$ACCT_F" yes
+seed_declared "$ACCT_L" no
+mkdir -p "$ACCT_F/projects/acme"
+for f in $DECLARED_FILES; do
+  run_case "declared block $f" "$(mkenv Write file_path "$f")" 2 "fs-guard. blocked path=$f reason=declared-file" "$ACCT_F"
+  run_case "declared owner $f" "$(mkenv Write file_path "$f")" 2 "$(owner_of "$f") plugin"                        "$ACCT_F"
+done
+for f in $AGENT_WRITTEN_FILES; do
+  run_case "agent-written allow $f" "$(mkenv Write file_path "$f")" 0 "" "$ACCT_F"
+done
+run_case "declared edit blocks"   "$(mkenv Edit file_path 'wa-channel-bindings.json')"  2 "reason=declared-file" "$ACCT_F"
+run_case "operator bucket allow"  "$(mkenv Write file_path 'projects/acme/a.txt')"      0 ""                     "$ACCT_F"
+run_case "no fence no deny"       "$(mkenv Write file_path 'wa-channel-bindings.json')" 0 ""                     "$ACCT_L"
+
+# Account machinery: five entries in the allowed set are the account's own
+# control plane, denied by name in the agent-denied-top-level fence. $ACCT is
+# the pristine template copy, so it carries the fence. $ACCT_M models a schema
+# written before the fence existed (names in the allowed set, fence stripped),
+# which pins the deny to the fence rather than to a list baked into the hook.
+ACCT_M=$(mktemp -d)
+trap 'rm -rf "$ACCT" "$ACCT_D" "$ACCT_F" "$ACCT_L" "$ACCT_M"' EXIT
+awk '/^```agent-denied-top-level$/{skip=1;next} skip && /^```$/{skip=0;next} !skip' "$TEMPLATE" > "$ACCT_M/SCHEMA.md"
+
+DENIED_NAMES="account.json SCHEMA.md secrets .claude .git"
+for n in $DENIED_NAMES; do
+  run_case "machinery block $n" "$(mkenv Write file_path "$n")" 2 "fs-guard. blocked path=$n reason=account-machinery"
+done
+# Segment-0 match: a nested path under a denied entry blocks for the same reason.
+run_case "machinery nested settings" "$(mkenv Write file_path '.claude/settings.json')"      2 "fs-guard. blocked path=.claude/settings.json reason=account-machinery"
+run_case "machinery nested secret"   "$(mkenv Write file_path 'secrets/cloudflare.env')"     2 "reason=account-machinery"
+# Every write tool, not just Write.
+run_case "machinery edit blocks"     "$(mkenv Edit file_path 'account.json')"                2 "reason=account-machinery"
+run_case "machinery notebook blocks" "$(mkenv NotebookEdit notebook_path '.claude/n.ipynb')" 2 "reason=account-machinery"
+# The schema's own reason reaches the operator-visible message.
+run_case "machinery reason text"     "$(mkenv Write file_path 'SCHEMA.md')"                  2 "widens its own fence"
+# An operator bucket under the same schema is unaffected.
+run_case "machinery bucket allow"    "$(mkenv Write file_path 'projects/acme/a.txt')"        0 ""
+# No fence, no deny.
+for n in $DENIED_NAMES; do
+  run_case "no deny fence allows $n" "$(mkenv Write file_path "$n")" 0 "" "$ACCT_M"
+done
+
 # Allowed-set parse == documented set.
 EXPECT="projects contacts documents url-get output generated extracted uploads agents specialists sites public cache secrets state logs tmp .quarantine SCHEMA.md account.json AGENTS.md .claude .git"
 GOT=$(awk '/^```allowed-top-level$/{f=1;next} /^```$/{f=0} f' "$ACCT/SCHEMA.md" | tr '\n' ' ' | sed 's/ *$//')
 if [ "$GOT" = "$EXPECT" ]; then echo "PASS: allowed-set parse"; PASS=$((PASS+1));
 else echo "FAIL: allowed-set parse: got [$GOT]" >&2; FAIL=$((FAIL+1)); fi
 
+# Deny-fence parse == documented set. The guard reads this fence, so pinning its
+# contents here means a name cannot be added or dropped without a test edit.
+EXPECT_D="account.json SCHEMA.md secrets .claude .git"
+GOT_D=$(awk '/^```agent-denied-top-level$/{f=1;next} /^```$/{f=0} f' "$ACCT/SCHEMA.md" | cut -f1 | tr '\n' ' ' | sed 's/ *$//')
+if [ "$GOT_D" = "$EXPECT_D" ]; then echo "PASS: deny-set parse"; PASS=$((PASS+1));
+else echo "FAIL: deny-set parse: got [$GOT_D]" >&2; FAIL=$((FAIL+1)); fi
+
+# Every deny entry carries a reason column: the block message has no owning
+# plugin to name, so the schema must supply the explanation.
+NOREASON=$(awk '/^```agent-denied-top-level$/{f=1;next} /^```$/{f=0} f' "$ACCT/SCHEMA.md" | awk -F'\t' 'NF<2 || $2==""{print $1}')
+if [ -z "$NOREASON" ]; then echo "PASS: deny-set reasons"; PASS=$((PASS+1));
+else echo "FAIL: deny-set reasons missing for [$NOREASON]" >&2; FAIL=$((FAIL+1)); fi
+
 echo "----- $PASS passed, $FAIL failed -----"
 [ $FAIL -eq 0 ]

package/payload/platform/plugins/admin/hooks/fs-schema-guard-bash-post.sh

@@ -17,6 +17,25 @@
 # Diffing against the pre-snapshot (not flagging every non-allowed entry) is what
 # keeps the hook from firing on the legacy backlog on every unrelated Bash call.
 #
+# A plugin-declared file (a name a plugin claims as its own in its PLUGIN.md) is
+# in the allowed set, so this hook never flags one. That silence is a decision,
+# not an accident. This hook fires only on a name that APPEARED during the
+# command: a declared file already exists on any live account, so a Bash edit to
+# one is invisible here no matter what the allowed set says. A signal that catches
+# only the first creation and misses every subsequent edit is not a boundary, and
+# paying for it in feedback noise buys nothing. The Write/Edit guard
+# (fs-schema-guard.sh) blocks the writes it can actually identify, on the
+# declared-files fence; this hook stays quiet, and a case in the test suite pins
+# the silence.
+#
+# The same reasoning covers the ```agent-denied-top-level fence, and for the same
+# reason it needs no code here: those five names are in the allowed set too, and
+# account.json, SCHEMA.md, .claude and .git all exist from provision onward, so
+# they can never APPEAR during a command on a live account. secrets/ can appear
+# once, and is deliberately left alone — the data-portal skill creates it with a
+# shell redirect as its sanctioned path, so flagging that first creation would
+# fire on the one legitimate writer and stay blind to every edit after it.
+#
 # Exit codes: 0 = allow, 2 = feedback to the agent (stderr shown). Fail open
 # (exit 0) when the snapshot is missing or the allowed set is empty. Every block
 # logs: [fs-guard-bash] stray path=<name> reason=<top-level|bad-name>

package/payload/platform/plugins/admin/hooks/fs-schema-guard.sh

@@ -5,6 +5,16 @@
 #   - the target's first path segment must be in the allowed top-level set
 #     (parsed from the fenced ```allowed-top-level block of the account's
 #     SCHEMA.md — our own structured data, not CLI prose);
+#   - a target whose first path segment is named in the fenced
+#     ```agent-denied-top-level block is blocked even though that name is in the
+#     allowed set: those entries are the account's control plane (identity,
+#     schema, credentials, agent settings, git dir), and none of them is ever
+#     authored by an agent file edit. The block message quotes the reason the
+#     fence carries for that name;
+#   - a target whose first path segment is a plugin-declared file (parsed from
+#     the fenced ```declared-files block of the same SCHEMA.md) is blocked even
+#     though that name is in the allowed set: the allowed set is a layout list,
+#     and a declared file is written whole by its owning plugin;
 #   - a target under an operator-data bucket (projects/ contacts/) may be at
 #     most <bucket>/<entity>/<file> deep; documents/ may be at most
 #     <bucket>/<folder>/<file> deep. Tool-owned dirs pass at any depth.
@@ -14,7 +24,7 @@
 #
 # Exit codes: 0 = allow, 2 = block (stderr shown to the agent). Fail closed when
 # the tool call cannot be inspected (tty or empty stdin). Every block logs
-#   [fs-guard] blocked path=<rel> reason=<top-level|over-deep|bad-name>
+#   [fs-guard] blocked path=<rel> reason=<top-level|account-machinery|declared-file|over-deep|bad-name>
 # No task numbers / internal refs in any operator-visible string.
 
 set -uo pipefail
@@ -84,6 +94,59 @@ if ! printf '%s\n' "$ALLOWED" | grep -qxF "$SEG0"; then
   exit 2
 fi
 
+# Account-machinery check. Some entries in the allowed set are the account's own
+# control plane rather than operator data: the identity file, the schema this
+# hook parses, the credential store, the agent's own settings and hooks, and the
+# git dir. The allowed set says which names may EXIST at the account root, not
+# which an agent may author, so each of these is named in a second fence together
+# with the reason it is off-limits. None of the five is authored through
+# Write/Edit/NotebookEdit: platform bash and Node write four of them, and git
+# itself writes .git, so denying them costs no legitimate writer. This denies
+# the agent's FILE-EDIT tools only, which is the whole surface the hook governs
+# — a Bash command still reaches these paths, and one sanctioned path relies on
+# that (the data-portal skill appends its fetch secret to secrets/ with a shell
+# redirect). The set and its reasons come from the account's own SCHEMA.md, so
+# the hook hard-codes no list. There is no owning plugin to name here, which is
+# why this fence carries a reason column the declared-files fence does not need.
+#
+# Not to be confused with the same phrase in account-dir-schema-reconcile.ts,
+# whose "account's own machinery" is the never-a-stray set and covers a
+# different membership (.quarantine and AGENTS.md are in it; secrets/ is not).
+#
+# No fence means nothing to deny, the same fail-open posture as the
+# missing-schema case above. Which accounts lack it is not uniform: setup-account.sh
+# re-provisions only the house account, and provision copies the template whole,
+# so the house account gains the fence on the next install while a client
+# sub-account — provisioned once, at creation — keeps a fence-less schema until a
+# durable backfill lands.
+DENIED=$(awk '/^```agent-denied-top-level$/{f=1;next} /^```$/{f=0} f' "$ACCOUNT_DIR/SCHEMA.md")
+if [ -n "$DENIED" ] && printf '%s\n' "$DENIED" | awk -F'\t' -v n="$SEG0" '$1==n{found=1} END{exit !found}'; then
+  WHY=$(printf '%s\n' "$DENIED" | awk -F'\t' -v n="$SEG0" '$1==n{print $2; exit}')
+  echo "[fs-guard] blocked path=$REL reason=account-machinery" >&2
+  echo "Blocked: '$SEG0' is this account's own machinery, not operator data: $WHY. Change it through the code that owns it." >&2
+  exit 2
+fi
+
+# Declared-file check. A file declared in the fence is written whole by platform
+# code, so an agent write to it is blocked even though the name is in the allowed
+# set: that set says which names may exist at the account root, not which an
+# agent may author. The owner column names the declaring plugin, which is where
+# the declaration lives, not necessarily the module that does the writing (a
+# shared service may write a file declared on the plugin that no brand excludes),
+# so the message points at the owning code rather than promising a plugin tool.
+# A file the merge marks as agent-written is not in this fence at all. The set
+# comes from the account's own SCHEMA.md, so the hook hard-codes no list. No
+# fence (a brand declaring no owned file, or a schema written before the fence
+# existed) means nothing to deny — the same fail-open posture as the
+# missing-schema case above.
+DECLARED=$(awk '/^```declared-files$/{f=1;next} /^```$/{f=0} f' "$ACCOUNT_DIR/SCHEMA.md")
+if [ -n "$DECLARED" ] && printf '%s\n' "$DECLARED" | awk -F'\t' -v n="$SEG0" '$1==n{found=1} END{exit !found}'; then
+  OWNER=$(printf '%s\n' "$DECLARED" | awk -F'\t' -v n="$SEG0" '$1==n{print $2; exit}')
+  echo "[fs-guard] blocked path=$REL reason=declared-file" >&2
+  echo "Blocked: '$SEG0' is a declared file owned by the $OWNER plugin. The platform writes it whole, so it is control-plane state, not operator data, and a hand-written copy is overwritten by the next platform write. Change it through the code that owns it, never by hand." >&2
+  exit 2
+fi
+
 # Over-deep check for operator-data buckets. Count path segments.
 depth=$(printf '%s' "$REL" | awk -F/ '{print NF}')
 case "$SEG0" in

package/payload/platform/plugins/admin/skills/whats-new/SKILL.md

@@ -9,6 +9,18 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-07-27 (0.1.514)
+
+- Three delete and danger buttons had no visible hover state, because their hover colour resolved to white. They now have a real hover step on the colour ramp.
+- The assistant can no longer write to your account's own configuration and machinery files, which are now fenced off at the write guard.
+- WhatsApp escalation checks now compare against the account a message was actually routed to, rather than a folder name, so an escalation is judged against the right account.
+
+## 2026-07-27 (0.1.513)
+
+- Fixed sign-in for sub-accounts: the browser session bridge now checks that you belong to the account you asked for, instead of only ever accepting the first one it found.
+- WhatsApp account checks now use the account's real identifier rather than a folder name, so conversations are attributed to the right account.
+- The saved session-title cache is now pruned as the sessions list is walked, so it no longer grows without limit.
+
 ## 2026-07-27 (0.1.512)
 
 - Signed PDFs keep their clickable links and selectable text. The e-sign stamp no longer falls back to flattening each page into an image, which had been discarding every link in the document.

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

@@ -1,7 +1,7 @@
 ---
 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 reused per-scope narrow token, or quoting a dashboard click-path the operator performs themselves.
-account-owned-files: [{"file": "data-portal.json", "description": "The account's data-portal folder index, written by bin/portal-index-push.mjs on every push."}]
+account-owned-files: [{"file": "data-portal.json", "writtenBy": "agent", "description": "The account's portal config and folder index. Authored by the agent under the data-portal skill, which is also the only path that changes it; bin/portal-index-push.mjs reads it on every push."}]
 tools: []
 mcp-manifest: skip
 ---

package/payload/platform/plugins/cloudflare/bin/schema-exposed-dirs.mjs

@@ -78,7 +78,7 @@ export function resolveExposedDirs(schemaText, exposeFolders = []) {
     collisions: /** @type {string[]} */ ([]),
     exposed: /** @type {string[]} */ ([]),
   }
-  // Fail CLOSED. fs-schema-guard.sh:76-78 fails open on a missing schema so an
+  // Fail CLOSED. fs-schema-guard.sh:83-86 fails open on a missing schema so an
   // unseeded legacy account is not write-blocked; a read surface facing a
   // client must do the opposite. Do not "fix" this to match the guard.
   if (typeof schemaText !== 'string' || schemaText.length === 0) return empty

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

@@ -1,7 +1,7 @@
 ---
 name: scheduling
 description: "Calendar and scheduling — create events, manage appointments, set up recurring triggers."
-account-owned-files: [{"file": "calendar-availability.json", "description": "The booking page's availability config, written by the publish-availability script and read by the live booking page."}]
+account-owned-files: [{"file": "calendar-availability.json", "writtenBy": "agent", "description": "The booking page's availability config. Authored by the agent under the calendar-site skill, which is also the only path that changes it; the publish-availability script reads it to refresh the live booking page."}]
 tools:
   - name: schedule-event
     publicAllowlist: false

package/payload/platform/plugins/whatsapp/references/channels-whatsapp.md

@@ -137,7 +137,7 @@ A passive-bound phone that DMs a requirement gets exactly one `:Task` filed unde
 
 **Recall surfaces the attachment, not just the text.** A recalled message that carried media now includes an `attachment` reference on its read-tool row (`whatsapp-messages` and both modes of `whatsapp-conversation-graph-state`): `attachmentId`, `filename`, `mimeType`, a `sizeBytes` (bytes, as stored — the line renders it as KB/MB), an absolute on-disk `path` to the stored bytes, and a `readableTextPath` when an extracted-text sibling exists. The reference resolves against the same store account the route read the thread from (the house account when projecting a sub-account), so the path always points at the house-stored bytes, never the sub-account's own empty uploads dir. The read-tool output renders it as an indented `[attachment: <name> (<mime>, <size>); Read: <path>]` line, and the agent reads that path directly (an image renders when Read). Inbound WhatsApp media runs best-effort text extraction (the earlier `skipDocToText` opt-out was retired): a convertible container (xlsx, docx, ods, and the rest of `CONVERTIBLE_DOC_MIME`) gets an `.extracted.txt` sibling, so `readableTextPath` is populated for those; an image or other non-convertible type has no sibling and surfaces the bytes `path` alone. Observable on each read route's result line as `withAttachments=<n>`; a record that names an attachment whose bytes are missing under the store account logs `[whatsapp-read-tool] op=attachment-miss attachmentId=<8> storeAccount=<id>`, which separates a genuine house-store gap from a sub-account mis-resolution.
 
-**Single source of truth + fail-closed.** The effective account is resolved **exactly once**, in the gate: `checkDmAccess` returns `effectiveAccountId` (the house account for owner/`adminPhones`/public, the bound sub-account for a manager), and that value threads through the inbound payload → gateway → `ensureChannelSession`, which spawns into it **without re-reading** the `accountManagers` map. There is no second resolution and no `?? accountId` house fallback: if a manager's bound sub-account is not a valid account, the inbound is **rejected** (no session spawned, no reply), never routed to the house. This closes the escalation where a divergence between two independent map reads handed a scoped manager a house-owner admin session. Observable signals: `op=account-manager-route … effectiveAccount=… source=gate` on a routed manager inbound; `op=account-manager-reject … reason=unresolved-effective-account` on the fail-closed drop; a standing `op=escalation-tripwire` belt that can only fire if a future change reintroduces the divergence.
+**Single source of truth + fail-closed.** The effective account is resolved **exactly once**, in the gate: `checkDmAccess` returns `effectiveAccountId` (the house account for owner/`adminPhones`/public, the bound sub-account for a manager), and that value threads through the inbound payload → gateway → `ensureChannelSession`, which spawns into it **without re-reading** the `accountManagers` map. There is no second resolution and no `?? accountId` house fallback: if a manager's bound sub-account is not a valid account, the inbound is **rejected** (no session spawned, no reply), never routed to the house. This closes the escalation where a divergence between two independent map reads handed a scoped manager a house-owner admin session. Observable signals: `op=account-manager-route … effectiveAccount=… source=gate` on a routed manager inbound; `op=account-manager-reject … reason=unresolved-effective-account` on the fail-closed drop; a standing `op=escalation-tripwire` belt that can only fire if a future change reintroduces the divergence. The belt compares the manager's effective account against the **house** UUID, not against the account inbound persists to — on an install that sets `channelRoutingAccountId` those differ, and a manager bound to the routing target is a legitimate binding that must admit. The binding write path now refuses a house-account binding at write time, so no new one can be created; a binding written before that refusal existed is still on disk and is what the belt catches.
 
 **The scheduler path fails closed too.** A scheduled dispatch (`POST /api/channel/schedule-inject`) reaches the same spawn machine without going through the gate, resolving its own effective account via `effectiveAccountFor`. That resolver carries the same single-source + fail-closed shape: a non-manager destination scopes to the house (an owner/admin's real scope), a valid manager scopes to the bound sub-account, and a manager whose bound sub-account is not a valid account resolves to nothing — the route **rejects** (`op=schedule-account-manager-reject … reason=unresolved-effective-account`, HTTP 403, no spawn, no reply), never routing to the house. There is no `?? accountId` fallback on this path either. Telegram scheduled dispatch is house-only by construction (no account-manager routing), so there is nothing to fail closed there.