@rubytech/create-sitedesk-code 0.1.508 → 0.1.510

package/payload/platform/docs/superpowers/specs/2026-07-26-task-1926-portal-push-concurrency-guard-design.md

@@ -0,0 +1,200 @@
+# Task 1926 — same-account portal push concurrency guard (design)
+
+**Date:** 2026-07-26
+**Task:** [`.tasks/1926-concurrent-same-account-portal-push-lets-the-pre-stage-clear-delete-the-live-tree.md`](../../../../.tasks/1926-concurrent-same-account-portal-push-lets-the-pre-stage-clear-delete-the-live-tree.md)
+**Touches:** `platform/plugins/cloudflare/bin/portal-index-push.mjs`, `platform/plugins/cloudflare/mcp/__tests__/portal-index-push.test.ts`
+
+## Problem
+
+`pushAccount` stages an account's file index at `next = currentGeneration + 1`, flips
+the `directory_state` pointer to `next`, then sweeps every other generation. Task 1923
+added a pre-stage `DELETE FROM directory WHERE accountId = ? AND generation = ?` bound
+to `next`, so a stage that died mid-batch could self-heal instead of colliding forever
+on `UNIQUE (accountId, relPath, generation)`.
+
+Two pushes of one account break that. The second writer reads `current = 5` before the
+first writer's flip, computes `next = 6`, and by the time its pre-stage DELETE runs the
+pointer already names generation 6. The DELETE removes the live tree. A client listing
+in the gap between that DELETE and the re-insert sees an empty portal.
+
+The overlap is reachable: the admin server's 60s loop calls `pushAllAccounts`, and a
+hand-run `node portal-index-push.mjs --account <id>` calls the same `pushAccount` from a
+separate OS process.
+
+## What success looks like
+
+Two concurrent pushes of one account never leave a reader seeing an empty or partial
+tree, and never delete rows at the pointer's generation.
+
+## Why the three candidate approaches in the task file were rejected
+
+**A per-account advisory lock.** The two racers are separate OS processes. A JavaScript
+mutex inside the admin server does not exist in the CLI process, so it guards nothing.
+A lock that does work across processes has to live in D1, which means new columns, a
+lease, and a lease expiry. A lease expiry reintroduces the wedge class Task 1923 just
+removed: a holder that dies wedges the account until the lease runs out, and a push
+slower than its lease keeps writing after another writer has taken over.
+
+**`next` from `MAX(generation)` alone.** This stops two writers sharing a staging
+generation, but the slower writer still flips the pointer down onto its own generation
+after the faster writer has already swept it. The reader still sees an empty tree, so
+the success criterion is not met.
+
+**Scoping the clear to `generation = next AND generation != current`.** `current` is a
+value read at the top of the push. By the time the DELETE runs, the pointer has moved.
+Re-reading the pointer immediately before the DELETE narrows the window without closing
+it, because the peer can flip between the re-read and the DELETE.
+
+## Design
+
+Three changes to `pushAccount`. No lock, no lease, no schema change, no new table.
+
+### 1. Claim a generation above everything that exists
+
+Keep the existing pointer read, and add one statement beside it:
+
+```sql
+SELECT MAX(generation) AS g FROM directory WHERE accountId = ?
+```
+
+`next = Math.max(current, maxStagedGeneration) + 1`.
+
+A peer that has already inserted at least one row is visible in that MAX, so the two
+writers claim different generations and neither stages into the other's rows.
+
+Two statements rather than one nested `UNION ALL`: each is trivially readable, each is
+trivially fakeable in a test, and the pointer read stays the push's first statement,
+which an existing test asserts.
+
+### 2. The flip only ever moves the pointer forward
+
+```sql
+INSERT INTO directory_state (accountId, currentGeneration) VALUES (?, ?)
+ON CONFLICT (accountId) DO UPDATE SET currentGeneration = excluded.currentGeneration
+WHERE excluded.currentGeneration > directory_state.currentGeneration
+```
+
+SQLite has supported a `WHERE` clause on upsert's `DO UPDATE` since 3.24, and D1 is
+SQLite. This is what makes a losing writer harmless: it cannot drag readers back onto a
+generation the winner has already swept.
+
+The D1 client returns rows, not affected-row meta, so the flip is followed by a pointer
+readback. That readback is the branch point:
+
+- **Pointer equals `next`.** We won. Log `op=flip`, sweep, verify, return. Unchanged
+  behaviour.
+- **Pointer is above `next`.** A peer won. Log
+  `op=stage-contended account=<id> generation=<next> pointer=<actual> action=superseded`
+  and return without sweeping and without verifying. Both of those would measure the
+  peer's tree against our expected row count, and `op=verify` would read as a failure
+  when nothing failed.
+
+Our staged rows at the losing generation are left in place. They are invisible (no
+reader sees a generation the pointer does not name) and the winner's next sweep collects
+them.
+
+### 3. The sweep only ever removes older generations
+
+```sql
+DELETE FROM directory WHERE accountId = ? AND generation < ?
+```
+
+`< next` rather than `!= next`, so a writer never deletes a peer's higher in-flight
+stage. Rows above `next` from an abandoned stage still converge: the following cycle
+claims a generation above them and sweeps them once it flips.
+
+### 4. The Task 1923 pre-stage clear is removed
+
+Because `next` is now always above every existing generation for the account, the orphan
+`SELECT COUNT(*) ... generation = next` can only ever return 0 and the pre-stage DELETE
+can never match a row. Leaving unreachable code whose comment claims it is the wedge
+heal would be false narration, so the orphan count, the DELETE, the `op=stage-clear` log
+line and its two tests go.
+
+Task 1923's outcome is preserved by construction and is stronger than before. A stage
+that died mid-batch leaves rows at generation 6; the next run claims 7, so there is no
+UNIQUE collision to freeze on, and the gen-6 orphans are swept after the flip. The heal
+now happens with no DELETE before the flip at all, which is exactly what removes this
+task's hazard rather than narrowing it.
+
+This was confirmed with the operator before the spec was written, because Task 1926
+lists Task 1923's heal as out of scope.
+
+## Cases covered, and the one left fail-closed
+
+**Peer reads the generation after we have staged a row.** It claims a higher generation.
+Both pushes complete. The forward-only flip picks the winner. The reader sees the old
+complete tree, then one complete new tree. Neither push fails.
+
+**Both read the generation before either inserts.** Both claim the same generation. The
+second writer's first INSERT hits `UNIQUE (accountId, relPath, generation)` and that push
+throws. Both walks resolve the same exposed set and `walkExposed` emits the exposed dirs
+in the same order, so the second writer collides on its first row and contributes
+nothing. The reader is safe: the winner's tree is complete and the pointer never moved
+backward. The loser logs `op=failed` and the next 60s cycle succeeds.
+
+This second case is left fail-closed rather than retried. The task's success criterion is
+about what a reader can see, and a loud failure that self-corrects one cycle later meets
+it. A retry-on-collision path would be an invented requirement.
+
+**The one residual, stated rather than fixed.** The claim above relies on both walks
+starting with the same row. If the account's `SCHEMA.md` or `data-portal.json` changes in
+the window between the two generation reads, the two walks can begin with different rows,
+so the second writer contributes some non-overlapping rows at the shared generation before
+colliding on a shared one. The winner then flips onto its own complete tree plus those few
+extra rows. That is not an empty tree and not a partial one, so it does not breach the
+success criterion, and the next cycle's sweep removes the whole generation. No task file is
+filed for it because nothing is deferred: the case is inside what this design covers, and
+its outcome is a stale row for one cycle rather than a reader-visible break.
+
+## Observability
+
+`op=stage-contended account=<id> generation=<next> pointer=<actual> action=superseded`
+is emitted when a push's flip was superseded by a peer. This deviates from the task
+file's `action=<waited|skipped>` wording: the design never waits and never skips work, so
+neither value describes what happened. `superseded` names the actual outcome, and
+`pointer=` names the generation that won, which is what an operator needs to correlate
+the two runs.
+
+`op=stage-clear` is retired with the code that emitted it. The task file's line that a
+`stage-clear` with `cleared=` equal to the live tree size must never appear is satisfied
+absolutely: no `stage-clear` line can appear at all.
+
+## Testing
+
+Both new tests drive two interleaved `pushAccount` calls against one shared fake store
+and snapshot the reader's view after every statement. The assertion is the success
+criterion stated directly: the visible tree is never empty and never a strict subset of
+a complete tree.
+
+1. **The task file's interleave.** Writer B reads the generation, then pauses. Writer A
+   runs to completion. B resumes. Red on current code, because B's pre-stage DELETE binds
+   the generation the pointer now names and the snapshot goes empty. Green after, because
+   B collides on UNIQUE and A's tree is untouched. This test also asserts that no DELETE
+   is ever issued naming the pointer's current generation, which is the other half of the
+   success criterion.
+
+2. **The higher-claim interleave.** Writer A stages fully but pauses before its flip.
+   Writer B reads the generation, sees A's staged rows in the MAX, claims the next one up,
+   and completes. A resumes and its flip is a no-op. Asserts the pointer never moves
+   backward, that A emits `op=stage-contended` with `action=superseded`, and that A
+   issues no sweep.
+
+The existing 27 tests stay green apart from the two Task 1923 stage-clear tests, which
+are removed with the code they cover.
+
+## Scope boundaries
+
+**In scope:** the generation claim, the forward-only flip, the backward-only sweep, the
+removal of the pre-stage clear, and the two-writer regression tests.
+
+**Out of scope:** INSERT batching (Task 1842). Cross-account contention (separate
+generation counters, no contention). Any change to `runTargets`, `recordSuccess`, or the
+portal reader in `files.ts`.
+
+## Deployment
+
+`portal-index-push.mjs` ships inside the installer payload and is inlined into the admin
+server bundle. No D1 migration is required: every statement runs against the existing
+`directory` and `directory_state` tables as defined in
+`platform/plugins/cloudflare/skills/data-portal/schema.sql`.

