diff --git a/Doc/isa/指令集优化.md b/Doc/isa/指令集优化.md
index dfd6e5e..82bb16d 100644
--- a/Doc/isa/指令集优化.md
+++ b/Doc/isa/指令集优化.md
@@ -173,19 +173,19 @@
 | A6 | sidecar/I/O 绑定 | **已定案**：与现状一致——绑定粒度仍 `slot = 槽号`（指向槽表条目），channel/bit 语义不变 |
 | A7 | disasm 文本格式 | **已定案**：**类型后缀**形式：`LOAD.I16 r5, s3`、`STORE.U32 s1, r7`、`ADD.F64 r1, r2, r3` |
 | A8 | machine.toml V2 schema | **已定案**：type 表 = **编译器内建基元别名**（bit/int8/int16/int32/int64/uint8/uint16/uint32/uint64/float32/float64）：REAL→base float32（=C float）、LREAL→base float64（=C double），其余按位宽/符号映射；op 表 {name, op(0..63), fmt} + fmt/type 位段互锁校验 |
-| A9 | 字面量类型推断 | **基本消解**：ST 字面量恒在表达式/赋值中，上下文（目标类型或运算类型）恒存在，v1 无"裸字面量"位置；进制字面量按上下文适配，默认 DINT 仅作兜底——**反问待答**（见 §8） |
+| ~~A9~~ | ~~字面量类型推断~~ | **已定案**：按上下文适配；默认 DINT 仅作兜底语义（上下文恒存在，正常程序不触发） |
 | A10 | FB 编码 | **反问待答**：为什么 FB 要 8 个 op（CAL_TON..CAL_F_TRIG）？可收敛为 1 个 CAL + FB 类型 id（立即数，查 machine.toml fb 表）——op 位段省 7 个、新增 FB 不加 opcode（见 §8） |
 
 另：CALL 的 V2 确认（随 A10）——ret_pc 字节化（随跳转已定）；CALL（IMM 形态）rd 恒 0；帧/寄存器约定不变（r0..r7 复制）。
 
 ## 8. 待讨论（用户反问）
 
-### A9：什么情况下会没有上下文？
+### A9：什么情况下会没有上下文？（已定案）
 
 ST 中字面量只能出现在表达式/赋值里（`x := 5`、`y + 5`、`IF 16#FF > t THEN`），
 目标类型或运算操作数类型恒在，v1 无"裸字面量"位置——**上下文恒存在**。
 因此"默认 DINT"只是防御性兜底（编译器内部缺类型时的报错路径），
-正常程序不触发。结论：按上下文适配即可，默认 DINT 保留为兜底语义。
+正常程序不触发。结论：按上下文适配即可，默认 DINT 保留为兜底语义。**已确认（2026-08-24）**。
 
 ### A10：FB 为什么会有 8 种？
 
@@ -234,4 +234,5 @@ V2 的 op 位段仅 6 位（64 个），FB 占 8 个不划算，且 machine.toml
 - 字面量：用户定支持 IEC 进制前缀（2#/8#/16#）
 - A2 定案：LOADK 用 type 位段解释常量值（与 LOAD 语义统一）；常量表条目 8B 无 tag；IMM64 预留不发射
 - A3..A8 定案（2026-08-24）：计数器单/双字两种；DATE 字面量不支持；TIME/浮点运算按推荐；sidecar 一致；disasm 类型后缀；type 表=基元别名（REAL→float32、LREAL→float64）
-- A9/A10 提出反问待讨论：字面量上下文恒存在；FB 8 op 可收敛为 1 CAL + fb 类型 id
+- A9 定案：按上下文适配、默认 DINT 兜底（用户确认）
+- A10 提出反问待讨论：FB 8 op 可收敛为 1 CAL + fb 类型 id