v8.7.17

English

OMP reply receipts are not business completion

• Returned replies no longer have to wait behind an entire long-running OMP business turn. The native bridge exposes bounded, owner-bound reply_deliver and reply_status requests; reply_capabilities advertises reply_ingress_version: 1.
• A custom ccb-reply is delivered as an aside at a safe step boundary, without clearing the composer, superseding the active ask anchor, or starting a concurrent turn.
• Only a persisted native custom_message with the exact ccb-reply delivery identity and matching body hash counts as a receipt. A request being accepted, queued or still pending is not proof of receipt.
• That receipt releases the delivery mailbox. It means the reply has reached native session history, not that the recipient has finished reading, reasoning about, or acting on it. Subsequent business processing keeps its own lifecycle.
• Ambiguous sends are resolved through status queries rather than blindly replayed. Pending, missing and unknown outcomes are not promoted to successful receipts.

Upgrade and compatibility

• Existing OMP processes must restart normally when idle to load the updated extension. Updating files alone does not change an already running extension; do not interrupt or restart a busy session, including busy nozeli, to apply this update.
• Update server and Android app together. Current metadata and APK references are v8.7.17; the Android build number is 8070017. Windows retains beta status.
• Preserve v8.7.16's sender-identity recovery and historical release entries. The WeChat invitation image and README QR cache key a9f2d800 are unchanged.

Release qualification

• Publication requires a passing receipt smoke against the actual installed OMP. Source-level expectations or an accepted bridge request alone do not qualify as persisted native receipt evidence.
• Local preview installed with the release installer; installed ccb --print-version returned v8.7.17. 363 targeted regressions and npm pack verification passed.
• Actual installed OMP 18.12.6 PTY plus a loopback streaming provider: two replies admitted while a native tool was running, both exact on-disk receipts consumed at 1.32s before the original turn finished at 1.36s. Duplicate admission produced no extra native entries; original anchor and unsubmitted draft remained unchanged. No external model requests or live-project business replay.
• Admission intent is fsynced before native send. Receipt requires a matching newline-terminated native JSONL record and fsync; in-memory queue acceptance alone never completes delivery. Unresolved intents fail closed across restart.

中文

OMP 回复收据不等于业务处理完成

• 返回回复不再必须等待 OMP 的整个长业务回合结束。原生桥提供有界、绑定归属的 reply_deliver、reply_status 请求，通过 reply_capabilities 的 reply_ingress_version: 1 声明支持。
• 自定义 ccb-reply 在安全步骤边界作为 aside 投递，不清空输入框、不取代活跃 ask 锚点，也不启动并发回合。
• 只有具有精确 ccb-reply 投递身份、正文哈希匹配且已持久化的原生 custom_message 才算收据。接口接受、排队或 pending 均不代表已经收到。
• 收据用于释放投递邮箱，表示回复已进入原生会话历史，不代表接收方已完成阅读、推理或后续业务处理；业务处理保留自己的生命周期。
• 发送结果不明时查询状态，不盲目重放。pending、missing、unknown 状态不能被提升为成功收据。

升级与兼容性

• 已有 OMP 进程必须在空闲后正常重启，才能加载新扩展。仅更新磁盘文件不会改变已运行的扩展；不要为升级打断或重启忙碌会话，包括忙碌的 nozeli。
• 服务器与 Android 应用一起更新。当前版本元数据与 APK 引用为 v8.7.17，Android 构建号为 8070017；Windows 继续保持 beta 状态。
• 保留 v8.7.16 的发送者身份恢复与全部历史版本记录。微信邀请图片及 README 二维码缓存标识 a9f2d800 保持不变。

发布资格

• 发布前必须通过真实已安装 OMP 的收据冒烟验证。仅源码预期或桥请求被接受，不能替代原生持久化收据证据。
• 已使用发布安装器安装本地候选，已安装 ccb --print-version 输出 v8.7.17；363 项针对性回归与 npm 打包检查通过。
• 真实已安装 OMP 18.12.6 PTY 配合本地流式接口：原生工具运行中接收两条回复，1.32 秒时两条磁盘收据均被消费，原回合 1.36 秒才结束。重复准入未新增记录，原锚点与未发送草稿不变；未调用外部模型、未重放真实项目业务。
• 原生发送前 fsync 投递意图；收据必须匹配完整原生 JSONL 记录并完成 fsync，不能凭内存排队判定成功；重启后未解决意图保持未知且不重放。