/**
 * In-memory SessionPolicyStore + the service's `deleteBySession` extension (E21 purge / 2c overwrite-dst wipe).
 *
 * WHY THIS EXISTS (and not core's `InMemorySessionPolicyStore`): core's in-memory/file policy stores implement only
 * the core interface (getRules/putRules/listBySession) — they have NO deletion seam, so neither the E21 session purge
 * nor the 2c `overwrite-dst` subsystem wipe can remove policy rows on a backend that uses them (the SQL twins carry
 * `deleteBySession` as a service extension; see session-policy-store-sql.ts). This store is the delete-capable
 * in-memory twin. The seam itself is also requested upstream (core: optional `deleteBySession?` on the interface +
 * the File/InMemory impls) — if core lands it, this class can retire in favor of core's.
 *
 * BYTE-MATCH DISCIPLINE: getRules/putRules/listBySession replicate core's `InMemorySessionPolicyStore` semantics
 * exactly (same key shape, same CAS `conflict` on expectedRev mismatch, same tighten-only `loosen_forbidden` gate via
 * core's exported `normalizeRules`/`loosenReasons`/`stripRev`, same rev start/bump). Any divergence is a bug here.
 * S-529 起同样钉住 `@contract session_policy.rev_survives_delete`:`deleteBySession` 保留每把键的 rev 高水位
 * **并给那把键的世代(`gen`)+1**(见 {@link MemorySessionPolicyStore.deleteBySession});共用试剂盒
 * `test/helpers/session-policy-rev-line-contract.ts` 与 SQL 双生、以及 core 自己的 `InMemorySessionPolicyStore`
 * (7.25.0 起带这条契约,已作为第三只引擎接进同一只试剂盒当 oracle)跑同一段剧本。
 */
import { type PutRulesOptions, type SessionPermissionRules, type SessionPolicyStore, type SessionRulesRecord, type StoredSessionRules } from "@sema-agent/core";
export declare class MemorySessionPolicyStore implements SessionPolicyStore {
    private readonly map;
    /** S-529 —— 每把键的 rev **高水位 + 世代**(`@contract session_policy.rev_survives_delete`):`deleteBySession`
     *  抹掉规则行时把它那条 rev 线的终点留在这里,于是删后首写 stamp 的是 `max(当前行 rev, 记号.rev) + 1`,
     *  而不是从 1 重来;同时把 `gen` +1 —— **抹除终结的是那一行的血统**,下一次写开的是新世代,读侧因此能把
     *  「重建的行」与「它正在执行的那一行的延续」分开,无论新行的 rev 有多大(core 7.25.0 [ref] 判词:
     *  没有世代时读侧只能靠「亲眼看见行消失」那条弱守卫,于是两道门之间未被观察到的 erase+重建抓不住,
     *  而一次瞬时读 null 会把该腿永久闩在旧行上)。
     *  与 SQL 双生的 `session_policy_rev_mark` 表、core File 店的 `<stem>.hwm.json` 侧车是同一条律的三个实现体
     *  (SQL 那边的表注写了为什么不留墓碑行)。本表只增不减、条目是两个整数 —— 与 `map` 同为进程内结构,
     *  随进程亡;跨副本的持久面在 SQL 双生那半。 */
    private readonly marks;
    private key;
    getRules(sessionId: string, principal?: string): Promise<StoredSessionRules | null>;
    putRules(sessionId: string, principal: string | undefined, rules: SessionPermissionRules, opts?: PutRulesOptions): Promise<StoredSessionRules>;
    listBySession(sessionId: string): Promise<SessionRulesRecord[]>;
    /** Purge ALL policy rows for a session, across every principal — KEEPING each key's rev high-water mark.
     *  Scoped by session_id alone — the caller (E21 route / importSession overwrite-dst) already proved ownership.
     *  Shape = core 1.423's optional `SessionPolicyStore.deleteBySession?` seam (`Promise<void>` — the count was
     *  incidental; nothing consumed it).
     *
     *  S-529:规则本身死,rev 线不死(`@contract session_policy.rev_survives_delete`)。记号只升不降(`Math.max`),
     *  所以反复抹除不会把线走回头;从没写过的键不留记号(没有线就不凭空抬)。**抹除同时终结那一行的血统**:
     *  `gen` +1,于是下一次写开的是新世代 —— 数字继续爬,但读侧按世代判「这不是我在执行的那一行的延续」。 */
    deleteBySession(sessionId: string): Promise<void>;
}
//# sourceMappingURL=memory-session-policy-store.d.ts.map