@rubytech/create-sitedesk-code 0.1.524 → 0.1.525

package/payload/platform/docs/superpowers/specs/2026-07-20-task-1829-platform-ui-typecheck-design.md

@@ -1,163 +0,0 @@
-# Task 1829 — package-wide typecheck for `platform/ui` (design)
-
-**Date:** 2026-07-20
-**Task:** [`.tasks/pending/1829-platform-ui-typechecks-nowhere-so-every-type-contract-is-advisory.md`](../../../../.tasks/pending/1829-platform-ui-typechecks-nowhere-so-every-type-contract-is-advisory.md)
-**Depends on:** 1825 (landed — the narrow loop-contract gate this replaces)
-
-## Problem
-
-Nothing in `platform/ui` runs the TypeScript compiler. `npm run build` is `vite build && tsup`,
-both esbuild-backed, and esbuild strips types without reading them. There is no `lint` script and
-no `typecheck` script. None of the eighteen prebuild gates invokes `tsc`, and no CI workflow does
-either. A type error in this package ships.
-
-Task 1825 built a compile-time contract for the loop-row wire shape, found nothing enforced it, and
-added `scripts/check-loop-contract-types.mjs` — a gate that runs `tsc` and then discards every
-error outside six named files. Six files are gated; roughly three hundred are not.
-
-## Measurements
-
-Every figure below was measured in the task-1829 worktree on 2026-07-20, Node 22.22.0, with
-`platform/node_modules` and `platform/ui/node_modules` symlinked from the parent checkout.
-
-The task file's stated figures do not survive measurement, and three of its premises change as a
-result.
-
-| Quantity | Task file | Measured |
-|---|---|---|
-| `tsc --noEmit` wall time | ~51s | 19s cold, 13s warm |
-| Total errors | 103 | 97 before `build:lib`, 80 after |
-| Error classes | 2 | 3 |
-
-**The sibling `dist/` question is settled: it is a setup problem, not a source problem.** Running
-`npm run build:lib` in `platform/` (clean, 24s) clears all 14 `TS2307` unresolved-import errors. It
-also removes two files from the report entirely — `../lib/graph-search/src/index.ts` and
-`../plugins/memory/mcp/src/tools/memory-delete.ts` — because with the dists present those imports
-resolve to `dist/*.d.ts` rather than dragging the sibling `.ts` sources into the program. So the
-gate's prerequisite is a documented build order, exactly as the task predicted.
-
-**The runtime cost concern dissolves.** At 13–19s there is no case for `--incremental` with a
-cached build-info file, and no case for moving the check to CI. It goes in prebuild.
-
-**There is a third error class the task did not anticipate.** After `build:lib`, the 80 remaining
-errors split three ways:
-
-| Class | Count | Nature |
-|---|---|---|
-| Test-file errors | 62 | Genuine; implicit-`any` params and stale fixtures |
-| Production-file errors, fixable in-tree | 8 | Genuine |
-| `neo4j-driver` v5/v6 type skew | 10 | Cross-package version conflict |
-
-## The `neo4j-driver` skew
-
-`platform/ui` declares `neo4j-driver@^6.0.1`. Thirteen workspace packages under `platform/` declare
-`^5.28.1`, which hoists to `platform/node_modules` as 5.28.3. `platform/lib/*` has no
-`package.json`, so those libs compile against the hoisted v5, while `platform/ui` hands them v6
-`Session` objects. That is the eight `TS2739` and two `TS2345` errors.
-
-It is not a worktree artefact. It reproduces wherever both trees are installed.
-
-At runtime it is currently inert but not honest. `neo4j-driver` is external to the tsup bundle,
-while `platform/lib/*` is inlined into `server.js`. So lib code compiled against v5 types already
-executes against v6 in the server process, and against v5 in each plugin MCP process. Both work
-today.
-
-`platform/ui` has carried `^6` since the fold-in commit; it was never deliberately bumped. It uses
-only `neo4j.int`, `isInt`, `driver`, `auth`, the six temporal `is*` guards, and `type { Session }`.
-Every one exists in v5 — the export diff shows v6 is a strict superset and v5 has nothing v6 lacks.
-
-**Decision: align downward.** `platform/ui` moves to `^5.28.1`. This is one source file, it lands
-`platform/ui` on the same version as the seventeen other packages and as what `platform/lib/*` is
-compiled against, and it stays inside the task's scope boundary. Aligning upward would move every
-platform plugin MCP, service and premium-plugin onto v6 and breach the task's stated out-of-scope
-line; that is its own sprint.
-
-`payload/server/package.json` is generated from `platform/ui/package.json` at bundle time
-(`packages/create-maxy-code/scripts/bundle.js`, `externalDeps`), so the deployed server's driver
-version follows this one file.
-
-## The two production defects
-
-Both were found by the compiler and neither is cosmetic.
-
-**`ChannelIcon` — a live crash.** `GLYPHS` is typed `Record<ReaderChannel, …>` but holds only
-`whatsapp` and `telegram`; `ReaderChannel` is `'whatsapp' | 'telegram' | 'webchat'`. At
-`Sidebar.tsx:1499` a conversation row passes `c.channel`, and `select-sessions.ts:43` states that a
-row can carry any of the three. A webchat row there makes `GLYPHS['webchat']` undefined and `g.fill`
-throws, taking the sidebar subtree with it. `SessionChannelBadge`, in the same file, already routes
-webchat to a globe and unknown tokens to a neutral bubble.
-
-The fix is not to invent a webchat brand path. `ChannelIcon` renders brand glyphs by design, which
-is why `BRAND_CHANNELS` maps only two. Its prop type narrows to the brand channels, and
-`Sidebar.tsx:1499` uses `SessionChannelBadge`, the component built for the all-three case. For
-whatsapp and telegram this is behaviour-preserving; `SessionChannelBadge` delegates to
-`ChannelIcon` at the same size.
-
-**`webchat-gateway` — the type is wrong, not the value.** `public-session-end-review.ts:41` declares
-`dispatchFor: 'eviction' | 'exit'`. The local callback type at `webchat-gateway.ts:83` narrowed it
-to `'eviction'`. Line 422 passing `'exit'` is the documented public-exit path. Widening line 83 is a
-type-only fix with no behaviour change.
-
-## What is built
-
-**Root-cause fixes, 70 errors to 0.** No error is suppressed; each is removed at source.
-
-| Fix | Clears |
-|---|---|
-| `platform/ui/package.json`: `neo4j-driver` `^6.0.1` → `^5.28.1` | 10 |
-| Test files: annotate implicit-`any` params, update stale fixtures | 62 |
-| `sessions.ts` ×4, `whatsapp-reader.ts` ×1 implicit-`any` | 5 |
-| `ChannelIcon` narrowed; `Sidebar.tsx:1499` uses `SessionChannelBadge` | 1 |
-| `webchat-gateway.ts:83` `dispatchFor` widened | 1 |
-| `sidebar-sessions.ts:283` `port` typed `string`, `requirePortEnv` returns `number` | 1 |
-
-**The gate.** `scripts/check-types.mjs` runs `tsc --noEmit` over the whole package and fails on any
-diagnostic. Its ignore list is empty and it says so in its own output, so a future non-zero ignored
-count is visible in build logs rather than inferred.
-
-It keeps both of 1825's blind-pass protections, because they are why that gate could be trusted:
-
-- A diagnostic with no `path(line,col)` prefix means the compiler failed *before* typechecking
-  rather than while typechecking, and is reported as a configuration failure. Exit status cannot
-  carry this distinction — `tsc` exits 2 on a normal run with errors and 1 when it cannot find
-  `tsconfig.json` at all.
-- A non-zero exit with no parseable diagnostic means nothing was typechecked, and fails loudly
-  rather than reporting success.
-
-It adds one pre-flight of its own: the sibling `lib/*/dist` artefacts that `platform/ui` imports
-must exist. If they do not, it exits naming `npm run build:lib` instead of emitting fourteen
-confusing unresolved-import errors. This is the documented build order the task asked for, enforced
-as a state check rather than left in prose.
-
-`check-loop-contract-types.mjs` is deleted. Two gates asserting the same invariant at different
-scopes is the drift 1825 exists to prevent, reintroduced one layer up.
-
-A `typecheck` script is added to `package.json` so the check is runnable on its own.
-
-## Testing
-
-The load-bearing case is a deliberately introduced type error in a file the narrow gate never
-covered. It must be observed failing, and observed passing once removed. A gate that has only ever
-been seen passing has not been shown to work.
-
-Separately, the gate must be shown not to pass blind: pointed at a tree where `tsc` cannot run, it
-exits non-zero rather than reporting success. And the dist pre-flight must be observed firing with a
-lib dist absent.
-
-The `neo4j-driver` downgrade is verified against a running Neo4j, not only against the compiler. A
-dependency change that only ever passed a typecheck has not been shown to work either.
-
-## Scope boundaries
-
-**In scope:** making `tsc` run and pass over `platform/ui`; triaging every pre-existing error;
-retiring the narrow loop-contract gate; aligning `platform/ui` onto `neo4j-driver` v5.
-
-**Out of scope:** the other platform packages (`platform/lib/*`, `platform/plugins/*`), which still
-typecheck nowhere — filed as a follow-up task rather than left as prose. Adding eslint. Changing
-`tsconfig.json` strictness. Moving the seventeen v5 packages to v6. The loop-row contract itself,
-which 1825 closed.
-
-## Observability
-
-None at runtime; this is a build-time contract with no runtime surface. The gate's own output names
-the error count found and the count ignored.

