@abloatai/ablo 0.36.0 → 0.37.1

package/dist/transaction/schema/relation.d.ts

@@ -1,204 +0,0 @@
-/**
- * Declarative relations between your models — the edges that turn a flat set
- * of models into a graph. You attach relations to a model with the
- * {@link relation} factories; the engine reads them to index foreign keys for
- * fast child lookups, to order inserts so a parent row lands before the rows
- * that reference it, and to generate the accessor properties that let you read
- * `task.project` or `project.tasks` directly.
- *
- * Usage:
- *   import { relation } from '@abloatai/ablo/schema';
- *
- *   const taskRelations = {
- *     project: relation.belongsTo('projects', 'projectId'),
- *     assignee: relation.belongsTo('users', 'assigneeId'),
- *     comments: relation.hasMany('comments', 'taskId'),
- *   };
- */
-/**
- * Options for `relation.belongsTo`. Each defaults to `false`, so every
- * behavior below is opt-in per relation.
- *
- * `index: true` registers a foreign-key index for the child model when the
- * engine starts, turning "every child that points at this parent" from a full
- * scan into a constant-time lookup. Reach for it on relations you query this
- * way often, such as a block's `sectionId`.
- *
- * `enrich: true` auto-populates the parent reference on an incoming change
- * before the child data lands. A change to `Task { teamId: 't1' }` picks up the
- * already-loaded `teams:t1` record and attaches it as `data.team`, so you can
- * read `task.team` without a second lookup. Enrichment is best-effort: if the
- * parent has not loaded yet it quietly does nothing, and the child data still
- * applies.
- *
- * `defer: true` tells the engine to ignore this edge when it works out the
- * order in which to insert rows. Use it on the soft side of a genuine reference
- * cycle — the side where you are willing to insert the child first with the
- * foreign key left null and fill it in with a later update. The other side of
- * the cycle then becomes a strict predecessor, so the child is ordered after
- * the parent rather than tied with it.
- *
- * `defer` changes only that ordering, not what the engine sends on the wire; it
- * does not rewrite an insert into an insert-then-update. Pair it with a Postgres
- * `DEFERRABLE INITIALLY DEFERRED` constraint when you also want the database to
- * relax the foreign-key check itself. For example:
- *
- *   ```ts
- *   layouts: model({ reportId: z.string().nullish() }, {
- *     // The report-owns-layout link is nullable and the layout is always
- *     // created first; marking it `defer` lets the report commit ahead of the
- *     // layout instead of sharing its insert-order slot.
- *     report: relation.belongsTo('reports', 'reportId', { defer: true }),
- *   }),
- *   ```
- */
-export interface BelongsToOptions {
-    readonly index?: boolean;
-    readonly enrich?: boolean;
-    readonly defer?: boolean;
-    /**
-     * Marks the relation's target as this record's parent: the entity the record
-     * lives inside and inherits its access scope from. When a record is written,
-     * the engine routes it into its parent's sync group — following a chain of
-     * `parent` edges all the way up — so the change reaches everyone subscribed to
-     * the owning entity. This is the familiar rule that access flows down from a
-     * container to the things it holds, as a folder does to its files.
-     *
-     * Do not set `parent` on a reference that merely points at another record for
-     * provenance or as a template, such as `sourceSectionId` or `templateId`; doing
-     * so would leak the record into an unrelated scope. The engine also cannot
-     * infer the parent from whether a field is optional — many real parent keys
-     * are optional, like a root folder or an inbox task — so you must declare the
-     * parent edge explicitly.
-     *
-     * It reads naturally at the call site:
-     * `belongsTo('report', 'reportId', { parent: true })` — the report is the parent.
-     */
-    readonly parent?: boolean;
-    /**
-     * Emit a real Postgres foreign-key constraint for this relation when the
-     * engine provisions tables in a customer-owned database. This is independent
-     * of `parent`: `parent` decides which subscribers a change reaches, while
-     * `fk` decides whether the database enforces referential integrity. A relation
-     * may set either, both, or neither.
-     *
-     * Set `fk: true` only when the target row lives in the same database and is
-     * written in the same commit as this row, and points at a strong, contained
-     * entity. Leave it off provenance or template pointers (`sourceSectionId`,
-     * `templateId`), cross-tenant references, or anything that may be written in a
-     * different transaction than its target — a hard constraint there would reject
-     * the write and break out-of-order sync. The constraint is emitted as
-     * `DEFERRABLE INITIALLY DEFERRED, ON DELETE NO ACTION`: a plain integrity
-     * guard, leaving any cascade or null-on-delete behavior to the application.
-     */
-    readonly fk?: boolean;
-}
-declare const __relationType: unique symbol;
-declare const __relationTarget: unique symbol;
-declare const __relationField: unique symbol;
-/**
- * The three edges the engine resolves. Inferred from `wire/modelShape.ts`
- * rather than restated: the set is reported to callers by `GET /api/schema`,
- * so it is protocol, and protocol has one definition.
- */
-export type { RelationType } from '../wire/modelShape.js';
-import type { RelationType } from '../wire/modelShape.js';
-/**
- * A relation definition, carrying its type information at both the type and
- * runtime level.
- *
- * The `Options` generic captures a relation's options in the type system; only
- * `belongsTo` uses it, while `hasMany` and `hasOne` leave it empty. The `const`
- * modifier on the `belongsTo` factory preserves literal inference, so
- * `{ enrich: true }` is remembered as `true` rather than widened to `boolean`,
- * letting type-level features read the exact option value.
- *
- * `options` is always present at runtime: the factory substitutes an empty
- * object when you omit it, so reading `options.index` or `options.enrich` needs
- * no null check.
- */
-export interface RelationDef<Type extends RelationType = RelationType, Target extends string = string, Field extends string = string, Options extends BelongsToOptions = BelongsToOptions> {
-    readonly [__relationType]: Type;
-    readonly [__relationTarget]: Target;
-    readonly [__relationField]: Field;
-    /** Runtime metadata */
-    readonly type: Type;
-    readonly target: Target;
-    /**
-     * The field on the child model that holds the parent's id, as a camelCase
-     * schema field name. The engine reads `model[foreignKey]` to resolve the
-     * relation and to build client-side index keys; it is never interpolated into
-     * raw SQL — that is what {@link foreignKeyColumn} is for.
-     */
-    readonly foreignKey: Field;
-    /**
-     * The same foreign key expressed as a database column identifier.
-     * {@link foreignKey} is translated into this when you configure a `casing`
-     * option on `defineSchema` — for example `'snake_case'` turns `messageId`
-     * into `message_id`. The server interpolates this column name into SQL
-     * directly, because a driver's automatic camelCase-to-snake_case mapping does
-     * not reach identifiers embedded in raw SQL; resolving the name once at
-     * schema-build time is what makes it available there.
-     *
-     * Defaults to {@link foreignKey} when no `casing` option is set, so consumers
-     * whose database columns already match their field names need no
-     * configuration.
-     */
-    readonly foreignKeyColumn: string;
-    readonly options: Options;
-    /**
-     * Optional sort field for `hasMany` relations. When set, the
-     * generated relation getter sorts results by this field. Populated
-     * by `relation.hasMany(target, fk, { orderBy: 'fieldName' })`.
-     */
-    readonly _orderBy?: string;
-}
-export declare const relation: {
-    /**
-     * This model belongs to another model via a foreign key.
-     * e.g., Task belongs to Project via projectId
-     *
-     * ```ts
-     * // Simple reference (no options)
-     * project: relation.belongsTo('projects', 'projectId'),
-     *
-     * // Register an FK index for O(1) child lookups
-     * section: relation.belongsTo('sections', 'sectionId', { index: true }),
-     *
-     * // Auto-populate the parent on delta arrival
-     * team: relation.belongsTo('teams', 'teamId', { enrich: true }),
-     *
-     * // Both
-     * parent: relation.belongsTo('threads', 'parentId', { index: true, enrich: true }),
-     *
-     * // Mark the soft side of a cycle so the priority computer breaks
-     * // the cycle deterministically instead of tying the two models.
-     * report: relation.belongsTo('reports', 'reportId', { defer: true }),
-     * ```
-     */
-    readonly belongsTo: <Target extends string, Field extends string, const Opts extends BelongsToOptions = Record<string, never>>(target: Target, foreignKey: Field, options?: Opts) => RelationDef<"belongsTo", Target, Field, Opts>;
-    /**
-     * This model has many of another model — for example, a project has many
-     * tasks via `Task.projectId`.
-     *
-     * At runtime the engine adds a getter to the parent model that returns every
-     * child whose foreign key matches, and registers the foreign-key index on the
-     * child model automatically.
-     *
-     * ```ts
-     * blocks: relation.hasMany('blocks', 'sectionId'),
-     * // → section.blocks returns all Block[] where sectionId === section.id
-     *
-     * blocks: relation.hasMany('blocks', 'sectionId', { orderBy: 'zIndex' }),
-     * // → section.blocks returns Block[] sorted by zIndex ascending
-     * ```
-     */
-    readonly hasMany: <Target extends string, Field extends string>(target: Target, foreignKey: Field, options?: {
-        orderBy?: string;
-    }) => RelationDef<"hasMany", Target, Field>;
-    /**
-     * This model has one of another model — for example, a user has one profile
-     * via `Profile.userId`.
-     */
-    readonly hasOne: <Target extends string, Field extends string>(target: Target, foreignKey: Field) => RelationDef<"hasOne", Target, Field>;
-};

