create-ailk 0.4.0 → 0.6.0

package/templates/content/en/LandingPage/how-it-works.mdx

@@ -0,0 +1,143 @@
+---
+type: "LandingPage"
+slug: "how-it-works"
+title: "Get set up in {number} easy steps"
+description: "Summarize the setup process briefly in a way that makes it seem approachable and quick."
+sections:
+  [
+    {
+      "id": "hero",
+      "type": "hero",
+      "data":
+        {
+          "eyebrow": "How it Works",
+          "headline": "Get set up in {number} easy steps",
+          "subheadline": "Summarize the setup process briefly in a way that makes it seem approachable and quick.",
+          "primaryCta": { "label": "{Primary CTA}", "href": "/contact" },
+          "secondaryCta":
+            {
+              "label": "{Secondary CTA}",
+              "href": "/pricing",
+              "variant": "outline",
+            },
+        },
+    },
+    {
+      "id": "steps",
+      "type": "feature",
+      "data":
+        {
+          "variant": "alternating",
+          "numbered": true,
+          "headline": "",
+          "features":
+            [
+              {
+                "title": "The first thing they need to do to get the outcome they want",
+                "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat.",
+              },
+              {
+                "title": "The second thing they need to do to get the outcome they want",
+                "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat.",
+              },
+              {
+                "title": "The third thing they need to do to get the outcome they want",
+                "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat.",
+              },
+            ],
+        },
+    },
+    {
+      "id": "logo-cloud",
+      "type": "logoCloud",
+      "data":
+        {
+          "headline": "Don’t just take our word for it",
+          "logos":
+            [
+              { "name": "Placeholder logo", "src": "/logomark.svg" },
+              { "name": "Placeholder logo", "src": "/logomark.svg" },
+              { "name": "Placeholder logo", "src": "/logomark.svg" },
+              { "name": "Placeholder logo", "src": "/logomark.svg" },
+              { "name": "Placeholder logo", "src": "/logomark.svg" },
+              { "name": "Placeholder logo", "src": "/logomark.svg" },
+            ],
+          "layout": "inline",
+          "treatment": "monochrome",
+        },
+    },
+    {
+      "id": "testimonial",
+      "type": "testimonials",
+      "data":
+        {
+          "variant": "featured",
+          "items":
+            [
+              {
+                "quote": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat.",
+                "author": "John Smith",
+                "role": "CEO, Google",
+              },
+            ],
+        },
+    },
+    {
+      "id": "switch",
+      "type": "cta",
+      "data":
+        {
+          "variant": "box",
+          "headline": "Switch to {your product} in {time amount} or less",
+          "description": "You shouldn't have to {experience a painful problem}. With {your product}, you can finally {achieve a value outcome or get a big improvement}.",
+          "chips":
+            ["No credit card required", "Cancel any time", "Live chat support"],
+          "primaryCta": { "label": "{Primary CTA}", "href": "/contact" },
+          "secondaryCta":
+            {
+              "label": "{Secondary CTA}",
+              "href": "/pricing",
+              "variant": "outline",
+            },
+          "closingLine": "{Social Proof goes here}",
+        },
+    },
+    {
+      "id": "faq",
+      "type": "faq",
+      "data":
+        {
+          "headline": "FAQs",
+          "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique.",
+          "supportLink": { "label": "Contact", "href": "/contact" },
+          "presentation": "accordion",
+          "initialOpen": "first",
+          "items":
+            [
+              {
+                "question": "Vel odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa?",
+                "answer": "Vel odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa.",
+              },
+              {
+                "question": "Dolorem consectetur quia maxime sunt ut sint. Fuga optio dolorem animi voluptatem laudantium error. Quis accusamus deleniti rer?",
+                "answer": "Vel odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa.",
+              },
+              {
+                "question": "Totam nihil esse. Itaque optio temporibus adipisci. Rerum nisi aperiam aliquid doloremque aliquam?",
+                "answer": "Vel odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa.",
+              },
+              {
+                "question": "Delectus minus officiis et. Perspiciatis illum nisi vitae. Sed consequuntur animi corrupti distinctio ipsam accusamus?",
+                "answer": "Vel odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa.",
+              },
+              {
+                "question": "Aperiam perferendis voluptatem est sit enim sed eaque perspiciatis enim. Est explicabo ea explicabo et et dignissimos aliquid?",
+                "answer": "Vel odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa odio odit voluptatum ut veritatis. Ex rerum aspernatur voluptas unde officia. Dolorem officiis laboriosa.",
+              },
+            ],
+        },
+    },
+  ]
+---
+
+{/* Rendered from frontmatter `sections[]` by the generic `[slug]` route (`app/[locale]/[slug]/page.tsx`). It emits the LandingPage builder's `WebPage` JSON-LD (the scaffold's structured-data gate accepts nothing else for a LandingPage). Placeholder copy, verbatim from the reference — replace before you launch. */}