package/payload/platform/docs/superpowers/specs/2026-07-26-task-2014-ui-suite-nondeterminism-design.md

@@ -0,0 +1,169 @@
+# Task 2014 design — cut the jsdom the `platform/ui` suite does not use
+
+Date: 2026-07-26
+Task: `.tasks/pending/2014-platform-ui-suite-is-nondeterministic-under-parallel-load.md`
+Supersedes brief: 1765, folded into 2014 on 2026-07-26
+
+## The measurement this design rests on
+
+All figures from the dev Mac, Node 22.22.0, vitest 4.1.2, worktree
+`task-2014-ui-suite-nondeterminism`, 2026-07-26.
+
+### Most apparent worktree flakiness is missing build output, not flakiness
+
+`platform/node_modules` and `platform/lib/*/dist` are gitignored build output. A
+fresh worktree has neither. Four full-suite runs, each after adding one more
+piece of provisioning:
+
+| Run | Worktree state | Failed | Duration |
+|---|---|---|---|
+| 1 | `platform/ui` deps only | 63 files / 32 tests | 435s |
+| 2 | + 3 libs built | 5 files / 8 tests | 180s |
+| 3 | + `platform` deps | 5 files / 3 tests | 111s |
+| 4 | + all 24 libs built | 0 | 143s |
+
+Runs 1 and 2 failed on `Cannot find module .../dist/index.js` and
+`Failed to resolve import "neo4j-driver"`. Those are absent artifacts, not
+timing. Only run 3's three failures are the defect this task describes, and all
+three are in the brief's population: both `/login/start` sub-account cases in
+`whatsapp-self-or-house-scope.test.ts` at 5013ms and 515ms, and
+`whatsapp-conversation-graph-state-projection.test.ts` "sub-account all-senders
+mode returns only its bound thread" at 5017ms. 5000ms is the vitest default
+`testTimeout`.
+
+### Environment setup costs six times what the tests cost
+
+Run 4, fully green:
+
+```
+tests        267s
+environment 1571s
+import       257s
+setup        196s
+transform     42s
+```
+
+`vitest.config.ts` sets `environment: 'jsdom'` globally. 530 test files pay it.
+
+### Roughly half the suite boots a DOM it never touches
+
+266 `.test.ts` files do not declare `@vitest-environment node`. Both runs
+back to back, same machine load:
+
+| | Duration | environment CPU |
+|---|---|---|
+| as-is (jsdom) | 103.0s | 1317.6s |
+| `--environment node` | 30.9s | 0.074s |
+
+Three consecutive node-environment passes over those 266 files agreed on 17
+`.ts` files that genuinely need a DOM. A file that appeared in only one pass
+(`route-cache-watchers.test.ts`) is the known flake, not a DOM dependency. A
+`.tsx` file in the failure list arrived because vitest CLI arguments are
+substring filters rather than exact paths.
+
+So the suite's problem is not 4757 tests. The tests are 267s of CPU. It is that
+about half the files run a browser DOM environment for nothing, and that is the
+CPU starving the workers the named tests race against.
+
+### Machine context
+
+The dev Mac ran these measurements at load average 100 to 350 with 60 `claude`
+processes across six peer worktree sessions. Self-contention from 20 vitest
+forks is not the only contender for CPU, and any verification has to record the
+load it ran under or a red run cannot be attributed.
+
+## Design
+
+### 1. Route the test environment by file extension
+
+`platform/ui/vitest.config.ts` replaces its single global `environment: 'jsdom'`
+with two projects:
+
+- `dom`: `**/*.{test,spec}.?(c|m)[jt]sx`, environment `jsdom`.
+- `node`: `**/*.{test,spec}.?(c|m)[jt]s` plus `../scripts/__tests__/**`,
+  environment `node`.
+
+The existing `resolve.dedupe`, `setupFiles`, `globals`, and `exclude` settings
+carry into both projects unchanged.
+
+The rule is structural, not a maintained list: a test that renders JSX gets a
+DOM, and anything else opts in explicitly. No `.tsx` file is edited.
+
+### 2. Seventeen `.ts` files opt back into jsdom
+
+Each gets `// @vitest-environment jsdom` with a short reason. Verified on vitest
+4.1.2 that a per-file docblock overrides a project's `environment` setting.
+
+```
+app/__tests__/spinning-class-global.test.ts
+app/__tests__/wa-viewer-width.test.ts
+app/graph/__tests__/side-panel-helpers.test.ts
+app/hooks/__tests__/useCopyFeedback.test.ts
+app/hooks/__tests__/useMediaQuery.test.ts
+app/hooks/__tests__/useVoiceRecorder.deviceId.test.ts
+app/hooks/__tests__/useVoiceRecorder.mic-result.test.ts
+app/lib/__tests__/admin-auth-login-remote-auth.test.ts
+app/lib/__tests__/switch-account-scope.test.ts
+app/lib/__tests__/use-admin-auth-claude-connected.test.ts
+app/lib/__tests__/use-admin-auth-heartbeat-remote-auth.test.ts
+app/lib/__tests__/useAdminFetch.test.ts
+app/lib/__tests__/useSubAccountSwitcher.test.ts
+app/public/__tests__/extract-seed-question.test.ts
+app/whatsapp/__tests__/useTranscriptStream-activity.test.ts
+app/whatsapp/__tests__/useTranscriptStream-endpoint.test.ts
+app/whatsapp/__tests__/useTranscriptStream.test.ts
+```
+
+A `.ts` test that needs a DOM and lacks the docblock fails loudly on
+`document is not defined`. It does not pass silently.
+
+### 3. A prebuild gate so the waste cannot creep back
+
+New `platform/ui/scripts/check-jsdom-budget.mjs`, joining the 24 checks already
+in the `prebuild` script. It counts the files that will boot jsdom, which is
+every `.test.tsx`/`.spec.tsx` plus every `.ts` test declaring the jsdom
+docblock, and fails the build when that count exceeds a ceiling written in the
+script. Adding a jsdom file becomes a deliberate one-line bump with a reason,
+not an accident. The failure message names the files above the ceiling and the
+CPU cost per jsdom file measured here, so a reader knows what the number buys.
+
+### 4. The 141 existing `@vitest-environment node` docblocks stay
+
+They remain accurate and are now redundant. Removing them is 141 files of churn
+for no behaviour change.
+
+## What this does not claim
+
+Removing the environment waste reduces the contention the named tests race
+against. It is not proven, before measurement, that the ten named tests stop
+failing. If group A's long-press tests still race React Testing Library's
+1000ms `findBy` default once contention drops, that is a second and separate
+lever, and it gets measured and brought back rather than stacked on top as a
+speculative second fix.
+
+## Verification
+
+**Group A and the suite.** Ten consecutive `npm test` runs in `platform/ui` on
+the merged branch, `uptime` captured before and after each run, exit code and
+any `×` lines collected to one file. Success is ten `exit=0` and zero `×`
+matches across the collection, reported alongside the load each ran under. A red
+run with its load recorded is attributable; a red run without is not.
+
+**Group B.** Ten runs do not test a one-in-twenty failure rate. Instead measure
+the wall-clock cost of the four group B seed calls under full-suite parallel
+load, before and after the change, and state the headroom inside the 5000ms
+default. The measurement is the evidence, not the run count.
+
+**The jsdom cut itself.** The suite must still report 530 files and 4757 tests.
+A file silently dropping out of the run because a glob missed it would look like
+a pass.
+
+## Out of scope
+
+- The `platform/lib` build artifacts that made runs 1 to 3 look flaky. That is
+  worktree provisioning friction and gets its own task file.
+- A blanket `testTimeout` bump, excluded by the brief.
+- Deleting, skipping, or loosening the four group B tests, excluded by the
+  brief: they are the only place the cross-account 403 ordering is asserted.
+- Removing the 141 redundant node docblocks.
+- Any product change to the whatsapp routes, the data browser, or graph-write.

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

