docs(cockpit): 记录终态契约定案与回执保留期

docs/cockpit-video-lifecycle-acceptance.md

@@ -72,6 +72,21 @@ Standards 与 Spec 在不同子代理中独立运行，未用 Lead 的自查替
 
 这四个新增坏响应参数用例后，再次完整 `mvn -o -fae ... test`（无 failure.ignore）通过：**270 + 844 + 22 + 96 = 1232 项**，0 失败/错误/跳过。前面的 1228 项 clean test 是修复前一阶段的真实记录，不覆盖历史。最终日志见[完整确认回归](<E:/pipe-ner-server/.scratch/video03-lifecycle/round-final-confirmation.log>)。
 
+## 第六轮：契约定案与回执保留期（2026-11-13，仍未关闭）
+
+`a5a0a707`：
+
+- **契约定案**：终止状态只能在同时具备 `allocationClosed` 正面证据时被声称。真实适配器（GB/Manual）确实在该字段里表达“已验证拆除”；旧用例的替身只返回裸 `STOPPED`，已修正为与真实契约一致，而不是放宽生产判定。
+- **回执保留期**：`VideoStopReceipts` 在同一次已提交事务内，对**终态**快照使用 `SET ... EX`（7 天）；未确认记录仍不设 TTL，重启后必须可读。新增断言验证“终态才设置、未结不设置”。
+
+完整后端回归：**291+851+22+162 = 1326 项**，0 失败/错误/跳过，BUILD SUCCESS（`round10-contract-ttl-reactor.log`）。
+
+**仍未解决**：
+
+1. `SIP_RECOVERY_V1:*`（`SipInviteSessionManager`）仍无 TTL/清理——本次只处理了 `VideoStopReceipts`；需要先确定 pending 意图的安全过期策略（删除过早会丢失迟到应答的恢复依据）。
+2. `SIPCommander:601` legacy（非 managed/adopted）路径仍调用非原子 `removeByCallId`。这是旧兼容路径的既有行为，改成 CAS 会改变旧路径语义，超出本票必要范围，未动。
+3. 规模性问题（内联全限定类名、`managed_` 判定散落、`stopManaged` 过长）仅记录，未重构。
+
 ## 第五轮：双轴审查确定缺陷修复（2026-11-13，仍未关闭）
 
 独立双轴审查指出的三处确定缺陷，已修复并各自补回归（均先在测试中失败，再修复）：
@@ -86,8 +101,8 @@ Standards 与 Spec 在不同子代理中独立运行，未用 Lead 的自查替
 
 **仍未解决（不掩盖）**：
 
-1. `VideoLifecycleService` 的 `STOPPED` 与 `allocationClosed` 契约：审查两次指出，我两次尝试收紧都破坏既有用例、已回退。需要先定契约（适配器返回 `STOPPED` 本身是否即终止证据），再动代码。
-2. 审查指出的**无界 Redis 键增长**：`SIP_RECOVERY_V1:*` 与 `video:stop-receipts:v1:*` 全仓无 TTL、无清理任务。这是真实长期运行风险，我尚未处理。
+1. ~~`VideoLifecycleService` 的 `STOPPED` 与 `allocationClosed` 契约~~ → 已在 `a5a0a707` 定案（见第六轮）。
+2. ~~审查指出的无界 Redis 键增长~~ → `VideoStopReceipts` 已在 `a5a0a707` 为终态设置 7 天保留期；`SIP_RECOVERY_V1:*` 仍未处理（见第六轮）。
 3. `SipInviteSessionManager.removeByCallId` 仍是先读后删的非原子旧实现，`SIPCommander` 仍在调用它，与双索引原快照 CAS 目标矛盾。
 4. 规模性问题（内联全限定类名 59 处、`managed_` 前缀判定散落 28 处、`stopManaged` 单方法过长）只作判断题记录，未重构。