fix(acp): v1 协商连接仍会读写 v2 草案 wire（读路径无闸门 / 四族无写闸门 / structured diff 破坏 round-trip）

[YoungSx]

优先级与时间窗

高。 这些是已经在 develop 上的行为缺陷，不是未来功能：v1 已协商的连接现在就会读出、并在某些路径写出 v2 草案 wire。与 #149 的关系是：#149 记录「v2 有哪些东西没建模」，本 issue 记录「已建模的这些东西泄漏进了 v1 通道」。

修法与 #165（草案面公开边界）有交集（读路径的正解顺带会被那边的重构做掉），建议两个一起排，并先定公开面方向再动手 —— 否则这里做的写路径闸门会被返工。

结论

PR #160 建模的 v2 wire 与 v1 通道之间没有完整隔离，三处具体缺陷：

1. 读路径完全没有版本闸门 —— v1 连接收到 v2 判别值仍会物化成草案类型交给上层。
2. 四族在 V1 默认写上下文照常吐 v2 报文 —— whole-message、terminal、tool_call_content_chunk、plan_update。
3. StructuredDiff 在 v1 读得进、写不出 —— 破坏 round-trip，违反 AGENTS.md §11「协议宽松度不得反向收紧」明文的原样 round-trip 要求。

这三条合起来意味着 AGENTS.md §11 要求的「显式草案上下文的隔离 wire 测试」目前只覆盖 2/6 族。

证据链

1. 版本检查全都只在 Write 一侧

src/SalmonEgg.Acp/Protocol/SessionWorkStateUpdateTypes.cs:199   Write: if (AcpProtocolWriteContext.Current != V2) throw
src/SalmonEgg.Acp/Protocol/SessionWorkStateUpdateTypes.cs:150-178  Read: 无任何版本检查
src/SalmonEgg.Acp/Tool/DiffTypes.cs:248                          同样只在 Write
src/SalmonEgg.Acp/Protocol/OtherSessionTypes.cs:275              同样只在 Write
src/SalmonEgg.Acp/Protocol/SessionUpdateTypes.cs:70-76           7 个 v2 判别子静态注册在 public SessionUpdate 上

AcpProtocolWriteContext 顾名思义只是写上下文（src/SalmonEgg.Acp/Protocol/AcpProtocolWriteContext.cs），读路径没有对应概念。于是在已协商为 v1 的连接上，agent 发来 "sessionUpdate":"agent_message" / "terminal_update" / "state_update"，SDK 会照样绑定成草案类型交给上层。

AcpProtocolVersion.RuntimeServed = V1 这个「唯一权威」（AcpProtocolVersion.cs:63）在读方向上其实是半开的。任何只比对这个常量的门禁都发现不了这一点。

2. 四族零闸门（逐文件计数）

Protocol/SessionUpdateTypes.cs              AcpProtocolWriteContext 出现 0 次
Protocol/TerminalUpdateTypes.cs             AcpProtocolWriteContext 出现 0 次
Protocol/V2SupplementalTypes.cs             AcpProtocolWriteContext 出现 0 次
Protocol/SessionWorkStateUpdateTypes.cs     出现 1 次   ← state_update 有闸门
Tool/DiffTypes.cs                           出现 1 次   ← structured diff 有闸门

tests/SalmonEgg.Acp.Tests/Protocol/TerminalUpdateTypesTests.cs:105-129 就是在默认（V1）上下文里断言 terminal_update 的 v2 报文形态成立 —— 现状被测试固化了。

3. StructuredDiff 的 round-trip 破坏

StructuredDiff 与 v1 的 flat diff 共用 "diff" 判别值，只靠有没有 changes 数组区分（src/SalmonEgg.Acp/Tool/DiffTypes.cs:185-187）。于是 v1 连接上收到一个带 changes 的 diff → 绑成 StructuredDiff → 在 V1 上下文不可再序列化（:248 抛 JsonException）。

在 PR #160 之前，这种载荷会落到 CustomToolCallContent 原样 round-trip。所以这是一次行为回归，而不只是「新功能没做完」。

正解与反模式

反模式：别照抄现有的「写时抛」

现有 state_update / structured diff 用的是「先绑定成草案类型，写的时候如果不是 V2 上下文就抛」。这个形状本身就是次优解 —— 它制造了「读得进、写不出」，也就是第 3 条缺陷的形状。如果给剩下四族照抄这个写法，等于把 round-trip 破坏面从 1 族扩大到 5 族。

正解：读路径分流

