create-freeholder 0.0.0-bootstrap.0 → 0.2.0-beta.2

package/dist/template/deploy/railway/README.md

@@ -0,0 +1,24 @@
+# Railway (Tier 1)
+
+`.railway/railway.ts` is Railway's current TypeScript IaC contract. It defines
+the public image-backed service, PostgreSQL and a private Storage Bucket, and
+wires typed database/S3 references. Railway's older `railway.toml` format is
+not used.
+
+## Install
+
+Install Railway CLI 5.42.1 or newer, authenticate and link an environment. Run
+`railway config plan`, inspect the diff, then `railway config apply`. Set
+`APP_URL`, a 32+ character `SESSION_SECRET` and the base64 `CREDENTIAL_KEY` on
+`freeholder-web`; the IaC `preserve()` entries retain them on later applies.
+Generate/attach a public domain, set `APP_URL` to its HTTPS origin and redeploy.
+
+## Operate
+
+- Verify with `verify.md` and the recipe's `verify` command.
+- Use the recipe's `backup`/`restore`; the CLI injects the linked database
+  variable. Media moves through `pnpm media:transfer` with virtual-hosted S3.
+- Run `config plan` before every `update`. Pin a release digest rather than an
+  edge tag for production; roll back by restoring the prior digest in IaC and
+  applying it, then verify.
+- Follow `migrate.md` before moving DNS or deleting the old environment.

package/dist/template/deploy/railway/migrate.md

@@ -0,0 +1,10 @@
+# Migrate to or from Railway
+
+Target: `railway`
+
+Follow the complete [Tier-1 migration runbook](../migration-runbook.md). Apply
+`.railway/railway.ts`, preserve `APP_URL`, `SESSION_SECRET` and `CREDENTIAL_KEY`,
+and use the generated Postgres and bucket reference variables. Railway buckets
+use virtual-hosted S3 addressing, which this recipe sets explicitly. Run the
+target export and upload/read/delete verification before assigning the public
+domain or changing DNS.

package/dist/template/deploy/railway/recipe.yaml

@@ -0,0 +1,35 @@
+# Copyright (C) 2026 Tony Aly
+# SPDX-License-Identifier: Apache-2.0
+name: railway
+schema: freeholder-deploy-recipe/v1
+tier: 1
+maintainers: ["@tonyaly"]
+freeholder_min_version: "0.0.0"
+provides:
+  database: railway-postgres
+  storage: s3-compatible
+  jobs: web-process
+  cron: railway-cron
+estimated_monthly_cost_usd: { min: 10, typical: 25 }
+limits:
+  - "Media MUST live in S3-compatible object storage"
+artifacts:
+  - .railway/railway.ts
+required_environment:
+  - APP_URL
+  - BOOTSTRAP_SECRET
+  - SESSION_SECRET
+  - CREDENTIAL_KEY
+operations:
+  install: "railway config plan && railway config apply"
+  verify: "pnpm doctor --url $FREEHOLDER_URL --email $FREEHOLDER_EMAIL --password $FREEHOLDER_PASSWORD"
+  backup: "railway run pg_dump --format=custom --no-owner --no-privileges --file freeholder.dump $DATABASE_URL"
+  restore: "railway run pg_restore --no-owner --no-privileges --dbname $DATABASE_URL freeholder.dump"
+  migrate-in: "railway run pg_restore --no-owner --no-privileges --dbname $DATABASE_URL freeholder.dump && pnpm media:transfer -- --manifest ownership-export/media-manifest.json"
+  migrate-out: "railway run pg_dump --format=custom --no-owner --no-privileges --file freeholder.dump $DATABASE_URL && pnpm ownership:export -- --output ownership-export && pnpm media:transfer -- --manifest ownership-export/media-manifest.json"
+  update: "FREEHOLDER_IMAGE=ghcr.io/campdenman/freeholder:$FREEHOLDER_IMAGE_TAG railway config plan && FREEHOLDER_IMAGE=ghcr.io/campdenman/freeholder:$FREEHOLDER_IMAGE_TAG railway config apply"
+  rollback: "FREEHOLDER_IMAGE=ghcr.io/campdenman/freeholder:$PREVIOUS_FREEHOLDER_IMAGE_TAG railway config plan && FREEHOLDER_IMAGE=ghcr.io/campdenman/freeholder:$PREVIOUS_FREEHOLDER_IMAGE_TAG railway config apply"
+update:
+  strategy: deploy-hook
+  rollback: redeploy the previous image through railway config apply
+tested_on: "2026-08-25"

