@jsonstudio/rcc 0.90.429 → 0.90.814

package/docs/agent-routing/00-entry-routing.md

@@ -0,0 +1,28 @@
+# RouteCodex 路由入口（Project Entry）
+
+## 索引概要
+- L1-L7 `purpose`：入口用途与使用方式。
+- L9-L22 `route-table`：按任务类型分发。
+- L24-L30 `dispatch-order`：标准分发顺序。
+- L32-L37 `update-rule`：更新策略。
+
+## 目标
+把项目级 AGENTS 保持为“短入口”，复杂规则全部路由到细节文档或 skill。
+
+## 分类分发表
+1. 架构/语义真源边界 → `10-runtime-ssot-routing.md`
+2. 构建/测试/发布 → `20-build-test-release-routing.md`
+3. servertool 生命周期（sm/heartbeat/clock） → `30-servertool-lifecycle-routing.md`
+4. BD/记忆/任务轨迹 → `40-task-memory-routing.md`
+5. 用户纠偏（全局） → `~/.codex/docs/agent-routing/10-alignment-and-profile.md`
+
+## 分发顺序
+1. 先按任务目标判类。
+2. 读对应路由文档（本目录）。
+3. 再跳转目标文档/skill执行。
+4. 若跨类别，按“主路径优先，辅路径补充”并行使用。
+
+## 更新策略
+- 新规则先决定归属：入口 / 路由文档 / skill。
+- 入口文件不写长流程。
+- 索引概要必须随内容变更同步更新。

package/docs/agent-routing/10-runtime-ssot-routing.md

@@ -0,0 +1,26 @@
+# 运行时与真源边界路由
+
+## 索引概要
+- L1-L7 `scope`：覆盖范围。
+- L9-L18 `ssot`：核心真源与禁止事项。
+- L20-L27 `layer-responsibility`：三层职责。
+- L29-L35 `authoritative-docs`：权威文档索引。
+
+## 覆盖范围
+适用于：路由语义、tool 治理、pipeline 编排、provider 传输层边界类改动。
+
+## 真源与禁止事项
+1. 路由与工具语义真源：`sharedmodule/llmswitch-core/rust-core/crates/router-hotpath-napi/`。
+2. Host 仅做编排与桥接，不重写 llmswitch 语义。
+3. Provider 仅做 transport/auth/retry/compat，不解析业务语义。
+4. 禁止 fallback 兜底和“跨层补一版逻辑”。
+
+## 三层职责（Block / App / UI）
+- Block：基础能力唯一真源。
+- App：只编排，不重写 Block 细节。
+- UI：只展示状态，不承载业务规则。
+
+## 权威文档索引
+- `docs/ARCHITECTURE.md`
+- `docs/error-handling-v2.md`
+- `docs/routing-instructions.md`

package/docs/agent-routing/20-build-test-release-routing.md

@@ -0,0 +1,25 @@
+# 构建 / 测试 / 发布路由
+
+## 索引概要
+- L1-L7 `scope`：覆盖范围。
+- L9-L20 `build-order`：构建与安装顺序。
+- L22-L30 `verification`：最小验证栈。
+- L32-L36 `release-boundary`：发布边界。
+
+## 覆盖范围
+适用于：本地编译、全局安装、release 打包、回归验证。
+
+## 构建顺序
+1. `sharedmodule/llmswitch-core` 先构建。
+2. 根仓执行 `npm run build:dev`。
+3. 需要发布时执行 `npm run install:release`。
+
+## 最小验证栈
+- 目标改动对应的最小测试（同路径回归）。
+- 至少一条 failing-shape replay + 一条 control replay。
+- 安装后版本/可执行性复核（`routecodex --version` / `rcc --version`）。
+
+## 发布边界
+- CLI release 用 `@jsonstudio/rcc`。
+- `routecodex` 仅本地/调试路径。
+- 不提交构建产物（`dist/`、tarball）。