v1 上下文下根本不该绑定成草案类型，而应走 passthrough：这样既不吐 v2 报文，又保持原样 round-trip，两条 AGENTS 规则同时满足。

好消息是基础设施已经就位。 SessionUpdate 的多态配置（SessionUpdateTypes.cs:55-58）已经是：

[JsonPolymorphic(
    TypeDiscriminatorPropertyName = "sessionUpdate",
    UnknownDerivedTypeHandling = JsonUnknownDerivedTypeHandling.FallBackToBaseType,
    IgnoreUnrecognizedTypeDiscriminators = true)]

未知判别值回落到基类 + ExtensionData 承载完整 payload（已有测试 SessionUpdatePolymorphismTests.cs:39 Deserialize_UnknownSessionUpdate_FallsBack…）。也就是说 —— 把 v2 判别子从 [JsonDerivedType] 列表里摘掉，v1 上下文下的 round-trip 就自动是对的。

但 [JsonDerivedType] 是静态特性，无法按运行时上下文动态注册。要做上下文相关分流，必须走手工分派 —— 而 SessionUpdateParams 已经有手工转换器 SessionUpdateParamsJsonConverter（SessionUpdateTypes.cs:113），同文件 :224 的 StateSessionUpdateWireFormat 就是现成先例（注释里已写明 STJ 不支持第二判别子，所以扁平化只能落在容器转换器上）。

这正是它与 #165 的交集：那边若选择把判别子搬进转换器 + 草案面 internal 化，这里的读路径闸门顺带就做完了。所以先定那边的方向。

"diff" 判别值的处置

v1 flat diff 与 v2 structured diff 共用判别值这件事无法靠改判别值解决（协议就是这么定的）。建议：在 v1 上下文下，带 changes 的 diff 走 CustomToolCallContent passthrough（恢复 #160 之前的行为）；只在 v2 上下文下绑成 StructuredDiff。

验证要求

照 #149 已定的标准，逐项都要：

• v1 与 v2 两条线的报文级断言，互不串味 —— v1 报文不得出现 v2 字段，反之亦然。六族都要有（现在只有 state_update 和 structured diff 有）。
• 读方向也要有断言，不能只测写方向：v1 上下文下喂 v2 判别值 → 断言落到 passthrough 且原样 round-trip 回去（字节级或字段级不丢）；v2 上下文下喂同一份 → 断言绑成对应草案类型。
• 反向验证：拆掉版本判别后，对应报文断言必须转红。
• TerminalUpdateTypesTests.cs:105-129 这类在默认上下文断言 v2 形态的测试要一并改成显式 v2 上下文，否则它会锁死错误行为。
• scripts/gates/run-acp-sdk-gates.sh 全绿；scripts/gates/wasm-capability-boundary-smoke.mjs:96-126 已覆盖「真实 WASM initialize 只发 v1 形态」，本次改动不应触及它，但要确认仍绿。

参考资料

• 上游 v2 schema（机器可解析）：https://raw.githubusercontent.com/zed-industries/agent-client-protocol/main/schema/v2/schema.json
• v1 schema：https://agentclientprotocol.com/llms.txt → protocol/v1/schema.md
• STJ 多态与未知判别值：https://learn.microsoft.com/dotnet/standard/serialization/system-text-json/polymorphism
• AGENTS.md §11：「草案协议的生产默认与能力门控」、「协议宽松度不得反向收紧」、「判别联合消费必须白名单」、「对端违反协议时的归责与呈现」
• 相关：chore(acp): ACP v2 draft 缺口清账（state_update 生命周期、整消息 upsert、终端归属、diff 结构化等） #149（v2 缺口清账）

[YoungSx]

实施方案（读了官方规格之后，本 issue 正文里「必须走手工分派」那个结论要改）

官方规格怎么说 —— 这决定了修法的形状

出处	原文
protocol/v2/migration.md	"a single connection always speaks exactly one negotiated version after initialize"
同上	"Each side selects its v1 or v2 surface per connection based on the negotiated version."
protocol/v2/initialization.md	"Clients and Agents MUST agree on a protocol version and act according to its specification."
protocol/v2/extensibility.md	"Implementations SHOULD preserve unknown values and any raw tagged-union payloads."
同上	"Closed discriminators can still reject unknown values when the receiver cannot safely continue without understanding the variant."
protocol/v1/extensibility.md	"Implementations SHOULD ignore unrecognized notifications."（对未知判别值完全未提）