@@ -2,6 +2,7 @@
 name: admin
 surface: platform
 description: "Platform administration plugin. Provides system-status, public-hostname (deterministic Cloudflare public-URL resolver, single call returning the operator's canonical hostname so agents never guess property names on :CloudflareHostname nodes), admin-hostname (the admin-host twin of public-hostname — resolves the host that serves /calendar and the rest of the admin shell behind sign-in from the same ingress + alias + operator files, so agents point the operator at the admin /calendar URL instead of the public host that 404s it), publish-site (move an extracted static-site tree under <accountDir>/sites/<slug>/, emit one canonical path slug, and refresh llms.txt at the site root — typed refusal taxonomy replaces the prior skill-prose contract), brand-settings, account-manage, capabilities-here (deterministic install-introspection — returns enabledPlugins, tier, models, installed platform + premium specialists, registered Claude Code agent types, and the brand block as a single JSON object; the canonical tool for grounding any claim about what is enabled on the current account), account-update, the multi-account managed-service lifecycle tools (account_list, account_create, account_delete, account_purge, account_channel_routing, account_channel_routing_set — one Rubytech operator hosting N client accounts on one house install; create/delete/purge are operator-only and purge is two-step with a typed confirmation; account_create requires the client business owner's real name (ownerName), refusing a blank or the placeholder "Owner" and seeding it onto the sub-account's owner AdminUser and owner Person, and requires the owner's IANA timezone (timezone) — refusing a blank or a non-IANA value — seeding it onto the owner UserProfile marked owner-set so scheduling reads the owner's real zone from the start rather than the box's server default, while a managing house admin (its userId) is optional — when supplied it is validated as a live house admin and recorded as the sub-account's managingAdminUserId, and when omitted the sub-account is unmanaged and its passive-intake tasks route to the install's primary admin; account_reassign_admin repoints a client sub-account's managing admin to another live house admin (the repair path for a dangling managingAdminUserId, or to record one on an unmanaged account); account_roster is the canonical per-account identity view — one row per sub-account giving business name, role, the managing house admin resolved to a name with status (assigned/absent/dangling), the business owner from the graph with status (named/nameless), and the WhatsApp account-manager binding if any, each field carrying what it means and does not (managing admin is the responsible house team member not the owner; account manager is WhatsApp routing only with no admin rights), so the agent never stitches admin-list + account.json + whatsapp-config; account_set_owner_name names (or corrects) a client sub-account's business owner by writing the owned Person — the canonical name source — refusing a blank or the placeholder "Owner", the guarded repair for a nameless owner (the standing identity-audit op=nameless-owned-person detector); account_channel_routing_set repoints the install's single WhatsApp/Telegram inbound stream to a different sub-account), admin-add (refuses on a client sub-account, where admin access is already install-wide so a per-operator seat grants nothing — the sub-account's one identity, its business owner, is set at account creation; the house account, where operators hold PIN logins and admins[] rows, is unchanged), admin-remove (refuses to remove a house admin who still manages one or more client sub-accounts, naming them so the operator reassigns each with account_reassign_admin first — never silently orphans them), admin-list, admin-update-pin, agent-list, agent-config-read, logs-read, cpu-triage-start and cpu-triage-read (the two-call device CPU diagnostic — start spawns a detached sampling run across at least one full 120s reconcile cycle and returns a run handle immediately, read returns running/complete/failed with the per-core distribution; no admin tool blocks through a sampling window, and no spot reading is obtainable), plugin-read, skill-load (one-call resolve+read for SKILL.md by skill name, the canonical primitive for loading a named skill; plugin-read remains the reader for references/* and PLUGIN.md), skill-search (free-text intent → skill resolver: ranks every plugin skill's SKILL.md name+description against a query and returns the top owners with their canonical skills/<slug>/ path, so intent→skill mapping survives the available-skills menu leaving context after a compaction), store-skill (deterministic write counterpart to plugin-read; persists operator-authored skills as plugin files under the active account), session-reset, session-resume, wifi, and action-approval tools (action-pending, action-approve, action-reject, action-edit) for managing the SiteDesk platform."
