create-ailk 0.4.0 → 0.6.0

package/templates/database/migrations/20260923120000_listing_capturing_magnet/migration.sql

@@ -0,0 +1,210 @@
+-- #6314 — ProjectListing gains `captured_by_flow_id`: the listicle-kind
+-- FlowDefinition that CAPTURED the application, so a magnet's own
+-- Applications list can be scoped to its own submissions rather than to the
+-- whole workspace. Nothing constrains a workspace to one listicle magnet
+-- ("flow_definitions" carries a (site_id, slug) unique and no
+-- (site_id, kind) one), so workspace-only scoping would silently conflate
+-- two listicle magnets' applications.
+--
+-- A NEW MIGRATION DIRECTORY, not an amendment of the already-merged
+-- 20260922120000_tenancy_fence (spec D8). #6254 AC-1's one-migration-per-
+-- milestone rule names #6314 by number in that migration's own header, so
+-- this is a DEPARTURE taken deliberately and with the operator's
+-- confirmation (2026-09-20), not a gap that rule failed to cover. Two
+-- reasons, in order of weight:
+--   1. Prisma records a per-migration CHECKSUM. `prisma migrate deploy`
+--      refuses a migration whose file no longer matches `_prisma_migrations`,
+--      so a database that already applied the fence directory would never
+--      receive this column or its index while the new code assumes both.
+--      "Editing it in place is a silent no-op" is true of the SQL; it is not
+--      true of the checksum.
+--   2. apps/api/CLAUDE.md: "Never edit a shipped migration — add a new one."
+--      Where a spec's convenience and an in-repo rule disagree, the rule wins.
+--
+-- PURELY ADDITIVE: one nullable column, one index. NO UPDATE, NO backfill,
+-- and NO foreign key.
+--
+-- NO BACKFILL, deliberately (spec § 3.5 / AC-3, operator ruling 2026-09-19).
+-- No existing row carries evidence naming the magnet that captured it — no
+-- referrer, no session link, no slug. A backfill would have to guess "the
+-- workspace's only listicle magnet", which is exactly the conflation this
+-- column exists to remove, made permanent and unauditable. Every row written
+-- before this migration therefore reads NULL for the life of the row:
+-- unattributed, excluded from every per-magnet list (NULL never equals a
+-- magnet id, so the exclusion is a property of the query, not a filter that
+-- can be forgotten), and UNCHANGED in the workspace Inbox — no operator loses
+-- access to any application. This is the same discipline the founder-name
+-- parts (#5407), the address parts (#5279) and `owner_user_id` (#5295) each
+-- follow: a value that can only be guessed must not be asserted.
+--
+-- NO foreign key, deliberately (spec § 3.2, operator decision 2026-09-20,
+-- which withdrew the 2026-09-19 ruling's "on-delete set-null" clause). Both
+-- models live in the `inbox` namespace, so ADR 0009 invariant #1 (which bans
+-- CROSS-namespace relations) does not reach this column — permission was
+-- never the question. The convention is: of the 24 foreign-key constraints
+-- under database/migrations/**, every one targets the `auth` namespace
+-- ("users"); the intra-inbox columns listing_id, lead_id, grant_id and
+-- flow_session_id carry none. The composite (workspace_id, …) shape was
+-- itself offered and declined on "listing_csv_sends" the day before this
+-- spec's pin. Integrity rests on the server-side resolve in
+-- `startProjectListingDraft` (site_id + workspace_id + kind = 'listicle')
+-- and on the read carrying the injected workspace_id alongside the magnet id
+-- — so a dangling or foreign value yields no rows, never another workspace's.
+-- Nothing deletes a flow_definitions row either (routes/magnets D5: "No
+-- DELETE"), so ON DELETE SET NULL would have described no live code path.
+--
+-- RE-RUNNABLE: IF NOT EXISTS on both DDL statements, the census temp table is
+-- dropped-if-exists before it is built, and post-assertion 2 is skipped on a
+-- re-apply (it proves this file grew no backfill, which only the first
+-- application can show — see its own comment). So re-applying this directory
+-- against a database that already has the column is inert rather than an abort
+-- that would wedge the ledger.
+--
+-- ORDER-SAFE: the index references "workspace_id", added by
+-- 20260919140000_inbox_workspace_key and made NOT NULL by
+-- 20260922120000_tenancy_fence — both of which this migration sorts strictly
+-- after. The guard below is therefore a formality in the normal case, kept
+-- for the reason 20260920130000_lead_workspace_source_index keeps one: IF NOT
+-- EXISTS guards the INDEX's own name, not the column it references, so an
+-- unguarded CREATE INDEX would abort inside prisma migrate's per-migration
+-- transaction and wedge the ledger for the whole deployment if that earlier
+-- migration were ever skipped, renamed, or rolled back on a given database.
+--
+-- CREATE INDEX is NOT CONCURRENT, and cannot be: CONCURRENTLY may not run
+-- inside prisma migrate's per-migration transaction. It therefore takes a
+-- lock on "project_listings" for its duration — the same accepted risk
+-- 20260920130000_lead_workspace_source_index names. A deployment with a large
+-- project_listings table should create this index out-of-band with
+-- CONCURRENTLY first; the IF NOT EXISTS guard then makes the statement a
+-- no-op.
+--
+-- Rollback:
+--   DROP INDEX "project_listings_workspace_id_captured_by_flow_id_idx";
+--   ALTER TABLE "project_listings" DROP COLUMN "captured_by_flow_id";
+-- Safe at any point: the column is nullable and unconstrained, and no row's
+-- correctness depends on it beyond per-magnet attribution.
+
+-- A census, so the post-assertions below can prove nothing moved.
+--
+-- `column_preexisted` is captured HERE, before the ALTER, and it is what keeps
+-- assertion 2 honest on a RE-APPLY. That assertion proves a property of THIS
+-- FILE (it performs no backfill), which is only observable on the application
+-- that first adds the column: once the application has written even one real
+-- attribution, "no row is attributed" is false for reasons this migration had
+-- nothing to do with. Asserting it unconditionally would abort inside prisma
+-- migrate's per-migration transaction and wedge the ledger for every later
+-- migration on that database — on a restored snapshot, a `migrate resolve
+-- --rolled-back` redeploy, or a branch of production.
+-- `pg_temp.`-qualified: DROP TABLE does not distinguish temporary from
+-- permanent relations, and at this point the session holds no temp table, so
+-- an unqualified name would resolve through search_path to `public` and drop
+-- a same-named PERMANENT table — inside the transaction prisma commits.
+DROP TABLE IF EXISTS pg_temp."_6314_capture_census";
+CREATE TEMP TABLE "_6314_capture_census" AS
+  SELECT
+    count(*) AS p,
+    EXISTS (
+      SELECT 1 FROM information_schema.columns
+       -- `table_schema = current_schema()` is load-bearing, not tidiness:
+       -- `information_schema.columns` spans EVERY schema in the database, so
+       -- without it the probe answers "does any table anywhere named
+       -- project_listings carry this column" rather than "does the table this
+       -- migration is about to alter carry it". A pre-migration snapshot in a
+       -- side schema (`CREATE TABLE backup.project_listings AS SELECT ...`, a
+       -- `pg_dump -n` restore) would then make a genuine FIRST apply take the
+       -- skip branch below and wave a real backfill through unchecked — the
+       -- exact AC-8 property assertion 2 exists to prove.
+       WHERE table_schema = current_schema()
+         AND table_name = 'project_listings'
+         AND column_name = 'captured_by_flow_id'
+    ) AS column_preexisted
+  FROM "project_listings";
+
+-- AlterTable — the capturing magnet's id. Nullable and unconstrained, so a
+-- row predating this migration reads NULL and nothing here can reject it.
+ALTER TABLE "project_listings" ADD COLUMN IF NOT EXISTS "captured_by_flow_id" TEXT;
+
+-- CreateIndex — the read is workspace_id = $1 AND captured_by_flow_id = $2,
+-- ordered by created_at desc. A two-column (workspace_id, captured_by_flow_id)
+-- index serves it directly. With no foreign key there is no cascade, so no
+-- referencing-side index is owed beyond this one.
+DO $$ BEGIN
+  IF EXISTS (
+    SELECT 1 FROM information_schema.columns
+     -- `table_schema = current_schema()` for the same reason the census probe
+     -- above carries it, and the failure direction here is WORSE. A decoy
+     -- `project_listings` in another schema makes this EXISTS spuriously true;
+     -- the CREATE INDEX below then runs against the table search_path actually
+     -- resolves, hits `column "workspace_id" does not exist`, and aborts the
+     -- whole migration transaction — a wedged ledger, where the census probe's
+     -- equivalent merely skips an assertion. The guard must ask about the table
+     -- the statement it protects will really touch.
+     WHERE table_schema = current_schema()
+       AND table_name = 'project_listings'
+       AND column_name = 'workspace_id'
+  ) THEN
+    CREATE INDEX IF NOT EXISTS "project_listings_workspace_id_captured_by_flow_id_idx"
+      ON "project_listings"("workspace_id", "captured_by_flow_id");
+  ELSE
+    RAISE NOTICE '#6314: project_listings.workspace_id absent — index skipped. 20260919140000_inbox_workspace_key has not run against this database; the per-magnet Applications read cannot be served efficiently until it does.';
+  END IF;
+END $$;
+
+-- Post-assertions, in 20260922120000_tenancy_fence's own idiom.
+DO $$
+DECLARE
+  before_p bigint;
+  after_p  bigint;
+  attributed bigint;
+  preexisted boolean;
+BEGIN
+  SELECT p, column_preexisted INTO before_p, preexisted FROM "_6314_capture_census";
+  SELECT count(*) INTO after_p FROM "project_listings";
+
+  -- 1. Nothing LOST. Deliberately `<`, not `<>`.
+  --
+  --    An equality test here has no true-positive mode and one guaranteed
+  --    false-positive mode, which is the worst shape a guard can have. No
+  --    statement in this file modifies a row of "project_listings" (the whole
+  --    file is five statements; read them), so the two counts can only diverge
+  --    through a write committed by ANOTHER session between them. The census
+  --    takes ACCESS SHARE; the ALTER takes ACCESS EXCLUSIVE, and until it does,
+  --    the table stays open to writers. "project_listings" is written by an
+  --    ANONYMOUS, unauthenticated route, so on a live deploy one application
+  --    started mid-migration aborts the migration — and the retry meets the
+  --    same race. That is a wedged ledger caused by the system working
+  --    normally.
+  --
+  --    `<` keeps the property the assertion is actually for — this migration
+  --    must never destroy a row — while letting a concurrent INSERT through.
+  --    A DELETE or TRUNCATE creeping into this file still trips it.
+  IF after_p < before_p THEN
+    RAISE EXCEPTION
+      '#6314 post-assertion: project_listings LOST row(s) across a purely additive migration (% -> %)',
+      before_p, after_p;
+  END IF;
+
+  -- 2. Nothing guessed (AC-8): every PRE-EXISTING row reads NULL. This
+  --    migration performs no UPDATE, so a non-NULL row on the application that
+  --    first adds the column would mean the file grew a backfill the ruling
+  --    refused.
+  --
+  --    Skipped when the column already existed: on a re-apply, attributed rows
+  --    are the APPLICATION's own writes, not a backfill, and failing on them
+  --    would wedge the migration ledger (see the census above). The assertion
+  --    still fires where it can mean anything — the first application, which is
+  --    the only run that can introduce a backfill.
+  IF preexisted THEN
+    RAISE NOTICE '#6314 post-assertion 2 skipped: captured_by_flow_id already existed, so this is a re-apply and any attributed row is an application write rather than a backfill.';
+  ELSE
+    SELECT count(*) INTO attributed
+      FROM "project_listings" WHERE "captured_by_flow_id" IS NOT NULL;
+    IF attributed <> 0 THEN
+      RAISE EXCEPTION
+        '#6314 post-assertion: % project_listings row(s) carry a captured_by_flow_id after a migration that performs no UPDATE — existing rows must stay unattributed (no backfill by guess)',
+        attributed;
+    END IF;
+  END IF;
+END $$;
+
+DROP TABLE pg_temp."_6314_capture_census";

package/templates/database/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@working-theory/database",
-  "version": "0.23.0",
+  "version": "0.25.0",
   "license": "Apache-2.0",
   "publishConfig": {
     "access": "public"
@@ -50,7 +50,7 @@
     }
   },
   "scripts": {
-    "lint": "tsx ../scripts/lint-package.ts",
+    "lint": "eslint .",
     "build": "tsc -b tsconfig.build.json && tsc -b tsconfig.tenancy.json && tsc -b tsconfig.flows.json",
     "db:generate": "prisma generate && pnpm run build",
     "db:migrate": "prisma migrate dev",
@@ -78,6 +78,10 @@
     "prisma": "^7.8.0",
     "ts-jest": "^29.4.11",
     "tsx": "^4.22.4",
-    "typescript": "^6.0.3"
+    "typescript": "^6.0.3",
+    "eslint": "^10.6.0",
+    "@eslint/js": "^10.0.1",
+    "globals": "^17.7.0",
+    "typescript-eslint": "^8.62.1"
   }
 }

package/templates/database/seed.ts

@@ -104,7 +104,7 @@ async function main(): Promise<void> {
   // Dynamic imports: the generated client + adapter are constructed only when
   // this module actually runs as the seed entrypoint — never at import time
   // (spec §5.2 Quality Constraints), matching the DI note on seed-test.ts's
-  // sibling and the lazy-require pattern in apps-paid/workspace/auth.ts.
+  // sibling and the lazy-require pattern in apps-paid/admin/auth.ts.
   const [{ PrismaClient: RealPrismaClient }, { PrismaPg }] = await Promise.all([
     import("./generated/client/client.js"),
     import("@prisma/adapter-pg"),

package/templates/database/tenancy.ts

@@ -22,7 +22,7 @@
 // that predicate, never a hardcoded literal. They carry the branded `Id<E>`
 // types so consumers get compile-time entity safety (ADR-0031 rule 5).
 
-import type { Id } from "@working-theory/ids";
+import { isSentinel, type Id } from "@working-theory/ids";
 
 /** Well-known default Organization identity — a fixed reserved-range sentinel. */
 export const DEFAULT_ORG_ID =
@@ -43,3 +43,88 @@ export const DEFAULT_WORKSPACE_SLUG = "default";
  */
 export const OPERATOR_MEMBERSHIP_ID =
   "member_00000000-0000-7000-8000-000000000001" as Id<"membership">;
+
+/**
+ * The minimal structural client the one-workspace predicate needs — no
+ * `@prisma/client` import, so this file stays a leaf `tsconfig.tenancy.json`
+ * can build without the generated client (#5876 spec D2). `apps/api` and
+ * `apps/mcp` are both `database`-importers (`architecture.yaml`
+ * `may_import_from`), and `database/**` is already wholesale-excluded from
+ * the tenant-scope `forbidden_pattern` — the only file this predicate could
+ * live in without widening that security allowlist.
+ */
+export interface WorkspacePredicateClient {
+  workspace: {
+    count(): Promise<number>;
+    findUnique(args: {
+      where: { id: string };
+    }): Promise<{ organizationId: string } | null>;
+  };
+}
+
+/**
+ * The one-workspace deployment predicate (#5876 spec D2), shared by every
+ * caller across the package boundary: `workspace.count() !== 1 ⇒ null`, then
+ * the sole workspace must be the well-known default AND hang off a sentinel
+ * Organization, or the deployment is not unambiguously single-tenant.
+ *
+ * Returns the **row** (`{ id, organizationId }`), not a projection — a
+ * caller that needs `organizationId` (as `resolveDefaultTenant` in
+ * `apps/api/src/services/default-tenant.ts` does) would otherwise have to
+ * run a second `findUnique`, which is the second-predicate drift NFR-7
+ * forbids. A caller that only needs the id projects `.id` itself.
+ *
+ * Carries no authentication — it answers "is this deployment one-workspace,
+ * and which workspace is it," nothing about the caller.
+ */
+export async function resolveDefaultWorkspaceRow(
+  prisma: WorkspacePredicateClient,
+): Promise<{ id: Id<"workspace">; organizationId: string } | null> {
+  const workspaceCount = await prisma.workspace.count();
+  if (workspaceCount !== 1) {
+    return null;
+  }
+  const workspace = await prisma.workspace.findUnique({
+    where: { id: DEFAULT_WORKSPACE_ID },
+  });
+  // The default workspace must hang off the sentinel default Organization
+  // (ADR-0031 rule 7): keyed on the reserved-range predicate, not a literal.
+  if (!workspace || !isSentinel(workspace.organizationId)) {
+    return null;
+  }
+  return { id: DEFAULT_WORKSPACE_ID, organizationId: workspace.organizationId };
+}
+
+/**
+ * The sentinel-EXISTENCE predicate (#6155 spec D2 rule 2), a SIBLING of
+ * {@link resolveDefaultWorkspaceRow}, not a replacement for it: it answers
+ * "does the well-known default workspace exist", never "is this deployment
+ * unambiguously single-tenant" — so it carries NO `workspace.count()` gate.
+ *
+ * The two questions coincide on a one-workspace deployment and diverge on a
+ * correctly-configured MULTI-workspace one: there,
+ * `resolveDefaultWorkspaceRow`'s count gate returns `null` even though the
+ * seeded sentinel workspace is present and resolvable. The site-alias
+ * resolver (`apps/api/src/lib/site.ts`) needs the sentinel-existence answer
+ * — the literal alias `"default"` names the seeded sentinel workspace on
+ * EVERY database, single- or multi-tenant (`database/seed.ts` upserts it
+ * unconditionally) — so it calls this function, not
+ * `resolveDefaultWorkspaceRow`.
+ *
+ * `resolveDefaultWorkspaceRow` is deliberately NOT modified or loosened:
+ * `resolveDefaultTenant` (`apps/api/src/services/default-tenant.ts`) depends
+ * on its single-tenancy meaning, so widening it would silently widen
+ * single-tenant detection for callers that are correct today. One function,
+ * one question.
+ */
+export async function resolveSentinelWorkspaceRow(
+  prisma: WorkspacePredicateClient,
+): Promise<{ id: Id<"workspace">; organizationId: string } | null> {
+  const workspace = await prisma.workspace.findUnique({
+    where: { id: DEFAULT_WORKSPACE_ID },
+  });
+  if (!workspace || !isSentinel(workspace.organizationId)) {
+    return null;
+  }
+  return { id: DEFAULT_WORKSPACE_ID, organizationId: workspace.organizationId };
+}

package/templates/database/tsconfig.json

@@ -10,6 +10,7 @@
     "seed.ts",
     "seed-test.ts",
     "tenancy.ts",
+    "__tests__/fixtures/appointment-create-probe.ts",
     "flows/**/*.ts"
   ]
 }

