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

package/dist/template/deploy/catalog-cart-access.md

@@ -0,0 +1,35 @@
+<!-- Copyright (C) 2026 Tony Aly -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# Cart and wishlist access
+
+C5.20/C11.10 use the existing catalog service contracts for both human and API
+clients. A cart ID or contact ID is an identifier, not a credential.
+
+A guest opens a cart with `catalog.getOrCreateCart`. Keep the returned private
+`cart.token`; use it as `token` for `catalog.getCart`, and as `cartToken` for
+`addCartItem`, `setCartItemQuantity`, `removeCartItem`, `applyCouponToCart`,
+`quoteCartPromotions` and `listCartOffers`. When an ID and token are supplied,
+they must identify the same cart. A gallery's `galleries.addToCart` needs both
+its gallery session and the cart token; viewing a gallery grants no access to
+another person's basket. Closed carts cannot have their lines edited.
+
+Authenticated customers may use their session-linked contact's carts and
+wishlists. Saving a named cart or changing a wishlist requires that profile
+ownership or the relevant catalog management permission. A token for one
+basket does not authorize reading all saved carts or creating profile records.
+Public wishlist share links remain a separate, explicitly issued capability.
+
+Staff and API keys may use cart IDs when their exact catalog operation is
+authorized. Cart reads/list results return `token: null` for view-only staff
+and narrow read keys, so read access does not disclose a write capability.
+Scoped mutations also keep their returned tokens redacted unless the caller
+already supplied the token, owns the contact, or has full catalog management.
+The getOrCreateCart operation deliberately issues a cart capability for a
+guest or an authorized contact profile, including an existing open cart. Treat cart tokens as
+private credentials and never use them as display identifiers; admin screens
+use the cart ID instead.
+
+Existing guest API integrations that sent only cart IDs must now pass the
+matching token. Staff interfaces continue using their authenticated role.
+The generated SDK includes the optional token inputs and nullable read tokens.

package/dist/template/deploy/catalog-checkout-milestones.md

@@ -0,0 +1,56 @@
+<!-- Copyright (C) 2026 Tony Aly -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+# Catalog payment milestones
+
+The catalog module defaults to full payment. A business can configure exact
+checkout stages with `settings.setModuleConfig`. This is an instance setting;
+the browser never chooses the amount. Example for a CAD order with 50% due at
+checkout and 50% due before delivery:
+
+```json
+{
+  "module": "catalog",
+  "config": {
+    "checkoutPayment": {
+      "mode": "milestones",
+      "currency": "CAD",
+      "firstPayment": { "type": "percent", "sharePpm": 500000 },
+      "milestones": [
+        { "label": "Down payment at checkout", "sharePpm": 500000 },
+        { "label": "Remaining balance before delivery", "sharePpm": 500000 }
+      ]
+    },
+    "checkoutTerms": {
+      "version": "owner-approved-v1",
+      "title": "Purchase agreement",
+      "body": "Replace with the approved full purchase agreement.",
+      "href": "/terms"
+    }
+  }
+}
+```
+
+Publish the approved terms at the linked page before enabling checkout. Change
+the version whenever the terms body changes. Checkout compares both the
+rendered version and SHA-256 body hash, so an edit under the same version also
+invalidates an open form. It saves the actual body, hash, version, and
+acceptance time on the order. Existing orders retain their own snapshot.
+
+The invoice records the complete binding price. Percentage stages are computed
+from its final integer-minor total after tax, discounts, and shipping. Earlier
+stages round down; the last stage receives the exact remainder. The first
+stage is payable immediately. After that payment settles, the owner calls
+`catalog.releaseOrderPaymentMilestone` with `{ "orderId": "...", "position": 1 }`
+at the contractually agreed milestone, or uses **Release this payment** on the
+order's admin page. Only then can the customer open the
+next provider checkout. Further stages use increasing positions. The release
+service refuses out-of-order releases, unsettled prior payments, and active
+attempts. It does not invent due dates or collect later payments automatically.
+
+Provider callbacks settle on the original full-price invoice. The order moves
+to `partially_paid` after the first payment and to `paid` only when the full
+invoice settles. Digital fulfillment and shipping remain blocked while the
+order is partially paid. Cancellation refuses received money and active
+payment attempts; refunds use the normal invoice refund path.
+Hosted checkout attempts cannot be cancelled locally while the provider may
+still capture them. Reconcile the provider result before cancelling the order.

