@noy-db/hub 0.3.0-pre.9 → 0.3.0

package/dist/subject-index-CyOgGMJL.d.ts

@@ -1,380 +0,0 @@
-/**
- * Ledger entry shape + canonical JSON + sha256 helpers.
- *
- * This file holds the PURE primitives used by the hash-chained ledger:
- * the entry type, the deterministic (sort-stable) JSON encoder, and
- * the sha256 hasher that produces `prevHash` and `ledger.head()`.
- *
- * Everything here is validator-free and side-effect free — the only
- * runtime dep is Web Crypto's `subtle.digest` for the sha256 call,
- * which we already use for every other hashing operation in the core.
- *
- * The hash chain property works like this:
- *
- *   hash(entry[i])       = sha256(canonicalJSON(entry[i]))
- *   entry[i+1].prevHash  = hash(entry[i])
- *
- * Any modification to `entry[i]` (field values, field order, whitespace)
- * produces a different `hash(entry[i])`, which means `entry[i+1]`'s
- * stored `prevHash` no longer matches the recomputed hash, which means
- * `verify()` returns `{ ok: false, divergedAt: i + 1 }`. The chain is
- * append-only and tamper-evident without external anchoring.
- */
-interface LedgerEntry {
-    /**
-     * Zero-based sequential position of this entry in the chain. The
-     * canonical adapter key is this number zero-padded to 10 digits
-     * (`"0000000001"`) so lexicographic ordering matches numeric order.
-     */
-    readonly index: number;
-    /**
-     * Hex-encoded sha256 of the canonical JSON of the PREVIOUS entry.
-     * The genesis entry (index 0) has `prevHash === ''` — the first
-     * entry in a fresh vault has nothing to point back to.
-     */
-    readonly prevHash: string;
-    /**
-     * Which kind of mutation this entry records. only supports
-     * data operations (`put`, `delete`, `amendment`). Access-control
-     * operations (`grant`, `revoke`, `rotate`) will be added in a
-     * follow-up once the keyring write path is instrumented — that's
-     * tracked in the epic issue.
-     *
-     * `'amendment'` is the multi-record audit entry written by the
-     * guards service when an admin/owner uses `withTransactions(...)`
-     * to repair a constraint-violating state. See `amendment` field
-     * below for the structured payload.
-     *
-     * `'lifecycle'` records a non-data audit event (e.g. partition
-     * handover) — `collection`/`id` are empty and the event detail
-     * lives in `reason` (e.g. `'partition-handed-over:<sealId>'`). Like
-     * `amendment`, it carries no data envelope, so `verifyBackupIntegrity`
-     * skips it in the data cross-check (it still participates in the
-     * tamper-evident chain).
-     *
-     * `'forget'` is the single summary entry written by `vault.forget()`
-     * (GDPR crypto-shred). `collection`/`id` are empty and `version`
-     * is 0 — a forget is not scoped to one record. `payloadHash` carries
-     * `sha256Hex(subjectId)` so the ledger PROVES "subject X existed and
-     * was erased on date D" without retaining the subject id or any
-     * plaintext; `reason` holds a JSON summary of the shred counts. Like
-     * `amendment`/`lifecycle` it carries no data envelope and is skipped
-     * by the reconstruct walker (it still participates in the chain, so
-     * `verify()` passes after a shred).
-     */
-    readonly op: 'put' | 'delete' | 'amendment' | 'lifecycle' | 'migration' | 'forget';
-    /** The collection the mutation targeted. */
-    readonly collection: string;
-    /** The record id the mutation targeted. */
-    readonly id: string;
-    /**
-     * The record version AFTER this mutation. For `put` this is the
-     * newly assigned version; for `delete` this is the version that
-     * was deleted (the last version visible to reads).
-     */
-    readonly version: number;
-    /** ISO timestamp of the mutation. */
-    readonly ts: string;
-    /** User id of the actor who performed the mutation. */
-    readonly actor: string;
-    /**
-     * Hex-encoded sha256 over the encrypted envelope's `_data` field, plus its
-     * sealed-field ciphertext map (`_sealed`) when the record carries one —
-     * so the ledger attests to both the open body and every sealed
-     * value. A record with no `_sealed` hashes `_data` alone.
-     * For `put`, this is the hash of the new ciphertext. For `delete`,
-     * it's the hash of the last visible ciphertext at deletion time, or the empty
-     * string if nothing was there to delete. Hashing the ciphertext (not the
-     * plaintext) preserves zero-knowledge — see the file docstring. The exact
-     * recipe lives in `envelopePayloadHash` (`hash.ts`).
-     */
-    readonly payloadHash: string;
-    /**
-     * Optional human-readable tag describing why this mutation happened.
-     * Threaded through `collection.put(_, _, { reason })`. Common
-     * values include `'import:csv'`, `'import:json'`, `'import:xlsx'` from
-     * `as-*` ImportPlan.apply(), but consumers can use any string for
-     * domain-specific audit filtering. Auto-strip via `canonicalJson` —
-     * absent on the wire, never serialized as `null`.
-     *
-     * Audit consumers filter: `entries.filter(e => e.reason?.startsWith('import:'))`.
-     */
-    readonly reason?: string;
-    /**
-     * Optional hex-encoded sha256 of the encrypted JSON Patch delta
-     * blob stored alongside this entry in `_ledger_deltas/`. Present
-     * only for `put` operations that had a previous version — the
-     * genesis put of a new record, and every `delete`, leave this
-     * field undefined.
-     *
-     * The delta payload itself lives in a sibling internal collection
-     * (`_ledger_deltas/<paddedIndex>`) and is encrypted with the
-     * ledger DEK. Callers use `ledger.loadDelta(index)` to decrypt and
-     * deserialize it when reconstructing a historical version.
-     *
-     * Why optional instead of always-present: the first put of a
-     * record has no previous version to diff against, so storing an
-     * empty patch would be noise. For deletes there's no "next" state
-     * to describe with a delta. Both cases set this field to undefined.
-     *
-     * Note: the canonical-JSON hasher treats `undefined` as invalid
-     * (it's one of the guard rails), so on the wire this field is
-     * either `{ deltaHash: '<hex>' }` or absent from the JSON
-     * entirely — never `{ deltaHash: undefined }`.
-     */
-    readonly deltaHash?: string;
-    /**
-     * Present only when `op === 'amendment'`. Records the human reason,
-     * the role of the actor, the (collection, id, vBefore, vAfter) tuple
-     * for every record touched, and which guard invariants passed.
-     *
-     * See docs/superpowers/specs/2026-05-18-guards-design.md.
-     */
-    readonly amendment?: {
-        readonly reason: string;
-        readonly role: 'admin' | 'owner';
-        readonly changes: ReadonlyArray<{
-            readonly collection: string;
-            readonly id: string;
-            readonly vBefore: number;
-            readonly vAfter: number;
-        }>;
-        readonly invariantsPassed: ReadonlyArray<string>;
-    };
-}
-/**
- * Canonical (sort-stable) JSON encoder.
- *
- * This function is the load-bearing primitive of the hash chain:
- * `sha256(canonicalJSON(entry))` must produce the same hex string
- * every time, on every machine, for the same logical entry — otherwise
- * `verify()` would return `{ ok: false }` on cross-platform reads.
- *
- * JavaScript's `JSON.stringify` is almost canonical, but NOT quite:
- * it preserves the insertion order of object keys, which means
- * `{a:1,b:2}` and `{b:2,a:1}` serialize differently. We fix this by
- * recursively walking objects and sorting their keys before
- * concatenation.
- *
- * Arrays keep their original order (reordering them would change
- * semantics). Numbers, strings, booleans, and `null` use the default
- * JSON encoding. `undefined` and functions are rejected — ledger
- * entries are plain data, and silently dropping `undefined` would
- * break the "same input → same hash" property if a caller forgot to
- * omit a field.
- *
- * Performance: one pass per nesting level; O(n log n) for key sorting
- * at each object. Entries are small (< 1 KB) so this is negligible
- * compared to the sha256 call.
- */
-declare function canonicalJson(value: unknown): string;
-/**
- * Compute a hex-encoded sha256 of a string via Web Crypto's subtle API.
- *
- * We use hex (not base64) for hashes because hex is case-insensitive,
- * fixed-length (64 chars), and easier to compare visually in debug
- * output. Base64 would save a few bytes in storage but every encrypted
- * ledger entry is already much larger than the hash itself.
- */
-declare function sha256Hex(input: string): Promise<string>;
-/**
- * Compute the canonical hash of a ledger entry. Short wrapper around
- * `canonicalJson` + `sha256Hex`; callers use this instead of composing
- * the two functions every time, so any future change to the hashing
- * pipeline (e.g., adding a domain-separation prefix) lives in one place.
- */
-declare function hashEntry(entry: LedgerEntry): Promise<string>;
-/**
- * Pad an index to the canonical 10-digit form used as the adapter key.
- * Ten digits is enough for ~10 billion ledger entries per vault
- * — far beyond any realistic use case, but cheap enough that the extra
- * digits don't hurt storage.
- */
-declare function paddedIndex(index: number): string;
-/** Parse a padded adapter key back into a number. Returns NaN on malformed input. */
-declare function parseIndex(key: string): number;
-
-/**
- * `withForgetCascade` — declaration surface for GDPR right-to-erasure via
- * per-record CEK crypto-shred.
- *
- * This file holds only the *declaration* shape and the disabled sentinel.
- * The actual erasure machinery lives in:
- *   - `subject-index.ts` — the encrypted `_subject_index` reserved collection
- *   - `vault.ts` `forget()` — the per-record tombstone + ledger flow
- *   - `collection.ts` `_writeTombstone` — the envelope rewrite
- *
- * A `ForgetStrategy` declares which collections carry erasable subject data
- * and the (dotted-path) field on each record that names the data subject.
- * Declaring a collection here ALSO forces `perRecordKeys: true` for it (a
- * shred can only erase a record whose body is keyed off a per-record CEK),
- * so adopters opt into the CEK foundation transitively.
- *
- * @module
- */
-
-/**
- * User-supplied declaration passed to {@link withForgetCascade}. Maps a
- * collection name to the record field (dotted path supported, e.g.
- * `'billing.buyerId'`) that identifies the data subject for erasure.
- *
- * ```ts
- * withForgetCascade({ subjects: { invoices: 'buyerId', contacts: 'id' } })
- * ```
- */
-interface SubjectDeclaration {
-    readonly subjects: Record<string, string>;
-}
-/**
- * Resolved forget strategy threaded through Noydb → every Vault. Carries
- * the same `subjects` map the user declared. `NO_FORGET` (empty map) is the
- * off-by-default sentinel; `vault.forget()` throws
- * `ForgetStrategyNotConfiguredError` when the map is empty.
- */
-interface ForgetStrategy {
-    /** Collection → subject-field (dotted path). Empty under `NO_FORGET`. */
-    readonly subjects: Readonly<Record<string, string>>;
-}
-/**
- * Disabled sentinel — no collections declare a subject field. `vault.forget()`
- * refuses with `ForgetStrategyNotConfiguredError`; no write hooks register; no
- * collection is forced into `perRecordKeys`. Non-adopters pay nothing.
- */
-declare const NO_FORGET: ForgetStrategy;
-/**
- * The outcome of a `vault.forget(subjectId)` call.
- *
- * `unmigratedRecords` lists `collection:id` pairs that were tombstoned but
- * whose body had NOT been migrated to a per-record CEK at shred time (legacy
- * body still under the shared collection DEK). Those records are tombstoned
- * (live envelope + history stripped) but their pre-shred ciphertext, if it
- * leaked into a backup before migration, remains decryptable under the
- * collection DEK — so erasure-completeness is NOT guaranteed for them. Run
- * the per-record-CEK migration pass, then re-forget, to close the gap.
- *
- * Blob attachments: a shredded record's **erasable** blobs (on a
- * `perRecordKeys` collection) are crypto-shredded inline — `blobsShredded`
- * counts those taken to refCount 0 (BlobObject deleted → chunks permanently
- * undecryptable), `blobsRetainedShared` counts those still referenced by
- * another record (shared content legitimately persists for its other owner).
- * `blobResidueCollections` now lists only collections with blobs that could
- * NOT be crypto-shredded: **legacy** blobs (no per-blob `_cek`, chunks under
- * the shared `_blob` DEK — migrate them), or a session without the blob
- * service loaded. An all-erasable subject yields an empty residue list.
- */
-interface ForgetResult {
-    /** The subject id passed to `forget()`. Echoed for caller convenience. */
-    readonly subject: string;
-    /** Count of live records rewritten to a tombstone. */
-    readonly recordsShredded: number;
-    /** Count of `_history` envelopes tombstoned across all shredded records. */
-    readonly historyVersionsShredded: number;
-    /** Distinct collections that had at least one record shredded. */
-    readonly collections: readonly string[];
-    /** `collection:id` pairs shredded while still un-migrated (see type docs). */
-    readonly unmigratedRecords: readonly string[];
-    /** Count of erasable blobs crypto-shredded (refCount → 0, BlobObject deleted). */
-    readonly blobsShredded: number;
-    /** Count of erasable blobs retained because still referenced elsewhere (shared). */
-    readonly blobsRetainedShared: number;
-    /** Collections with blobs that could NOT be crypto-shredded — legacy (no `_cek`) or blobs disabled (see type docs). */
-    readonly blobResidueCollections: readonly string[];
-    /**
-     * Count of persisted `_idx/<field>/<recordId>` index side-cars hard-deleted
-     * across the shredded records. These live under the retained
-     * collection DEK, so crypto-shred alone would leave the indexed field VALUES
-     * readable — `forget()` must delete them.
-     */
-    readonly indexPostingsPurged: number;
-    /**
-     * `collection:id:field` entries whose persisted `_idx` side-car could NOT be
-     * deleted — index residue that still leaks the indexed value under the
-     * retained collection DEK. Non-empty means erasure is INCOMPLETE: retry, or
-     * purge the side-car out of band.
-     */
-    readonly indexResidue: readonly string[];
-    /**
-     * Count of `_sealed[field]` slots dropped from the live store across the
-     * shredded records. For slots written under `sensitive` +
-     * `perRecordKeys` (the current path), the key derives off the per-record CEK,
-     * so tombstoning the record — which drops `_cek` and `_sealed` — also
-     * crypto-shreds the value. A legacy slot (written before per-record CEKs) keys
-     * off the collection DEK instead, so dropping it removes it from the live store but a
-     * pre-forget backup remains recoverable by a DEK holder (same caveat `_data`
-     * carries); migrate by re-`put`ting before forgetting for full crypto-shred.
-     */
-    readonly sealedFieldsShredded: number;
-    /** Count of `_sealed_cek` host-delivery envelopes deleted (#H-1). A record sealed to an
-     * at-* host via sealRecordToHost persists its raw CEK there; forget() must destroy them. */
-    readonly sealedCekEnvelopesPurged: number;
-    /** `collection:id` whose `_sealed_cek` purge failed (residue — the host-recoverable CEK may survive). */
-    readonly sealedCekResidue: readonly string[];
-    /** `collection:id:field` sealed slots that were DEK-derived (legacy, written before per-record CEKs) and thus NOT crypto-shredded
-     * by dropping `_cek` — the collection DEK is retained, so synced/backup copies stay decryptable (#M-1). */
-    readonly sealedResidue: readonly string[];
-    /** The single `op:'forget'` ledger entry appended for this erasure. */
-    readonly ledgerEntry: LedgerEntry;
-    /** #622 — record-grain derived artifacts (MV rows, per-record derived copies) erased
-     *  because their source subject was forgotten. Overlay outputs are intentionally out of
-     *  scope here — an overlay is always sourced from an MV, never directly from a subject
-     *  collection, so the personal-data-bearing MV rows it reads are already erased above. */
-    readonly derivedRecordsErased: number;
-    /** #622 — aggregate-grain targets (rollups) recomputed without the forgotten contribution. */
-    readonly derivedAggregatesRecomputed: number;
-    /** #622 — `collection:id` derived writes SKIPPED because the target period is frozen
-     *  (recompute deferred; the aggregate retains the forgotten contribution — audited). */
-    readonly derivedResidueFrozen: readonly string[];
-    /** #650 Task 5 (#648) — referencing records tombstoned via a `'ref'` edge's `cascade` policy. */
-    readonly lookupReferencesCascaded: number;
-    /** #650 Task 5 (#648) — referencing fields cleared via a `'ref'` edge's `nullify` policy. */
-    readonly lookupReferencesNullified: number;
-    /** #650 Task 5 review (Important fix) — `'ref'` edges whose compare-key could NOT be resolved,
-     *  even from the LIVE pre-shred backing row — cascade/nullify propagation was SKIPPED for these.
-     *  Always empty in the ordinary case; non-empty means the skip is reported, never silent. */
-    readonly lookupReferencesResidue: readonly string[];
-}
-
-/**
- * The encrypted subject index.
- *
- * GDPR crypto-shred needs to answer "which records belong to data subject
- * X?" portably (the index must travel with the vault/bundle) WITHOUT leaking
- * subject-equivalence to the store. The rejected alternative — an unencrypted
- * subject tag in envelope metadata — would let anyone with store access see
- * which records share a subject. Instead we keep a reserved `_subject_index`
- * collection, encrypted under its OWN DEK (`getDEK('_subject_index')`):
- *
- *   - record id  = `HMAC-SHA256(indexDEK, subjectId)` (M-2). A bare
- *     `sha256Hex(subjectId)` would be offline-computable: an attacker with
- *     store access and a candidate list (emails / customer ids are low-entropy)
- *     could dictionary the hash to confirm "subject X is present here." Keying
- *     the id with the vault-only index DEK removes that capability — without the
- *     DEK the id cannot be derived. (Legacy entries written before M-2 used the
- *     bare sha256 id; the read/remove paths dual-look-up both forms.)
- *   - record body = AES-GCM(JSON `{ r: [{ collection, id }], p }`) under the
- *     index DEK, where `p` pads the plaintext to a bucketed length so the
- *     ciphertext `_data` length does not leak the approximate record count.
- *     Legacy bodies were a bare `[{ collection, id }]` array; reads accept both.
- *
- * ## Concurrency (RISK #3 — known v1 limitation)
- *
- * `addSubjectRef` / `removeSubjectRef` are read-modify-write with no CAS. The
- * design assumes a SINGLE WRITER (the noy-db single-process write model). Two
- * concurrent writers racing on the SAME subject can lose an entry (last-write
- * wins on the ref list). This is documented, not fixed in v1:
- * `rebuildSubjectIndex` performs a full scan to recover a correct index from
- * the canonical records, so a lost ref is recoverable. A CAS-backed index is
- * deferred to a later slice.
- *
- * @module
- */
-
-/** Reserved collection holding the encrypted subject → records index. */
-declare const SUBJECT_INDEX_COLLECTION = "_subject_index";
-/** A single record reference held in a subject's index entry. */
-interface SubjectRef {
-    readonly collection: string;
-    readonly id: string;
-}
-
-export { type ForgetStrategy as F, type LedgerEntry as L, NO_FORGET as N, type SubjectDeclaration as S, type ForgetResult as a, SUBJECT_INDEX_COLLECTION as b, type SubjectRef as c, canonicalJson as d, parseIndex as e, hashEntry as h, paddedIndex as p, sha256Hex as s };

