@noy-db/hub 0.3.0-pre.1 → 0.3.0-pre.11

package/dist/transition-guard-C7ol6oPw.d.ts

@@ -1,165 +0,0 @@
-import { bJ as GuardStrategy, bP as GuardStrategyHandle, bK as GuardChange, bL as GuardContext } from './index-BzUo1B6n.js';
-
-/**
- * Register a guard for a collection. Guards run on every `put()` /
- * `delete()` for the named collection (after permissions, before
- * encryption) and may:
- *
- *   - `check` — block writes by throwing (typically `RecordLockedError`)
- *   - `frozenFields` — freeze specific fields once a condition is true
- *   - `amendment` — declare an authorized-override path with invariant
- *
- * Pass the returned handle to `createNoydb({ strategies: [...] })`.
- *
- * @see docs/superpowers/specs/2026-05-18-guards-design.md
- */
-declare function withGuard<T extends Record<string, unknown>>(strategy: GuardStrategy<T>): GuardStrategyHandle<T>;
-
-/**
- * `immutableGuard` — declarative WORM / append-only sugar over the guard
- * service.
- *
- * Issued fiscal documents (invoices, DDTs) must be immutable after issue.
- * That is expressible today with a hand-rolled `withGuard` (block on
- * `check`/`onDelete`, allow an admin `amendment`), but the boilerplate is
- * repetitive and easy to get subtly wrong. `immutableGuard` generates
- * exactly that guard from a declarative config, reusing the guard
- * machinery wholesale — `check`/`onDelete` rejection, the ledgered
- * `amendment` override, and composition with `periods`/`history`.
- *
- * ```ts
- * createNoydb({ guardStrategies: [
- *   immutableGuard({
- *     collection: 'invoices',
- *     after: (r) => r.status === 'issued',   // immutable once issued
- *   }),
- * ] })
- * ```
- *
- * A record is mutable until `after(record)` holds; from then on, updates
- * and deletes throw `RecordLockedError` unless performed inside an
- * `amendment` transaction by an authorized role (the override is
- * ledgered by the guard amendment mechanism). `appendOnly: true` is
- * shorthand for `after: () => true` — immutable from creation.
- */
-
-interface ImmutableGuardConfig<T extends Record<string, unknown>> {
-    /** The collection to make WORM. */
-    collection: string;
-    /**
-     * A record becomes immutable once this predicate holds. Evaluated on
-     * the *existing* (already-persisted) record, so the write that first
-     * makes it true is still allowed; subsequent writes are blocked.
-     * Mutually exclusive with `appendOnly`.
-     */
-    after?: (record: T) => boolean;
-    /** Shorthand for `after: () => true` — immutable from creation. */
-    appendOnly?: boolean;
-    /** Roles permitted to override via an amendment transaction. Default `['admin', 'owner']`. */
-    amendmentRoles?: ReadonlyArray<'admin' | 'owner'>;
-    /**
-     * Optional set-level invariant run over the amendment change-set after
-     * the writes execute. Signature matches `GuardStrategy.amendment.invariant`
-     * exactly: it receives every {before, after} pair touching this
-     * collection in the amendment plus the guard context; throwing reverts
-     * the whole amendment and surfaces as `InvariantError`.
-     *
-     * Use this to keep a constraint inviolable EVEN under amendment — e.g.
-     * forbid deleting an issued document by re-throwing on any
-     * `before !== null && after === null` change, or assert a cross-record
-     * sum is preserved. When omitted the amendment is unconditionally
-     * allowed (the amendment itself is the sanctioned, ledgered override) —
-     * this is the backward-compatible default.
-     */
-    amendmentInvariant?: (changes: ReadonlyArray<GuardChange<T>>, ctx: GuardContext<T>) => Promise<void> | void;
-}
-/**
- * Build an immutability guard. Pass the returned handle to
- * `createNoydb({ guardStrategies: [...] })`.
- */
-declare function immutableGuard<T extends Record<string, unknown>>(config: ImmutableGuardConfig<T>): GuardStrategyHandle<T>;
-
-/**
- * `transitionGuard` — declarative state-machine sugar over the guard
- * service.
- *
- * Any record with a lifecycle field (invoice `status`, order state,
- * ticket workflow, subscription phase) needs transition validation: a
- * write may only move the field along a declared arc. That is expressible
- * with a hand-rolled `withGuard({ check })`, but every consumer
- * re-implements the same graph lookup + error. `transitionGuard`
- * generates exactly that guard from a state graph, reusing the guard
- * machinery wholesale — `check` rejection, the ledgered `amendment`
- * override, and composition with `periods`/`history`.
- *
- * It generalizes {@link immutableGuard}: WORM is the special case "every
- * state has no outgoing arcs", i.e. `transitions` mapping each state to `[]`.
- *
- * ```ts
- * createNoydb({ guardStrategies: [
- *   transitionGuard<Sale>({
- *     collection: 'sales', field: 'status',
- *     transitions: {                          // absence of an arc = forbidden
- *       draft: ['to_verify', 'cancelled'],
- *       to_verify: ['proforma', 'draft', 'cancelled'],
- *       proforma: ['invoiced', 'cancelled'],
- *       invoiced: ['paid'], paid: [], cancelled: [],
- *     },
- *     initial: ['draft', 'to_verify'],        // allowed status on insert
- *   }),
- * ] })
- * ```
- *
- * Semantics:
- * - **Insert** (`ctx.existing === null`): `incoming[field]` must be in
- *   `initial`. When `initial` is omitted, any value is allowed on insert.
- * - **Update**: the arc `(existing[field] → incoming[field])` must be
- *   listed in `transitions[from]`, else `IllegalTransitionError`. A
- *   same-value write (`from === to`) is allowed when `allowIdempotent`
- *   (default `true`) — so writes that touch other fields without moving
- *   state pass.
- * - **Override**: inside an `amendment` transaction by an authorized role
- *   the check is skipped and the change is ledgered (mirrors every guard).
- *
- * The status graph is caller-supplied data — no UI, no domain logic.
- */
-
-interface TransitionGuardConfig<T extends Record<string, unknown>> {
-    /** The collection whose state field is governed. */
-    collection: string;
-    /** The state field on the record (e.g. `'status'`). */
-    field: keyof T & string;
-    /**
-     * The transition graph: each state maps to the states it may move to.
-     * A state absent from the map (or mapped to `[]`) is terminal — no
-     * outgoing arc, so any non-idempotent write from it is rejected.
-     */
-    transitions: Readonly<Record<string, readonly string[]>>;
-    /**
-     * States allowed as the initial value on insert (`existing === null`).
-     * Omit to allow any value on insert.
-     */
-    initial?: readonly string[];
-    /**
-     * Allow a same-value write (`from === to`) on update. Default `true` —
-     * lets a put that changes other fields, but not the state, through.
-     */
-    allowIdempotent?: boolean;
-    /** Roles permitted to override via an amendment transaction. Default `['admin', 'owner']`. */
-    amendmentRoles?: ReadonlyArray<'admin' | 'owner'>;
-    /**
-     * Optional set-level invariant run over the amendment change-set after
-     * the writes execute. Signature matches `GuardStrategy.amendment.invariant`
-     * exactly. When omitted the amendment is unconditionally allowed (the
-     * amendment itself is the sanctioned, ledgered override) — the
-     * backward-compatible default. Mirrors {@link immutableGuard}.
-     */
-    amendmentInvariant?: (changes: ReadonlyArray<GuardChange<T>>, ctx: GuardContext<T>) => Promise<void> | void;
-}
-/**
- * Build a state-machine transition guard. Pass the returned handle to
- * `createNoydb({ guardStrategies: [...] })`.
- */
-declare function transitionGuard<T extends Record<string, unknown>>(config: TransitionGuardConfig<T>): GuardStrategyHandle<T>;
-
-export { type ImmutableGuardConfig as I, type TransitionGuardConfig as T, immutableGuard as i, transitionGuard as t, withGuard as w };

