create-ailk 0.20.0 → 0.22.0

package/site-templates/shapes/person-service/TEMPLATE-MANIFEST.md

@@ -232,6 +232,14 @@ _Code route — no content, no sections._
 
 <!-- generated:end -->
 
+<!-- generated:begin page=/working-agreement -->
+
+| #   | Section                             | Component         | Copy (first line) |
+| --- | ----------------------------------- | ----------------- | ----------------- |
+| 1   | `document-chassis` (layout=article) | `DocumentChassis` | Working Agreement |
+
+<!-- generated:end -->
+
 `/blog` (the Free teaser row, § 1.9 — served by the generic `[slug]` route over the always-copied overlay's `BlogList/blog.mdx`):
 
 <!-- generated:begin page=/blog -->
@@ -287,8 +295,9 @@ The standard page set for this shape (`derive-roster.py --shape person-service -
 | `PortfolioList` · `PortfolioItem` | the portfolio pair belongs to every shape's standard roster (operator, 2026-09-25; roadmap § 4)                                                                                                                               |
 | `BlogList`                        | every Free scaffold's nav links `/blog` unconditionally (`renderNavConfig`, operator ruling 2026-09-23); the Free teaser serves it, as on organization-product (#6753 D3)                                                     |
 | `LandingPage`                     | the Free `/meet` meeting-types hub is a LandingPage seed, the same generic `[slug]` route serves it through (#6897 D3); the four `/meet/[slug]` BookCall detail seeds ride the `BookCall` type already in the standard roster |
+| `WorkingAgreementPage`            | the Contact form's terms checkbox links `/working-agreement` beside `/terms` and `/privacy`, so every starter ships the page from `_base` (#8661 D10)                                                                         |
 
-`|S − D| = 13` and `|R| = 18`.
+`|S − D| = 13` and `|R| = 19`.
 
 `/sign-in` and `/sign-up` are also rostered (#6797) — code routes (`kind: route`) with no page type, so they sit outside this set equation: the locale layout's header links both, and the roster of record lists every page the scaffold serves.
 
@@ -305,26 +314,27 @@ person-service:
   shape: person-service
   design: standard
   roster:
-    - { route: "/",                 kind: page, content: ["content/en/HomePage/home.mdx"] }
-    - { route: "/services",         kind: page, content: ["content/en/ServicesList/services.mdx"] }
-    - { route: "/services/[slug]",  kind: page, contentDir: "content/en/Service" }
-    - { route: "/for",              kind: page, content: ["content/en/UseCasesList/for.mdx"] }
-    - { route: "/for/[slug]",       kind: page, contentDir: "content/en/UseCase" }
-    - { route: "/about",            kind: page, content: ["content/en/AboutPage/about.mdx"] }
-    - { route: "/contact",          kind: page, content: ["content/en/ContactPage/contact.mdx"] }
-    - { route: "/faq",              kind: page, content: ["content/en/FAQPage/faq.mdx"] }
-    - { route: "/glossary",         kind: page, content: ["content/en/GlossaryList/glossary.mdx"] }
-    - { route: "/newsletter",       kind: page, content: ["content/en/NewsletterSignup/newsletter.mdx"] }
-    - { route: "/sign-in",          kind: route }
-    - { route: "/sign-up",          kind: route }
-    - { route: "/purchase-policy",  kind: page, content: ["content/en/PurchasePolicyPage/purchase-policy.mdx"] }
-    - { route: "/privacy",          kind: page, content: ["content/en/PrivacyPage/privacy.mdx"] }
-    - { route: "/terms",            kind: page, content: ["content/en/TermsPage/terms.mdx"] }
-    - { route: "/blog",             kind: page, content: ["content/en/BlogList/blog.mdx"] }
-    - { route: "/meet",             kind: page, content: ["content/en/LandingPage/meet.mdx"] }
-    - { route: "/meet/[slug]",      kind: page, content: ["content/en/BookCall/book-a-call.mdx", "content/en/BookCall/onsite-estimate.mdx", "content/en/BookCall/start-project.mdx", "content/en/BookCall/onsite-service.mdx"] }
-    - { route: "/portfolio",        kind: page, content: ["content/en/PortfolioList/portfolio.mdx"] }
-    - { route: "/portfolio/[slug]", kind: page, contentDir: "content/en/PortfolioItem" }
+    - { route: "/",                  kind: page, content: ["content/en/HomePage/home.mdx"] }
+    - { route: "/services",          kind: page, content: ["content/en/ServicesList/services.mdx"] }
+    - { route: "/services/[slug]",   kind: page, contentDir: "content/en/Service" }
+    - { route: "/for",               kind: page, content: ["content/en/UseCasesList/for.mdx"] }
+    - { route: "/for/[slug]",        kind: page, contentDir: "content/en/UseCase" }
+    - { route: "/about",             kind: page, content: ["content/en/AboutPage/about.mdx"] }
+    - { route: "/contact",           kind: page, content: ["content/en/ContactPage/contact.mdx"] }
+    - { route: "/faq",               kind: page, content: ["content/en/FAQPage/faq.mdx"] }
+    - { route: "/glossary",          kind: page, content: ["content/en/GlossaryList/glossary.mdx"] }
+    - { route: "/newsletter",        kind: page, content: ["content/en/NewsletterSignup/newsletter.mdx"] }
+    - { route: "/sign-in",           kind: route }
+    - { route: "/sign-up",           kind: route }
+    - { route: "/purchase-policy",   kind: page, content: ["content/en/PurchasePolicyPage/purchase-policy.mdx"] }
+    - { route: "/privacy",           kind: page, content: ["content/en/PrivacyPage/privacy.mdx"] }
+    - { route: "/terms",             kind: page, content: ["content/en/TermsPage/terms.mdx"] }
+    - { route: "/working-agreement", kind: page, content: ["content/en/WorkingAgreementPage/working-agreement.mdx"] }
+    - { route: "/blog",              kind: page, content: ["content/en/BlogList/blog.mdx"] }
+    - { route: "/meet",              kind: page, content: ["content/en/LandingPage/meet.mdx"] }
+    - { route: "/meet/[slug]",       kind: page, content: ["content/en/BookCall/book-a-call.mdx", "content/en/BookCall/onsite-estimate.mdx", "content/en/BookCall/start-project.mdx", "content/en/BookCall/onsite-service.mdx"] }
+    - { route: "/portfolio",         kind: page, content: ["content/en/PortfolioList/portfolio.mdx"] }
+    - { route: "/portfolio/[slug]",  kind: page, contentDir: "content/en/PortfolioItem" }
 ```
 
 <!-- generated:end -->

package/templates/README.md

@@ -43,31 +43,32 @@ The pages of the Free `organization-product` shape, and where each one's copy li
 
 <!-- generated:begin content -->
 
-| Page                | Content file                                                                                                                                                        | Ships in                       |
-| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
-| `/`                 | `content/en/HomePage/home.mdx`                                                                                                                                      | every scaffold                 |
-| `/features`         | `content/en/FeaturesList/features.mdx`                                                                                                                              | `--shape organization-product` |
-| `/features/[slug]`  | — (a code route)                                                                                                                                                    | `--shape organization-product` |
-| `/for`              | `content/en/UseCasesList/for.mdx`                                                                                                                                   | `--shape organization-product` |
-| `/for/[slug]`       | — (a code route)                                                                                                                                                    | `--shape organization-product` |
-| `/pricing`          | `content/en/Pricing/pricing.mdx`                                                                                                                                    | `--shape organization-product` |
-| `/about`            | `content/en/AboutPage/about.mdx`                                                                                                                                    | every scaffold                 |
-| `/faq`              | `content/en/FAQPage/faq.mdx`                                                                                                                                        | every scaffold                 |
-| `/contact`          | `content/en/ContactPage/contact.mdx`                                                                                                                                | every scaffold                 |
-| `/glossary`         | `content/en/GlossaryList/glossary.mdx`                                                                                                                              | `--shape organization-product` |
-| `/newsletter`       | `content/en/NewsletterSignup/newsletter.mdx`                                                                                                                        | `--shape organization-product` |
-| `/sign-in`          | — (a code route)                                                                                                                                                    | every scaffold                 |
-| `/sign-up`          | — (a code route)                                                                                                                                                    | every scaffold                 |
-| `/privacy`          | `content/en/PrivacyPage/privacy.mdx`                                                                                                                                | `--shape organization-product` |
-| `/terms`            | `content/en/TermsPage/terms.mdx`                                                                                                                                    | `--shape organization-product` |
-| `/purchase-policy`  | `content/en/PurchasePolicyPage/purchase-policy.mdx`                                                                                                                 | every scaffold                 |
-| `/blog`             | `content/en/BlogList/blog.mdx`                                                                                                                                      | every scaffold                 |
-| `/meet`             | `content/en/LandingPage/meet.mdx`                                                                                                                                   | every scaffold                 |
-| `/meet/[slug]`      | `content/en/BookCall/book-a-call.mdx`, `content/en/BookCall/onsite-estimate.mdx`, `content/en/BookCall/start-project.mdx`, `content/en/BookCall/onsite-service.mdx` | every scaffold                 |
-| `/portfolio`        | `content/en/PortfolioList/portfolio.mdx`                                                                                                                            | `--shape organization-product` |
-| `/portfolio/[slug]` | — (a code route)                                                                                                                                                    | `--shape organization-product` |
-| `/team`             | `content/en/TeamList/team.mdx`                                                                                                                                      | `--shape organization-product` |
-| `/team/[slug]`      | — (a code route)                                                                                                                                                    | `--shape organization-product` |
+| Page                 | Content file                                                                                                                                                        | Ships in                       |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
+| `/`                  | `content/en/HomePage/home.mdx`                                                                                                                                      | every scaffold                 |
+| `/features`          | `content/en/FeaturesList/features.mdx`                                                                                                                              | `--shape organization-product` |
+| `/features/[slug]`   | — (a code route)                                                                                                                                                    | `--shape organization-product` |
+| `/for`               | `content/en/UseCasesList/for.mdx`                                                                                                                                   | `--shape organization-product` |
+| `/for/[slug]`        | — (a code route)                                                                                                                                                    | `--shape organization-product` |
+| `/pricing`           | `content/en/Pricing/pricing.mdx`                                                                                                                                    | `--shape organization-product` |
+| `/about`             | `content/en/AboutPage/about.mdx`                                                                                                                                    | every scaffold                 |
+| `/faq`               | `content/en/FAQPage/faq.mdx`                                                                                                                                        | every scaffold                 |
+| `/contact`           | `content/en/ContactPage/contact.mdx`                                                                                                                                | every scaffold                 |
+| `/glossary`          | `content/en/GlossaryList/glossary.mdx`                                                                                                                              | `--shape organization-product` |
+| `/newsletter`        | `content/en/NewsletterSignup/newsletter.mdx`                                                                                                                        | `--shape organization-product` |
+| `/sign-in`           | — (a code route)                                                                                                                                                    | every scaffold                 |
+| `/sign-up`           | — (a code route)                                                                                                                                                    | every scaffold                 |
+| `/privacy`           | `content/en/PrivacyPage/privacy.mdx`                                                                                                                                | `--shape organization-product` |
+| `/terms`             | `content/en/TermsPage/terms.mdx`                                                                                                                                    | `--shape organization-product` |
+| `/working-agreement` | `content/en/WorkingAgreementPage/working-agreement.mdx`                                                                                                             | `--shape organization-product` |
+| `/purchase-policy`   | `content/en/PurchasePolicyPage/purchase-policy.mdx`                                                                                                                 | every scaffold                 |
+| `/blog`              | `content/en/BlogList/blog.mdx`                                                                                                                                      | every scaffold                 |
+| `/meet`              | `content/en/LandingPage/meet.mdx`                                                                                                                                   | every scaffold                 |
+| `/meet/[slug]`       | `content/en/BookCall/book-a-call.mdx`, `content/en/BookCall/onsite-estimate.mdx`, `content/en/BookCall/start-project.mdx`, `content/en/BookCall/onsite-service.mdx` | every scaffold                 |
+| `/portfolio`         | `content/en/PortfolioList/portfolio.mdx`                                                                                                                            | `--shape organization-product` |
+| `/portfolio/[slug]`  | — (a code route)                                                                                                                                                    | `--shape organization-product` |
+| `/team`              | `content/en/TeamList/team.mdx`                                                                                                                                      | `--shape organization-product` |
+| `/team/[slug]`       | — (a code route)                                                                                                                                                    | `--shape organization-product` |
 
 <!-- generated:end -->
 

package/templates/apps/api/CLAUDE.md

@@ -40,18 +40,18 @@ The root index sits outside `/v1/*`:
 
 Routes are versioned under `/v1/*`:
 
-- `/v1/leads/{submit,subscribe,callback}` — lead capture, newsletter subscription, callback request. Where a lead goes is `src/lib/lead-delivery.ts` (#6730): `DATABASE_URL` set → the database (the inbox); no database but `RESEND_API_KEY` + `AILK_LEAD_NOTIFICATION_TO` + `AILK_LEAD_NOTIFICATION_FROM` → the owner email IS the delivery (`persisted: "email"`, a refused send is `503 delivery_failed`); neither outside production → the local file fallback; neither in production → `503 lead_capture_not_configured` before any write. A newsletter signup needs a database (or the local file). A lead is never reported captured when nothing stored or delivered it.
+- `/v1/leads/{submit,subscribe,callback}` — lead capture, newsletter subscription, callback request. **A contact lead carries terms acceptance (#8730):** a `submit` whose `source` is a contact source (`isContactLeadSource` — `contact-form`, `conversational-intake`, `flow:contact`) without a top-level `consent: true` is `400 consent_required` before the tenant read; an accepted one gets `payload.consent = { statement, acceptedAt }` written by the route (the platform's `CONTACT_FORM_TERMS_STATEMENT` and the request's receive time), replacing any the client sent. Other sources, `subscribe` and `callback` are unchanged. **A magnet's completion (#8757 D6):** after a `flow:<slug>` submit is written to the database, `services/magnet-completion.ts` reads that LIVE magnet's setting. `invite` adds `next: { completion: "invite" }` to the 201 and, on a first write (never a replay), sends the submitter one `sendDeliverableEmail` from the completion emails' sender (`AILK_DELIVERABLE_EMAIL_FROM`, else `AILK_LEAD_NOTIFICATION_FROM`) — the magnet's `completionEmail` copy, else "We received your {title}" — whose link (`cta` "Track this in your account") is `accountOrigin + accountInvitePath(…)`: `FRONTEND_URL`'s origin with `/sign-in` for a keyless caller on a `workspace`/`multi-tenant` build, the enabled spoke sign-in client's callback origin (`https:` unless `NODE_ENV=development`) with `/api/hub-session/sign-in` for a spoke; no origin degrades to `lead`. The completion read waits at most 1.5 s (`MAGNET_COMPLETION_BUDGET_MS`). Capped in the database at one email per recipient per magnet per day and 50 per magnet per hour (a capped send keeps `next`); logged `{ event: "magnet-invite", outcome }`, never the address. `checkout` adds `next: { completion: "checkout", checkoutOffering }` only while the `commerce` claim reads `claimed` and the offering is still listed. A failed read or send never changes the 201. `capture_lead` posts `source: "mcp"`, so its answer and the parity rows are unchanged. Where a lead goes is `src/lib/lead-delivery.ts` (#6730): `DATABASE_URL` set → the database (the inbox); no database but `RESEND_API_KEY` + `AILK_LEAD_NOTIFICATION_TO` + `AILK_LEAD_NOTIFICATION_FROM` → the owner email IS the delivery (`persisted: "email"`, a refused send is `503 delivery_failed`); neither outside production → the local file fallback; neither in production → `503 lead_capture_not_configured` before any write. A newsletter signup needs a database (or the local file). A lead is never reported captured when nothing stored or delivered it.
 - `/v1/leads/capture` (GET) — `{ ok: true, data: { contact, newsletter } }`, two booleans saying whether a submit / a subscribe would be accepted (#6730). The web contact page reads it to show the form or the site's contact email. Never names the delivery mode, an address or an env var. Registered at the top level, outside `leadsScope`'s strict per-IP limit. No MCP twin — a recorded exception on the same footing as the anonymous form-lifecycle routes: an agent needs no preflight, because the three lead-write tools already return the 503 when capture is not accepted.
 - `/v1/leads` (GET, `?cursor=&limit=`) — the leads INBOX read (#5678): the caller's OWN sites' leads, newest first, cursor-paginated (`limit` defaults to 50, max 200; `(createdAt desc, id desc)`; `cursor` is the previous page's last row id, and one that does not resolve within the caller's scope is a 400, never a silent page 1 — the API keeps that contract, and the web inbox deliberately softens it on its own side by re-reading page one when a URL-supplied cursor 400s, which is a rendering choice and not a change to this response). Five fields per row and nothing more — `id`, `name` (lifted from `payload.name` when the site's form captured one), `email`, `source`, `createdAt`; `payload`'s other keys, `siteId`, `promotedUserId` and `promotedAt` are never selected (`src/services/leads-inbox.ts` is the only read path). Registered in `authScope` only (auth, no tenant guard) and — alone in that scope — **unconditionally**, with no `isModuleEnabled()` gate: lead capture is a never-gate surface at every level, so reading a lead back cannot be gated either. Identity is `request.userId`; there is no site, org or workspace parameter, so the scope cannot be widened from the wire. It is resolved from the caller's own memberships by `src/services/owner-workspaces.ts`'s `resolveOwnerWorkspaces` — the ONE site→workspace resolution in this app, shared with `lead-promotion.ts` rather than written a second time — and every read filters `siteId ∈ workspaceIds`. Role floor: the `inbox-read` permission in `@working-theory/validation`'s permission table (#7636 D2) — every role, a member included (the operator's 2026-10-04 decision; contact PII is the inbox's job); the scope is the UNION of every workspace in the caller's organizations whose role holds `inbox-read`, not one active tenant, because this route registers outside the tenant scope. **Two deployment preconditions decide whether it returns anything, and both fail EMPTY rather than wide:** on a build with no `multi-tenant` module `resolveOwnerWorkspaces` resolves none (a deliberate scope limit since #5677), so there the scope is the default workspace, granted only through `services/default-tenant.ts`'s `resolveDefaultTenantForOperator` — `AILK_OPERATOR_EMAIL` set, the caller's verified email equal to it, a one-workspace deployment, a role holding `inbox-read` — and every other caller gets the empty page (#6730); and the `siteId` the leads were WRITTEN under must equal a workspace id. That `siteId` has TWO sources, and `currentSiteId()` is not the one on the primary path: the three POST capture routes read it from the REQUEST BODY (`routes/leads/index.ts`), which the capture sections declare in content and default to `"default"` (`ContactForm`/`Newsletter`/`StepFlow`, `ext.siteId ?? "default"`), while the recommender's capture path (`routes/flows/recommender.ts`) is the one that uses `currentSiteId()` (`lib/site.ts`, `AILK_SITE_ID ?? "default"`). A workspace id is `wksp_<uuidv7>`, so `siteId ∈ workspaceIds` matches only when the content-declared value — and, for recommender leads, `AILK_SITE_ID` — is set to it (the same convention `waitlist-dashboard.ts` already relies on). The rendered `name` is lifted from `payload.name` and truncated at 200 characters: the write side bounds `payload` at 64 keys and no per-value length, and `POST /v1/leads/submit` is anonymous with no ownership check on `siteId`. No MCP twin — identity-bound (#3591 exception, the same shape as `/v1/workspaces/*` and `/v1/billing/*`).
-- `/v1/flows/:slug` (GET), `/v1/flows/:slug/steps` (POST) — serve a flow config + submit a step's answers; server-side per-step partial-state persistence (#3956). The GET serves the stored config **minus `completionEmail`** (#7519 D5, SEC-7519-I1): `serveFlow` projects the owner's completion-email copy out, while completion reads the stored snapshot and sends it (`sendCompletionEmail`, for a flow with no `deliverables`). Module: `signal-collectors` (D-48, #5366) — registers only when the module is enabled; MCP twins `get_flow`/`submit_flow_step` carry the same `module` tag (D7).
-- `/v1/flows/:slug/definition` (PUT) — a registered spoke seeds one of its declared `flows/<slug>.json` into its OWN workspace (#7876, `src/routes/flows/index.ts` over `services/flow-engine.ts`'s `seedDeclaredFlow`). No MCP twin — recorded exception: a seed is a deploy-time write by the site's owner, and a spoke's `apps/mcp` acts through the same key for every anonymous agent, so a twin would give each of them write access to the site's flows. Off until the hub's operator sets `AILK_SPOKE_FLOW_SEED` (`403 flow_seed_disabled`, answered before the key or the database is read). The workspace comes from the `x-ailk-spoke-key` alone, through `resolveCallerSite`: a keyless call is `403 spoke_key_required` on any deployment, and a refused key `503 tenant_unresolved`. The body is a flow config of `slug`, `defaultLocale`, `steps`, `thankYou` and `flags` only — every block the hub acts on outside the spoke's own pages (emails, deliverables, pricing, registers, listings) is `400 field_not_seedable`; a slug a listing owns, a stored config the Admin extended with one of those blocks, or the standard `onboarding` slug (#8515 D15, before any read) is `409 slug_owned`, so a seed never deletes them or replaces the owner's onboarding questions. A config equal to the stored one (keys sorted) answers `unchanged` and writes nothing; otherwise `created` or `updated` through `upsertFlowDefinition`, so `kind`, `title` and `status` are written on create only. Route-level `bodyLimit` 256 KiB; the config is never echoed or logged. Module: `signal-collectors`.
+- `/v1/flows/:slug` (GET), `/v1/flows/:slug/steps` (POST) — serve a flow config + submit a step's answers; server-side per-step partial-state persistence (#3956). The GET serves the stored config **minus `completionEmail`** (#7519 D5, SEC-7519-I1): `serveFlow` projects the owner's completion-email copy out, while completion reads the stored snapshot and sends it (`sendCompletionEmail`, for a flow with no `deliverables`). Module: `signal-collectors` (D-48, #5366) — registers only when the module is enabled; MCP twins `get_flow`/`submit_flow_step` carry the same `module` tag (D7). **A completion on an `invite` magnet (#8771):** `submitStep` reads that LIVE magnet's setting once, at completion, through `services/magnet-completion.ts` (`magnetCompletionWithinBudget`, `accountTargetFor`) for the `accountCaller` the route hands it (`{ kind: "spoke", spokeId, workspaceId }` for a registered spoke's key, else `{ kind: "anonymous" }`; never taken from the body). On `invite` the response gains `data.next: { completion: "invite" }` (never the email) and `sendInviteConfirmation` is fired, not awaited, in place of the magnet's own `completionEmail` — one email, under #8757's caps; a flow with `deliverables` sends its deliverable's email only. Any other setting, a lead not written to the database, a failed read or a failed send gives no `next` and today's completion email. `submit_flow_step` returns the body as it came, so the twin carries `next` with no tool change.
+- `/v1/flows/:slug/definition` (PUT) — a registered spoke seeds one of its declared `flows/<slug>.json` into its OWN workspace (#7876, `src/routes/flows/index.ts` over `services/flow-engine.ts`'s `seedDeclaredFlow`). No MCP twin — recorded exception: a seed is a deploy-time write by the site's owner, and a spoke's `apps/mcp` acts through the same key for every anonymous agent, so a twin would give each of them write access to the site's flows. Off until the hub's operator sets `AILK_SPOKE_FLOW_SEED` (`403 flow_seed_disabled`, answered before the key or the database is read). The workspace comes from the `x-ailk-spoke-key` alone, through `resolveCallerSite`: a keyless call is `403 spoke_key_required` on any deployment, and a refused key `503 tenant_unresolved`. The body is a flow config of `slug`, `defaultLocale`, `steps`, `thankYou` and `flags` only — every block the hub acts on outside the spoke's own pages (emails, deliverables, pricing, registers, listings) is `400 field_not_seedable`; a slug a listing owns, a stored config the Admin extended with one of those blocks, or a standard magnet's slug (`onboarding`, #8515 D15, and `contact`, #8661 D4 — `RESERVED_FLOW_SLUGS`, before any read) is `409 slug_owned`, so a seed never deletes them or replaces the owner's onboarding questions or Contact form. `upsertFlowDefinition` itself refuses the reserved slugs the same way, so no preset, approved listing or waitlist register writes one either, and a new listing's derived slug skips them (`contact-2`). A config equal to the stored one (keys sorted) answers `unchanged` and writes nothing; otherwise `created` or `updated` through `upsertFlowDefinition`, so `kind`, `title` and `status` are written on create only. Route-level `bodyLimit` 256 KiB; the config is never echoed or logged. Module: `signal-collectors`.
 - `/v1/flows/:slug/aggregate` (GET) — anonymous, site-scoped per-question response counts across all completed respondents for the results reveal (#4771): respondents are completed `FlowSession` rows (not `Lead` rows — a recommending-mode respondent has no Lead until the email moment), question metadata + the chart flag come from the `WaitlistExperiment` register, and only `resultsReveal`-flagged `single`/`multi` questions are returned (`src/services/flow-aggregate.ts`). No individual answer, email, name, session id, or score in the response; no auth. Module: `signal-collectors`. No MCP twin — recorded exception (an agent walking a flow already gets everything it needs from `submit_flow_step`'s own response; "how everyone else answered" changes none of it).
 - `/v1/deliverables/:grantId` (GET) — the capability-token download route for gated PDFs and reports, including client deliverables (#3961 D5); the token itself is the sole gate, no auth preHandler applies (`src/routes/deliverables/index.ts`). Module: `signal-collectors` (D-48, #5366). No MCP twin — identity-bound capability-link download (#3591 exception, the same shape as `/v1/waitlist-signups/me`). **Three grant classes since #6310**, keyed on `grant.assetId`'s ADR-0031 prefix: `playbook:` (unchanged, the FEAT-074 U4b virtual asset); `asset_` — a workspace `Asset`, resolved through the named boundary `src/lib/deliverable-asset-store.ts`, scoped by `grant.workspaceId` (a serve-time tenancy re-check restored for this class — D15) — served `attachment` with an extension pinned to the stored content type, `nosniff`, a non-raster `Content-Security-Policy` (for EVERY content type, including raster — never `inline`), and `Cache-Control: private, no-store` so a deleted asset stops downloading immediately; `dasset_` — the LEGACY `DeliverableAsset` store (unchanged, tried only when a magnet's `assetKey` does not resolve against `Asset`). A client's file — tagged `private`, attached to a member-area message, or (#8171 D3) named by a delivered piece version — is never minted or served as a deliverable. Every miss on the `asset_` class — a NULL `workspaceId`, no row, a foreign-workspace row — folds into the SAME uniform 404 as every other class; there is deliberately no redirect to the public `GET /v1/assets/:assetId` (that route's year-long `immutable` cache would defeat deletion as a revocation lever, and would collapse every lead's capability onto one workspace-canonical id — spec #6310 §9 SEC-001/SEC-002).
 - `/v1/flows/:slug/save` (POST), `/v1/flows/:slug/checkout` (POST) — the recommender's email moment (#4841): `save` creates the FlowSession + Lead (+ the T+0 DeliverableGrant) for the permalink's answers; `checkout` does the same, records the `FlowCheckout` buyer row at a SERVER-recomputed `price()` (the body carries no amount — `flowCheckoutInputSchema` is strict), and opens a Stripe TEST-mode Checkout Session whose metadata carries the permalink + offer key (`src/routes/flows/recommender.ts`, `src/services/recommender-capture.ts`, `packages/stripe-client`'s `createQuotedCheckoutSession`). Anonymous, rate-limited; a non-`sk_test_` key is refused before any side effect. No MCP twin — recorded exception: an agent walking a flow has no email to give and no card to pay with; the anonymous MCP surface is identity-blind.
-- `/v1/workspaces/:workspaceId/magnets` (GET, POST), `/v1/workspaces/:workspaceId/magnets/:id` (GET, PATCH), `/v1/workspaces/:workspaceId/magnets/:id/signups` (GET), `/v1/workspaces/:workspaceId/magnets/:id/subscribers` (GET), `/v1/workspaces/:workspaceId/magnets/:id/messages` (GET) — the tenant-scoped magnet Admin authoring surface over the flow engine's `FlowDefinition` rows (#6157 S5c, `src/routes/magnets/index.ts`): list (cursor-paginated, fixed 50-row page), create, get, update, and the three per-magnet captured-lead reads (#6246 S6h). Reads and writes only through `tenantDb(tenant).flows` — never `prisma.flowDefinition`, `currentSiteId()`, or `upsertFlowDefinition` (the PUBLIC/seed path below, which the admin path never calls). No DELETE — the reversible alternative is `status: "draft"` (#6156), which stops a NEW walk from starting while an in-flight walk finishes on its pinned snapshot. `slug` lives only inside `config.slug` and is immutable through this surface after create (`400 slug_immutable` on a mismatched PATCH). The two operator-writable config URLs (`abandonEmail.resumeUrl`, `followUps[].cta.href`) pass an exact-origin gate against `FRONTEND_URL` before any write, the same discipline the recommender's checkout redirect already applies (#4912). Role floors from `@working-theory/validation`'s permission table (#7636 D2) (D5): list and get serve the full row to `magnets-manage` (owner, admin) and, to a caller holding only `magnets-read` (a member), a LIVE-only summary of exactly `{ id, slug, kind, title, landingPage }` — a member's list is read to completion (at most 20 pages of 50, a `warn` at the cap) and answers `nextCursor: null`, a member's `?cursor=` is a 400, and a draft's get is the same 404 as an absent id — because a magnet's `config` carries `scoring` thresholds, `offers`/`rateTable` and `deliverables` asset keys and no draft is a member's; POST and PATCH need `magnets-manage`; the per-magnet captured-people lists need `inbox-read` (every role), and for a caller without `magnets-manage` a magnet that is not live is the same 404. Both writes declare a route-level `bodyLimit` (256 KiB) and each records one `recordAgentAction` audit row. **`customersEnabled` (#8171 D6)** — the member-area customer switch — is served on every full row and written by the PATCH (a PATCH of it alone skips the plan check); the member summary row never carries it. **The standard onboarding magnet (#8515 D2–D4):** every workspace holds one `diagnostic` magnet at slug `onboarding` (`ONBOARDING_FLOW_SLUG`, `onboardingFlowConfig` in `@working-theory/validation`), `draft` and `customersEnabled: true`, written only by `lib/tenant-db.ts`'s insert-only seed (`createMany` with `skipDuplicates`, so a re-seed creates nothing and never overwrites the owner's edits or an owner's own magnet at that slug): `POST /v1/workspaces` seeds the workspace it just created, after its transaction commits (a failed seed is one `error` line and still a `201`), and the seed-presets CLI (`node dist/bin/seed-presets.js`, run once after deploy) seeds every existing workspace and prints counts only. Its two bare-id exports have one production caller each, pinned by `tests/architecture/onboarding-seed-callers.test.ts`. Module: `multi-tenant || signal-collectors`, the same gate the review-surface dashboard (`/v1/waitlist-experiments/*`, `/v1/project-listings/*`) already registers under. No MCP twin on any of the seven — identity-bound tenant routes (#3591 exception, same shape as the sibling `/v1/workspaces/*` routes); the public `/v1/flows/*` routes and their two MCP tools are unchanged, pinned by `src/routes/flows/__tests__/parity.test.ts`. **The three new list routes (#6246 S6h)** join every magnet through `Lead.source = 'flow:' + <the resolved magnet's slug>` — the literal string `flow-engine.ts`'s `completeSubmission` stamps on every flow-engine `Lead` row regardless of kind, including `newsletter`/`waitlist` (`Subscriber` is written only by the separate, pre-flow-engine `subscribe_newsletter` path, unrelated to a magnet) — via ONE new `tenantDb(tenant).leads.listBySource(source, { limit })` accessor, an exact-source-equality sibling of #6204's allowlist-scoped `listUnhandledMessages`, served by a new `(workspaceId, source)` composite index on `Lead`. `/signups` expects `kind: "waitlist"`, `/subscribers` expects `"newsletter"`, `/messages` expects `"contact"`; a magnet id absent from the caller's workspace OR resolved to the WRONG kind for the called route is `404 not_found`, indistinguishably (mirrors the existing GET's absent-or-foreign fold). `/signups` and `/subscribers` serve four keys (`id`, `name`, `email`, `createdAt`); `/messages` serves those four plus `handledAt`. Bounded `?limit=` (default 50, max 200), newest-first — mirrors `workspaces/messages.ts`'s own query schema. Applications (Listicle) is deliberately OUT of this surface — `ProjectListing` carries no reverse link to the listicle-kind `FlowDefinition` that captured it, so "scoped to that magnet" cannot be honored without a schema change (split to #6314).
+- `/v1/workspaces/:workspaceId/magnets` (GET, POST), `/v1/workspaces/:workspaceId/magnets/:id` (GET, PATCH), `/v1/workspaces/:workspaceId/magnets/:id/signups` (GET), `/v1/workspaces/:workspaceId/magnets/:id/subscribers` (GET), `/v1/workspaces/:workspaceId/magnets/:id/messages` (GET) — the tenant-scoped magnet Admin authoring surface over the flow engine's `FlowDefinition` rows (#6157 S5c, `src/routes/magnets/index.ts`): list (cursor-paginated, fixed 50-row page), create, get, update, and the three per-magnet captured-lead reads (#6246 S6h). Reads and writes only through `tenantDb(tenant).flows` — never `prisma.flowDefinition`, `currentSiteId()`, or `upsertFlowDefinition` (the PUBLIC/seed path below, which the admin path never calls). No DELETE — the reversible alternative is `status: "draft"` (#6156), which stops a NEW walk from starting while an in-flight walk finishes on its pinned snapshot. `slug` lives only inside `config.slug`. **A PATCH whose `config.slug` differs renames the magnet (#8641 D8):** `tenantDb(tenant).flows.rename` moves the row, this workspace's `Lead.source = 'flow:<slug>'` rows and its `FlowSession.flowSlug` rows to the new slug in one transaction, so its submissions follow it; `FlowCheckout` rows and lead payload copies are never rewritten. Refused before any write: `409 slug_fixed` (the stored slug is `onboarding`, `request-quote`, `contact` (#8661 D5) or `job-application` (#8746 D3), which the server reads by name, or the row belongs to a listing) and `409 slug_reserved` (the new slug is one of those four); inside the transaction, `409 slug_bound` (a checkout or a waitlist register of this workspace names either slug, or a lead or session of this workspace already sits at the new one) and `409 conflict` (another magnet holds it). A rename records a `magnet.rename` audit row whose summary is `{ from, to, leads, sessions }`. The two operator-writable config URLs (`abandonEmail.resumeUrl`, `followUps[].cta.href`) pass an exact-origin gate against `FRONTEND_URL` before any write, the same discipline the recommender's checkout redirect already applies (#4912). Role floors from `@working-theory/validation`'s permission table (#7636 D2) (D5): list and get serve the full row to `magnets-manage` (owner, admin) and, to a caller holding only `magnets-read` (a member), a LIVE-only summary of exactly `{ id, slug, kind, title, landingPage }` — a member's list is read to completion (at most 20 pages of 50, a `warn` at the cap) and answers `nextCursor: null`, a member's `?cursor=` is a 400, and a draft's get is the same 404 as an absent id — because a magnet's `config` carries `scoring` thresholds, `offers`/`rateTable` and `deliverables` asset keys and no draft is a member's; POST and PATCH need `magnets-manage`; the per-magnet captured-people lists need `inbox-read` (every role), and for a caller without `magnets-manage` a magnet that is not live is the same 404. Both writes declare a route-level `bodyLimit` (256 KiB) and each records one `recordAgentAction` audit row. **`customersEnabled` (#8171 D6)** — the member-area customer switch — is served on every full row and written by the PATCH (a PATCH of it alone skips the plan check); the member summary row never carries it. **The completion setting (#8757 D1–D4):** every magnet carries `completion` (`lead` | `invite` | `checkout`, column default `lead`) and `checkoutOffering` (set exactly when `checkout`), two `FlowDefinition` columns closed by three CHECKs and read and written only through `lib/flow-completion-store.ts` (`tenant-db.ts` stays closed under the #8746 contract; `architecture.yaml` lists the store under `paths_scoped`). The migration backfilled `onboarding`, `request-quote` and `job-application` to `invite` by slug (`STANDARD_MAGNET_COMPLETIONS`); a magnet created later is `lead` until #8759. Every full row serves the pair; the member summary never does. The PATCH writes it ALONE — `{ completion, checkoutOffering }` beside any other key is `400 completion_alone`, an offering without a completion or a pair `flowCompletionSettingSchema` refuses `400 validation_failed` — with no plan check, and records `magnet.update` with summary `{ completion }`. `checkout` also needs a person (`403 completion_needs_person` for an agent key), the `commerce` claim (`409 commerce_required`, `503 license-undetermined`) and a key `services/plan-offerings.ts`'s `listPlanOfferings` lists right now (`409 offering_unknown`; a failed read `503 offerings_unavailable`). **The standard onboarding magnet (#8515 D2–D4):** every workspace holds one `diagnostic` magnet at slug `onboarding` (`ONBOARDING_FLOW_SLUG`, `onboardingFlowConfig` in `@working-theory/validation`), `draft` and `customersEnabled: true`, written only by `lib/tenant-db.ts`'s insert-only seed (`createMany` with `skipDuplicates`, so a re-seed creates nothing and never overwrites the owner's edits or an owner's own magnet at that slug): `POST /v1/workspaces` seeds the workspace it just created, after its transaction commits (a failed seed is one `error` line and still a `201`), and the seed-presets CLI (`node dist/bin/seed-presets.js`, run once after deploy) seeds every existing workspace and prints counts only. Its two bare-id exports have one production caller each, pinned by `tests/architecture/onboarding-seed-callers.test.ts`. **The standard Contact form magnet (#8661 D1–D3):** every workspace also holds one `contact` magnet at slug `contact` (`CONTACT_FORM_FLOW_SLUG`, `contactFormFlowConfig`), titled "Contact form", `live`, `customersEnabled: false`, landing page `/contact` — Name, Email, a five-option Subject, Message and a required terms checkbox. It is written by the same insert-only seed, from the same two callers (a failed seed is one `contact-form-seed` `error` line and still a `201`), and by `database/seed.ts` for the default workspace; a re-seed never duplicates it or overwrites an edit. The web /contact page reads it on every request through `GET /v1/flows/contact`, and a submission that used it is stamped `flow:contact`, an Inbox submission under "Contact form". **The standard Job application magnet (#8746 D3, D4):** every workspace also holds one `diagnostic` magnet at slug `job-application` (`JOB_APPLICATION_FLOW_SLUG`, `jobApplicationFlowConfig`), titled "Job application", `live`, `customersEnabled: false`, landing page `/careers` — First name, Last name and Email (required), Phone and LinkedIn URL — with no `completion` field. It is written by the same insert-only seed, from the same two callers (a failed seed is one `job-application-seed` `error` line and still a `201`), and by `database/seed.ts` for the default workspace; `RESERVED_FLOW_SLUGS` carries its slug, so no flow-engine write, spoke seed or new listing takes it. Each web job page `/careers/<slug>` reads it through `GET /v1/flows/job-application` and draws its field step under `#apply`, and a submission is stamped `flow:job-application`, an Inbox submission under "Job application" whose `name` is first + last and whose `job` is the posting's slug. Module: `multi-tenant || signal-collectors`, the same gate the review-surface dashboard (`/v1/waitlist-experiments/*`, `/v1/project-listings/*`) already registers under. No MCP twin on any of the seven — identity-bound tenant routes (#3591 exception, same shape as the sibling `/v1/workspaces/*` routes); the public `/v1/flows/*` routes and their two MCP tools are unchanged, pinned by `src/routes/flows/__tests__/parity.test.ts`. **The three new list routes (#6246 S6h)** join every magnet through `Lead.source = 'flow:' + <the resolved magnet's slug>` — the literal string `flow-engine.ts`'s `completeSubmission` stamps on every flow-engine `Lead` row regardless of kind, including `newsletter`/`waitlist` (`Subscriber` is written only by the separate, pre-flow-engine `subscribe_newsletter` path, unrelated to a magnet) — via ONE new `tenantDb(tenant).leads.listBySource(source, { limit })` accessor, an exact-source-equality sibling of #6204's allowlist-scoped `listUnhandledMessages`, served by a new `(workspaceId, source)` composite index on `Lead`. `/signups` expects `kind: "waitlist"`, `/subscribers` expects `"newsletter"`, `/messages` expects `"contact"`; a magnet id absent from the caller's workspace OR resolved to the WRONG kind for the called route is `404 not_found`, indistinguishably (mirrors the existing GET's absent-or-foreign fold). `/signups` and `/subscribers` serve four keys (`id`, `name`, `email`, `createdAt`); `/messages` serves those four plus `handledAt`. Bounded `?limit=` (default 50, max 200), newest-first — mirrors `workspaces/messages.ts`'s own query schema. Applications (Listicle) is deliberately OUT of this surface — `ProjectListing` carries no reverse link to the listicle-kind `FlowDefinition` that captured it, so "scoped to that magnet" cannot be honored without a schema change (split to #6314).
 - `/v1/content/{types,:type,:type/:slug}` — public content reads
 - `/v1/auth/tokens`, `/v1/user/{profile,data/:key}` — local auth + user data
-- `/v1/hub-sign-in/codes` (POST), `/v1/hub-sign-in/token` (POST), `/v1/hub-sign-in/revoke` (POST), `/v1/hub-sign-in/me` (GET) — the hub signs in its spokes (#7894, `src/routes/auth/hub-sign-in.ts` over `src/services/hub-sign-in.ts`; spec `docs/specs/7894-the-hub-signs-in-its-spec.md`): an authorization code with PKCE between a spoke (a confidential client whose `OAuthClient.clientId` IS its `Spoke.id`) and this hub. `codes` is in `authScope` and answers a COOKIE session only (a personal `ApiToken` is 403, an agent key 403 at the preHandler, a hub credential 404): it mints a single-use 60 s code only for an email-verified person and a callback in the client's registered `redirectUris` (exact match), 30 a user per 10 minutes. `token` and `revoke` are in their OWN scope outside `authScope` (per-IP `rateLimitMiddleware`, scope `hubsignin`, 60/min; plus a per-client bucket of 120 exchanges a minute keyed on the VERIFIED client): the caller authenticates with `Authorization: Basic clientId:secret` AND `x-ailk-spoke-key`, which must resolve to the unrevoked spoke whose id is that client — either alone is `401 invalid_client`. `token` consumes the code first and exactly once, then checks the client, the callback and the PKCE verifier (`400 invalid_grant` for any failure, the code gone either way) and issues `ailk_hst_…`, a 24 h credential stored only as a SHA-256 digest in `OAuthAuthorization` (one row per person and spoke, so a new sign-in rotates it); it writes no `Session` row and sets no cookie. `revoke` ends a credential or burns an unexpired code of that client (`{ revoked }`, never an error). `me` answers the credential's person, read live, and is reachable only by that credential. **The credential is admitted by one branch of `middleware/auth.ts`** — only beside the same spoke's key, only while its grant is unrevoked and unexpired, its client enabled and its person's email verified, and only on `HUB_SESSION_ROUTES`, an exact list of 24 method + registered-URL strings, never a prefix (#8220): `GET /v1/hub-sign-in/me`, #7877's three member reads, #8169's eight member reads, #8170's six member writes, #8435's two contact routes, #8438's two consent routes and #8515's onboarding read and write; every other route answers `404` with no handler run (the status the account area's `read()` loads as "nothing for this caller"), and the list is extended only by a reviewed edit. **The per-person budget (#8220 D2, SEC-8169-4):** each person at each spoke gets 60 requests and 10 writes a minute and 30 writes an hour (a fixed hour window from the first admitted write, so up to twice that across a window edge), keyed on the VERIFIED spoke and person and charged only after admission (a refused credential or an off-list route never gets a bucket); over budget is `429 rate_limited` with `Retry-After`. The write limits refuse only writes, and a refused request is not counted. Every line the request logger writes for an admitted request after admission carries `spokeId` (never the key or the credential); a helper logging through the module-level `logger` carries no request binding. The server-wide per-IP limiter still counts all of one spoke's members together — a named residual whose follow-up (the visitor forward key on member calls) must land before Phase 3 (#8163) ships to a live spoke. A bearer write skips the origin check, so the cross-site-request protection for the member writes is the spoke's: its server actions that send a sealed credential carry it (Phase 3, #8163; SEC-8220-11). A completed password reset (`apps/web/auth.ts` `onPasswordReset`) revokes every credential of that person. The operator registers a spoke's client with `spokes sign-in-client --id <spoke_id> --redirect-uri <url>` (`bin/spokes.ts`; `--disable` switches it off) — `lib/hub-sign-in-store.ts` is the only file that names `prisma.oAuthClient` and `prisma.oAuthAuthorization`. No MCP twin for any of the four — a credential exchange between a site and its hub is not an agent-facing call (#3591 exception, the `/v1/auth/tokens` footing). The browser step lives on the hub's web app: `apps/web/app/api/auth/hub/authorize/route.ts`.
+- `/v1/hub-sign-in/codes` (POST), `/v1/hub-sign-in/token` (POST), `/v1/hub-sign-in/revoke` (POST), `/v1/hub-sign-in/me` (GET) — the hub signs in its spokes (#7894, `src/routes/auth/hub-sign-in.ts` over `src/services/hub-sign-in.ts`; spec `docs/specs/7894-the-hub-signs-in-its-spec.md`): an authorization code with PKCE between a spoke (a confidential client whose `OAuthClient.clientId` IS its `Spoke.id`) and this hub. `codes` is in `authScope` and answers a COOKIE session only (a personal `ApiToken` is 403, an agent key 403 at the preHandler, a hub credential 404): it mints a single-use 60 s code only for an email-verified person and a callback in the client's registered `redirectUris` (exact match), 30 a user per 10 minutes. `token` and `revoke` are in their OWN scope outside `authScope` (per-IP `rateLimitMiddleware`, scope `hubsignin`, 60/min; plus a per-client bucket of 120 exchanges a minute keyed on the VERIFIED client): the caller authenticates with `Authorization: Basic clientId:secret` AND `x-ailk-spoke-key`, which must resolve to the unrevoked spoke whose id is that client — either alone is `401 invalid_client`. `token` consumes the code first and exactly once, then checks the client, the callback and the PKCE verifier (`400 invalid_grant` for any failure, the code gone either way) and issues `ailk_hst_…`, a 24 h credential stored only as a SHA-256 digest in `OAuthAuthorization` (one row per person and spoke, so a new sign-in rotates it); it writes no `Session` row and sets no cookie. `revoke` ends a credential or burns an unexpired code of that client (`{ revoked }`, never an error). `me` answers the credential's person, read live, and is reachable only by that credential. **The credential is admitted by one branch of `middleware/auth.ts`** — only beside the same spoke's key, only while its grant is unrevoked and unexpired, its client enabled and its person's email verified, and only on `HUB_SESSION_ROUTES`, an exact list of 26 method + registered-URL strings, never a prefix (#8220): `GET /v1/hub-sign-in/me`, #7877's three member reads, #8169's eight member reads, #8170's six member writes, #8435's two contact routes, #8438's two consent routes, #8765's account-agreements pair and #8515's onboarding read and write; every other route answers `404` with no handler run (the status the account area's `read()` loads as "nothing for this caller"), and the list is extended only by a reviewed edit. **The per-person budget (#8220 D2, SEC-8169-4):** each person at each spoke gets 60 requests and 10 writes a minute and 30 writes an hour (a fixed hour window from the first admitted write, so up to twice that across a window edge), keyed on the VERIFIED spoke and person and charged only after admission (a refused credential or an off-list route never gets a bucket); over budget is `429 rate_limited` with `Retry-After`. The write limits refuse only writes, and a refused request is not counted. Every line the request logger writes for an admitted request after admission carries `spokeId` (never the key or the credential); a helper logging through the module-level `logger` carries no request binding. The server-wide per-IP limiter still counts all of one spoke's members together — a named residual whose follow-up (the visitor forward key on member calls) must land before Phase 3 (#8163) ships to a live spoke. A bearer write skips the origin check, so the cross-site-request protection for the member writes is the spoke's: its server actions that send a sealed credential carry it (Phase 3, #8163; SEC-8220-11). A completed password reset (`apps/web/auth.ts` `onPasswordReset`) revokes every credential of that person. The operator registers a spoke's client with `spokes sign-in-client --id <spoke_id> --redirect-uri <url>` (`bin/spokes.ts`; `--disable` switches it off) — `lib/hub-sign-in-store.ts` is the only file that names `prisma.oAuthClient` and `prisma.oAuthAuthorization`. No MCP twin for any of the four — a credential exchange between a site and its hub is not an agent-facing call (#3591 exception, the `/v1/auth/tokens` footing). The browser step lives on the hub's web app: `apps/web/app/api/auth/hub/authorize/route.ts`.
 - `/v1/checkout/sessions` — start a Stripe checkout
 - `/v1/workspaces/:workspaceId/{theme,identity,seo}` (GET/PUT) — per-workspace site config (multi-tenant module). PUT needs `workspace-settings` (owner, admin — `@working-theory/validation`'s permission table (#7636 D2)), checked before the body parse; GET stays open to every member.
 - `/v1/workspaces/:workspaceId/meetings` (GET/PUT) — the operator's enabled-slug gate for meeting types (#6183 S9b, `src/routes/workspaces/meetings.ts`). Beside the three siblings above in URL shape and tenant-isolation posture, but registered in its OWN scope, gated on `isModuleEnabled("scheduling")` ALONE — not the `workspace`/`multi-tenant` scope its siblings share, because its GET reaches `services/scheduling/` (see below), which a scaffold without that module does not carry (`tools/lint-slice-registration.ts`, #5701). PUT needs `meeting-types-manage` (owner, admin — `@working-theory/validation`'s permission table (#7636 D2)) because this blob decides which pages the public site serves. GET answers `meeting-types-manage` with the full join and `meeting-types-read` (every role, a member included) with the ENABLED rows only (#7636 D6) — since it does NOT just return the stored blob, it echoes the deployment's whole provider catalog, including the rows the operator chose not to publish (security review, 2026-09-19), which a member never sees. GET is the one segment in this file's family that does NOT just return the stored blob: it ALSO lists the scheduling provider's own bookable event types (`listEventTypes`, #6182), joined with `enabled: boolean`; an unconfigured/unreachable provider answers the same `SchedulingErrorKind` outcome `/v1/schedule/*` uses, distinct from an empty list. **`customerSlugs` (#8171 D5)** — who may book from the member area, independent of `enabledSlugs`: `GET ?include=customers` (exactly that value) adds `customer: boolean` per row, and without it the body is unchanged; the PUT carries `customerSlugs`, and a PUT without it keeps the stored list (a read then a write, last-writer-wins), so the public toggle never erases it. `enabledSlugs` keeps its whole-list meaning, so a writer of `customerSlugs` sends the `enabledSlugs` it read. An agent's PUT is audited `meetings.set_customers` when it carries `customerSlugs`, else `meetings.set_enabled`. No MCP twin — identity-bound tenant route (#3591 exception).
@@ -65,7 +65,7 @@ Routes are versioned under `/v1/*`:
 - `/v1/member/pieces` (GET), `/v1/member/messages` (GET), `/v1/member/messages/:id/file` (GET) — the member reads: a client's OWN pieces and messages, served to the spoke that signed them in (#7877, `src/routes/member/{pieces,messages}.ts`). Registered in `authScope` only (auth, NOT tenant-guarded — a client holds no membership; an agent key is 403 at the preHandler) under the same `workspace || multi-tenant` predicate, at the exact URLs `HUB_SESSION_ROUTES` admits a hub credential on. Who and where come only from `services/member-area.ts`'s `resolveMember`, before any member read: the caller through `middleware/auth.ts`'s `memberCaller` — the hub's own cookie session or a hub credential, never a personal `ApiToken` (`401 { error: "unauthorized" }`); the workspace from the calling spoke's `x-ailk-spoke-key` (a keyless call only on a one-workspace deployment that is not a hub), and a hub credential must name that same workspace, else `503 tenant_unresolved`; an unverified email `403 email_unverified`. The Person is the one linked by `Person.userId`, else the one whose email is the caller's verified email, linked on that first read by `stampPersonUser`'s rule; no Person is `items: []`. Every read goes through the named boundary `src/lib/member-store.ts`, scoped by that resolved workspace AND Person: at most 50 rows, newest first; a message serves `{ id, subject, body, file: { filename, contentType } | null, createdAt, readAt }` — never an asset, creator, person or workspace id — and the first read stamps `readAt` ("shown to the client's spoke", not "read"; served as it stood before the stamp). The file read streams the attachment only when the message is the caller's own and its stored type is attachable — any other case is one `404 not_found` — `attachment` with a sanitized, extension-pinned name, `nosniff`, the sandbox `Content-Security-Policy` and `Cache-Control: private, no-store`. `@working-theory/api-client`'s `member.*` is the spoke's caller; a spoke that re-serves the bytes sends those five headers unchanged. No MCP twin, by decision — identity-bound client reads behind a hub credential; the anonymous MCP surface is identity-blind, recorded in `tests/parity/README.md`.
 - `/v1/member/purchases`, `/v1/member/appointments`, `/v1/member/artifacts`, `/v1/member/artifacts/:pieceId/versions/:version/file`, `/v1/member/meeting-types`, `/v1/member/availability`, `/v1/member/request-form`, `/v1/member/billing` (all GET) — the Phase 1 member reads (#8169, `src/routes/member/{purchases,appointments,artifacts,meeting-types,availability,request-form,billing}.ts`; spec `docs/specs/8169-member-reads-spec.md`). Same caller seam, refusals and registration as the bullet above, each read through one `src/lib/member-store.ts` function, each success body re-parsed against its `@working-theory/validation` `member.ts` schema. All eight are in `HUB_SESSION_ROUTES` (#8220). Appointments, artifacts and the file read are scoped by the resolved workspace AND Person (≤ 50, never an attendee's name, email or time zone; never a version or asset id; the file read is one `404 not_found` for every miss, a version above the 32-bit column included, and sends `messages.ts`'s five headers). **Purchases and billing read at organization grain** (the operator's #8140 ruling): only Persons whose `userId` is ALREADY the caller, inside the calling workspace's organization — they link nothing, so a caller with no Person here still sees a linked Person elsewhere. That grain rests on one precondition nothing enforces (SEC-8169-2, stated at `lib/member-store.ts`'s `linkedPersonsInOrganization` and pinned by `src/__tests__/member-isolation.test.ts`): every workspace of one organization belongs to one owner, so a deployment must never put two businesses' workspaces in one organization. A purchase is a completed hub `FlowCheckout` whose lead carries its Person's own email, or (#8185) a `Lead` the hub marked `spokeCheckout` when it was written — a registered spoke's unrelayed (`x-ailk-relayed` absent), LIVE paid checkout, the #7877 plan rule's own predicate evaluated in `services/lead-routing.ts` before the create and never updated, served with the same Person-workspace and Person-email rules, its offering kept only if it is a plan-offering key (SEC-8169-6); an anonymous, relayed, test-mode or pre-#8185 lead is never marked and never served (no backfill), and `tests/architecture/idempotency-key-producers.test.ts` fails if any spoke-side file, MCP tool or client wrapper starts sending an `Idempotency-Key`. **Billing answers a hub credential only**: any other caller gets `404 not_found` before `resolveMember` and before any read, and no log line ever names a `cus_` id; a hub credential reads it at the organization grain, under that precondition. Meeting types and availability join the workspace's `customerSlugs` (independent of `enabledSlugs`) to the scheduling provider — a provider failure is its `SCHEDULING_ERROR_STATUS`, never an empty list; a slug outside `customerSlugs` is `404 meeting_type_not_offered` with no provider call — and register under `scheduling && (workspace || multi-tenant)`, because only the `scheduling` module delivers `services/scheduling/`. The request form is the `request-quote` contact row while `customersEnabled`, whatever its status, else `{ form: null }`. **`GET /v1/member/onboarding` (#8515 D7)** serves the standard onboarding magnet — the `diagnostic` row at slug `onboarding` while `customersEnabled`, whatever its status — reduced to display keys (a field's name, input type, `required`, select options and label/help/placeholder; a choice question's name, options, `multi` and `exclusiveValues`; never a `showIf`, `mapsTo`, `purposes`, field rule, `segments`, `whenHidden` or `resultsReveal`), else `{ form: null }`. `GET /v1/member/messages` items carry `action: "onboarding" | null` (#8515 D6). No MCP twin, by decision — the same reason, recorded in `tests/parity/README.md`.
 - `/v1/member/requests` (POST), `/v1/member/messages` (POST), `/v1/member/bookings` (POST), `/v1/member/artifacts/:pieceId/review` (POST), `/v1/member/profile` (PATCH), `/v1/member/profile/contact` (GET, PATCH), `/v1/member/deletion-request` (POST) — the Phase 1 member writes (#8170, the contact pair #8435, `src/routes/member/{requests,messages,bookings,artifact-review,profile,deletion-request}.ts`; spec `docs/specs/8170-member-writes-spec.md`). Same caller seam and refusals as the reads, and a cookie write must carry a trusted `Origin` (the preHandler's 401). Nothing in a body, path or query names a person, user or workspace; every body parses its `@working-theory/validation` `member.ts` schema (`400 invalid_input`, or `400 link_not_https` when a link is why) and every success body is re-parsed before it is sent. **Requests, messages and reviews are each ONE inbound `Interaction` on the caller's own Person** — channel `member`, direction `inbound`, `createdBy` the caller — and never a `Lead`: a request is checked against the `request-quote` magnet's CURRENT field steps (`400 answers_invalid` for a key the form does not ask, a missing required answer, an array answer or a failed field rule; `409 request_form_off` when the form is off or the caller has no Person) and stores `{ flowSlug, items }` with each label as the form shows it; a message stores `{ link }` when one is sent (`404 not_found` with no Person). **The cap:** every inbound write runs in one transaction whose first statement is the Person's advisory lock (`ailk:member-inbound:<personId>`), then counts the Person's inbound rows of the last hour — 30 or more is `429 too_many_requests` with nothing written. **The review** lands only on the piece's LATEST version (`409 version_not_latest`), only once per version and never after `Piece.approvedAt` is set (`409 review_closed`); a missing, foreign or approved piece is refused from one read before any lock, otherwise the Person lock then the workspace's piece lock (`lib/tenant-db.ts`'s `pieceStagesLockKey`, the key the operator's piece writes take), and it writes the version's `review`, `reviewComment`, `reviewedAt`, the piece's `approvedAt` on an approval and the `review` Interaction in that one transaction — never a title, stage, link, asset or note; asking for changes stays open on every new latest version (#8140 disposition 3). **The booking** books an offered `customerSlugs` meeting type at `<handle>/<slug>` as the caller (verified email, own name), refuses a Person holding 10 upcoming non-cancelled appointments `429` before any provider call, answers a provider failure through `SCHEDULING_ERROR_STATUS`, and binds a spoke caller's booking to its workspace as `/v1/schedule/book` does; it registers under `scheduling && (workspace || multi-tenant)`. **The profile** writes only the caller's own `User.name` / `User.image` (https only) and answers `{ name, image }`. **The contact** (`profile/contact`, #8435) is the caller's contact details on THIS site, never on the hub `User` and never synced to another site: the GET serves the contact of the caller's linked Person only once a human saved it (`contactConfirmedAt` set — a value only an anonymous capture wrote is `{ contact: null }`, SEC-8435-B); the PATCH takes all six keys, each nullable and required, and REPLACES the whole contact (so no value the client never saw survives), stamping `contactConfirmedBy: "client"`. With no Person yet it finds or creates the Person for the caller's VERIFIED email and links it through `stampPersonUser`'s rule; any outcome but linked is `409 contact_unavailable`, nothing written. Only the caller's own linked Person (`{ id, workspaceId, userId }`) is ever written; `400 invalid_input` or `400 telephone_invalid` for a refused body, an 8 KiB body bound, and `{ event: "member-contact", outcome }` as its one log line. **The deletion request** is filed through `routeLead` as a `web` message lead (kind `deletion`, the caller's verified email, no idempotency key) into `resolveSiteWorkspaceId()` — the deployment's own site workspace, so a spoke caller's request reaches the hub operator (`sentTo: "hub-operator"`), never the spoke's. Every data write goes through `src/lib/member-store.ts`; every write logs only `{ event, outcome }` and a `ref` of at most 8 characters (`services/member-area.ts`'s `memberWriteLog`), never a subject, body, answer, link, note, name, email or full id. All six (and the two contact routes) are in `HUB_SESSION_ROUTES` (#8220): a spoke's deletion request reaches the hub operator, and a spoke's profile write changes the name and photo the hub's `me` answers. **The onboarding submission (#8515 D8–D10):** `POST /v1/member/onboarding` takes the request body's `{ answers }` (`plainText`, ≤ 64), checks them against the served onboarding form (every key a served field or question; a required field non-blank; `email`, https `url`, `select` options and `minLength` as the request checker applies them; a single choice one option value; a `multi` choice 1…options distinct option values, an exclusive value only alone — `400 answers_invalid` / `link_not_https`; `409 onboarding_off` with no Person or no form) and writes ONE `flow:onboarding` `Lead` — never an `Interaction` — on the caller's own Person with the Person's email, the answers, `flowSlug`, `locale` and the server-written `submittedBy` (the caller's user id, a server-owned key the Inbox never shows as an answer), so it is an Inbox submission and a `lead` Activity entry with no reader change. Under the Person's inbound lock, at most five of the caller's OWN submissions an hour (`429 too_many_requests`) — only leads carrying the caller's `submittedBy` count, so an anonymous `POST /v1/leads/submit` with that source and the client's email never fills the allowance. Both onboarding routes are in `HUB_SESSION_ROUTES`. **A proposal (#8516):** the artifacts read and the review answer carry `kind`, `price` and `payment` (`{ status: "due" }` for an approved, priced, unpaid proposal where payment runs; `{ status: "paid", paidAt }` once paid; else `null`), and a proposal's review — the same write, which is how a proposal is accepted or sent back — also writes one `people.proposal.client_review` audit row as the client (`recordWorkspaceAuditAction`). **`POST /v1/member/artifacts/:pieceId/payment`** opens the client's Stripe Checkout page for their own approved, priced, unpaid proposal and answers `{ url }` — a `checkout.stripe.com` URL only (`isStripeCheckoutUrl`, checked before anything is stored), `Cache-Control: private, no-store`. It sits behind the commerce claim (`requireCommerceClaim`, the module-disabled 404 before any read) and its own strict per-IP limiter (`proposalpay`); it is NOT on `HUB_SESSION_ROUTES`. **Same site, sandbox only:** `services/proposal-payments.ts`'s `proposalPaymentsFor` is `on-approval` only with the claim, on a one-workspace deployment whose workspace is the proposal's (the deployment's one Stripe account is provably that seller's), with a key `assertSandboxKey` admits and `FRONTEND_URL` set — and never for a call carrying a spoke key or a hub credential; anywhere else approval records acceptance only and the pay route is `404 not_found`. The session is card only, expires in an hour, carries a fixed product name and the stored amount (never a request value), and is reused while it has more than five minutes left; a concurrent second session is expired. `409 proposal_not_approved` / `409 proposal_paid` / `502 payment_unavailable`; each opened session writes one `people.proposal.checkout` audit row. No MCP twin, by decision — identity-bound client writes, recorded in `tests/parity/README.md`.
-- `/v1/consent/cookie` (POST), `/v1/consent/unsubscribe` (POST), `/v1/consent/platform` (GET, POST), `/v1/member/consents` (GET, POST), `/v1/workspaces/:workspaceId/people/:personId/consents` (GET) — the consent ledger's routes (#8438, spec `docs/specs/8438-consent-registry-and-ledger-step-spec.md`). `consent_grants` is THE ledger: append-only (the database refuses any change to a stored row, and any truncation, on it and on `consent_visitor_links`), every row naming its `source`, its `policyVersion` and, when known, its Person; every writer is `src/services/consent.ts` (`recordConsent`, `recordPersonConsent`, `recordCookieChoice`, `linkConsentVisitor`) and every reader is `src/lib/consent-store.ts` (`DISTINCT ON` current-state reads, never a window). **Two readings of a Person's rows:** the OWN reading (`sign_up`, `account_settings`, `email_unsubscribe` — a verified caller or a signed link) is what the member's screens and any send read; the ANY-SOURCE reading (adds `magnet`, `api`, `cookie_banner`, and linked visitors' cookie rows) is the operator's, marked `unverified` — an anonymous form's row never changes a member's own answer. A write appends only when the answer changes the reading it is checked against, under an advisory lock on the (subject, purpose) pair. `POST /v1/consent/cookie` takes `{ visitorId, choice, locale }` and never a workspace (it comes from `resolvePublicWorkspace`); `POST /v1/consent/unsubscribe` takes a token signed with `AILK_CONSENT_LINK_SECRET` (≥ 32 bytes, optional; unset ⇒ `503 link_secret_not_configured`) and answers every defect as one `400 invalid_link`. Both are top-level, outside every module gate, in their own rate-limit scopes (`consent`, `unsubscribe`) and on `FORWARDED_VISITOR_ROUTES`. The member pair is in `HUB_SESSION_ROUTES` (24 entries since #8515); `/v1/consent/platform` is NOT — it is the deployment owner's own consent to Working Theory, a cookie session holding `platform-consents`, under `multi-tenant`. The banner's visitor id travels in `x-ailk-consent-visitor` (only a v4 UUID counts) on the lead and flow routes and the member write, linking the visitor to the Person; the header is never echoed or logged. A `consent` flow field now stores `{ [purposeId]: boolean }` and writes the ledger at completion (source `magnet`, `sourceRef` the flow slug). The operator's `…/consents` answers `{ own, anySource, history, nextCursor }` (history 500 a page, `Cache-Control: private, no-store`, never a subject id). No MCP twin for any of them, recorded in `tests/parity/README.md`.
+- `/v1/consent/cookie` (POST), `/v1/consent/unsubscribe` (POST), `/v1/consent/sign-up` (GET), `/v1/consent/account` (GET, POST), `/v1/consent/platform` (GET, POST), `/v1/member/consents` (GET, POST), `/v1/workspaces/:workspaceId/people/:personId/consents` (GET) — the consent ledger's routes (#8438, spec `docs/specs/8438-consent-registry-and-ledger-step-spec.md`; #8765, spec `docs/specs/8765-sign-up-refuses-without-the-spec.md`). `consent_grants` is THE ledger: append-only (the database refuses any change to a stored row, and any truncation, on it and on `consent_visitor_links`), every row naming its `source`, its `policyVersion` and, when known, its Person; it has two writers — `src/services/consent.ts` (`recordConsent`, `recordPersonConsent`, `recordCookieChoice`, `linkConsentVisitor`, `recordCheckoutConsent`; every source) and the web's sign-up hook `apps/web/lib/sign-up-agreements.ts` (#8765 D4), which writes only `sign_up` rows (subject `user`) of a user it creates in the same Better Auth transaction, from the evidence `GET /v1/consent/sign-up` built with `consent.ts`'s own functions — and every reader is `src/lib/consent-store.ts` (`DISTINCT ON` current-state reads, never a window). **Two readings of a Person's rows:** the OWN reading (`sign_up`, `account_settings`, `email_unsubscribe` — a verified caller or a signed link) is what the member's screens and any send read; the ANY-SOURCE reading (adds `magnet`, `api`, `cookie_banner`, `checkout`, and linked visitors' cookie rows) is the operator's, marked `unverified` — an anonymous form's row never changes a member's own answer. **The checkout grant (#8765 D13, D14):** `checkout` is the eighth source (the `consent_grants_source_known` CHECK names all eight). The hub webhook's `checkout.session.completed` arm, after the flow-checkout Person step, writes one `account_terms` row (subject `person`, source `checkout`, `sourceRef` the Checkout Session id, locale `en`, the current statement and version) through `recordCheckoutConsent` — one transaction under the `ailk:consent:<workspaceId>:checkout:<sessionId>` lock, nothing written when that Person already holds that session's row — only when `consent.terms_of_service` is `accepted` and `metadata.ailk_terms` is `account_terms@<current version>`; the Person is `services/checkout-buyer.ts`'s `checkoutBuyerPerson` (a proposal session → the piece's Person in its `ailk_workspace` through `lib/proposal-paid-store.ts`'s `proposalPersonId`; a flow checkout → the Person the Person step's `resolveCheckoutPerson` found or created, never created here; a signed-in buyer's `ailk_user_id` → the Person of that user's verified email in the site workspace, test mode included; else, for a paid live-mode session only, `customer_details.email`'s Person). **A spoke purchase records the same grant (#8778):** a spoke's checkout runs on the spoke's own Stripe account, so the hub webhook never sees it; instead the first write of a `spokeCheckout` lead with a Person (`services/lead-routing.ts`) whose `payload.termsAccepted` equals the current `account_terms@<version>` stamp (`currentAccountTermsStamp`) calls `recordCheckoutConsent` for the lead's Person, `sourceRef` the lead's `Idempotency-Key` (the Checkout Session id) — a `null` or absent value writes nothing (`consent_absent`), any other value nothing (`terms_unstamped`), a replay never reaches it (and `termsAccepted` is left out of the replay comparison, so a redelivery across a spoke's update still replays), and the store's per-session guard keeps it to one row; it logs `{ event: "checkout-consent", outcome, siteId }` only and never changes the lead's answer. A `checkout` row is unverified: the payer is not a signed-in user, so it never satisfies the account interstitial. It logs `{ event: "checkout-consent", outcome, eventIdPrefix }` only (`consent_absent`, `terms_unstamped`, `person_unresolved`, `recorded`, `unchanged`, `version_changed` — the site registry has moved past the stamped version, so nothing is written — and `failed`, which adds the error's `errName`) and never changes the 200. A write appends only when the answer changes the reading it is checked against, under an advisory lock on the (subject, purpose) pair. `POST /v1/consent/cookie` takes `{ visitorId, choice, locale }` and never a workspace (it comes from `resolvePublicWorkspace`); `POST /v1/consent/unsubscribe` takes a token signed with `AILK_CONSENT_LINK_SECRET` (≥ 32 bytes, optional; unset ⇒ `503 link_secret_not_configured`) and answers every defect as one `400 invalid_link`. Both are top-level, outside every module gate, in their own rate-limit scopes (`consent`, `unsubscribe`) and on `FORWARDED_VISITOR_ROUTES`. **A sign-up agreement is the account's (#8765 C3, D5, D6):** a `signUp` purpose (`account_terms`) is recorded once per `User`, subject `user` / the user id in the deployment's own site workspace (`resolveSiteWorkspaceId()`, the owner platform consents' footing, read by `userPlatformRows`), never per Person, so the hub and every spoke signed in through it read one row. `GET /v1/consent/sign-up` is anonymous and keyless: `{ workspaceId, agreements: [{ purposeId, policyVersion, locale, statement, statementHash }] }` for the site workspace (`locale` default `en`, `null` workspace `503 tenant_unresolved`, `Cache-Control: no-store`), top level beside the cookie route in its own rate-limit scope `signupevidence` (`DEFAULT_PER_IP_PER_MINUTE_STRICT`), outside every module gate. `GET /v1/consent/account` answers `{ agreements: [{ id, statement, policyVersion, acceptedVersion, acceptedAt, current }], complete }` for the caller (`memberCaller` — a cookie session or a hub credential; a personal token `401`); `POST` takes `{ purposeIds, locale? }`, refuses any id that is not a `signUp` agreement `404 purpose_unknown` before writing anything, writes each through `recordPersonConsent` (source `account_settings`, `sourceRef: spoke:<id>` for a hub credential) and answers the GET body; both register in `authScope` unconditionally and log `{ event: "account-agreements", outcome }` only. The member pair reads and writes that same row for a `signUp` purpose (no Person is created) and is unchanged for every other purpose; a `null` site workspace keeps the old per-Person reading; a hub credential's `via: "sign_up"` is `400 sign_up_window_closed` with nothing written (SEC-8765-B). The member pair and the account pair are in `HUB_SESSION_ROUTES` (26 entries since #8765); the anonymous `GET /v1/consent/sign-up` is not, and neither is `/v1/consent/platform` — it is the deployment owner's own consent to Working Theory, a cookie session holding `platform-consents`, under `multi-tenant`. The banner's visitor id travels in `x-ailk-consent-visitor` (only a v4 UUID counts) on the lead and flow routes and the member write, linking the visitor to the Person; the header is never echoed or logged. A `consent` flow field now stores `{ [purposeId]: boolean }` and writes the ledger at completion (source `magnet`, `sourceRef` the flow slug). The operator's `…/consents` answers `{ own, anySource, history, nextCursor }` (history 500 a page, `Cache-Control: private, no-store`, never a subject id). No MCP twin for any of them, recorded in `tests/parity/README.md`.
 - `/v1/workspaces/:workspaceId/requests` (GET, `?limit=`), `/v1/workspaces/:workspaceId/people/:personId/pieces/:pieceId/versions` (POST) — the provider routes (#8171, `src/routes/workspaces/{requests,pieces}.ts` over `tenantDb(tenant).memberArea`; spec `docs/specs/8171-provider-routes-the-workspace-requests-spec.md`). **The Requests read** lists the workspace's inbound member rows (#8170's messages, quote requests and reviews), newest first, `limit` 1–50 (default 50, no cursor), behind `inbox-read` (every role) checked with `can(tenant.role, …)`. It is tiered: a role holding `people-read` (owner, admin) gets the full row — the subject, body and the kind's own fields (a message's `link`, a quote's `items`, a review's `pieceId`, `version`, `review`); every other caller, every agent key included, gets `{ id, kind, person, createdAt }` and the content is never selected. A row whose payload fails its kind's schema, or whose Person is gone, is left out and counted in one `warn`. **Deliver a version** numbers version n+1 under the piece lock (`withPieceStagesLock`), behind `member-pieces-manage` through `allows` (an agent granted it delivers); the body is exactly one of an `https` link (`isHttpsLink`, else `400 link_not_https`) and a private attachable asset of this workspace (`400 asset_not_found` / `asset_not_attachable`), plus an optional note; `version`, `deliveredBy` and `deliveredAt` are the server's (a body naming one is `400 validation_failed`); a piece with `approvedAt` set is `409 piece_approved`; a malformed, absent or foreign Person or piece is `404 not_found`. There is no round count, limit or remaining count (#8140 disposition 3). It answers `201 { version: { id, pieceId, version, file, link, note, deliveredAt } }` — the file's download name, never an asset id or `deliveredBy` — and every call that reaches the store writes one `people.version.create` audit row. Same registration, scope and tenant guard as the routes above (`workspace || multi-tenant`). No MCP twin, by decision — member-area MCP tools are a later phase of the CRM nucleus, recorded in `tests/parity/README.md`.
 - `/v1/workspaces/:workspaceId/members` (GET) — the org's member roster (`userId`, `name`, `email`, `role`), the Pro `workspace` module's Team tab (#5371). Read-only by design: granting a Membership is the invite flow, which is its own spec with a mandatory security review (§2.3), so no POST/PUT/DELETE is routed at this path. Scoped to `request.tenant.organizationId` — Membership is org-level — server-resolved from the validated session. Role floor: `members-read` (owner, admin — `@working-theory/validation`'s permission table (#7636 D2)): the roster carries every member's email, and who the other members are is not a member's job. No MCP twin — identity-bound tenant route (#3591 exception).
 - `/v1/workspaces/:workspaceId/agents` (GET `?userId=`, POST), `/v1/workspaces/:workspaceId/agents/:agentId/key` (POST), `/v1/workspaces/:workspaceId/agents/:agentId` (PATCH `{ enabled }`), `PUT /v1/workspaces/:workspaceId/agents/:agentId/grants` (`{ grants }`, #7864), and `/v1/agent/context` (GET) — the agent seat (#3591, `src/routes/workspaces/agents.ts` over `src/lib/agent-store.ts`, `// oss: false`). An agent is a stored delegate of one person, bound to one workspace. The five management routes refuse an agent caller outright (403), check `agents-manage` (owner, admin) before any read, and scope every read and write to `tenant.organizationId`, never a body or query value; an agent of another organization is the same 404 as a missing one. Create returns 201 with the key shown once; re-key returns the new key once. Each successful create, re-key, switch and grant change writes an `agents.*` audit record. **Grants (#7864, `docs/specs/7864-agent-key-grants-spec.md`).** An agent acts at `member`, plus any of seven permissions an owner or admin granted it one by one — `content-edit`, `content-publish`, `assets-write`, `magnets-manage`, `meeting-types-manage`, `people-read` since #852, and `member-pieces-manage` since #7878 (`@working-theory/validation`'s `AGENT_GRANTABLE_PERMISSIONS`, held to that set by the `agents_grants_allowed` CHECK). The grant PUT replaces the whole set (an empty list removes every grant) and refuses a grant the agent's person's own role does not hold, `409 grant_exceeds_person`. The clamp is one function both tenant guards call (`services/default-tenant.ts`'s `agentTenant`): an agent holds a stored grant only while its person's role holds it, so a demoted person's agent keeps the row but not the permission. The routes for the seven check `allows(tenant, "<permission>")`, which reads the grants; every other check keeps `can(tenant.role, …)`, so no other owner or admin permission is reachable. Every agent write on content, assets and meeting types writes one `recordAgentWrite` row naming the agent and its person (magnets already did); a person's writes there stay unaudited. The member-area writes audit every caller through `recordAuditAction`, whose actor names an agent as the agent. No grant raises the ceiling. `/v1/agent/context` is the agent's own read, unchanged by grants, and needs no permission beyond the workspace guard. Same registration scope as the routes above (`workspace || multi-tenant`).
@@ -167,6 +167,7 @@ sweep's own DB constraint (never a caller-side lock).
 - Don't assume Stripe is configured. Read at startup; if missing, disable commerce endpoints and log a warning.
 - Never log secret keys, even at debug.
 - **A restricted live key can run live (#8450, D-68's apps/api leg).** `build()` admits the key once at boot through `lib/stripe.ts`'s `admitApiStripeKey()` — the one apps/api file `architecture.yaml` lets name the SDK's admission call. It admits only a restricted live key beside `STRIPE_MODE=live` on a production build (`VERCEL_ENV=production`, or `NODE_ENV=production` off Vercel); `STRIPE_MODE` unset or `test` is the old sandbox-only boot, and every other combination stops the server. At request time the member portal session and the checkout start and read call `assertAdmittedStripeKey`, which passes the admitted restricted key and still refuses an unrestricted or publishable live key; the Organization portal, the recommender checkout and request-and-confirm stay on `assertSandboxKey`, sandbox-only until their own issues. The Billing page's plan read and webhook signature checks have no route guard and go live with the process. A live process gives both checkout routes their own per-IP `checkout` rate-limit bucket (`AILK_RATE_LIMIT_CHECKOUT_PER_MINUTE`). The webhook drops, with a 200 and a `livemode_mismatch` warn, any signed event whose `livemode` is not the admitted key class (`stripeKeyMode()`), before any write and without marking it seen. **The proposal paid stamp (#8516 D13):** a `checkout.session.completed` carrying the server-written `metadata.ailk_proposal` and `ailk_workspace` stamps that proposal's `paid_at` and `paid_session_id` once through the base-tree boundary `lib/proposal-paid-store.ts` (the webhook may import no slice-owned file), and writes one `people.proposal.paid` audit row as the `stripe` system actor keyed by the event id — `succeeded`, or `failed` with `already_paid` (a second charge) or `not_paid`; a same-session replay writes none. Proposal payment stays on `assertSandboxKey` until its own issue moves it live.
+- **Every Checkout session shows a terms box (#8765 D12).** `@working-theory/stripe-client`'s creators set `consent_collection.terms_of_service: "required"` on every session, so **the seller's Stripe account must have a Terms of service URL set in the Stripe Dashboard** (Settings → Business → Public details); without one Stripe refuses the session and the creator throws `TermsOfServiceUrlMissingError`, which each caller answers with its existing failure. Every session also carries `metadata.ailk_terms` — the stamp the webhook's checkout grant requires (see the consent bullet).
 
 ## What NOT to do
 
@@ -177,7 +178,19 @@ sweep's own DB constraint (never a caller-side lock).
 - Don't put session state in `apps/api`. It's stateless.
 - Don't bundle `apps/api` (esbuild, rollup, webpack). Slice specifiers cannot survive it — see `## Deploy path`.
 
-Last updated: 2026-10-14 — the standard client onboarding diagnostic (#8515): the magnets bullet names the standard onboarding seed and its two callers; the flow-definition seed refuses the `onboarding` slug; the member-area bullet names Start onboarding and the outbound action; the member reads and writes bullets name the onboarding pair and the message `action`; `HUB_SESSION_ROUTES` is 24 entries — verified against `apps/api/src/lib/{tenant-db,member-store}.ts`, `apps/api/src/routes/{member/onboarding,workspaces/messages-out,workspaces/index}.ts`, `apps/api/src/services/flow-engine.ts`, `apps/api/src/bin/seed-presets.ts` and `apps/api/src/middleware/auth.ts`.
+Last updated: 2026-10-16 — a spoke purchase's checkout grant (#8778): the consent bullet names the spokeCheckout write point's grant from `payload.termsAccepted` — verified against `apps/api/src/services/{lead-routing,consent}.ts`.
+
+Prior: 2026-10-16 — the checkout grant (#8765 PR B): the consent bullet names `checkout` as the eighth, unverified source and the webhook's grant (`recordCheckoutConsent`, `checkoutBuyerPerson`, the stamp and outcome rules); BYO Stripe names the terms box and its Dashboard precondition — verified against `apps/api/src/routes/webhooks/stripe.ts`, `apps/api/src/services/{consent,checkout-buyer}.ts`, `apps/api/src/lib/consent-store.ts` and `database/migrations/20261019120000_consent_source_checkout/migration.sql`.
+
+Prior: 2026-10-15 — sign-up refuses without the agreements (#8765): the consent bullet names the evidence route, the account-agreements pair, the second ledger writer (the web sign-up hook), the account-level `user`-subject reading of a sign-up agreement and the member pair's change; `HUB_SESSION_ROUTES` is 26 entries — verified against `apps/api/src/routes/consent/account.ts`, `apps/api/src/routes/member/consents.ts`, `apps/api/src/middleware/auth.ts` and `apps/api/src/server.ts`.
+
+Prior: 2026-10-15 — a per-magnet completion setting (#8757): the leads bullet names the `next` key and the invite email; the magnets bullet names the completion pair, its PATCH rules and refusals — verified against `apps/api/src/routes/{leads,magnets}/index.ts`, `apps/api/src/services/{magnet-completion,plan-offerings}.ts` and `apps/api/src/lib/flow-completion-store.ts`.
+
+Prior: 2026-10-14 — the Contact form magnet (#8661): the magnets bullet names the Contact form seed, its callers and the `contact` slug's place in `slug_fixed`/`slug_reserved`; the definition bullet names the `contact` refusal and the `upsertFlowDefinition` guard — verified against `apps/api/src/lib/tenant-db.ts`, `apps/api/src/routes/{workspaces,magnets}/index.ts`, `apps/api/src/services/{flow-engine,project-listings}.ts` and `apps/api/src/bin/seed-presets.ts`.
+
+Prior: 2026-10-14 — magnets editable after creation (#8641): the magnets bullet names the slug rename, its four `409` refusals and its audit row in place of the old immutable-slug refusal — verified against `apps/api/src/routes/magnets/index.ts` and `apps/api/src/lib/tenant-db.ts`.
+
+Prior: 2026-10-14 — the standard client onboarding diagnostic (#8515): the magnets bullet names the standard onboarding seed and its two callers; the flow-definition seed refuses the `onboarding` slug; the member-area bullet names Start onboarding and the outbound action; the member reads and writes bullets name the onboarding pair and the message `action`; `HUB_SESSION_ROUTES` is 24 entries — verified against `apps/api/src/lib/{tenant-db,member-store}.ts`, `apps/api/src/routes/{member/onboarding,workspaces/messages-out,workspaces/index}.ts`, `apps/api/src/services/flow-engine.ts`, `apps/api/src/bin/seed-presets.ts` and `apps/api/src/middleware/auth.ts`.
 
 Prior: 2026-10-14 — proposals as an artifact kind (#8516): the member-area bullet names the piece `kind`, the proposals pair, its two MCP twins and the money gate (C4); the member-writes bullet names a proposal's artifact keys, the client review audit row and the pay route with its same-site and sandbox rule; the BYO Stripe bullet names the webhook's proposal stamp — verified against `apps/api/src/routes/workspaces/pieces.ts`, `apps/api/src/routes/member/{artifacts,artifact-review}.ts`, `apps/api/src/services/proposal-payments.ts`, `apps/api/src/lib/{tenant-db,member-store,proposal-paid-store}.ts` and `apps/api/src/routes/webhooks/stripe.ts`.
 

package/templates/apps/api/jest.config.cjs

@@ -1,5 +1,6 @@
 module.exports = {
   preset: 'ts-jest',
+  globalSetup: require.resolve('../../tools/jest/pin-timezone.cjs'),
   testEnvironment: 'node',
   roots: ['<rootDir>/src'],
   testMatch: ['**/__tests__/**/*.test.ts', '**/?(*.)+(test).ts'],

package/templates/apps/api/src/lib/__tests__/consent-store.test.ts

@@ -135,6 +135,25 @@ describe("the two readings (SEC-8438-1)", () => {
     ).toBe(true);
   });
 
+  it("a checkout row is unverified: in the Person's any-source reading, never their own (#8765 D13, C10)", async () => {
+    expect(isUnverifiedSource("checkout")).toBe(true);
+    double.ledger.push(
+      row({
+        purposeId: "data",
+        granted: true,
+        source: "checkout",
+        sourceRef: "cs_live_abc123",
+      }),
+    );
+    const own = await ownConsentState(WS, PERSON, CONFIG);
+    const any = await anySourceConsentState(WS, PERSON, CONFIG);
+    expect(own.find((s) => s.purposeId === "data")?.row).toBeNull();
+    expect(any.find((s) => s.purposeId === "data")?.row).toMatchObject({
+      source: "checkout",
+      sourceRef: "cs_live_abc123",
+    });
+  });
+
   it("another workspace's rows and another Person's rows never show", async () => {
     double.ledger.push(
       row({ workspaceId: OTHER_WS, purposeId: "data", granted: true }),

package/templates/apps/api/src/lib/__tests__/flow-completion-store.test.ts

@@ -0,0 +1,149 @@
+/**
+ * @file flow-completion-store.test.ts
+ *
+ * A magnet's completion setting — its data boundary (#8757, spec
+ * docs/specs/8757-a-per-magnet-completion-setting-spec.md D3, AC-3): every
+ * statement is scoped by the workspace it is given, so a write naming another
+ * workspace's magnet answers `not_found` and changes nothing, a draft magnet
+ * is never a live completion, and the invite caps count only this magnet's
+ * leads of this workspace in their window.
+ *
+ * The world is the in-memory Prisma double (`__tests__/factories/in-memory-prisma`),
+ * which refuses a filter it does not model — so scoping that rides on one
+ * cannot pass silently.
+ */
+// eslint-disable-next-line no-restricted-syntax -- jest mock factory must be hoisted
+jest.mock("../prisma.js", () =>
+  jest
+    .requireActual<typeof import("../../__tests__/factories/in-memory-prisma")>(
+      "../../__tests__/factories/in-memory-prisma",
+    )
+    .createInMemoryPrisma(),
+);
+
+import { prisma } from "../prisma.js";
+import {
+  completionOf,
+  completionsFor,
+  inviteSendCounts,
+  liveCompletionBySlug,
+  setCompletion,
+} from "../flow-completion-store.js";
+
+type Row = Record<string, unknown>;
+// eslint-disable-next-line no-restricted-syntax -- the in-memory double exposes its store on keys the real client type does not declare
+const fake = prisma as unknown as { __db: Record<string, Row[]> };
+
+const WS_A1 = "wksp_00000000-0000-7000-8000-0000000000a1";
+const WS_A2 = "wksp_00000000-0000-7000-8000-0000000000a2";
+const M1 = "flow_00000000-0000-7000-8000-000000000001";
+const M2 = "flow_00000000-0000-7000-8000-000000000002";
+const DRAFT = "flow_00000000-0000-7000-8000-000000000003";
+const NOW = new Date("2026-10-15T12:00:00.000Z");
+
+function magnet(id: string, ws: string, slug: string, status: string, extra: Row = {}): Row {
+  return { id, siteId: ws, workspaceId: ws, slug, title: `Magnet ${slug}`, status, ...extra };
+}
+
+function lead(ws: string, n: number, source: string, email: string, ago: number): Row {
+  return {
+    id: `lead_00000000-0000-7000-8000-${String(n).padStart(12, "0")}`,
+    siteId: ws,
+    workspaceId: ws,
+    source,
+    email,
+    createdAt: new Date(NOW.getTime() - ago),
+  };
+}
+
+beforeEach(() => {
+  const db = fake.__db;
+  for (const key of Object.keys(db)) delete db[key];
+  db.flowDefinition = [
+    magnet(M1, WS_A1, "contact", "live", { completion: "invite", checkoutOffering: null }),
+    magnet(M2, WS_A2, "contact", "live", { completion: "lead", checkoutOffering: null }),
+    magnet(DRAFT, WS_A1, "request-quote", "draft", { completion: "invite", checkoutOffering: null }),
+  ];
+  db.lead = [];
+});
+
+describe("completionsFor (D3)", () => {
+  it("reads only the given workspace's rows; an id absent from it reads as lead", async () => {
+    const settings = await completionsFor(WS_A1, [M1, M2]);
+    expect(completionOf(settings, M1)).toEqual({ completion: "invite", checkoutOffering: null });
+    expect(settings.has(M2)).toBe(false);
+    expect(completionOf(settings, M2)).toEqual({ completion: "lead", checkoutOffering: null });
+  });
+
+  it("reads a row with neither column as lead", async () => {
+    fake.__db.flowDefinition!.push(
+      magnet("flow_00000000-0000-7000-8000-000000000009", WS_A1, "bare", "live"),
+    );
+    const settings = await completionsFor(WS_A1, ["flow_00000000-0000-7000-8000-000000000009"]);
+    expect(completionOf(settings, "flow_00000000-0000-7000-8000-000000000009")).toEqual({
+      completion: "lead",
+      checkoutOffering: null,
+    });
+  });
+});
+
+describe("setCompletion (D3, AC-3)", () => {
+  it("writes exactly the pair onto the workspace's own magnet", async () => {
+    expect(
+      await setCompletion(WS_A1, M1, { completion: "checkout", checkoutOffering: "retainer" }),
+    ).toBe("set");
+    const row = fake.__db.flowDefinition!.find((r) => r.id === M1)!;
+    // `updatedAt` is Prisma-managed (`@updatedAt`); every other column is as it was.
+    expect(row).toEqual({
+      ...magnet(M1, WS_A1, "contact", "live", {
+        completion: "checkout",
+        checkoutOffering: "retainer",
+      }),
+      updatedAt: expect.any(Date),
+    });
+  });
+
+  it("answers not_found for another workspace's magnet and changes nothing", async () => {
+    const before = structuredClone(fake.__db.flowDefinition);
+    expect(await setCompletion(WS_A1, M2, { completion: "invite", checkoutOffering: null })).toBe(
+      "not_found",
+    );
+    expect(fake.__db.flowDefinition).toEqual(before);
+  });
+});
+
+describe("liveCompletionBySlug (D3, AC-3)", () => {
+  it("answers a live magnet's setting and title", async () => {
+    expect(await liveCompletionBySlug(WS_A1, "contact")).toEqual({
+      completion: "invite",
+      checkoutOffering: null,
+      title: "Magnet contact",
+      config: undefined,
+    });
+  });
+
+  it("answers null for a draft row, an absent slug and another workspace's magnet", async () => {
+    expect(await liveCompletionBySlug(WS_A1, "request-quote")).toBeNull();
+    expect(await liveCompletionBySlug(WS_A1, "missing")).toBeNull();
+    fake.__db.flowDefinition = fake.__db.flowDefinition!.filter((r) => r.id !== M1);
+    expect(await liveCompletionBySlug(WS_A1, "contact")).toBeNull();
+  });
+});
+
+describe("inviteSendCounts (D6)", () => {
+  it("counts this magnet's leads of this workspace: the recipient's over a day, all over an hour", async () => {
+    const HOUR = 60 * 60 * 1000;
+    fake.__db.lead = [
+      lead(WS_A1, 1, "flow:contact", "a@b.example", 5 * 60 * 1000),
+      lead(WS_A1, 2, "flow:contact", "a@b.example", 20 * HOUR),
+      lead(WS_A1, 3, "flow:contact", "a@b.example", 25 * HOUR),
+      lead(WS_A1, 4, "flow:contact", "c@d.example", 10 * 60 * 1000),
+      lead(WS_A1, 5, "flow:other", "a@b.example", 60 * 1000),
+      lead(WS_A2, 6, "flow:contact", "a@b.example", 60 * 1000),
+    ];
+    expect(await inviteSendCounts(WS_A1, "contact", "a@b.example", NOW)).toEqual({
+      recipientDay: 2,
+      siteHour: 2,
+    });
+  });
+});