package/payload/platform/docs/superpowers/specs/2026-07-20-task-1831-data-portal-class-derived-allowlist-design.md

@@ -1,163 +0,0 @@
-# Task 1831 — data portal class-derived allowlist (design)
-
-Date: 2026-07-20. Task: [`.tasks/1831-data-portal-exposes-only-uploads-not-the-sub-accounts-folder-tree.md`](../../../../.tasks/1831-data-portal-exposes-only-uploads-not-the-sub-accounts-folder-tree.md).
-
-## Problem
-
-The portal only shows what the client uploaded. `processFiles`
-(`skills/data-portal/template/functions/api/files.ts:11-24`) reads
-`manifest WHERE ownerId = ?`, and `manifest` holds one row per `/api/upload`
-object. There is no device-to-portal path at all, so an account can receive
-documents from a client but cannot hand any back.
-
-A fixed folder list cannot solve it. On SiteDesk account
-`098a18a3-1741-447f-9778-65470645d57d` the deliverables sit in both `output/`
-and `quotes/`, and `quotes/` is projected per account from the brand's vertical
-ontology (`platform/scripts/lib/account-schema-owned-dirs.py:288-296`), not
-shipped in the template. A different vertical projects different buckets.
-
-Provenance cannot be recovered either. `upsertFileArtifact`
-(`platform/ui/app/lib/file-index.ts:294-307`) stores no writer, and the watcher
-runs agent writes and operator uploads through one path
-(`platform/ui/app/lib/file-watcher.ts:30-34`).
-
-## Approach
-
-Key on each folder's declared class, not its name.
-
-Exposed = the dirs named in the account's `<!-- ontology-buckets -->` region,
-plus `output`, intersected with the ```` ```allowed-top-level ```` block. All
-three are read from `accounts/<accountId>/SCHEMA.md`, which is generated per
-account. A new vertical projects new buckets and they appear with no code change.
-
-## Data flow
-
-```
-DEVICE (each heartbeat)                    D1                     PORTAL
-  read SCHEMA.md
-  resolve exposed dirs
-  walk those dirs only  ── metadata ──▶  directory  ──── read ───▶ folder tree
-                                                                      │
-                                          click a file ───────────────┘
-                                                  │
-                        HEAD (alive?) ◀───────────┤
-                                                  │
-                        signed link, 5 min  ──────┘
-                                  │
-  verify signature ◀──────────────┘
-  re-resolve exposed dirs
-  serve bytes
-```
-
-Bytes never enter D1 or R2. Listing therefore survives the device being offline;
-download does not, and says so plainly.
-
-## Components
-
-| File | Responsibility |
-|---|---|
-| `plugins/cloudflare/bin/schema-exposed-dirs.mjs` | `SCHEMA.md` text in, exposed dir names out. Pure, no I/O. |
-| `plugins/cloudflare/bin/portal-index-push.mjs` | walk exposed dirs, full-replace the account's `directory` rows |
-| `.../template/functions/api/_lib/portal-sign.mjs` | mint + verify the signed link, portal side (sits beside `passcode.mjs`, same precedent) |
-| `plugins/cloudflare/skills/data-portal/schema.sql` | `directory` table, `people.accountId` column |
-| `.../template/functions/api/files.ts` | folder entries beside today's uploads |
-| `.../template/functions/api/download.ts` | uploads to R2 unchanged; indexed files get a signed link |
-| `.../template/portal.js`, `index.html` | breadcrumb folder navigation |
-| `platform/ui/server/routes/portal-fetch.ts` | verify signature, re-resolve exposure, serve |
-
-## Parsing contract
-
-Pinned against the generator, because two details are easy to get wrong and both
-fail silently:
-
-- The ontology region lists `` - `<dir>/` - one folder per <Label> record. `` with
-  an **ASCII hyphen**; the plugin-owned region uses an **em dash**
-  (`account-schema-owned-dirs.py:294` vs `:281`). Parsing on the em dash matches
-  nothing and reads as "this account has no buckets".
-- An absent ontology region is normal, not corrupt: `merge()` strips both regions
-  before regenerating, and a brand with no declared vertical never gets one. It
-  yields `output` alone.
-- A dir claimed by a plugin is described only in the plugin-owned region
-  (`:287`), so it will not parse as a domain bucket and drops out of the exposed
-  set. Instrumented, not fixed, here.
-
-## Authentication
-
-One secret per account, generated at portal assembly, written to the account's
-secrets file and set as the Pages secret `PORTAL_FETCH_SECRET`. The install
-origin is set alongside it as `PORTAL_INSTALL_ORIGIN`.
-
-The portal signs `accountId`, `relPath` and an expiry with HMAC-SHA256 via Web
-Crypto and puts the signature in the link. The install verifies it. The secret
-itself never travels, and each grant covers one file for five minutes.
-
-The install re-resolves the exposed dir list from `SCHEMA.md` on every request
-rather than trusting the path it was handed. A valid signature over
-`documents/private.pdf` is still refused. That check is the security boundary;
-the signature only proves the request came from the portal.
-
-**The two ends do not share a module.** No production code in `platform/ui`
-imports from `platform/plugins` today — only one test does
-(`server/lib/calendar-ics.test.ts:12`) — and this sprint will not invent that
-coupling for fifteen lines of HMAC. The portal mints with
-`_lib/portal-sign.mjs`; `portal-fetch.ts` carries its own verify. Both call Web
-Crypto, which Node 22 and Workers both provide, so the algorithm is identical by
-construction. A parity test mints with the portal module and verifies with the
-install's function, which catches drift at the only place it could occur.
-
-## Error handling
-
-| Condition | Response |
-|---|---|
-| device unreachable (HEAD fails) | 503 `device-offline` |
-| signature absent, altered, or expired | 401 |
-| path outside the exposed dirs | 404, regardless of signature |
-| path outside the account partition | 404 |
-| `SCHEMA.md` missing or unparseable | expose nothing |
-
-The last one deliberately inverts `fs-schema-guard.sh:76-78`, which fails open so
-an unseeded legacy account is not write-blocked. A read surface facing a client
-must fail closed. The code carries that reason inline.
-
-## Testing
-
-Unit only. No portal is deployed anywhere and no account exists on this Mac, so
-nothing can be driven end to end.
-
-- **Resolver.** SiteDesk-shaped text yields `output,quotes`. No ontology region
-  yields `output`. A dir absent from the allowed block is dropped. A region
-  written with an em dash yields zero buckets, which asserts the hyphen contract
-  rather than assuming it. Missing file yields nothing.
-- **Walker.** Fixture tree carrying `output/`, `quotes/`, `documents/`,
-  `uploads/`, `.claude/` produces rows for the first two only, at any depth.
-  Delete leaves no stale row; rename produces one row at the new path; a
-  repeated run is identical.
-- **Listing.** Account A never sees account B's rows. Prefix filtering
-  synthesises directories from paths. A `people` row with no `accountId` returns
-  an empty list, not an error.
-- **Signing.** Round trip verifies. Expired fails. Tampered path fails. Tampered
-  account fails. Parity: a token minted by the portal module verifies with the
-  install's own function, so the two implementations cannot drift unnoticed.
-- **Fetch route.** Well-signed request for a non-exposed path is refused. Path
-  traversal is refused. Exposed path serves with the right content type.
-- **Regression.** The existing 139 tests across 10 files stay green.
-  `typecheck:templates` stays at exit 0.
-
-## Out of scope
-
-The upload ingestion sweep; client write-back, delete or rename; mirroring bytes
-into R2; recording write provenance (the SiteDesk quote engine writes through its
-own tool, not `Write`/`Edit`, so `quotes/` would never register); fixing the
-plugin-owned name collision; search; the `/data` admin browser.
-
-## Dependencies
-
-`people.accountId` is new, so existing enrolments are re-run — the upsert on
-`ownerId` makes that a re-run, not a migration. Each portal-serving account needs
-a seeded `SCHEMA.md` or it exposes nothing. Downloads need the install reachable
-at its tunnel hostname; listing does not.
-
-The heartbeat spawn this copies
-(`plugins/scheduling/mcp/src/scripts/check-due-events.ts:797`) has never been
-observed running on a Pi, which is Task 1828. `portal-index-push.mjs` is
-therefore runnable standalone, so it stays operable while 1828 is open.

package/payload/platform/docs/superpowers/specs/2026-07-22-task-1899-reconcile-report-only-design.md

@@ -1,121 +0,0 @@
-# Task 1899 — the account-dir reconcile reports and never moves
-
-Design agreed 2026-07-22. Source task: `.tasks/1899-account-dir-reconcile-moves-live-state.md`.
-
-## The problem this removes
-
-`reconcileAccount` treats every account-root entry that is neither in the account's
-`SCHEMA.md` `allowed-top-level` block nor in the hand-maintained
-`PROTECTED_TOP_LEVEL` set as a stray, and moves it into `<account>/.quarantine/`.
-The closed list has never matched what the platform and its agents write at an
-account root, so every mismatch is a live feature or live data going dark with no
-error anywhere. `PROTECTED_TOP_LEVEL` has been extended once per casualty
-(`calendar-availability.json` was Task 1877). The sweep is what changes; the
-allowed-list is not made complete here, because once nothing moves an undeclared
-entry costs one log line rather than a broken feature.
-
-## Units
-
-### 1. `platform/services/claude-session-manager/src/account-dir-schema-reconcile.ts`
-
-The move block, `quarantineDest`, and the `mkdirSync` / `renameSync` /
-`appendFileSync` imports are deleted. `ReconcileCounts` loses `quarantined` and
-stays the pure formatter's input, so `formatReconcileLine` still takes exactly
-what it prints:
-
-```
-[fs-reconcile] stray-top-level=<n> over-deep=<n> bad-name=<n>
-```
-
-`reconcileAccount` returns a new `ReconcileResult`: the counts plus
-`strayNames: string[]`. `PROTECTED_TOP_LEVEL` and `QUARANTINE_DIR` both stay.
-They no longer protect anything from being moved, because nothing moves; they
-keep known platform entries and existing quarantine directories out of the stray
-count so the standing line stays readable and a clean account still reports zero.
-
-### 2. `runReconcile` names the strays
-
-One line per account that has any, emitted before the summary:
-
-```
-[fs-reconcile] op=strays account=<id> names=<a,b,c>
-```
-
-No cap on the name list. A count alone cannot distinguish six pieces of debris
-from a live plugin config, and a truncated list would hide the entry an operator
-is hunting for.
-
-### 3. `platform/services/claude-session-manager/src/index.ts`
-
-The call-site comment states that the pass quarantines. It is rewritten to state
-that it reports and never moves, and why: a closed allowed-list that lags what
-the platform writes turns a metric into data loss.
-
-### 4. `platform/scripts/quarantine-restore.mjs`
-
-One-shot, run per install with `--accounts-root <dir>`, plus `--dry-run`. For
-each `<account>/.quarantine/manifest.jsonl` it walks records newest-first and for
-each `originalPath`:
-
-| On disk | Action | Log |
-|---|---|---|
-| Target free at the account root | move it back | `op=restore account=<id> name=<n> result=moved` |
-| Target occupied by a copy the platform rewrote | leave the quarantined copy alone | `result=skipped-live-copy` |
-| Target occupied by a newer copy this same run restored | leave the quarantined copy alone | `result=skipped-superseded` |
-| Source absent (already restored by hand) | nothing | `result=absent` |
-
-Three further outcomes were added during code review, each because its absence
-would have been a silent skip of exactly the kind this task exists to end:
-
-| Condition | Log | Effect |
-|---|---|---|
-| A manifest line that will not parse, or lacks a string `originalPath` / `quarantinePath` | `line=<n> result=unparsable` | counted, run continues |
-| A record whose source escapes `<account>/.quarantine/` or whose target escapes the account | `line=<n> result=refused-outside-account` | counted, exit code 1 |
-| The rename fails, or the manifest will not open | `result=failed` / `result=manifest-unreadable` | counted, exit code 1 |
-
-The containment check exists because `.quarantine` is in the write guard's
-allowed-top-level set, so an account-scoped agent can append to its own manifest,
-while the script runs as the platform user across every account. Without it a
-crafted record moves one account's live data into another. Every record the
-reconcile ever wrote was a bare basename plus a path under `.quarantine/`, so the
-check refuses nothing genuine.
-
-Newest-first is what makes the occupied case correct for a name quarantined more
-than once: the most recent copy is considered first, and every older copy of that
-name then finds the target occupied. The live copy wins because the platform
-rewrote it after the move, which the four `wa-channel-bindings.json` records on
-account `5e99bba5` prove happened.
-
-A restored record is appended to `<account>/.quarantine/restored.jsonl` and the
-manifest is left intact, so the history of what moved and what came back
-survives. The script never deletes.
-
-### 5. `platform/templates/account-schema/SCHEMA.md`
-
-The paragraph telling the agent that `.quarantine/` holds entries the reconcile
-moved out of the top level describes behaviour this task deletes. It is reworded
-to say the directory is a historical store from the pre-1899 sweep that nothing
-adds to any more. Re-filing its contents through the `data-manager` specialist
-still stands.
-
-## Tests
-
-New and rewritten cases go in the existing
-`src/__tests__/account-dir-schema-reconcile.test.ts`; several of its 18 cases
-assert quarantine moves and are rewritten to assert no move. The restore script
-gets `platform/scripts/__tests__/quarantine-restore.test.sh`, matching how every
-other `platform/scripts/` test is written.
-
-## Out of scope
-
-- Completing the `account-owned-dirs` declarations, and extending declarations
-  from dirs to files so `data-portal.json` has a declaration path. Task 1902.
-- The portal index push. It is correct and was starved of its config.
-- The standing portal audit going silent when a config disappears. Task 1901.
-- `over-deep` and `bad-name`. Both already count without moving.
-- Installer payload twins. The payload has no committed copy of any file touched
-  here; `packages/create-maxy-code/scripts/bundle.js` copies `platform/` at
-  bundle time.
-- Publishing, installing on the laptop's three reconcile-carrying installs, and
-  running the restore. All await the operator's publish command, because the
-  currently-installed sweep would re-take anything restored before it.

package/payload/platform/docs/superpowers/specs/2026-07-22-task-1910-two-way-portal-exchange-design.md

@@ -1,103 +0,0 @@
-# Task 1910 — Two-way portal file exchange (design)
-
-Design for [`.tasks/1910-two-way-portal-file-exchange.md`](../../../../.tasks/1910-two-way-portal-file-exchange.md). Operator decision 2026-07-22: the data portal becomes a two-way folder exchange, reversing the one-way scope decisions of Tasks 1831, 1905 and 1906.
-
-## The problem in one line
-
-Today the portal is two stores that never meet: a flat, destination-less R2 upload area the client writes to, and a read-only device folder index the client browses. Neither can reach the other.
-
-## Manifest state machine
-
-Three new columns on `manifest`: `targetPath` (the exposed folder chosen at upload, empty means untargeted), `devicePath` (where the bytes actually landed, written only after a verified device write, so its presence *is* the proof the move happened), and `deleted` (the client asked to withdraw a file that has already moved).
-
-| State | Columns | Bytes live in | Uploads panel |
-|---|---|---|---|
-| In transit | `ingested=0`, `devicePath=''` | R2 | shown, downloads from R2 |
-| Moved | `ingested=1`, `devicePath` set, R2 object gone | device | shown only when the file is not reachable in the folder tree |
-| Withdrawn | `deleted=1` | device, pending removal | hidden |
-
-**One listing rule:** the uploads panel shows a row when the bytes are still in R2, or when the moved file is not reachable in the folder tree. A targeted file therefore leaves the panel and appears in its folder; an untargeted file stays in the panel and downloads through the device. No file is ever listed twice, and no file becomes unreachable.
-
-`devicePath` rather than a boolean is deliberate: a boolean would say a move happened without saying where, and the audit's `unpublishedRouted` check needs the path to compare against the published index.
-
-**Withdrawal ends in row deletion, not a tombstone.** Once the device file is confirmed absent the row is removed. A tombstone would grow the manifest without bound and force every listing read to filter it, and the R2 object is already gone, so the row describes nothing.
-
-### Serving a moved untargeted file
-
-A moved untargeted file sits at `uploads/<ownerId>/<filename>`, and `uploads` is deliberately never exposed (`schema-exposed-dirs.mjs:9-14`). `resolveFetchTarget` refuses any path whose top segment is outside the exposed set (`portal-fetch.ts:182`), and the signed message carries `accountId`, `relPath` and an expiry but no owner (`portal-fetch.ts:56`), so as it stands the device would both refuse the path and be unable to tell whose uploads folder was asked for.
-
-Two link types with two distinct signed messages resolve this:
-
-| Link type | Signed message | Device admission rule |
-|---|---|---|
-| Exposed-folder file | `accountId \n relPath \n exp` (unchanged) | top segment ∈ exposed set |
-| Own-upload file | `accountId \n uploads \n ownerId \n relPath \n exp` | path is exactly `uploads/<signed ownerId>/…` |
-
-The owner is inside the HMAC, so a portal cannot mint a link into another person's upload folder, and the device still decides admission itself rather than trusting the path. `uploads/` gains no exposure to the folder tree; only a link naming its own owner reaches it.
-
-Two message shapes rather than one extended shape, because the exposed-folder message is unchanged and an already-deployed portal never mints the second type. Device and portal redeploy at different times (installer publish versus `site-deploy`), so a single extended message would break every existing download in the window between them.
-
-## Upload key
-
-`ownerId/targetPath/filename`, collapsing to `ownerId/filename` when untargeted.
-
-The target must be in the key. With a flat `ownerId/filename` key, the same filename dropped into two different folders collides on `objectKey UNIQUE`: the upsert would overwrite the first object, reset `ingested`, and the first file would never land. `authorizeKey` (`_lib/authorize.ts:22-32`) already admits deeper keys, rejecting only `..` and a leading separator, so the owner-isolation gate is unchanged by this.
-
-Same owner, same folder, same filename still upserts, which is success criterion 7's replace case.
-
-## Target validation, and where the boundary actually is
-
-A target is legal when it passes the person's grant (`grantAllows`, `_lib/session.ts:87`) **and** carries a folder row (`isDir=1`) in the published `directory` index for that account.
-
-This means you can only drop where you can see, which introduces no new permission concept: the set of legal upload targets is exactly the set of folders already rendered to that person. An empty target is always legal.
-
-**The portal check is convenience; the device check is the boundary.** The pull re-derives the exposed set itself through `resolveExposedDirs`, refusing anything outside it, the same two-ended pattern `portal-fetch.ts` uses for signed downloads. A compromised portal cannot route a file into a folder the device does not expose. The two ends are pinned to agree by a parity test over one shared fixture set, mirroring the existing HMAC parity test.
-
-Refusal fails closed: the file stays pending, the refusal is logged with the exact failing segment, and it is never silently rerouted to the default. A silent reroute would put a client's file somewhere they did not choose and could not find.
-
-## Large uploads
-
-The client slices anything above one part into 25 MiB pieces against an R2 multipart session; files at or below one part keep today's single request. The cap is 1 GiB, checked at session creation against the declared size and again at completion against the summed parts.
-
-Slicing is on the client because the ceiling is the isolate: an upload is read wholly into Function memory (`upload.ts:137`), which is why 25 MiB was chosen in the first place (`upload.ts:8-15`). Parts preserve that bound exactly while removing the total-size limit. Cloudflare's proxied-body cap is not the constraint here; the portal is on Pages, not behind the tunnel that bounds the admin `/data` page (Task 1174).
-
-## Atomic index replace
-
-`directory` gains a `generation` column and a per-account pointer table. The push writes rows at the next generation, flips the pointer in one statement, then deletes superseded rows.
-
-The flip is the atomic point, so a listing racing a push sees the old tree or the new one, never a half-built one. Cleanup afterwards need not be atomic because nothing reads a superseded generation. This supersedes backlog Task 1842, which recorded the delete-then-insert window as an open defect; at 60 second cadence that window would otherwise be hit sixty times more often than at hourly.
-
-## Cadence
-
-The index push becomes a 60 second loop in the admin server's loop registry, beside the pull that already runs there. The scheduling heartbeat's hourly gate and its `auditPortalIndexPush` are retired.
-
-That heartbeat spawn is the path whose own header records it has "never been observed running on a device" (`portal-index-push.mjs:11-13`). Moving the push into the loop registry replaces an unobserved spawn with the mechanism the pull demonstrably uses, and removes the hourly gate that made the client's tree stale by up to two hours. Importing across the tree boundary is precedented: `portal-fetch.ts:22` already imports `schema-exposed-dirs.mjs` from the plugins tree. The script stays runnable standalone.
-
-## Audit
-
-The five-minute `[data-portal-audit]` gains four fields, each answering a failure that emits no event of its own:
-
-- `lastPushAgeSec` — the push stopped running. Healthy under 180.
-- `unmovedObjects` — an R2 object survived its own pull, so the move leaked.
-- `deletePendingRows` — a withdrawal never reached the device.
-- `unpublishedRouted` — a routed file landed somewhere the index never published, so the client cannot see what they uploaded.
-
-Enumeration becomes the union of accounts presenting a config and accounts with a prior push record, reporting `config-absent` rather than falling silent. That is Task 1901's fix, folded in here because this task retires the audit 1901 would have patched.
-
-## Download routing
-
-`/api/download?key=` keeps serving R2 bytes while the row is in transit. Once the row has moved the object is gone, so the same request mints an own-upload signed link and 302s to the device, which is what keeps criterion 5 true without the client learning that the bytes changed home.
-
-## Client
-
-Folder rows and the open listing become drop targets with a drop state. The picker takes multiple files and a multi-file drop uploads each in turn. Upload rows gain `DownloadURL` drag-out, matching what device rows already have (`portal.js:226-233`). Uploads show per-file progress and distinct messages per failure class, replacing today's single "Upload failed." for every status. The page re-reads every 60 seconds while its tab is visible.
-
-Polling was rejected in Tasks 1885 and 1900 on the explicit reasoning that "a poll against an hourly tree is waste". The premise dies with the hourly push: against a 60 second tree the poll is the thing that makes a device-side change visible without the client clicking anything, which is success criterion 4.
-
-## Out of scope
-
-Client deletion or rename of device-authored files the client did not upload; the trust boundary is that a client may withdraw their own file, not destroy a business record. Folder upload and zip download, both directions being files only. Portal-side folder creation, rename and move. The third D1 client (Task 1843). The admin `/data` page and Task 1174. Graph ingestion of pulled files, unchanged from Task 1906.
-
-## Dependency
-
-Live acceptance is blocked until Task 1909 restores the quarantined `data-portal.json` on both sitedesk accounts; the portal has enumerated zero accounts since 2026-07-21T19:16:05Z. Code and unit verification do not depend on it.

package/payload/platform/docs/superpowers/specs/2026-07-23-task-1930-adherence-enforcement-design.md

@@ -1,81 +0,0 @@
-# Task 1930 — Schema-and-preference adherence enforcement (design)
-
-Date: 2026-07-23
-Task: `.tasks/backlog/1930-enforce-schema-and-preference-adherence-scratch-deliverables-and-unconsulted-sends.md`
-
-## Problem
-
-Two adherence failures share one root: a rule the agent follows by judgement, with no gate forcing it.
-
-- **Preferences.** Layer-2 `Preference` nodes (`platform/plugins/memory/mcp/src/tools/profile-read.ts`) are consulted by per-turn judgement. A customer signature preference was missed on a delivered document because nothing forced a `profile-read` before the send.
-- **Placement.** `output/` is tool-owned scratch rebuilt each write (`platform/templates/account-schema/SCHEMA.md:29-42`); finished deliverables strand there and graph refs point at those scratch paths. The `data-manager` reconcile audit skips tool-owned dirs, so both are invisible to it.
-
-## Decisions (operator-confirmed)
-
-1. The preference gate fires only on **customer-facing document deliverables**, not every send. Casual channel replies and plain-text emails pass.
-2. This sprint ships the gate, the wrapper reminder, and the spec changes. The **periodic scheduling** of the reconcile audit is deferred to Task 1931.
-3. The gate hard-blocks (exit 2), matching the user's instruction.
-
-## Architecture
-
-Five units, each single-purpose and independently testable.
-
-### 1. `platform/plugins/admin/hooks/preference-consult-gate.sh` (new, PreToolUse)
-
-Contract mirrors `quote-render-gate.sh`: read the JSON envelope on stdin, exit 0 allow / exit 2 block, fail-open on any uninspectable call (tty, empty stdin, missing `python3`, missing/unreadable transcript).
-
-**Fires only on a customer-facing document deliverable**, decided from `tool_name` + `tool_input`:
-- `mcp__plugin_browser_browser__browser-pdf-save` whose output path is under `memory/users/<phone>/documents/`.
-- `SendUserFile` whose file path is under `memory/users/<phone>/documents/` or carries a document extension (`.pdf`, `.html`, `.docx`).
-- `mcp__plugin_email_email__email-send` / `email-reply` / `email-draft-send` with a non-empty `attachments`.
-- `mcp__plugin_outlook_outlook__outlook-mail-send` / `outlook-mail-reply` / `outlook-draft-send` with a non-empty `attachments`.
-
-Any tool or shape not matching the above exits 0 (not a document deliverable).
-
-**Consultation check.** Read the transcript at `transcript_path`. Scan the messages from the last `role:user` entry to the end for an assistant `tool_use` whose name ends in `profile-read`. Found → exit 0. Absent → exit 2.
-
-**Block message** (operator-visible, no task numbers): names that a customer document is about to go out without the account's saved preferences being checked this turn, and directs the agent to run `profile-read` for this account and retry the send. A false block (preferences read in an earlier turn) is a one-step recovery, not a dead end.
-
-**Log line** (stderr): `[preference-gate] op=bypass tool=<name> detail=no profile-read this turn` on a block; `op=allow tool=<name> consulted=true` on the allow path for a document deliverable. `browser-pdf-save` already carries `quote-render-gate` on the same matcher; both hooks run and are independent (one on receipt, one on consultation).
-
-### 2. `platform/plugins/admin/hooks/preference-consult-directive.sh` (new, UserPromptSubmit)
-
-Mirrors `datetime-inject.sh`: drain stdin first, fail-open exit 0 on every path, emit `hookSpecificOutput.additionalContext` via python3. The block is standing and prompt-independent. Content: the two-layer preference architecture (layer 1 fixed/injected, layer 2 the account's `Preference` records read via `profile-read`), and two directives: consult the relevant layer-2 preferences before any customer-facing document deliverable, and promote finished deliverables out of `output/` into `documents/` or `projects/`. Breadcrumb line: `[pref-wrapper] op=inject`.
-
-### 3. `platform/templates/account-schema/SCHEMA.md`
-
-In the tool-owned section (`:29-42`), add one sentence: finished deliverables must be promoted out of `output/` into `documents/` or `projects/`; `output/` is scratch of last resort, rebuilt on the next write, and a graph reference must never point into it.
-
-### 4. `platform/templates/specialists/agents/data-manager.md`
-
-Extend "The reconcile audit brief": in addition to (a) files unreachable from any node and (b) refs that resolve to no real path, count (c) graph refs resolving into a scratch dir (`output/`, `generated/`, `extracted/`, `url-get/`) and (d) deliverables referenced by a node but resolving only under scratch. Output contract becomes `unreachable=N broken-refs=M scratch-refs=P stranded=Q`. The audit stays read-only; it moves nothing.
-
-### 5. Registration + docs
-
-- `platform/scripts/lib/provision-account-dir.sh`: add PreToolUse matcher entries routing the document-send tools to `preference-consult-gate.sh`, and add `preference-consult-directive.sh` to the UserPromptSubmit hooks list.
-- `platform/plugins/admin/PLUGIN.md`: hook entries for both new hooks (matcher, block condition, block message, log line, fail-open).
-- `.docs/` and `platform/plugins/docs/references/`: the sprint-gate documentation targets.
-
-## Registration matcher note
-
-Settings matchers are per-tool. The gate registers against the browser, email, outlook, and SendUserFile matchers; the script itself does the document-deliverable discrimination, so over-matching a non-document send is safe (it exits 0). WhatsApp document delivery routes through the file path the same discrimination covers when a document goes out as a `SendUserFile`; a plain `whatsapp-reply` text is not a document deliverable and is out of scope by decision 1.
-
-## Testing (ephemeral)
-
-- **Gate.** For each document-send tool: envelope whose transcript has a `profile-read` since the last user turn → exit 0; envelope with none → exit 2 with the bypass line. A non-document send (email with no attachments, plain browser-pdf-save outside the customer documents scope) → exit 0. Empty/tty stdin → exit 0.
-- **Wrapper.** Emits `hookSpecificOutput.additionalContext` containing both directives; fails open (exit 0) when python3 is absent.
-- **Regression.** The 22 `fs-schema-guard` tests and the `quote-render-gate` tests stay green.
-
-## Observability
-
-- **Gate (per send):** `[preference-gate] op=allow|bypass tool=<name>`. Success = `op=allow consulted=true`. Failure = any `op=bypass`.
-- **Wrapper:** `[pref-wrapper] op=inject` per turn; absence across turns means the directive is not reaching the agent.
-- **Reconcile:** the extended brief emits `unreachable=N broken-refs=M scratch-refs=P stranded=Q`; a rising `scratch-refs`/`stranded` is the placement-drift signal. The standing periodic run that would make this a no-event backstop is Task 1931.
-
-## Out of scope
-
-- Hard write-block on `output/` writes (render tools legitimately use it as scratch).
-- Auto-promotion or auto-move of stranded files (stays the `data-manager` paired-move job).
-- The periodic scheduler for the reconcile audit (Task 1931).
-- Layer-1 fixed-block content, the voice file, and which preferences are stored.
-- Quote-specific conformance (1922/1928/1929).