package/dist/tx/index.d.ts

@@ -1,35 +0,0 @@
-import { i_ as TransactionInvariant, kX as TxStrategy } from '../index-BzUo1B6n.js';
-export { kY as AmendmentTxOptions, j0 as TxCollection, dP as TxContext, j2 as TxVault, kx as runTransaction } from '../index-BzUo1B6n.js';
-import '../subject-index-O75wKshW.js';
-import '../describe-aBkJR2sd.js';
-import '../index-B9QdHytu.js';
-import '@noy-db/attestation';
-
-/**
- * Active transactions strategy. Only reachable via `@noy-db/hub/tx`.
- */
-
-/**
- * Options for {@link withTransactions}. Currently only commit-time
- * changeset `invariants` (see {@link TransactionInvariant}).
- */
-interface TransactionStrategyOptions {
-    /**
-     * Commit-time set-level invariants run over the changeset on every
-     * commit (ordinary AND amendment). See {@link TransactionInvariant}.
-     */
-    invariants?: ReadonlyArray<TransactionInvariant>;
-}
-/**
- * Build the default transactions strategy. Pass into
- * `createNoydb({ txStrategy: withTransactions() })` to enable
- * `db.transaction(fn)` (and `db.transaction({ dryRun: true }, fn)`).
- *
- * Supply `{ invariants }` to register commit-time changeset invariants —
- * set-level constraints that fire after the writes commit and revert the
- * transaction on a throw. Unlike `amendment.invariant`, these run for
- * ordinary `db.transaction(fn)` calls (and amendments) with no role gate.
- */
-declare function withTransactions(opts?: TransactionStrategyOptions): TxStrategy;
-
-export { TransactionInvariant, type TransactionStrategyOptions, TxStrategy, withTransactions };

