msgexchange-v2/docs/flight-state.md

# 航班运行数据接入与当前状态管理设计

本文是航班状态接入与当前态存储的唯一设计与架构规范文档：统一界定系统职责、存储模型、字段语义、状态流转与跨模块不变量。已定决策与演进红线以正文为准；未完成项与开放风险在各节显式标注。

**标注约定**：正文未加标注的段落是规范要求；凡标注「开放项 / 未决 / 已知偏差 / 待补 / 验收目标 / 现状」的段落，是对当前实现或未定设计的如实披露，不是已交付事实，两类内容不得混作依据。

## 阅读速览：专用数据与设计逻辑

### 专用数据与术语

| 数据 / 术语 | 含义与用途 |
|---|---|
| SIS / AODB | SIS 是 AODB（机场运行数据库，上游业务权威）向各子系统分发数据的接口规范（SIS_AODB_RMS V0.1）；本系统从共享 MySQL 信箱接收 AODB 报文。共享信箱是接入边界，本地数据库是本模块对外提供当前状态的唯一读取源，不是高于 AODB 的业务权威。 |
| `FLID` | AODB 分配的航班唯一 ID（Number(1-12)，规范 §3.16.2）；主表一行对应一个 `FLID`，明细、状态事件及删除通知均按它归属航班。`FLID` ≠ 航班号（`FLNO` 是标量列）：关键键字段（航司代码、航班号、航班日期、航班时间、进离港标识）变更时，AODB 以「删除事件 FDEL + 新航班事件 ADFT」重新指名，两个事件的 `FLID` 可能不同（规范 §3.18）；主航班与代码共享航班各有 `FLID`、事件分别发送，经 `MAID`/`TAID` 关联。 |
| `FLIGHT_SCHD` + 9 张明细表 | 一个航班的完整权威态：主表保存标量、异常对象前缀列及文本字段；明细表保存 10 类变长集合，其中 ROUT/ERUT 共用路线表。展示视图只是只读投影。 |
| `FDAY`（名单归属运营日） | 当前负责该航班成员管理与差删的日计划快照所覆盖的运营日（三个日期概念中的「名单归属日期」，区分见 §3.2），不是报文接收日或落库日，也不承诺等同于业务运营日。`NULL` 表示尚未被任何日计划代收录，不表示航班没有运行日；跨日归属由整包快照更新，动态事件不修改。 |
| `SCHD_GEN` / `SCHD_GEN_FLID` | 每个运营日的快照账本与当前成员名单。成员资格以名单为准；差删先比较新旧名单，再用当前 `FDAY` 防止误删已迁往其他运营日的航班。 |
| `VERSION` / `STATE_VERSION` | 前者是同一运营日的快照版本，每次新快照推进；后者是单个航班的状态版本。运营日、快照版本、航班状态版本是不同维度。 |
| `identity_key` / `LAST_MESSAGE_ID` | 前者按“发送方\|类型\|子类型\|序号”识别重复业务消息；后者追踪最近一次写入消息，其中快照账本的该字段用于最近一条快照的重放短路，不能拦住任意历史快照。 |
| `ORDINAL` / `SOURCE_SEQ` | 前者是明细输入顺序（从 1 起），后者保存报文中的源序号。源序号可空、不唯一，资源号也不是去重依据，不能据此把多条分配记录合并为一条。 |
| SCHD：DNLD / RESP / ADFT | 日计划相关报文。DNLD、RESP 按整包快照换代并差删；ADFT 是单航班临时增量，不换代、不差删、不完成请求。当前仅 DNLD 接入，RESP/ADFT 及请求闭环仍有未决项。 |
| FLOP / GTDT | FLOP 是字段级航班运行事件；规范 §3.19–3.43 定义了 25 类航班级事件（AODB→RMS 事件总计 44 类，§3.1–3.44），GTDT（§3.34）是其中的登机门更新。当前仅接入 GTDT；动态事件只表达所携带字段的变化。 |
| `REQ_TRACK` / `COUTMSGS` | 前者登记请求及其应答、超时状态，后者承担请求出站 outbox；出站发送与超时重发尚未实现。 |
| `PROC_STATE` / `BACKFILL_TODO` | 前者记录消息处理状态，后者记录共享信箱回填补偿。回填意图与业务终态同事务持久化仍是待补齐目标。 |
| `KAFKA_SCHD` / `KAFKA_MSG` / tombstone | 分别表示航班整态投影、变更通知、删除通知。整态投递可合并同航班的中间版本，消费端按整态替换处理、不得按补丁合并。本文 tombstone 指自定义删除事件：载荷仅含 `FLID` 与 `DELETED` 标记、value 非 null，**不是** Kafka 日志压缩语义的原生墓碑消息，Kafka 不会对其执行压缩删除。 |

集合与异常、文本字段的逐项映射见第 6 节；表结构职责与代际记账见第 3 节；一个运营日的数据全景、历史版本不留存决策与跨运营日清理（开放项）见 §3.5/§3.6。

### 设计逻辑

- **提交**：单活动主泵（即消息处理主循环，下同）按 FIFO 推进；航班状态、快照账本、outbox 与处理终态同事务提交，回填和投递在提交后独立重试。
- **合并**：快照与动态事件均保留未出现的字段，显式清除才清空；同日快照覆盖其携带字段的已有值。集合按整组替换，保留全部条目及顺序。
- **记账**：`SCHD_GEN` 每运营日一行，记录最近成功提交的快照版本和消息 ID；`SCHD_GEN_FLID` 每运营日保存该版快照的完整航班名单，新版提交时替换旧名单。
- **差删**：从旧名单中找出新快照不再包含的航班，仅删除当前 `FLIGHT_SCHD.FDAY` 仍等于该运营日的记录。未入代航班和已迁往其他日的航班保留，见 §3.3 示例。
- **投递**：`KAFKA_SCHD` 按航班聚合为最新整态，删除发 tombstone；`KAFKA_MSG` 仅通知变化，两个主题不保证先后顺序。

## 1. 系统定位与核心不变量

本系统作为消息交换与航班运行状态汇聚核心：从共享 MySQL 信箱接入 SIS（AODB）报文，按报文语义把报文合并进本地权威的"航班当前状态"，再把状态变化以标准化领域事件发往 Kafka。

系统坚持三条架构底线：