package/templates/content/en/ReturnsPolicyPage/returns.mdx

@@ -0,0 +1,108 @@
+---
+type: "ReturnsPolicyPage"
+slug: "returns"
+title: "Returns & Refunds"
+description: "How to return an order from this site, how long you have, and how refunds are issued."
+updatedAt: "2026-09-17"
+sections:
+  [
+    {
+      "id": "returns-document",
+      "type": "document-chassis",
+      "data":
+        {
+          "headline": "Returns & Refunds",
+          "backHref": "/",
+          "backLabel": "Back home",
+          "navGroupLabel": "Contents",
+          "stats":
+            [
+              { "label": "Last updated", "sublabel": "17 September 2026" },
+              { "label": "Applies to", "sublabel": "Orders placed on this site" },
+            ],
+          "sections":
+            [
+              {
+                "id": "intro",
+                "heading": "Returns & Refunds",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "This page explains how returns and refunds work on this site. Replace the starter copy below with the policy you actually operate — the headings are the ones a customer and an agent both look for, so keep them and fill in your own terms.",
+                    },
+                  ],
+              },
+              {
+                "id": "return-window",
+                "heading": "How long you have",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "State the return window in days, counted from a date a customer can verify — delivery, not dispatch. If different products carry different windows, say which, and say plainly which items cannot be returned at all.",
+                    },
+                  ],
+              },
+              {
+                "id": "condition",
+                "heading": "What condition an item must be in",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Describe the condition an item must come back in — unused, original packaging, tags attached, or whatever your standard is. Name anything that voids a return, such as a removed seal on a digital product or a personalised item.",
+                    },
+                  ],
+              },
+              {
+                "id": "how-to-return",
+                "heading": "How to start a return",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Give the customer one route to start a return and the information they need to hand: an order number, the item, and the reason. If you issue a return label, say who pays for it; if you do not, say that too.",
+                    },
+                  ],
+              },
+              {
+                "id": "refunds",
+                "heading": "How refunds are issued",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Say what a customer gets back — the item price, the original shipping, or both — and how long the refund takes to reach the payment method it came from. If you offer store credit or an exchange instead, describe when each applies.",
+                    },
+                  ],
+              },
+              {
+                "id": "exchanges",
+                "heading": "Exchanges and faulty items",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "A faulty or incorrectly shipped item is usually not an ordinary return. Set out how those are handled, and say whether the return window above applies to them.",
+                    },
+                  ],
+              },
+              {
+                "id": "contact",
+                "heading": "Questions about a return",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Point to the one place a customer should write, and say roughly how quickly you answer. A returns policy nobody can ask a question about is a policy that generates disputes.",
+                    },
+                  ],
+              },
+            ],
+        },
+    },
+  ]
+---
+
+{/* Rendered from frontmatter `sections[]`; the MDX body is not read by the section-catalog renderer. The JSON-LD for this page — a WebPage wrapping a MerchantReturnPolicy — is emitted by `buildReturnsPolicyPage` (#5947), not hand-rolled here. */}

package/templates/content/en/ShippingPolicyPage/shipping.mdx