「按协商版本为每条连接挑一个面」是规格原话。所以正解不是"把草案判别子搬进手工转换器"，而是让判别子集合成为协商版本的属性。

两版 SessionUpdate 的权威对照

拉自 schema/v1/schema.json 与 schema/v2/schema.json（v1 那份存在，本 issue 参考资料里写的 404 是错的，路径写错了）：

	联合写法	discriminator 关键字	兜底变体	具名变体
v1	oneOf	有	0 → 封闭	11
v2	anyOf	无	1 → 开放	16

仅 v1 有（v2 已删）: current_mode_update, plan, tool_call
仅 v2 有：           agent_message, agent_thought, plan_update, state_update,
                     terminal_output_chunk, terminal_update, tool_call_content_chunk, user_message
两版共有（8 个）：    agent_message_chunk, agent_thought_chunk, available_commands_update,
                     config_option_update, session_info_update, tool_call_update,
                     usage_update, user_message_chunk

仓库现状：一张静态表 18 条 [JsonDerivedType]（11 v1 + 7 v2）+ 转换器里的 state_update = 19 条，一个连接能看见全部。建模是完整且正确的（11 与 v1 逐个对上、8 与 v2 逐个对上），缺的只是选择。

补一条本 issue 漏记的镜像缺陷

本 issue 只记了「v1 连接会认 v2 变体」。反方向同样破：一旦 v2 跑起来，那张单表会让 v2 连接照样认 tool_call / plan / current_mode_update —— 这三个是 v2 明确删掉的。同一根因、同一修法。

这也说明「把 7 个草案判别子直接删掉」那个省事方案是错的：修一半、留一半，而且留下的那半会在 v2 落地时咬人。

方案：版本携带在 resolver 上，不在环境状态里、也不在手工分派里

「有哪些判别子」是协商版本的属性；在 STJ 里「该用哪份契约」正好是 IJsonTypeInfoResolver 决定的事。所以：

internal sealed class AcpWireFormat : IJsonTypeInfoResolver
{
    public int Version { get; }
    public JsonTypeInfo? GetTypeInfo(Type type, JsonSerializerOptions options)
    {
        var info = _inner.GetTypeInfo(type, options);   // AcpJsonContext.Default（源生成）
        if (info?.Type == typeof(SessionUpdate))
            PruneToNegotiatedSurface(info.PolymorphismOptions, Version);
        return info;
    }
}

19 个 [JsonDerivedType] 一条都不动 —— 完整映射仍在一处、仍被源生成 AOT 检查、#168 上线的判别子清点门禁继续管用。版本靠"递进去哪副 options"表达，而这正是 SDK 已有的传递方式（options.GetTypeInfo(...)）。

已实测（最小工程，IsAotCompatible + TreatWarningsAsErrors，0 警告）

问	答
修改器能在源生成的 JsonTypeInfo 上摘派生类型？	✅ 一侧 1 条、另一侧 2 条
AOT / 裁剪分析器放行？	✅ 0 警告（前提是用 GetTypeInfo 重载，不是 Deserialize<T>(string, options)——后者直接 IL2026+IL3050）
v1 读到被摘掉的判别值 → 回落基类 + ExtensionData 捕获？	✅
v2 读同一份 → 物化成对应类型？	✅
共有变体两侧都正常？	✅
交叉污染（先摸 v2 再摸 v1）？	✅ 无，两个 options 各拿独立 JsonTypeInfo 实例，与访问顺序无关
反复取 / 8 线程并发？	✅ 稳定
透过 JsonTypeInfoResolver.Combine 包一层（MessageParser 就是这么组的）？	✅ 仍生效
转换器能否从 options.TypeInfoResolver 取回版本？	✅ 所以 AcpProtocolWriteContext（AsyncLocal）可以整个删掉

两个必须配套的坑（也是实测出来的）

① v1 上写一个 v2-only 实例，不抛异常 —— 静默吐 {}。 摘掉派生类型后基类没属性，全部字段静默蒸发。今天是静默吐完整 v2 wire（协议违规），改完是静默吐空对象 —— 两个都不能接受，所以显式写闸门无论走哪条路都得有。这不是"照抄写时抛反模式"：反模式是只在写侧设闸门而读侧照绑，导致"读得进写不出"；这里读侧已经不绑了，写闸门只是把"你构造了一个本连接发不出的对象"这件事显式报错而不是静默丢数据。

② 收口 AcpJsonContext.Default。 实测：直接拿 AcpJsonContext.Default 读，完全不受版本约束。分布：

