---
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`，把它们视为辅助素材。真实编辑、测试、提交和最终判断
   仍由你完成。

有边界的运行：

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

较长运行：

```bash
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”。