@@ -0,0 +1,108 @@
+---
+type: "ShippingPolicyPage"
+slug: "shipping"
+title: "Shipping Policy"
+description: "Where orders from this site ship, how long delivery takes, what it costs, and what happens when a parcel goes missing."
+updatedAt: "2026-09-17"
+sections:
+  [
+    {
+      "id": "shipping-document",
+      "type": "document-chassis",
+      "data":
+        {
+          "headline": "Shipping Policy",
+          "backHref": "/",
+          "backLabel": "Back home",
+          "navGroupLabel": "Contents",
+          "stats":
+            [
+              { "label": "Last updated", "sublabel": "17 September 2026" },
+              { "label": "Applies to", "sublabel": "Orders shipped from this site" },
+            ],
+          "sections":
+            [
+              {
+                "id": "intro",
+                "heading": "Shipping Policy",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "This page explains how orders from this site are shipped. Replace the starter copy below with the policy you actually operate — the headings are the ones a customer and an agent both look for, so keep them and fill in your own terms.",
+                    },
+                  ],
+              },
+              {
+                "id": "destinations",
+                "heading": "Where we ship",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "List the countries or regions you ship to, and say plainly where you do not. If some products are restricted to a subset of those destinations, say which.",
+                    },
+                  ],
+              },
+              {
+                "id": "processing-and-transit",
+                "heading": "How long it takes",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Give processing time and transit time as two separate figures, in business days, per shipping option. A single blended estimate is the one thing customers most often read as a promise you did not make.",
+                    },
+                  ],
+              },
+              {
+                "id": "costs",
+                "heading": "What shipping costs",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Set out the cost of each shipping option and any threshold above which it is free. Say whether the figure shown at checkout is final, and whether duties and import taxes are included or collected on delivery.",
+                    },
+                  ],
+              },
+              {
+                "id": "tracking",
+                "heading": "Tracking your order",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Say when tracking information is sent, where it comes from, and what a customer should do if it has not updated for a while.",
+                    },
+                  ],
+              },
+              {
+                "id": "lost-or-damaged",
+                "heading": "Lost or damaged parcels",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Describe how long a parcel must be missing before you treat it as lost, what you do then, and what you need from the customer — photographs for damage, a written report for a loss. Returns of damaged goods are the returns policy's business; link to it rather than restating it here.",
+                    },
+                  ],
+              },
+              {
+                "id": "contact",
+                "heading": "Questions about a delivery",
+                "blocks":
+                  [
+                    {
+                      "kind": "paragraph",
+                      "text": "Point to the one place a customer should write, and say roughly how quickly you answer.",
+                    },
+                  ],
+              },
+            ],
+        },
+    },
+  ]
+---
+
+{/* Rendered from frontmatter `sections[]`; the MDX body is not read by the section-catalog renderer. `OfferShippingDetails` is offer-scoped, not page-scoped, so this page emits a plain WebPage (#5947, D3) — real rates belong on an Offer, or reach this page's JSON-LD through the `schema:` escape hatch. */}

package/templates/database/CHANGELOG.md

@@ -1,5 +1,154 @@
 # @working-theory/database
 
