docs(acm2-75): Q1 定案 schd record 粒度沿用旧系统整批单条

docs/specification.md

@@ -54,7 +54,7 @@
 
 ### 2.4 下游（admin-api、网页客户端与运营航班显示界面）
 
-- **C-9** 航班变更发到 Kafka 主题 `msg`（单条）和 `schd`（批量）；`schd` 的内容是 `SCHD.FLTR` 序列化出的 JSON，空字段不输出，边界是定时任务的一次 tick——两次 tick 之间积累的变化整批发一次，没有变化就不发；删除航班不进 `schd`，只由 `msg` 发一条删除通知；不设消息键。同一条可能发多次。
+- **C-9** 航班变更发到 Kafka 主题 `msg`（单条）和 `schd`（批量）；`schd` 沿用旧系统粒度：两次 tick 之间积累的变化序列化成一个 `SCHD.FLTR` 数组 JSON，整批作为单条 record 发出（`Q1`），空字段不输出，没有变化就不发；删除航班不进 `schd`，只由 `msg` 发一条删除通知；不设消息键。同一条可能发多次。
 - **C-10** 静态参考数据写入本系统数据库，供 admin-api 只读；本系统不调用 admin-api。
 - **C-11** 航班投影写入 Redis，供读取全体动态航班；`GET /all/flights` 与网页客户端读同一份；返回 JSON 由消息文档中的 XML 结构转换而来（`Q6`、`Q21`）。
 
@@ -106,7 +106,7 @@
 
 | 编号 | 事项 | 当前假定 | 影响 |
 |---|---|---|---|
-| Q1 | `schd` 的 Kafka record 粒度 | 按 `C-9` 是每条 record 一条运营航班 JSON；旧系统相反，把两次定时 tick 之间积累的整批序列化成一个 JSON 数组作为单条 record 发出 | 消费方的解析方式与 `C-9` 二者只能取一 |
+| Q1 | `schd` 的 Kafka record 粒度 | 已定原则：按旧系统，两次 tick 之间积累的整批序列化成一个 JSON 数组作为单条 record 发出（`C-9`） | 消费方未确认按此格式解析 |
 | Q2 | 请求与应答按时间匹配时的时钟偏斜容忍判据 | 比较前统一时区与单位（implementation.md「上游请求与静态数据」） | 容忍判据未定前，降级匹配不得描述为精确关联 |
 | Q3 | 现场会发但 SIS 未定义的子类型（靠桥、延误等）的报文形态与逐类终态 | 按现有处理逻辑延续，不得因 SIS 未记载就丢掉（`US-05` AC1） | 逐类终态与幂等规则未定（`G-FLOP-SEMANTICS`） |
 | Q4 | 上游重发时是否可能改发正文 | 报文不可变，绑定身份后不比对内容（implementation.md「消息、身份与决策」） | 改发正文的重发会被判为重复并跳过 |