package/docs/agent-routing/30-servertool-lifecycle-routing.md

@@ -0,0 +1,32 @@
+# Servertool 生命周期路由（sm / heartbeat / clock）
+
+## 索引概要
+- L1-L7 `scope`：覆盖范围。
+- L9-L17 `sm-lifecycle`：sm 生命周期。
+- L19-L27 `heartbeat-delivery`：heartbeat/DELIVERY 执行顺序。
+- L29-L34 `clock-rule`：异步等待规则。
+- L36-L41 `authoritative-docs`：权威文档。
+
+## 覆盖范围
+适用于：自动续轮、tmux 注入、heartbeat 巡检、定时回查。
+
+## sm 生命周期
+1. 仅识别 `sm` marker（旧 `stopMessage` 语法已移除）。
+2. 清理优先、最后一条有效。
+3. 注入失败必须清理状态，防止循环。
+4. 解析失败 fail-closed，不污染有效状态。
+
+## heartbeat / DELIVERY 顺序
+1. 读取 `HEARTBEAT.md`。
+2. 先核对上次交付完整性。
+3. 有缺口就继续修复，不只汇报。
+4. 更新 `DELIVERY.md` 后执行 review 并落盘证据。
+
+## clock 规则
+- 未知时长异步任务必须设置回查提醒。
+- 汇报后不停止，按提醒自动续跑。
+
+## 权威文档
+- `docs/stop-message-auto.md`
+- `docs/design/servertool-stopmessage-lifecycle.md`
+- `docs/routing-instructions.md`

package/docs/agent-routing/40-task-memory-routing.md

@@ -0,0 +1,26 @@
+# 任务跟踪与记忆路由
+
+## 索引概要
+- L1-L7 `scope`：覆盖范围。
+- L9-L18 `bd-routing`：BD 工作流。
+- L20-L28 `memory-routing`：MEMORY/CACHE/memsearch 边界。
+- L30-L35 `skills-index`：相关 skills。
+
+## 覆盖范围
+适用于：任务状态管理、结论沉淀、历史检索与复盘。
+
+## BD 路由
+1. 任务生命周期真源使用 `bd-task-flow`。
+2. `.beads/issues.jsonl` 只保留结论和证据路径。
+3. 避免超长 notes，必要时先清理 oversized notes。
+
+## 记忆路由
+- `MEMORY.md`：项目长期可复用结论。
+- `memory/`：单任务过程性记忆。
+- `CACHE.md`：短期上下文（只读为主，不手写）。
+- 需要检索/写入记忆时优先走 `memsearch-flow`。
+
+## 相关 skills
+- `bd-task-flow`
+- `memsearch-flow`
+- `conversation-memory`

package/docs/design/heartbeat-session-execution-state.md

