qubu 0.6.2 → 0.6.3

package/docs/guides/mutations.md

@@ -1,6 +1,6 @@
 # Write mutations
 
-> Build typed `INSERT`, `UPDATE`, and `DELETE` statements from the same table metadata while keeping destructive operations explicit.
+> Insert, update, and delete rows with typed inputs and explicit safeguards.
 
 ## Define write-time rules
 
@@ -121,6 +121,8 @@ const query = update(
 The assignment expression is source-aware, so a column from an unrelated table
 cannot silently enter the update.
 
+### Update from another source
+
 PostgreSQL updates can introduce one or more typed sources with `updateFrom()`.
 Those sources are available to assignments, the predicate, and `RETURNING`:
 
@@ -153,6 +155,8 @@ with the default, SQLite, or MySQL dialect is rejected. Qubu still requires a
 predicate or an explicit `allowAll()` marker; introducing a source does not
 authorize an unrestricted update.
 
+### Omit an assignment at runtime
+
 Use `omit` for a runtime-conditional assignment. Qubu removes omitted fields
 before validating and rendering the effective assignment set:
 
@@ -171,7 +175,9 @@ const query = update(
 
 `omit` means that the column is absent from `SET`. It is distinct from `null`
 and explicit `undefined`, which remain bound assignment values, and it does not
-emit SQL `DEFAULT`. At least one assignment must remain; `update()` throws
+emit SQL `DEFAULT`.
+
+At least one assignment must remain; `update()` throws
 before rendering when every field is omitted. Possible expression branches
 remain source- and capability-aware even when their runtime alternative is
 `omit`.
@@ -237,11 +243,14 @@ unrestricted operation is intended.
 
 ## Return typed rows
 
-`returning()` uses the same named object projection as `SELECT`. Reserve
-`{ ...all(table) }` for the intentional contract of returning every table
-column. When present, the mutation's `row` type is inferred from that projection, so
+`returning()` uses the same named object projection as `SELECT`. Use
+`{ ...all(table) }` when you want every table column.
+
+The mutation’s `row` type is inferred from that projection, so
 `(await db.execute(query)).rows` has the same shape as a read query when `db`
-comes from `qubu(adapter)`. The projection's SQL semantic domains are
+comes from `qubu(adapter)`.
+
+The projection’s SQL semantic domains are
 retained too, so a returned query used by typed composition does not collapse
 UUID, text, numeric, or other known fields to their JavaScript types alone.
 

package/docs/guides/select/conditions.md

@@ -1,7 +1,6 @@
 # Add optional conditions
 
-> Keep optional predicates, null checks, and empty-list behavior explicit while
-> the query keeps the same structural shape.
+> Add or omit conditions at runtime, and handle NULL values and empty lists.
 
 The examples use the `users` table from [Build a `SELECT`](overview.md).
 
@@ -65,15 +64,23 @@ Here `omit` affects only whether `email` belongs to the projection. It does
 not make the expression nullable: a non-nullable expression would produce
 `email?: string`, while this nullable column produces `email?: string | null`.
 
-This support is specific to boolean operand lists, query-level ordering terms,
-and the complete clauses named above. Generic `sequence()` and
-`commaSeparated()` collections do not discard `omit`. Clauses that provide
-sources or change structural guarantees cannot be conditional. Pagination is
-the exception: `offset()`, `fetchFirst()`, and `fetchNext()` can be paired
-with `omit`, but a conditional row bound keeps the query's inferred
-cardinality at `many`. Qubu still rejects `omit` branches paired with
-`from()`, joins, `groupBy()`, correlation, CTEs, or custom clauses. Build
-separate queries when those structural parts differ at runtime.
+### Where omission is supported
+
+Use `omit` in the clauses and expression lists shown above. Generic
+`sequence()` and `commaSeparated()` collections do not discard it.
+
+Pagination also supports `omit`: pair it with `offset()`, `fetchFirst()`, or
+`fetchNext()`. A conditional limit keeps the inferred cardinality at `many`
+because the limit may be absent.
+
+Build separate queries when any of these parts differ at runtime. They cannot
+be paired with `omit`:
+
+- `from()` or joins.
+- `groupBy()`.
+- Correlation.
+- CTEs.
+- Custom clauses.
 
 ## Handle `NULL` and empty lists deliberately
 

package/docs/guides/select/grouping-and-windows.md

@@ -1,6 +1,6 @@
 # Group and rank rows
 
-> Use aggregates, grouping, and window expressions while preserving the dependencies and result types that make each expression valid.
+> Summarize rows with aggregates and rank them with window functions.
 
 The examples use the `users` and `posts` tables from [Build a
 `SELECT`](overview.md).
@@ -28,6 +28,7 @@ const counts = select(
 
 `users.name` is grouped, while `posts.id` is consumed by `COUNT()`. The
 same dependency rule applies to `HAVING` and grouped `ORDER BY` expressions.
+
 A projection such as `{ email: users.email, postCount: count(posts.id) }` is
 rejected unless `users.email` is grouped or is functionally determined by a
 grouped primary or unique key declared in the table schema. Qubu uses only
@@ -58,7 +59,9 @@ const rankedUsers = select(
 Window expressions remain ordinary expressions. They can be projected, aliased,
 and passed to `orderBy()`. Their source requirements and result types are
 retained through `over()`, and values rendered inside the window
-specification remain parameters. Named windows and frame clauses are outside
+specification remain parameters.
+
+Named windows and frame clauses are outside
 the initial inline scope.
 
 ## Read next

package/docs/guides/select/ordering-and-pagination.md

@@ -1,6 +1,6 @@
 # Order and paginate
 
-> Choose a stable order and apply optional row limits while keeping SQL clause order and query cardinality visible.
+> Sort results and limit the rows a query returns.
 
 The examples use the `users` table from [Build a `SELECT`](overview.md).
 
@@ -34,10 +34,12 @@ const page = select(
 )
 ```
 
-The rendered clause order is still `FROM`, `WHERE`, `ORDER BY`, and
-pagination. The active dialect decides whether pagination uses standard
+The rendered clauses follow SQL order: `FROM` comes before `WHERE`, followed
+by `ORDER BY` and pagination. The active dialect decides whether pagination uses standard
 `FETCH` syntax or a driver-specific `LIMIT` form.
 
+### Make the limit optional
+
 Pair a pagination clause with `omit` when the row bound is optional at runtime:
 
 ```ts

package/docs/guides/select/overview.md

@@ -1,6 +1,6 @@
 # Build a `SELECT`
 
-> Build a `SELECT` from typed tables, then inspect its sources, projection, joins, and result row.
+> Choose fields, add a source, and join tables to build a typed SELECT query.
 
 ## Start with a projection and a source
 
@@ -24,8 +24,7 @@ render(query).text
 ```
 
 An object projection uses its keys as result names. Name the fields you intend
-to return in the usual case. Reserve `all(source)` for a result contract that
-intentionally returns every source column. It returns the source's columns as a
+to return in the usual case. Use `all(source)` when you want every source column. It returns the source's columns as a
 named projection object, so it can still be spread alongside computed
 expressions:
 
@@ -79,6 +78,8 @@ Use `innerJoin`, `leftJoin`, `rightJoin`, or `fullJoin` with an `ON`
 condition. `crossJoin` and `naturalJoin` add a source without a condition;
 use them only when that SQL behavior is intentional.
 
+### Handle missing joined rows
+
 `leftJoin()` also carries nullability into the selected row. A column from the
 joined source is nullable because the row may be missing, while an expression
 with a deliberately non-nullable result such as `count()` remains non-null:
@@ -98,6 +99,8 @@ const summary = select(
 // { userName: string; postTitle: string | null; postCount: number }
 ```
 
+### Add conditions
+
 Compose boolean expressions explicitly:
 
 ```ts

package/docs/guides/sql-templates.md

@@ -1,6 +1,6 @@
 # Compose SQL templates
 
-> Use trusted SQL syntax with bound runtime values while retaining the Qubu metadata carried by interpolated expressions, fragments, and queries.
+> Write SQL templates that bind values safely and preserve type information from Qubu expressions.
 
 ## Bind every runtime value
 
@@ -108,10 +108,16 @@ reaches `unsafeExpression()`.
 
 ## Preserve metadata through interpolated fragments
 
-The tag inherits source dependencies, conservative outer-join nullability,
-grouping facts, aggregate and window state, subquery state, and dialect
-capability requirements from Qubu fragment substitutions. It does not infer
-those facts from unchecked template text.
+Qubu fragment substitutions pass these facts to the template:
+
+- Required sources.
+- Possible nulls from outer joins.
+- Grouping dependencies.
+- Aggregate and window state.
+- Subquery state.
+- Required dialect capabilities.
+
+Qubu does not infer these facts from template text.
 
 Use a built-in expression as the substitution when its semantics matter:
 

package/docs/guides/valtio-sync.md

@@ -102,11 +102,17 @@ const handlers = applyOpsWithQubu<SyncContext>({
 export const sync = valtioSync({ schema: { todos }, handlers })
 ```
 
-Authorization, conflict checks, the application mutation, and
-`syncEvents.write()` run in that order inside one Qubu transaction. If any step
-fails, the adapter rolls the transaction back. The event sequence becomes
-`serverVersion` unless the mutation handler returns an explicit version. Read
-handlers pass through unchanged.
+Each mutation runs these steps in one Qubu transaction:
+
+1. Check authorization.
+2. Check conflicts.
+3. Apply the application mutation.
+4. Write the sync event with `syncEvents.write()`.
+
+If any step fails, the adapter rolls the transaction back.
+
+The event sequence becomes `serverVersion` unless the mutation handler returns
+an explicit version. Read handlers pass through unchanged.
 
 The integration does not define persistence tables, import Drizzle, or execute
 driver APIs. The application owns table design, authorization, conflict policy,

package/docs/guides/vite-plugin.md

@@ -1,6 +1,6 @@
 # Vite compiler hint
 
-> Opt a JavaScript or TypeScript module into Qubu's ambient query API while keeping the transform limited to explicit directive-bearing files.
+> Use a "use qubu" directive to add the Qubu imports a module needs.
 
 The optional Vite plugin recognizes the `"use qubu"` directive and injects only
 the referenced named imports from the configured module.
@@ -33,7 +33,7 @@ ambient value and type declarations for the TypeScript compiler.
 
 ## Mark a module explicitly
 
-Put the directive in the module's initial directive prologue:
+Put the directive at the start of the module, alongside any other directives:
 
 ```ts
 "use qubu"

package/docs/index.md

@@ -1,11 +1,17 @@
 # Qubu
 
-> Build parameterized SQL from typed tables, expressions, and clauses.
+> Build SQL queries from typed tables and reusable values.
 
-Qubu builds SQL from values. Tables, expressions, clauses, and complete queries
-compose without a mutable query builder. TypeScript tracks selected row shapes,
-source scope, and nullability, while rendering returns SQL text and ordered
-parameters.
+Qubu builds SQL from reusable values. You can combine query parts without
+changing a shared query-builder object.
+
+TypeScript checks:
+
+- Which fields the query returns and their types.
+- Whether each column belongs to a source in the query.
+- Whether a result can be `null`.
+
+Render a query to inspect its SQL text and ordered parameters.
 
 The preferred source style names each projected field and writes the final
 `select()` clauses in SQL order. Clause values remain order-independent at
@@ -17,7 +23,7 @@ and placed in that final call where it reads best.
 If this is your first query, follow [Getting started](getting-started.md) to
 define a table, build a `SELECT`, and inspect its SQL and parameters.
 
-## Choose a task
+## Build and run queries
 
 - [Build a `SELECT`](guides/select/overview.md) with projections, joins,
   predicates, ordering, and grouping.
@@ -36,18 +42,18 @@ define a table, build a `SELECT`, and inspect its SQL and parameters.
 - [Query nested JSON](guides/json.md) or read scalars from structured paths.
 - [Enable the Vite compiler hint](guides/vite-plugin.md) when query modules
   should opt into named imports through a directive.
-- [Inspect an existing database](schema/introspection.md) through the optional
-  user-owned catalog boundary.
-- [Generate a schema module](schema/code-generation.md) from one complete,
-  non-lossy Snapshot v1 introspection result.
+
+## Work with schemas and migrations
+
+- [Inspect an existing database](schema/introspection.md) using a connection you provide.
+- [Generate a schema module](schema/code-generation.md) from an introspection result without losing schema facts.
 - [Compare snapshots](schema/diff.md) with explicit rename hints and reviewable
   safety diagnostics.
 - [Build migration plans](schema/migration-plans.md) as reviewed, deterministic
   data before DDL emission.
 - [Emit DDL](schema/ddl-emission.md) from an approved migration plan without
   handing Qubu a database connection.
-- [Operate migrations](migrations/index.md) with versioned artifacts, verified
-  adapter profiles, baselines, a portable executor, and explicit recovery.
+- [Operate migrations](migrations/index.md) with reviewed migration files and a verified adapter.
 
 ## The query pipeline
 
@@ -106,8 +112,9 @@ render(query)
 The inferred row is `{ id: number; name: string }`. The value `7` stays out
 of the SQL text and appears in the `parameters` array in placeholder order.
 
-The [supported features](reference/supported-surface.md) page is the canonical
-package-entrypoint and ownership map. Applications may use Qubu's portable
-migration executor while retaining credentials, approval policy, custom SQL,
-and deployment lifecycle ownership. [Troubleshooting](troubleshooting.md)
-starts from common errors and points to the concept page behind each one.
+## Find support details
+
+- [Supported features](reference/supported-surface.md) lists package imports and
+  explains which responsibilities stay with your application.
+- [Troubleshooting](troubleshooting.md) starts from common errors and explains
+  how to fix them.

package/docs/migrations/adapters.md

@@ -1,6 +1,6 @@
 # Adapter capability profiles
 
-> Select a migration adapter from capabilities proven by its driver and environment, not from dialect name alone.
+> Choose a migration adapter based on what its driver and environment have been tested to support.
 
 Every executable migration adapter opens a migration session and
 advertises the exact behavior the executor may use:
@@ -25,12 +25,12 @@ executor never treats one as proof of the other.
 
 ## Trusted migration SQL
 
-Migration SQL, including SQL conditions, is trusted across all adapters. Qubu
-validates program structure and adapter capabilities, but does not parse SQL
-to enforce safety. Callers must preserve executor-owned transactions, connection
-settings, and migration journal state. For example, an explicit `COMMIT` can
-leave schema changes applied without their journal record; atomicity and recovery
-guarantees depend on respecting this contract.
+Qubu validates program structure and adapter capabilities. It trusts the SQL
+you supply, including SQL conditions, and does not parse it for safety.
+
+Migration SQL must preserve the executor’s transactions, connection settings,
+and journal state. For example, an explicit `COMMIT` can apply schema changes
+without their journal record, breaking the executor’s recovery guarantees.
 
 ## Current profiles
 
@@ -44,11 +44,24 @@ The following stable profiles have live conformance coverage in this checkout:
 | `@qubu/adapter-postgresjs/migration`  | PostgreSQL | required, optional, forbidden | none, exclusive | checkpointed     | Reserves and releases one connection                   |
 | `@qubu/adapter-pglite/migration`      | PostgreSQL | required, optional, forbidden | none, exclusive | checkpointed     | Uses the database query queue as the pinned session    |
 
-All five support every current tagged parameter kind (`null`, `boolean`,
-`string`, `number`, `bigint`, `bytes`, and `json`), a database journal and
-lease, atomic applied-record/head advancement, and recovery-required commit
-ambiguity classification. Support still depends on the artifact's server,
-feature, transaction, and lock constraints.
+All five support:
+
+- Every current tagged parameter kind.
+- A journal and migrator lease stored in the database.
+- An atomic update of the applied record and journal head.
+- A recovery-required result when a commit’s outcome is uncertain.
+
+Parameter kinds are:
+
+- `null` and `boolean`.
+- `string` and `number`.
+- `bigint` and `bytes`.
+- `json`.
+
+The artifact’s server, feature, transaction, and lock requirements must still
+match the adapter.
+
+### Unavailable profiles
 
 These exported profiles are unavailable and must not be passed to the
 executor:
@@ -62,6 +75,8 @@ executor:
 Unavailable profiles expose `reason` and `missingCapabilities`; they do not
 fall back to a generic executor.
 
+### Configure libSQL inspection
+
 For libSQL, let the migration entrypoint exclude all reserved journal objects
 during strict inspection:
 
@@ -84,7 +99,9 @@ Each executable artifact must contain exactly one phase and an embedded before
 snapshot. The adapter submits its statements, SQL assertions, applied-history
 record, head update, and terminal attempt state in one `client.migrate()` call.
 For example, creating a table and recording that migration either both commit
-or both roll back. Multiple artifacts are separate batches; earlier successful
+or both roll back.
+
+Multiple artifacts are separate batches; earlier successful
 artifacts remain applied if a later one fails.
 
 Preparation reads the schema in a read transaction. The submitted batch checks
@@ -92,13 +109,24 @@ that the catalog still matches that inspection, the lease is still owned, and
 the head still equals the expected parent. Foreign-key validation runs before
 commit because libSQL temporarily disables enforcement during `migrate()`.
 
+### Supported conditions
+
 Schema fingerprint and property preconditions are checked against the embedded
-before snapshot, whose physical facts are verified during preparation and
-guarded by the in-batch catalog assertion. Object-presence and scalar SQL checks
-run inside the batch. Postconditions must be object-presence/absence checks
-without fingerprints, or scalar SQL checks returning `1`. Unsupported conditions
-and multiple phases are rejected. SQL content is passed to the driver without
-safety validation; each program entry must follow the driver's statement contract.
+before snapshot. Preparation verifies its physical facts, and the batch
+asserts that the catalog still matches.
+
+Object-presence and scalar SQL checks run inside the batch. Postconditions
+must use either:
+
+- Object-presence or absence checks without fingerprints.
+- Scalar SQL checks returning `1`.
+
+Unsupported conditions and multiple phases are rejected.
+
+SQL is passed to the driver without safety validation. Each program entry
+must follow the driver’s statement contract.
+
+### Crashes and uncertain outcomes
 
 The database-row lease has no expiry or heartbeat. A process crash can leave
 it held; ownership must be resolved before another runner can proceed. A lost

package/docs/migrations/artifacts-and-policy.md

@@ -1,10 +1,12 @@
 # Artifacts and approval policy
 
-> Review exactly what is authenticated and executable before an artifact enters a repository.
+> Review migration files and approve the exact operations they will run.
 
-Qubu has two strict artifact kinds. An executable migration contains a reviewed
-plan and authoritative program. A verified baseline records an observed schema
-without pretending that historical SQL ran.
+An artifact is a versioned migration file. Qubu supports two kinds:
+
+- An **executable migration** contains a reviewed plan and the program to run.
+- A **verified baseline** records the observed schema as a starting point. It
+  does not claim that historical SQL ran through Qubu.
 
 ## Published formats
 
@@ -38,18 +40,30 @@ An executable artifact records:
 - operation-scoped approvals and custom-program provenance;
 - artifact provenance and `artifactDigest`.
 
-The program—not `emitMigrationPlan(...).sql` and not joined statement text—is
-the execution authority. Each phase declares its position, dependencies,
-transaction and lock requirements, preconditions, postconditions, and ordered
-statements. Each statement declares its operation ID, dependencies, SQL, and
-tagged parameters.
+The executor runs the program stored in the artifact. The SQL preview from
+`emitMigrationPlan(...).sql` is not an executable artifact.
+
+Each phase declares:
+
+- Its position and dependencies.
+- Transaction and lock requirements.
+- Preconditions and postconditions.
+- Ordered statements.
+
+Each statement declares its operation ID, dependencies, SQL, and tagged parameters.
 
 ### Baseline artifact schema
 
-A baseline records `id`, sequence and parent lineage, encoding descriptors,
-dialect and optional constraints, one verified snapshot descriptor,
-`verifiedAt`, provenance, optional operator metadata, and `artifactDigest`. It
-has no migration plan, program, or SQL digest.
+A baseline records:
+
+- `id`, sequence, and parent lineage.
+- Encoding descriptors.
+- Dialect and optional constraints.
+- One verified snapshot descriptor and `verifiedAt`.
+- Provenance and optional operator metadata.
+- `artifactDigest`.
+
+It has no migration plan, program, or SQL digest.
 
 Artifact IDs are stable identities, not repository order. Sequence and parent
 digest establish the linear chain. Renumbering therefore changes lineage and
@@ -57,21 +71,36 @@ the artifact digest.
 
 ## Canonical bytes and digest domains
 
-`encodeCanonical()` sorts object keys by Unicode code-point order, preserves
-array order, emits compact JSON as UTF-8, normalizes `-0` to `0`, rejects
-non-finite numbers, and adds one LF at EOF. `digestCanonical()` prefixes those
-bytes with the UTF-8 bytes for:
+`encodeCanonical()` produces a repeatable byte representation:
+
+- Sort object keys by Unicode code-point order.
+- Preserve array order.
+- Emit compact UTF-8 JSON.
+- Normalize `-0` to `0` and reject non-finite numbers.
+- End the file with one line feed.
+
+`digestCanonical()` prefixes those bytes with the UTF-8 bytes for:
 
 ```text
 qubu:migrate:v1:<domain>\0
 ```
 
-The five domains are `artifact`, `baseline`, `migration-plan`,
-`migration-program`, and `schema-snapshot`. Domain separation prevents equal
-JSON values used for different purposes from sharing an integrity identity.
+The digest identifies its purpose through one of five domains:
+
+- `artifact`.
+- `baseline`.
+- `migration-plan`.
+- `migration-program`.
+- `schema-snapshot`.
+
+The prefix ensures that identical JSON used for different purposes gets
+different digests.
+
 Operational digests have the form `sha256:` plus 64 lowercase hexadecimal
 digits and are recomputed while sealing or decoding.
 
+### Fingerprints and integrity digests
+
 Snapshot and plan `fingerprint` APIs are deterministic FNV-1a64 change
 detectors. They remain useful for caches and fixture assertions, but they are
 not cryptographic integrity evidence and are never valid journal heads,

package/docs/migrations/index.md

@@ -1,8 +1,8 @@
 # Migration operations
 
-> Choose the package entrypoint that owns each migration concern without pulling database or Node.js behavior into pure schema code.
+> Find the packages and guides for planning, running, and recovering migrations.
 
-Qubu migrations are split across explicit ownership boundaries:
+These packages handle different parts of a migration:
 
 | Owner           | Imports                                                                                                                     | Responsibility                                                                                                               |
 | --------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
@@ -21,6 +21,8 @@ import { emitMigrationPlan } from "@qubu/migrate/ddl"
 import { compileMigrationProgram, sealExecutableArtifact } from "@qubu/migrate/artifact"
 ```
 
+## Choose an import
+
 The `@qubu/migrate` root intentionally exports only format/version constants
 and the central plan and artifact types. Import behavior from its focused
 entrypoint:
@@ -46,12 +48,17 @@ entrypoint:
 | `@qubu/migrate/bootstrap/sqlite`   | Plan a fresh SQLite schema through the normal compiler                                                                        |
 | `@qubu/migrate/testing`            | Test adapter capabilities and deterministic failure boundaries                                                                |
 
-Start with [Artifacts and approval policy](artifacts-and-policy.md) when
-reviewing a migration format. Check [Adapter capability
-profiles](adapters.md), use [Command line operations](operations.md) to
-configure an application, then keep [Recovery and reconciliation](recovery.md)
-with the deployment runbook. [Lotta Games adoption](lotta-adoption.md) records
-the downstream cutover boundary and current combo-matrix blocker.
+## Choose a guide
+
+- [Artifacts and approval policy](artifacts-and-policy.md): review migration
+  files and approve operations.
+- [Adapter capability profiles](adapters.md): choose a supported driver.
+- [Command line operations](operations.md): configure and use the CLI.
+- [Recovery and reconciliation](recovery.md): handle interrupted migrations.
+- [Lotta Games adoption](lotta-adoption.md): review the downstream cutover
+  plan and combo-matrix release blocker.
+
+## Select a built-in dialect
 
 Choose the dialect-specific bootstrap entrypoint when using a built-in dialect:
 

package/docs/migrations/lotta-adoption.md

@@ -1,11 +1,13 @@
 # Lotta Games adoption
 
-> Replace Lotta's provisional runner with Qubu while preserving product-owned deployment policy and historical truth.
+> Move Lotta to Qubu migrations while keeping deployment decisions in Lotta.
 
 Adopt the released `@qubu/migrate`, `@qubu/cli`, and libSQL migration entrypoint
 as a hard cutover. Do not add an upstream decoder for Lotta's provisional JSON,
 FNV artifact digests, journal, or broad unsafe flags.
 
+## Establish the starting state
+
 Before changing downstream state, inspect every environment for a provisional
 journal or baseline row. Regenerate unreleased migrations in the Qubu artifact
 format. For an existing database, create one standard baseline only after strict
@@ -13,6 +15,8 @@ live introspection matches the intended Qubu snapshot. That baseline records a
 verified starting state; it does not claim that old migrations ran through
 Qubu.
 
+## Keep deployment policy in Lotta
+
 Keep these concerns in Lotta:
 
 - Turso credentials and environment selection;
@@ -30,10 +34,17 @@ databases with `schema bootstrap`; keep connection PRAGMAs in the test harness.
 > Drizzle history. A verified baseline is the handoff from historical state to
 > Qubu lineage.
 
-The downstream verification set should cover a fresh bootstrap, an already
-baselined database, a no-op deploy, pending migrations in both deployment
-timing modes, drift refusal, concurrent invocation, rollback, and explicit
-recovery.
+## Verify the cutover
+
+Cover these scenarios downstream:
+
+- A fresh bootstrap.
+- An already baselined database.
+- A deploy with no pending migrations.
+- Pending migrations in both deployment timing modes.
+- Refusal when the schema has drifted.
+- Concurrent migration attempts.
+- Rollback and explicit recovery.
 
 ## Combo-matrix release blocker