qubu 0.6.2 → 0.7.0

package/docs/sql-semantic-types.md

@@ -1,6 +1,6 @@
 # SQL semantic types
 
-> Use SQL domains to constrain valid query composition without conflating database semantics with driver-decoded application values.
+> Understand which SQL operations a column supports, even when its JavaScript type looks the same as another column’s.
 
 Qubu tracks four independent facts for a field or result expression:
 
@@ -11,7 +11,7 @@ Qubu tracks four independent facts for a field or result expression:
 | Nullability     | Can the selected value be `null`?                         | `false`                   |
 | SQL domain      | Which portable SQL operations may consume the expression? | `SqlText` or `SqlUuid`    |
 
-The axes are deliberately separate. Both `text()` and `uuid()` decode to a
+These facts are separate. Both `text()` and `uuid()` decode to a
 JavaScript `string`, but their SQL behavior differs. Likewise, two
 `timestamp()` definitions may share `SqlTimestamp` while a custom column uses
 different JavaScript output and write types for its driver.
@@ -111,12 +111,15 @@ target is vendor-specific.
 
 ## Known incompatibility is rejected
 
-Qubu checks capabilities and compatibility when it knows both SQL domains.
-Arithmetic and `SUM`/`AVG` require numeric-like expressions; text functions,
-concatenation, `LIKE`, and PostgreSQL `ILIKE` require text-like expressions;
-ordering and range comparisons require compatible ordering groups; and
-equality, `IN`, `CASE`, `COALESCE`, and set-operation fields require compatible
-equality groups. Boolean clauses require a boolean SQL domain.
+When Qubu knows both SQL domains, it checks these rules:
+
+- Arithmetic and `SUM`/`AVG` require numeric-like expressions.
+- Text functions, concatenation, and pattern matching (`LIKE` or `ILIKE`)
+  require text-like expressions.
+- Ordering and range comparisons require compatible ordering groups.
+- Equality comparisons and `IN` require compatible equality groups. The same
+  rule applies to `CASE`, `COALESCE`, and set-operation fields.
+- Boolean clauses require a boolean SQL domain.
 
 These checks model portable capability and group relationships, not every
 database's implicit casts. An expression accepted by one database after an

package/docs/troubleshooting.md

@@ -1,6 +1,6 @@
 # Troubleshooting
 
-> Start from the observed error or output, verify the boundary that produced it, and apply the smallest fix that changes the result.
+> Find a common error, check its cause, and fix the query.
 
 ## Column is not available in this query scope
 
@@ -73,9 +73,13 @@ driver that expects `?` placeholders.
 ## Read and repair query diagnostics
 
 Type-level query failures carry stable properties in the diagnostic type, and
-runtime authoring failures throw `QueryValidationError`. Read the code, context,
-path, and hint before changing the query. The hint names the repair boundary;
-the path points to the clause or field that needs attention.
+runtime authoring failures throw `QueryValidationError`. Check these fields
+before changing the query:
+
+- `code`: the kind of error.
+- `context`: where the error occurred.
+- `path`: the clause or field that needs attention.
+- `hint`: how to fix it.
 
 ```ts
 import { QueryValidationError, fetchFirst } from "qubu"
@@ -130,8 +134,12 @@ Verify all three opt-ins:
 3. TypeScript includes `qubu/globals` in its `types` list or includes the
    declaration explicitly.
 
-The transform skips non-script files, dependencies under `node_modules`, files
-excluded by filters, and modules that reference no eligible Qubu global.
+The transform skips:
+
+- Non-script files.
+- Dependencies under `node_modules`.
+- Files excluded by filters.
+- Modules that reference no eligible Qubu global.
 
 ## Parameters are in an unexpected order
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "qubu",
-  "version": "0.6.2",
+  "version": "0.7.0",
   "repository": {
     "type": "git",
     "url": "https://github.com/aleclarson/qubu"

package/dist/index-CaxrMD1A.d.mts

@@ -1 +0,0 @@
-export {}

package/docs/migrations/lotta-adoption.md

@@ -1,50 +0,0 @@
-# Lotta Games adoption
-
-> Replace Lotta's provisional runner with Qubu while preserving product-owned deployment policy and historical truth.
-
-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.
-
-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
-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 these concerns in Lotta:
-
-- Turso credentials and environment selection;
-- Cloudflare deployment waiting and migrate-first/migrate-last prompts;
-- the destructive-deny approval policy and product-specific custom programs;
-- rollout timing and the one-time legacy journal cutover decision.
-
-Replace the private migration and runner modules with thin configuration and
-CLI/library invocation. Make the release script apply the complete pending
-repository chain and preserve non-zero failures. Generate fresh local test
-databases with `schema bootstrap`; keep connection PRAGMAs in the test harness.
-
-> [!WARNING]
-> Keep Drizzle migration SQL and snapshots read-only. Do not import or replay
-> 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.
-
-## Combo-matrix release blocker
-
-The main repository currently pins the `combos` submodule gitlink to
-`2e2856e5692ef5cbef03a055fa71e5baab8ec10a`. Commit `d9d2e02` added and verified
-migration profiles in the main repository without advancing that gitlink, so
-the orphan-branch adapter × environment matrix is not yet synchronized with the
-new profile claims. This is an unresolved pinned-SHA issue, not evidence that
-the matrix has verified the new migration entrypoints.
-
-Do not edit the gitlink or matrix as part of Lotta adoption. Before release,
-update the `combos` branch in its own review, run the declared environments and
-real database round trips, classify every candidate pair, then advance the main
-repository gitlink to that reviewed commit in a separate change.