Client/AcpClient.cs            44 处  ← 全部经 ToElement/FromElement 两个漏斗
Protocol/InitializeTypes.cs    17 处  ← 在转换器内部，应改用传入的 options
Protocol/Elicitation*.cs        6 处  ← 同上
JsonRpc/MessageParser.cs        1 处  ← Combine 的一个成员，保留

AcpClient 那 44 处是好消息：两个漏斗。把 ToElement<T>(value, typeInfo) / FromElement<T>(element, typeInfo) 改成不收 typeInfo、从 _wire 解析，44 处就少一个参数 —— 而且调用点再也没法指名一个上下文，旁路在这 44 处是被结构消掉的，不只是被门禁挡住。

转换器里那 23 处是另一个潜伏缺陷：转换器拿到的是版本化 options，却对嵌套类型退回未版本化的 AcpJsonContext.Default。今天无害（ClientInfo 等不区分版本），但它是逃逸口。仓库其它转换器（SessionUpdateTypes.cs、V2SupplementalTypes.cs）已经用的是 options.GetTypeInfo(...)，改成一致即可。

一处对本 issue「正解」的修正

本 issue 写「v1 上下文下根本不该绑定成草案类型，而应走 passthrough」—— 对。但要说清 passthrough 是我们的选择，不是 v1 规格的命令：

• v1 的 SessionUpdate 是封闭联合，未知变体意味着对端违反了协商的规格。规格给的路是 ignore（v1 扩展性页）或 reject（v2 扩展性页对封闭判别子的说法）。
• 「逐字保留并 round-trip」是 v2 的机制（rfds/v2/enum-variant-extension），v1 规格没有这条。SessionUpdateTypes.cs:80-84 的注释把它写成"协议要求"，是把我们的选择说成了规格的命令，要改。
• 仍然选保留，理由要写明：AGENTS.md「协议宽松度不得反向收紧」禁止把现有宽松度改严；代理场景需要原样转发；v2 本身要求保留。同时 UnknownUpdateKind 要留着并且是归责口 —— v1 上出现未知变体就是对端违规，这跟 HasStopReason 是同一个道理，别静默吞掉。

分阶段（每阶段独立可验证）

阶段 1 —— 接缝，零行为变化
新增 AcpWireFormat（此时不裁剪任何东西）+ 每版本一份缓存 JsonSerializerOptions；AcpClient 加 _wire，协商成功后（AcpClient.cs:281）重选；ToElement/FromElement 去掉 typeInfo 参数。全绿、行为不变。

阶段 2 —— 按版本裁剪变体集合（真正的修复）
判别子 → 版本归属表放在 [JsonDerivedType] 声明旁边，单一真源；门禁断言「表的键 == 声明的判别子 ∪ {state_update}」且每条至少归属一个版本（新增声明不分类就红）。state_update 留在转换器侧，但只在 v2 接受/产出。#168 的 PinnedDraftSessionUpdateDiscriminators 与这张表合并。
测试：v1 喂 v2 判别值 → 回落基类 + UnknownUpdateKind 有值 + 逐字 round-trip；v2 喂 v1 已删判别值 → 同样；两个方向都反向验证。TerminalUpdateTypesTests.cs:105-129 这类在默认上下文断言 v2 形态的测试改成显式 v2 options。

阶段 3 —— 删掉 AsyncLocal
6 处 AcpProtocolWriteContext.Current 改为从 options 取版本；删 AcpProtocolWriteContext（63 行）；测试里 8 处 Enter(V2) 改成递 v2 options。
（InitializeTypes 不动 —— 它从报文自带的 value.ProtocolVersion 分叉，那是比环境状态更好的来源，是现成的正样本。）

阶段 4 —— 写闸门 + diff passthrough + 收口 + 文档
写 v2-only 实例经 v1 options → 抛明确 JsonException（而非静默 {}）；"diff" 判别值在 v1 上带 changes 时走 CustomToolCallContent passthrough（恢复 #160 前行为）；转换器里 23 处 AcpJsonContext.Default 改用 options.GetTypeInfo(...)；门禁断言生产代码只在接缝内引用 AcpJsonContext.Default；改掉那句"协议要求逐字保留"的注释。

与 #165 的关系（更新）

#165 已由 PR #168 交付，没有把判别子搬进手工转换器 —— 它把那 7 条 + state_update 清点钉死了，所以这个缺口在本 issue 动手前不会悄悄变大。原来的排期约束（"先定 #165 方向"）已解除：本方案两条路都不选，可以直接开工。