package/dist/template/deploy/railway/verify.md

@@ -0,0 +1,9 @@
+# Verify: Railway
+
+Complete the shared [Tier-1 verification](../recipe-verification.md), then the
+platform checks below.
+
+- [ ] Public URL loads.
+- [ ] Doctor is green.
+- [ ] Uploads land in object storage.
+- [ ] `/api/health` reports `version`.

package/dist/template/deploy/recipe-verification.md

@@ -0,0 +1,23 @@
+# Tier-1 deployment verification
+
+Run this checklist after install, restore, update and rollback. A command that
+exists in `recipe.yaml` is not considered tested until its observable result is
+checked here.
+
+1. Confirm the platform reports the service and PostgreSQL resource healthy.
+2. Request `/api/health`; require HTTP 200, `ok: true` and the expected version.
+3. Complete `/setup` on a fresh database, sign in, sign out and sign in again.
+4. Run the recipe's `verify` operation and resolve every Doctor failure.
+5. Upload an image, reload it through its signed/private URL, then delete it.
+   Confirm the object is in the configured bucket—not container/workspace disk.
+6. Create a contact and an invoice with a non-round amount; record their IDs,
+   cents, currency and timestamps for restore comparison.
+7. Run `backup`, restore into a scratch database with `restore`, point a
+   temporary app at it and compare an ownership export. Drop the scratch DB.
+8. Deploy a newer digest with `update`, repeat steps 1–5, then deploy the prior
+   digest with `rollback` and repeat them again. Return to the intended release.
+9. Record provider, region, image digest, database version, test time and
+   operator in the deployment's private operations log.
+
+For a provider move, continue with [migration-runbook.md](migration-runbook.md)
+and do not delete the old database or bucket during this checklist.

package/dist/template/deploy/record-trash.md