package/dist/ui/index.d.ts

@@ -1 +0,0 @@
-export { C as CollectionDescription, a as CollectionMeta, D as DescribeOptions, b as DescribedField, F as FieldMeta, S as SemanticType } from '../describe-aBkJR2sd.js';

package/dist/ulid-DRH25k3y.d.ts

@@ -1,66 +0,0 @@
-/**
- * Minimal ULID generator — zero dependencies, Web Crypto API only.
- *
- *. Used by the bundle writer to generate stable opaque
- * handles for `.noydb` containers.
- *
- * **What's a ULID?** A 128-bit identifier encoded as 26 Crockford
- * base32 characters. Layout:
- *
- * ```
- *   01HYABCDEFGHJKMNPQRSTVWXYZ
- *   |--------||---------------|
- *    48-bit     80-bit
- *    timestamp  randomness
- * ```
- *
- * The first 10 chars encode a millisecond Unix timestamp (so ULIDs
- * sort lexicographically by creation time), and the remaining 16
- * chars are random. Crockford base32 omits I/L/O/U to avoid
- * ambiguity in handwriting and URLs.
- *
- * **Why hand-roll instead of pulling in `ulid`?** The package adds
- * a dep, the implementation is ~30 lines, and the bundle module
- * is the only consumer. Adding `ulid` would also drag in its own
- * crypto polyfill that we don't need on Node 18+ or modern
- * browsers.
- *
- * **Privacy consideration:** the timestamp prefix is observable in
- * the bundle header. This is a deliberate trade-off:
- *   - Pro: lexicographic sortability lets bundle adapters list
- *     newest-first without an extra index.
- *   - Con: a casual observer can read the bundle's creation time
- *     from the handle. They cannot read it from any OTHER field
- *     (the header explicitly forbids `_exported_at`), and a
- *     creation timestamp is the same kind of metadata that
- *     filesystem mtime would already expose for a downloaded
- *     bundle. The leak is therefore equivalent to what's already
- *     visible from the file's mtime — not a new exposure.
- *
- * If a future use case needs timestamp-free handles, a v2 of the
- * format could specify "use the random portion only" without a
- * format break — `validateBundleHeader` only checks the regex
- * shape, not the encoded timestamp.
- */
-/**
- * Generate a fresh ULID. Uses `crypto.getRandomValues` for the
- * randomness portion — same Web Crypto API the rest of the
- * codebase uses for IVs and salt.
- *
- * Returns a 26-character string. Calling twice in the same
- * millisecond produces two distinct ULIDs (the random portion
- * differs); ULIDs from the same millisecond are NOT guaranteed
- * to be monotonically ordered relative to each other, only
- * relative to ULIDs from a different millisecond. The bundle
- * format never relies on intra-millisecond ordering.
- */
-declare function generateULID(): string;
-/**
- * Validate that a string is a syntactically well-formed ULID. Used
- * by the bundle header validator. Does NOT verify that the
- * timestamp portion decodes to a sensible date — the format only
- * cares about the encoding shape.
- */
-declare function isULID(value: string): boolean;
-
-export { generateULID as g, isULID as i };

