| 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 可用时优先使用它承载独立工作。
- 先检查
odw --version。
- 在本仓库里，常规“规划者 -> 多分支 -> 评审者 -> 综合”用
examples/ultra-mode.js。
- 离开本仓库时，读取
../references/ultra-mode-workflow.js，写入临时或项目本地 workflow，
例如 .odw/workflows/ultra-mode.js。
- 如果任务需要挖到干为止、自定义领域 fan-out 或 pipeline，不要硬塞进内置模板；
写一个任务专用 ODW workflow。
- 检查返回的
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 能力，就有意识地模拟结构：
- 先写出拆解方案：切片、视角、领域。
- 把每个切片当成独立处理，不让前面切片的结论污染后面切片。
- 把验证作为独立趟处理，切换到怀疑者视角。
- 显式重复发现轮次，直到某轮没有新发现，或明确预算接近耗尽。
- 最终回答里说明覆盖和验证是串行多趟模拟完成的，不是独立并行 worker 完成的。
最终责任
worker 输出只是素材，不是成品。你必须读完、裁决分歧、去重重叠发现、判断什么是真的，
再综合成一份连贯答案。不要只罗列“worker 1 说 X、worker 2 说 Y”。