package/dist/transaction/schema/relation.js

@@ -1,104 +0,0 @@
-/**
- * Declarative relations between your models — the edges that turn a flat set
- * of models into a graph. You attach relations to a model with the
- * {@link relation} factories; the engine reads them to index foreign keys for
- * fast child lookups, to order inserts so a parent row lands before the rows
- * that reference it, and to generate the accessor properties that let you read
- * `task.project` or `project.tasks` directly.
- *
- * Usage:
- *   import { relation } from '@abloatai/ablo/schema';
- *
- *   const taskRelations = {
- *     project: relation.belongsTo('projects', 'projectId'),
- *     assignee: relation.belongsTo('users', 'assigneeId'),
- *     comments: relation.hasMany('comments', 'taskId'),
- *   };
- */
-// ── Internal relation builder ─────────────────────────────────────────────
-class RelationBuilder {
-    type;
-    target;
-    foreignKey;
-    /**
-     * Starts out identical to {@link foreignKey}. `defineSchema` overwrites
-     * this when a `casing` option is set — it's declared as a mutable
-     * (non-readonly on the implementation side) so the schema builder can
-     * resolve it once at build time without allocating a new object per
-     * relation. Consumers see it typed as `readonly` on {@link RelationDef}.
-     */
-    foreignKeyColumn;
-    options;
-    /**
-     * Stashed by `hasMany` when the caller provides `{ orderBy }`. Read
-     * back in `createSyncEngine` to install the sort comparator on the
-     * generated relation getter. Declared on the builder so both writer
-     * and reader stay type-safe — no double-cast smuggle through `Record<...>`.
-     */
-    _orderBy;
-    constructor(type, target, foreignKey, options) {
-        this.type = type;
-        this.target = target;
-        this.foreignKey = foreignKey;
-        this.foreignKeyColumn = foreignKey;
-        this.options = (options ?? {});
-    }
-}
-// ── Public relation factories ─────────────────────────────────────────────
-export const relation = {
-    /**
-     * This model belongs to another model via a foreign key.
-     * e.g., Task belongs to Project via projectId
-     *
-     * ```ts
-     * // Simple reference (no options)
-     * project: relation.belongsTo('projects', 'projectId'),
-     *
-     * // Register an FK index for O(1) child lookups
-     * section: relation.belongsTo('sections', 'sectionId', { index: true }),
-     *
-     * // Auto-populate the parent on delta arrival
-     * team: relation.belongsTo('teams', 'teamId', { enrich: true }),
-     *
-     * // Both
-     * parent: relation.belongsTo('threads', 'parentId', { index: true, enrich: true }),
-     *
-     * // Mark the soft side of a cycle so the priority computer breaks
-     * // the cycle deterministically instead of tying the two models.
-     * report: relation.belongsTo('reports', 'reportId', { defer: true }),
-     * ```
-     */
-    belongsTo(target, foreignKey, options) {
-        return new RelationBuilder('belongsTo', target, foreignKey, options ?? {});
-    },
-    /**
-     * This model has many of another model — for example, a project has many
-     * tasks via `Task.projectId`.
-     *
-     * At runtime the engine adds a getter to the parent model that returns every
-     * child whose foreign key matches, and registers the foreign-key index on the
-     * child model automatically.
-     *
-     * ```ts
-     * blocks: relation.hasMany('blocks', 'sectionId'),
-     * // → section.blocks returns all Block[] where sectionId === section.id
-     *
-     * blocks: relation.hasMany('blocks', 'sectionId', { orderBy: 'zIndex' }),
-     * // → section.blocks returns Block[] sorted by zIndex ascending
-     * ```
-     */
-    hasMany(target, foreignKey, options) {
-        const builder = new RelationBuilder('hasMany', target, foreignKey);
-        if (options?.orderBy) {
-            builder._orderBy = options.orderBy;
-        }
-        return builder;
-    },
-    /**
-     * This model has one of another model — for example, a user has one profile
-     * via `Profile.userId`.
-     */
-    hasOne(target, foreignKey) {
-        return new RelationBuilder('hasOne', target, foreignKey);
-    },
-};