@@ -0,0 +1,115 @@
+<!-- Copyright (C) 2026 Tony Aly -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# Record recovery (C11.14)
+
+**Move to trash** removes a record from normal lists and every surface that
+reads it. The original row remains — same id, same natural key, same history —
+until an explicit purge or the thirty-day sweep, so removal is reversible and
+nothing silently widens or disappears underneath a recovery.
+
+## Notes and tasks
+
+Notes and tasks were the first recovery family. Trashed tasks do not appear in
+project checklists or their open-task counts, briefings, or reminder claims.
+Restoring preserves IDs, revisions, assignment, recurrence state and subject
+links; a contact merge and its undo also update contact-subject links,
+including on trashed rows. Purging a note also removes its revisions; erasure
+deletes notes and anonymizes tasks even while they are trashed, and restore
+never recreates erased personal fields. The trash screen uses each record's
+existing view/manage grants; a private note remains visible only to its author.
+
+## Pages, forms, popups, segments and saved views
+
+The same guarantees now cover the rest of the recoverable families:
+
+- **Pages, draft and published.** Trashing a page is instant takedown: the
+  public lookup, sitemap, global search, help centre, scheduled publish and
+  unpublish, preview links, presence, comments and every admin read filter
+  trash. Because the trashed row keeps its slug, nothing can take the address
+  while the page recovers; restoring a published page puts the same row back
+  online. Purging removes the page and everything that exists only for it —
+  revisions, layouts, preview links, presence, comments and translations.
+- **Forms — the definition only.** Submissions are evidence of what somebody
+  told the business: they stay live and reviewable while the definition is in
+  trash, and the public form stops accepting new submissions. Purging a form
+  is the pre-existing hard delete (the definition and, by its cascade, its
+  submissions) behind typed confirmation, recent verification and the hold
+  below — deleting submissions was not changed in any other way.
+- **Popups.** A trashed popup stops deciding immediately: it is not a
+  candidate, and recording events or captures against it fails. Its event
+  history stays until purge.
+- **Segments.** A trashed segment stops answering, and every consumer fails
+  closed: a popup wired to it does not show (neither the inSegment nor the
+  notInSegment reading), a contract price list stops applying, an automation
+  does not start, and a segment-scoped messaging window steps aside so the
+  default quiet-hours and caps still govern. Purging a segment that another
+  surface still wires in is refused with a plain sentence.
+- **Saved views — personal.** Only the owner sees or recovers their trashed
+  views; a colleague's shared view that its owner trashed is not visible to
+  anyone else. The daily sweep reclaims every owner's expired trash.
+
+**Purging** requires typing `PURGE` and a recent identity verification. It
+only accepts an already trashed record. Families whose rows — or whose child
+rows, by cascade — carry contact personal data (forms via submissions, popups
+via events, segments via captured membership) refuse to purge while any of
+those contacts is under an active retention exception; the same guard covers
+the scheduled sweep. Pages and saved views name no contact, so no contact-
+scoped hold can apply to them and their purge carries no hold guard.
+
+Privacy erasure still reaches the evidence rows while their parent is in
+trash — submissions are anonymized in place, captured membership and popup
+event links are removed — and restoring the parent never resurrects that
+erased data.
+
+Open **View trash** from the notes panel or task list, or open
+`/admin/trash` directly. The paginated trash screen uses the same record
+permissions as those surfaces: view access allows reading; manage access (or
+ownership, for saved views) allows restore or purge.
+
+The daily `core.purgeExpiredWorkRecords` job permanently purges eligible
+trash older than thirty days, up to 500 records of each kind per run. Active
+retention holds protect records from both this job and manual purge. Inspect
+failed jobs in the existing platform job screen and retry after resolving the
+failure. Configured retention policies and privacy erasure still apply and may
+remove records before the normal thirty-day trash period. This feature does
+not recover records that were permanently deleted before it was installed.
+
+## What recovery deliberately does not cover
+
+Not every family gets undelete, and the exclusions are deliberate rather than
+oversights:
+
+- **Money and ledger records** (orders, invoices, quotes, credit notes,
+  payments, subscriptions, gift cards) are never hard-deleted; their
+  reversible layer is the state machine — void, cancel, refund — which keeps
+  numbers, audit trail and `RETENTION_TABLE_OPT_OUTS` legal/accounting holds.
+  There is nothing to undelete.
+- **Append-only evidence** (audit log, timeline events, the outbox, consent
+  records, SMS compliance, data requests and erasure receipts) is opted out
+  by spec. Restoring an erasure receipt would be wrong.
+- **Credentials and bearers** (API keys, sessions, magic links, share links,
+  device tokens, payment methods) must not be recoverable — security requires
+  that revoking one is final.
+- **Join and fan-out rows** (project collections, order items, captured
+  memberships) ride their parent; recovering the parent recovers them.
+- **Families with no delete path at all** (contacts, conversations, deals,
+  bookings, projects, galleries, documents, suppliers, gift registries,
+  events, newsletters, loyalty, reviews, referrals) already keep every row —
+  the "no silent loss" promise holds by construction.
+- **Owner configuration whose removal is the act itself** — redirects, webhook
+  endpoints, keyword actions, scoring rules, playbooks, export artifacts and
+  grants — is recreated by re-entering it, not recovered; deleting it never
+  takes customer data with it.
+
+Migration `0011_record_trash.sql` adds nullable timestamps and partial indexes
+to the five new tables; existing rows remain active. No second contact or
+archive store is introduced. Ownership exports include the original rows and
+trash timestamps, and instance backup/restore preserves them.
+
+Application versions predating migration `0011` do not filter the new trash
+timestamps. If rolling back to such a version, restore its matching
+pre-upgrade database backup through the normal rollback procedure; retaining
+the upgraded database would make trashed pages, forms, popups, segments and
+saved views appear active to the old code. (The same caveat has applied to
+`0010` note and task trash since it shipped.)

package/dist/template/deploy/release-channels.md

@@ -0,0 +1,27 @@
+# Release channels
+
+An update is only as honest as the metadata that describes it. Freeholder
+does not infer “this is a patch, so it is safe” from a version number.
+
+| Channel | What it carries |
+|---|---|
+| `stable` | Patch and minor releases. The default. |
+| `security` | Security-only patches, backported to the current and previous minor. |
+| `edge` | `main`. For contributors and freeholder.ai itself. |
+
+An instance subscribed to `stable` also receives `security`. An instance
+subscribed to `security` receives only that channel. `edge` receives
+everything.
+
+Every release declares, in machine-readable form:
+
+- **minFromVersion** — the earliest version it can be applied from
+- **schemaRisk** — `compatible` or `breaking`
+- **CVSS** and **severity** — a score where a CVE applies, otherwise neither
+- **manualSteps** — an empty list when none are required
+- **pluginApi** — the plugin-API version this release ships
+
+`platform.describeRelease` reports this build’s declaration. Doctor checks
+`update.channel` and `update.release`. The signed feed that publishes these
+records is C10.03; this document is not a claim that unattended self-update
+is already running.