[YoungSx]

PR #169 已开（叠在 #168 上，base = feat/acp-draft-surface-165；#168 合入 develop 后 GitHub 会自动改基）。四个提交按阶段推进：接缝（零行为变化）→ 按版本裁剪 → 删 AsyncLocal → 写闸门与收口。

本 issue 正文有三处需要更正，都是查了官方规格与上游 schema JSON 之后的结论：

1. 「必须走手工分派」不成立。 规格原话是 protocol/v2/migration.md："a single connection always speaks exactly one negotiated version after initialize" + "Each side selects its v1 or v2 surface per connection based on the negotiated version." 「挑一个面」在 STJ 里就是 IJsonTypeInfoResolver 决定的事，所以版本挂在 resolver 上，19 个判别子的映射仍在一处、仍被源生成 AOT 检查。

2. 漏了镜像方向。 本 issue 只记了「v1 会认 v2 变体」。v2 删掉了 tool_call/plan/current_mode_update，所以那张单表一旦 v2 跑起来会让 v2 连接照样认这三个。两个面互不为超集，同一根因、同一修法 —— 这也是「直接删掉 7 个草案判别子」那个省事方案错的原因。

3. 「参考资料」里 v1 schema 的路径写错了。 schema/v1/schema.json 存在（246KB）；站点 markdown 会截断（拉 protocol/v2/schema.md 时内容在 ElicitationPropertySchema 中途就断，到不了 SessionUpdate）。版本面比对必须用 JSON。

「正解」那段也要加一句限定。 本 issue 写「v1 上下文下根本不该绑定成草案类型，而应走 passthrough」—— 对，但 passthrough 是我们的选择而不是 v1 规格的命令：v1 的 SessionUpdate 是封闭 oneOf（discriminator 关键字、零兜底），v1 扩展性页只说 SHOULD ignore 未识别通知；逐字保留是 v2 的机制（anyOf + 开放兜底 + "SHOULD preserve unknown values and any raw tagged-union payloads"）。仍然选保留，理由已写进代码注释：AGENTS 禁止收紧既有宽松度、代理要原样转发、UnknownUpdateKind 才能把违规归给对端。SessionUpdateTypes.cs 里原来那句「协议要求…」已改掉。

另外炸出一个陷阱，值得单独记： STJ 源生成默认模式的 fast-path 按上下文实例解析嵌套契约（生成为 JsonSerializer.Serialize(writer, value.ReplayFrom, SessionReplayFrom)，属性读的是 AcpJsonContext.Default.Options），所以携带在 options 上的版本跨一层嵌套就丢：拿 v2 契约序列化 SessionResumeParams 会在 SessionReplayFromJsonConverter 里拿到 v1 options 并抛错。已改 GenerationMode = Metadata，并断言 SerializeHandler 为 null —— 行为测试只覆盖它恰好走到的嵌套。

验证：509 测试 0 失败、门禁六步全绿、消费方 smoke 全绿、下游三工程 0 warning；反向验证 14 条全红 0 假绿（含我第一次配错对的那条，说明在 PR 正文里）。

[YoungSx]

PR #169 已被合入 feat/acp-draft-surface-165（rebase merge，内容逐字相同 —— 已用 git diff 核对为空）。

所以本 issue 的交付现在装在 #168 里，不是 #169 —— #168 是那条唯一指向 develop 的 PR，现在带 11 个提交（前 7 个是 #165，后 4 个是本 issue）。已做的处理：

• feat(acp): 标记 v2 草案公开面，并按协商版本选择 wire 面 #168 标题与正文重写成两部分，把 fix(acp): v1 协商连接仍会读写 v2 草案 wire（读路径无闸门 / 四族无写闸门 / structured diff 破坏 round-trip） #166 的要点内联（评审不必回头翻 fix(acp): 按协商版本给每条连接选择 session update 面 #169）
• Closes #165 之外补上 Closes #166 —— 否则合 feat(acp): 标记 v2 草案公开面，并按协商版本选择 wire 面 #168 不会关掉本 issue
• feat(acp): 标记 v2 草案公开面，并按协商版本选择 wire 面 #168 原正文里那段「范围边界：不含 fix(acp): v1 协商连接仍会读写 v2 草案 wire（读路径无闸门 / 四族无写闸门 / structured diff 破坏 round-trip） #166」已作废并明确标注。它说本 issue 的修法取决于「7 个 v2 判别子留在 [JsonDerivedType] 还是搬进手工转换器」，查了规格之后两条都不选：protocol/v2/migration.md 说的是「Each side selects its v1 or v2 surface per connection based on the negotiated version」，「挑一个面」在 STJ 里是 IJsonTypeInfoResolver 的活，所以 19 个判别子的映射仍在一处、仍被源生成 AOT 检查