package/dist/transaction/schema/residency.d.ts

@@ -1,29 +0,0 @@
-/**
- * A model's residency: which database its rows live in. This is a sibling axis
- * to `tenancy`, which instead describes how rows are isolated within a single
- * database.
- *
- *   - `tenant`  — the tenant data plane. For a customer-connected database this
- *                 is the customer's own database, and provisioning creates these
- *                 tables there.
- *   - `control` — the coordination plane the engine owns: the change log,
- *                 attribution, audit, and the like. These tables are never
- *                 created in a customer's database.
- *
- * The name is `residency` rather than `plane` because "plane" already refers to
- * the server's tenancy scope — organization, environment, and optionally
- * project and sandbox. On the wire the serialized option is still keyed as
- * `plane`, a frozen part of the wire format; only the TypeScript name differs.
- *
- * Declaring this boundary lets provisioning derive what a customer's database
- * receives — the models whose residency is `tenant` — rather than hand-coding
- * that list. Defaults to `tenant`.
- */
-import { z } from 'zod';
-export declare const residencySchema: z.ZodEnum<{
-    tenant: "tenant";
-    control: "control";
-}>;
-export type ModelResidency = z.infer<typeof residencySchema>;
-/** Default residency for a model that doesn't declare one — the tenant data plane. */
-export declare const DEFAULT_RESIDENCY: ModelResidency;

