@jini-ai/cms 0.3.10 → 0.4.0

package/dist/identity/auth-service.js

@@ -1,170 +0,0 @@
-import { createHash, randomBytes } from "node:crypto";
-import { resolveEffectivePermissions } from "./authorize.js";
-import { AuthInvalidCredentialsError } from "./types.js";
-import { normalizeUsername } from "./username.js";
-/**
- * @file Login / logout / session validation (REQ-06, state.spec `LOGIN`/`LOGOUT`).
- *
- * Purpose:
- * The credential-verification + session-lifecycle surface `middleware/dev-auth.ts`
- * wires into HTTP. Session tokens are hashed with SHA-256 before storage — the
- * same technique `members/write-service.ts` uses for magic-link/member-session
- * tokens (INV-05: the raw token is never persisted). Password verification is
- * argon2id (`hasher.ts`), never a raw comparison.
- *
- * `createSessionForPrincipal` (2026-09-06) is the one session minter; `login()` calls it after
- * verifying credentials, and a host that identifies a principal by some other means (e.g. a
- * loopback-only single-use boot token, which has nothing to verify a password against) calls it
- * directly instead of re-implementing session construction. Before this export existed, a
- * downstream host had duplicated this file's private `hashToken` byte-for-byte because
- * `login()` was the only minter and hard-requires a password — this closes that fork.
- *
- * Architectural role:
- * Ordinary core functions (like `updatePost`/`membersWriteService`), not a
- * port — session/credential logic has one implementation.
- */
-/** RT-004/behavior.spec §4: absolute session lifetime, fixed at creation. */
-export const SESSION_TTL_MS = 30 * 24 * 60 * 60 * 1000;
-/** SHA-256 hex digest of a raw bearer token (mirrors `members/write-service.ts`'s `hashToken`). */
-function hashToken(rawToken) {
-    return createHash("sha256").update(rawToken).digest("hex");
-}
-function newRawToken() {
-    return randomBytes(32).toString("hex");
-}
-function isoPlusMs(nowIso, ms) {
-    return new Date(new Date(nowIso).getTime() + ms).toISOString();
-}
-/**
- * Mint and persist a session for a principal the caller has ALREADY identified by some means
- * other than this function (password verification in `login()` below, or a caller-specific proof
- * such as a loopback-only single-use boot token). Factored out of `login()`'s former inline
- * session-construction block (2026-09-06) so both paths share one minter — a host with no
- * password to verify no longer has to hand-roll its own token hashing (and risk drifting from
- * this file's private `hashToken`) just to mint a session for a principal it has already proven
- * by other means.
- *
- * @complexity O(1) — one session write.
- * @overallScore 100
- */
-export async function createSessionForPrincipal(required) {
-    const { deps, input } = required;
-    const nowIso = deps.clock.nowIso();
-    const rawToken = newRawToken();
-    const session = {
-        id: deps.idGen.newId(),
-        workspaceId: input.workspaceId,
-        principalId: input.principalId,
-        tokenHash: hashToken(rawToken),
-        createdAt: nowIso,
-        expiresAt: isoPlusMs(nowIso, SESSION_TTL_MS),
-        ip: input.ip,
-        userAgent: input.userAgent,
-    };
-    await deps.repos.sessions.save(session);
-    return { session, rawToken };
-}
-/**
- * Verify `username`+`password` for an `active` principal and mint a session
- * (AC-02, REQ-06). Constant-shaped failure: a nonexistent username, a
- * disabled principal, and a wrong password are all `AuthInvalidCredentialsError`
- * with the same message — no user-enumeration signal.
- *
- * @complexity O(1) — one username lookup, one principal lookup, one hash
- * verify, one session write (via `createSessionForPrincipal`), one `lastLoginAt` write.
- * @overallScore 100
- */
-export async function login(required) {
-    const { deps, input } = required;
-    const username = normalizeUsername(input.username);
-    if (!username || !input.password) {
-        throw new AuthInvalidCredentialsError("invalid username or password");
-    }
-    const userRow = await deps.repos.users.findByUsername({ workspaceId: input.workspaceId, username });
-    if (!userRow) {
-        throw new AuthInvalidCredentialsError("invalid username or password");
-    }
-    const principal = await deps.repos.principals.findById({
-        workspaceId: input.workspaceId,
-        id: userRow.principalId,
-    });
-    if (!principal || principal.status !== "active") {
-        throw new AuthInvalidCredentialsError("invalid username or password");
-    }
-    const passwordOk = await deps.hasher.verify(userRow.passwordHash, input.password);
-    if (!passwordOk) {
-        throw new AuthInvalidCredentialsError("invalid username or password");
-    }
-    const { session, rawToken } = await createSessionForPrincipal({
-        deps,
-        input: { workspaceId: input.workspaceId, principalId: principal.id, ip: input.ip, userAgent: input.userAgent },
-    });
-    // Reuses the session's own `createdAt` rather than a second `clock.nowIso()` call — both are
-    // meant to be the same instant, and reading one avoids two clock reads ever disagreeing.
-    await deps.repos.users.save({ ...userRow, lastLoginAt: session.createdAt });
-    return { principal, session, rawToken };
-}
-/**
- * Resolve a session cookie's raw token to its principal, applying every
- * fail-closed check server-side (EC-02/EC-03/EC-13, AC-05/AC-20): unknown
- * token, revoked, past absolute `expiresAt`, or a disabled bound principal
- * all resolve to `null` (the caller maps that to 401 `UNAUTHENTICATED` and
- * never reaches `authorize()`).
- *
- * @complexity O(1) — one token-hash lookup, one principal lookup.
- * @overallScore 100
- */
-export async function validateSession(required) {
-    const { deps, input } = required;
-    const nowIso = input.nowIso ?? deps.clock.nowIso();
-    const session = await deps.repos.sessions.findByTokenHash({
-        workspaceId: input.workspaceId,
-        tokenHash: hashToken(input.rawToken),
-    });
-    if (!session)
-        return null;
-    if (session.revokedAt)
-        return null;
-    // EC-13/AC-20: past absolute expiry is treated as revoked, never reaching authorize().
-    if (session.expiresAt <= nowIso)
-        return null;
-    const principal = await deps.repos.principals.findById({
-        workspaceId: input.workspaceId,
-        id: session.principalId,
-    });
-    // EC-02: a disabled principal's live session stops validating immediately.
-    if (!principal || principal.status !== "active")
-        return null;
-    return { principal, session };
-}
-/** Revoke the session bound to `rawToken`. Idempotent — already-revoked/unknown is a no-op. */
-export async function logout(required) {
-    const { deps, input } = required;
-    const session = await deps.repos.sessions.findByTokenHash({
-        workspaceId: input.workspaceId,
-        tokenHash: hashToken(input.rawToken),
-    });
-    if (!session || session.revokedAt)
-        return;
-    await deps.repos.sessions.revoke({
-        workspaceId: input.workspaceId,
-        id: session.id,
-        revokedAt: deps.clock.nowIso(),
-    });
-}
-/** The introspection surface for `AUTH_ME` (REQ-07): dotted permission strings, `["*"]` for owner. */
-export async function getEffectivePermissions(required) {
-    const rows = await resolveEffectivePermissions({
-        deps: {
-            principals: required.deps.principals,
-            principalRoles: required.deps.principalRoles,
-            rolePolicies: required.deps.rolePolicies,
-            principalPolicies: required.deps.principalPolicies,
-            policyPermissions: required.deps.policyPermissions,
-        },
-        principalId: required.input.principalId,
-        workspaceId: required.input.workspaceId,
-    });
-    return [...new Set(rows.map((row) => row.permission))];
-}
-//# sourceMappingURL=auth-service.js.map