package/dist/util/index.d.ts

@@ -1,79 +0,0 @@
-export { i as isDiscriminant } from '../discriminant-BN9REW3o.js';
-
-/**
- * Target-profile aware filename sanitizer.
- *
- * Pure string in / string out. No filesystem access, no I/O. Use this
- * at the boundary where a user-supplied filename meets a storage
- * destination — local FS, ZIP archive, S3 key, URL path, SMB share —
- * to defuse the canonical 14-class footgun before it reaches that
- * destination.
- *
- * ## Threat model
- *
- *   1. Path injection — `..`, NUL bytes, `\` on POSIX, absolute paths.
- *   2. Windows reserved names — `CON`, `PRN`, `AUX`, `NUL`,
- *      `COM1-9`, `LPT1-9`, with or without an extension.
- *   3. Windows reserved chars — `< > : " / \ | ? *` plus ASCII 0-31.
- *   4. Trailing `.` and ` ` on Windows / SMB.
- *   5. Unicode normalization drift — same display, different bytes →
- *      "two files with the same name" sync ghosts.
- *   6. Bidi override spoofing — U+202E reversing `harmless.exe.txt`
- *      into `harmless.txt.exe`.
- *   7. URL `+` ambiguity in S3 presigned URLs.
- *   8. ZIP general-purpose-flag bit 11 (UTF-8 filename) optional in
- *      pre-2006 readers.
- *   9-14. Length caps, leading/trailing whitespace + controls,
- *      `.DS_Store`-style hidden noise, etc.
- *
- * ## Always-on transforms (every profile)
- *
- *   - NFC normalize (`String.prototype.normalize('NFC')`).
- *   - Reject NUL — hard fail, not strip. Silent strip enables a
- *     classic truncation bypass (`safe.txt\0.exe` → `safe.txt`).
- *   - Strip bidi overrides (`U+202A..U+202E`, `U+2066..U+2069`).
- *   - Trim leading/trailing whitespace and ASCII control chars.
- *
- * ## Non-goals (i18n boundary policy, )
- *
- *   - No transliteration.
- *   - No locale-aware slugging.
- *   - No script-specific segmentation.
- *
- * @module
- */
-/**
- * One of seven storage destinations the sanitizer knows how to defang
- * for. Pick the most restrictive that covers your write site:
- * `'macos-smb'` is the safe default for "I don't know where these
- * files end up but they're going to a real filesystem somewhere."
- */
-type FilenameProfile = 'posix' | 'windows' | 'macos-smb' | 'zip' | 'url-path' | 's3-key' | 'opaque';
-interface SanitizeFilenameOptions {
-    /** Target-destination profile. */
-    readonly profile: FilenameProfile;
-    /**
-     * Override the per-profile length cap. Useful when leaving headroom
-     * for a collision suffix — e.g. `maxBytes: 240` on a `posix` write
-     * site that wants 15 bytes of slack for `-1`, `-2`, …
-     */
-    readonly maxBytes?: number;
-    /**
-     * Required when `profile === 'opaque'`. The opaque profile replaces
-     * the entire input with `${opaqueId}.${ext}` (extension preserved
-     * from the input when present).
-     */
-    readonly opaqueId?: string;
-}
-/**
- * Sanitize a filename for a target-destination profile. Pure: same
- * input + options always returns the same output, no I/O.
- *
- * Returns the sanitized name. Throws {@link FilenameSanitizationError}
- * when the input cannot be made safe at all (NUL byte, empty after
- * normalization, missing `opaqueId` for the opaque profile,
- * `..` segment that would fall out of any reasonable target).
- */
-declare function sanitizeFilename(name: string, opts: SanitizeFilenameOptions): string;
-
-export { type FilenameProfile, type SanitizeFilenameOptions, sanitizeFilename };