+account-owned-files: [{"file": "webchat-channel-bindings.json", "description": "Routes this account's inbound admin webchat messages. Written by the session manager's webchat-channel-store."}, {"file": "wa-channel-bindings.json", "description": "Routes this account's inbound WhatsApp messages. Written by the session manager's wa-channel-store, which runs on every brand whether or not the whatsapp plugin ships."}, {"file": "telegram-channel-bindings.json", "description": "Routes this account's inbound Telegram messages. Written by the session manager's telegram-channel-store, which runs on every brand whether or not the telegram plugin ships."}, {"file": "canonical-webchat-session.json", "description": "Pins the account's canonical webchat session. Written by the admin UI server."}, {"file": "session-titles.json", "description": "Operator renames of sessions. Written by the session manager's title stores."}, {"file": "agents-disabled.json", "description": "Names the agents the operator switched off. Written by the admin agents route; provision reads it to re-apply the disables and never creates it."}]
 tools:
   - name: system-status
     publicAllowlist: false

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what SiteDesk ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:b15d0e491d957f75523ecf7056f8004bafcdf448767c0c3dd64b40a73926b58b
+content-hash: sha256:86e768fb27dbcb38fc304ace12dbca3462943fcb58435cea6925ebf2469a0647
 brand: sitedesk-code
 product-name: SiteDesk
 ---