- **单一权威状态（Single Source of Truth）。** 本地数据库是本模块对外提供当前状态的唯一读取源；共享 MySQL 信箱与 Kafka 均为本地提交之后的外围边界，各自独立重试，任何外围故障都不会让已提交的状态回滚或重复计算。它不是高于 AODB 的业务权威——上游业务事实以 AODB 为源，本模块是其在本系统范围内的当前态投影。
- **单活动主泵（Single Active Pump）。** 生产部署约束为同一时刻仅一个实例执行信箱消费与状态推进。事务行锁可以串行化所有遵守该锁协议的数据库事务（跨进程、跨实例同样生效），但行锁本身不能实现消息认领、主实例选举、故障切换或全链路 FIFO——跨实例安全由「单活动实例」部署约束保证，而非行锁。
- **单提交事务（Single Commit Transaction）。** 状态、outbox 事件、处理终态（`PROC_STATE`）在同一个本地事务内落库，全部成功或整体回滚。

**职责边界。** 本模块只同步上游报文并维护当前态，不推导业务状态：取消、延误、备降、返航等运行状态由上游报文给定（对应 FDEL/CNCL/FDIV/FRET 等事件，规范 §3.27–3.33），本模块不做状态机推导；登机、登机结束等旅客服务状态不在接入范围。实际时间取 SIS §3.20 口径——进港为 ATA、出港为 ATD 的单值时间（本地列 `ACTT`），不区分 A-CDM 建模的落地/入位/离位/起飞等多节点；进出港过站关联按到港记录携带的 TAOP/TAFL/TAID 原样保存（见 §3.2）。

处理按信箱 FIFO 严格有序推进，按业务身份幂等去重，失败按指数退避重试。

数据库口径：现场目标库为 Oracle 11g；当前实际接通并作为验证基准的只有 PostgreSQL，本文描述 PostgreSQL 实现细节。

## 2. 关键架构决策

| 架构决策 | 理由与边界 |
|---|---|
| 状态、快照代、处理终态与 outbox 同库提交 | 消除 Redis 状态与数据库终态跨库双写窗口；Redis 等缓存不参与动态状态权威。 |
| 当前验证基准为 PostgreSQL，现场目标库为 Oracle 11g | 单次部署只绑定一个内部权威库；Oracle 尚未完成全链路适配，不可作为运行时可用配置开关。 |
| 航班标量主表 + 9 张关系明细表 | 完整保留 10 类变长集合的输入顺序、源序号及多条资源/操作记录，不按展示槽位截断。 |
| 异常对象保留主表前缀列；SRVT/VIPF/MAFL 保留文本列 | 既有载体可承载时不新增抽象或关系表；其读写语义需以回归证明。 |
| 单活动主泵，事务内 `PIPELINE_LOCK` 行锁 | 行锁串行化遵守锁协议的数据库事务（跨实例同样生效），但不实现消息认领、FIFO 或跨实例协调；跨实例安全依赖单活动实例部署约束。 |
| 外部回填与事件投递按幂等重试处理 | 不使用跨库分布式事务；回填意图与业务终态同事务持久化是待补齐目标（见第 8 节）。 |
| 展示视图仅为只读投影 | 仅展示前序资源（前两个登机门/柜台等），不作为全量权威状态或数据一致性比对输入。 |

**废弃方案与架构约束。** 系统明确放弃：固定 GATE1/GATE2 式槽位作为权威、"超界数据静默丢弃"、"零子表为架构约束"、"存储模型决定零方言迁移成本"、以及脱离全量备份前提的 RPO=0 承诺。历史决策论证与撤销记录见 [决策历史](legacy/decision-flight-state-history.md)。

## 3. 存储：标量主表 + 9 张明细表

### 3.1 为何不采用固定槽位

航班资源本质是变长集合，数量因航班、机型与保障安排而异。SIS 规范 §2 资源限制表给出协议上限：登机门、值机柜台、行李转盘每航班各 99，计划机位 9、当前机位 1，实际机位移动数量不限；规范未给出数量下限，本设计不做数量假设。ACM2-29 曾采用"全标量宽表、零子表"（GATE1/GATE2 式固定槽位），当日即被推翻——槽位会截断数据，而设计约束要求保留重复资源的全部属性、输入顺序与源序号。结论：标量进主表，集合进明细表。

### 3.2 表清单

| 表 | 职责 |
|---|---|
| `FLIGHT_SCHD` | 主表，一行一 `FLID`：标量字段、异常前缀列、`SRVT/VIPF/MAFL_TEXT`、`FDAY`、`STATE_VERSION`、`LAST_MESSAGE_ID` 与时间戳。 |
| 8 张集合明细表 | `flight_gate`/`flight_checkin`/`flight_belt`/`flight_stand_plan`/`flight_chute`/`flight_delay`/`flight_bridge_op`/`flight_chock_op`；当前主键 `(FLID, ORDINAL)`。 |
| `FLIGHT_ROUTE_POINT` | 第 9 张明细表；ROUT/ERUT 两类路线共用，以 `ROUTE_KIND` 区分。 |
| `SCHD_GEN` / `SCHD_GEN_FLID` | 快照代际记账，见 3.3。 |
| `PIPELINE_LOCK` | 单写者行锁：每个处理事务先锁 `FLIGHT_SCHD_WRITER` 行；缺失时两事务并发读写同一航班会互相覆盖。 |
| `BACKFILL_TODO` | 回填补偿待办，见第 8 节。 |
| `FLIGHT_SCHD_DISPLAY` | PG 展示视图（前两个登机门/柜台、首个转盘/延误、资源数）；仅为投影，非状态来源。 |

9 张明细表承载 10 类集合——路线表一张覆盖两类。

**`FDAY` 的语义。** 涉及「日期」的三个概念必须区分：**航班业务日期**（该航班实例业务上归属哪一天、以什么口径确定——模型不保存，ADFT/动态新增行 `FDAY=NULL` 正是因为模型不为未上计划的行保存业务日期）、**快照覆盖日期**（本份快照查询/发布的运营日 D）、**名单归属日期**（当前由哪一天的快照负责其成员管理与差删）。`FLIGHT_SCHD.FDAY` 保存的是第三者，由整包快照赋值，与接收日、落库日无关。三者在本协议下通常同值，但那是快照接管规则的结果，不是定义使然。动态事件保留 `FDAY`；动态新增或 ADFT 新增航班尚未被收录时为 `NULL`，后续被快照收录再赋值。`NULL` 不表示航班没有运行日，其清理规则见第 7 节。

**过站关联与报文排序（协议事实）。** 到港记录携带 TAOP/TAFL/TAID——离开当前机场的过站连接航班的承运人代码/航班号/AODB ID，仅到港有效（§3.16.2）；SCHD 报文内离港航班先于到港航班、代码共享航班跟在主航班之后（§3.16.1 排序注释）。注意：V1.1 迁移注释把 TAOP/TAFL/TAID 标注为「实际承运」，与规范的「过站连接」语义不符，待核对修正（ACM2-31）。

### 3.3 快照记账：每运营日一份版本记录、一份成员名单