package/dist/template/deploy/ci-release-gate.md

@@ -0,0 +1,83 @@
+# CI and release gate
+
+Freeholder treats the `checks` job in `.github/workflows/ci.yml` as the single
+protected-branch fan-in. It succeeds only after application checks, security
+checks, all runtime-balanced isolated test shards, the ownership restore drill,
+browser tests, the customer-app export (iOS and Android against the demo
+contract, including store-asset and privacy-manifest gates), and the
+deployment recipe matrix have passed. Do not add a required check outside that
+fan-in without updating the branch-protection contract. Signed store binaries
+are a separate, skippable EAS workflow and are not a required check.
+
+GitHub treats a skipped required check as success. The fan-in job therefore
+uses `if: always()` and fails unless every needed job result is `success`.
+Without that, a failed shard skips `checks` and the merge queue can land the
+candidate: merge-group run `33993046449` failed `Tests (19/20)` and still
+merged #270. `pnpm workflow:check` rejects a `checks` job that can skip after
+a failed dependency.
+
+## Feedback objective
+
+The pull-request objective is a 95th-percentile failing-job result within 12
+minutes and a complete result within 35 minutes. Every job has a finite timeout.
+Review job duration monthly and after two timeout failures in seven days. Improve
+caching, fixture isolation, or shard balance when the objective regresses; never
+remove coverage or weaken an assertion to meet it.
+
+Each test shard owns a separate PostgreSQL service and database. The browser,
+ownership, and deployment jobs also use isolated services so concurrency cannot
+hide data coupling or make failures order-dependent.
+
+The shard topology has a checked degradation budget, not an arbitrary count.
+Run `33904651417` established the normal duration of a deterministic shard;
+run `33905822088` then placed that exact file list on a contended hosted runner,
+where representative database files slowed uniformly by as much as 6.7x. CI
+therefore partitions the suite across twenty-three databases and keeps a tested 7x
+work allowance plus fixed setup overhead below the unchanged 25-minute job
+limit. `tests/core/runtime-balanced-sequencer.test.ts` proves full, unique test
+coverage, bounded predicted skew, the degradation budget, and exact workflow
+topology. Refresh measured outliers and re-run that contract after a material
+test redesign; never increase the timeout merely to absorb an unexplained tail.
+
+The image gate also boots once against an unreachable database and requires
+process liveness to remain `200` while readiness is `503`, then boots normally
+and requires durable current-version worker evidence. This prevents a dependency
+outage from being converted into a restart loop.
+
+## Security evidence
+
+Every pull request, merge-group candidate and main-branch push runs a live
+registry advisory audit, secret-history scanning, and CodeQL; pull requests also
+run dependency review. TruffleHog receives the immutable event-specific base and
+head SHAs explicitly. This is required because its action does not infer a
+`merge_group` range and otherwise falls back to unrelated full-history findings.
+The live audit emits an attestation containing the exact lockfile and exception-
+ledger hashes. Scheduled security CI regenerates the same evidence and performs
+the deliberate full-history scan weekly instead of trusting a cache.
+
+Credential-shaped values used to prove redaction or URL rejection are assembled
+inside the test process. Deployment examples never ship a default database
+password: Compose requires a separately generated, URL-safe
+`POSTGRES_PASSWORD` before configuration interpolation can succeed.
+
+All third-party actions and CI service containers are pinned to immutable
+digests, and CI reads the exact Node version from `.node-version`.
+`pnpm workflow:check` enforces the action and service-container rules, rejects
+floating action-managed tool versions, and forbids `pull_request_target`
+workflows. Checkout credentials are never persisted for repository code, and
+the only job with `security-events: write` executes CodeQL actions—not project
+scripts or dependency lifecycle hooks.
+
+## Exact-artifact promotion
+
+On a successful push to `main`, CI builds one candidate image, pushes it by an
+immutable candidate tag, records its digest, and creates GitHub build-provenance
+evidence. Publication downloads the dependency and candidate evidence from that
+exact successful CI run, verifies the source SHA, audit freshness, image name,
+digest, and provenance, and then promotes the existing digest. It never rebuilds
+release source. The promoted digest is keylessly signed and receives an SPDX
+SBOM attestation.
+
+A `vMAJOR.MINOR.PATCH` tag, optionally with a SemVer prerelease suffix, is
+publishable only when the tagged commit already has a successful `main` push CI
+run. Failed or pull-request artifacts cannot enter the release path.

