@rubytech/create-sitedesk-code 0.1.524 → 0.1.526

package/payload/platform/docs/superpowers/specs/2026-07-27-task-2016-disabled-agent-routing-design.md

@@ -1,139 +0,0 @@
-# Task 2016 — a disabled agent must leave the admin's routing table, and read as disabled rather than missing
-
-Design, 2026-07-27. Depends on Task 1996 (landed).
-
-## The defect
-
-Task 1996 stops dispatch by moving an agent file out of `<accountDir>/specialists/agents/`,
-the directory `spawn-context.ts` reads to build the spawn manifest. Two surfaces still
-believe the file is there.
-
-`platform/scripts/lib/agents-md-bootstrap.sh:42-47` only ever appends. A line matching
-`^- \*\*specialists:<name>\*\*:` in `agents/admin/AGENTS.md` is preserved verbatim and a
-missing one is appended; nothing is ever removed. So the admin's routing prose keeps
-advertising a specialist the operator switched off, and dispatch fails inside a turn
-against a file that is gone.
-
-`platform/plugins/admin/mcp/src/index.ts:520-533` walks the AGENTS.md entries against
-`specialists/agents/` and calls a name with no file `missing file`. An operator action is
-rendered as an install fault.
-
-## What the fix delivers
-
-1. A name the operator disabled has no routing line.
-2. Re-enabling restores it.
-3. `system-status` reports `disabled` and `missing file` as different things, and counts
-   them separately.
-
-## Surface 1 — `agents-md-bootstrap.sh` reconciles
-
-The store is `<accountDir>/agents-disabled.json`, `{ "disabled": ["<basename>.md", …] }`,
-written whole at 0600 by `platform/ui/server/routes/admin/agents.ts`. The bootstrap reads
-it with the same python3 extractor `provision-account-dir.sh:264-276` already uses, which
-accepts only strings ending `.md` with no `/` and no `..`.
-
-**The name rule.** A store entry maps to a routing line by stripping `.md`. One rule, no
-branch: all twelve files under `platform/templates/specialists/agents/` have `name:` equal
-to their filename, the disable route keys on `slug` equal to the basename, and the status
-walker at `index.ts:526` already maps a name back to `<name>.md`.
-
-**The reconcile rule.** A name in the store gets no routing line. It applies at both points
-in the script: an existing line for that name is removed, and the append loop skips that
-name. Stating it once and applying it uniformly is what makes the invariant hold in the
-drift state the standing `op=agent-parity` check exists to catch (store names it, file is
-still live) rather than only on the happy path.
-
-**An unreadable store withholds nothing.** `provision-account-dir.sh:293` already prints
-`specialists agents-disabled-store-unreadable — withholding nothing` and carries on, so
-the prose posture matches the file-withholding posture that runs immediately before it.
-
-**Observability.** The existing line stays byte-identical, because the current suite
-asserts its counts:
-
-```
-  [admin-bootstrap] AGENTS.md specialists=<n> appended=<m> existing=<k>
-```
-
-A second line is added:
-
-```
-  [agents-md] op=specialist-lines account=<id8> kept=<n> withheld=<comma-list|none|store-unreadable>
-```
-
-`id8` is the first eight characters of the account directory's basename. `kept` counts the
-`- **specialists:` lines in AGENTS.md after the run. `withheld` names the store's entries,
-sorted, as names rather than basenames; `none` when the store is absent or empty; the
-literal `store-unreadable` when it is present but does not parse.
-
-## Surface 2 — `system-status` separates disabled from missing
-
-The classification at `index.ts:520-533` moves into a new
-`platform/plugins/admin/mcp/src/specialist-registry.ts`, beside `skill-resolution.ts` and
-`store-skill-core.ts`, which are the same shape: a module `index.ts` imports and a
-`node:test` suite covers. It exports one function taking the AGENTS.md text, the
-specialists directory, the account directory and whether Chrome is up, and returning the
-per-name lines plus the two counts.
-
-Status, in order:
-
-- the file exists in `specialists/agents/` → `ok`, except `personal-assistant` with Chrome
-  down, which keeps today's `degraded — chrome not running`;
-- otherwise the name is in the store → `disabled (operator)`;
-- otherwise → `missing file`.
-
-The header becomes `<n> registered, missing=<x> disabled=<y>`. An unreadable store is
-tolerated the same way the bootstrap tolerates it: no names classify as disabled, and the
-absent file stays `missing file`, which is the honest answer when the store cannot be read.
-
-With surface 1 in place a disabled agent has no AGENTS.md line at all, so in the steady
-state `disabled=0`. The classification earns its place in the drift window: an account
-disabled before this change carries the stale line until a provisioning run or a
-disable/enable call reconciles it, and that is exactly when the operator needs the line to
-read `disabled` rather than `missing file`.
-
-## Surface 3 — the disable path reconciles immediately
-
-`agents.ts` currently leaves AGENTS.md untouched, so prose is only correct after the next
-provisioning run. After the file move and the store write, both handlers exec
-`bash <PLATFORM_ROOT>/scripts/lib/agents-md-bootstrap.sh <accountDir>` with a timeout.
-`platform/scripts` ships in the payload (`packages/create-maxy-code/scripts/bundle.js:318`
-copies the whole `platform` tree minus the listed exclusions), and `claude-info.ts:33`
-is the precedent for `execFileSync` in an admin route.
-
-Enable needs no separate restore path. The file is live again by the time the script runs,
-so the append loop puts the line back and the store no longer names it.
-
-**Failure posture.** A failed exec does not turn the request into a 500: the file move and
-the store write already happened, and dispatch is already stopped, so reporting the whole
-disable as failed would be false. The handler logs
-`[admin/agents] op=agents-md-reconcile accountId=<id8> slug=<slug> outcome=failed reason="…"`
-and the response carries `routingReconciled: false`, so no caller is told the prose is
-correct when it is not.
-
-## Tests
-
-**Shell, `platform/scripts/__tests__/agents-md-bootstrap.test.sh`.** Against the existing
-three-specialist temp account: a store naming one of them leaves no line for it and keeps
-the other two, and the `op=specialist-lines` line reports `kept=2 withheld=<that name>`;
-clearing the store restores the line on the next run; a malformed store removes nothing and
-reports `withheld=store-unreadable`. The pre-existing cases run unchanged with no store on
-disk.
-
-**Route, `platform/ui/server/routes/admin/__tests__/agents.test.ts`.** The harness mocks
-`PLATFORM_ROOT` to a temp tree; the real bootstrap script is copied into
-`<platformRoot>/scripts/lib/` so the exec runs the shipped code rather than a stub. A
-disable leaves no `specialists:<name>` line in the account's AGENTS.md; the following
-enable puts it back.
-
-**MCP, `platform/plugins/admin/mcp/src/__tests__/specialist-registry.test.ts`
-(`node:test`).** A temp account with three AGENTS.md entries: one live file, one named by
-the store, one neither. Asserts `ok`, `disabled (operator)`, `missing file`, and
-`missing=1 disabled=1`. A `missing file` line for a name in the store is a failure.
-
-## Out of scope
-
-- The disable mechanism, the quarantine directory, and the store format (Task 1996).
-- What AGENTS.md is for, and its append-only posture for anything that is not a specialist
-  routing line.
-- The `op=agent-parity` check, which already covers store-versus-directory drift.
-- `AGENTS.md` write permissions, which is Task 2057.

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