**记账单位是运营日，同一天可以多次更新。** 例如 9 月 9 日的日计划先后收到三份快照，对应同一运营日的版本 1、2、3。“换代”指替换该日的当前版本及名单，不是进入下一个自然日。两张账本表记录当前版，不保存各历史版本的完整航班状态。

#### 三份数据各记什么

| 数据 | 记录粒度 | 内容 | 用途 |
|---|---|---|---|
| `SCHD_GEN` | 每运营日一行 | `FDAY`、`VERSION`、`LAST_MESSAGE_ID` | 记录该日最近成功提交的快照版本及消息；版本用于 CAS，消息 ID 用于最近一条快照的重放判断。 |
| `SCHD_GEN_FLID` | 每运营日、每成员航班一条记录 | 运营日与 `FLID` 的对应关系 | 保存该日当前版快照包含的完整名单，作为下一次比较的旧名单；新版提交时整体替换。 |
| `FLIGHT_SCHD` | 每 `FLID` 一行 | 航班当前状态及 `FDAY` | 保存快照与动态事件合并后的状态；`FDAY` 表示当前归属，差删时据此排除已跨日迁移的航班。 |

`SCHD_GEN.VERSION` 是日计划快照版本；`FLIGHT_SCHD.STATE_VERSION` 是单航班状态版本。动态事件可以推进后者，但不更新快照版本或成员名单。

#### 一份新快照如何更新账本

设快照覆盖运营日为 D，消息 ID 为 M，航班名单为 N。以下动作与航班状态、outbox、处理终态在同一事务内完成：

1. 锁内读取 D 的账本和旧名单 O。首次快照没有旧名单，按空集比较，成功提交后版本为 1。
2. 若 M 等于账本的 `LAST_MESSAGE_ID`，按最近快照重放短路：不改航班状态、不替换名单、不推进版本、不新增事件；处理成功并执行提交后回填。
3. 计算候选差删名单 `O − N`。逐项检查当前航班主行，只保留 `FLIGHT_SCHD.FDAY = D` 的航班作为实际删除对象。
4. 合并写入 N 中各航班的状态，将它们的 `FDAY` 设为 D；删除实际差删对象的主行、全部明细，并登记 tombstone。
5. 将 D 的 `SCHD_GEN_FLID` 名单整体替换为 N；以旧版本为条件执行 CAS，将 `VERSION` 加 1，并把 `LAST_MESSAGE_ID` 更新为 M。版本不符则整个事务回滚。
6. 登记状态事件和处理成功状态，提交。任一步失败，旧版本、旧名单和旧航班状态一并保留，不产生半份快照。

因此，版本计数对应**成功提交的新快照**，不是接收次数；失败重试和最近快照重放不额外加版本。

#### 示例：同日替换与跨日保护

下表以 A、B、C 表示三个 `FLID`，日期均为 2026 年。

| 顺序 | 输入 | `SCHD_GEN` 提交后 | `SCHD_GEN_FLID` 提交后 | 航班状态变化 |
|---|---|---|---|---|
| 1 | M1：9/9 快照 `{A, B}` | 9/9：版本 1，消息 M1 | 9/9：`{A, B}` | A、B 写入，`FDAY=9/9`。 |
| 2 | M2：9/9 快照 `{A, C}` | 9/9：版本 2，消息 M2 | 9/9：`{A, C}` | 候选差删 `{B}`；B 仍属 9/9，删除 B 并登记 tombstone；A 更新，C 新增。 |
| 3 | M3：9/10 快照 `{C}` | 9/10：版本 1，消息 M3；9/9 不变 | 9/10：`{C}`；9/9 仍为 `{A, C}` | C 被 9/10 快照收录，主行 `FDAY` 改为 9/10。 |
| 4 | M4：9/9 快照 `{A}` | 9/9：版本 3，消息 M4 | 9/9：`{A}`；9/10 仍为 `{C}` | 候选差删 `{C}`；C 当前属 9/10，保留主行和明细，不发删除事件。 |
| 5 | M4 再次进入快照重放检查 | 不变 | 不变 | 命中 9/9 的最近消息 ID，状态和事件不重复写入。 |

第 3 步说明两者为何都需要：**旧日名单记着上次快照包含 C，主行 `FDAY` 记着 C 已归属新日。** 名单负责找出消失者，主行归属负责判断能否删除。仅凭旧名单会误删跨日航班；仅扫描主行 `FDAY` 则丢失了“上次快照包含谁”的依据。

**重放的三种去向。** 同一条报文重新到达有三种情形，去重与重放守卫各管一层：

- **入口去重**：同一消息首次处理时已绑定 `identity_key`（见 4.1），再次从信箱到达按重复 `SKIPPED`。
- **同一消息重试**：事务内失败退回重试时，消息未提交过，正常走全流程；提交成功后因入口去重不会重算。
- **人工重放**：历史快照报文（其消息 ID ≠ 当前 `LAST_MESSAGE_ID`）不会命中重放短路；若已清空入口身份记录而被人工重放，本设计不承诺旧状态不被覆盖——人工重放须携带明确的版本/业务日期策略方可放行（见第 7 节）。

需明确的实现约束：

1. **明细表不声明外键。** 清理动作由仓储显式执行，不依赖数据库级联。`SOURCE_SEQ` 可空且不唯一，仅为记录性质——逐条定位更新的 Apply 协议本期不实现（无生产调用方，且定位键不可靠）。
2. **差删按代圈定范围，不扫 `FDAY`。** 目标运营日 = 本份快照覆盖的运营日。最终删除集合 =（旧名单 − 新名单）∩ 当前仍 `FDAY`=目标运营日的航班；仅对该集合显式删除明细行与主行。`FDAY=NULL`、已归属其他运营日、未在旧名单中的航班均不受本次差删影响；删除与名单替换同事务提交。
3. **演进纪律。** 不为尚无消费者的查询新增类型化时间列、摘要、额外载荷表或索引；时间类字段先保留原始字符串，字段与长度以已应用迁移为准。
4. **跨日归属回迁（未决）。** 上述流程把新名单 N 中各航班的 `FDAY` 一律置为 D：若某航班已被更晚运营日的快照接管（`FDAY=D'`），一份迟到的旧日快照再次收录它时会把 `FDAY` 改回 D，并以旧值覆盖新日的合并态（示例：C 已属 9/10，迟到的 9/9 快照仍含 C → C 被改回 9/9）。现行「跨日保护」（约束 2）只拦截差删删除，不拦截归属回写与字段回退。归属迁移的时序判断是开放项（ACM2-31）；定案前本设计不承诺 `FDAY` 单向迁移。

### 3.4 已知待修

路线表当前主键为 `(FLID, ORDINAL)`：同一航班 ROUT 与 ERUT 各自从序号 1 起写，二者共存即冲突。计划通过新迁移改为 `(FLID, ROUTE_KIND, ORDINAL)`（见 ACM2-30）。