package/dist/sync/index.d.ts

@@ -1,40 +0,0 @@
-import { bW as SyncStrategy } from '../index-DzhNI2vE.js';
-import '../subject-index-CyOgGMJL.js';
-import '../index-B9QdHytu.js';
-import '@noy-db/attestation';
-
-/**
- * Active sync strategy — `withSync()` returns the real implementation
- * that wires the `SyncEngine`, `SyncTransaction`, and `PresenceHandle`
- * constructors into the Noydb / Vault / Collection hot paths.
- *
- * Consumers opt in by:
- *
- * ```ts
- * import { createNoydb } from '@noy-db/hub'
- * import { withSync } from '@noy-db/hub/sync'
- *
- * const db = await createNoydb({
- *   store: localStore,
- *   sync: remoteStore,
- *   user: ...,
- *   syncStrategy: withSync(),
- * })
- * ```
- *
- * The factory delegates to the existing `sync.ts`,
- * `sync-transaction.ts`, and `presence.ts` modules. Splitting the
- * import chain through this file is what lets tsup tree-shake the
- * ~856 LOC of replication + presence machinery out of the default
- * bundle when no `withSync()` import is present.
- *
- * Keyring + grant/revoke/magic-link/delegation stay in the always-on
- * core (or tree-shake via direct named imports) — those are required
- * for any multi-user vault, even purely local ones.
- *
- * @public
- */
-
-declare function withSync(): SyncStrategy;
-
-export { SyncStrategy, withSync };

