/**
 * runs 账本(`task_run_event`)的**事件型闭集**——[ref] P1-③ / codex 交叉复审 F2。
 *
 * ## 为什么需要这个联合
 * 账本行的 `type` 是消费端分流的键:`GET /v1/runs/:id/events` 裸回放照发,而 `trace/project.ts` 的
 * `mapTraceEventInner` 要把其中一部分投影成 registry 契约 2.3 的 SSE 帧,剩下的**刻意**落 null。
 * 「新加了一个账本事件型却没人给它归类」这件事此前只能靠源码扫描发现,而扫描对**别名门**是盲的
 * (真例:`http/server.ts` 的 `const ap = (type, data) => rs2.appendEvent(...)`,以及
 * `ap(reSuspended ? reParkStatus : "suspended", …)` 这种**动态**首参 —— 任何词法门都抓不到)。
 * 把词表收成一个**类型**,新型就必须先在这里登记(否则调用点编译红),投影闭合门再从这里枚举 ⇒
 * 「加型 ⇒ 必须归类」变成编译期 + 门的两道执法,不再依赖扫描器的视力。
 *
 * ## 执法面(收到哪一层)
 * 联合被**三层**写口共同引用,所以"绕开 typed 门直写"这条路已经堵死(codex R2-F2:此前只收了
 * `LedgerSink.append`,底层 `appendEvent` 仍吃 `string`,`const t = "x"; runStore.appendEvent(id, seq, t, d)`
 * 既过编译又躲过逐行字面量扫描):
 *  1. `LedgerSink.append` / `trace/project.ts` 的 `AppendFn` / 各腿的 `append`·`ap`·`approvalEmit` 闭包;
 *  2. `createLedgerSink({ appendEvent })` 的回调签名;
 *  3. **三个 RunStore 实现**的 `appendEvent(taskId, seq, type, data)`(SQL / file / memory)—— 账本行的
 *     最终落点,类型收在这里才与"能不能写进去"同源。
 *
 * ## 射程上限(如实,别夸大)
 * 仍有**一条动态门**:`http/server.ts` 的通知 drain 回调把 core 帧的 `type` 逐字落账(那里有一处
 * 显式窄化 + 自陈注释)。它今天产出的是 `task_notification`(已在册),但 core 换帧名时本联合**不会**
 * 自动红 —— 那条腿的对齐由 core 帧集的消费门(`trace/core-keyset-guard.ts` 一族)负责,不是这里。
 * 另有若干测试用显式窄化写入**历史行名**(`brain_status`)或合成桩型:那是在模拟"库里躺着的旧行/
 * 失败路径",不是本版本的写口 —— 本联合的语义是「**这个版本会写出来的型**」,故不收它们。
 *
 * ## 成员的两类
 *  · **流事件投影**:两条 durable 腿(bg = `runs.ts` + `trace/ledger-sink.ts`,resume = `http/server.ts`)
 *    的 `switch (ev.type)` 白名单臂(差集门 `test/durable-append-arm-parity.test.ts` 看守两腿一致);
 *  · **腿自己的带外行**:park/终局/失败/建议/用量/装配自证(不来自流事件)。
 */
export type LedgerEventType = "reasoning" | "text" | "tool_start" | "tool_end" | "status" | "context_usage" | "compacted" | "diagnostics" | "steering_injected" | "compaction_outcome" | "workspace_changed" | "wiring_manifest"
/** S-212(7.71.0):运行期名册变更(core 7.8.0 [ref] ⑪)。**快照语义**——`delta.roster` 是整只
 *  变更后名册,消费端收到即整只替换,所以回放不需要任何合并;它的耐久面因此不是 `wiring_manifest.tools`
 *  的重复,而是那份开腿快照**之后**的每一次改动(修前两条 durable 腿零 case ⇒ 回放只见开头一版)。 */
 | "tool_roster_delta"
/** [ref](core 7.18.0):本条腿的**延迟工具普查**快照(policy / thresholdPercent? / deferred[] / activated[])。
 *  与 `tool_roster_delta` 同判、同理由——**快照语义**(整只替换,回放零合并),而开腿那一份住在
 *  `wiring_manifest` 之后的首帧、**之后每一次激活**只活在本帧上。整帧缺席 = 这条腿什么都没延迟。
 *  🔴 `tool_progress`([ref])**刻意不在本表**:core 的 `tool_progress.ephemeral` 契约逐字「LIVE ONLY …
 *  core never persists this frame」,与 `task_progress` / `status` 同一处置(两条 durable 腿零 case)。 */
 | "tool_disclosure" | "human_input" | "task_progress" | "task_notification" | "turn_end"
/** park 行名**两个**(`appendParked(kind)` 逐字取自 `result.status`)—— 运行期闭集见
 *  {@link PARK_LEDGER_EVENT_TYPES}(本联合是它的类型面,两者由下方的双向断言锁步)。 */
 | "suspended" | "needs_review" | "done" | "failed" | "suggestions" | "model_usage" | "prompt_assembled" | "config_assembled" | "file_link"
