@rubytech/create-sitedesk-code 0.1.524 → 0.1.525

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

@@ -1,303 +0,0 @@
-# Task 2028 — declared-file write deny: implementation plan
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** The write guard blocks an agent `Write`/`Edit`/`NotebookEdit` to a plugin-declared account-root file, naming the owning plugin, while an operator bucket in the same fence still passes.
-
-**Architecture:** The merge emits a third generated region carrying `name<TAB>owning-plugin` inside a ```` ```declared-files ```` fence. The guard parses that fence with the same one-line awk it already uses for `allowed-top-level`, and denies after the top-level check passes. `allowed-top-level` itself is untouched, so the standing reconcile is unaffected.
-
-**Tech Stack:** bash (PreToolUse/PostToolUse hooks), python3 (schema merge), bash test suites.
-
-## Global Constraints
-
-- No task numbers or internal refs in any operator-visible string (existing hook rule, stated in both hook headers).
-- The guard never hard-codes a file list; the account's own `SCHEMA.md` is the only source.
-- Fail-open posture is preserved: no `declared-files` fence means nothing to deny.
-- The block log keeps the existing shape: `[fs-guard] blocked path=<rel> reason=<...>`.
-- Spec: `platform/docs/superpowers/specs/2026-07-27-task-2028-declared-file-write-deny-design.md`.
-
----
-
-### Task 1: The merge emits the declared-files region
-
-**Files:**
-- Modify: `platform/scripts/lib/account-schema-owned-dirs.py` (module constants; `merge()`)
-- Test: `platform/scripts/__tests__/account-schema-owned-dirs.test.sh`
-
-**Interfaces:**
-- Produces: a region delimited by `<!-- declared-files:start -->` / `<!-- declared-files:end -->` containing a ```` ```declared-files ```` fence, one `name<TAB>plugin` line per declared file in `resolve()` order. Task 2's guard consumes exactly that fence.
-
-- [ ] **Step 1: Write the failing test**
-
-Append to `platform/scripts/__tests__/account-schema-owned-dirs.test.sh`, after the existing platform-plugin declarations block:
-
-```bash
-# --- declared-files fence: one name<TAB>plugin line per declared file -------
-DECL="$(awk '/^```declared-files$/{f=1;next} /^```$/{f=0} f' "$A_MX/SCHEMA.md")"
-assert_grep "$(printf 'wa-channel-bindings.json\tadmin')" "$DECL" "mx-decl-wa"
-assert_grep "$(printf 'agents-disabled.json\tadmin')" "$DECL" "mx-decl-agents-disabled"
-assert_grep "$(printf 'data-portal.json\tcloudflare')" "$DECL" "mx-decl-portal"
-assert_grep "$(printf 'calendar-availability.json\tscheduling')" "$DECL" "mx-decl-availability"
-assert_nogrep "e-sign" "$DECL" "mx-decl-excludes-dirs"
-assert_grep "declared-files:start" "$(cat "$A_MX/SCHEMA.md")" "mx-decl-marker"
-```
-
-- [ ] **Step 2: Run the test to verify it fails**
-
-Run: `bash platform/scripts/__tests__/account-schema-owned-dirs.test.sh`
-Expected: FAIL on `mx-decl-wa` and the other new assertions (no such fence yet).
-
-- [ ] **Step 3: Write the implementation**
-
-In `platform/scripts/lib/account-schema-owned-dirs.py`, beside the existing marker constants:
-
-```python
-DECL_START = "<!-- declared-files:start -->"
-DECL_END = "<!-- declared-files:end -->"
-```
-
-In `merge()`, add the strip beside the two existing strips:
-
-```python
-    text = _strip_region(text, DECL_START, DECL_END)
-```
-
-and append the region after the ontology region is appended:
-
-```python
-    declared = [e for e in owned if e["kind"] == "file"]
-    if declared:
-        region = [DECL_START, "## Declared files (written by their owning plugin)", "",
-                  "Each file below is written whole by the plugin named beside it. It is",
-                  "control-plane state, not operator data, and is not hand-edited: change",
-                  "it through the owning plugin's own tool. The write guard reads this",
-                  "block and blocks a write whose first path segment is one of these",
-                  "names, which the allowed-top-level set above cannot express — that set",
-                  "lists what may exist at the root, not what may be authored by hand.", "",
-                  "```declared-files"]
-        for e in declared:
-            region.append(f"{e['name']}\t{e['plugin']}")
-        region.append("```")
-        region.append(DECL_END)
-        text = text.rstrip("\n") + "\n\n" + "\n".join(region) + "\n"
-```
-
-- [ ] **Step 4: Run the tests to verify they pass**
-
-Run: `bash platform/scripts/__tests__/account-schema-owned-dirs.test.sh`
-Expected: PASS, including the pre-existing `idempotent-second-merge` assertion.
-
-- [ ] **Step 5: Commit**
-
-```bash
-git add platform/scripts/lib/account-schema-owned-dirs.py platform/scripts/__tests__/account-schema-owned-dirs.test.sh
-git commit -m "feat(2028): merge emits a declared-files fence carrying each file's owning plugin"
-```
-
----
-
-### Task 2: The guard denies a write to a declared file
-
-**Files:**
-- Modify: `platform/plugins/admin/hooks/fs-schema-guard.sh` (header comment; new check after the top-level check)
-- Test: `platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
-
-**Interfaces:**
-- Consumes: the ```` ```declared-files ```` fence from Task 1, lines `name<TAB>plugin`.
-- Produces: `[fs-guard] blocked path=<rel> reason=declared-file` on stderr, exit 2.
-
-- [ ] **Step 1: Write the failing test**
-
-Append to `platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`, after the `ACCT_D` setup:
-
-```bash
-# A third account modelling a merged schema: the eight declared files are in the
-# allowed set (as the merge unions them) AND in the declared-files fence.
-ACCT_F=$(mktemp -d)
-trap 'rm -rf "$ACCT" "$ACCT_D" "$ACCT_F" "$ACCT_L"' EXIT
-DECLARED_FILES="webchat-channel-bindings.json wa-channel-bindings.json telegram-channel-bindings.json canonical-webchat-session.json session-titles.json agents-disabled.json data-portal.json calendar-availability.json"
-seed_declared() { # $1=acct  $2=with-fence(yes|no)
-  cp "$TEMPLATE" "$1/SCHEMA.md"
-  for f in $DECLARED_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
-      case "$f" in
-        data-portal.json) printf '%s\tcloudflare\n' "$f" ;;
-        calendar-availability.json) printf '%s\tscheduling\n' "$f" ;;
-        *) printf '%s\tadmin\n' "$f" ;;
-      esac
-    done
-    echo '```'; echo '<!-- declared-files:end -->'; } >> "$1/SCHEMA.md"
-}
-seed_declared "$ACCT_F" yes
-mkdir -p "$ACCT_F/projects/acme"
-
-# A fourth account in the pre-2028 state: the names are in the allowed set, but
-# no declared-files fence exists. Pins that the deny comes from the fence and
-# not from a list baked into the hook.
-ACCT_L=$(mktemp -d)
-seed_declared "$ACCT_L" no
-
-for f in $DECLARED_FILES; do
-  case "$f" in
-    data-portal.json) owner=cloudflare ;;
-    calendar-availability.json) owner=scheduling ;;
-    *) owner=admin ;;
-  esac
-  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 plugin"                                  "$ACCT_F"
-done
-run_case "operator bucket allow"  "$(mkenv Write file_path 'projects/acme/a.txt')"       0 "" "$ACCT_F"
-run_case "declared edit block"    "$(mkenv Edit file_path 'wa-channel-bindings.json')"   2 "reason=declared-file" "$ACCT_F"
-run_case "no fence no deny"       "$(mkenv Write file_path 'wa-channel-bindings.json')"  0 "" "$ACCT_L"
-```
-
-- [ ] **Step 2: Run the test to verify it fails**
-
-Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
-Expected: FAIL on every `declared block`/`declared owner` case with `exit=0, want 2`; `no fence no deny` already passes.
-
-- [ ] **Step 3: Write the implementation**
-
-In `platform/plugins/admin/hooks/fs-schema-guard.sh`, immediately after the top-level check block:
-
-```bash
-# Declared-file check. A file a plugin declares in its PLUGIN.md is written
-# whole by that plugin, so an agent write to it is blocked even though its name
-# is in the allowed set: that set lists what may exist at the account root, not
-# what may be authored by hand. The set and its owner come from the account's
-# own SCHEMA.md — the hook hard-codes no list. No fence (a brand declaring no
-# files, or a schema predating the block) means nothing to deny, the same
-# fail-open posture as the missing-schema case above.
-DECLARED=""
-if [ -f "$ACCOUNT_DIR/SCHEMA.md" ]; then
-  DECLARED=$(awk '/^```declared-files$/{f=1;next} /^```$/{f=0} f' "$ACCOUNT_DIR/SCHEMA.md")
-fi
-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}')
-  [ -z "$OWNER" ] && OWNER="owning"
-  echo "[fs-guard] blocked path=$REL reason=declared-file" >&2
-  echo "Blocked: '$SEG0' is written whole by the $OWNER plugin. It is control-plane state, not operator data, and a hand-written copy is overwritten by its owner's next write. Change it through the $OWNER plugin's own tool." >&2
-  exit 2
-fi
-```
-
-Update the header comment's reason list to `reason=<top-level|declared-file|over-deep|bad-name>` and add one line to the enforcement summary: a target whose first segment is a declared file is blocked.
-
-- [ ] **Step 4: Run the tests to verify they pass**
-
-Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
-Expected: PASS on all cases, including the pre-existing ten.
-
-- [ ] **Step 5: Mutation check**
-
-Comment out the `exit 2` inside the new block, re-run the suite, confirm the 16 declared cases fail, then restore.
-
-- [ ] **Step 6: Commit**
-
-```bash
-git add platform/plugins/admin/hooks/fs-schema-guard.sh platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh
-git commit -m "feat(2028): the write guard denies a write to a plugin-declared file"
-```
-
----
-
-### Task 3: The Bash post-hook decision is stated and pinned
-
-**Files:**
-- Modify: `platform/plugins/admin/hooks/fs-schema-guard-bash-post.sh` (header comment only)
-- Test: `platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh`
-
-**Interfaces:**
-- Consumes: nothing new. The behaviour under test is the existing allowed-set diff.
-
-- [ ] **Step 1: Write the failing test**
-
-Append to `platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh`:
-
-```bash
-# --- 10. Bash creating a declared file -> silent, by decision ---------------
-# A declared file is in the allowed set, so the diff never flags it. Kept
-# deliberately: this hook sees only names that appeared during the command and
-# cannot tell a hand-written copy from the owner's own script creating it.
-D=$(new_acct)
-awk '1; /^```allowed-top-level$/{print "wa-channel-bindings.json"}' "$D/SCHEMA.md" > "$D/SCHEMA.md.tmp" && mv "$D/SCHEMA.md.tmp" "$D/SCHEMA.md"
-run_pre "$D" "$(env_json PreToolUse Bash "$SID")" "$ef"
-printf '{}' > "$D/wa-channel-bindings.json"
-run_post "$D" "$(env_json PostToolUse Bash "$SID")" "$ef"
-check "post silent on declared file" 0 $? "" "$(cat "$ef")"
-```
-
-- [ ] **Step 2: Run the test**
-
-Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh`
-Expected: PASS. This test pins existing behaviour rather than driving a change; it fails only if a future edit makes the post hook flag declared files.
-
-- [ ] **Step 3: State the decision in the hook**
-
-Add to the header comment of `platform/plugins/admin/hooks/fs-schema-guard-bash-post.sh`:
-
-```
-# A declared file (a name a plugin declares as its own in PLUGIN.md) is in the
-# allowed set, so this hook never flags one. That silence is a decision, not an
-# accident: the diff sees only names that appeared during this command, so it
-# cannot tell the agent hand-writing the file from the agent running the owner's
-# own script (the portal index push, the availability publish), and feedback
-# would fire on the legitimate path. The Write/Edit guard blocks the hand-write
-# it can actually identify; this hook stays quiet. A test pins the silence.
-```
-
-- [ ] **Step 4: Re-run both hook suites**
-
-Run: `bash platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh && bash platform/plugins/admin/hooks/__tests__/fs-schema-guard.test.sh`
-Expected: PASS on both.
-
-- [ ] **Step 5: Commit**
-
-```bash
-git add platform/plugins/admin/hooks/fs-schema-guard-bash-post.sh platform/plugins/admin/hooks/__tests__/fs-schema-guard-bash.test.sh
-git commit -m "docs(2028): state and pin the Bash post-hook's silence on declared files"
-```
-
----
-
-### Task 4: End-to-end against the real brand tree
-
-**Files:** none modified. Verification only.
-
-- [ ] **Step 1: Merge a real schema and read the fence**
-
-```bash
-ACCT=$(mktemp -d) && cp platform/templates/account-schema/SCHEMA.md "$ACCT/SCHEMA.md"
-PROJECT_DIR="$PWD/platform" python3 platform/scripts/lib/account-schema-owned-dirs.py merge "$ACCT"
-awk '/^```declared-files$/{f=1;next} /^```$/{f=0} f' "$ACCT/SCHEMA.md"
-```
-
-Expected: eight `name<TAB>plugin` lines.
-
-- [ ] **Step 2: Drive the real hook against that merged account**
-
-```bash
-( cd "$ACCT" && printf '{"tool_name":"Write","tool_input":{"file_path":"wa-channel-bindings.json"}}' \
-  | bash "$OLDPWD/platform/plugins/admin/hooks/fs-schema-guard.sh"; echo "exit=$?" )
-```
-
-Expected: `reason=declared-file` on stderr and `exit=2`, against the same envelope that returned exit 0 before this change.
-
-- [ ] **Step 3: Confirm the reconcile still names no declared file as a stray**
-
-```bash
-PROJECT_DIR="$PWD/platform" python3 platform/scripts/lib/account-schema-owned-dirs.py reconcile "$ACCT" | grep ownedFile
-```
-
-Expected: `present=true` on every line.
-
----
-
-## Self-review
-
-- Spec coverage: emission (Task 1), deny (Task 2), Bash decision (Task 3), the spec's testing section (Tasks 1-3 plus the mutation check in Task 2 and the end-to-end in Task 4).
-- One spec sentence is tightened here: the "no fence" case uses an account whose allowed set already carries the names, because under the pristine template those names block as `top-level` and would not prove anything about the new branch.

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