package/dist/transaction/schema/residency.js

@@ -1,25 +0,0 @@
-/**
- * A model's residency: which database its rows live in. This is a sibling axis
- * to `tenancy`, which instead describes how rows are isolated within a single
- * database.
- *
- *   - `tenant`  — the tenant data plane. For a customer-connected database this
- *                 is the customer's own database, and provisioning creates these
- *                 tables there.
- *   - `control` — the coordination plane the engine owns: the change log,
- *                 attribution, audit, and the like. These tables are never
- *                 created in a customer's database.
- *
- * The name is `residency` rather than `plane` because "plane" already refers to
- * the server's tenancy scope — organization, environment, and optionally
- * project and sandbox. On the wire the serialized option is still keyed as
- * `plane`, a frozen part of the wire format; only the TypeScript name differs.
- *
- * Declaring this boundary lets provisioning derive what a customer's database
- * receives — the models whose residency is `tenant` — rather than hand-coding
- * that list. Defaults to `tenant`.
- */
-import { z } from 'zod';
-export const residencySchema = z.enum(['tenant', 'control']);
-/** Default residency for a model that doesn't declare one — the tenant data plane. */
-export const DEFAULT_RESIDENCY = 'tenant';

package/dist/transaction/schema/roles.d.ts

@@ -1,249 +0,0 @@
-import { z } from 'zod';
-/**
- * Sync-group roles — the fan-out vocabulary, as typed data.
- *
- * A *sync group* is the unit the broadcast layer routes deltas on. On the wire
- * it's a `kind:id` string, but that serialization is owned entirely by this
- * module — callers never hand-write `'org:abc'`. Instead they declare a typed
- * {@link Role} (`kind` + which field supplies the id) and the engine mints the
- * branded {@link SyncGroup} string via {@link syncGroup}.
- *
- * Two reading directions, one shape:
- *
- *   • {@link IdentityRole} — "which groups may this *participant* subscribe to?"
- *     Reads fields off an identity context (`organizationId`, `teamIds`).
- *
- *   • {@link EntityRole} — "which groups does this *record* live in?" Reads
- *     fields off the record itself (`id`, `reportId`), so the server can fan a
- *     committed delta to the right entity streams regardless of what the
- *     committer was subscribed to.
- *
- * Roles are pure data (no closures) so a `Schema` round-trips through the
- * control plane and the reconstructed copy behaves identically.
- */
-/**
- * The branded wire form of a sync group: `${kind}:${id}`. Branded so a raw
- * string can't masquerade as one — the only way to produce a `SyncGroup` is
- * {@link syncGroup}. Because the brand is an intersection it's still assignable
- * *to* `string`, so existing `string[]` plumbing keeps working unchanged.
- */
-export declare const syncGroupSchema: z.core.$ZodBranded<z.ZodTemplateLiteral<`${string}:${string}`>, "SyncGroup", "out">;
-export type SyncGroup = z.infer<typeof syncGroupSchema>;
-/**
- * Mint a sync-group string. The single place the `kind:id` convention lives —
- * if the wire format ever changes (structured columns, a different separator),
- * it changes here and nowhere else.
- */
-export declare function syncGroup(kind: string, id: string): SyncGroup;
-/**
- * The caller-facing input form of a sync group. Accepts a {@link SyncGroup}
- * from the constructor, a template literal of the right shape
- * (`` `org:${orgId}` `` type-checks without importing the constructor), or the
- * reserved `'default'` anchor. A plain string with no colon is a compile error,
- * because it would match no group and silently subscribe to nothing.
- */
-export type SyncGroupInput = SyncGroup | `${string}:${string}` | 'default';
-/**
- * Runtime validation for {@link SyncGroupInput}, used wherever a group crosses a
- * trust boundary such as minting a capability or an ephemeral key. A malformed
- * group is rejected with `invalid_sync_group` rather than stored and left
- * silently subscribed to nothing.
- */
-export declare const syncGroupInputSchema: z.ZodUnion<readonly [z.ZodLiteral<"default">, z.core.$ZodBranded<z.ZodTemplateLiteral<`${string}:${string}`>, "SyncGroup", "out">]>;
-/** Runtime guard matching {@link SyncGroupInput}. */
-export declare function isSyncGroupInput(value: unknown): value is SyncGroupInput;
-/**
- * The sync-group kinds the authentication provider mints directly onto an
- * identity. This is a fixed vocabulary: add to this list rather than write a
- * new namespace string inline.
- *
- *   - `org:<organizationId>`  — every member of the organization
- *   - `user:<participantId>`  — the participant itself
- *   - `project:<projectId>`   — every credential scoped to the project; the
- *     organization's default project shares the organization's id
- *
- * Schema-declared roles ({@link identityRole} and {@link entityRole}) extend
- * this vocabulary per application; the kinds here are the ones the engine
- * reserves.
- */
-export declare const IDENTITY_ANCHOR_KINDS: readonly ["org", "user", "project"];
-export type IdentityAnchorKind = (typeof IDENTITY_ANCHOR_KINDS)[number];
-/** Mint an engine-reserved identity anchor (typed wrapper over {@link syncGroup}). */
-export declare function identityAnchor(kind: IdentityAnchorKind, id: string): SyncGroup;
-/** Validates how a role pulls ids out of a context (identity or record). */
-export declare const roleSourceSchema: z.ZodObject<{
-    field: z.ZodString;
-    multi: z.ZodBoolean;
-}, z.core.$strip>;
-export type RoleSource = z.infer<typeof roleSourceSchema>;
-/** Back-compat alias — historical name for {@link RoleSource}. */
-export type IdentityRoleSource = RoleSource;
-/** Record-side name for {@link RoleSource}. */
-export type EntityRoleSource = RoleSource;
-/** Free-form context a role reads from. */
-export type RoleContext = Record<string, unknown>;
-/** The identity shape an {@link IdentityRole} reads from. */
-export type IdentityContext = RoleContext;
-/** The record shape an {@link EntityRole} reads from. */
-export type EntityContext = RoleContext;
-/**
- * A sync-group role: a typed `kind` plus the field that supplies the id. The
- * wire string is `${kind}:${id}`, built by the engine — there is deliberately
- * no template/placeholder for the author to get wrong.
- */
-export declare const roleSchema: z.ZodObject<{
-    kind: z.ZodString;
-    source: z.ZodObject<{
-        field: z.ZodString;
-        multi: z.ZodBoolean;
-    }, z.core.$strip>;
-}, z.core.$strip>;
-export type Role = z.infer<typeof roleSchema>;
-/**
- * Identity-anchored role. Reads an identity field; `kind` names the group.
- *
- * ```ts
- * identityRole({ kind: 'org',  source: 'organizationId' })
- * identityRole({ kind: 'team', source: 'teamIds', multi: true })
- * ```
- */
-export type IdentityRole = Role;
-/**
- * Record-anchored role. Reads a record field; `kind` names the group. A record
- * can route to a group keyed by its own `id` *or* a foreign key like `reportId`.
- *
- * ```ts
- * entityRole({ kind: 'report', source: 'id' })        // a report → report:<id>
- * entityRole({ kind: 'report', source: 'reportId' })  // a block → its parent report
- * ```
- */
-export type EntityRole = Role;
-/** Validates an {@link IdentityRole}. */
-export declare const identityRoleSchema: z.ZodType<IdentityRole>;
-/** Validates an {@link EntityRole}. */
-export declare const entityRoleSchema: z.ZodType<EntityRole>;
-/**
- * Validates a model's `scope` declaration: `true` (kind = typename) or an
- * explicit lowercase kind string. The same vocabulary the roles use, so the
- * whole sync-group declaration surface is Zod-validated, not hand-checked.
- */
-export declare const scopeSchema: z.ZodUnion<readonly [z.ZodBoolean, z.ZodString]>;
-/**
- * Validates a model's `grants` membership edge. Both values are relation names
- * declared on the same model (`subject` → identity, `scope` → scope root); that
- * the relations actually exist + are `belongsTo` is a cross-field check done in
- * `defineSchema` where the relation map is in scope.
- */
-export declare const grantsRefSchema: z.ZodObject<{
-    subject: z.ZodString;
-    scope: z.ZodString;
-}, z.core.$strip>;
-/**
- * The authoring form of a model's sync-group routing — the `groups: { ... }`
- * option. One object collects the three independent routing controls. This is a
- * separate concern from `policy`, which governs tenant isolation: `policy`
- * decides who may read a row, while `groups` decides which change channels a row
- * fans into.
- *
- * - `root`   — marks this model a scope root, so its records form the group
- *   `<kind>:<id>` (the kind defaults to the typename).
- * - `grants` — a membership edge granting an identity access to a scope root.
- * - `roles`  — record-to-group roles keyed on a plain field rather than a
- *   relation, such as inbox fan-out. Accepts a single role or an array.
- */
-export declare const groupsInputSchema: z.ZodObject<{
-    root: z.ZodOptional<z.ZodUnion<readonly [z.ZodBoolean, z.ZodString]>>;
-    grants: z.ZodOptional<z.ZodObject<{
-        subject: z.ZodString;
-        scope: z.ZodString;
-    }, z.core.$strip>>;
-    roles: z.ZodOptional<z.ZodUnion<readonly [z.ZodType<{
-        kind: string;
-        source: {
-            field: string;
-            multi: boolean;
-        };
-    }, unknown, z.core.$ZodTypeInternals<{
-        kind: string;
-        source: {
-            field: string;
-            multi: boolean;
-        };
-    }, unknown>>, z.ZodArray<z.ZodType<{
-        kind: string;
-        source: {
-            field: string;
-            multi: boolean;
-        };
-    }, unknown, z.core.$ZodTypeInternals<{
-        kind: string;
-        source: {
-            field: string;
-            multi: boolean;
-        };
-    }, unknown>>>]>>;
-}, z.core.$strip>;
-export type GroupsInput = z.infer<typeof groupsInputSchema>;
-/** Build an identity-anchored role. `multi` defaults to `false`. */
-export declare function identityRole(spec: {
-    readonly kind: string;
-    /** Identity-context field to read. See {@link RoleSource.field}. */
-    readonly source: string;
-    /** Treat the field as an array of ids. See {@link RoleSource.multi}. */
-    readonly multi?: boolean;
-}): IdentityRole;
-/** Build a record-anchored role. `multi` defaults to `false`. */
-export declare function entityRole(spec: {
-    readonly kind: string;
-    /** Record field to read. See {@link RoleSource.field}. */
-    readonly source: string;
-    /** Treat the field as an array of ids. See {@link RoleSource.multi}. */
-    readonly multi?: boolean;
-}): EntityRole;
-/**
- * Evaluate a {@link RoleSource} against a context. Absent or falsy fields yield
- * `[]`, so a role whose field isn't present (a user with no `teamIds`, a record
- * with no `reportId`) is a silent no-op.
- */
-export declare function extractRoleIds(context: RoleContext, source: RoleSource): readonly string[];
-/** Identity-side name for {@link extractRoleIds}. */
-export declare const extractIdentityIds: typeof extractRoleIds;
-/** Record-side name for {@link extractRoleIds}. */
-export declare const extractEntityIds: typeof extractRoleIds;
-/**
- * Compose the sync groups an identity may subscribe to, from the schema's
- * registered {@link IdentityRole}s. Returns `[]` when no role produces an id;
- * the caller treats `[]` as "no scope", not "match everything".
- */
-export declare function composeIdentitySyncGroups(identity: IdentityContext, schema: {
-    readonly identityRoles: readonly IdentityRole[];
-}): readonly SyncGroup[];
-/**
- * Compose the sync groups a record belongs to, from the model's registered
- * {@link EntityRole}s. Mirror of {@link composeIdentitySyncGroups}, reading the
- * record instead of an identity. Returns `[]` when the model has no entity
- * roles (the delta then fans on its base `org:`/`user:` groups only).
- */
-export declare function composeEntitySyncGroups(record: EntityContext, def: {
-    readonly entityRoles?: readonly EntityRole[];
-}): readonly SyncGroup[];
-/**
- * Narrow a client's requested sync-group set to the groups it is actually
- * allowed to subscribe to. This helper is fully generic — it never inspects the
- * group strings — so it lives beside the composition helpers above.
- *
- * Behaviour:
- *   - If the client requested no groups, return the full identity-derived set,
- *     which is this participant's default subscription scope.
- *   - If the client requested some groups, keep only those that appear in the
- *     identity-derived allowed set and drop the rest, reporting the dropped
- *     groups through the optional `logDropped` callback.
- *   - If nothing survives the filter, fall back to the full allowed set rather
- *     than return `[]`, which would otherwise collapse to the server-side
- *     `'default'` fallback and deliver no changes at all.
- */
-export declare function intersectRequestedWithAllowed(args: {
-    readonly requested: readonly string[];
-    readonly allowed: readonly string[];
-    readonly logDropped?: (dropped: readonly string[]) => void;
-}): readonly string[];