### 3.5 一个运营日的数据全景

运营日 D 的快照提交后，库内构成如下整体视图：

| 数据 | 当天形态 |
|---|---|
| `SCHD_GEN` | 一行：D 的最新快照版本与 `LAST_MESSAGE_ID`，同日内被各次快照顺序覆盖。 |
| `SCHD_GEN_FLID` | 当前版快照的完整名单 N，每次新快照整体替换。 |
| `FLIGHT_SCHD` | 被 D 收录的航班各一行（`FDAY=D`），入库后可继续被动态事件推进；跨日被新快照收录时 `FDAY` 改写。 |
| 9 张明细表 | 各 `FDAY=D` 航班的集合行，随每次写入整组替换。 |
| tombstone / outbox | 差删航班与整态投递事件，与上述状态同事务落账。 |

**历史版本不留存（已定决策；下列为四项独立决策，不可互相推论）。** ① **不保存状态历史**：账本只记当前版，同日快照版本 1→2→3 的中间完整状态不保存；② **不逐条投递中间版本**：`KAFKA_SCHD` 只按当前整态输出；③ **不提供历史查询**：无此接口；④ **不保存原始报文**：由共享信箱侧保留策略决定，不是本模块承诺。①② 的理由：权威态唯一，差删与 CAS 只依赖当前名单与版本，消费端按 `(FLID, STATE_VERSION, UPDATED_AT)` 去重也不依赖中间版本。后果：当日被覆盖的中间态不可从库中恢复；「可凭重放原始报文重建」依赖信箱保留期限、处理顺序与解析器版本，只是理论可能性，不作为恢复承诺。需要中间态历史线或审计留存时须另行设计，本设计不承担。

### 3.6 跨运营日生命周期

- 差删是历史航班出场的唯一常规路径：旧名单 − 新名单 ∩ 仍属本日的航班，同事务删除主行、明细并登记 tombstone。
- 被新运营日快照接管的航班，其集合经整组替换，仅保留最新值、不保存被替换记录（同 3.5 决策）。
- `FDAY=NULL` 未归属行的清理见第 7 节；已归属历史日的数据没有对应的清理规则。
- **开放项（未决）**：旧运营日的 `SCHD_GEN` / `SCHD_GEN_FLID` 行随日期无限累积，当前无定期清理或归档设计；快照长期停发时历史日留存航班也无兜底清理。清理策略须待真实保留期限需求定案后补齐，清理动作须经 `FLIGHT_SCHD` 与账本的一致性校验，不得破坏差删依赖的"旧名单 + 主行 `FDAY`"双依据。跨日归属回迁的时序防护同样未决（§3.3 约束 4）。

## 4. 状态的两条来路

状态仅有两条来源，各成一条处理线：

- **请求/下载线（基准）。** 建立**指定运营日**航班的基准全量。本系统向 AODB 发送日计划请求，AODB 返回 SCHD 报文——该运营日的全部航班——快照整体落库；该运营日未再出现的航班被差删。
- **动态线（运行事件）。** 跟踪运行中的持续变化——实际时间、登机门开关、值机柜台、行李转盘、延误、靠撤桥、轮挡等。FLOP 字段级事件在规范 §3.19–3.43 共 25 类（AODB→RMS 事件总计 44 类），当前仅接入 GTDT 一类；单条报文只变更一个航班的一类资源，其余字段不受影响。

两条线共用同一入口与同一套事务/失败规则：进入事务后统一为"锁内读态 → 合并 → 写库 → 事件入 outbox → 终态 → 提交 → 回填"。

```text
信箱队头 → 解码 → 绑定身份（去重）→ 按 Handler 路由
    ├─ SCHD-DNLD（已接通）────────→ 请求/下载线
    ├─ SCHD-RESP / ADFT（未接通）─→ 请求/下载线
    └─ FLOP 事件（已接 GTDT）────→ 动态线
```

图中「已接通/未接通」为适用范围标注，不是完成度承诺：「已接通」仅表示该类型已进入本设计的路由与事务链，解析、出站与应答闭环等环节是否齐备以 §4.2 各处未决标注为准。

### 4.1 公共入口（所有消息必经）

1. **排队。** 信箱消息与定时任务共用一个 FIFO 队列，主泵只处理队头；队头失败按退避等待，重试超限或队头滞留超过时限 → `DEAD`。一条异常报文会阻塞其后所有航班与定时任务：最大阻塞时限、隔离/旁路规则与告警阈值是运维未决参数（ACM2-31）。
2. **解码。** 报文非法 → `DEAD`（不重试）；解码器缺陷类错误 → `FAILED`（退避重试）。
3. **绑定身份。** 幂等键 = `发送方|类型|子类型|序号`，仅首次处理时绑定；该键已被其他消息占用 → `SKIPPED`（重复），自身照常回填共享信箱。协议中 SEQN 为发送方设置的 6 位序号（1–999999，规范 §2 元数据），其唯一范围与重置/回绕策略规范未定义；上游序号重置、重启后重复，以及同身份不同载荷时的处理均为未决项，当前实现仅按键判重（ACM2-31）。
4. **路由。** 按报文类型定位 Handler；无注册 Handler → `FAILED`（可重放，不写终态）。

### 4.2 请求/下载线：基准全量的建立

SIS 循环：本系统向 AODB 发送日计划请求 → AODB 返回 SCHD。三个子类型进入本流程时的规则：

| 子类型 | `FDAY` 来源 | 是否换代 | 是否参与差删 | 可完成请求 |
|---|---|---|---|---|
| **DNLD** | 快照覆盖的运营日 | 是 | 是（整包成员差） | 是（运营日匹配时） |
| **RESP** | 快照覆盖的运营日 | 是 | 是（整包成员差） | 是（且要求对应 `REQ_TRACK` 存在） |
| **ADFT** | 无（保持/置为 NULL） | 否 | 否 | 否 |

ADFT 为单条临时航班增量：只增改本条 `FLID`（整行整集合写入），不触发换代与整包差删，也不算完成任何请求。ADFT 报文不携带运营日，本行也不单独承载它：`FDAY=NULL` 仅表示该航班未被任何日计划代收录（见 §3.2）——临时航班在现实中有运行日，但模型不为未上计划的行保存该日期。同 `FLID` 后续被整包快照收录时由快照接管（见 §3.2 `FDAY` 语义）。

请求登记于 `REQ_TRACK`（同类并发=1，新请求把旧请求强制置 `EXPIRED`），出站经 `COUTMSGS` outbox——出站发送与超时重发尚未实现。

收到下载后的落库步骤：