package/dist/vault-diff-B5fYNBL7.d.ts

@@ -1,147 +0,0 @@
-import { V as Vault, cE as DiffEntry } from './index-BzUo1B6n.js';
-
-/**
- * Vault-level diff orchestrator.
- *
- * Compares a live `Vault`'s plaintext state against a candidate state
- * (another vault, a plain `{ collection: records[] }` map, or a vault
- * dump JSON) and returns a structured `VaultDiff` plan listing the
- * records that would be added, modified, or deleted to bring the live
- * vault into the candidate's shape.
- *
- * Builds on two existing record-level helpers:
- *
- *   1. `diff(a, b)` from `./history/diff.ts` — emits dot-pathed
- *      `DiffEntry[]` with `type: 'added' | 'removed' | 'changed'` for
- *      each changed field of two records. Used here for the
- *      `fieldDiffs` of every `modified` entry, and (with empty result)
- *      as the default deep-equal check.
- *
- *   2. `Vault.exportStream()` from `./vault.ts` — the canonical
- *      decrypt-and-stream-records iterator. Used to walk both sides
- *      when the candidate is itself a `Vault`. ACL-scoped: collections
- *      the caller can't read silently drop out, the same way every
- *      other plaintext-emitting export pipeline filters them.
- *
- * The new orchestration is the **vault-level** enumeration: bucket
- * each record id into added (only in candidate), deleted (only in
- * vault), or modified (in both with field changes); leave the
- * field-level granularity to the existing `diff()`.
- *
- * Use cases:
- *
- *   - Import preview (`@noy-db/as-*` `fromString` returns a plan
- *     whose body is a `VaultDiff`).
- *   - Backup verification ("does this `.noydb` bundle from yesterday
- *     match the current vault?").
- *   - Two-vault reconciliation ("what's different between Office A
- *     and Office B before we sync?").
- *   - Test assertions (golden-file testing with one-liner
- *     `expect(plan.summary).toEqual(...)`).
- *
- * @module
- */
-
-/** Per-record entry shape — added and deleted records carry only the record value. */
-interface VaultDiffEntry<T = unknown> {
-    readonly collection: string;
-    readonly id: string;
-    readonly record: T;
-    /**
-     * Unencrypted envelope metadata for the RECEIVER-side record.
-     * Populated only when `diffVault` is called with `{includeMetadata: true}`.
-     * Default: `undefined` (zero extra reads, no behavior change).
-     *
-     * Populated for `modified` (the CURRENT receiver state, before the candidate
-     * is applied) and `deleted` (the receiver envelope of the record being
-     * removed). `added` entries have no receiver envelope at diff time, so their
-     * `metadata` is always absent.
-     */
-    readonly metadata?: {
-        readonly version: number;
-        readonly timestamp: string;
-        readonly by?: string;
-        readonly source?: string;
-        readonly sourceTs?: string;
-    };
-}
-/** Modified records carry both halves of the diff plus the field-level breakdown. */
-interface VaultDiffModifiedEntry<T = unknown> extends VaultDiffEntry<T> {
-    /** The record as it stands in the live vault. */
-    readonly before: T;
-    /** Top-level keys whose values differ between `before` and `record`. */
-    readonly fieldsChanged: readonly string[];
-    /**
-     * Field-level diff entries from `diff(before, record)`. Reuses the
-     * existing per-record diff helper so consumers can render git-style
-     * `path: from → to` rows without re-walking the records.
-     */
-    readonly fieldDiffs: readonly DiffEntry[];
-}
-interface VaultDiff<T = unknown> {
-    readonly added: readonly VaultDiffEntry<T>[];
-    readonly modified: readonly VaultDiffModifiedEntry<T>[];
-    readonly deleted: readonly VaultDiffEntry<T>[];
-    /** Only populated when `options.includeUnchanged: true`. */
-    readonly unchanged: readonly VaultDiffEntry<T>[] | undefined;
-    readonly summary: {
-        readonly add: number;
-        readonly modify: number;
-        readonly delete: number;
-        readonly total: number;
-    };
-    /**
-     * Format the diff as a human-readable string.
-     *
-     *   - `'count'`   — one line, just the numbers (`12 added · 3 modified · 0 deleted`)
-     *   - `'one-line'` — count plus a single overview line
-     *   - `'full'`    — count + one row per added/modified/deleted record (default)
-     */
-    format(opts?: {
-        detail?: 'count' | 'one-line' | 'full';
-    }): string;
-}
-interface DiffOptions {
-    /** Restrict the diff to a subset of collections. */
-    readonly collections?: readonly string[];
-    /** Field on each record that carries its id. Defaults to `'id'`. */
-    readonly idKey?: string;
-    /** Override the default deep-equal check for "modified vs unchanged". */
-    readonly compareFn?: (a: unknown, b: unknown) => boolean;
-    /** If true, include unchanged records in the diff (off by default to save memory). */
-    readonly includeUnchanged?: boolean;
-    /**
-     * When `true`, each entry in `added`, `modified`, and `deleted` will carry a
-     * `metadata` field with the RECEIVER-side envelope metadata
-     * (`version`, `timestamp`, `by?`, `source?`, `sourceTs?`).
-     *
-     * Off by default — no extra adapter reads, no behavior change for existing callers.
-     */
-    readonly includeMetadata?: boolean;
-}
-/**
- * Candidate state to diff the vault against:
- *
- *   - A `Vault` instance — both sides are walked via `exportStream()`.
- *   - A `Record<collection, records[]>` map — same shape `as-json.toObject()`
- *     produces. Useful for diffing parsed file content against the live vault.
- *   - A `VaultDump` (output of `vault.dump()`) — a JSON string carrying the
- *     full vault state. Parsed and reduced to the map shape above.
- */
-type DiffCandidate<T = unknown> = Vault | Record<string, readonly T[]> | string;
-/**
- * Compute the diff between a live vault and a candidate state.
- *
- * Ungated shared import/merge infrastructure: the `as-*` exporters call this
- * internally from their `fromString`/import merge logic, so it is always
- * available (not behind `withCargo()`). Only `extractPartition` is a gated
- * cargo capability.
- *
- * Returns a fully buffered `VaultDiff` — no streaming. Memory cost is
- * O(n + m) in the row count of vault + candidate. For documented
- * 1K-50K-record vaults this is fine; a streaming variant lands as a
- * follow-up if a > 100K-record consumer arrives.
- */
-declare function diffVault<T = unknown>(vault: Vault, candidate: DiffCandidate<T>, options?: DiffOptions): Promise<VaultDiff<T>>;
-
-export { type DiffCandidate as D, type VaultDiff as V, type DiffOptions as a, type VaultDiffEntry as b, type VaultDiffModifiedEntry as c, diffVault as d };

