秀秀 3.223 - 大型串行Loop派发深度保护修复

记录日期：中国时间 2026-08-22；不可覆盖快照 ID：5825eeb4130d817d78507f4eb48911c290be8f63de0abde375e7416cc69d28a0

记录完整性：九项详细记录完整

## 秀秀 3.223 - 大型串行Loop派发深度保护修复

- 建立时间：2026-08-22 CST。
- 父版本：秀秀 3.222；固定严重故障回滚基准仍为秀秀 3.2。
- 修改目的：修复正式串行协同Loop在16位及以上业务BOT时，前15位完成后群里虽然显示“继续第16位”，但后台没有创建第16位执行任务、只能等真人发送“继续执行”才恢复的问题。
- 原因判断：普通BOT行首`@`派发共用固定`mention_dispatch_depth >= 30`防死循环门槛；正式串行Loop每位业务BOT需经历“替身->业务BOT、业务BOT->替身”两次合法派发，15位正好消耗30层。立志教育真实审计记录为`bot.reply.mention.dispatch.max_depth`，第15位回报任务元数据深度为30，因此第16位可见派发消息写入后被深度保护拒绝入队。这不是206、EasyTier或跨服授权拒绝。
- 修改逻辑：普通群聊、普通BOT互相`@`继续以30层作为每个自动派发分段的安全基准；到达基准后停止自动续派，只有真人明确发送“继续刚才/恢复原任务/继续往下执行”等续跑指令，才从当前深度开启下一段最多30层额度。BOT回复中的“继续”不能自行续额。正式`substitute_collaboration_loop`具有参与者清单时，单段深度上限按`2 × 参与BOT数 × 轮数 + 4`动态计算，并仍设置最低30、轮数最高按10计算。原有行首完整BOT名匹配、串行只派第一位、阶段过期检查、重复任务检查、幂等键和横向业务BOT互调阻断全部保留。
- 采用方法：以真实任务群`g_task_0601e5c063b9`、Loop`loop_89b86507039f554c`的任务元数据与审计日志反推派发次数，仅对固定深度门槛做最小修改；没有改变Loop参与人、当前轮次、当前序号、消息正文或任务结果。按真人要求暂不新增大型真实模型专项测试，避免费用和对现有群聊的干扰。
- 数据/调用链路：替身生成下一位正式Loop派发 -> 读取当前Loop参与数与轮数 -> 计算本Loop独立安全上限 -> 继续执行原行首`@BOT`选择、权限、阶段和幂等校验 -> 创建唯一`queued`任务 -> 业务BOT执行并回报替身。普通任务达到本段30层后停止；真人明确要求继续 -> 系统确认消息来源为`user`且语义明确指向原任务 -> 记录新分段起点 -> 从未完成上下文继续下一段；BOT消息不能触发该续额。
- 兼容保护：不修改BOT人设、账号、群组、聊天、Session、上下文、四大法、Q/OpenClaw配置、206中转、EasyTier、授权、数据库结构、Web/APP界面或安装包。真人续跑只增加新的30层安全分段，不清零全链路累计深度，审计仍可追溯；存在多个未完成任务时继续沿用现有澄清规则。没有实现“后台自动补`@替身BOT`”：真实跨服恢复任务的`return_to_bot_id`为空，而`@替身BOT`本身是可执行路由信号，强行补写可能与显式回报、救援派发和幂等逻辑叠加；现有缺失回报标记时只重试当前步骤的保护保持不变。
- 改动文件：`xiuxiu3_core/standalone.py`、`VERSION_RECORDS.md`、`VERSION_LOCK.md`以及秀秀3.0功能修改进展网站。
- 验证结果：Python编译通过；现有跨服Loop失败恢复回归`6 passed`。组合旧测试另有4项与当前3.222基线不一致的历史断言（300秒旧超时、旧分组原因文案、旧函数签名），与本次深度修改无关，未为通过测试而反向改动现网功能。未启动真实16-BOT Loop。
- 同步与回滚：部署前各节点只备份本机`standalone.py`、版本文件和systemd版本标记，不复制或覆盖数据库、环境、密钥、BOT工作区和节点身份；普通回滚恢复故障节点自己的3.222文件并重启Web/Bridge。守一替身需使用其独立SSH管理钥匙，连接确认前不通过其他节点代写。