/**
 * Durable user-origin permission rules, approval decisions that persist.
 *
 * A "remember" decision with a generalizing tier (exact command / command
 * class / path scope / whole tool) writes a PolicyRule with origin 'user'
 * here. PermissionManager consults these rules before ever prompting (the
 * in-memory session map is just a cache in front), and evaluateRuntimePolicy
 * folds them into the layered evaluator when the policy engine flag is on,
 * user rules are evaluated ahead of managed rules there.
 *
 * Storage: one JSON file per project (control-plane config dir), atomic
 * writes via PersistentStore; ':memory:' for tests. Rules are project-scoped
 * by where the file lives.
 */
import type { PolicyRule } from '../runtime/permissions/types.js';
import type { RememberTier } from './approval-rules.js';
/** A stored rule plus its provenance. */
export interface StoredUserPermissionRule {
    readonly rule: PolicyRule;
    readonly createdAt: number;
    /** The remember tier that produced this rule. */
    readonly tier: Exclude<RememberTier, 'session'>;
    /** The tool whose ask produced the rule (display context). */
    readonly tool: string;
}
export declare class UserPermissionRuleStore {
    private readonly store;
    private records;
    private loaded;
    /** Whole-store writes run one at a time, in call order. See StoreWriteQueue. */
    private readonly writes;
    constructor(filePath: string);
    /** Load persisted rules. Safe to call more than once. */
    init(): Promise<void>;
    /** All stored rules, newest first. */
    list(): readonly StoredUserPermissionRule[];
    /** Just the PolicyRules, for evaluation (insertion order, first match wins). */
    rules(): readonly PolicyRule[];
    add(record: StoredUserPermissionRule): Promise<void>;
    /** Delete by rule id. Returns whether a rule was removed. */
    delete(ruleId: string): Promise<boolean>;
    /**
     * Replace the store file with the rules as they stand at THIS call, after
     * every write already queued has finished.
     *
     * `PersistentStore.persist` is atomic but says nothing about ORDER, and these
     * rules are written by two paths that overlap in practice: `add`, from a
     * "remember this decision" answer, and `delete`, from a revocation. With the
     * writes unordered the add's rename could land AFTER the delete's, putting
     * the revoked rule back on disk, and a durable user rule is consulted before
     * anything prompts, so the next matching ask was auto-approved by a rule its
     * owner had already taken away.
     *
     * The snapshot is still taken here, synchronously, exactly as it always was.
     * Ordering is sufficient because both callers replace `records` and then
     * persist, so each snapshot is at least as new as the one queued before it.
     */
    private persist;
}
//# sourceMappingURL=user-rule-store.d.ts.map