package/dist/with/index.d.ts

@@ -1,38 +0,0 @@
-export { U as Unsubscribe, W as WriteEvent, a as WriteHook, b as WriteHookRegistry } from '../index-B9QdHytu.js';
-import { cF as UnlockedKeyring, cG as ExportFormat } from '../index-BzUo1B6n.js';
-export { cH as BusHandler, cI as GateDeleteEvent, cJ as GateEventMap, cK as GateHandler, cL as GatePoint, cM as GatePutEvent, cN as LifecycleEventMap, cO as LifecyclePoint, cP as ServiceBus, cQ as SubsystemBus } from '../index-BzUo1B6n.js';
-import '../subject-index-O75wKshW.js';
-import '../describe-aBkJR2sd.js';
-import '@noy-db/attestation';
-
-/**
- * Authorize an `@noy-db/as-*` export against the keyring's `exportCapability`.
- * Throws `ExportCapabilityError` if the keyring is not authorised.
- *
- * - plaintext tier requires a `format`; defaults to empty for every role.
- * - bundle tier defaults to on for owner/admin, off for others.
- */
-declare function assertCanExport(keyring: UnlockedKeyring, tier: 'plaintext' | 'bundle', format?: ExportFormat): void;
-/**
- * Authorize an `@noy-db/as-*` import against the keyring's `importCapability`.
- * Throws `ImportCapabilityError` if the keyring is not authorised.
- *
- * - plaintext tier requires a `format`; default-closed for every role.
- * - bundle tier is default-closed for every role, including owner — import is
- *   more dangerous than export (corrupts vs leaks).
- */
-declare function assertCanImport(keyring: UnlockedKeyring, tier: 'plaintext' | 'bundle', format?: ExportFormat): void;
-/**
- * Read-only accessor for the keyring's export capability, with role-based
- * defaults resolved. Useful for UI affordances (grey out the export button if
- * no capability) without throwing.
- */
-declare function canExport(keyring: UnlockedKeyring, tier: 'plaintext' | 'bundle', format?: ExportFormat): boolean;
-/**
- * Read-only accessor for the keyring's import capability. UI affordance —
- * returns false in every default-closed case (every role with no explicit
- * `importCapability` grant).
- */
-declare function canImport(keyring: UnlockedKeyring, tier: 'plaintext' | 'bundle', format?: ExportFormat): boolean;
-
-export { assertCanExport, assertCanImport, canExport, canImport };