@@ -3189,8 +3189,8 @@ explicit `?plugin=` parameter, not inferred from `--` in the slug.
 
 | Route | Behaviour |
 |-------|-----------|
-| `GET /api/admin/agents` | Session-scoped. Lists the session account's public `agents/*/` dirs (never the `admin` agent), its user-created specialists from `plugins/*/agents/*.md`, and its shipped specialists, each row tagged `kind` and `origin` and carrying `risk`, `worstTool`, `unresolved` and `disabled`. Returns `{agents, accountId, skipped, specialistsSkipped, shippedSkipped}`. 401 when the session maps to no account. |
-| `GET /api/admin/agents/:slug` | Session-scoped. Without `?plugin=` or `?origin=`, returns a public agent's config fields + four owned docs + a `present` map (a missing or unreadable doc is `''`/`present.<role>=false`, never a 500). With `?plugin=`, that plugin's user-created specialist; with `?origin=shipped`, the shipped one. Both specialist shapes add `{risk, worstTool, unresolved, byTool, disabled}`, where `byTool` is one class per declared tool. Selection is explicit rather than inferred, because a premium file and a user-created specialist under a plugin of the same name produce the same slug. Unknown 404s, 401 as above. |
+| `GET /api/admin/agents` | Session-scoped. Lists the session account's public `agents/*/` dirs (never the `admin` agent), its user-created specialists from `plugins/*/agents/*.md`, and its shipped specialists, each row tagged `kind` and `origin` and carrying `risk`, `riskiestTool`, `unresolved` and `disabled`. Returns `{agents, accountId, skipped, specialistsSkipped, shippedSkipped}`. 401 when the session maps to no account. |
+| `GET /api/admin/agents/:slug` | Session-scoped. Without `?plugin=` or `?origin=`, returns a public agent's config fields + four owned docs + a `present` map (a missing or unreadable doc is `''`/`present.<role>=false`, never a 500). With `?plugin=`, that plugin's user-created specialist; with `?origin=shipped`, the shipped one. Both specialist shapes add `{risk, riskiestTool, unresolved, byTool, disabled}`, where `byTool` is one class per declared tool. Selection is explicit rather than inferred, because a premium file and a user-created specialist under a plugin of the same name produce the same slug. Unknown 404s, 401 as above. |
 | `POST /api/admin/agents/:slug/disable?accountId=` | Shipped agents only, enforced here: a slug present in none of the three shipped directories 404s. Moves the file from `specialists/agents/` to `specialists/agents-disabled/` and records the basename in the 0600 store. Returns `{ok, moved}`; `moved:false` means the agent existed only as a bundled template, so nothing was there to move and the store entry is what stops the next provisioning run delivering it. The store is read strictly before anything moves, so an unreadable store 500s with the file untouched rather than rewriting the file whole from an empty set and dropping every other disabled agent. Same `accountId` contract as delete. |
 | `POST /api/admin/agents/:slug/enable?accountId=` | Covers both of disable's outcomes. Returns `{ok, restored}`: a quarantined file moves back (`restored:true`); a bundled-only agent has nothing to move, so clearing the store entry is the whole job (`restored:false`), which is what stops provisioning withholding it. Treating that second case as "nothing to restore" made disable a one-way door. 404 only when neither directory nor store knows the agent. |
 | `DELETE /api/admin/agents/:slug?accountId=` | Public agents only, on the named validated account. Removes the dir after `deleteAgentProjection`; refuses the `admin` slug (403) and a missing/unknown `accountId` (400) with no write. Loud-fail: a graph-cleanup throw aborts the file removal. |