#168 现在跑的是完整 16 项门禁（base 是 develop）。已过 7 项，含最相关的 ACP SDK Gates 与 ACP Consumer Integration，其余 8 项在跑。

顺带：feat/acp-per-version-wire-surface-166 这个远端分支现在是冗余的（内容已在 165 分支上，SHA 不同）。要不要删由你定，我没动。

[YoungSx]

已交付并合入 develop — 原 PR #169 先合入了 feat/acp-draft-surface-165，随后随 PR #168 一起合入 develop（合并提交 d46d8cdf），16/16 门禁全绿。

未被自动关闭的机制原因同 #165：Closes 关键字只在合入默认分支（main）时生效，#168 的 base 是 develop。

本 issue 正文的结论被推翻了 —— 修法不是手工分派

正文写「必须走手工分派」。读了官方规格之后，两条候选路（判别子留在 [JsonDerivedType] + AsyncLocal 读上下文 / 全部搬进手工转换器）都不选。规格原话给的是第三条：

Each side selects its v1 or v2 surface per connection based on the negotiated version.
— protocol/v2/migration.md

a single connection always speaks exactly one negotiated version after initialize
— 同上

「按协商版本为每条连接挑一个面」，在 System.Text.Json 里就是 IJsonTypeInfoResolver 的职责。于是版本挂在 resolver 上，18 个 [JsonDerivedType] 的声明位置不动。

正文漏记的镜像缺陷

本 issue 只记了「v1 连接会认 v2 变体」。反方向同样破：v2 删掉了 3 个变体（tool_call / plan / current_mode_update），单张静态表会让 v2 连接照样认它们。

从两版 schema JSON 实测比对：

	判别子数	仅该版本有
v1	具名 11	tool_call、plan、current_mode_update
v2	具名 16	user_message、agent_message、agent_thought、state_update、tool_call_content_chunk、terminal_update、terminal_output_chunk、plan_update

两个面互不为超集。 所以「直接删掉 7 个草案判别子」那个省事方案是错的 —— 修一半、留一半，留下的那半会在 v2 落地时咬人。

落地范围（develop 上的提交）

提交	内容
abdc4bfc	AcpWireFormat 接缝：44 处调用点再也无法指名一个上下文。零行为变化
17123036	按协商版本裁剪变体集合；静态特性收窄成只声明 v1 面
27c54c54	删掉 63 行 AcpProtocolWriteContext（AsyncLocal），6 个读点从手上的 options 取版本
d46d8cdf	表驱动写闸门、diff passthrough、收口 23 处旁路、修两处错的文档

三条施工中查实、值得记录的事

① STJ 源生成默认模式的 fast-path 会架空 options。 它按上下文实例解析嵌套契约（JsonSerializer.Serialize(writer, value.X, SomeContextProperty)），版本跨一层嵌套即丢失，而调用点看不出跨过了任何边界。已改 GenerationMode = Metadata；门禁断言 SerializeHandler 为 null，不只靠行为测试 —— 行为测试只覆盖它恰好走到的那层嵌套。

② 裁剪读契约只让写方向变安静，不变安全。 未定义的变体没有注册项可走，按基类写出去就是 {} —— 一个字段填满的 v2 更新静默变成空对象，比它替代掉的协议违规更糟（对端看到的是个"看起来合规"的更新）。所以另加了表驱动写闸门。

③ v1 保留未知变体是我们的选择，不是规格要求。 v1 的 SessionUpdate 是封闭 oneOf + discriminator、零兜底变体；v1 扩展性页只说 SHOULD ignore 未识别通知。逐字保留是 v2 的机制（anyOf + 1 个兜底变体 + "SHOULD preserve unknown values"）。仍然选保留（代理场景需要，且是"不作为"的更强形式），但 SessionUpdateTypes.cs 里原来那句「协议要求…」已改成把理由写成理由。

反向验证

14 条，全部转红，0 假绿。其中一条第一次配错了对：拿"resolver 不裁剪"去测 v1 passthrough 结果是绿的 —— 因为 v1 passthrough 靠的是属性表已收窄成 v1，不靠 resolver。改成对 v2 侧配对后三条全红。那条链的两个环节各有独立门禁。