package/dist/with-materialized-view-6p0Fk8bL.d.ts

@@ -1,27 +0,0 @@
-import { cf as MaterializedViewStrategy, cg as MaterializedViewStrategyHandle } from './index-BzUo1B6n.js';
-
-/**
- * Register a materialized view: a declared query whose result is
- * persisted as a queryable collection and kept fresh as sources
- * change. Writes go through the standard `Collection.put` pipeline;
- * refresh-driven deletes route through `Collection._internalDelete` so
- * user `onDelete` guards on the output collection aren't tripped by
- * housekeeping.
- *
- * Two registration modes:
- *   - **single-source** — declare `query: (db) => Query<TRow>`; the
- *     dependency analyzer derives source collections from the plan.
- *   - **UNION** — declare `unionSources: [{ collection, map }, ...]`
- *     plus optional `groupBy` + `aggregate`; the executor reads each
- *     arm, maps to the unified row shape, concatenates, then groups
- *     and aggregates.
- *
- * The two modes are mutually exclusive — exactly one of `query` /
- * `unionSources` must be set at registration time.
- *
- * See docs/superpowers/specs/2026-05-20-dim14-mv-v2-design.md (single-source v2)
- * and docs/superpowers/specs/2026-05-21-dim14-mv-multikey-and-union.md (UNION).
- */
-declare function withMaterializedView<TRow extends Record<string, unknown>>(spec: MaterializedViewStrategy<TRow>): MaterializedViewStrategyHandle;
-
-export { withMaterializedView as w };

package/dist/with-overlayed-view-BJ6mXGMd.d.ts