/** 人在环三族的 open/close 帧对(投递面 = 本腿的 durable events tail)。 */
 | "elicitation" | "elicitation_complete" | "question" | "question_complete" | "tool_approval" | "tool_approval_complete"
/** [ref] §4.3 新协议的呈卡帧(与上面两只 tool_approval 帧同一条投递面)。 */
 | "approval_request"
/**
 * [ref]([ref]):批级撤卡帧在 **bg/resume 两条 durable 腿**的账本落行(与呈卡帧同口
 * `append(type, rest)`,seq 由腿自己的 ledger 链步分配)。此前成文「reaper/收敛器无 seq 可分配故
 * live-only」只对**调用点**成立,不对 ctx 的投递口成立——帧经 `emitRevokeTo` 交给各 ctx 的
 * `emitRevoke`,durable 腿的那只钩子自己就是账本写口。sync 腿维持 live-only(行为零变,
 * `routes/tasks.ts` 装配点注)。重放语义:同一账本里卡帧(`approval_request`)在前、撤帧在后,
 * 全量重读恒同序 ⇒ 幂等诚实;不投影成 trace 2.3 帧(`LEDGER_TYPES_NOT_PROJECTED` 登记)。
 */
 | "approval_revoke"
/** 异步 workflow 完成的入箱 drain(`emitPendingWorkflowCompletions` 两个字面型之一)。 */
 | "workflow_complete"
/**
 * [ref] `engine_notice` —— core `EngineNotice` 白名单三码按 `detail.sessionId` 路由到该会话的事件投影。
 *
 * 🔴 **是"腿自己的带外行",不是流事件投影**:它不经 `TaskStream`(`RunnerDeps.onNotice` 是 deps 级
 * 同步 sink),所以两条 durable 腿的 `switch (ev.type)` 里**没有也不该有** `case "engine_notice"` ——
 * `test/durable-append-arm-parity.test.ts` 的差集是按那个 switch 抽的,本型结构上在它射程之外
 * (与 `elicitation` / `question` / `approval_request` / `model_usage` 同类)。本型的"三腿是否都挂了口"
 * 由 `test/engine-notice-wire.test.ts` 的腿覆盖门看守,那才是它的对位门。
 */
 | "engine_notice";
/**
 * 🔴 **park 行名的运行时闭集**(合并重扫 [4])。
 *
 * 此前这两个词在仓里有**三处**并列的字面量:`ledger-sink.ts` 的 `appendParked` 形参与 `onDone` 的分诊、
 * 以及 `observability/run-terminal.ts` 的脱敏臂。`LedgerEventType` 只是类型联合、运行期取不到,
 * 所以脱敏臂只能自己再抄一份 —— 而抄的那一份**加词不红**:仓里/引擎加第三个 park 词并登记进
 * `LedgerEventType` 之后,`appendParked` 与 resume 腿的动态首参照写照落,回放时那一行的
 * `gate.riskDescriptor.summary` 明文,脱敏臂一声不吭。
 *
 * ⇒ 词表落成**运行时常量**由消费点派生;下方两条断言把它与类型联合双向锁死(多一词 / 少一词都 tsc 红)。
 */
export declare const PARK_LEDGER_EVENT_TYPES: readonly ["suspended", "needs_review"];
export type ParkLedgerEventType = (typeof PARK_LEDGER_EVENT_TYPES)[number];
/**
 * 🔴 **模型自由文本行名的运行时闭集**(B-106 / S-268)—— 与 {@link PARK_LEDGER_EVENT_TYPES} 同一条理由、
 * 同一种锁步形。
 *
 * 这两行(`text` = 模型写给用户的文本,`reasoning` = 同一支笔的 CoT)是账本上**唯二**逐字携带模型散文的型,
 * 所以脱敏臂必须按词分派;把词表留在脱敏臂里手抄,就会重演 park 那一案:「仓里加第三个自由文本行名并登记进
 * `LedgerEventType`,写口照写照落,回放时明文,脱敏臂一声不吭」。
 */
export declare const MODEL_TEXT_LEDGER_EVENT_TYPES: readonly ["text", "reasoning"];
export type ModelTextLedgerEventType = (typeof MODEL_TEXT_LEDGER_EVENT_TYPES)[number];
/** 模型自由文本行名的**收窄谓词**(与 park 谓词同形)。 */
export declare function isModelTextLedgerEventType(v: string): v is ModelTextLedgerEventType;
/** park 行名的**收窄谓词**(消费点要的是「这个词是不是 park 词」+ 类型收窄,不是一次裸 includes)。 */
export declare function isParkLedgerEventType(v: string): v is ParkLedgerEventType;
//# sourceMappingURL=ledger-events.d.ts.map