@@ -1,250 +0,0 @@
-# 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/plans/2026-07-28-task-2097-email-signature-set.md

@@ -1,65 +0,0 @@
-# Task 2097 — `email-signature-set` implementation plan
-
-Design: [`2026-07-28-task-2097-email-signature-set-design.md`](../specs/2026-07-28-task-2097-email-signature-set-design.md).
-
-## Registration surfaces — corrected against the tree
-
-The task file names `ADMIN_CORE_TOOLS`. It does not exist: `grep -rn 'ADMIN_CORE_TOOLS' platform/` returns
-nothing outside comments. The live surfaces, each confirmed by reading the file, are four:
-
-| # | Surface | Evidence |
-|---|---|---|
-| 1 | `plugins/email/mcp/src/index.ts` | `eagerTool(server, "email-setup", …)` at line 124 |
-| 2 | `plugins/email/PLUGIN.md` | frontmatter `description:`, `tools:` list, Capabilities, Skills table |
-| 3 | `platform/templates/specialists/agents/personal-assistant.md` | the only template matching `grep -rl email-setup platform/templates/` |
-| 4 | `services/claude-session-manager/src/canonical-tool-names.generated.ts` | header: generated from `PLUGIN.md` `tools:` blocks, `check-canonical-tool-names.mjs` fails the build on drift |
-
-Surface 4 is not in the task file and would have broken the build. It is regenerated, never hand-edited:
-`cd platform && npm run gen:canonical-tools`.
-
-Three further files match `email-draft-send` and are deliberately **not** touched:
-`plugins/admin/hooks/preference-consult-gate.sh`, `scripts/lib/provision-account-dir.sh`, and the
-`plugins/admin/PLUGIN.md` prose describing them. All three are the outbound-send preference gate,
-matching sends that carry attachments. `email-signature-set` sends nothing, so it is not a gate member.
-
-## Steps
-
-1. **`lib/signature.ts`** — add `SIGNATURE_BASENAME`, `signatureDirFor(accountId)`, and
-   `saveSignature(accountDir, parts)`. `loadSignature` / `applySignature` unchanged.
-   `signatureDirFor` is `accountDirFor(accountId) || process.env.ACCOUNT_DIR || undefined`, which is the
-   expression `compose.ts:112` already computes, with an empty-string env normalised to `undefined`
-   (both already load as no-signature, so behaviour is unchanged). No import cycle: `attachment-resolve.ts`
-   imports only `node:fs` and `node:path`.
-2. **`lib/compose.ts`** — replace the inline `sigDir` expression with `signatureDirFor(accountId)` and the
-   literal `"email-signature"` in `assetNote` with `SIGNATURE_BASENAME`. `accountDirFor` stays imported for
-   the attachment path at line 75.
-3. **`tools/email-signature-set.ts`** — refuse an all-absent call and an unresolvable directory before any
-   write, call `saveSignature`, log, return the resolved paths.
-4. **`index.ts`** — import and `eagerTool` register, placed after the `email-setup` block. Guard with
-   `refuseNoAccount`, wrap in try/catch like `email-setup`. The handler's local result variable is named
-   `message`, not `text`, so it cannot shadow the `text` parameter.
-5. **`PLUGIN.md`** — `tools:` entry (`riskClass: write_local`, both allowlists false, matching `email-setup`),
-   a Config clause in the frontmatter `description:`, a Capabilities bullet, a Skills-table row.
-6. **`personal-assistant.md`** — add `mcp__plugin_email_email__email-signature-set` after `email-setup`.
-7. **Regenerate** `canonical-tool-names.generated.ts`.
-8. **`skills/email-signature/SKILL.md`** — new skill.
-9. **`skills/email-composition/SKILL.md`** — one added rule, see below.
-10. **`__tests__/email-signature-set.test.ts`** — committed, not ephemeral: the plugin already carries 34
-    test files and the task file mandates a regression test.
-
-## Addition beyond the task file
-
-The task specifies that the new `email-signature` skill carries the rule "never hand-build a signature
-inside a draft body". That skill activates when the operator asks to set or change a signature. The
-incident happened while **drafting**, when that skill is not loaded. `grep -in signature` over
-`skills/email-composition/SKILL.md` returns zero hits, so the drafting surface currently says nothing
-about signatures.
-
-So the rule is also stated in one sentence in `email-composition`, which is the skill that is loaded while
-drafting. Without it the doctrine lives only in a skill absent at the moment it is needed. Declared in Plan
-Conformity as an addition.
-
-## Verification
-
-`npm run build` and `npx vitest run` in `plugins/email/mcp`, then `npm run gen:canonical-tools` and the
-`check-canonical-tool-names.mjs` gate in `platform/`. No browser surface, no Pi hook surface.