package/dist/template/deploy/release-feed.md

@@ -0,0 +1,53 @@
+# Signed release feed
+
+The update feed is a static `releases.json` published next to each versioned
+image. The instance ships the Ed25519 public key that must have signed it. A
+signature that does not verify is a hard stop — never a warning that scrolls
+past.
+
+This is not unattended self-update. Checking the feed on a schedule is C10.04.
+
+## What each entry carries
+
+Every release names its channel, `minFromVersion`, schema risk, CVSS/severity,
+manual steps, plugin-API version, image digest, the image repository, a link
+to the assembled notes, and the workflow that built it. The updater reads
+those fields; it does not infer them from the version number.
+
+The image itself is still signed keyless (cosign) with GitHub provenance and
+an SPDX SBOM, as in [`ci-release-gate.md`](ci-release-gate.md). The feed
+points at that digest; it does not replace image verification.
+
+## Where it is published
+
+On a matching version tag (including a beta), `Publish image` signs `releases.json` with
+`FREEHOLDER_RELEASE_SIGNING_KEY` and uploads it as a release asset:
+
+`https://github.com/CampDenman/freeholder/releases/download/<version-tag>/releases.json`
+
+The default discovery endpoint is
+`https://api.github.com/repos/CampDenman/freeholder/releases`.
+
+## Key rotation
+
+Trusted keys live in `src/core/update/trusted-release-keys.json`;
+`src/core/update/keys.ts` exposes them to the runtime.
+
+1. Generate a new Ed25519 key pair.
+2. Add the new public key as `active` and mark the previous key `retiring`.
+3. Store the new private key as `FREEHOLDER_RELEASE_SIGNING_KEY` and set
+   the publication workflow’s `FREEHOLDER_RELEASE_KEY_ID` to the new id.
+4. Ship that image. Feeds signed by either key still verify.
+5. Once every supported image includes the new public key, remove the
+   retiring key.
+
+An instance never fetches a replacement key from the network. Rotation is
+an image update.
+
+`platform.verifyReleaseFeed` is the same hard stop Doctor describes as
+`update.feed.key`.
+
+The default updater discovers the newest published signed feed from this public
+release list, including prereleases, and constructs the versioned asset URL in
+the fixed upstream repository. It does not treat a beta as stable/latest; signed
+feed verification and channel selection still apply.

package/dist/template/deploy/release-notes-2026-09-14.md