package/templates/package.json

@@ -45,10 +45,8 @@
     "globals": "^17.7.0",
     "gray-matter": "^4.0.3",
     "http-server": "^14.1.1",
-    "husky": "^9.1.7",
     "jest": "^30.4.2",
     "jiti": "^2.4.2",
-    "lint-staged": "^15.3.0",
     "prettier": "^3.9.4",
     "ts-declaration-location": "^1.0.7",
     "ts-jest": "^29.4.11",
@@ -60,18 +58,7 @@
     "yaml": "^2.9.0",
     "zod": "^4.2.1",
     "zod-to-ts": "^2.1.0",
-    "@working-theory/cli": "^0.23.0"
-  },
-  "lint-staged": {
-    "*.{ts,tsx}": [
-      "eslint --fix --cache"
-    ],
-    "*.{js,jsx,json,md,mdx,yaml,yml,css,scss,html}": [
-      "prettier --write"
-    ],
-    "{apps,packages,database}/**": [
-      "bash -c 'pnpm architecture'"
-    ]
+    "@working-theory/cli": "workspace:*"
   },
   "packageManager": "pnpm@10.34.5+sha512.a4ee05f2f73658255bd6a89859c065a45c28a57daefae2c893a168ee2b73168c37b91e83e57ea67654ad03f03031746430e8bce38e362e042605fb8abc80192e",
   "engines": {

package/versions.json

@@ -0,0 +1,52 @@
+{
+  "@working-theory/admin-ui": "0.25.0",
+  "@working-theory/aeo": "0.25.0",
+  "@working-theory/agent-context": "0.25.0",
+  "@working-theory/agent-contract": "0.1.0",
+  "@working-theory/agent-memory": "0.0.0",
+  "@working-theory/ai": "0.1.0",
+  "@working-theory/analytics": "0.25.0",
+  "@working-theory/api-client": "0.25.0",
+  "@working-theory/cda-filesystem": "0.0.0",
+  "@working-theory/cli": "0.25.0",
+  "@working-theory/common": "0.25.0",
+  "@working-theory/consent": "0.1.0",
+  "@working-theory/content-adapters": "0.25.0",
+  "@working-theory/content-projection": "0.25.0",
+  "@working-theory/email": "0.25.0",
+  "@working-theory/env": "0.0.0",
+  "@working-theory/eslint-config": "0.25.0",
+  "@working-theory/fumadocs-schema": "0.25.0",
+  "@working-theory/ids": "0.8.0",
+  "@working-theory/jsonld": "0.25.0",
+  "@working-theory/license": "0.25.0",
+  "@working-theory/metadata": "0.25.0",
+  "@working-theory/observability": "0.25.0",
+  "@working-theory/page-renderer": "0.25.0",
+  "@working-theory/schema": "0.25.0",
+  "@working-theory/schema-pack-registry": "0.25.0",
+  "@working-theory/schema-validator": "0.25.0",
+  "@working-theory/sections-registry": "0.25.0",
+  "@working-theory/site-config": "0.25.0",
+  "@working-theory/stripe-client": "0.25.0",
+  "@working-theory/templates": "0.25.0",
+  "@working-theory/theme": "0.25.0",
+  "@working-theory/ui": "0.25.0",
+  "@working-theory/validation": "0.25.0",
+  "@working-theory/web-i18n": "0.25.0",
+  "@working-theory/billing-client": "0.0.0",
+  "@working-theory/branding": "0.0.0",
+  "@working-theory/license-client": "0.0.0",
+  "@working-theory/license-manifest": "0.0.0",
+  "@working-theory/marketing-api-client": "0.0.0",
+  "@working-theory/partner-session": "0.0.0",
+  "@working-theory/preview-protocol": "0.0.0",
+  "@working-theory/ui-commerce": "0.23.2",
+  "@working-theory/ui-docs-blog": "0.23.2",
+  "@working-theory/ui-scheduling": "0.23.2",
+  "@working-theory/ui-signal-collectors": "0.24.0",
+  "@working-theory/web": "0.0.0",
+  "@working-theory/api": "1.0.0",
+  "@working-theory/mcp": "0.0.0",
+  "@working-theory/database": "0.25.0"
+}

package/site-templates/marketing-site-free/content/en/Pricing/pricing.mdx

@@ -1,103 +0,0 @@
----
-type: "Pricing"
-slug: "pricing"
-title: "Pricing"
-description: "Replace this with one sentence naming how Your Company charges — the unit, the range, and what moves the number. It is the description answer engines quote."
-sections:
-  [
-    {
-      "id": "hero",
-      "type": "hero",
-      "data":
-        {
-          "headline": "Pricing",
-          "subheadline": "Replace this with the one thing a buyer most needs to know about what they will pay.",
-        },
-    },
-    {
-      "id": "plans",
-      "type": "pricing",
-      "data":
-        {
-          "headline": "Replace these plans with your own",
-          "description": "Three placeholder plans. Rename them, set real prices, and list what each one actually includes. Delete any plan you do not offer — an empty tier is worse than one fewer.",
-          "plans":
-            [
-              {
-                "name": "Plan one",
-                "description": "Replace this with who this plan is for.",
-                "price": { "custom": "Your price" },
-                "features":
-                  [
-                    "Replace this line with something the plan includes.",
-                    "One line per included thing.",
-                    "Name the limit, not just the feature.",
-                  ],
-                "cta": { "label": "Get in touch", "href": "/contact" },
-              },
-              {
-                "name": "Plan two",
-                "description": "Replace this with who this plan is for.",
-                "price": { "custom": "Your price" },
-                "features":
-                  [
-                    "Everything in plan one.",
-                    "Replace this line with what the step up buys.",
-                    "Say the number when there is one.",
-                  ],
-                "cta": { "label": "Get in touch", "href": "/contact" },
-                "highlighted": true,
-              },
-              {
-                "name": "Plan three",
-                "description": "Replace this with who this plan is for.",
-                "price": { "custom": "Let's talk" },
-                "features":
-                  [
-                    "Everything in plan two.",
-                    "Replace this line with the work you quote per engagement.",
-                    "Scope, not adjectives.",
-                  ],
-                "cta":
-                  {
-                    "label": "Book a call",
-                    "href": "/contact",
-                    "variant": "outline",
-                  },
-              },
-            ],
-        },
-    },
-    {
-      "id": "pricing-faq",
-      "type": "faq",
-      "data":
-        {
-          "headline": "Pricing questions",
-          "items":
-            [
-              {
-                "question": "Replace this with the pricing question you are actually asked.",
-                "answer": "Answer it in the first sentence, with the number in it. A pricing answer that opens with context is the one buyers stop reading.",
-              },
-              {
-                "question": "What happens when the scope changes?",
-                "answer": "Replace this with how you handle a change in scope — who decides, how it is priced, and when the new price starts. Say it plainly here and you will not have to say it awkwardly later.",
-              },
-            ],
-        },
-    },
-    {
-      "id": "cta",
-      "type": "cta",
-      "data":
-        {
-          "headline": "Not sure which plan fits?",
-          "description": "Replace this with an invitation to the conversation you actually want to have.",
-          "primaryCta": { "label": "Get in touch", "href": "/contact" },
-        },
-    },
-  ]
----
-
-{/* Rendered from frontmatter `sections[]`. Seed content — replace the plan names, prices and features above with your own before you launch. */}