package/dist/template/deploy/client-readiness.md

@@ -0,0 +1,49 @@
+# Client deployment requirements
+
+Readiness repair, 2026-09-21 (MASTER.md C1.03, C1.05, C6.08, C6.11,
+C9.09, C9.12, C10.06, C10.10, C11.10).
+
+Before exposing a fresh production instance, configure an independent random
+`BOOTSTRAP_SECRET` of at least 32 characters in the deployment environment.
+Generate one with `openssl rand -hex 32`, store it privately, and enter it in
+the setup form. API setup callers supply `bootstrapSecret` alongside email and
+password. Keep it in private deployment settings for subsequent recipe deployments;
+existing users do not enter it at login. If you unset it, remove the variable
+entirely instead of leaving an empty value in the environment.
+Development and test instances without a configured secret retain local setup.
+
+The deployment examples and scaffold require this secret. Render generates it;
+retrieve it from the private environment settings before setup. The App Platform
+spec preparation script requires it. Never put the generated secret in Git.
+
+Public waitlist enrollment now returns only `{ "ok": true }`, including repeat
+requests. Read entry IDs and status through authenticated waitlist services.
+Referral touches may still use an anonymous visitor identifier, but binding a
+contact requires that contact's signed-in user or explicit referral write scope.
+
+Forms limit repeated validated submissions by signed-in user, explicitly trusted
+proxy address, validated email, or identical answers. Invalid answers do not
+consume another visitor's bucket. This application limit is not a network flood
+defense. Configure edge request limits for public endpoints. Only configure
+`TRUSTED_CLIENT_IP_HEADER` when the proxy overwrites the named header and direct
+access to the application is blocked. Supported headers are
+`x-freeholder-client-ip`, `cf-connecting-ip`, and `x-real-ip`. Client-supplied
+forwarding headers are not trusted by default.
+
+Free event registrations remain supported. Events with tickets require an active
+ticket belonging to that event. Paid registrations are currently refused before
+contact creation, reservation, or charging: payment settlement has not been
+integrated. Reconcile any existing paid-event confirmations made by older builds
+against actual payment records before admitting attendees.
+Legacy paid or invalid ticket registrations are also blocked from automatic
+promotion and check-in; verifying old payments does not enable the missing flow.
+
+Automatic apply and rollback are disabled. Use [the operator update procedure](update-apply.md).
+Previous update history and 64-byte snapshot fingerprints are not evidence of a
+backup, a completed deployment, or successful rollback. Do not delete them as
+part of this repair; retain them as historical records with that limitation.
+
+Before client launch, exercise the site's enabled workflows on staging and
+restore a real database backup into a separate database. Container/provider
+deployment, email delivery, payment settlement, and restore tests must use the
+actual target configuration. Local tests cannot certify those external systems.

package/dist/template/deploy/commerce-catalog.md