@@ -0,0 +1,86 @@
+<!--
+Copyright (C) 2026 Tony Aly
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# Release notes — session digest 2026-09-14
+
+Product version remains **0.1.0**, in active development. This is a session
+digest, not a release-candidate announcement or a claim of deployment.
+`CHANGELOG.md`, generated from `.changeset/`, is the canonical owner-facing
+change list. This snapshot includes main through `55d65fc` (#372); refresh
+GitHub before treating the pending changes below as shipped.
+
+## Available on main
+
+- **Broader, permission-aware search.** Orders, subscriptions, gift registries,
+  suppliers, agreements, price lists, marketplace orders and privacy request
+  IDs join the existing search sources. Results use the corresponding read
+  permissions and open the relevant record. Privacy request bodies and
+  signing credentials are excluded. Labels ship in English, French and Spanish
+  (#366, #369, #371).
+- **Access-control repairs.** Private order reads and stock operations enforce
+  their permissions. Cart capabilities, private wishlists and hidden location
+  addresses are protected. Private-note pinning and revision history enforce
+  the same visibility rules as ordinary reads (#365, #367, #368, #372).
+- **Provider implementations.** Paid catalog lines can use the Printify adapter;
+  Shopify sync verifies and imports paid orders; Daily supports private rooms
+  and verified recording access (#362–#364). These are implemented provider
+  paths with automated contract tests, not completed live-account acceptance.
+- **Honest provider erasure.** A privacy erasure request remains in progress
+  while durable Daily recording/transcript cleanup jobs are outstanding.
+  Retries retain the original job identity; completion follows successful
+  cleanup acknowledgment. The admin screen shows pending cleanup (#370).
+- **Audit and verification repairs.** The audit corrected authorization,
+  provider-state and completion-evidence gaps, verified performance fixture
+  counts, repaired tied-row pagination and expanded browser coverage. Booking
+  tests now use future dates for live-clock workflows (#361, #369).
+
+The earlier search, per-kind retention, first-party plugin screens and customer
+app work remains available. Retention holds still protect eligible records.
+Native store binaries and physical-device acceptance are not claimed.
+
+## Implemented in open PRs — not yet on main at this snapshot
+
+- **[#381](https://github.com/CampDenman/freeholder/pull/381): note/task recovery.**
+  Move records to trash, restore their original IDs/history/links, or explicitly
+  confirm permanent deletion with recent identity verification. Privacy holds
+  protect manual and scheduled purge; privacy erasure remains irreversible.
+  Project checklists/counts exclude trash. Task navigation and saved views use
+  task permissions. Includes localized, paginated UI and migration `0010`.
+- **[#382](https://github.com/CampDenman/freeholder/pull/382): queue measurements.**
+  Twenty real worker dispatches provide database enqueue-to-start samples and
+  p95. Missing or failed work fails the harness. Local small/medium runs passed
+  with p95 of 1,985/1,982 ms; these are diagnostic results, not reference-host
+  acceptance. Requested missing auxiliary clocks also fail on the large fixture.
+
+Both PRs require fresh green checks and the protected merge queue. Current
+blockers and tested commit references are recorded in `SESSION_HANDOFF.md`.
+
+## Operator notes
+
+- Main currently has migrations `0000_reviewed-baseline.sql` through `0009`.
+  Note/task trash adds `0010` only when #381 lands. Inspect the journal before
+  allocating another number.
+- Daily cleanup operations are documented in
+  [`provider-recording-erasure.md`](provider-recording-erasure.md). Owner-storage
+  recording import and complete live-provider acceptance remain unfinished.
+- The pending recovery runbook documents rollback compatibility: old app builds
+  do not filter trash timestamps; use the matching pre-upgrade database backup
+  when rolling back to a version predating that behavior.
+- `doctl` 1.168.0 and Android platform tools 37.0.1 are installed on the local
+  workstation. DigitalOcean authentication and Replit SSH setup await the
+  owner's connection steps. Neither test device has been detected or wiped.
+- No live hosting deployment, payment settlement, device acceptance, image
+  publication or independent security-review completion is claimed by this update.
+
+## Completion status
+
+`MASTER.md` §43 remains authoritative: **255 of 273 C-items checked, 18 open**.
+The full gate counts F/B criteria too: **297 IDs, 267 checked, 30 open**.
+Provider coverage, whole-product verification, reference-host performance,
+second-target restore, physical-device evidence, independent security review
+and the clean-room/owner completion record remain outstanding.
+
+For reproducible commands, PR state and account/device setup, read
+[`SESSION_HANDOFF.md`](../SESSION_HANDOFF.md).

package/dist/template/deploy/release-notes-2026-09-15.md

@@ -0,0 +1,52 @@
+<!--
+Copyright (C) 2026 Tony Aly
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# Release notes — session digest 2026-09-15
+
+Product version remains **0.1.0**, in active development. This is a session
+digest, not a release-candidate announcement or a claim of deployment.
+`CHANGELOG.md`, generated from `.changeset/`, is the canonical owner-facing
+change list.
+
+## Scope decision — mobile apps move to v2
+
+**Owner decision, 2026-09-15 (Tony Aly):** "DONE now means everything but the
+mobile apps — mobile happens as v2." The seven remaining mobile-app acceptance
+items — **C10.17, C10.18, C10.25, C10.26, C10.27, C10.28 and C10.30** — are
+deferred to v2 and recorded in `MASTER.md` §43.18.
+
+This is a dated, bounded, owner-approved scope decision, not a generic escape
+hatch. The plan's doctrine stands: version labels express dependency order,
+not an excuse to leave the product incomplete. Concretely:
+
+- Each deferred item is quoted verbatim in §43.18 with its ID, evidence and
+  outstanding physical-device obligations intact; §35 remains the v2
+  specification for the mobile apps.
+- Checked mobile items stay checked — their evidence stands. Native store
+  binaries and physical-device acceptance are still not claimed.
+- The plan gate encodes the same closed set as an explicit `DEFERRED`
+  constant: references to those IDs keep resolving, C10 sequence contiguity
+  is computed around the sanctioned holes, and any change that re-enters one
+  of the seven into the live checklist as a checkbox fails the gate. An item
+  leaves the set only by shipping in v2 or by explicit owner reversal, never
+  by silent deletion.
+- §43.1's completion rule, scope-of-DONE paragraph and remaining-open row now
+  name the deferral; the owner signature and completion record remain
+  untouched and unsigned.
+
+The rest of the plan is unchanged: C0.11, C3.13, C11.08–C11.17 and the
+per-item F01–F12 rows remain open v1 work.
+
+## Completion status
+
+`MASTER.md` §43 remains authoritative. After the deferral the full gate
+counts: **290 IDs, 267 checked, 23 open** (was 297 / 267 / 30; the seven
+deferred mobile items leave the live sequence, all other counts unchanged).
+Provider live-acceptance, whole-product verification, reference-host
+performance, second-target restore, independent security review and the
+clean-room/owner completion record remain outstanding.
+
+For reproducible commands, PR state and account/device setup, read
+[`SESSION_HANDOFF.md`](../SESSION_HANDOFF.md).

package/dist/template/deploy/release-notes-2026-09-16.md

@@ -0,0 +1,114 @@
+<!--
+Copyright (C) 2026 Tony Aly
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# Release notes — session digest 2026-09-16
+
+Product version remains **0.1.0**, in active development. This is a session
+digest, not a release-candidate announcement or a claim of deployment.
+`CHANGELOG.md`, generated from `.changeset/`, is the canonical owner-facing
+change list. This snapshot covers the `feat/rtl-ar-catalog` branch; refresh
+GitHub before treating the pending change below as shipped.
+
+## Implemented in the open RTL PR — not yet on main at this snapshot
+
+- **Arabic ships as a complete catalog.** `locales/ar.json` carries all 6,340
+  English strings in Modern Standard Arabic, ICU placeholders and plural
+  contracts preserved exactly and enforced by `tests/core/i18n-gate.test.ts`.
+  The provenance table in `locales/README.md` labels it AI-drafted pending
+  native review, the same honesty the French and Spanish catalogs carry.
+  Enabling `ar` in Settings flips the admin, storefront and portal to
+  right-to-left from the locale's script — no layout rewrite.
+- **Accessibility acceptance closes C11.12.** `tests/browser/accessibility.spec.ts`
+  proves RTL from the shipped catalog instead of an injected `dir` attribute:
+  `/admin`, `/ar` and the portal all render `html[lang=ar][dir=rtl]` and pass
+  axe WCAG 2.0/2.1/2.2 A+AA — the admin in both asserted themes — plus the
+  bypass-link, Enter-to-main and 12-stop keyboard loop, and the 320px reflow
+  with nested-scroll refusal. Populated contact, invoice, product and
+  appointment detail forms carry the same full pass, ten owner screens join
+  the list scan, and the French and Spanish storefronts join the 320px
+  reflow. The covered matrix is locale (en/fr/es/ar) × theme (light/dark) ×
+  viewport (1280px/320px) across admin, detail forms, storefront and portal.
+- **Arabic SMS compliance.** The mandatory carrier control words recognise
+  Arabic STOP/START/HELP keywords and the non-configurable compliance replies
+  answer in Arabic for an Arabic-preferred contact; owner keyword rules still
+  cannot shadow any of them.
+
+Native review of the Arabic catalog remains the follow-up, as it does for
+French and Spanish. Live provider acceptance and the other open C-items are
+unchanged.
+
+## F-criteria evidence matrix — closes C0.11 and C11.09 (docs(plan) PR)
+
+- **Every completion claim now faces all twelve F-criteria.**
+  `deploy/f-criteria-matrix.md` audits F01–F12 across 286 rows: every live
+  §43 checklist item (the row set computed from `scripts/plan-gate.mjs`, so
+  it cannot drift from the plan), the seven mobile items deferred to v2,
+  all seven workspace packages and all six first-party plugins. Every cell
+  is a repository citation that resolves or a specific `N/A — reason`.
+- **The matrix is gate-enforced, not a one-time document.**
+  `scripts/f-matrix.mjs` + `tests/core/f-matrix.test.ts` fail on row-set
+  drift, empty cells, unresolvable citations, cited test files outside the
+  suite, and lazy N/A — and run inside `pnpm gates`.
+- **The C0.11 audit sampled for truth, not presence.** Every item the
+  2026-09-13 audit reopened or repaired was re-read assertion-by-assertion
+  (all confirmed true), plus a deterministic 15% sample of the rest. Three
+  finding classes are corrected in the change: C4.08's annotation claimed
+  the calendar screen as its F04 (now `/admin/work/playbooks`); 45
+  annotations carried a "covers permission, refusal and recovery" stamp
+  their cited file does not prove (narrowed per-cell in the matrix with
+  `tests/core/api.test.ts` named for the scoped-permission half; annotation
+  rewrites landed with C11.15 below); C11.12/C1.17 cells cited catalog gates as
+  service-boundary proof (curated to the true evidence). No capability
+  claim proved false; no unrelated checkbox moved.
+- **Full-suite verification** is recorded in the matrix header — the whole
+  `pnpm test` suite ran green on a fresh disposable database with every
+  cited test file part of the run.
+
+## Doc-claim mapping — C11.15 closed (docs/doc-claim-mapping)
+
+- **Every §§1–42 claim now carries evidence or a same-change strike.**
+  `deploy/doc-claim-mapping.md` inventories 118 claim rows across all 42
+  sections: 108 map to a passing suite, gate or generated artifact, and 10
+  are Struck/Narrowed in MASTER.md itself — §12's mail-adapter id literal,
+  §21b's `scripts/backup.sh` path (the script ships at
+  `deploy/digitalocean-droplet/infra/backup.sh`), §25's "MIT plugin-kit"
+  (every package is Apache-2.0), §27's hosted canonical-registry/catalog
+  claims, §28's hosted docs site with executable guides, §31's "pgvector"
+  (retrieval ranks a `real[]` column by cosine on stock Postgres), §4.8's
+  instance-release-notes scope (platform upgrades auto-draft today; wider
+  auto-draft and the agent-note mandate remain work), §37's "every accepted
+  change writes a ReleaseNote", §38's unqualified release-notes bullet, and
+  §34's changelog share target. The item text's two judgement calls stand as
+  documented behaviour: §35 branded placeholder screenshots and adapter
+  "not implemented" fail-closed refusals.
+- **The map is a gate, not a promise.** `tests/core/doc-claim-mapping.test.ts`
+  (in `pnpm gates` via `scripts/fast-gates.mjs`) fails on any unmapped
+  section, any evidence path that does not resolve, any claim row citing no
+  test or gate, and any strike whose old wording still parses in MASTER.md
+  or whose new wording is missing. C11.15 is checked with F04/F05 N/A,
+  F07 = the fail-closed mapping gate, F09 = the mapping doc + gate, F12 =
+  alignment with `deploy/spec-reconciliation.md`.
+
+## Session wrap — completion push
+
+- **Everything closable by software is closed.** Since the 2026-09-15
+  snapshot, #381–#397 landed: note/task trash, real queue-dispatch
+  measurement, the dependabot react-group fix, the §43.18 mobile→v2
+  deferral, the Arabic RTL catalog (C11.12), C3.13's software remainder,
+  trash for pages/forms/popups/segments/saved views (C11.14), the F01–F12
+  evidence matrix (C0.11, C11.09) and the §§1–42 claim mapping (C11.15).
+  Dependabot #373–#380 and #83 merged; #109 (TypeScript major) closed as a
+  deliberate manual upgrade.
+- **Plan state: 290 IDs, 272 checked, 18 open.** The 18 are §43.2's twelve
+  F-template rows plus six C-items, each blocked on the owner: C3.13 (live
+  Printify/Shopify/Daily accounts), C11.08 (Replit/DO second target), C11.10
+  (named reviewer), C11.11 (doctl auth + droplet), C11.16 (auto-unblocks
+  after C3.13), C11.17 (owner signature). No closable-by-software work
+  remains; mobile devices are v2 scope, so no v1 wipe or setup is pending.
+- **Handoff and evidence refreshed.** `SESSION_HANDOFF.md` now carries the
+  owner action list with prepared commands; §43.1's evidence snapshot cites
+  this digest, the matrix and the claim mapping. Full-suite verification:
+  3,655–3,657 tests passing, 17 deploy-recipe skips, one pre-existing funnel
+  isolation flake (documented in both mapping headers).