1. 解析整包并校验，单包上限 10000 个航班（超限 → `DEAD`；协议口径：SCHD 单包不分段、不超过 CIIMS 10MB 上限，`RECS` 为 1–4 位记录数，§3.16.1）。**差删的完整性前提**：「本包 = 该运营日完整名单」由协议保证——规范注释明确日计划是「AODB 最新数据的完整快照」（§3.16.1 注释 2）、单包不分段、`RECS` 给出包内记录数（`RECS=0` 即空名单）；`RECS` 与实收航班数的核对、同包重复 `FLID` 的处理为待补校验（ACM2-31）。
2. 进入事务（先锁 `PIPELINE_LOCK` 行）：
   - **重放短路**：该消息已提交过（与 `SCHD_GEN.LAST_MESSAGE_ID` 相同，记账见 3.3）→ 直接 `SUCCEEDED`，不加版本、不发事件。
   - **算成员差**：新快照相对上代消失的航班进入差删名单。
   - **合并写入**：锁内逐航班读当前态 → 合并 → 整集合替换，`FDAY` 置为该快照覆盖的运营日（不是报文接收或落库日期）。
   - **差删**：删除差删名单内航班的明细与主行（规则见 3.3）；每个被删航班同事务登记一条 tombstone 事件入 outbox（载荷见第 8 节）。
   - **CAS 推进日代版本**：版本不符则整体回滚 → `FAILED(INFRA)` 退避。
   - **应答匹配**：与 `REQ_TRACK` 同事务联动——关联键 =（运营日, 发送方, 请求类型），完成该组合下最新一条 PENDING 请求（协议无请求关联号：RQFD 请求仅含时间范围筛选字段，RESP 也不回指请求报文，此关联键是规范约束下的替代方案，与「同类并发=1、新请求强制 EXPIRED 旧请求」共同收敛错配风险）；迟到（已 `EXPIRED`）或重复应答照常执行快照落库（数据仍权威），但不重复置完成、不报错；DNLD 仅在运营日匹配时完成请求，不按类型隐式完成。
   - 每个航班一条 `KAFKA_SCHD` 事件入 outbox；`PROC_STATE` → `SUCCEEDED`；提交。
3. 提交后回填共享信箱（失败落 `BACKFILL_TODO`，见第 8 节）；重放短路同样执行回填。

**同日重快照的权威规则（M）。** 整包快照是同日**最高权威**：两次快照之间已应用的动态运行更新（实际时间、登机门、柜台等），在重叠字段上以快照值覆盖（含快照显式清空）；动态报文更新当前状态，其与快照的冲突按本规则处理。快照省略的字段按「整行替换混合规则」（第 5、7 节）保留合并后当前值，不属于覆盖例外的组成部分。

**规则 M 的成立条件（未决）。** 本规则隐含两个上游前提：① 快照内容是 AODB 生成/发送时点的完整最新数据（§3.16.1 注释 2 支持生成时点口径）；② 两条线的投递顺序与上游发送顺序一致（共享信箱 FIFO + 同一发送方 SEQN 单调）。若前提 ② 不成立（快照生成后延迟投递、SEQN 按类型分段编号等），重叠字段会被旧值回退——例如 10:00 生成的快照 10:03 才入队，会把 10:02 已处理的登机门更新改回旧值。前提 ② 尚未从协议条款逐条核实，把规则 M 作为对外承诺前须经设计评审确认（ACM2-31）。

**示例：一次 DNLD 快照的落库。** 示例中的 CA100、MU201、CZ300 均为 AODB 分配的 `FLID` 值（写成形似航班号仅为可读；`FLNO` 航班号是主表标量列，与 `FLID` 无恒定关系）。报文为 AODB 下发的**运营日 2026-09-09** 的整包快照，含 CA100、MU201 两个航班（`FDAY` 取快照覆盖的运营日 2026-09-09，与该报文何时接收、何时落库无关）；库内该运营日的代（`SCHD_GEN`）当前成员为 CA100、CZ300。进入事务后依次发生：

| 步骤 | 动作 | 结果 |
|---|---|---|
| 重放检查 | 该消息 ID 等于日代 `LAST_MESSAGE_ID`？ | 否，继续 |
| 算成员差 | 上代成员 {CA100, CZ300} − 新快照 {CA100, MU201}，∩ 当前仍 `FDAY`=2026-09-09 | 差删名单 = {CZ300} |
| 合并写入 | CA100 已存在 → 锁内读态、整集合替换，`FDAY=2026-09-09`；MU201 新航班 → 先插主行再写明细 | 两航班状态就位 |
| 差删 | 删 CZ300 主行 + 全部明细行 | CZ300 消失 |
| CAS 推版本 | `SCHD_GEN` 版本 7 → 8；不符则整体回滚 `FAILED(INFRA)` | 版本推进 |
| 事件 | CA100、MU201 各一条 `KAFKA_SCHD` 入 outbox | |
| 终态 | `PROC_STATE` → `SUCCEEDED`，提交 | 提交后回填共享信箱 |

此后 Dispatcher 按 FLID 聚合这批 `KAFKA_SCHD` 发出（见第 8 节）。

**覆盖范围与未决。** 本流程的设计范围当前仅覆盖 DNLD 子类型；RESP 与 ADFT 的 Handler、「请求 → 应答 → 标记完成」闭环为未决设计项，未覆盖类型的处理按 `FAILED(UNSUPPORTED)` 对齐。参考数据请求（RQRD；参考数据事件见规范 §3.1–3.15）同样登记于 `REQ_TRACK`，但应答落参考库、由 RequestCoordinator 处理，与航班状态无关。

### 4.3 动态线：运行事件的落库（以 GTDT 为例）

1. **Handler 纯函数决策。** 输入 = 受影响航班当前态 + 报文，输出 = 字段变更与待发事件；此步不算账、不落库。每类资源的语义在 Handler 内固定，如 GTDT 为登机门集合整体替换（GTNO=0 表示清除）。
2. 进入事务（先锁 `PIPELINE_LOCK` 行）：
   - 每个受影响航班：锁内重读最新态 → 合并字段变更 → 整集合替换写入，保留既有 `FDAY`（保留该行所属的运营日/代；动态事件不携带也不推断运营日，跨运营日的归属更正只由请求/下载线的快照接管完成，见 §3.2）。
   - 事件（`KAFKA_MSG` 变更通知 + `KAFKA_SCHD` 状态推送）入 outbox；`PROC_STATE` → `SUCCEEDED`；提交。
3. 提交后回填共享信箱（同上）。

**示例：一条 GTDT 报文如何变更登机门。** 报文（FLOP 增量，仅携带登机门，其余字段未出现）：

```text
META: SNDR=AODB, TYPE=FLOP, STYP=GTDT, SEQN=42
FLOP: FLID=CA100
  GTDT GTNO=1  GATE=A1  GTYP=D
  GTDT GTNO=3  GATE=B2  GTYP=I
```

