@rubytech/create-sitedesk-code 0.1.513 → 0.1.514

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-sitedesk-code",
-  "version": "0.1.513",
+  "version": "0.1.514",
   "description": "Install SiteDesk — automated back office for independent building contractors",
   "bin": {
     "create-sitedesk-code": "./dist/index.js"

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

@@ -0,0 +1,250 @@
+# Account-machinery write fence Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Stop the account agent writing the five entries in the shipped account schema that are the account's own machinery rather than operator data.
+
+**Architecture:** A new fenced `agent-denied-top-level` block in the shipped `SCHEMA.md` template lists the five names with a per-name reason. `fs-schema-guard.sh` parses it with the same awk shape it already uses for the other two fences and blocks a write whose first path segment matches, reporting `reason=account-machinery`. The `allowed-top-level` fence is not touched, so the standing reconcile keeps reading exactly what it reads today.
+
+**Tech Stack:** bash, awk, python3. The hook and its tests are plain bash; no build and no `npm install`.
+
+## Global Constraints
+
+- The deny set and each name's reason come from the account's own `SCHEMA.md`. The hook hard-codes no list.
+- `allowed-top-level` is not modified. All five names stay in it, so the standing reconcile never reports them as strays.
+- No fence means nothing is denied. An account whose `SCHEMA.md` predates this change keeps today's behaviour, matching the guard's existing fail-open posture on a missing schema and on a missing `declared-files` fence.
+- No task numbers or internal refs in any operator-visible string.
+- Block log line shape is fixed: `[fs-guard] blocked path=<rel> reason=account-machinery`.
+- The separator inside the fence is a literal TAB, matching the `declared-files` fence.
+- `fs-schema-guard-bash-post.sh` is not modified.
+- Baseline before any change: `fs-schema-guard.test.sh` is `39 passed, 0 failed`; `fs-schema-guard-bash.test.sh` is `15 passed, 0 failed`.
+
+---
+
+### Task 1: Ship the deny fence in the account schema template
+
+**Files:**
+- Modify: `platform/templates/account-schema/SCHEMA.md` (append a section after the "## Allowed top-level entries" section)
+- Test: `platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
+
+**Interfaces:**
+- Consumes: nothing.
+- Produces: a fenced block whose header line is exactly three backticks followed by `agent-denied-top-level`, one line per name as `name<TAB>reason`, in the order `account.json`, `SCHEMA.md`, `secrets`, `.claude`, `.git`. Task 2 parses it.
+
+This task is data only. After it the guard's behaviour is unchanged, and every pre-existing case must still pass — that is the evidence the appended fence disturbs no existing reader.
+
+- [ ] **Step 1: Write the failing assertions**
+
+Append these two assertions to `platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`, immediately after the existing `allowed-set parse` assertion and before the `echo "----- $PASS passed, $FAIL failed -----"` line:
+
+````bash
+# 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
+````
+
+- [ ] **Step 2: Run the suite to verify the new assertion fails**
+
+Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
+
+Expected: `FAIL: deny-set parse: got []` on stderr, and the run ends `----- 40 passed, 1 failed -----` with a non-zero exit. `deny-set reasons` passes at this point only because an absent fence yields no rows; it becomes meaningful after Step 3.
+
+- [ ] **Step 3: Add the fence to the template**
+
+Append this section to the end of `platform/templates/account-schema/SCHEMA.md`, after the closing fence of the `allowed-top-level` block. **The separator between each name and its reason is a literal TAB character, not spaces.**
+
+`````markdown
+## Entries you may not write
+
+Five of the entries above are this account's own machinery rather than operator
+data. Each is listed below with the reason it is off-limits. The write guard
+blocks a write whose first path segment matches one of them and quotes that
+reason back. Change any of them through the code that owns it: platform code
+writes all five, and none is written through an agent file edit.
+
+```agent-denied-top-level
+account.json	the account's identity and settings, changed through the account and admin tools
+SCHEMA.md	the layout rules the write guard itself reads, so editing it widens its 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, managed by git
+```
+`````
+
+- [ ] **Step 4: Verify the tab separator landed**
+
+Run:
+
+````bash
+awk '/^```agent-denied-top-level$/{f=1;next} /^```$/{f=0} f' platform/templates/account-schema/SCHEMA.md | cat -A | head -5
+````
+
+Expected: each of the five lines shows `^I` between the name and the reason, and ends `$`. If any line shows spaces instead, fix it before continuing — the guard splits on TAB and a space-separated line parses as a name with no reason.
+
+- [ ] **Step 5: Run the full guard suite**
+
+Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
+
+Expected: `----- 41 passed, 0 failed -----`. Every pre-existing case must still pass, which is the proof the appended fence does not disturb the `allowed-top-level` parse, the `declared-files` parse, or any existing account fixture.
+
+- [ ] **Step 6: Run the neighbouring suites that read the same schema**
+
+Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh`
+
+Expected: `----- 15 passed, 0 failed -----`
+
+Run: `bash platform/scripts/__tests__/account-schema-owned-dirs.test.sh`
+
+Expected: the suite's own pass line with zero failures. This is the regression check that the owned-dirs merge still finds and rewrites the `allowed-top-level` fence and its three marker-delimited regions with an extra fence present in the file.
+
+- [ ] **Step 7: Commit**
+
+````bash
+git add maxy-code/platform/templates/account-schema/SCHEMA.md maxy-code/platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh
+git commit -m "feat(2052): ship the agent-denied-top-level fence in the account schema template"
+````
+
+---
+
+### Task 2: The guard denies a write to a fenced name
+
+**Files:**
+- Modify: `platform/plugins/admin/hooks/fs-schema-guard.sh` (header comment block at lines 2-22; new branch inserted after the top-level check's closing `fi` at line 89)
+- Test: `platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
+
+**Interfaces:**
+- Consumes: the `agent-denied-top-level` fence from Task 1, `name<TAB>reason` per line.
+- Produces: exit 2 with `[fs-guard] blocked path=<rel> reason=account-machinery` on stderr, plus an operator-visible line quoting that name's reason. Nothing later depends on it.
+
+- [ ] **Step 1: Write the failing tests**
+
+Add this block to `platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`, immediately after the `run_case "no fence no deny" ...` line and before the `# Allowed-set parse == documented set.` comment:
+
+````bash
+# 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
+````
+
+- [ ] **Step 2: Run the suite to verify the new cases fail**
+
+Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
+
+Expected: the ten `machinery *` cases FAIL with `(exit=0, want 2; ...)`. The five `no deny fence allows *` cases and `machinery bucket allow` already pass. The run ends `----- 47 passed, 10 failed -----` with a non-zero exit.
+
+- [ ] **Step 3: Add the deny branch to the guard**
+
+In `platform/plugins/admin/hooks/fs-schema-guard.sh`, insert this block immediately after the top-level check's closing `fi` (line 89) and before the `# Declared-file check.` comment:
+
+````bash
+# 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. Every one of them is written by platform code
+# from bash or Node, never through Write/Edit/NotebookEdit, so denying them costs
+# no legitimate writer. 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. No fence (a schema written before the fence existed) means
+# nothing to deny — the same fail-open posture as the missing-schema case above.
+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, never by hand." >&2
+  exit 2
+fi
+````
+
+- [ ] **Step 4: Update the hook's header comment**
+
+In the same file, in the header comment block, insert this bullet after the `allowed top-level set` bullet and before the `plugin-declared file` bullet, so the header lists all three rules the hook enforces:
+
+````bash
+#   - 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 own machinery (identity,
+#     schema, credentials, agent settings, git dir), written by platform code
+#     and never by an agent file edit. The block message quotes the reason the
+#     fence carries for that name;
+````
+
+Then extend the exit-codes paragraph's log-line list so it reads:
+
+````bash
+#   [fs-guard] blocked path=<rel> reason=<top-level|account-machinery|declared-file|over-deep|bad-name>
+````
+
+- [ ] **Step 5: Run the suite to verify it passes**
+
+Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
+
+Expected: `----- 57 passed, 0 failed -----`
+
+- [ ] **Step 6: Mutation check**
+
+Comment out the `exit 2` inside the new branch and re-run the suite.
+
+Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
+
+Expected: the ten `machinery *` cases FAIL. Then restore the line and re-run.
+
+Expected after restore: `----- 57 passed, 0 failed -----`
+
+- [ ] **Step 7: Confirm the untouched surfaces still pass**
+
+Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh`
+
+Expected: `----- 15 passed, 0 failed -----`. The Bash post-hook still reads only `allowed-top-level` and `declared-files`, and still stays silent on all five names.
+
+Run: `bash platform/scripts/__tests__/account-schema-owned-dirs.test.sh`
+
+Expected: zero failures.
+
+- [ ] **Step 8: Commit**
+
+````bash
+git add maxy-code/platform/plugins/admin/hooks/fs-schema-guard.sh maxy-code/platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh
+git commit -m "feat(2052): deny agent writes to the account's own machinery"
+````
+
+---
+
+## Reach note for the debrief
+
+`provision-account-dir.sh:40-41` copies the template to `<accountDir>/SCHEMA.md`, and `setup-account.sh:59` calls that for the house account only. The standing all-accounts reconcile merges just the marker-delimited regions, so it never carries the template body. The house account therefore gains the fence on the next install, while a client sub-account, provisioned once at creation, keeps a fence-less schema indefinitely and the guard stays fail-open there. That gap is filed as `.tasks/pending/2056-the-account-machinery-deny-fence-never-reaches-an-existing-sub-account.md`, following the durable-backfill pattern of Task 1683 and Task 1929. Separately, `platform/` ships inside the bundled `create-*-code` payload, so reaching a device at all needs an operator-gated installer publish plus an `npx` upgrade. Both belong in the debrief's known-limitations section.

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

@@ -121,6 +121,7 @@ rather than flip it silently.
 
 - The fence's pre-existing permissiveness for `account.json`, `secrets/` and
   `.claude/`. It predates Task 1902 and is a separate decision, filed as
-  `.tasks/pending/2048-the-allowed-fence-permits-agent-writes-to-the-account-s-own-machinery.md`.
+  `.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/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh

@@ -125,11 +125,52 @@ run_case "declared edit blocks"   "$(mkenv Edit file_path 'wa-channel-bindings.j
 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

@@ -28,6 +28,14 @@
 # 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,12 @@
 #   - 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,
@@ -18,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|declared-file|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
@@ -88,6 +94,39 @@ 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

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

@@ -9,6 +9,12 @@ 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.

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:77-80 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/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.
 

package/payload/platform/templates/account-schema/SCHEMA.md

@@ -112,3 +112,20 @@ AGENTS.md
 .claude
 .git
 ```
+
+## Entries you may not write
+
+Five of the entries above are this account's own machinery rather than operator
+data. Each is listed below with the reason it is off-limits. The write guard
+blocks a write whose first path segment matches one of them and quotes that
+reason back. Change any of them through the code that owns it. Each has an
+owner already, named in its reason below, and none of the five is ever authored
+by editing the file here.
+
+```agent-denied-top-level
+account.json	the account's identity and settings, changed through the account and admin tools
+SCHEMA.md	the layout rules the write guard itself reads, so editing it widens its 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, managed by git
+```

package/payload/server/public/activity.html

@@ -5,12 +5,12 @@
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
   <title>Activity — Maxy</title>
   <link rel="icon" href="/favicon.ico">
-  <script type="module" crossorigin src="/assets/activity-ByWYF5dC.js"></script>
+  <script type="module" crossorigin src="/assets/activity-BgZISMuE.js"></script>
   <link rel="modulepreload" crossorigin href="/assets/chunk-CltuBf4Z.js">
-  <link rel="modulepreload" crossorigin href="/assets/useSubAccountSwitcher-CJKjEPNN.js">
-  <link rel="modulepreload" crossorigin href="/assets/AdminShell-BMPEWNZk.js">
-  <link rel="modulepreload" crossorigin href="/assets/triangle-alert-Ck_3VhT9.js">
-  <link rel="stylesheet" crossorigin href="/assets/useSubAccountSwitcher-DOWQXDT8.css">
+  <link rel="modulepreload" crossorigin href="/assets/useSubAccountSwitcher-DH0P6QMV.js">
+  <link rel="modulepreload" crossorigin href="/assets/AdminShell-DkrURZnF.js">
+  <link rel="modulepreload" crossorigin href="/assets/triangle-alert-D-bSbPnX.js">
+  <link rel="stylesheet" crossorigin href="/assets/useSubAccountSwitcher-BYl2c7xA.css">
   <link rel="stylesheet" href="/brand-defaults.css">
 </head>
 <body>