@@ -1,127 +0,0 @@
-# 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

@@ -1,150 +0,0 @@
-# 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/docs/superpowers/specs/2026-07-28-task-2097-email-signature-set-design.md

@@ -1,155 +0,0 @@
-# Task 2097 — `email-signature-set` design
-
-Date 2026-07-28. Lane *Platform / email · signature provisioning*.
-Task file: [`.tasks/pending/2097-email-signature-setter-so-the-deterministic-loader-can-be-populated.md`](../../../../.tasks/pending/2097-email-signature-setter-so-the-deterministic-loader-can-be-populated.md).
-
-## Problem
-
-`email-draft` appends an account's signature deterministically, with no model judgement, at
-[`compose.ts:113`](../../../plugins/email/mcp/src/lib/compose.ts). It calls `loadSignature(sigDir)` then
-`applySignature`, where `loadSignature` (Task 1952,
-[`signature.ts:24`](../../../plugins/email/mcp/src/lib/signature.ts)) reads three fixed-convention files at the
-account root: `email-signature.txt`, `email-signature.html`, `email-signature.font`.
-
-Nothing in the platform writes those files. Task 1952 shipped the reader with no writer, so the
-path-and-format convention lives only in code and no account can be provisioned. On the G.L. Smith
-account none of the three exist, `applied` was false, no signature was appended, and a drafting
-subagent with no file-read tool reconstructed the HTML from a memory node and pulled a stale logo
-into a client draft.
-
-The failure is not a model ignoring a rule. The deterministic path works; it had no files to read.
-
-## Outcome
-
-An account's signature is installed into the loader's exact path and format through a sanctioned,
-discoverable tool, and every subsequent draft carries it byte-for-byte with no model-authored
-signature markup.
-
-## Architecture
-
-`lib/signature.ts` becomes the single owner of the signature convention in both directions. Read and
-write cannot drift because one file defines the base path, the three extensions, and the font
-trimming for both.
-
-| Unit | Responsibility | Depends on |
-|---|---|---|
-| `lib/signature.ts` → `signatureDirFor(accountId)` | Resolve the one directory an account's signature lives in | `attachment-resolve.ts` → `accountDirFor`, `process.env.ACCOUNT_DIR` |
-| `lib/signature.ts` → `saveSignature(accountDir, parts)` | Write present parts, remove absent ones, report both | `node:fs` |
-| `lib/signature.ts` → `loadSignature` / `applySignature` | Unchanged (Task 1952) | — |
-| `tools/email-signature-set.ts` | Param refusals, call `saveSignature`, log, format the response | `lib/signature.ts` |
-| `lib/compose.ts` | Swaps its inline dir expression for `signatureDirFor` | `lib/signature.ts` |
-
-### Directory resolution
-
-`compose.ts:113` currently resolves the read directory inline as
-`accountDirFor(accountId) || process.env.ACCOUNT_DIR`. The setter must write to the identical
-directory in every environment, so that expression moves into `signatureDirFor(accountId)` and both
-sides call it. Substituting the identical expression leaves `compose.ts` behaviour unchanged; the
-point is that "which directory" now has one definition rather than two copies that can diverge.
-
-Writing to `accountDirFor(accountId)` alone was rejected: on a spawn where `PLATFORM_ROOT` is absent
-but `ACCOUNT_DIR` is set, the setter would refuse while drafts would have read the file fine.
-
-## Behaviour
-
-Parameters, all optional strings: `text`, `html`, `font`. The account is the caller's `accountId`,
-the same authority `email-draft` uses. There is no `mailbox` parameter — a signature is account-scoped,
-because `loadSignature` reads one account root and knows nothing about mailboxes.
-
-| Input | Effect on `email-signature.<ext>` |
-|---|---|
-| `text` present | `.txt` written byte-for-byte verbatim, no reflow, no re-encoding |
-| `html` present | `.html` written byte-for-byte verbatim |
-| `font` present | `.font` written trimmed, matching `loadSignature`'s trim-on-read |
-| any one absent | that file removed if it exists; absence of the file is not an error |
-| all three absent | refused, nothing on disk is touched |
-| directory unresolvable | refused, nothing on disk is touched |
-
-Absent and empty are different inputs. A parameter is absent only when it is not supplied; a supplied
-empty string is present, so it writes an empty file and counts toward the all-three-absent check. That
-follows from writing verbatim: the tool stores what it was given rather than second-guessing it. The
-consequence is that an empty `.txt` makes the next draft report `applied` true while appending
-nothing visible, which is why an empty string is a deliberate act and omission is the way to remove.
-
-The removal rule is what makes a text-only call clear a stale `.html` rather than leave it to keep
-appending. The all-three-absent refusal is what stops a mis-shaped call silently wiping a working
-signature; removal stays reachable, but only as a side effect of setting something.
-
-The response names the resolved paths written and the resolved paths removed, so the caller sees the
-account root it landed in rather than trusting it.
-
-## Failure handling
-
-Files are written in the fixed order `.txt`, `.html`, `.font`. A filesystem error surfaces verbatim
-naming the offending path and the paths already written, so a half-applied state is reported rather
-than hidden. There is no transactional rollback: the task does not ask for one, and reaching the
-partial state requires a filesystem fault mid-call.
-
-## Observability
-
-`[email-signature-set] op=write accountId=<first-8> files=<written> removed=<removed>` on every
-successful write. The task specifies the line through `files=`; `removed=` is added because the task
-mandates removal as a behaviour and mandates that provisioning be auditable, and an unlogged removal
-is not auditable.
-
-The existing `[email-draft] op=signature applied=<bool> asset=<path>` line stays the per-draft
-signal. An account that has run the setter shows `applied=true` on its next draft. That pair is the
-end-to-end evidence: a write line naming the files, then a draft line reporting them applied.
-
-## Registration
-
-`ADMIN_CORE_TOOLS` is named in the task file but does not exist — `grep -rn 'ADMIN_CORE_TOOLS\s*[:=]'`
-over `platform/` returns nothing, and the name survives only in comments. The live surfaces are:
-
-1. `mcp/src/index.ts` — `eagerTool(server, name, description, zodShape, handler)`.
-2. `PLUGIN.md` — a `tools:` entry (`riskClass: write_local`, `publicAllowlist: false`,
-   `adminAllowlist: false`, matching `email-setup`), a clause in the frontmatter `description:` prose,
-   an operator-docs bullet, and a skills-table row for the new skill.
-3. `platform/templates/specialists/agents/personal-assistant.md` — the `tools:` frontmatter grant, the
-   canonical per-tool permission surface since Task 453.
-
-`riskClass: write_local` is correct because the tool writes account-local files and sends nothing
-outbound, which is the same class `email-setup` carries.
-
-## Skill
-
-`platform/plugins/email/skills/email-signature/SKILL.md`, activated when the operator asks to set or
-change an email signature. It states the loader convention, and three standing rules:
-
-- A signature is installed only through `email-signature-set`. Hand-writing the three files is not a
-  documented path.
-- The agent never hand-builds a signature inside a draft body, because `email-draft` applies the
-  stored one automatically and a hand-built one both duplicates it and drifts from the asset.
-- The signature content is read from the operator's own source of truth and passed through verbatim.
-  Reconstructing markup from memory or from stripped graph text is what put the stale logo in a
-  client draft.
-
-Written as outcomes and constraints, not a step recipe, per `maxy-code/CLAUDE.md`.
-
-## Testing
-
-Added to the plugin's existing vitest surface at `mcp/src/__tests__/`, not substituted for it.
-
-- Round trip: set all three, `loadSignature` returns the exact values, `applySignature` reports
-  `applied` true.
-- Verbatim: text and html land byte-identical, trailing newlines and all; font lands trimmed.
-- Text-only call writes `.txt` and removes a pre-existing `.html` and `.font`, so a later draft
-  carries no stale HTML.
-- All-three-absent call is refused and leaves pre-existing files untouched.
-- Unresolvable directory is refused.
-- A draft composed after a successful set carries body and html exactly equal to `applySignature`
-  output, with no model-authored signature text.
-- `signatureDirFor` prefers `accountDirFor` and falls back to `ACCOUNT_DIR`.
-- A supplied empty string writes an empty file and does not count as absent.
-- Existing `signature.test.ts` stays green.
-
-## Out of scope
-
-- Making `applied=false` a fail-closed refusal on client-facing drafts. Operator scoped this out on
-  2026-07-28 as separate hardening; deliberately not filed.
-- The one-off G.L. Smith provisioning and the stale memory-node deletion. That is a runtime action on
-  the live install, performed through the tool this task ships.
-- Any change to `loadSignature` / `applySignature` behaviour (Task 1952). `signatureDirFor` moves an
-  expression out of `compose.ts`; neither function's behaviour changes.
-- The drafts list/verify capability, which is
-  [Task 2098](../../../../.tasks/pending/2098-email-drafts-list-verify-tool-so-draft-presence-is-confirmable.md).