package/dist/identity/authorize.d.ts

@@ -1,90 +0,0 @@
-import type { UUID } from "../core/ports.js";
-import type { PolicyPermissionRepoPort, PrincipalPolicyRepoPort, PrincipalRepoPort, PrincipalRoleRepoPort, RolePolicyRepoPort } from "./ports.js";
-import type { PolicyPermissionRecord } from "./types.js";
-/**
- * @file `authorize()` — the RBAC evaluator (REQ-04).
- *
- * Purpose:
- * Ordinary core function, deliberately NOT a port (one evaluator —
- * "no PolicyPort"). The command gateway calls this before every
- * mutation (REQ-05); it is deterministic and side-effect free given the
- * repo snapshot (state.spec §4).
- *
- * How it relates to the project:
- * - `command.ts`'s `executeCommand` calls a bound closure of this shape
- *   (typed there as `AuthorizeFn`, kept generic so `core/commands` never
- *   imports this feature-level library — see that file's header).
- * - Route handlers call it directly for mutations that do not flow through
- *   the command gateway (this pass: `members` disable — see the handoff).
- *
- * Architectural role:
- * Implements the matcher precedence in behavior.spec §1.1 exactly:
- * disabled-principal short-circuit > owner wildcard > exact matching row >
- * fail-closed default. Fail-closed extensibility: a non-null
- * `constraintJson` is never treated as unconstrained, and a `resourceType`
- * mismatch/absence is never treated as a global grant.
- */
-/** The context an authorization decision is evaluated against (REQ-04). */
-export interface AuthorizeContext {
-    workspaceId: UUID;
-    entityType?: string;
-    entityId?: UUID;
-}
-/** `authorize()`'s result — always fail-closed on `allowed: false` (INV-03). */
-export interface AuthorizeResult {
-    allowed: boolean;
-    /** Machine-readable reason: `principal_disabled | no_grant | resource_scope_mismatch | unconstrained_deny | owner_wildcard | matched`. */
-    reason: string;
-}
-/** Repos `authorize()`/`resolveEffectivePermissions()` read. Not a port bag with alternate adapters — see file header. */
-export interface AuthorizeDeps {
-    principals: PrincipalRepoPort;
-    principalRoles: PrincipalRoleRepoPort;
-    rolePolicies: RolePolicyRepoPort;
-    principalPolicies: PrincipalPolicyRepoPort;
-    policyPermissions: PolicyPermissionRepoPort;
-}
-/**
- * Resolve a principal's effective permission rows: the union of (a) its
- * roles' policies' permissions and (b) policies attached directly via
- * `principal_policies` (behavior.spec §1.2). Scoped to `workspaceId` by
- * construction (every repo call below is workspace-scoped).
- *
- * @complexity O(r*p + d) round trips, r = roles held, p = policies per role,
- * d = direct policy attachments — all expected small (a handful of rows per
- * principal). No caller-unbounded collection is walked.
- * @overallScore 100
- */
-export declare function resolveEffectivePermissions(required: {
-    deps: AuthorizeDeps;
-    principalId: UUID;
-    workspaceId: UUID;
-}): Promise<PolicyPermissionRecord[]>;
-/**
- * The RBAC decision (REQ-04). Fail-closed: `allowed` defaults to `false` and
- * only ever flips to `true` on an explicit disabled-short-circuit-cleared,
- * matching row.
- *
- * Precedence (behavior.spec §1.1, highest to lowest):
- * 1. Disabled principal -> `false`, `principal_disabled` (overrides all grants).
- * 2. An unconstrained owner `"*"` row -> `true`, `owner_wildcard`.
- * 3. An exact matching row (permission + workspace + resource-scope + no
- *    constraint) -> `true`, `matched`.
- * 4. Fail-closed default -> `false`, with the most specific diagnostic reason
- *    available among same-permission candidates (`unconstrained_deny` over
- *    `resource_scope_mismatch` over `no_grant` — an inferred, undocumented-but-
- *    reasonable tie-break; the spec only pins each reason in isolation, see
- *    AC-09/AC-14/EC-04).
- *
- * @complexity O(resolveEffectivePermissions) + O(k) local filtering, k = the
- * principal's effective row count (small, bounded by grants a workspace
- * administrator creates by hand).
- * @overallScore 100
- */
-export declare function authorize(required: {
-    deps: AuthorizeDeps;
-    principalId: UUID;
-    permission: string;
-    context: AuthorizeContext;
-}): Promise<AuthorizeResult>;
-//# sourceMappingURL=authorize.d.ts.map