@@ -0,0 +1,227 @@
+# Heartbeat Session Execution State 设计
+
+## 目标
+
+为 heartbeat 注入建立一个 **tmux-scoped 执行状态真源**，在注入前判断目标 tmux 当前是否仍在执行任务；若仍在执行，则跳过本次 heartbeat，避免打扰。
+
+本设计重点解决两个问题：
+
+1. 不能再把 `client alive` 误判为 `session busy`。
+2. 不能只看 executor 生命周期；流式 SSE 仍在输出时，必须视为仍在执行。
+
+---
+
+## 已确认可用的现有信号
+
+### 1. tmux / session 绑定
+
+来源：
+
+- `src/server/runtime/http-server/executor-metadata.ts`
+- `src/server/runtime/http-server/session-scope-resolution.ts`
+
+当前可解析：
+
+- `tmuxSessionId`
+- `sessionId`
+- `conversationId`
+- `workdir`
+- `clientType`
+
+### 2. request 开始/结束
+
+来源：
+
+- `src/server/runtime/http-server/request-executor.ts`
+- `src/server/runtime/http-server/request-activity-tracker.ts`
+
+可用作“请求已发出”的信号，但 **不能单独作为流式执行态真源**，因为 `onRequestEnd` 发生在 executor `finally`，早于 SSE 真正结束。
+
+### 3. SSE 生命周期与 finish_reason
+
+来源：
+
+- `src/server/handlers/handler-response-utils.ts`
+- `src/server/utils/finish-reason.ts`
+
+当前已经能识别：
+
+- SSE stream start
+- SSE end
+- client close
+- finish / terminal event
+- `finish_reason`
+
+这些信号目前主要停留在响应层日志，没有形成 tmux-scoped 共享运行态。
+
+### 4. daemon alive / registry
+
+来源：
+
+- `src/server/runtime/http-server/session-client-registry.ts`
+
+当前能说明：
+
+- client daemon 是否仍在线
+- 最近 heartbeat / inject 时间
+
+但这 **不能说明 pane 当前是否 busy**。
+
+---
+
+## 核心判断原则
+
+### A. 流式请求优先
+
+若目标 tmux 当前存在 **未关闭的 SSE**，则直接判定为 **正在执行**，heartbeat 必须跳过。
+
+### B. 非流式请求看最近 request/response 时间线
+
+若最近一条事件是 request，且还未观察到对应 response：
+
+- 在 timeout 窗口内：视为仍在等待响应，应跳过 heartbeat
+- 超过 timeout：视为大概率已超时/断连，不应无限跳过 heartbeat
+
+### C. 最近一条事件是 response 时，看 finish_reason
+
+- `finish_reason=stop` 且之后没有新 request：视为空闲
+- `finish_reason!=stop`：进入短暂 grace 窗口，避免刚结束 tool_calls / length 时立刻误判为空闲
+
+---
+
+## 建议新增的真源模块
+
+建议新增：
+
+- `src/server/runtime/http-server/session-execution-state.ts`
+
+按 `tmuxSessionId` 维护最近执行态，至少记录：
+
+- `state`
+- `lastRequestId`
+- `lastRequestAtMs`
+- `lastRequestWasStream`
+- `openSseCount`
+- `lastSseOpenAtMs`
+- `lastSseCloseAtMs`
+- `lastResponseAtMs`
+- `lastFinishReason`
+- `lastTerminalAtMs`
+- `lastClientCloseBeforeTerminal`
+
+---
+
+## 状态机
+
+### 状态
+
+- `IDLE`
+- `WAITING_RESPONSE`
+- `STREAMING_OPEN`
+- `POST_RESPONSE_GRACE`
+- `STALED`
+- `UNKNOWN`
+
+### 含义
+
+#### `IDLE`
+
+当前可注入 heartbeat。
+
+#### `WAITING_RESPONSE`
+
+已收到 request，但尚未观察到 response 完成；在 timeout 窗口内应跳过 heartbeat。
+
+#### `STREAMING_OPEN`
+
+流式请求的 SSE 仍未关闭；这是“仍在执行”的最高优先级判定。
+
+#### `POST_RESPONSE_GRACE`
+
+刚结束一个非 `stop` 的响应，例如 `tool_calls` / `length`，短时间内仍可能紧接下一轮请求。
+
+#### `STALED`
+
+最近一条是 request，但超过 timeout 仍无 response，视为超时或断连，不应再无限跳过 heartbeat。
+
+#### `UNKNOWN`
+
+当前没有足够的新执行态数据；只允许降级到 tmux pane heuristic，不允许把 daemon alive 直接当作 busy。
+
+---
+
+## 事件与转移
+
+建议统一记录这些事件：
+
+- `REQUEST_STARTED`
+- `SSE_OPENED`
+- `SSE_CLOSED`
+- `RESPONSE_COMPLETED`
+- `RESPONSE_CLIENT_CLOSED`
+- `RESPONSE_ERROR`
+- `TIMEOUT_EXPIRED`
+
+主要转移：
+
+- `IDLE -> WAITING_RESPONSE`：收到 request
+- `WAITING_RESPONSE -> STREAMING_OPEN`：流式响应开始
+- `WAITING_RESPONSE -> IDLE`：收到非流式终态且 `finish_reason=stop`
+- `WAITING_RESPONSE -> POST_RESPONSE_GRACE`：收到非流式终态且 `finish_reason!=stop`
+- `WAITING_RESPONSE -> STALED`：超时无响应
+- `STREAMING_OPEN -> IDLE`：SSE 正常结束且 `finish_reason=stop`
+- `STREAMING_OPEN -> POST_RESPONSE_GRACE`：SSE 正常结束且 `finish_reason!=stop`
+- `STREAMING_OPEN -> STALED`：client close / 异常结束且没有正常终态
+- `POST_RESPONSE_GRACE -> WAITING_RESPONSE`：grace 期间来了新 request
+- `POST_RESPONSE_GRACE -> IDLE`：grace 到期且没有新 request
+- `STALED -> WAITING_RESPONSE`：之后出现新的 request
+
+---
+
+## Heartbeat skip 决策顺序
+
+推荐优先级：
+
+1. **存在未关闭 SSE** → `skip`
+2. **最新是 request，且仍在 timeout 窗口内** → `skip`
+3. **最新是 response，`finish_reason=stop`，且之后无新 request** → `allow`
+4. **最新是 request，但已超时无响应** → `allow`
+5. **状态不足** → fallback 到 tmux pane heuristic
+
+明确禁止：
+
+- 仅因为 `registry.hasAliveTmuxSession()` 为真，就直接判定 busy
+
+---
+
+## 与现有 heartbeat 的关系
+
+当前 heartbeat skip 逻辑里已有：
+
+- tmux 存活检查
+- request inflight 检查
+- client daemon alive 检查
+- tmux pane heuristic fallback
+
+新方案应调整为：
+
+1. execution-state tracker 为主真源
+2. tmux pane heuristic 仅作 fallback
+3. daemon alive 只表示“在线”，不表示“忙”
+
+---
+
+## 落地顺序建议
+
+1. 新增 `session-execution-state.ts`
+2. 在 request start 路径写入 `REQUEST_STARTED`
+3. 在 JSON response 完成路径写入 `RESPONSE_COMPLETED`
+4. 在 SSE 路径写入 `SSE_OPENED / SSE_CLOSED / RESPONSE_COMPLETED / RESPONSE_CLIENT_CLOSED`
+5. heartbeat 决策改为优先读取 execution-state tracker
+6. 在缺少状态时再回退到 tmux pane heuristic
+
+---
+
+## 备注
+
+该设计上线后，只能对 **上线后的新请求** 逐步建立准确执行态。对上线前已在跑的老 session，短期内仍需依赖 tmux pane heuristic 兜底。