@@ -3220,10 +3220,15 @@ Agents page survived undiagnosed on a multi-account install.
   `reason=<graph-cleanup-failed|rm-error>` on failure (files preserved on a
   graph-cleanup throw).
 - `op=classify account=<id8> agent=<name> origin=<shipped|public|specialist>
-  risk=<green|amber|red> worstTool=<tool> tools=<n> unresolved=<comma-list|none>
+  risk=<green|amber|red> riskiestTool=<tool> tools=<n> unresolved=<comma-list|none>
   disabled=<bool>` — one line per classified agent per listing, so it fires on
-  every page load. `worstTool` makes a wrong class diagnosable without
-  re-deriving it. **A non-empty `unresolved=` is the one to act on**: the agent
+  every page load. `riskiestTool` makes a wrong class diagnosable without
+  re-deriving it. Its value is the FULL canonical tool name, while the card
+  renders only the segment after the plugin prefix. One load
+  showing `riskiest tool: memory-update` on the card and
+  `riskiestTool=mcp__plugin_memory_memory__memory-update` on this line is the
+  confirmation that both derive from one value.
+  **A non-empty `unresolved=` is the one to act on**: the agent
   is forced red, and the cause is that the built-in table or the registry
   mapping has drifted, not that the agent changed.
 - `op=risk-surface status=load-failed reason=<msg>` — the plugin registry did
@@ -5446,7 +5451,7 @@ If the initial Cloudflare login fails during setup, SiteDesk will fall back to a
 
 `maxy-edge.service` (always-on front door) classifies upstream errors and serves a brand-aware response. There are two distinct user-visible shapes; the right one depends on what failed.
 
-**Branded holding page (brand logo + "Starting") for ~10 s during an upgrade — this is expected and self-healing.** The edge process binds the public port immediately, but `maxy.service` (the upstream UI) takes ~10 s after restart to apply the neo4j schema and mount its 11 routes. Any browser navigation that lands during that window gets a self-contained HTML holding page that polls `/api/health` and reloads automatically once the upstream binds. The page renders the brand logo (inlined as a base64 data URI at edge boot from `<install>/server/public/brand/<assets.logo>`) and the brand display/body fonts (loaded from fonts.googleapis.com) — both paths bypass the unavailable upstream so the page never makes a same-origin asset fetch. When `brand.logoContainsName` is true the logo replaces the productName text; otherwise the page falls back to "SiteDesk is starting". No operator action required. The diagnostic line in `~/.maxy/logs/edge.log` is `[edge] upstream http error path=… err=connect ECONNREFUSED 127.0.0.1:<UPSTREAM_PORT> err-class=econnrefused-coldstart upstream=…` and disappears as soon as upstream binds. Boot-time confirmation that the logo resolved: `[edge] brand=<name> holding-logo=inlined assets-dir=<path>` — `holding-logo=missing` means the logo file wasn't found at `assets-dir`, the page degrades to text-only.
+**Branded holding page (brand logo + "Starting") for ~10 s during an upgrade — this is expected and self-healing.** The edge process binds the public port immediately, but `maxy.service` (the upstream UI) takes ~10 s after restart to apply the neo4j schema and mount its 11 routes. Any browser navigation that lands during that window gets a self-contained HTML holding page that polls `/api/health` and reloads automatically once the upstream binds. The page renders the brand logo (inlined as a base64 data URI at edge boot from `<install>/server/public/brand/<assets.logo>`) and the brand display/body fonts (loaded from fonts.googleapis.com) — both paths bypass the unavailable upstream so the page never makes a same-origin asset fetch. When `brand.logoContainsName` is true the logo replaces the productName text; otherwise the page falls back to "SiteDesk is starting". No operator action required. The diagnostic line in `~/.maxy/logs/edge.log` is `[edge] ts=<ISO-8601> upstream http error path=… err=connect ECONNREFUSED 127.0.0.1:<UPSTREAM_PORT> err-class=econnrefused-coldstart upstream=…` and disappears as soon as upstream binds. `ts=` is what lets a run of these be read as an outage with a start, an end and a duration, and cross-read against `journalctl --user -u <brand>-code.service`; `path=` carries the endpoint only, never the query string, because this line fires on paths whose query can hold a download signature, an OAuth code, or a customer phone number. Boot-time confirmation that the logo resolved: `[edge] brand=<name> holding-logo=inlined assets-dir=<path>` — `holding-logo=missing` means the logo file wasn't found at `assets-dir`, the page degrades to text-only.
 
 **Branded plain-text 502 ("Bad Gateway (SiteDesk unavailable)") — real upstream failure, not cold-start.** Any error class other than `ECONNREFUSED` (timeouts, resets, host-unreachable) returns the existing 502 path. The diagnostic line carries `err-class=other`. Read the log with `tail -200 ~/.maxy/logs/edge.log | rg 'err-class=other'` and check `~/.maxy/logs/server.log` for upstream stack traces — the upstream itself is the source.
 

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