package/dist/identity/authorize.js

@@ -1,94 +0,0 @@
-/**
- * Resolve a principal's effective permission rows: the union of (a) its
- * roles' policies' permissions and (b) policies attached directly via
- * `principal_policies` (behavior.spec §1.2). Scoped to `workspaceId` by
- * construction (every repo call below is workspace-scoped).
- *
- * @complexity O(r*p + d) round trips, r = roles held, p = policies per role,
- * d = direct policy attachments — all expected small (a handful of rows per
- * principal). No caller-unbounded collection is walked.
- * @overallScore 100
- */
-export async function resolveEffectivePermissions(required) {
-    const { deps, principalId, workspaceId } = required;
-    const roleLinks = await deps.principalRoles.listByPrincipalId({ workspaceId, principalId });
-    const rolePermissionGroups = await Promise.all(roleLinks.map(async (roleLink) => {
-        const rolePolicyLinks = await deps.rolePolicies.listByRoleId({
-            workspaceId,
-            roleId: roleLink.roleId,
-        });
-        const policyPermissionGroups = await Promise.all(rolePolicyLinks.map((rolePolicyLink) => deps.policyPermissions.listByPolicyId({ workspaceId, policyId: rolePolicyLink.policyId })));
-        return policyPermissionGroups.flat();
-    }));
-    const directLinks = await deps.principalPolicies.listByPrincipalId({ workspaceId, principalId });
-    const directPermissionGroups = await Promise.all(directLinks.map((directLink) => deps.policyPermissions.listByPolicyId({ workspaceId, policyId: directLink.policyId })));
-    return [...rolePermissionGroups.flat(), ...directPermissionGroups.flat()];
-}
-/**
- * True iff `row` is an exact, unconstrained-or-scope-matching grant of
- * `permission` in `context` (state.spec §4 `matchesRow`). Assumes `row` has
- * already passed the owner-wildcard check upstream — this never special-cases
- * `"*"`.
- */
-function matchesRow(row, permission, context) {
-    if (row.permission !== permission)
-        return false;
-    if (row.constraintJson != null)
-        return false;
-    if (row.resourceType != null && row.resourceType !== context.entityType)
-        return false;
-    return true;
-}
-/**
- * The RBAC decision (REQ-04). Fail-closed: `allowed` defaults to `false` and
- * only ever flips to `true` on an explicit disabled-short-circuit-cleared,
- * matching row.
- *
- * Precedence (behavior.spec §1.1, highest to lowest):
- * 1. Disabled principal -> `false`, `principal_disabled` (overrides all grants).
- * 2. An unconstrained owner `"*"` row -> `true`, `owner_wildcard`.
- * 3. An exact matching row (permission + workspace + resource-scope + no
- *    constraint) -> `true`, `matched`.
- * 4. Fail-closed default -> `false`, with the most specific diagnostic reason
- *    available among same-permission candidates (`unconstrained_deny` over
- *    `resource_scope_mismatch` over `no_grant` — an inferred, undocumented-but-
- *    reasonable tie-break; the spec only pins each reason in isolation, see
- *    AC-09/AC-14/EC-04).
- *
- * @complexity O(resolveEffectivePermissions) + O(k) local filtering, k = the
- * principal's effective row count (small, bounded by grants a workspace
- * administrator creates by hand).
- * @overallScore 100
- */
-export async function authorize(required) {
-    const { deps, principalId, permission, context } = required;
-    const principal = await deps.principals.findById({ workspaceId: context.workspaceId, id: principalId });
-    if (!principal || principal.status === "disabled") {
-        return { allowed: false, reason: "principal_disabled" };
-    }
-    const effectiveRows = await resolveEffectivePermissions({
-        deps,
-        principalId,
-        workspaceId: context.workspaceId,
-    });
-    const hasUnconstrainedWildcard = effectiveRows.some((row) => row.permission === "*" && row.resourceType == null && row.constraintJson == null);
-    if (hasUnconstrainedWildcard) {
-        return { allowed: true, reason: "owner_wildcard" };
-    }
-    const candidates = effectiveRows.filter((row) => row.permission === permission);
-    if (candidates.length === 0) {
-        return { allowed: false, reason: "no_grant" };
-    }
-    const matched = candidates.some((row) => matchesRow(row, permission, context));
-    if (matched) {
-        return { allowed: true, reason: "matched" };
-    }
-    if (candidates.some((row) => row.constraintJson != null)) {
-        return { allowed: false, reason: "unconstrained_deny" };
-    }
-    if (candidates.some((row) => row.resourceType != null)) {
-        return { allowed: false, reason: "resource_scope_mismatch" };
-    }
-    return { allowed: false, reason: "no_grant" };
-}
-//# sourceMappingURL=authorize.js.map