@@ -0,0 +1,119 @@
+# Commerce catalog operations
+
+Freeholder's `catalog` module owns the shared identity and lifecycle of every
+thing a business sells. Physical goods, downloads, services, rentals, bundles
+and passes are kinds of one Product; later option, price, inventory, booking and
+order records attach to that row instead of creating parallel catalogs.
+
+C5.09 established product lifecycle and the owner workspace. C5.10 adds reusable option dimensions and generated variant matrices. C5.11
+adds attributes, comparison and unlimited ordered media with variant swaps.
+C5.13 adds customer groups and currency-locked price lists. C5.12 adds
+relations and bundle quotes. C5.14 adds volume and tiered quantity breaks on
+the same resolver. C5.15 adds service offerings, cancellation policies,
+intake-form attachment and payment-mode rules on `service` products.
+Calendars, waiver templates and public product pages still arrive in C6 and
+C5.04/C2.21. C5.16 is the ledger at `/admin/inventory`. C5.17 is
+procurement at `/admin/procurement`. C5.18 is shipping quotes at
+`/admin/shipping`. C5.20 carts live at `/admin/carts`. C5.21 checkout and
+C5.22 orders live at `/admin/orders`; payment stays on the invoice.
+Shipments and returns are C5.19 at `/admin/fulfillment` and `/admin/returns`.
+Coupons, gift cards and cart offers are C5.23 at `/admin/promotions`.
+
+## Admin workspace
+
+Authorized staff use `/admin/products` to create reusable option types and
+values, assign dimensions to a product, preview the generated matrix, apply a
+reconciliation that archives unused combinations instead of deleting them, and
+choose a default variant.
+
+Authorized staff also use `/admin/products` to:
+
+- filter products by lifecycle, kind and visibility;
+- create drafts for all six product kinds;
+- edit the name, stable product address, subtitle, brand, visibility, tax
+  category and SEO overrides;
+- build the description from the same validated content blocks and real
+  responsive preview used by the CMS;
+- activate a tax-configured draft, archive without deletion, restore only to
+  draft, and read the append-only lifecycle history.
+
+The workspace is translated in English, French and Spanish. `catalog` view
+access reads products and history; `catalog` manage access performs mutations.
+Owners retain wildcard manage access, administrators receive catalog manage
+access, and the legacy staff compatibility role receives view access through
+the default-role seeding path. Custom roles can grant either level normally.
+
+Admin forms call `catalog.*` services. Generated HTTP and MCP projections use
+the same definitions, validation, permission checks, transactions, audit rows
+and events. No route writes product tables directly.
+
+## Lifecycle and visibility
+
+```text
+draft -> active -> archived
+  \-------> archived -> draft
+```
+
+- Every product begins as `draft` at version 1.
+- Activation requires an existing active tax category. This prevents an item
+  from becoming available with ambiguous tax treatment.
+- Archive is reversible but requires a reason. Archived products are read-only
+  until explicitly restored to draft.
+- Restore never jumps directly to active; the owner reviews and activates it
+  again.
+- The first publication timestamp survives archive/restore. Once first
+  activated, `kind` is immutable so orders, inventory and booking records can
+  never have their meaning changed underneath them.
+- Every write compares an expected integer version. Stale admin tabs, API
+  clients and agents receive a conflict rather than silently overwriting a
+  newer change. Description autosaves are serialized and advance the same
+  token.
+- Renaming the address after first activation records a permanent redirect from
+  `/products/<old>` to `/products/<new>` in the normal SEO redirect table.
+
+Visibility is independent of lifecycle:
+
+- `public`: included in the public catalog projection.
+- `unlisted`: omitted from lists but resolvable by its exact address.
+- `member_only`: resolvable only for an authenticated actor.
+
+Only active products reach any public projection. Draft and archived rows stay
+owner-visible only. The storefront routes themselves remain a later catalog/
+checkout milestone.
+
+## Data and migration
+
+Migration `0048_marvelous_morg.sql` adds:
+
+- `products`: normalized identity, kind, validated description blocks,
+  lifecycle/visibility, tax category, SEO, timestamps and optimistic version;
+- `product_lifecycle_events`: append-only actor, prior/resulting state,
+  visibility, version, reason and timestamp evidence.
+
+The database independently checks kind, status, visibility, schema type, slug,
+lifecycle timestamps and positive versions. Product slug is unique. Every
+foreign key and admin/public query pattern has a matching index.
+
+The migration is additive. Incident rollback is application-first: deploy the
+previous application and retain the catalog tables. Do not drop owner product
+content or lifecycle evidence. Backup/restore, ownership export and test cleanup
+discover both tables through the module manifest.
+
+## Verification
+
+Run the focused gate with a migrated test database:
+
+```sh
+pnpm exec vitest run tests/core/catalog.test.ts tests/core/i18n-gate.test.ts tests/core/registry-completeness.test.ts tests/core/roles.test.ts
+pnpm typecheck
+pnpm lint
+pnpm build
+pnpm test:journeys
+```
+
+The catalog suite proves all six kinds, visibility projections, activation
+interlocks, validated block vocabulary, post-publication kind immutability,
+redirect-safe renames, exact archive/restore history, permission boundaries,
+database checks and concurrent stale-write refusal. The Chromium journey uses
+the production standalone artifact and scans the product workspace for WCAG
+A/AA violations.

package/dist/template/deploy/commerce-money.md