@@ -9,6 +9,18 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-07-26 (0.1.510)
+
+- The admin screens load faster: page assets are now sent pre-compressed, and the sessions list reads from disk without holding up everything else on the server.
+- Fixed several admin screens that could answer for the wrong account when an install has more than one, including the calendar booking link, the logs search, and the chat settings.
+- When an account folder cannot be found, the error now says which condition it actually hit instead of blaming a missing file.
+
+## 2026-07-26 (0.1.509)
+
+- The Agents page now names the tool that set an agent's risk level, and shows it by its short name instead of the full internal path.
+- Publishing a site twice at the same time can no longer delete the live copy; the later publish now stands down instead of clearing the tree out from under the first.
+- A slow dashboard now records where the time actually went, so a sluggish load can be traced rather than guessed at.
+
 ## 2026-07-25 (0.1.508)
 
 - SiteDesk's screens now use a single, cleaner typeface throughout, and the old olive-green colour is gone.

package/payload/platform/plugins/business-assistant/PLUGIN.md

@@ -1,6 +1,7 @@
 ---
 name: business-assistant
 description: "Business assistant for small businesses. Handles customer enquiries, appointment booking, quote formatting, invoice generation, and daily briefings. Responds instantly, triages by urgency, and never lets a message fall through the cracks."
+account-owned-dirs: [{"dir": "e-sign", "description": "One folder per signed document, each holding that document's render-once base.pdf, its base.sha256, and the per-signer stamped copies. Written by the e-sign skill; the layout is skill-owned and recreated on the next document."}]
 metadata: {"platform":{"always":true,"embed":["admin"],"pluginKey":"business-assistant","optional":true,"recommended":true}}
 ---
 

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

@@ -1,6 +1,7 @@
 ---
 name: cloudflare
 description: Cloudflare operations — tunnel setup/reset, DNS, Pages hosting, D1 data capture, and dashboard guidance. Zero agent-facing MCP tools; every operation is the agent invoking `cloudflared` or `wrangler` directly via Bash, calling the Cloudflare API with a reused per-scope narrow token, or quoting a dashboard click-path the operator performs themselves.
+account-owned-files: [{"file": "data-portal.json", "description": "The account's data-portal folder index, written by bin/portal-index-push.mjs on every push."}]
 tools: []
 mcp-manifest: skip
 ---

package/payload/platform/plugins/cloudflare/bin/portal-index-push.mjs

@@ -122,7 +122,8 @@ export async function walkExposed(accountDir, exposed) {
  *           client: { query: (sql: string, params?: unknown[]) => Promise<Record<string, unknown>[]> },
  *           log: (line: string) => void, nowIso: string,
  *           exposeFolders?: string[], previousExposed?: string[] }} opts
