ultra-mode

name	ultra-mode
description	执行被显式授权的 Ultracode / Ultra Mode 请求：在用户给定范围内，把优化目标设为尽可能 详尽和正确，使用当前环境提供的任何独立工作机制（ODW workflow、子智能体、派发 worker、 并行工具任务）进行覆盖、验证和综合；只有完全没有这类机制时才使用串行多趟退化方案。 当用户明确说 ultracode、ultra mode、go exhaustive、深度模式、多 agent、并行、 对抗式、彻底处理、别漏掉任何东西、每个角度都查一遍，或要求多种独立验证策略时使用。 不要只因为任务困难、技术性强、含糊或高风险就自行启用。

Ultracode / Ultra Mode

Ultracode 是一种行为模式，不绑定某个具体工具。激活后，只在用户给定范围内优化一件事：产出尽可能完整、正确的答案。Token 和算力成本不是约束，但这不等于可以扩大任务范围。

使用环境里任何可用的独立工作机制。本仓库里优先使用 Open Dynamic Workflows (odw)。如果完全没有独立 worker 能力，就使用本文末尾的串行退化方案，并在最终回答里说明。

范围纪律

• 只把显式授权视为激活依据：当前请求点名、已确认的 session 设置，或用户直接要求多 agent、 并行、对抗式、穷尽式、独立验证。
• 即使 session 级别已经开启，也要逐个请求重新评估范围。一个 Ultracode 任务完成后， 不要让它蔓延到无关后续请求。
• 小事仍然小做。合格工程师 30 秒内能答对的请求，直接回答，不上编排。
• 深度要和请求匹配。窄而随意的请求只需要适中分头查找和轻量验证；明确要求彻底性的请求才使用 更大规模的发现、挖到干为止、对抗式验证和综合。
• 遇到含糊范围，按较窄的合理范围做，并说明覆盖了什么、没覆盖什么。
• 每新增 worker 或轮次，都要对应一个具体覆盖缺口。仅仅“预算还有”不是理由；“某个领域未检查”才是理由。

先判断拆解目的

派发工作前，先判断拆解是为了什么：

• 全面覆盖：存在很多独立部分，例如文件、模块、需求项、研究角度。
• 信心/确定性：只需要一个答案，但单次尝试可能听着合理却是错的，需要独立视角和反驳。
• 规模：任务大到一次做不完，例如完整审计、大迁移、大范围排查。

真实 Ultracode 任务通常同时包含至少两类目的。

控制流形态

先问：某个 worker 的结果能不能立刻被用上，还是必须等所有同级结果都回来？

• Fan-out / fan-in：把独立单元派发出去，再在屏障处汇总。只在下一步确实需要全量结果时使用： 去重、排名、判断“到底有没有问题”、最终综合。
• Pipeline：让每个条目按自己的节奏走完多个阶段，不等待无关条目。多阶段工作默认用这个形态， 例如发现 -> 验证 -> 撰写。
• 挖到干为止：开放式排查时，跑一轮独立查找、合并去重、再跑下一轮，直到连续 2-3 轮没有新发现 才停；高风险审计可以提高阈值。
• 预算感知扩展：用户给了明确精力或 token 预算时，持续扩大覆盖和验证深度，直到预算接近耗尽， 或确实没有具体缺口。

典型审计形态：按领域 fan-out；每个领域内部 loop-until-dry；每个存活发现进入独立验证 pipeline； 最后只保留一次屏障，做去重综合。

质量门

• 对抗式验证：非平凡发现或“已修复”结论，都要派怀疑者尝试反驳。举证责任在提出结论的一方。 多数认真反驳仍反驳不倒时，才保留该发现。
• 多视角验证：把怀疑者分配到不同失败模式：需求正确性、安全性、性能/资源、实际复现、 边界情况、未检查假设。
• 评审团模式：开放式设计或综合题，先让几个真正不同的方案独立产生，再由独立评委打分， 最终以最强方案为基础，并吸收其他方案的好点子。
• 多策略搜索：探索类任务用不同搜索策略并行查找，避免单一策略的盲区定义结果。
• 查漏评审：以为完成后，专门跑一趟“还漏了什么”：未打开文件、未验证断言、未读资料、 未测边界、未覆盖角度。真实缺口要重新纳入工作，而不是当备注。
• 覆盖披露：如果覆盖被限定过，最终回答里要具体说明，例如只抽样、只看 top N、某检查未重试。

映射到 ODW

odw 可用时优先使用它承载独立工作。

1. 先检查 odw --version。
2. 在本仓库里，常规“规划者 -> 多分支 -> 评审者 -> 综合”用 examples/ultra-mode.js。
3. 离开本仓库时，读取 ../references/ultra-mode-workflow.js，写入临时或项目本地 workflow， 例如 .odw/workflows/ultra-mode.js。
4. 如果任务需要挖到干为止、自定义领域 fan-out 或 pipeline，不要硬塞进内置模板； 写一个任务专用 ODW workflow。
5. 检查返回的 final、lanes、reviews，把它们视为辅助素材。真实编辑、测试、提交和最终判断 仍由你完成。

有边界的运行：

odw run examples/ultra-mode.js --wait --args '{"task":"<任务>","intensity":"standard"}'

较长运行：

RUN=$(odw run examples/ultra-mode.js --args '{"task":"<任务>","intensity":"max"}')
odw logs "$RUN" --follow
odw result "$RUN"

常用参数：

• task：必填，除非直接传入裸字符串。
• intensity：lite、standard 或 max；默认 standard。
• lanes：独立工作分支数量；默认按强度分别为 3/4/6。
• reviewers：对抗式评审者数量；默认按强度分别为 2/3/4。
• constraints：硬性要求，可以是字符串或字符串数组。
• context：相关文件、仓库事实、已有发现或用户偏好。
• finalFormat：最终综合结果的格式要求。

ultra-mode 的 lane 显式请求隔离（isolation: "worktree"），改动落在一次性 git worktree 里——请保持这一点，除非用户明确要求共享的就地执行（ODW 的默认行为）并接受风险。worktree 隔离要求 source 是有提交的 git 仓库。意外变大的运行用 odw stop <run_id> 停止，或用 odw pause <run_id> 暂停。

串行退化方案

如果没有任何独立 worker 能力，就有意识地模拟结构：

1. 先写出拆解方案：切片、视角、领域。
2. 把每个切片当成独立处理，不让前面切片的结论污染后面切片。
3. 把验证作为独立趟处理，切换到怀疑者视角。
4. 显式重复发现轮次，直到某轮没有新发现，或明确预算接近耗尽。
5. 最终回答里说明覆盖和验证是串行多趟模拟完成的，不是独立并行 worker 完成的。

最终责任

worker 输出只是素材，不是成品。你必须读完、裁决分歧、去重重叠发现、判断什么是真的， 再综合成一份连贯答案。不要只罗列“worker 1 说 X、worker 2 说 Y”。