package/docs/design/servertool-stopmessage-lifecycle.md

@@ -29,7 +29,7 @@ Design goals:
 1. Client starts via `routecodex codex` / `routecodex claude` inside tmux.
 2. Client request carries tmux metadata (`tmuxSessionId` family fields / headers).
 3. Server resolves tmux session and marks `clientInjectReady=true`.
-4. User sends `<**stopMessage,...**>` instruction.
+4. User sends `<**sm:...**>` instruction.
 5. Chat-process parser saves instruction state under `tmux:<sessionId>`.
 6. Model response reaches response orchestration.
 7. StopMessage matcher runs in chat-process servertool stage.

package/docs/reports/apply-patch-errorsamples-classification.md

@@ -0,0 +1,144 @@
+# apply_patch 错误样本分类表（2026-03-18）
+
+## 范围
+
+本表基于两个样本集合：
+
+1. **近期主样本集**
+   - `~/.rcc/errorsamples/client-tool-error/chat_process.req.stage2.semantic_map.apply_patch-*.json`
+   - 按最近 **200** 条与最近 **500** 条做统计
+2. **历史回归样本集**
+   - `~/.rcc/errorsamples/apply-patch-regression/*.json`
+
+## 结论摘要
+
+- 近期高频错误几乎全部是 `apply_patch_verification_failed`，而且高度集中在 **4 类**。
+- 当前主因不是执行器随机失效，而是 **模型 patch 心智错误**：
+  1. 把 GNU diff 头混进 `*** Begin Patch` 块；
+  2. 把 merge/conflict 标记直接塞进 patch；
+  3. 继续硬写 GNU 行号上下文（`@@ -51,7 +51,9 @@`）；
+  4. 少量真实的 `expected lines not found`。
+- 历史回归样本还保留两类基础错误：
+  - `unsupported_patch_format`
+  - `empty_add_file_block`
+
+---
+
+## 近期样本统计
+
+### 最近 200 条 apply_patch 专属样本
+
+来源：
+
+- `~/.rcc/errorsamples/client-tool-error/chat_process.req.stage2.semantic_map.apply_patch-*.json`
+
+统计结果：
+
+| 分类 | 数量 |
+|---|---:|
+| conflict_markers_or_merge_chunks | 72 |
+| gnu_line_number_context_not_found | 55 |
+| mixed_gnu_diff_inside_begin_patch | 55 |
+| expected_lines_not_found | 18 |
+
+### 最近 500 条 JSON 错误样本中的 apply_patch 相关分类
+
+来源：
+
+- `~/.rcc/errorsamples/**/*.json`
+
+统计结果：
+
+| 分类 | 数量 |
+|---|---:|
+| conflict_markers_or_merge_chunks | 75 |
+| gnu_line_number_context_not_found | 57 |
+| mixed_gnu_diff_inside_begin_patch | 49 |
+| expected_lines_not_found | 19 |
+
+备注：
+
+- 最近 500 条 JSON 样本里，**未看到**新的 `exec_command_nested_apply_patch_warning` 成为主流；说明这轮主要问题已从“工具选错”转向“patch 形状错误”。
+
+---
+
+## 历史回归样本统计
+
+来源：
+
+- `~/.rcc/errorsamples/apply-patch-regression/*.json`
+
+统计结果：
+
+| 分类 | 数量 |
+|---|---:|
+| unsupported_patch_format | 2 |
+| empty_add_file_block | 1 |
+
+---
+
+## 分类表
+
+| 分类 | 典型 matchedText / 症状 | 当前数量 | 更可能的根因 | 建议修复层 | 优先级 | 建议动作 |
+|---|---|---:|---|---|---|---|
+| `conflict_markers_or_merge_chunks` | `Expected update hunk to start with a @@ context marker, got: '======='` | 72 / 75 | 模型把 merge/conflict chunk 或非 patch 文本直接塞进 `Update File` | **prompt/guidance** + request-path guard | P0 | 强化“禁止 `=======/<<<<<<</>>>>>>>`”与“`Update File` 必须有 `@@` hunk”；必要时在 request-path 直接拦截冲突标记并回写 guard reason |
+| `gnu_line_number_context_not_found` | `Failed to find context '-114,6 +114,7 @@'` | 55 / 57 | 模型误以为必须精确写 GNU 行号上下文；或基于旧内容生成 patch | **prompt/guidance** + post-failure retry policy | P0 | 明确“可以用 `@@` + 上下文，不必强写 GNU 行号”；失败后要求重读文件并缩小唯一上下文 |
+| `mixed_gnu_diff_inside_begin_patch` | `invalid hunk at line 2, '--- a/src/server/index.ts' is not a valid hunk header` | 55 / 49 | 模型把 internal `*** Begin Patch` 与 GNU diff 头混用 | **prompt/guidance** + validator normalization（可选） | P0 | 明确“二选一，严禁混用”；可评估是否把 `*** Begin Patch` 包裹的 GNU diff 头再做一层自动剥离修复 |
+| `expected_lines_not_found` | `Failed to find expected lines in ...` | 18 / 19 | 真正的上下文不匹配：文件已变化、上下文过大、不够唯一 | **runtime retry guidance** | P1 | 出错后强制重读最新文件，再用更小且唯一的上下文；必要时把单次 patch 拆小 |
+| `unsupported_patch_format` | `Update File` 后直接跟 frontmatter / 正文，没有 hunk | 2（历史） | 模型不理解 internal grammar；把 `Update File` 当“全文替换” | **tool guidance** + validator reason hint | P1 | 强化最小合法模板，显式提示“没有 `@@` hunk 的 `Update File` 会被拒绝” |
+| `empty_add_file_block` | `*** Add File: ...` 后没有任何 `+` 行 | 1（历史） | 模型误以为空文件 Add File 合法 | **tool guidance** + validator reason hint | P2 | 明确 Add File 必须至少包含一行 `+内容`；若真要空文件，应改为 shell `touch` 之类的受控策略或专门工具，而不是空 patch |
+| `exec_command_nested_apply_patch_warning` | `Warning: apply_patch was requested via exec_command` | 非近期主流，历史存在 | 工具选错：模型把 `apply_patch` 当 shell 命令 | **rewrite/guard** | P2 | 维持现有 rewrite/guard；后续做样本分类时单独追踪是否再次升高 |
+
+---
+
+## 已完成的前置收敛
+
+本轮已先修正工具引导文案，避免继续制造同类错误：
+
+- `src/config/system-prompts/codex-cli.txt`
+  - 去掉“apply_patch 不好用就换 Node/Python 脚本”的弱引导
+- `sharedmodule/llmswitch-core/src/guidance/index.ts`
+  - 明确 **Begin Patch / GNU diff 二选一，禁止混用**
+  - 增加最小合法模板
+  - 禁止 conflict markers / 裸 frontmatter 作为 `Update File` body
+- `sharedmodule/llmswitch-core/src/guidance/CCR_TOOL_GUIDE.md`
+  - 同步补齐以上规则
+- `sharedmodule/llmswitch-core/src/conversion/hub/process/chat-process-clock-tool-schemas.ts`
+  - 工具描述补齐 FREEFORM 与“不混用”要求
+
+---
+
+## 建议修复顺序
+
+### 第一步：先修 prompt / guidance
+
+优先原因：
+
+- 当前占比最高的三类错误都属于**模型生成 patch 形状错误**
+- 不先收紧提示词，后面即使增强 validator，也只是在被动收垃圾输入
+
+### 第二步：补 request-path / validator 的 reason 编码与 guard
+
+优先看两点：
+
+1. 对 conflict markers 的 request-path 早拦截
+2. 对“mixed GNU diff inside Begin Patch”评估是否做自动修复，还是继续 fail-fast
+
+### 第三步：为 `expected_lines_not_found` 设计统一 retry 策略
+
+这是最像“正常 patch 失败”的一类，应通过：
+
+- 重读文件
+- 缩小上下文
+- 拆小 patch
+
+来恢复，而不是继续堆更宽松的语法容错。
+
+---
+
+## 下一步实施建议
+
+1. 在 `apply_patch` 工具引导里增加**可复制模板**的实际注入验证
+2. 给 `tool-governor` / request-path 增加 **conflict-marker 明确分类 reason**
+3. 决定是否为“`*** Begin Patch` + GNU diff 头混用”加一层**自动正规化**
+4. 把本表对应到测试矩阵，新增每类错误至少 1 条回归用例