@@ -1,12 +0,0 @@
-import { ch as OverlayedViewStrategy, cq as OverlayedViewStrategyHandle } from './index-BzUo1B6n.js';
-
-/**
- * Register a read-shadow overlay: bind an MV-owned base collection to
- * a user-writable overlay so consumers can express operator-editable
- * lifecycles as one declarative block.
- *
- * See docs/superpowers/specs/2026-05-20-dim14-mv-v2-design.md.
- */
-declare function withOverlayedView(spec: OverlayedViewStrategy): OverlayedViewStrategyHandle;
-
-export { withOverlayedView as w };

package/dist/with-rollup-BvQo3ROo.d.ts

@@ -1,47 +0,0 @@
-import { c2 as DerivationStrategy, cb as DerivationStrategyHandle } from './index-BzUo1B6n.js';
-
-/**
- * Register a deterministic derivation: one source collection → one or
- * more typed outputs, computed by the user's `derive` function on
- * plaintext after DEK unwrap. Outputs are encrypted with the same DEK
- * as the source and written via the standard `Collection.put` path.
- *
- * See docs/superpowers/specs/2026-05-01-dim14-derivation-v1-design.md.
- */
-declare function withDerivation<TSource extends Record<string, unknown>, TOutputs extends Record<string, Record<string, unknown> | ReadonlyArray<Record<string, unknown>>>>(spec: DerivationStrategy<TSource, TOutputs>): DerivationStrategyHandle;
-
-/**
- * `withRollup` — aggregate many child records onto a single field of their
- * parent. The reverse of a join: instead of reading children
- * on demand, the parent carries a maintained summary.
- *
- * ```ts
- * withRollup<Sale, Buyer>({
- *   from: 'sales',          // child collection (the trigger)
- *   key: 'buyerId',         // FK on the child → parent id
- *   into: 'buyers',         // parent collection
- *   field: 'revenueByYear', // field on the parent to maintain
- *   compute: (sales) => groupSumByYear(sales, 'total'),
- * })
- * ```
- *
- * On every write OR delete of a `from` record, the parent at id `child[key]`
- * is recomputed: `compute(allChildren where child[key] === parentId)` is
- * patched onto `parent[field]`. A parent write also recomputes its own
- * aggregate (so a parent created after its children still fills in). Only the
- * `field` is touched — the rest of the parent record is never clobbered — and
- * a value-equality guard suppresses no-op writes. The aggregate is gap-free
- * with respect to child inserts, updates, and deletes.
- *
- * Desugars to a `withDerivation` strategy carrying a `rollup` marker; dispatch
- * handles it without invoking the executor. Eager-only in this slice.
- */
-declare function withRollup<TChild extends Record<string, unknown> = Record<string, unknown>, TParent extends Record<string, unknown> = Record<string, unknown>>(config: {
-    from: string;
-    key: keyof TChild & string;
-    into: string;
-    field: keyof TParent & string;
-    compute: (children: TChild[]) => unknown;
-}): DerivationStrategyHandle;
-
-export { withRollup as a, withDerivation as w };

package/dist/withdraw-accessible-FFS46EOD.js

@@ -1,22 +0,0 @@
-import {
-  FROZEN_SNAPSHOTS_COLLECTION,
-  freezeAndDeleteClosure,
-  freezeSnapshotOnly,
-  randomId,
-  withdrawAccessibleData
-} from "./chunk-PSMV73A5.js";
-import "./chunk-HCIPRAGS.js";
-import "./chunk-FISN7WE4.js";
-import "./chunk-SMXWYP24.js";
-import "./chunk-5O3AOPDT.js";
-import "./chunk-5TDJ56JE.js";
-import "./chunk-ZYUC53LT.js";
-import "./chunk-PZ5AY32C.js";
-export {
-  FROZEN_SNAPSHOTS_COLLECTION,
-  freezeAndDeleteClosure,
-  freezeSnapshotOnly,
-  randomId,
-  withdrawAccessibleData
-};
-//# sourceMappingURL=withdraw-accessible-FFS46EOD.js.map