- * @returns {Promise<{ exposed: string[], rows: number, schemaPresent: boolean }>}
+ * @returns {Promise<{ exposed: string[], rows: number, schemaPresent: boolean,
+ *                     generation?: number, superseded?: boolean }>}
  */
 export async function pushAccount(opts) {
   const { accountDir, accountId, client, log, nowIso } = opts
@@ -196,29 +197,26 @@ export async function pushAccount(opts) {
     [accountId],
   )
   const current = Number(state[0]?.currentGeneration ?? 0)
-  const next = current + 1
-
-  // Crash safety (Task 1923). A stage that died mid-batch — a D1 500 on one
-  // INSERT — leaves rows at `next` while the pointer stays at `current`. Every
-  // later run recomputes the same `next`, and its first colliding INSERT then
-  // hits UNIQUE(accountId, relPath, generation), so the index freezes at the
-  // stale generation until an operator hand-clears the orphans. Clearing `next`
-  // before staging lets a partial stage self-heal on the next cycle. Guarded on
-  // a non-zero count so the DELETE never precedes the flip on a clean cycle and
-  // the log line always means a recovered wedge. The count comes from a SELECT
-  // because the D1 client returns rows, not the affected-row meta.
-  const orphan = await client.query(
-    'SELECT COUNT(*) AS n FROM directory WHERE accountId = ? AND generation = ?',
-    [accountId, next],
+
+  // Claim a generation above EVERY generation this account already holds, not
+  // merely above the pointer (Task 1926). Two pushes of one account are
+  // reachable: the admin server's 60s loop and a hand-run `--account` are
+  // separate processes, so no in-process lock can see both. `current + 1` let
+  // the second writer claim the generation the first had just flipped onto and
+  // then delete it. A peer that has inserted even one row is visible in this
+  // MAX, so the two runs claim different generations.
+  //
+  // This also retires the Task 1923 pre-stage clear. That clear existed because
+  // a later run recomputed the SAME generation as a dead partial stage and
+  // collided on UNIQUE(accountId, relPath, generation); claiming above the
+  // orphans leaves nothing to collide with, and the post-flip sweep collects
+  // them. The clear was itself the DELETE a concurrent peer could aim at the
+  // live tree, so removing it removes the hazard rather than narrowing it.
+  const staged = await client.query(
+    'SELECT MAX(generation) AS g FROM directory WHERE accountId = ?',
+    [accountId],
   )
-  const orphanCount = Number(orphan[0]?.n ?? 0)
-  if (orphanCount > 0) {
-    await client.query('DELETE FROM directory WHERE accountId = ? AND generation = ?', [
-      accountId,
-      next,
-    ])
-    log(`${TAG} op=stage-clear account=${accountId} generation=${next} cleared=${orphanCount}`)
-  }
+  const next = Math.max(current, Number(staged[0]?.g ?? 0)) + 1
 
   for (const row of rows) {
     await client.query(
@@ -231,18 +229,56 @@ export async function pushAccount(opts) {
 
   // THE atomic point. Upsert rather than insert-or-update, so an account
   // publishing for the first time and one republishing take the same path.
+  //
+  // The WHERE moves the pointer FORWARD ONLY (Task 1926). Without it a writer
+  // that was overtaken while staging drags every reader back onto a generation
+  // the winner has already swept, which is an empty tree. SQLite has carried a
+  // WHERE on upsert's DO UPDATE since 3.24, and D1 is SQLite.
   await client.query(
     'INSERT INTO directory_state (accountId, currentGeneration) VALUES (?, ?) ' +
-      'ON CONFLICT (accountId) DO UPDATE SET currentGeneration = excluded.currentGeneration',
+      'ON CONFLICT (accountId) DO UPDATE SET currentGeneration = excluded.currentGeneration ' +
+      'WHERE excluded.currentGeneration > directory_state.currentGeneration',
     [accountId, next],
   )
+
+  // Read back rather than assume: the D1 client returns rows, not affected-row
+  // meta, so a suppressed flip is otherwise indistinguishable from an applied
+  // one.
+  const flipped = await client.query(
+    'SELECT currentGeneration FROM directory_state WHERE accountId = ?',
+    [accountId],
+  )
+  const pointer = Number(flipped[0]?.currentGeneration ?? 0)
+  if (pointer !== next) {
+    // A peer published while this run was staging. Its tree is live and
+    // complete, ours is invisible, and its rows are collected by the peer's
+    // next sweep. Sweeping or verifying from here would act on, and measure,
+    // the PEER's tree — reporting a failure where nothing failed. Logged rather
+    // than silent: a suppressed run is otherwise indistinguishable from one
+    // that never started.
+    log(
+      `${TAG} op=stage-contended account=${accountId} generation=${next} ` +
+        `pointer=${pointer} action=superseded`,
+    )
+    return {
+      exposed: r.exposed,
+      rows: rows.length,
+      schemaPresent: true,
+      generation: next,
+      superseded: true,
+    }
+  }
   log(`${TAG} op=flip account=${accountId} generation=${next}`)
 
   // Housekeeping only. A failure here leaves stale rows nothing reads, which is
   // waste rather than incorrectness — so it must not fail the publish that has
   // already succeeded.
   try {
-    await client.query('DELETE FROM directory WHERE accountId = ? AND generation != ?', [
+    // Strictly older only (Task 1926): `!= next` would delete a peer's HIGHER
+    // in-flight stage. Rows above `next` left by an abandoned stage still
+    // converge, because the next cycle claims a generation above them and
+    // sweeps them once it flips.
+    await client.query('DELETE FROM directory WHERE accountId = ? AND generation < ?', [
       accountId,
       next,
     ])
@@ -291,9 +327,13 @@ export function readState(platformRoot) {
 }
 
 /**
- * Written ONLY after op=verify, so a stale entry means the push stopped
- * succeeding rather than merely stopped logging. Read-modify-write per account
- * so one account's failure does not erase another's record.
+ * Written after a publish that reached the flip, so a stale entry means the
+ * push stopped succeeding rather than merely stopped logging. That includes a
+ * run superseded by a concurrent peer (Task 1926), which emits
+ * `op=stage-contended` instead of `op=verify`: the index WAS refreshed inside
+ * this cycle, by the peer, and recording otherwise would report a healthy
+ * account as never-ran. Read-modify-write per account so one account's failure
+ * does not erase another's record.
  * @param {string} platformRoot @param {string} accountId
  * @param {{lastPushMs: number, rows: number, exposed: string[]}} entry
  */