package/docs/routing-instructions.md

@@ -161,14 +161,13 @@ RouteCodex 支持通过用户消息中的特殊指令 `<**...**>` 来动态控
 
 > 仅当 RouteCodex 内置的 `stop_message_auto` servertool 启用时生效。
 
-**语法：**
+**语法（仅 `sm`）：**
 
-- 启用 / 更新自动续写：
-  - `<**stopMessage:"继续"**>` → 默认最多自动续写 10 次；
-  - `<**stopMessage:"继续",3**>` → 最多自动续写 3 次；
-  - `<**stopMessage:<file://stopMessage/message1.md>**>` → 读取 `~/.rcc/stopMessage/message1.md` 作为 stopMessage 文案（设置时读取并缓存到内存）；
-- 清理 stopMessage 状态：
-  - `<**stopMessage:clear**>`
+- `<**sm:"补齐交付证据",30**>` → 目标 + 轮次；
+- `<**sm:"补齐交付证据"**>` → 只有目标（持续执行直到目标达成）；
+- `<**sm:on/30**>` / `<**sm:30**>` → 无显式目标时使用默认目标“继续执行”；
+- `<**sm:<file://stopMessage/message1.md>**>` → 读取 `~/.rcc/stopMessage/message1.md` 作为 stopMessage 文案；
+- `<**sm:off**>` → 清理 stopMessage 状态。
 
 **行为：**
 
