@noy-db/hub 0.7.1-pre.0 → 0.8.0

package/CHANGELOG.md

@@ -1,5 +1,138 @@
 # Changelog — hub
 
+## 0.8.0
+
+**The capsule seam** (#4). Hub's crypto interior is now one contract behind one door, and an application can replace it at build time without forking hub.
+
+`enclave-aes` — PBKDF2 → AES-KW → AES-256-GCM, exactly what shipped before — stays inside hub and remains the default, so `npm install @noy-db/hub` is unchanged and needs no configuration. An alternative binds through hub's `imports` map with a build condition (`resolve.conditions` in Vite/esbuild/webpack, `--conditions` for Node). Deliberately not a runtime option: a `createNoydb({ capsule })` switch would be a hot-swap surface, whereas a build condition lives in build config and `npm ls` tells an auditor which capsule a build actually contains.
+
+`@noy-db/hub/capsule` is the published contract — `CapsuleKey`, `CapsuleGroup`, `CapsulePrimitives`, `capabilities()`, `makeCapsule()`, and `CapsuleNotSupportedError`. A service that needs a capability asserts it at `createNoydb()` and refuses there by name, never on first write: a capability discovered mid-write is a half-built vault.
+
+Three things made this real rather than nominal. Every `crypto.subtle` call outside the capsule is gone — 38 of them across 10 files — and the ratchet that tracked them is now a flat ban, so hub ships with no runtime dependencies at all. The shared envelope machinery (~3,000 lines of AAD construction, tombstones, sealed slots, the record codec, rekeying) lives once and is bound to a capsule's 15 primitives by `makeCapsule()`, so two capsules cannot drift into writing rows the other cannot read. And `@noy-db/test-capsule-conformance` is the suite both implementations run, asserting the `enclave-`/`exclave-` prefix rule **from the package name** — which is what makes the prefix a trust posture rather than a naming convention.
+
+`@noy-db/exclave-plain` is the first alternative: a plaintext capsule for the case the seam was built for — a table whose rows other tools read and write, where access control already lives in IAM.
+
+⛔ **It turns off encryption.** Rows are stored readable; noy-db stops being zero-knowledge and the security boundary moves out of the library and into your store. Its `_mac` integrity stamp detects corruption, foreign writes, and rows moved between collections — it is **not** a defence against a malicious store, because there is no secret in exclave mode and anyone who can write a row can compute a valid stamp for it. Read its README before installing it.
+
+**`EncryptedEnvelope` is now `Envelope`, with `_iv`/`_data` optional** (#15). The old name remains an exact alias for the whole 0.8 line, and both are exported from the root barrel and from `@noy-db/hub/to`.
+
+⚠️ **If you are already on `0.8.0-pre.0`, this reaches you as a breaking change.** That release declared `readonly _data: string` and exported no `Envelope`. Code that reads `envelope._data` as a `string` now sees `string | undefined` and stops compiling. There is no runtime behaviour change and no wire-format change — `NOYDB_FORMAT_VERSION` does not move and every envelope already written reads back identically — but the type genuinely narrowed under you, and a type error with no explanation is a poor way to learn that.
+
+The fields are optional because an **exclave** capsule stores a plaintext row and has no ciphertext body at all. Absence and `''` mean the same thing: no sealed body. That equivalence is not new — a tombstone, a `_del` marker and a plaintext collection have carried `_iv: ''` since the format's first version, and `hasSealedBody()` has always been the question to ask. Widening only lets a capsule omit the keys instead of emptying them.
+
+`EncryptedEnvelope` is an **alias, not a narrower subtype**. Declaring it as body-required was considered and rejected: every existing reader would have kept compiling untouched, which is precisely the bug — a store handing back an exclave row would then fail at runtime in code the compiler had just declared safe.
+
+If you implement `NoydbStore`, nothing is required of you: a store that honours "dumb ciphertext store" never reads these fields for meaning. If you *do* read them, treat absent exactly as empty.
+
+**A declaration that cannot resolve is now refused at registration, instead of silently doing nothing** (#19, #25).
+
+⛔ **The security fix first.** `classifiedFields` accepted a **dotted path** — `classifiedFields: { 'account.password': spec }` — and sealed nothing. Registration succeeded, the write succeeded, and the secret came back **in full plaintext** from `get()` and `list()`. The only signal was `reveal()` throwing, which a developer who believes the field is sealed has no reason to call, because they can already read the value.
+
+So "misconfigured" and "not classified at all" were observationally identical while the developer's belief was that the secret was protected. Nested paths are not supported by `classifiedFields` and a dotted key is now a `ClassifiedConfigError` naming the workaround (promote the field to the top level). **If you declared a nested classified field, values written under it are plaintext at rest and this fix does not reach them** — treat them as exposed and rotate.
+
+Found and reported by a consumer while validating a design, before shipping.
+
+Two further guards close the same class:
+
+- **A malformed field path is refused.** `i18nFields` and `lookupFields` resolve nested paths through a helper that validates nothing — by design, since "nothing is at this path" is a legitimate answer for an optional field. The consequence was that `'contacts[.name'` was indistinguishable from an absent value: the declaration did nothing, forever. Measured: an `i18nFields` declaration with `required: 'all'` and a malformed path accepted a record missing every required language, while the same spec on a well-formed path refused it. The guarantee was not weakened — it was never installed.
+- **An `i18nFields` declaration naming a field the collection does not have is refused** when the schema is readable. `titel` for `title` is valid syntax and equally inert.
+
+Both stay **silent when they cannot know**: a schema-less or TS-generic collection has real fields that simply are not enumerable, and refusing them would break working collections to fix a silent one. `lookupFields` is deliberately exempt from the existence check — its keys *declare* fields rather than referencing them.
+
+`moneyFields` already guarded its own grammar and explained why in its header. These are the same lesson reaching the families next door.
+
+**Two correctness fixes on the write path.**
+
+`writeQueue.pending` now covers the **pre-write gate phase** (#11). A write waits on the schema-update gate and the schema fence before it reaches the store, and that window was outside the queue's accounting — so `pending` read `0` and `onFlush()` resolved while a write was still in flight, gated but not yet committed. A caller using `onFlush()` to know "everything is written" could act on a vault that was not yet consistent. The queue now brackets the gate phase too, and a write refused by a gate — before it commits — still settles the queue without reporting a spurious error, because a refusal at the gate is a legitimate outcome rather than a failure to flush.
+
+**Pod flush retries now re-encode at the version they observed** (#12). On a conflict, the retry loop re-fetched the remote pod and merged, but the encoded bytes and the expected version were computed **once, before the loop** — so every retry re-sent the *original* bytes against the *original* version. The merge was performed and then discarded, and the retry could only fail the same way or, worse, overwrite the concurrent write it had just merged with. Encoding now happens inside the loop, so a retry sends the merged bytes at the version it actually read.
+
+The regression test records that the interleaving is load-bearing: it requires the remote to move between the read and the write, because a naively ordered test passes against the broken code.
+
+
+## 0.8.0-pre.0
+
+Relicensed from MIT to Apache-2.0 from this version on. Earlier versions remain MIT.
+
+`@noy-db/shamir` is published for the first time under a surviving number (its `0.7.1-pre.0` was withdrawn). `revokeAuthenticator` lands (vLannaAi/noy-db#1445). `repository.url` now points at `github.com/noy-db/core`.
+
+Query tiers: the DSL ships in four groups, and a Find-only consumer stops paying for the other three (#1458).
+
+`@noy-db/hub/query` now carries **Find** and nothing else — `where` (ten operators), `or`, `and`, `filter`, `wherePredicate`, `orderBy`, `limit`, `offset`, `page`, `after`, `first`, `toArray`, `count`, `exists`, `ids`, `toPlan`. The other three groups are side-effect subpaths:
+
+```ts
+import '@noy-db/hub/query/live'     // subscribe, live
+import '@noy-db/hub/query/reduce'   // aggregate, groupBy, window, distinct, dateTrunc
+import '@noy-db/hub/query/relate'   // the joins, traverse, ancestorsOf, descendantsOf, explain
+```
+
+One line at your app's entry patches the methods onto `Query.prototype` **and** merges their types, so no call site changes. `collection.scan()` is split the same way — `scan().aggregate()` / `scan().groupBy()` come with Reduce, `scan().join()` with Relate.
+
+**Consumers of `@noy-db/hub` (the root barrel) do nothing.** The root barrel imports all three groups, so every method and every re-export is exactly where it was. This is breaking only for code that imports from `@noy-db/hub/query` directly; `codemods/0.8.0-pre.json` lists the moved symbols and the imports to add.
+
+Calling a method whose group is not imported does not compile — the method's type ships with its subpath. If a cast gets one past `tsc`, it throws `QueryExtensionMissingError`, which names the method and the subpath rather than `TypeError: q.join is not a function`.
+
+Measured: `import { Query } from '@noy-db/hub/query'` plus `where().orderBy().limit().toArray()` was 80,743 B minified / 26,036 B gzipped, of which 33,589 B was Relate, Reduce and Live code the query never touched — and importing the barrel cost the same as using it, because a bundler cannot drop a method of a class. `scripts/check-bundle.mjs` now measures each group as a scenario, with a control per group asserting the side-effect import still brings its code in.
+
+A materialized view can declare a **window** — a running total, a ranking, or a look at the neighbouring row (#1411).
+
+```ts
+withMaterializedView({
+  name: 'clientRollup',
+  unionSources: [{ collection: 'payments', map: (r) => ({ client: r.client, period: r.period, amount: r.amount }) }],
+  groupBy: ['client', 'period'],
+  aggregate: { total: sum('amount') },
+  moneyFields: { amount: THB, total: THB, cumulative: THB },
+  window: {
+    partitionBy: 'client',
+    orderBy: 'period',
+    select: { cumulative: runningMoneySum('total') },
+  },
+  rowKey: (row) => `${row.client}:${row.period}`,
+})
+```
+
+Runs after `groupBy` + `aggregate` and before `derive`, which is the order the useful shape needs: aggregate per (client, period), then accumulate *across* periods. Available on the `unionSources` and `projection` forms; the `query` form is unchanged, because a `Query` already has `.window(...).select(...)`.
+
+**Money is exact.** Reducer slots are rewritten through the same money binding `aggregate` uses, from the view's own `moneyFields`, so `runningMoneySum` accumulates in BigInt. Without that rewrite a running total over decimal strings returns `0.6000000000000001` where the aggregate on the same rows returns `'0.60'`.
+
+`moneyFields` no longer requires `aggregate` — a window's reducer slots are money-rewritten too, so a view declaring a window and no aggregate is now valid. `window.select` keys are refused if they collide with a `groupBy` key (a group key is the row's identity and feeds `rowKey`), and an empty `select` is refused.
+
+The window folds into `queryHash`, so re-parameterising one forces a refresh. `partitionBy` and `orderBy` are deliberately **not** sorted into the hash, unlike the groupBy and aggregate keys beside them: group buckets are commutative and window keys are not, so sorting them would let a real semantic change reuse a stored hash. A view that declares no window hashes byte-identically to before.
+
+Periods, blobs and materialized views — a pilot-reported round (#1450–#1456, #1411).
+
+- **#1454 — the periods family is not reachable through `vault.collection()`.** `_periods`, `_period_reopens`, `_period_freezes`, `_period_archives` and `_period_target_purges` now throw `ReservedCollectionNameError`, the same door as `_sync_credentials` and `_manifest`. Measured before: two `put()`s through the public handle rewrote a close, erased its append-only reopen log and unsealed the cell on the next cold open, undetected. `loadPeriods()` now verifies the inter-period hash chain and throws the new `PeriodChainError` when an interior close was rewritten or deleted under the engine; the newest close in a timeline has no successor hashing it, which is why the refusal, not the chain, is the fix. `chainAnchor` hashes the STORED record shape (return-only reopen/freeze/archive fields stripped), so a close following a reopen verifies.
+- **#1455 — a business date the gate cannot read is refused, not admitted.** With a `dateField`, a `Date` value is compared as the ISO string it will be stored as; a number, boolean or object throws `ValidationError`; absent / `null` means the record carries no business date and belongs to no period. The per-record `_ts` fallback the `endDate` docstring promised is withdrawn rather than implemented — it would have sealed every dateless row written before a vault-wide close. `PeriodClosedError` gains structured `dateField` and `side`.
+- **#1456 — reopening a period frees the records in its window.** A value is owned by the closed period with the smallest `endDate` at or after it; when that owner is reopened, no later close vetoes it. Reopening January with February and March closed frees January-dated rows and leaves February's sealed.
+- **#1452 — a sealed record's attachments are sealed with it.** `blob(id).put/delete/publish/deleteVersion/adoptExternal` run the owning record's `beforePut` gate with `incoming = existing`, so closed periods AND record guards refuse an attachment change exactly as they would refuse the record's update. A record with no stored body is not gated.
+- **#1451 — `collection.delete(id)` releases the record's blob references.** Ref-counted: an erasable blob shreds at refCount 0, shared content survives the deletion of one holder, a legacy blob's slot is gone and its chunks await reclaim.
+- **#1453 — legacy blobs have a reclaim path and `compact()` can see them.** `CompactionResult.unreferencedLegacyBlobs` counts key-less index rows at `refCount <= 0` on every run; `compact({ reclaimLegacyBlobs: true })` deletes them chunks-first. `BlobSet.delete()`'s docstring no longer names a `vault.blobGC()` that never existed.
+- **#1450 — on record: a UNION MV arm's `map` receives virtual via fields**, with correct values. It arrived with #1416 and is intended; it is now pinned by a test so a read-path refactor cannot take it away silently.
+- **#1411 — a UNION MV arm can declare a `joinOn` leg:** `join: [{ target, as, on, mode?, maxRows? }]` is `Query.joinOn()` in declaration form — composite equality or a range, predicate as data. The predicate folds into `queryHash` and the target joins the dependency set without a `sources` entry. `window` on MV declarations stays open (strategy-coupling design question).
+
+Period membership refuses a malformed business date instead of comparing it (#1459).
+
+#1455 made the guard refuse a `dateField` value that is neither a string nor a `Date`. Strings were still passed straight into the lexicographic comparison, so `'hello'` was written and — the case that matters — `'2026-6-15'` was written **into a sealed June**: it names a real day, but as text it sorts above `'2026-06-30'`.
+
+Both sides are now validated against the set that orders correctly: **zero-padded** `YYYY`, `YYYY-MM` or `YYYY-MM-DD`, optionally with a time. Coarser is fine — `'2026-01'` is how a monthly cycle is written, and it orders correctly — but unpadded is not. `closePeriod({ endDate })` refuses a malformed cutoff at the close, and `record[dateField]` is refused at the write with a `ValidationError` naming the field and the value. Absent and `null` still mean "no business date and no period" (#1455), unchanged.
+
+⚠️ Two inputs previously refused for the wrong reason now fail for the right one: `''` and `'15/06/2026'` were caught only because they sort below every plausible `endDate` — the period gate firing on garbage. They are `ValidationError` about the input now, not `PeriodClosedError`. Code catching `PeriodClosedError` around a write with an unvalidated date string should widen to `ValidationError`.
+
+`TamperedError` means exactly "AEAD failed under this key" (lanna-db #4). `reason` gains `'key-absent'` (thrown by the DEK resolver when a keyring holds no DEK for a reserved collection that already holds sealed records — #1288), plus the reserved `'generation-mismatch'` / `'foreign-stamp'` values (declared, not emitted). A credential-derived key that fails to open a wrapped-DEK blob now surfaces `InvalidKeyError`, never `TamperedError` (#1318). With the periods strategy active, `grant()` mints the grantor's `_periods` DEK first, so every grantee who may write a subject collection can read the gate that admits the write (#1288 ask 2).
+
+`Array.isArray` on a cold collection's pending result now returns `true`, so the idiomatic guard cannot silently swallow the read (#1462).
+
+`toArray()` is declared `T[]`, so `Array.isArray(rows) ? rows : []` is the ordinary defensive shape for the declared type — and on an unhydrated collection it returned `[]`, restoring #1414's silent empty read behind code that looks like it handles the edge case. The pending result's proxy target is now `[]` rather than `{}`; `IsArray` unwraps a proxy to its target, so the check answers `true` and the guard falls through to the throwing path. Every content access still throws `CollectionNotHydratedError` — the target is classified, never read.
+
+The docstring no longer claims the result "throws on any other use". It now enumerates the two operations that stay silent and cannot be made to throw — `typeof` (answered from the value's type) and truthiness (`ToBoolean` never calls a trap) — with the reason for each. That phrasing is what a consumer calibrates against, and a probe written against "any other use" passes vacuously because the phrase names no specific use.
+
+Export `./package.json` so a consumer can read hub's own manifest.
+
+Node refuses `require.resolve('@noy-db/hub/package.json')` with `ERR_PACKAGE_PATH_NOT_EXPORTED` unless the exports map names it — and hub's never did, on any version published. A consumer that needs the installed hub's exports map (`@noy-db/ui-nuxt` decides which query groups to register from it; `noy-db-as`'s codemod-row checker reads the same path) had to resolve the entry and walk up directories to find the manifest.
+
+Additive, no seam change, and nothing a bundler ships.
+
 ## 0.7.1-pre.0
 
 ### Patch Changes
@@ -8269,7 +8402,7 @@ This release also lands a build fix: `main` had been red since [#196](https://gi
 
 ## 0.1.0-pre.15
 
-A small fast-follow to pre.14's Dim 14 v2: extends `withMaterializedView` along two consumer-driven axes ([#165](https://github.com/vLannaAi/noy-db/issues/165) + [#166](https://github.com/vLannaAi/noy-db/issues/166)), folds in a pre.14 type-only cleanup ([#131](https://github.com/vLannaAi/noy-db/issues/131)), and resolves two niwat-review follow-ups ([#169](https://github.com/vLannaAi/noy-db/issues/169) + [#170](https://github.com/vLannaAi/noy-db/issues/170)). 5 issues closed, 1 PR merged ([#167](https://github.com/vLannaAi/noy-db/pull/167)), 28 new hub tests, 1601 hub tests on the tip.
+A small fast-follow to pre.14's Dim 14 v2: extends `withMaterializedView` along two consumer-driven axes ([#165](https://github.com/vLannaAi/noy-db/issues/165) + [#166](https://github.com/vLannaAi/noy-db/issues/166)), folds in a pre.14 type-only cleanup ([#131](https://github.com/vLannaAi/noy-db/issues/131)), and resolves two pilot-1-review follow-ups ([#169](https://github.com/vLannaAi/noy-db/issues/169) + [#170](https://github.com/vLannaAi/noy-db/issues/170)). 5 issues closed, 1 PR merged ([#167](https://github.com/vLannaAi/noy-db/pull/167)), 28 new hub tests, 1601 hub tests on the tip.
 
 ### Multi-key `groupBy` ([#166](https://github.com/vLannaAi/noy-db/issues/166))
 
@@ -8295,9 +8428,9 @@ Registration validation (new `MaterializedViewConfigError`):
 
 Executor path: reads each arm, runs per-source `map`, concatenates, then dispatches by shape (no groupBy → return as-is; groupBy without aggregate → dedupe via `canonicalGroupKey`, first row wins per composite key; groupBy + aggregate → delegate to `groupAndReduce`). Source-write hook fires on every arm via the existing dependency reverse-index — `Collection.put` is unchanged.
 
-`summarizeUnionPlan` hashes arm collection names in **declaration order** (semantically meaningful for the dedup-only path — first-seen row per composite key wins, and reordering arms must trigger a refresh). `groupBy` fields and `aggregate` keys are still sorted (genuinely commutative). Two regression tests pin the asymmetry. (niwat review, [#167](https://github.com/vLannaAi/noy-db/pull/167) — first finding addressed in `6be47a2`.)
+`summarizeUnionPlan` hashes arm collection names in **declaration order** (semantically meaningful for the dedup-only path — first-seen row per composite key wins, and reordering arms must trigger a refresh). `groupBy` fields and `aggregate` keys are still sorted (genuinely commutative). Two regression tests pin the asymmetry. (pilot-1 review, [#167](https://github.com/vLannaAi/noy-db/pull/167) — first finding addressed in `6be47a2`.)
 
-`maxRows`, `onEmpty`, `strict` semantics inherited unchanged. Composes with multi-key groupBy: the niwat canonical monthly-VAT shape — `union(taxReceipts, creditNotes).groupBy('clientId', 'period').sum('vat')` — is the combined test fixture.
+`maxRows`, `onEmpty`, `strict` semantics inherited unchanged. Composes with multi-key groupBy: the pilot-1 canonical monthly-VAT shape — `union(taxReceipts, creditNotes).groupBy('clientId', 'period').sum('vat')` — is the combined test fixture.
 
 ### `GuardStrategyHandle` variance cleanup ([#131](https://github.com/vLannaAi/noy-db/issues/131))
 
@@ -8311,9 +8444,9 @@ The fix: a sealed internal `GuardStrategyHandleAny` existential interface (`{ __
 
 The single `any` retained inside the existential body is the established named-existential pattern — `any` is now contained behind a private named boundary instead of leaking from public-API field positions. Type-only refactor; no behaviour change; guards test suite (48 tests) and showcase 79 unchanged.
 
-### Niwat-review follow-ups
+### Pilot-1-review follow-ups
 
-`5b385e7` adds two registration guards from the niwat review of [#167](https://github.com/vLannaAi/noy-db/pull/167):
+`5b385e7` adds two registration guards from the pilot-1 review of [#167](https://github.com/vLannaAi/noy-db/pull/167):
 
 - [#169](https://github.com/vLannaAi/noy-db/issues/169) — UNION MV with `aggregate` requires `groupBy` (else the executor silently dropped the reducer)
 - [#170](https://github.com/vLannaAi/noy-db/issues/170) — `predicates` not supported on UNION MVs (predicate hashes weren't folded into `summarizeUnionPlan` and `.wherePredicate` never fired in the executor)
@@ -8326,7 +8459,7 @@ Both fail-fast at registration with `MaterializedViewConfigError`, same pattern
 
 ### Showcases + docs
 
-- [`85-with-multikey-groupby`](https://github.com/vLannaAi/noy-db/blob/main/showcases/src/85-with-multikey-groupby.showcase.test.ts) — variadic groupBy walkthrough, declaration-order assertions, niwat per-(client, period) shape
+- [`85-with-multikey-groupby`](https://github.com/vLannaAi/noy-db/blob/main/showcases/src/85-with-multikey-groupby.showcase.test.ts) — variadic groupBy walkthrough, declaration-order assertions, pilot-1 per-(client, period) shape
 - [`86-with-union-mv`](https://github.com/vLannaAi/noy-db/blob/main/showcases/src/86-with-union-mv.showcase.test.ts) — UNION MV walkthrough with the monthly-VAT example
 - `docs/services/aggregate.md` — new "Multi-key groupBy" section
 - `docs/services/derivations.md` — "Multi-key groupBy in MV queries" + "UNION sources" sections
@@ -8350,14 +8483,14 @@ Four fast-follow refinements that landed first to give the MV v2 work a hardened
 Query-level materialized views. Where `withDerivation` v1 projects one source row into N typed outputs, `withMaterializedView` materializes the result of an entire `Query<T>` — filter, groupBy, aggregate, join — into a queryable collection kept fresh on source writes. Six sub-issues across foundation, lifecycles, correctness, predicates, overlays, and showcases:
 
 - **Foundation** ([#150](https://github.com/vLannaAi/noy-db/issues/150), PR [#156](https://github.com/vLannaAi/noy-db/pull/156)) — `withMaterializedView({ name, query, rowKey, refresh })` factory; `MaterializedViewRegistry`; `MaterializedViewExecutor`; `Collection.put` source-write hook for eager refresh. `_materializedFrom` payload metadata (lives inside encrypted `_data`, opaque to the store — matches `_derivedFrom` precedent). `MaterializedViewCycleError` + `MaterializedViewSourceUnknownError`. New `@noy-db/hub/materialized-views` subpath.
-- **Lazy + manual lifecycles** ([#151](https://github.com/vLannaAi/noy-db/issues/151), PR [#157](https://github.com/vLannaAi/noy-db/pull/157)) — `refresh: 'lazy'` marks the MV stale on source writes; the next read of the MV output collection resolves on demand. `refresh: 'manual'` opts out of the source-write hook entirely; `vault.refreshView(name)` is the only refresh path. Returns `{ written, deleted, failed }` — niwat-review caught the original "deleted: 0 hardcode" pre-merge.
+- **Lazy + manual lifecycles** ([#151](https://github.com/vLannaAi/noy-db/issues/151), PR [#157](https://github.com/vLannaAi/noy-db/pull/157)) — `refresh: 'lazy'` marks the MV stale on source writes; the next read of the MV output collection resolves on demand. `refresh: 'manual'` opts out of the source-write hook entirely; `vault.refreshView(name)` is the only refresh path. Returns `{ written, deleted, failed }` — pilot-1-review caught the original "deleted: 0 hardcode" pre-merge.
 - **Correctness — partition / onEmpty / ceiling / strict / aggregate** ([#152](https://github.com/vLannaAi/noy-db/issues/152), PR [#158](https://github.com/vLannaAi/noy-db/pull/158)) — five strategy fields:
   - `output.partition: { field, value }` — same-collection edges are allowed when a where-clause provably excludes `partition.value` (`==` against a different value, `!=` against the value, `in` lists that exclude it). Cycle detector resolves these as non-cycles.
   - `onEmpty: 'delete' | 'keep'` (default `'delete'`) — when a key that previously emitted rows yields zero rows, tombstone via `Collection._internalDelete`. User `onDelete` guards on the output collection are bypassed for housekeeping (the composition fix that makes #145 + MV refresh coherent).
   - `maxRows` (default `100_000`) — row-count ceiling; throws `MaterializedViewTooLargeError` **before** any writes (clean rollback).
   - `strict: true` re-throws row-write failures → composes with `withTransactions` to roll back the source-write atomically via `revertExecuted` (the orphan-window fix from pre.12 #133).
   - **Aggregate / groupBy queries** — executor branches on the terminal shape (`Query<T>.toArray()` / `Aggregation.run()` / `GroupedAggregation.run()`). `groupBy().aggregate()` closes over its source so the dep analyzer can't introspect; aggregate MVs require explicit `sources?: string[]`.
-- **Declared deterministic predicates** ([#153](https://github.com/vLannaAi/noy-db/issues/153), PR [#159](https://github.com/vLannaAi/noy-db/pull/159)) — `MaterializedViewStrategy.predicates: { [name]: { hash, fn } }` registers named functions callable from inside the MV's `query()` callback via `.wherePredicate(name, ctx?)`. The predicate's `hash` **and** a canonical-JSON hash of the `ctx` argument both fold into `queryHash` — bumping `hash` or changing `ctx` forces refresh. Canonical use: `isOverdue` against an `asOf` date that moves externally. Niwat-review caught the original "predicates dropped through chain methods" pre-merge: every chain operator (`where`, `or`, `and`, `filter`, `orderBy`, `limit`, `offset`, `join`) now threads the predicates map.
+- **Declared deterministic predicates** ([#153](https://github.com/vLannaAi/noy-db/issues/153), PR [#159](https://github.com/vLannaAi/noy-db/pull/159)) — `MaterializedViewStrategy.predicates: { [name]: { hash, fn } }` registers named functions callable from inside the MV's `query()` callback via `.wherePredicate(name, ctx?)`. The predicate's `hash` **and** a canonical-JSON hash of the `ctx` argument both fold into `queryHash` — bumping `hash` or changing `ctx` forces refresh. Canonical use: `isOverdue` against an `asOf` date that moves externally. Pilot-1-review caught the original "predicates dropped through chain methods" pre-merge: every chain operator (`where`, `or`, `and`, `filter`, `orderBy`, `limit`, `offset`, `join`) now threads the predicates map.
 - **Overlay views — `withOverlayedView`** ([#154](https://github.com/vLannaAi/noy-db/issues/154), PR [#160](https://github.com/vLannaAi/noy-db/pull/160)) — read-shadow primitive. Declares a virtual collection that merges a `base` (typically an MV output) with a user-writable `overlay` via a single-field shadow predicate (`overlay[shadowField] === shadowValue`). Writes through the virtual proxy route to the overlay. Constraints: `base` must be concrete (no overlay-on-overlay stacking — v3 non-goal); `overlay` must not be an MV output; virtual name must not collide with concrete collections or MV outputs. Four error classes (`OverlayBaseIsVirtualError`, `OverlayCollectionUnavailableError`, `OverlayNameCollisionError`, `OverlayIdMismatchError`).
 - **Showcases + reader-facing docs** ([#155](https://github.com/vLannaAi/noy-db/issues/155), PR [#161](https://github.com/vLannaAi/noy-db/pull/161)) — four new showcases (`81-with-mv-eager`, `82-with-mv-lazy`, `83-with-overlay`, `84-with-mv-predicates`) totaling 19 tests; `docs/services/derivations.md` extended with Materialized Views + Overlay views sections; `features.yaml` entries for `materialized-views` and `overlay-views`.
 
@@ -8373,9 +8506,9 @@ The pre.14 release closes the loop on the write-path primitive composition:
 
 The `Collection._internalDelete` housekeeping bypass (introduced in #148 for #144's tombstoning) is the load-bearing primitive that keeps `withGuard.onDelete: throw` rules coherent with system-driven tombstones from optional derivations and MV `onEmpty: 'delete'` flows.
 
-### Process notes for niwat integration
+### Process notes for pilot-1 integration
 
-- All five MV PRs (#156–#160) plus #161 passed niwat-review with "No issues found" verdicts after pre-merge fixes. The niwat-review pattern that worked: surface composition issues (e.g. "list/query/scan don't trigger lazy resolve", "chain methods drop predicates map") before the PR landed on main.
+- All five MV PRs (#156–#160) plus #161 passed pilot-1-review with "No issues found" verdicts after pre-merge fixes. The pilot-1-review pattern that worked: surface composition issues (e.g. "list/query/scan don't trigger lazy resolve", "chain methods drop predicates map") before the PR landed on main.
 - Stacked-PR rebase pattern documented in [project memory](https://github.com/vLannaAi/noy-db/blob/main/) after this cycle: when squash-merging a stack of N PRs, the canonical recovery for the (N+1)th descendant is `reset --hard origin/main && cherry-pick <descendant-only-commits>` rather than re-rebasing the original branch. Re-rebasing leaks conflict markers when the parent's content has been merged with reviewer-fix tweaks.
 
 ### Files of interest
@@ -8542,7 +8675,7 @@ A 2026-05-09 deep-review of the pre.9 surface (security + API consistency) filed
 
 ### Consumer-iteration cycle on pre.8 APIs
 
-Closes the 5-issue follow-up batch surfaced after Niwat (first production consumer) shipped pre.8 to production. No new subsystems; surgical extensions to APIs that landed in pre.8.
+Closes the 5-issue follow-up batch surfaced after Pilot-1 (first production consumer) shipped pre.8 to production. No new subsystems; surgical extensions to APIs that landed in pre.8.
 
 #### New public APIs
 
@@ -8572,7 +8705,7 @@ Closes the 5-issue follow-up batch surfaced after Niwat (first production consum
 
 ### Authentication surface — major auth-review batch
 
-Closes the 12-issue auth-review filed at the start of this milestone. Driven by feedback from the first production consumer (Niwat); the pre.8 surface is what they need to drop ~250 LOC of vendored workarounds.
+Closes the 12-issue auth-review filed at the start of this milestone. Driven by feedback from the first production consumer (Pilot-1); the pre.8 surface is what they need to drop ~250 LOC of vendored workarounds.
 
 #### New public APIs
 
@@ -8641,9 +8774,9 @@ Closes the 12-issue auth-review filed at the start of this milestone. Driven by
 
   See `docs/services/user-envelope.md`, `docs/recipes/user-preferences.md`, `showcases/src/70-user-envelope.showcase.test.ts`, and `showcases/src/recipe-user-preferences.recipe.test.ts`.
 
-- **`db.enrollWebAuthn(vault, ceremony, presented?)`** ([#16](https://github.com/vLannaAi/noy-db/issues/16)) — native WebAuthn enrollment using the **real** internal keyring. Unblocks `vLannaAi/niwat#31`. The ceremony callback receives the live `UnlockedKeyring` so the `wrapped_kek` references the live KEK (not the synthetic-keyring workaround that broke unlock). Hub does not import `@noy-db/on-webauthn` (would invert dep graph); consumers wire the on-webauthn `enrollWebAuthn` function in via the ceremony callback. Companion `db.listWebAuthnSlots(vault)` returns webauthn-method slots only.
+- **`db.enrollWebAuthn(vault, ceremony, presented?)`** ([#16](https://github.com/vLannaAi/noy-db/issues/16)) — native WebAuthn enrollment using the **real** internal keyring. Unblocks `pilot-1#31`. The ceremony callback receives the live `UnlockedKeyring` so the `wrapped_kek` references the live KEK (not the synthetic-keyring workaround that broke unlock). Hub does not import `@noy-db/on-webauthn` (would invert dep graph); consumers wire the on-webauthn `enrollWebAuthn` function in via the ceremony callback. Companion `db.listWebAuthnSlots(vault)` returns webauthn-method slots only.
 
-- **`db.lockVault(vault)`** ([#17](https://github.com/vLannaAi/noy-db/issues/17)) — soft lock that scrubs `keyringCache`, `vaultCache`, `activeTier`, `syncEngines`, `policyEnforcers` for the vault, but **preserves `quickUnlock`** (PIN resume after lock-screen UX) and `policyCache` (on-disk policy survives lock). Idempotent; the `Noydb` instance remains usable. Unblocks `vLannaAi/niwat#33`.
+- **`db.lockVault(vault)`** ([#17](https://github.com/vLannaAi/noy-db/issues/17)) — soft lock that scrubs `keyringCache`, `vaultCache`, `activeTier`, `syncEngines`, `policyEnforcers` for the vault, but **preserves `quickUnlock`** (PIN resume after lock-screen UX) and `policyCache` (on-disk policy survives lock). Idempotent; the `Noydb` instance remains usable. Unblocks `pilot-1#33`.
 
 - **New built-in policy gates** — `edit-own-profile` and `view-team-profiles` registered in `PERSONAL_POLICY` and `STRICT_POLICY`. Apps can tighten (e.g. require TOTP for profile edits) but cannot relax the own-only write rule (structural, not policy-controlled).
 

package/LICENSE

@@ -1,21 +1,202 @@
-MIT License
-
-Copyright (c) 2026 vLannaAi
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 vLannaAi
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/NOTICE

@@ -0,0 +1 @@
+noy-db — Copyright 2026 vLannaAi

package/README.md

@@ -20,9 +20,9 @@ declare const lines: Collection<Line>
 > Zero-knowledge, offline-first, encrypted document store — core library.
 
 [![npm](https://img.shields.io/npm/v/@noy-db/hub.svg)](https://www.npmjs.com/package/@noy-db/hub)
-[![license](https://img.shields.io/npm/l/@noy-db/hub.svg)](https://github.com/vLannaAi/noy-db/blob/main/LICENSE)
+[![license](https://img.shields.io/npm/l/@noy-db/hub.svg)](https://github.com/noy-db/core/blob/main/LICENSE)
 
-Part of [**noy-db**](https://github.com/vLannaAi/noy-db) — *"None Of Your Damn Business"*. This is the **core library** — install this first, then pair it with a storage backend.
+Part of [**noy-db**](https://github.com/noy-db/core) — *"None Of Your Damn Business"*. This is the **core library** — install this first, then pair it with a storage backend.
 
 ## Install
 
@@ -334,9 +334,9 @@ pnpm add @noy-db/hub@next @noy-db/to-memory@next
 
 ## Documentation
 
-- Full docs: <https://github.com/vLannaAi/noy-db-docs>
-- Spec: <https://github.com/vLannaAi/noy-db-docs/blob/main/SPEC.md>
-- Roadmap: <https://github.com/vLannaAi/noy-db-docs/blob/main/ROADMAP.md>
+- Full docs: <https://github.com/noy-db/docs>
+- Spec: <https://github.com/noy-db/docs/blob/main/SPEC.md>
+- Roadmap: <https://github.com/noy-db/docs/blob/main/ROADMAP.md>
 
 ## License
 

package/codemods/0.8.0-pre.json

@@ -0,0 +1,61 @@
+{
+  "$comment": "Machine-readable migration map for noy-db#1458 — the QUERY TIERS split. The query DSL was one class in one subpath; it is now four groups. `@noy-db/hub/query` keeps Find (where/or/and/filter/wherePredicate/orderBy/limit/offset/page/after/first/toArray/count/exists/ids/toPlan) and is unchanged for consumers who only find records. Live, Reduce and Relate moved to `@noy-db/hub/query/{live,reduce,relate}`, which are SIDE-EFFECT imports: one line at the app's entry patches the methods onto Query.prototype and merges their types, so no call site changes. ⭐ WHO IS AFFECTED, precisely: only consumers who import from `@noy-db/hub/query` directly. A consumer on the root barrel `@noy-db/hub` needs NO row here — the root barrel imports all three groups, so every method and every re-export is exactly where it was. That is why the rows below are `import-move` rather than `subpath`: the SUBPATH `@noy-db/hub/query` still resolves and still exports Find; what moved is a set of symbols within it. ⚠️ THE COVERAGE CHECKER CANNOT SEE THIS BREAK. `scripts/check-codemod-coverage.mjs` measures the package's whole reachable surface as a union across subpaths, and every symbol below is still reachable — from a different subpath. It reports zero losses for this change, correctly by its own definition and uselessly for this one. These rows are hand-written for that reason; do not read the green checker as evidence the map is unnecessary.",
+  "version": "0.8.0-pre",
+  "renames": [
+    {
+      "from": "@noy-db/hub/query:applyJoins",
+      "to": "@noy-db/hub/query/relate:applyJoins",
+      "kind": "import-move",
+      "package": "@noy-db/hub",
+      "safeGlobalReplace": false,
+      "section": "query-tiers",
+      "note": "Relate's free functions moved with the group. `safeGlobalReplace: false` throughout this map: the symbol name is unchanged, so a global find-and-replace on the NAME is meaningless — the edit is to the import SPECIFIER, and only in files that import from '@noy-db/hub/query'."
+    },
+    { "from": "@noy-db/hub/query:DEFAULT_JOIN_MAX_ROWS", "to": "@noy-db/hub/query/relate:DEFAULT_JOIN_MAX_ROWS", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:DEFAULT_CROSS_JOIN_MAX_ROWS", "to": "@noy-db/hub/query/relate:DEFAULT_CROSS_JOIN_MAX_ROWS", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:resetJoinWarnings", "to": "@noy-db/hub/query/relate:resetJoinWarnings", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:runTraversal", "to": "@noy-db/hub/query/relate:runTraversal", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:explainPlan", "to": "@noy-db/hub/query/relate:explainPlan", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:renderExplainText", "to": "@noy-db/hub/query/relate:renderExplainText", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:ALL_PARTITIONS", "to": "@noy-db/hub/query/relate:ALL_PARTITIONS", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:describePartitionScope", "to": "@noy-db/hub/query/relate:describePartitionScope", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:partitionsInScope", "to": "@noy-db/hub/query/relate:partitionsInScope", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:resolvePartitionScope", "to": "@noy-db/hub/query/relate:resolvePartitionScope", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    {
+      "from": "@noy-db/hub/query:JoinTooLargeError",
+      "to": "@noy-db/hub/query/relate:JoinTooLargeError",
+      "kind": "import-move",
+      "package": "@noy-db/hub",
+      "safeGlobalReplace": false,
+      "section": "query-tiers",
+      "note": "⚠️ An `instanceof` check, not just an import. The class is the same object — it comes from the same `kernel/errors.ts` and hub builds with code-splitting so cross-subpath identity holds — so a consumer who catches it from the ROOT barrel is unaffected. Only the import specifier in a `/query`-importing file changes. Same for the four errors below."
+    },
+    { "from": "@noy-db/hub/query:DanglingReferenceError", "to": "@noy-db/hub/query/relate:DanglingReferenceError", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:TraversalCycleError", "to": "@noy-db/hub/query/relate:TraversalCycleError", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:CrossJoinTooLargeError", "to": "@noy-db/hub/query/relate:CrossJoinTooLargeError", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:CrossJoinSourceUnknownError", "to": "@noy-db/hub/query/relate:CrossJoinSourceUnknownError", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:buildLiveQuery", "to": "@noy-db/hub/query/live:buildLiveQuery", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:dateTrunc", "to": "@noy-db/hub/query/reduce:dateTrunc", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:isDateTruncKey", "to": "@noy-db/hub/query/reduce:isDateTruncKey", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:truncateDate", "to": "@noy-db/hub/query/reduce:truncateDate", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" },
+    { "from": "@noy-db/hub/query:GroupCardinalityError", "to": "@noy-db/hub/query/reduce:GroupCardinalityError", "kind": "import-move", "package": "@noy-db/hub", "safeGlobalReplace": false, "section": "query-tiers" }
+  ],
+  "sideEffectImports": [
+    {
+      "subpath": "@noy-db/hub/query/live",
+      "methods": ["subscribe", "live"],
+      "note": "Add `import '@noy-db/hub/query/live'` once, anywhere in the app's entry, if any file calls these on a Query obtained through `@noy-db/hub/query`."
+    },
+    {
+      "subpath": "@noy-db/hub/query/reduce",
+      "methods": ["aggregate", "groupBy", "window", "distinct", "scan().aggregate", "scan().groupBy"],
+      "note": "The METHODS, not the aggregate SERVICE. `withReduce()` from `@noy-db/hub/reduce` is still what makes them compute; these are two different opt-ins and both are still required."
+    },
+    {
+      "subpath": "@noy-db/hub/query/relate",
+      "methods": ["join", "joinOn", "rightJoin", "fullOuterJoin", "crossJoin", "crossJoinWith", "traverse", "ancestorsOf", "descendantsOf", "explain", "scan().join"],
+      "note": "Also fills the executor's join hooks, so a plan carrying legs built elsewhere can run."
+    }
+  ],
+  "$sideEffectComment": "Not `renames`, because nothing is renamed: this field lists the imports a consumer must ADD. Omitting one is caught by `tsc` — the method's type ships with its subpath, so the call does not compile — and at runtime by QueryExtensionMissingError, which names the method and the subpath. A consumer on the root barrel adds nothing."
+}

package/dist/api-OS747DS4.js

@@ -0,0 +1,18 @@
+import {
+  UserApi,
+  createUserApi
+} from "./chunk-AEQGFRU4.js";
+import "./chunk-LIOVX5TJ.js";
+import "./chunk-EZGV6F47.js";
+import "./chunk-OIEO4WDL.js";
+import "./chunk-Q2XRFWOI.js";
+import "./chunk-NH2UOV3B.js";
+import "./chunk-42ALPZ2B.js";
+import "./chunk-QMWY2FDS.js";
+import "./chunk-SV2PM2OY.js";
+import "./chunk-37EPTBBR.js";
+export {
+  UserApi,
+  createUserApi
+};
+//# sourceMappingURL=api-OS747DS4.js.map