升级 Exomind release line 到上游 0.119.0 稳定基线

[ARCJ137442]

父 issue

• Sync fork to latest OpenAI Codex upstream baseline #32

Goal

将 Exomind fork 的上游基线同步目标从当前已过时的 rust-v0.118.0 推进到最新稳定版 rust-v0.119.0，并在不丢失 Exomind 定制行为的前提下完成下一轮正式基线升级。

Background

#32 已在 2026-04-02 刷新为统一的上游同步追踪 issue，并明确当时的下一个稳定目标是 rust-v0.118.0。

但当前上游稳定版已经推进到：

• rust-v0.119.0

因此需要从 #32 下拆出一个更具体的子 issue，专门追踪本轮 0.119.0 基线升级，而不是继续沿用已经过时的 0.118.0 目标。

Scope

• 对比当前 Exomind fork 基线与上游 rust-v0.119.0
• 盘点必须保留的 fork-only 改动
• 梳理 0.115.0 -> 0.119.0 的上游变更与潜在冲突面
• 将 fork 合并 / rebase 到 rust-v0.119.0
• 保留或明确重做以下 Exomind 特性：
  • queue / steer / repeating-message 工作流
  • tmux / TUI 重绘行为
  • Termux / Android 兼容路径
  • fork 自身的治理 / tracking 增补
• 同步更新版本线与文档

Out of Scope

• 追踪 0.119.0-alpha.* 预发布线
• 泛化的长期版本策略讨论
• 与 0.119.0 基线同步无关的独立功能开发

Definition of Done

• fork 基线已明确同步到 rust-v0.119.0
• workspace version 已更新到对应的 Exomind 版本线
• README.md 的 fork status / baseline 信息已更新
• 关键 Exomind 定制行为仍可工作，或已有明确替代结论
• 受影响 crate / 工作流完成针对性验证
• 最终结果记录清楚所采用的上游 tag / commit

Notes

• 本 issue 只追踪稳定版 0.119.0
• #32 继续作为总 tracking issue 保留
• 旧的 #44 仍应视为已过时的历史子任务

[ARCJ137442]

Issue #47: Exomind rust-v0.119.0 Upgrade Execution Plan

Summary

Issue #47 is not a narrow replay bugfix. It is the work to rebuild the Exomind
release line on top of upstream rust-v0.119.0, while restoring the minimum
set of Exomind-specific behavior required for product continuity and release.

The implementation strategy is:

• start from a clean branch based on upstream/rust-v0.119.0
• restore Exomind behavior in layers instead of hard-merging the current fork
• preserve user-facing semantics even when the old implementation must be
  rewritten
• treat durable replay v1 as a first-class completion requirement for 升级 Exomind release line 到上游 0.119.0 稳定基线 #47

The recently fixed replay/queue hang after replay remains important as a
regression case, but it is tracked outside #47 and should be used as a behavior
reference rather than as the main definition of this upgrade issue.

Completion Criteria

Issue #47 is complete only when all of the following are true:

• the repository baseline is rebuilt on upstream/rust-v0.119.0
• the workspace version and external metadata are updated to
  0.119.0-exomind
• the Exomind release line keeps the required queue, steer, and
  repeating-message semantics
• required tmux, Termux, and Android compatibility behavior is restored
• durable replay v1 works on the new baseline with core-owned semantics
• full project-level validation passes
• the Windows release artifact can be produced for distribution

Required Public-Facing Changes

The first completed upgrade branch must include these outward-facing changes:

• codex-rs/Cargo.toml workspace version updated to 0.119.0-exomind
• README.md fork status updated to show the rust-v0.119.0 baseline
• release naming and release notes updated to the new Exomind line
• CI and release automation adjusted where the 0.119 baseline requires it

These changes should land with the first baseline-complete branch rather than
being delayed until the very end, to avoid a long-lived state where the code
and the documented release line disagree.

Implementation Strategy

Phase 1: Create the clean sync branch

• create a dedicated sync branch from upstream/rust-v0.119.0
• verify that the clean upstream branch builds and that the relevant tests can
  run in this repository environment
• record the fork delta as layered patch buckets rather than applying all fork
  changes at once

Phase 2: Restore release metadata and governance

• update workspace version, README fork status, and release-line identifiers
• restore only the CI and release workflow adjustments that are necessary for
  the Exomind release line and the new upstream baseline
• confirm that the repository can now be described truthfully as a
  0.119.0-exomind line, even before deeper behavior restoration finishes

Phase 3: Restore Exomind workflow and compatibility deltas

• restore queue, steer, and repeating-message behavior first
• restore the tmux, Termux, and Android compatibility layer next
• prefer upstream 0.119 abstractions when they can carry the required Exomind
  semantics with a smaller patch
• do not preserve old fork implementation details when the same semantics can
  be expressed more cleanly on the 0.119 baseline

Phase 4: Restore durable replay v1 on the 0.119 baseline

Durable replay remains in scope for #47 and must preserve the v1 behavior
contract:

• replay stays within the same logical turn
• core owns replay state, backoff, resume, and gate semantics
• TUI is limited to presentation and turn-lifecycle integration
• Regular and thread-spawn SubAgent replay are both required
• manual pause and gate pause behavior must survive resume
• approval, elicitation, and request_user_input gates must be restorable