库内 CA100 当前登机门为 G28（序号 1）、G33（序号 2）。处理过程：

1. **解析字段集**：GTDT = [(GTNO=1, GATE=A1, GTYP=D), (GTNO=3, GATE=B2, GTYP=I)]。其余键未出现 = 不动——延误、机位、时间一概不碰。
2. **翻译命令**：GTDT 出现 → Replace，整组替换为这 2 条。
3. **锁内合并**：读当前态 → 整组替换 → 版本 +1、记 `LAST_MESSAGE_ID`。
4. **写库**：`flight_gate` 中 CA100 旧 2 行删除，按输入顺序插入 2 行（ORDINAL=1,2；SOURCE_SEQ=1,3）；GTDT 无标量列，主表仅推进版本/消息/更新时间。
5. **事件**：`KAFKA_MSG` 变更通知；`KAFKA_SCHD` 载荷 `"GTDT":[{"GATE":"A1","GTNO":"1","GTYP":"D"},{"GATE":"B2","GTNO":"3","GTYP":"I"}]`——JSON 数组、不做二次字符串编码，键按字典序。
6. **提交后**：回填共享信箱。

读回时按 ORDINAL 组装主行与 `flight_gate` 2 行为权威态；展示视图取前两个登机门 A1、B2。

**清除与拒绝语义示例：**

- `<GTDT GTNO="0"/>` 单条且全 0 → Clear：`flight_gate` 行删空，`KAFKA_SCHD` 中 GTDT 键消失。
- `[{"GTNO":"1","GATE":"A1"},{"GTNO":"0"}]`：0 与正常条目混排 → 非法结构，整条消息失败，不猜测、不截断。
- 字段未出现 ≠ 清除：仅收到一条 DELY 报文时登机门不受影响。
- 异常键的空值才构成 Clear：FDIV 出现为 `{}` → Clear → `FDIV_*` 列全部置 NULL；SRVT 为空串/null 目前不算 Clear（见第 6 节），只有显式 Clear 命令能清列。

## 5. 状态变更实现（两条线共用）

所有状态变更统一经加工链：**报文 → 命令 → 合并出新状态 → 写库**。

### 5.1 数据统一形态

内存中一个航班的状态即一个模型（`FlightNextState`）：一组标量键值 + 10 类集合（每类为一组条目，每条目一组键值）+ 版本/消息追踪字段。主表存标量、明细表存集合，列映射固定（如 GTDT 的 GATE/GOTM/GCTM → `flight_gate` 对应列）；读回时按 ORDINAL 组装集合，数据库权威态 = 主行 + 明细行。

### 5.2 第一步：报文到命令

当前 Handler 返回字段集，`commandsFromFields` 将其翻译为命令；仓储仍会解析异常/文本 JSON，显式命令尚未贯通全部边界。

| 命令 | 标量 | 集合 |
|---|---|---|
| Unchanged（未出现） | 不修改 | 不修改 |
| Set(value)（出现） | 覆盖 | — |
| Clear | 删键，物理列置 NULL | 删除全部明细行 |
| Replace(list) | — | 同事务 DELETE + 批量 INSERT 整集合替换 |
| Apply(item, sourceSeq) | — | 引擎内预留：按首个 SOURCE_SEQ 匹配更新，否则追加；无生产调用方，尚非已确认协议 |

规则：

- **字段未出现 = 不动。** 增量报文只携带变化部分，其余不受影响。
- **标量出现 = Set（覆盖）。** 异常键（FDIV/FRET/FLAB）载荷为空串、null、空对象时 = Clear。
- **集合出现 = Replace。** 整组替换为报文给定条目。条目序号属性（如 GTNO）为 "0" 是协议显式清除标记：仅当集合内**全部**条目均为 0 时翻译为 Clear；与正常条目混排属非法结构，fail fast 拒绝。
- **空数组 `[]` = Replace(空集)**，明细行清空——区别于字段缺失的 Unchanged。
- DELY 无协议序号属性，不支持逐条 Apply；清除走空数组替换。

**验收目标。** 非法 JSON、未知形状、超容输入不得在截断后成功。当前 `parseCollection` 未校验数组元素必须是对象，仓储会忽略未知属性；该目标尚未完成。

### 5.3 第二步：命令合并进当前态（纯函数）

`FlightStateEngine.apply` 从当前态拷贝一份并逐条应用命令：Set 覆盖键值；Clear 删键并记入 clearedKeys（被清除的标量键清单，供第三步写库时据此将物理列置 NULL）；Replace 整组替换。随后版本 +1、记 `LAST_MESSAGE_ID`，产出 `FlightNextState`。纯函数：不碰库、不发事件，同样输入恒得同样输出。

### 5.4 第三步：新状态写库（唯一写入口 `persistNextStates`）

- **写库写的是合并后完整态，不是报文字段。** 主表与集合写入的输入是锁内合并后的完整 `FlightNextState`；「未提字段一律不动」发生在引擎合并层（5.3），不在写库层。快照线整行替换（`FDAY`=该快照覆盖的运营日）写出的同样是合并后状态——快照省略的字段以合并流程结束时的当前值持久化。例：航班当前态含 `ESTT=0900`（预计时间）与登机门 {G28}，快照给出 `STD`、`ACTT=1012`（实际时间，进港语义 ATA/出港 ATD）与登机门 {A1}，省略 `ESTT` → 输出 = `STD`/`ACTT`/登机门改为快照值，`ESTT` 保留 0900。若快照显式给空（Clear/空数组）才构成清空。`FDAY` 由快照 Set 显式推进，是保留规则唯一的结构性例外。
- **动态线**仅 UPDATE 本次出现的列，clearedKeys 对应物理列显式置 NULL；新航班先插一行 `FDAY=NULL`——动态消息不携带运营日、不触发换代，新行尚未被任何日计划代收录（并非"无运营日"），待后续被某运营日整包快照收录时由快照赋值（清理见第 7 节「未归属行」）。
- **明细集合**：每次写航班，9 张明细表对该 `FLID` 先 DELETE 再按合并后集合整组 INSERT——即使某集合本次未变也重写，以保证库内与内存状态严格一致。此即"整集合替换"的落地：ORDINAL 按输入顺序 1..N，SOURCE_SEQ 存协议序号，RECORD_VERSION 记写入时版本。
- `last_message_id` / `state_version` / `updated_at` 一并更新。

### 5.5 事件由状态序列化而来

`KAFKA_SCHD` 载荷 = `FlightNextState` 序列化（`FlightFieldsJson`）：键按字典序输出保证同状态字节级稳定；集合键输出为 JSON 数组/对象，不做二次字符串编码。快照线的事件与落库共用同一份事务内状态；动态线的事件目前来自 Handler 的锁外预览（见 5.6），偏差收敛前动态事件载荷不承诺与提交状态逐字节一致——对外状态的最终一致性由投递聚合按当前整态投影兜底（第 8 节）。