package/dist/identity/grant-service.d.ts

@@ -1,198 +0,0 @@
-import type { UUID } from "../core/ports.js";
-import { type AuthorizeDeps } from "./authorize.js";
-import type { AuthServiceDeps } from "./auth-service.js";
-import type { IdentityRepos } from "./ports.js";
-import { type PolicyRecord, type PrincipalPolicyRecord, type PrincipalRecord, type PrincipalRoleRecord, type RoleRecord, type UserRecord } from "./types.js";
-/**
- * @file Human grant-writing transitions (state.spec.md §3): `CREATE_USER`,
- * `CREATE_ROLE`, `CREATE_POLICY`, `ASSIGN_ROLE`, `ATTACH_POLICY`.
- *
- * Purpose:
- * The only usable identity principal before this file was the seeded owner —
- * there was no API path to create a second user or grant/change permissions.
- * These five functions are that path, following `auth-service.ts`'s exact
- * shape (`{ deps: AuthServiceDeps, input: {...} }`, one exported async
- * function per transition, plain `Error` subclasses for control flow).
- *
- * Out of scope (deferred, see the dispatch directive): `ISSUE_API_KEY`,
- * `CREATE_PRINCIPAL` (api_key/agent principal creation), agent/api_key
- * delegation, `WRITE_POLICY_PERMISSION`, `DISABLE_PRINCIPAL`.
- *
- * Architectural role:
- * Ordinary core functions, not ports (mirrors `auth-service.ts`'s reasoning —
- * grant-writing logic has one implementation). Each function calls
- * `authorize()`/`resolveEffectivePermissions()` from `authorize.ts` itself
- * (rather than pushing the gate into the route layer, the way
- * `members/disable.ts`'s route does) so the caller-permission gate and the
- * INV-07 clamp are exercised directly by unit tests, no HTTP harness needed.
- */
-/**
- * Assemble the `AuthorizeDeps` bag `authorize()`/`resolveEffectivePermissions()` expect from the
- * flat `IdentityRepos` bag. Exported so `admin-crud-service.ts`'s new transitions
- * (`ENABLE_PRINCIPAL`/`UPDATE_USER`/`RESET_USER_PASSWORD`/`UPDATE_ROLE`/`UPDATE_POLICY`/
- * `DELETE_ROLE`/`DELETE_POLICY`/`WRITE_POLICY_PERMISSION`/`DISABLE_PRINCIPAL`) reuse the identical
- * gate/clamp logic rather than duplicating it — same file-split reasoning `auth-service.ts` and
- * `grant-service.ts` already use (one shared helper set, two transition files).
- */
-export declare function authorizeDepsFrom(repos: IdentityRepos): AuthorizeDeps;
-/**
- * Fail-closed caller-permission gate shared by every transition in this file.
- * Throws `IdentityForbiddenError` (403 `FORBIDDEN`) unless the caller holds
- * at least one of `permissions` (an OR gate — `CREATE_USER` accepts either
- * `user.manage` or `member.manage`, state.spec §3).
- *
- * @complexity O(p) `authorize()` calls, p = `permissions.length` (1 or 2 in
- * every caller this pass) — each itself O(resolveEffectivePermissions), see
- * that function's doc.
- * @overallScore 100
- */
-export declare function assertCallerHasAnyPermission(required: {
-    deps: AuthServiceDeps;
-    workspaceId: UUID;
-    callerPrincipalId: UUID;
-    permissions: readonly string[];
-}): Promise<void>;
-/**
- * The INV-07 grant-authority clamp (feature.spec.md, state.spec §3
- * `ASSIGN_ROLE`/`ATTACH_POLICY` rows): every permission in `conferredPermissions`
- * must be a matching effective row the caller holds unconstrained
- * (`resourceType`/`constraintJson` both null; owner's `*` qualifies for all).
- * A permission held only conditionally (resource-scoped or constraint-bound)
- * cannot be delegated. Throws `GrantExceedsIssuerError` (403
- * `GRANT_EXCEEDS_ISSUER`) naming every offending permission, and writes no
- * grant row (caller does the write only after this resolves).
- *
- * @complexity O(resolveEffectivePermissions) + O(k) local filtering, k =
- * `conferredPermissions.length` (bounded by one role's/policy's permission
- * rows — a handful, per `identity/INFO.md`'s scale assumptions).
- * @overallScore 100
- */
-export declare function assertGrantClamp(required: {
-    deps: AuthServiceDeps;
-    workspaceId: UUID;
-    callerPrincipalId: UUID;
-    conferredPermissions: readonly string[];
-}): Promise<void>;
-/**
- * `CREATE_USER` (state.spec §3, REQ-01/MF-1). Atomically mints a NEW
- * `kind='user'` principal and its `users` row — the `principalId` is always
- * generated here, never caller-supplied, so this transition can never attach
- * a credential to a pre-existing principal (the MF-1 privilege-escalation
- * class: an earlier draft let an admin bind a password to the seeded owner
- * principal and log in as owner). Gated by `user.manage` OR `member.manage`
- * (admin onboarding, AC-22).
- *
- * "Atomically" here means structurally, not via a DB transaction — the
- * in-memory adapters have no cross-repo transaction (same disclosed gap as
- * `seed.ts`/`executeCommand`'s compensating-rollback path). The invariant
- * that actually matters (no credential ever attaches to an existing
- * principal) holds regardless, because `principalId` is generated inline and
- * the password is hashed before either row is written, so a hashing failure
- * leaves no orphan principal. A future SQLite adapter wraps both writes in
- * one real transaction (port/adapter rule-of-two) without changing this contract.
- *
- * @complexity O(1) — one permission check, one username lookup, one hash,
- * two saves.
- * @overallScore 100
- */
-export declare function createUser(required: {
-    deps: AuthServiceDeps;
-    input: {
-        workspaceId: UUID;
-        callerPrincipalId: UUID;
-        username: string;
-        email?: string | undefined;
-        password: string;
-    };
-}): Promise<{
-    principal: PrincipalRecord;
-    user: UserRecord;
-}>;
-/**
- * `CREATE_ROLE` (state.spec §3). Gated by `role.manage`. Always mints
- * `isBuiltin=false` — built-ins are SEED-only and immutable (INV-06).
- *
- * Deviation from the state.spec §3 table (disclosed): that row lists
- * `name`, `description?` jointly for `CREATE_ROLE`/`CREATE_POLICY`, but
- * `RoleRecord` (types.ts, frozen before this task) has no `description`
- * field — only `PolicyRecord` does. `createRole` therefore takes `name`
- * only; `createPolicy` below takes both.
- *
- * @complexity O(1) — one permission check, one save.
- * @overallScore 100
- */
-export declare function createRole(required: {
-    deps: AuthServiceDeps;
-    input: {
-        workspaceId: UUID;
-        callerPrincipalId: UUID;
-        name: string;
-    };
-}): Promise<{
-    role: RoleRecord;
-}>;
-/**
- * `CREATE_POLICY` (state.spec §3). Gated by `role.manage`. Always mints
- * `isBuiltin=false` and `isFrozen=false` — only the (out-of-scope this pass)
- * `ISSUE_API_KEY` transition ever mints `isFrozen=true` policies.
- *
- * @complexity O(1) — one permission check, one save.
- * @overallScore 100
- */
-export declare function createPolicy(required: {
-    deps: AuthServiceDeps;
-    input: {
-        workspaceId: UUID;
-        callerPrincipalId: UUID;
-        name: string;
-        description?: string | undefined;
-    };
-}): Promise<{
-    policy: PolicyRecord;
-}>;
-/**
- * `ASSIGN_ROLE` (state.spec §3, REQ-02, AC-24/AC-25). Gated by `role.manage`;
- * target must be a `kind='user'` principal (AC-25b); the INV-07 clamp must
- * pass over every permission carried by the role's policies (AC-24) — so
- * assigning the built-in `owner` role requires the caller to already hold
- * the wildcard `*` (owner-only). No row is written on any rejection.
- *
- * @complexity O(resolveEffectivePermissions) + O(role's rolePolicy count)
- * round trips to gather conferred permissions — both bounded by the small,
- * hand-authored grant graph this system assumes (see `identity/INFO.md`).
- * @overallScore 100
- */
-export declare function assignRole(required: {
-    deps: AuthServiceDeps;
-    input: {
-        workspaceId: UUID;
-        callerPrincipalId: UUID;
-        principalId: UUID;
-        roleId: UUID;
-    };
-}): Promise<{
-    assignment: PrincipalRoleRecord;
-}>;
-/**
- * `ATTACH_POLICY` (state.spec §3, REQ-02, AC-24/AC-25). Gated by
- * `role.manage`; target must be a `kind='user'` principal (AC-25b); the
- * INV-07 clamp must pass over every permission the policy carries (AC-24) —
- * attaching the built-in `owner` policy requires the caller to already hold
- * `*` (owner-only). No row is written on any rejection.
- *
- * @complexity O(resolveEffectivePermissions) + O(policy's permission row
- * count) — both bounded, see `assignRole`'s doc.
- * @overallScore 100
- */
-export declare function attachPolicy(required: {
-    deps: AuthServiceDeps;
-    input: {
-        workspaceId: UUID;
-        callerPrincipalId: UUID;
-        principalId: UUID;
-        policyId: UUID;
-    };
-}): Promise<{
-    attachment: PrincipalPolicyRecord;
-}>;
-//# sourceMappingURL=grant-service.d.ts.map