The recovery path should be rebuilt around upstream 0.119 lifecycle mechanics
instead of forcing the old fork code shape onto the new baseline.

Phase 5: Release preparation

• build and smoke-check the Windows distributable codex.exe
• update release packaging inputs and release notes as required
• treat Termux as a secondary release target that must be built and verified in
  a real Termux environment after the primary Windows artifact is ready

Durable Replay Acceptance Requirements

Durable replay is accepted on the new baseline only if these behaviors hold:

• automatic replay does not create a new logical turn
• replay state is persisted durably and can be resumed after restart
• scheduled, running, paused_manual, paused_gate, and completed
  states remain coherent
• the same durable prompt snapshot is reused for automatic replay
• queued user input remains queued while replay is pending unless the replay is
  explicitly interrupted
• stale or mismatched turn completion events do not advance the queue
• the real terminal completion event can still authoritatively finish the turn
  after replay

Test Plan

The upgrade branch should not be considered merge-ready until it passes both
automated and scenario-level verification.

Automated validation

• run project-level tests for all crates touched by the upgrade work
• add or update replay regression coverage for:
  • queue advance after replay completion
  • stale or drifted TurnComplete handling
  • replay resume after restart
  • manual pause versus scheduled auto-resume
  • gate restore for approval and request_user_input
  • SubAgent replay coverage
• update any user-visible snapshots that intentionally change

Manual validation

• verify one real replay cycle for a regular turn
• verify replay with queued follow-up input
• verify manual interrupt and resume
• verify at least one gate pause and restore scenario
• verify the Windows release artifact starts and can complete a basic session

Defaults And Assumptions

• preserve Exomind user-visible semantics when a tradeoff is required
• allow implementation rewrites when they reduce coupling to old fork history
• keep the replay/queue hang fix as a regression reference, not as 升级 Exomind release line 到上游 0.119.0 稳定基线 #47 scope
• treat Windows as the primary release target and Termux as the secondary one
• keep governance and release metadata updates in 升级 Exomind release line 到上游 0.119.0 稳定基线 #47 rather than postponing
  them to a later cleanup task

[ARCJ137442]

同步当前仓库内的 #47 规划，后续以以下两份文档为准：

• docs/issue-47-upstream-0.119-sync-analysis.md
• docs/issue-47-upstream-0.119-implementation-plan.md

当前确认的执行基线如下：

1. #47 的主体是把 Exomind release line 重建到 upstream/rust-v0.119.0，不是单点 replay bugfix。
2. 实施方式采用“从 upstream/rust-v0.119.0 新起同步分支，再分层恢复 Exomind 必要差异”，不在当前 main 上直接硬合旧实现历史。
3. 首轮完成条件必须同时包含：
   • workspace version / README / fork status / release 配套更新到 0.119.0-exomind
   • queue / steer / repeating-message 语义恢复
   • tmux / Termux / Android 必要兼容恢复
   • durable replay v1 在新基线上成立
4. durable replay 在 #47 中不是后续可选项，而是完成条件之一；并且默认坚持“core 持有恢复语义，UI 只负责呈现”的边界。
5. durable replay 的首轮验收范围包括：
   • same logical turn
   • durable state + resume
   • Regular + thread-spawn SubAgent
   • scheduled / running / paused_manual / paused_gate / completed
   • exec approval / patch approval / elicitation / request_user_input gate 恢复
6. 最近已修好的 replay 后 queue 卡住问题，作为关键回归样例保留，但不单独定义 #47 的主体范围。
7. #47 完成后默认进入发行准备：Windows 可分发 exe 为首要目标，Termux 为次要目标。

当前建议的直接执行顺序：

• A. 从 upstream/rust-v0.119.0 建立 clean sync branch，并先验证纯上游基线健康度
• B. 回补版本、README、fork status、CI/release 治理配套
• C. 回补 Exomind 核心工作流与环境兼容
• D. 在 0.119 新基线上恢复 durable replay v1
• E. 做完整项目级验证并进入 Windows 发行准备

后续实现与验收以仓库内文档版计划为准，如果阶段边界或完成条件有变化，再继续在本 issue 追记。

[ARCJ137442]

补充一个需要严格遵守的真实使用体验约束，作为本阶段迁移的修正目标：

• 只有在输入框里存在文本输入时，Shift+Tab 才应该生成 repeat_mode = true 的 UserMessage
• Ctrl+Tab 不应落成 repeating message 的语义
• 仅有附件、没有文本时，也不应因为 Shift+Tab / Ctrl+Tab 进入 repeat queue 语义

基于当前 0.119.0-exomind 迁移实现的代码核对，现状与该约束不一致：

• Ctrl+Tab 和 Shift+Tab / BackTab 当前都会先生成 BufferedQueued
• chatwidget 当前会把所有 BufferedQueued 无条件转换成 repeat_mode = true
• BufferedQueued 当前也不是“必须有文本”才能触发，而是文本或附件任一存在即可触发

因此，后续实现需要把“buffered queue”与“repeat queue”语义拆开，至少保证上述输入体验约束成立，再继续推进 #47 的后续迁移。