### 5.6 已知偏差（待收敛）

GTDT Handler 在事务外先算一遍预览并构造事件，主泵在事务内再算一遍；该偏差收敛前，不能宣称动态事件载荷与提交状态一致（见 5.5，投递侧以整态投影兜底）。目标状态为 Handler 只表达业务变化，事务内产出唯一一份 nextState，落库与 `KAFKA_SCHD` 共用——尚未实现，列为可靠性验收项。

## 6. 字段语义矩阵

### 6.1 16 类结构映射

| 集合键 | 存储载体 | 序号属性 | 出现语义 | 显式清除 | Apply |
|---|---|---|---|---|---|
| GTDT 登机门 | `flight_gate` | GTNO | Replace | GTNO=0 全清 | 引擎预留（未启用；GTNO 定位） |
| CKDT 值机柜台 | `flight_checkin` | CKNO | Replace | CKNO=0 全清 | 引擎预留（未启用）；同 CHKC 多舱位分配按 CKNO 区分，不按资源号去重 |
| CLDT 行李转盘 | `flight_belt` | CLNO | Replace | CLNO=0 全清 | 引擎预留（未启用） |
| PSDT 计划机位 | `flight_stand_plan` | PSNO | Replace | PSNO=0 全清 | 引擎预留（未启用） |
| CHDT 行李滑槽 | `flight_chute` | CHNO | Replace | CHNO=0 全清 | 引擎预留（未启用） |
| DELY 延误 | `flight_delay` | 无 | Replace（仅保存本次集合，不追加历史） | `[]` 清空 | 不支持（协议无定位键） |
| ABTM 靠撤桥 | `flight_bridge_op` | ASNO | Replace（操作全集） | ASNO=0 全清 | 引擎预留（未启用；ASNO 定位，多次靠/撤桥各占一行） |
| CHOT 轮挡 | `flight_chock_op` | CSNO | Replace | CSNO=0 全清 | 引擎预留（未启用；CHID=ON/OFF 为业务属性，非序号） |
| ROUT 计划航路 | `flight_route_point(route_kind=ROUT)` | RTNO | Replace | RTNO=0 全清 | 引擎预留（未启用） |
| ERUT 扩展航路 | `flight_route_point(route_kind=ERUT)` | RTNO | Replace | RTNO=0 全清 | 引擎预留（未启用） |
| FDIV 备降 | 主表前缀列 `FDIV_*` | — | Set（对象） | `"null"`/`{}`/空串 → Clear | — |
| FRET 返航 | 主表前缀列 `FRET_*` | — | Set | 同上 | — |
| FLAB 中止 | 主表前缀列 `FLAB_*` | — | Set | 同上 | — |
| SRVT 服务 | 主表 `SRVT_TEXT` | — | Set | 当前字段转换器不将 null/{}/空串转 Clear；显式 ScalarCommand.Clear 可清列 | — |
| VIPF 贵宾 | 主表 `VIPF_TEXT` | — | Set | 同 SRVT | — |
| MAFL 共享航班 | 主表 `MAFL_TEXT` | — | Set | 同 SRVT | 无查询需求时维持现有载体 |

公共明细列：`FLID`（逻辑归属，当前无数据库外键）、`ORDINAL`（输入顺序，1 起）、`SOURCE_SEQ`（报文序号属性，如 GTNO=3；仅记录，不参与定位、不唯一）、`RECORD_VERSION`、`CREATED_AT/UPDATED_AT`（整组替换为物理重写：`CREATED_AT` 反映最近一次重建时刻，不是业务记录时间）；当前主键 `(FLID, ORDINAL)`。路线表尚需把 ROUTE_KIND 纳入主键以避免 ROUT/ERUT 冲突。相同资源号不代表同一条分配记录，禁止按资源号去重。**表中"引擎预留（未启用）"的 Apply 仅指引擎分支存在，生产只生成 Replace/Clear。**

**集合全集语义：协议依据与待确认项。** 快照线（SCHD）可按全集理解：规范注释明确日计划是「AODB 最新数据的完整快照」，可选字段/段未出现即 AODB 无此信息、子系统应删除本地已有值（§3.16.1 注释 4），DELY 亦明确「该标签对所有已记录延误重复出现」。动态线各事件每次携带全量集合还是仅本次变更，规范未逐条写明——CHOT 的 CSNO 实为机位序号（非轮挡序号），每段记录一次上/下轮挡移动（§3.22.2），若事件仅携带本次移动，Replace 会丢失既有操作记录；各集合「序号=0 全清」的协议出处也需逐类核实。动态线集合语义确认前，Replace 全集语义仅对快照线可视为定案（ACM2-31 未决）。

### 6.2 清除的库内与线上表达

- 库内：标量/异常/文本键 Clear → 对应列置 `NULL`；集合键 Clear/Replace(空集) → 明细行删除。
- 线上（`KAFKA_SCHD`）：清空的表达**定为键缺失**——Clear 与 Replace(空集) 事件同语义，`KAFKA_SCHD` 载荷不输出该集合键；下游不得把「键缺失」与「`[]`」作两种解释。库内读回（无键）与 wire 表达按此收敛，黄金样例按此口径固定（投递聚合与 tombstone 见第 8 节）。
- **两个方向的「缺失」语义相反**，消费契约必须写明：上游输入报文中字段缺失 = Unchanged（保留原值）；下游 `KAFKA_SCHD` 整态投影中字段/键缺失 = 当前态无该数据，消费端应移除本地旧值。下游接收的是整态替换，不得按补丁合并。
- 异常对象 Set 在增量 SQL 中仅写出现的属性；旧对象被省略的属性可能残留，与对象整体替换目标不一致，待回归修正。

### 6.3 时区与空值

- `FDAY` 只记录日期（该行所属代覆盖的运营日，见 §3.2），其来源与日界都按「快照覆盖的运营日」口径：由日计划快照决定，不由报文接收/落库时刻推算——跨午夜接收不改变归属；动态事件不更新 `FDAY`。
- SIS 时间串（`DDMONYYHHMM`，机场当地时）原值保存；类型化提升按实际查询需要另行定案。
- PG 当前保留字符串空值，集合 JSON null 属性会被解析为空串。Oracle 11g 对零长度字符值按 NULL 处理是官方文档明确的既定行为，不再是待确认的数据库事实；待验证的是本模块在该行为下能否维持字段语义——空串往返、SRVT/VIPF/MAFL「空串不算 Clear」的判断、显式命令的持久化保真，均列为 Oracle 适配的交付门槛验证项。

## 7. 失败规则与不变量（两条线共用）