@@ -177,6 +176,10 @@ RouteCodex 支持通过用户消息中的特殊指令 `<**...**>` 来动态控
   - `stopMessageText`：自动补发的用户消息内容；
   - `stopMessageMaxRepeats`：允许自动续写的最大次数（>=1）；
   - `stopMessageUsed`：已执行次数（从 0 开始计数）；
+- marker 生命周期规则：
+  - 只以最新一条 user 消息为准；
+  - 同条消息中存在多个 `sm` 时，`off` 优先；否则最后一条生效；
+  - 注入成功后 `stopMessageUsed += 1`，达到上限后自动停用；
 - stopMessage 阶段策略的 BD 状态判定：默认优先尝试真实命令查询（`bd --no-db list/ready --json`），命令失败时回退到历史消息启发式；
   - 可用 `ROUTECODEX_STOPMESSAGE_BD_MODE=auto|runtime|heuristic` 控制（默认 `auto`）；
   - 可用 `ROUTECODEX_STOPMESSAGE_BD_TIMEOUT_MS`、`ROUTECODEX_STOPMESSAGE_BD_CACHE_TTL_MS`、`ROUTECODEX_STOPMESSAGE_BD_WORKDIR` 调整运行参数；
@@ -186,15 +189,19 @@ RouteCodex 支持通过用户消息中的特殊指令 `<**...**>` 来动态控
   - `stopMessageUsed < stopMessageMaxRepeats`；
   - 客户端仍处于连接状态（HTTP 层会在断连时设置 `clientDisconnected=true`，servertool 检测到后停止自动续写）；
 - 自动续写时：
-  - 以保存的原始 Chat 请求（`capturedChatRequest`）为基础，复制 `model/messages/tools/parameters`；
-  - 在消息末尾追加一条 `{ role: "user", content: stopMessageText }`；
+  - 生成下一步 followup 文本（默认 review 模式，`ai:on`）；
+  - 通过 `clientInjectOnly` 路径向绑定 tmux 客户端注入文本（不走嵌套 reenter 请求）；
   - 自增 `stopMessageUsed` 并写回 sticky 存储；
-  - 通过内部 `reenterPipeline` 再发起一次 /v1/chat/completions（对客户端透明，对 Responses / Chat / Gemini 协议统一生效）。
+  - 注入失败时清理 stopMessage 激活状态并保留主请求完成。
+- 错误管理：
+  - 非法 marker（如 `sm:on/not-a-number`）忽略且不改写状态；
+  - 无法解析的 `file://` marker 不生效，但主请求继续；
+  - 注入失败会清理 stopMessage 激活状态，避免坏状态自循环。
 
 **示例：**
 
 ```text
-<**stopMessage:"继续",3**>
+<**sm:"继续",3**>
 帮我把这个项目的架构分 3 步讲完，每一步结束后我会说“继续”。
 ```