package/dist/team/index.d.ts

@@ -1,154 +0,0 @@
-import { jz as TeamStrategy, c_ as NoydbStore, c8 as UnlockedKeyring } from '../index-DzhNI2vE.js';
-export { e8 as BundleRecipient, fO as EnrollAuthenticatorOptions, fP as EnrollAuthenticatorWrappingDEKsOptions, fQ as EnrollAuthenticatorWrappingKEKOptions, gQ as ListUsersOptions, hm as NO_TEAM, hF as PaperRecoveryEntry, hR as PresenceHandle, ik as RecoverPassphraseInput, il as RecoverPassphraseResult, im as RecoverUserOptions, iq as RecoveryProof, iC as RotatePassphraseInput, j8 as SlotRewrapCeremony, j9 as SlotRewrapContext, ji as SyncEngine, jq as SyncTransaction, jy as TeamNotEnabledError, jN as UpdateAuthenticatorOptions, k6 as WrappedDeksBlob, kh as buildRecipientKeyringFile, ki as burnPaperRecoveryEntry, lC as changeSecret, lD as createOwnerKeyring, ko as deriveMagicLinkContentKey, kt as enrollAuthenticator, lE as ensureCollectionDEK, ky as evaluateExportCapability, kA as evaluateImportCapability, kD as findAuthenticator, lF as grant, kE as hasExportCapability, kF as hasImportCapability, kI as isMagicLinkGrantExpired, kS as listMagicLinkGrants, kT as listUsers, kU as listUsersWithEnvelopes, lG as loadKeyring, kX as loadPaperRecoveryEntries, k$ as magicLinkGrantRecordId, l0 as mintPaperRecoveryEntry, l2 as mintWrappedDeksBlob, lH as persistKeyring, l7 as readMagicLinkGrantRecord, kP as recoverPassphrase, l9 as recoverUser, ld as removeAuthenticator, lI as revoke, lj as revokeMagicLinkGrant, kQ as rotatePassphrase, ll as savePaperRecoveryEntries, lp as unwrapDeksFromBlob, lq as unwrapDeksFromPaperEntry, ls as unwrapMagicLinkGrant, lJ as updateAuthenticator, lK as updateKeyringIdentity, lB as writeMagicLinkGrant } from '../index-DzhNI2vE.js';
-import '../subject-index-CyOgGMJL.js';
-import '../index-B9QdHytu.js';
-import '@noy-db/attestation';
-
-/**
- * Enable the multi-user team capability (#267 Track A tail).
- *
- * Pass to `createNoydb({ teamStrategy: withTeam() })` to make `db.grant` /
- * `db.revoke` / `db.rotate` live. The keyring grant/revoke/rotate engines
- * are statically imported HERE — this module is reachable only through the
- * `@noy-db/hub/team` subpath (and the root barrel's tree-shakeable
- * re-export), so a single-user floor bundle never carries them. The facade
- * (`TeamFacade.runGrant` / `runRevoke` / `runRotate`) owns the policy-gate +
- * keyring plumbing and receives the engine as an argument.
- */
-
-declare function withTeam(): TeamStrategy;
-
-/**
- * Secret-bearing reserved collections — the `_`-prefixed reserved collections
- * whose record CONTENTS are directly-usable secrets (transport OAuth tokens,
- * connection strings, API keys), as opposed to the *operational* reserved
- * collections (`_ledger`, `_history`, `_sync`, …) whose contents are metadata
- * (collection names, record ids, ciphertext hashes).
- *
- * This distinction matters at two trust-boundary seams:
- *
- *  1. `vault.collection()` — a secret-bearing reserved name must never be
- *     reachable through the generic public collection handle. It is served
- *     ONLY by its dedicated, role-gated API (e.g. `_sync_credentials` →
- *     `getCredential`/`putCredential`, which enforce owner/admin access).
- *
- *  2. `grant()` DEK propagation — a sub-admin grantee (operator, viewer,
- *     client, custodian) must NOT receive a secret-bearing collection's DEK.
- *     Operational reserved DEKs still propagate to every role (grantees must
- *     write ledger/history entries on every mutation), but handing a
- *     sub-admin the `_sync_credentials` DEK would let them decrypt the firm's
- *     transport secrets — a plaintext leak, not a metadata leak.
- *
- * Kept dependency-free so both the kernel (`vault.ts`) and the team layer
- * (`keyring.ts`) can import it without an import cycle.
- */
-/** Reserved collection holding per-adapter sync transport secrets. */
-declare const SYNC_CREDENTIALS_COLLECTION = "_sync_credentials";
-
-/**
- * _sync_credentials reserved collection —
- *
- * Stores per-adapter OAuth tokens (and any other long-lived sync secrets) as
- * encrypted records inside the vault itself. Tokens are wrapped with the
- * compartment's own DEK, live on disk as ciphertext like any other record, and
- * are accessed only through the dedicated API in this module — never via
- * `vault.collection('_sync_credentials')`.
- *
- * Design decisions
- * ────────────────
- *
- * **Why a reserved collection, not a separate store?**
- * The compartment's existing encryption stack (AES-256-GCM + collection DEK)
- * is exactly the right primitive for protecting OAuth tokens at rest. Using a
- * separate store would require a new encryption surface, new adapter calls,
- * and a new backup/restore path — all of which already exist for collections.
- *
- * **Why not exposed as a regular collection?**
- * The same reason `_keyring` and `_ledger` aren't: they have invariants that
- * must be enforced (naming scheme, no cross-user leakage, no schema
- * validation, no history/ledger writes for privacy). Routing through a
- * dedicated API enforces those invariants.
- *
- * **Token lifecycle:**
- * - `putCredential(vault, adapterId, token)` — store or overwrite
- * - `getCredential(vault, adapterId)` — load and decrypt
- * - `deleteCredential(vault, adapterId)` — remove
- * - `listCredentials(vault)` — enumerate adapter IDs (not tokens)
- *
- * The `adapterId` is the record ID within the `_sync_credentials` collection.
- * It should be a stable, human-readable identifier for the adapter instance
- * (e.g. `'google-drive'`, `'dropbox'`, `'s3-prod'`).
- *
- * **ACL:** only `owner` and `admin` roles can read/write sync credentials.
- * Operators, viewers, and clients cannot call this API. The check is made
- * against the caller's keyring role at call time.
- */
-
-/**
- * An OAuth/auth token stored in `_sync_credentials`.
- *
- * Fields mirror the OAuth2 token response shape. `customData` is an escape
- * hatch for adapter-specific secrets (API keys, connection strings, etc.)
- * that don't fit the OAuth2 shape.
- */
-interface SyncCredential {
-    /** Stable identifier for the adapter instance (e.g. 'google-drive'). */
-    readonly adapterId: string;
-    /** OAuth token type, usually 'Bearer'. */
-    readonly tokenType: string;
-    /** The access token. Expires at `expiresAt` if set. */
-    readonly accessToken: string;
-    /** Long-lived refresh token for renewing the access token. */
-    readonly refreshToken?: string;
-    /** ISO timestamp when `accessToken` expires. Absent means "no expiry". */
-    readonly expiresAt?: string;
-    /** Space-separated OAuth scopes. */
-    readonly scopes?: string;
-    /** Adapter-specific opaque data (API keys, endpoints, etc.). */
-    readonly customData?: Record<string, string>;
-}
-/**
- * Store or overwrite a sync credential for the given adapter.
- *
- * The credential is encrypted with the `_sync_credentials` collection DEK
- * (auto-generated on first use). The record ID is the `adapterId`.
- *
- * Requires owner or admin role.
- */
-declare function putCredential(adapter: NoydbStore, vault: string, keyring: UnlockedKeyring, credential: SyncCredential): Promise<void>;
-/**
- * Load and decrypt a sync credential for the given adapter ID.
- *
- * Returns `null` if no credential exists for this adapter.
- * Requires owner or admin role.
- */
-declare function getCredential(adapter: NoydbStore, vault: string, keyring: UnlockedKeyring, adapterId: string): Promise<SyncCredential | null>;
-/**
- * Delete a sync credential by adapter ID.
- *
- * No-op if the credential doesn't exist. Requires owner or admin role.
- */
-declare function deleteCredential(adapter: NoydbStore, vault: string, keyring: UnlockedKeyring, adapterId: string): Promise<void>;
-/**
- * List all adapter IDs that have stored credentials.
- *
- * Returns only the IDs, never the credential payloads. Useful for
- * displaying "connected adapters" in UI without decrypting tokens.
- * Requires owner or admin role.
- */
-declare function listCredentials(adapter: NoydbStore, vault: string, keyring: UnlockedKeyring): Promise<string[]>;
-/**
- * Check whether a credential exists and whether its access token has expired.
- *
- * Returns `{ exists: false }` if no credential is stored, or
- * `{ exists: true, expired: boolean }` based on the `expiresAt` field.
- * Requires owner or admin role.
- */
-declare function credentialStatus(adapter: NoydbStore, vault: string, keyring: UnlockedKeyring, adapterId: string): Promise<{
-    exists: false;
-} | {
-    exists: true;
-    expired: boolean;
-}>;
-
-export { SYNC_CREDENTIALS_COLLECTION, type SyncCredential, TeamStrategy, UnlockedKeyring, credentialStatus, deleteCredential, getCredential, listCredentials, putCredential, withTeam };

package/dist/tiers/index.d.ts

@@ -1,4 +0,0 @@
-export { lR as NO_TIERS, lS as TiersContext, jD as TiersNotEnabledError, lT as TiersStrategy, lU as assertDeclaredTier, lV as assertTiersEnabled, lW as classifySealedShred, lX as demote, lY as elevate, lZ as getAtTier, l_ as listAtTier, l$ as putAtTier, m0 as withTiers } from '../index-DzhNI2vE.js';
-import '../subject-index-CyOgGMJL.js';
-import '../index-B9QdHytu.js';
-import '@noy-db/attestation';

package/dist/to/index.d.ts

@@ -1,4 +0,0 @@
-export { dx as BundleVersionConflictError, fc as ConflictError, d0 as EncryptedEnvelope, gP as ListPageResult, hn as NetworkError, ht as NoydbBundleStore, bq as NoydbPodStore, c_ as NoydbStore, dB as PodVersionConflictError, jf as StoreCapabilities, jg as StoreCapabilityError, jh as StoreTime, jH as TxOp, jY as VaultSnapshot } from '../index-DzhNI2vE.js';
-import '../subject-index-CyOgGMJL.js';
-import '../index-B9QdHytu.js';
-import '@noy-db/attestation';