事务内任一步失败 → 整体回滚，消息记 `FAILED` 退避重试。已提交的成功不受后续失败影响：回填与投递失败仅落补偿待办，不降级 `SUCCEEDED`，不重放业务。

**不变量：**

- **状态、事件、终态同事务**：库内可见的必是完整提交结果。
- **计算是合并不是覆盖；写库是一致不是增量。** 报文未提字段一律不动（加工链见第 5 节）；写入库的永远是锁内合并后的完整 `FlightNextState`，其中包括快照线整行替换写出的合并后状态（混合规则与例见 5.4）。快照线更新 `FDAY`（置为该快照覆盖的运营日），动态线保留 `FDAY`（不改变归属、不推断运营日），动态/ADFT 新行 `FDAY=NULL`（尚未被任何运营日代收录，不等于无运营日）。
- **快照是同日最高权威**：重叠字段上快照覆盖动态更新（见 4.2 规则 M 及其成立条件标注）；动态报文更新当前状态，与快照的冲突按规则 M 处理。
- **快照重放仅一道防线**：凭 `schd_gen.last_message_id`（见 3.3）识别最近一次快照的重放；消息去重凭 `identity_key`；版本号只是顺序令牌。更早历史快照的重入是否安全，依赖人工重放的版本/业务日期策略（见 3.3 重放三种去向）。
- **未归属行（`FDAY=NULL`）的生命周期**：动态线先于快照到达或从未上日计划的 `FLID` 以 `FDAY=NULL` 建行，不隶属任何代、差删不触达，不引用 `SCHD_GEN` 名单。其清理由定期历史化作业执行：条件 = 最后更新时间超过 N 天（默认 7，可配置）且未被任何待答请求/名单引用；N 的默认值须有真实消费方复核后启用。已归属历史日的账本行与航班清理为另一独立未决项（见 §3.6），不适用本规则。

**错误分类与队列行为（目标矩阵）：**

| 错误类别 | 示例 | 终态 | 重试 | 队头行为 |
|---|---|---|---|---|
| 协议结构非法（解码乱码/0 与正常条目混排/未知形状/缺身份键） | §5.2 非法结构 | `DEAD` | 不重试 | 立即释放 |
| 容量超限（单包 >10000 航班等） | §4.2 超限 | `DEAD` | 不重试 | 立即释放 |
| 无注册 Handler | 路由不到 Handler（4.1） | `FAILED`，不写终态 | 不自动重试，可人工重放 | 队头滞留至超限 |
| 未定义 SCHD 子类型 | 未在子类型规则表中的子类型 | 现状 `FAILED(UNSUPPORTED)`；目标终态待定案（其余行为以本行现状标注为准） | 不自动重试 | 队头滞留至超限 |
| 解码器缺陷/内部错误 | 事务 DB 故障 `FAILED(INFRA)` | `FAILED` → 退避 | 超限转 `DEAD` | 队头滞留直至超限 |
| 并发版本 CAS 冲突 | 日代推进版本不符 | 事务回滚（无终态） | 同事务或下一轮重读自动重试 | 队头滞留直至成功 |
| 人工重放 | — | 仅 `DEAD` 消息可人工重放，须携带版本/业务日期策略（见 4.2/3.3） | — | — |

矩阵中「既有」：`DEAD`/`FAILED` 两类终态、CAS 自动回滚、队头失败退避；「待补校验」：超容与结构非法的显式拒绝（§5.2 验收目标）、未定义子类型的终态归属、人工重放的幂等身份策略（失败前已绑定的 `identity_key` 与重放身份的关系未定义）。每类错误有且只有一个默认路径，以本矩阵行为准。

字段缺失、清除、空数组、异常对象的精确行为见第 6 节。

## 8. 提交之后：回填与事件

提交成功后有两件外部副作用：回填共享 MySQL 信箱、异步投递 Kafka，二者各自独立重试。

回填恢复依赖一条持久待办：

- **现状**：仅在回填失败后写 `BACKFILL_TODO`；提交后立即崩溃的窗口内没有待办，无法恢复。
- **目标**：在业务终态同一事务内登记回填意图，提交后回填成功即删待办。崩溃后自然有账可查，无需额外"重启对账框架"。
- **红线**：登记待办后再失败，不得把已提交的 `SUCCEEDED` 降级为 `FAILED`。

**`KAFKA_SCHD` 投递语义（按 FLID 聚合，第 8 节的主体）。** Dispatcher 聚合未发出的同 `FLID` 事件，按该 `FLID` **当前整态投影**输出——不是逐事件补丁流：

- 同 `FLID` 多条未发事件合并为一次按最新 `STATE_VERSION` 生成的整态载荷；中间版本的载荷不逐条补发。
- 旧批次的投递重试可晚于新批次发出；消费端以 `(FLID, STATE_VERSION, UPDATED_AT)` 去重，晚到的旧投影不应覆盖新状态。
- `KAFKA_MSG` 仅作变更通知，不承载状态；两个主题之间不承诺顺序。
- 未归属行约定（第 7 节）与 tombstone（下）也是事件身份的一部分：`FLID` 不重复重发。
- **tombstone（差删的对外删除语义；自定义删除事件，非 Kafka 原生墓碑）**：被差删航班的最后一类 `KAFKA_SCHD` 事件以 tombstone 表达——载荷仅含 `FLID` 与 `DELETED` 标记（无状态字段；value 非 null，Kafka 不会按日志压缩语义处理它）；与差删同事务登记，投递失败照常重试、不过期，下游接到后删除该 `FLID` 本地数据。删除通知不携带版本号：迟到删除、删除后恢复与旧更新事件的冲突消解由消费端负责；主行物理删除后 `STATE_VERSION` 的连续性（删除前与重建后的事件可能同号）未定义——删除事件的版本/世代标识为开放项（ACM2-31）。

## 9. 读取路径

当前读一个航班 = 主行 1 次 + 10 类集合各 1 次，共 11 次查询；全量读 N 个航班约 1+10N 次（N=航班数，主行批量 1 次 + 每航班 10 类集合各 1 次）。多次读不一定落在同一数据库快照，主子状态不保证一致。

后续在仓储边界按 FLID 批次加载明细，并明确一致性读事务；投递侧 Dispatcher 的整态投影读取受同一缺口影响，一并纳入验收。不引入缓存权威或通用查询框架。`GET /all/flights` 仍是 Controller TODO——仓储方法与展示视图存在不等于接口已交付。

`KAFKA_SCHD` 输出结构化 JSON，集合禁止双重编码为字符串。清空的 wire 表达已按第 6 节定案（键缺失）；未知属性、异常局部替换与空值往返仍存在验收缺口（见第 6 节）；单个全字段样例通过并不等于整个 SIS 协议无损。