+## 0.25.0
+
+### Minor Changes
+
+- [#5813](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/5813) [`518c590`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/518c59023876a0212504ace9a683084df0168be6) Thanks [@claudio-planck](https://github.com/claudio-planck)! - Generalize `Artifact` into the workspace's content store, and add `Asset` ([#5800](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/5800), roadmap D1/D7).
+
+  `artifacts.session_id` was `NOT NULL` behind an `ON DELETE CASCADE`, so deleting an agent session deleted every artifact it had produced. It is now nullable behind `ON DELETE SET NULL`: the session is provenance, the workspace owns the artifact. Beside it, four columns the content store needs — `content_type` (the discriminator; `text/page` is what the editor writes), `locale` (defaulting to ADR 0019's `product.default_locale`), `slug` (NULL until publish) and `published_version_id`. `(workspace_id, content_type, locale, slug)` is unique and `(workspace_id, content_type, updated_at)` is the list index. `published_version_id` is a plain pointer, never a relation and never `is_current`, which remains the draft tip and is never the publish mechanism.
+
+  `content_type` is ADDITIVE beside the existing `type` column rather than a rename: `apps/api/src/routes/workspaces/sessions.ts` reads `type` and keeps working unchanged. The migration backfills `content_type` from `type`, so the two agree row-for-row; new code reads `content_type`.
+
+  `Asset { workspaceId, key, filename, contentType, bytes, size }` follows the inbox namespace's `DeliverableAsset` precedent — bytes in the row, no new infrastructure — with `(workspace_id, key)` unique and a relation-free `workspaceId` (ADR 0009 invariant 1). `@working-theory/ids` registers its `asset_` prefix (ADR 0031 rule 3) and exports `zAssetId`.
+
+  The migration brackets the FK relaxation with zero-row assertions — no row already NULL and no orphan before the swap; no row lost, no row nulled and no `content_type`/`type` drift after it — so it applies to an empty database and to a populated one, and aborts rather than backfilling past a surprise.
+
+- [#6139](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6139) [`9f45297`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/9f4529701aaf2f56acbd2be416e8a8c17358e1aa) Thanks [@samuelhenry](https://github.com/samuelhenry)! - Appointments from Cal.com webhooks ([#6085](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6085), brief H7).
+
+  Adds `POST /v1/webhooks/calcom` — a signed receiver (HMAC-SHA256 over the raw
+  body, `x-cal-signature-256`) that normalizes six `BOOKING_*` trigger events
+  into a new `Appointment` row, guarded by three independent per-family
+  watermarks (lifecycle / payment / no-show) and a 15-minute replay window —
+  and `GET /v1/schedule/appointments`, a tenant-guarded, `owner|admin`-floored
+  read of the site's own appointments, scoped strictly to
+  `tenant.workspaceId` (never `currentSiteId()`, never a platform-operator
+  escape hatch).
+
+  `@working-theory/database` gains the `Appointment` model
+  (`database/inbox/schema.prisma`) and its migration.
+  `@working-theory/ids` registers the `appointment` → `appt` prefix (ADR-0031
+  rule 3). `@working-theory/validation` gains `AppointmentSchema`,
+  `AppointmentListSchema`, `listAppointmentsInputSchema` /
+  `listAppointmentsOutputSchema`, and the inbound Cal.com webhook envelope
+  schemas. `@working-theory/api-client` gains `schedule.appointments()`.
+  `create-ailk` adds the receiver + read + service files (and their tests) to
+  the `scheduling` module's `ownedFiles` — a keyless scaffold is unaffected;
+  a `--modules scheduling` scaffold now carries the new surface.
+
+- [#6118](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6118) [`8b20866`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/8b20866470f5aa3ef9fbbba1d11e4fc3b998da86) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `Asset` gains three columns the lightbox edits in place ([#6092](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6092), S4/D10): `title String?`, `description String?`, `tags String[] @default([])`.
+
+  `title` and `description` are nullable with no default — `NULL` means the owner has not written one, distinct from an empty string meaning they cleared it, and neither is backfilled from `filename`. `tags` is non-null with an empty-array default: an untagged asset is an empty set, not an unknown one. The column stores tag SLUGS (`ad-creative`, `workspace-memory`, …), never the human labels a surface renders them as, and is deliberately unconstrained — the asset vocabulary and the document vocabulary (a document is a row in this same store) ride the one column, and a fixed set is a UI affordance, not a database constraint.
+
+  Delivered by one additive migration, `20260918120000_asset_metadata_columns` — no column dropped or renamed, no value backfilled, the `(workspace_id, key)` identity and the `asset_` UUIDv7 CHECK untouched. An `INSERT` naming none of the three columns still succeeds.
+
+- [#6202](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6202) [`b85e147`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/b85e147d0d26150eb1a00e1933df138087727628) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `FlowDefinition` and `FlowSession` gain a nullable `workspaceId` column, backfilled 1:1 from `siteId` ([#6155](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6155)).
+
+  The literal alias `"default"` resolves to the seeded sentinel workspace; every other alias resolves only by exact `workspaces.id` equality. A row whose `siteId` matches no workspace is left `NULL` — unset, never guessed — and stays invisible to every tenant-scoped read rather than visible to the wrong one. `siteId` is unchanged and the public flow engine keeps resolving it; nothing about the request or response shape of `/v1/flows/*` or either MCP flow tool changes.
+
+  `database/tenancy.ts` also gains `resolveSentinelWorkspaceRow(prisma)` — the sentinel-existence sibling of `resolveDefaultWorkspaceRow`, carrying no `workspace.count()` gate, so a correctly-configured multi-workspace deployment that has not pinned `AILK_SITE_ID` still resolves the `"default"` alias.
+
+- [#6218](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6218) [`80f498e`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/80f498e3dcd3d70931045dc376c293c0c9a88c65) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `FlowDefinition` gains four operator-facing columns — `kind`, `title`, `landingPage`, `status` ([#6156](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6156)) — backfilled for every existing row by a structural rule (never from slug), with the visitor-facing `config` left byte-identical.
+
+  `status` (`draft` | `live`) carries NO column default and is backfilled `'live'` — every row that exists today is already serving, and a silent default would make publication the thing that happens when a future writer says nothing. `title` is likewise `NOT NULL` with no default, backfilled from `slug`. `kind` (`special-report` | `diagnostic` | `listicle` | `waitlist` | `contact` | `newsletter`) keeps its column default (`'contact'`) and is reclassified only where the row's own structure (a projected listing, a recommending-mode config, a `deliverables` block) says otherwise. `landingPage` is nullable with no backfill — a magnet has three public addresses, and NULL means the canonical route serves it.
+
+  `@working-theory/validation`'s `flow.ts` gains `flowKindSchema` / `flowStatusSchema` / `flowLandingPageSchema` as standalone exports — never members of `flowConfigShapeSchema`, which stays `.strict()` and gains none of the four keys, so every stored `configSnapshot` keeps parsing unchanged.
+
+  A `status` of `draft` refuses a NEW walk from starting (`resolveSession`'s definition branch) while a walk already in progress finishes on its pinned snapshot — the `sessionId` branch never re-reads the definition. `upsertFlowDefinition` supplies `kind`/`title`/`status` on CREATE only, never on UPDATE, so a re-seed or re-materialize can never overwrite what an operator later sets. The public routes and both MCP flow tools are unchanged.
+
+- [#6274](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6274) [`3bd8785`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/3bd87854c6589556426894720c85f54bf2daa801) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `ProjectListing` and `Lead` gain a nullable `workspaceId` column (`workspace_id`), indexed for a per-workspace list and backfilled from `siteId` for any existing row whose alias resolves to a real workspace ([#6203](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6203)). `tenantDb(tenant)` gains `projectListings` and `leads` read accessors, scoped by the injected `workspaceId` and never returning a row from another workspace. `siteId` stays the legacy alias, unchanged, on both models.
+
+- [#6280](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6280) [`2e7b0d2`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/2e7b0d2411944002104d5105edb6e8d59c8434c5) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `Lead` gains a nullable triage stamp — `handledAt` (`handled_at`) and `handledBy` (`handled_by`), the actor — plus a `(workspaceId, handledAt)` index for the Needs-you read ([#6204](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6204)). Existing rows are unaffected by the purely-additive migration and read as unhandled. `@working-theory/validation` gains `MESSAGE_LEAD_SOURCES` / `MESSAGE_LEAD_SOURCE_LIST` and `isMessageSource()` — the one closed allowlist declaring which `Lead.source` values are messages (a lead that needs an answer, operator decision Q1(a)), never a denylist and never a pattern test. `tenantDb(tenant).leads` gains `listUnhandledMessages` (bounded, workspace-scoped) and `markHandled` (an idempotent compare-and-swap), and `leads-inbox.ts` exposes the role-floored service pair over them. No route and no MCP tool — nothing new is reachable from this unit.
+
+- [#6360](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6360) [`2809d30`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/2809d307d4d130541cb29ea7176b4af17e58679c) Thanks [@claudio-planck](https://github.com/claudio-planck)! - `Lead`, `ProjectListing`, `FlowDefinition`, `FlowSession` gain NOT NULL `workspaceId` plus a `CHECK (workspace_id = site_id)` equality constraint, and `WorkspaceSiteIdentity` gains `@@unique([id, workspaceId])` ([#6254](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6254), the tenancy-fence keystone).
+
+  The issue's literal ask — a composite foreign key from the four fenced models to `WorkspaceSiteIdentity` — is not buildable against this tree: it crosses the `inbox` → `config` namespace boundary ADR-0009 forbids, `siteId` never holds a `WorkspaceSiteIdentity.id` (it holds the workspace id), and `WorkspaceSiteIdentity` is an optional per-workspace config blob whose required existence would break anonymous lead capture, a never-gate surface. The equality CHECK delivers the same guarantee — Postgres rejects a row whose `workspaceId` disagrees with its site — without a relation and without crossing the boundary; it is strictly tighter than the FK would have been. `docs/database/namespaces.md` documents the pattern for the fan-out ([#6255](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6255)–[#6260](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6260), [#6171](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6171), [#6314](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6314)), which land their own model changes into this same migration, `database/migrations/20260922120000_tenancy_fence`.
+
+  `DeliverableGrant` (the fifth already-keyed model) is deliberately NOT touched — its `workspaceId` has no source column to derive from and `NULL` is the serve path's fail-closed sentinel; [#6257](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6257) fences it separately, at mint grain.
+
+  Every write site that creates a `Lead`, `ProjectListing`, `FlowDefinition` or `FlowSession` row now derives `workspaceId` server-side from the resolved site alias (`apps/api/src/lib/site.ts`'s `resolveSiteWorkspaceId()` / `resolveWorkspaceIdForAlias()`), never from a request body. `routeLead`'s file-fallback no longer swallows a constraint violation into a silent success — it re-raises as a `persist_failed` error, while a genuine infrastructure outage still takes the file fallback unchanged.
+
+- [#6418](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6418) [`14dcb0f`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/14dcb0fe7864a13f3fb9d573c303ddb8780dbdf5) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `ProjectListing` records the listicle magnet that captured it, so a magnet's Applications list can be scoped to its own submissions ([#6314](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6314)).
+
+  Nothing constrains a workspace to one listicle-kind `FlowDefinition` — the model carries `@@unique([siteId, slug])` and no `@@unique([siteId, kind])` — so a workspace-only Applications list would silently show two listicle magnets' applications on both of their detail pages, with nothing to notice it. `ProjectListing` carried no reverse link to the magnet that captured it: the two pointers that existed (`FlowDefinition.listingId` and `ProjectListing.experimentKey`) are both written at APPROVAL time, when an approved listing is projected into its own diagnostic sub-flow, and name a different flow entirely.
+
+  **`@working-theory/database`** — `ProjectListing` gains `capturedByFlowId String? @map("captured_by_flow_id")` and `@@index([workspaceId, capturedByFlowId])`. A plain scalar ref: no `@relation`, no foreign key, no `onDelete`, matching the intra-`inbox` convention every sibling reference on this model already follows (`leadId`, `listingId`, `grantId`, `flowSessionId` carry none, and all 24 foreign keys in the migration history target `auth`). Integrity rests on the server-side resolve and on the read carrying both scope terms; the column's own schema comment states that cost rather than arguing it away. Permanently nullable and **not** a backfill target — no existing row carries evidence naming the magnet that captured it, so every row written before this reads `NULL` for the life of the row: unattributed, absent from every per-magnet list, and unchanged in the workspace Inbox. `NULL` means "not attributed", never "attribution failed" and never "captured directly".
+
+  **`@working-theory/validation`** — `projectListingStartSchema` gains one optional key, `capturedByFlowSlug: flowSlugSchema.optional()`. Additive on a `.strict()` schema, so every existing caller (the agent channel included) is accepted unchanged. It is a slug rather than an id because no public surface hands a visitor a `flow_<uuidv7>`; the server resolves it against the already-resolved `siteId`/`workspaceId` plus `kind: "listicle"` and stores the id it finds. A slug that resolves to nothing — naming no magnet, another workspace's magnet, or a non-listicle magnet — writes `NULL` and still returns `201`: this is a never-gate anonymous route where a refused body is a lost application, and a distinguishable error would make it a cross-workspace magnet-slug oracle. The operator's signal is a PII-safe server-side log line instead.
+
+- [#6383](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6383) [`e71eb5d`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/e71eb5d0d5796732e19dfab7768048a1009ef66d) Thanks [@claudio-planck](https://github.com/claudio-planck)! - **breaking** — the tenancy fence fan-out: thirteen models gain a required `workspace_id`.
+
+  `Subscriber`, `Callback`, `ConsentGrant`, `Appointment`, `DeliverableAsset`,
+  `FlowCheckout`, `WaitlistExperiment`, `WaitlistScore`, `WaitlistFollowUpSend`,
+  `PlaybookInstance` and `SiteListingConfig` each gain a NOT NULL
+  `workspaceId String @map("workspace_id")`, an `@@index([workspaceId])`, a
+  `<table>_workspace_id_format` CHECK and a
+  `<table>_workspace_site_agree CHECK (workspace_id = site_id)`. Every
+  `create`/`upsert` of these models must now supply `workspaceId`, and it must
+  equal the row's `site_id` — a server-resolved workspace id, never a value read
+  from a request body.
+
+  Two models carry no `site_id` and take a different shape:
+
+  - `ListingCsvSend` gains NOT NULL `workspace_id` plus the format CHECK only —
+    no equality CHECK and no foreign key. It is backfilled and stamped from the
+    parent `ProjectListing`.
+  - `SiteSetting` gains NOT NULL `workspace_id`, and **its unique key moves from
+    `key` to `(workspaceId, key)`** — `key` alone is no longer unique, so
+    `siteSetting.findUnique`/`upsert` must pass the compound
+    `workspaceId_key` selector. Existing rows backfill to the sentinel
+    workspace, and every `key` string is left verbatim.
+
+  `DeliverableGrant.workspaceId` stays **nullable** — NULL remains the serve
+  path's fail-closed sentinel for a legacy grant — but gains a NULL-tolerant
+  `CHECK (workspace_id IS NULL OR workspace_id = site_id)`, and both mint sites
+  now stamp it.
+
+  Per [#6254](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6254) AC-1 this lands as an amendment to the single M32 migration
+  `20260922120000_tenancy_fence` rather than a new migration directory. The
+  amendment is a no-op on a database that already applied that migration, which
+  is safe here under the operator's 2026-09-20 disposition that no persistent
+  database carries state that must survive (spec § 1.5); if that ever stops
+  holding, the SQL moves verbatim into a new migration directory and nothing
+  else changes.
+
+- [#5939](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/5939) [`0d2a2b5`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/0d2a2b54eb622a904d4a8b80c31a495651ef19e7) Thanks [@samuelhenry](https://github.com/samuelhenry)! - Add the shared one-workspace resolution predicate to the `./tenancy` subpath ([#5876](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/5876)).
+
+  `resolveDefaultWorkspaceRow(prisma)` and its structural `WorkspacePredicateClient` type join the sentinel constants already exported there — the deployment-level predicate `apps/api/src/services/default-tenant.ts` and `apps/mcp`'s new tenant resolution both delegate to, so the one-workspace check exists exactly once in the repository (NFR-7). Additive: no existing export changes shape.
+
+### Patch Changes
+
+- [#6172](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6172) [`20bab3b`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/20bab3ba318e4ecb8ae7489e4ad638808a3a165d) Thanks [@samuelhenry](https://github.com/samuelhenry)! - Fix `Appointment.noShow` — restore its `@map("no_show")`, matching every sibling field on the model and the column the `20260918120000_add_appointment` migration actually creates ([#6162](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6162)).
+
+  Without the mapping, Prisma's generated client targeted the literal column `noShow`, which the live database does not have — every `prisma.appointment.create()` (and any other read/write touching this field) failed at runtime with `The column noShow of relation appointments does not exist in the current database.` No schema shape changed and no migration is added; this restores the field's intended, already-migrated column target. A new `database/__tests__/appointment.db.test.ts` proves the round trip against a live migrated database, and `tools/check-prisma-migration-drift.ts` — a new preflight check — fails when a Prisma schema field/model's implied column/table name disagrees with what the migration history actually creates, catching this exact class before merge.
+
+- [#6367](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6367) [`d3f599e`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/d3f599e1f1cadd3d998b92514231b0b4b7b7f77c) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `ProjectListing.consentAt` now declares `@db.Timestamptz(3)`, matching the `TIMESTAMPTZ` column its migration (`20260909180000_listing_draft_and_fields`) actually created ([#6171](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6171)). The Prisma schema previously declared this legal-consent timestamp as a plain, timezone-naive `DateTime`, which Prisma defaults to `TIMESTAMP(3)` on Postgres — a drift between the schema's declared type and the live column's real type. No migration is needed; the column already exists as `TIMESTAMPTZ`.
+
+- [#6224](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6224) [`454edc7`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/454edc7bb960666c57b7f2651f644b3788194698) Thanks [@samuelhenry](https://github.com/samuelhenry)! - Add the enabled-meeting-slugs gate ([#6183](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6183) S9b) — the operator's control over which meeting types the site's OWN PAGES publish.
+
+  A fourth workspace site-config blob, `MeetingsSchema` (`enabledSlugs`, beside `ThemeSchema`/`SiteIdentitySchema`/`SEOSchema`), reads and writes through a new route, `GET|PUT /v1/workspaces/:workspaceId/meetings` (`apps/api/src/routes/workspaces/meetings.ts`) — a new route file and a new handler, but the SAME path shape, tenant guard and `{ok,data}` envelope as its three siblings, registered in its own scope gated on the `scheduling` module alone (its GET needs the scheduling provider seam, which a `workspace`/`multi-tenant`-only build does not carry). The write floor is `owner|admin`, matching every other publication-affecting write in this route family; the GET carries the SAME floor, since it echoes the deployment's provider catalog joined with which rows are enabled — a plain member should not read that. The GET also lists the scheduling provider's own bookable event types (`listEventTypes`, [#6182](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6182)), joined with `enabled: boolean`, so the Admin Meetings page can render a toggle list.
+
+  A new anonymous route, `GET /v1/schedule/meeting-types`, is what lets the public `/meet` surface — which holds no session — honour the gate at request time for its OWN two pages: `/meet/[slug]` now 404s a disabled slug (gating both the page and `generateMetadata`, so a disabled event's title/description never reach the document head), and `/meet` lists the enabled set rather than a single configured link, titled from one batched `event-meta` read. An unconfigured deployment falls back to the singleton `SCHEDULING_CAL_LINK` already advertises, so no shipped page goes dark on upgrade. Both pages are `force-dynamic`: enabling or disabling a slug takes effect on the next request, no deploy.
+
+  **This is a publication gate on this site's own pages, not an authorization boundary on the provider.** The three anonymous scheduling routes — `POST /v1/schedule/book`, `GET /v1/schedule/availability`, `GET /v1/schedule/event-meta` — are unchanged and still accept any `calLink` naming ANY event the provider knows about, disabled or not; none of them consults `enabledSlugs`. A disabled event's own page on this site 404s, but the event is still bookable at the provider's own public page and through those three routes directly, and nothing this repo can change alters that. Gating them would change a fenced scheduling-route contract this unit does not touch, and would not close the provider's own page regardless.
+
+- [#6407](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/pull/6407) [`87535c1`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/87535c162654d76af314395eb55e87bd0ef96021) Thanks [@samuelhenry](https://github.com/samuelhenry)! - `database/inbox/schema.prisma` drops the 'PLACEMENT IS A HARD REQUIREMENT' comment blocks ([#6261](https://github.com/working-theory-labs/ai-launch-kit-internal/issues/6261)).
+
+  Comment-only: no model, field, mapping, index or migration changes, so the generated client is byte-identical. The blocks documented a workaround for the tenant-scope drift guard's old model-body collector, which matched `/model\s+(\w+)\s+\{([^}]*)\}/` and stopped at the first closing-curly CHARACTER — including one written inside a doc comment — and so forced `workspaceId` to be declared above any comment that might contain one.
+
+  The reader behind that guard now lives in `tools/lib/tenant-scope-schema.ts` and parses model bodies by brace DEPTH, outside `//` and `///` comments and outside double-quoted strings. Field placement no longer carries meaning for it, so the per-field 'DO NOT MOVE this field' clauses that referenced the blocks go with them. No field moved.
+
+- Updated dependencies [[`8eadc43`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/8eadc437285a0c0121c9f4750ff83dac9591729e), [`2666bf3`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/2666bf3ed24324a37a51cfc5c68019ad5d26403e), [`94ebca8`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/94ebca8f3c1c9f3b744182c720e91417012ecc9b), [`518c590`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/518c59023876a0212504ace9a683084df0168be6), [`8f931f1`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/8f931f1af0d170fb743bf027634154cd53aa1db9), [`ecab283`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/ecab283284d5f6a6ba4a2a08b018b077257de288), [`3bb6a93`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/3bb6a93f41c7dfd8d24ea017f5c403edaae03fcf), [`ab6b792`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/ab6b79258a369ff909fa62d7bffca7fe264fe532), [`9e7df0d`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/9e7df0d93343e126c7b058a66b71ad4dda8ae9e4), [`28f14b5`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/28f14b50dfe29d2d9bf8e75aa368eb1ef3767d47), [`9f45297`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/9f4529701aaf2f56acbd2be416e8a8c17358e1aa), [`80f498e`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/80f498e3dcd3d70931045dc376c293c0c9a88c65), [`454edc7`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/454edc7bb960666c57b7f2651f644b3788194698), [`2e7b0d2`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/2e7b0d2411944002104d5105edb6e8d59c8434c5), [`6d061a0`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/6d061a0cd48baec20899cec2962ff6877addaa85), [`14dcb0f`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/14dcb0fe7864a13f3fb9d573c303ddb8780dbdf5), [`f917f0b`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/f917f0b182ea8daf657b4762551ea5e86fc90616)]:
+  - @working-theory/validation@0.25.0
+  - @working-theory/ids@0.8.0
+
+## 0.24.0
+
+### Patch Changes
+
+- Updated dependencies [[`885adcb`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/885adcbfb23b032424d105942ac0085a03209208), [`c1fb87c`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/c1fb87cbf3ee7ca97951b272cdcdf48c0d1f3a37), [`0b71694`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/0b71694feb662a9686d85cf9478a0b703cc92805), [`6f98cfd`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/6f98cfdef3ebd995dd1c812071cbe62ba4324f64), [`f2a92c5`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/f2a92c585cd5e81fd146c78f65d6fcbca52f7bca), [`ea1e07d`](https://github.com/Working-Theory-Labs/ai-launch-kit-internal/commit/ea1e07dde98d451325d9c0e49c1dad3d243c7a68)]:
+  - @working-theory/validation@0.24.0
+
 ## 0.23.0
 
 ### Patch Changes

package/templates/database/README.md

@@ -143,11 +143,18 @@ await prisma.userData.upsert({
   create: { userId, key: "preferences", value: { theme: "dark" } },
 });
 
-// Store site-wide cache
+// Store a per-workspace setting.
+//
+// #6374 D3 — `SiteSetting` is keyed by (workspaceId, key), NOT by `key`
+// alone: `key` lost its global @unique so two workspaces may each hold a
+// `cached_config` row. `workspaceId` is resolved SERVER-SIDE (see
+// apps/api/src/lib/site.ts's `resolveWorkspaceIdForAlias`) and never read
+// from a request body — `site_settings.workspace_id` is NOT NULL with a
+// format CHECK, so a raw site alias is refused by Postgres.
 await prisma.siteSetting.upsert({
-  where: { key: "cached_config" },
+  where: { workspaceId_key: { workspaceId, key: "cached_config" } },
   update: { value: platformConfig },
-  create: { key: "cached_config", value: platformConfig },
+  create: { workspaceId, key: "cached_config", value: platformConfig },
 });
 ```