@@ -0,0 +1,191 @@
+# Commerce money and tax foundation
+
+Freeholder's `invoicing` module is the single accounting spine for invoices,
+payments, refunds, credit notes, customer balances, payment plans, provider
+payouts, and the tax evidence attached to them. Catalog, checkout, booking,
+tips, subscriptions, and future plugins must call these
+services instead of creating parallel money records.
+
+This checkpoint does not claim a complete public storefront. It establishes
+the transaction-safe money path those surfaces use.
+
+## Money rules
+
+- Every amount is an integer in the currency's minor unit. Fractional quantities
+  use millionths (`quantityMicros`); extension and tax rounding use integer/
+  bigint arithmetic and reject unsafe JavaScript numbers.
+- Creation calls carry an idempotency key and a canonical request hash. Reusing
+  a key with the same request returns the original row; reusing it with changed
+  contents is a conflict.
+- Invoice and credit-note numbers are allocated inside the issuing transaction.
+  A failed transaction does not consume the number.
+- Invoice, payment, refund, and credit-note lifecycle changes append immutable
+  `money_state_events`, emit module events, and add contact timeline evidence
+  where the customer should see the consequence.
+- Payment settlement locks both payment and invoice, so competing successful
+  attempts cannot overpay. Refund creation reserves the refundable balance, and
+  settlement updates refund, payment, and invoice atomically.
+- Issued invoices are not edited. Adjustments use a numbered credit note;
+  returned money uses a refund tied to the successful payment.
+
+The current transitions are:
+
+```text
+invoice:     draft -> sent -> viewed/overdue/partially_paid -> paid -> refunded
+                    \-> void (only while unpaid)
+payment:     created -> processing -> succeeded
+                     \-> failed/cancelled
+refund:      created -> processing -> succeeded
+                     \-> failed/cancelled
+credit note: draft -> issued -> void
+payment plan: active <-> defaulted -> completed/cancelled
+payout:      pending -> in_transit -> paid
+                    \-> failed/cancelled
+```
+
+## Advanced terms and voluntary money
+
+- `invoicing.createDepositAndBalance` creates two normal invoices and links the
+  balance to its deposit. Each retains its own due date, tax evidence, number,
+  payments, and immutable issued total.
+- `invoicing.createPaymentPlan` requires installments to add up exactly to the
+  invoice's current outstanding balance. Successful partial payments allocate
+  oldest-due-first and may span installments. Refreshing a plan derives due and
+  default state from an explicit time; cancelling terms retains every prior
+  allocation.
+- `invoicing.createFlexiblePayment` validates a chosen amount against snapshotted
+  minimum/maximum terms, then creates a normal tip or pay-what-you-want invoice.
+  An attached invoice must have the same contact and currency.
+- `invoicing.assessLateFee` waits until the due date plus grace period, applies
+  fixed or integer-PPM percentage terms to the outstanding principal, honors a
+  cap, and creates a linked fee invoice. It never edits the overdue invoice.
+- Customer credit is held per contact and currency in an append-only balance
+  journal. Applying credit creates provider `balance` money in the normal
+  `Payment` table; refunding it uses the normal `Refund` table and restores the
+  credit atomically. The internal provider is not selectable as an external
+  checkout adapter.
+- Contact merge combines same-currency credit without losing entries, and exact
+  undo restores both accounts if neither changed after the merge. Privacy export
+  includes advanced terms and movements; erasure redacts free text while
+  retaining required accounting amounts and links.
+
+## Operator workspace
+
+`/admin/invoices` lists, filters and reconciles invoices. `/admin/invoices/new`
+creates a draft through `invoicing.createDraft`. The invoice detail issues,
+voids, credits and shows immutable tax lines, payments and receipts. Tax
+configuration lives at `/admin/invoices/tax`: dated starters, categories,
+zones, rates, registrations (collection stays off until the starter limitation
+is acknowledged), exemptions and threshold progress. Contact records with
+invoicing access show that contact's invoices. These screens call the same
+services as HTTP and MCP.
+
+## Tax setup
+
+1. Call `invoicing.listTaxTemplates` and show the source, verification date, and
+   activation limitation to the owner. The tax studio at `/admin/invoices/tax`
+   does this.
+2. Call `invoicing.installTaxTemplate`. Installation is idempotent and creates
+   its zone, rates, and registration in `monitoring`; it never starts collecting
+   tax.
+3. Add or adjust `TaxCategory` and category-specific `TaxRate` rows for what the
+   business actually sells. An exact category row replaces the same generic
+   named jurisdiction rate, so a zero-rate category does not stack with it.
+4. Configure the registration number, collection date, and any monetary
+   threshold. A non-zero threshold must state its currency.
+5. Review the template limitation and activate with
+   `acknowledgeTemplateLimitations: true`. That acknowledgement is included in
+   the normal mutation audit record.
+6. Quote with origin and destination. Matching is country first, then postal/
+   region specificity, explicit priority, and stable name order. No locale or
+   translated URL participates in tax location.
+
+The catalog contains 13 Canadian province/territory starters, 27 EU member
+standard-VAT starters, UK VAT, Australian GST, New Zealand GST, and 51 US state/
+DC base-rate starters. Definitions are versioned and source-attributed in
+`src/modules/invoicing/tax-templates.ts`.
+
+All starters deliberately interlock activation because a standard rate is not
+the same as a complete tax decision. Reduced/exempt categories, place of
+supply, shipping, thresholds, and business facts still require review. US rows
+are especially limited: state base rates do not include county/city rates or
+address-level taxability. Add explicit local zones for the handful of places a
+business sells into, or use a later tax adapter before enabling broad US sales.
+
+## Calculation and evidence
+
+- Rates use integer parts per million, not basis points. This represents rates
+  such as Quebec's 9.975% exactly as `99_750`.
+- Zones choose line or invoice rounding, half-up or bankers rounding, and
+  inclusive or exclusive source prices.
+- Sequential compound rates operate on prior tax. Inclusive compound regimes
+  are refused by the built-in engine because reverse extraction is ambiguous
+  without jurisdiction-specific rules.
+- Shipping is a separate taxable subject. Each rate states whether it applies.
+- A validated, unexpired exemption produces explicit zero `TaxLine` rows and a
+  required invoice legend; reverse-charge wording is retained.
+- Every calculated draft snapshots rate name, rate PPM, taxable amount, tax
+  amount, jurisdiction, registration number, inclusion/compound flags, order,
+  exemption kind, and a plain-language explanation. Later rate edits do not
+  change that evidence.
+- A matching zone without an active registration returns zero with an explicit
+  explanation. The invoice stores that explanation instead of silently
+  presenting tax as zero.
+
+`invoicing.taxThresholds` reports issued gross sales, refunds, net sales,
+transaction count, remaining amount, and parts-per-million progress for each
+registration. It never combines currencies. The configured currency drives the
+threshold state, while excluded currency totals remain visible. The report uses
+gross issued sales for a conservative signal and presents refunds/counts
+separately because legal threshold definitions vary.
+
+`invoicing.receipt` returns a stable receipt number, customer, successful
+payment reference, invoice lines, immutable tax lines, and settled refunds.
+`invoicing.reconciliation` independently sums successful payments and refunds
+against the stored invoice/payment balances and names every discrepancy.
+`invoicing.reconcileAdvancedMoney` independently checks customer journal sums,
+payment allocations, and reconciled payout nets. Provider operations expose
+unsettled checkouts, disputes, unmatched statement lines, payout deposits, and
+authenticated webhook receipts together.
+
+## Access and provider boundaries
+
+All services are `scoped` under the `invoicing` module. Owners and administrators
+receive manage access; bookkeepers receive invoicing manage access; customers
+receive none by default. Generated HTTP API and MCP projections come from the
+same service registry. Checkout will call the quote/create services through a
+purpose-built public boundary rather than granting anonymous callers arbitrary
+tax-exemption or money mutations.
+
+Payment-provider code remains behind `src/adapters/payments`. The disabled
+adapter cannot fabricate checkout URLs, provider references, webhooks, or
+refunds. Stripe, PayPal, manual/offline orchestration, receipt PDF/archive
+rendering, and provider reconciliation remain subsequent C5 checkpoints.
+
+## Migration and verification
+
+The additive migrations are:
+
+- `0043_worried_shaman.sql`: normalized tax and money tables, constraints,
+  indexes, and foreign keys.
+- `0044_nervous_maelstrom.sql`: tax-zone attribution on invoices and
+  currency-safe registration thresholds.
+- `0045_peaceful_puck.sql`: database enforcement that a valid exemption has
+  validation evidence.
+- `0046_right_swordsman.sql`: provider customers, methods, disputes, and
+  authenticated event receipts.
+- `0047_fantastic_miss_america.sql`: balances, plans/allocations, voluntary
+  payment terms, late-fee evidence, and provider payout reconciliation.
+
+After deployment, migrate normally and verify with:
+
+```sh
+pnpm exec vitest run tests/core/money-arithmetic.test.ts tests/core/invoicing.test.ts tests/core/advanced-money.test.ts
+pnpm typecheck
+pnpm lint
+```
+
+Rollback is application-first: deploy the prior application while leaving the
+additive tables in place. Do not drop money or tax evidence during an incident.
+Backup/restore and ownership export discover these tables through the module
+manifest.