minimal-agent 0.6.9 → 0.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "minimal-agent",
-  "version": "0.6.9",
+  "version": "0.7.0",
   "description": "最小化 Agent 系统 —— 10 工具 + 插件系统 + workflow DSL + 自动压缩 + OpenAI 兼容 + Ink TUI；NodeNext + tsc 原地编译，dev 用 Bun .ts、install 用 Node .js（学习/教学用）",
   "license": "SEE LICENSE IN LICENSE",
   "author": "Bill Wang <leiwang0359@gmail.com>",

package/skills/adversarial-review/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: adversarial-review
+description: 质疑一个结论 / 计划 / 既有评审 / 设计方案是否站得住脚——默认怀疑、逼出证据，把发现分成「真问题 / 误报 / 待澄清」。注意：若用户只是想给代码找冗余 / 反模式 / 做常规质量改进，用 /simplify 而非本 skill。
+triggers: 对抗审查、反向提问、红队、挑战这个结论、验证某结论或方案是否站得住脚、哪些是误报哪些是真问题、审稿、复核这个判断
+---
+
+# /adversarial-review —— 对抗式审查（反向提问，默认怀疑）
+
+## 目的
+
+验证一个**结论 / 计划 / 既有评审 / 设计方案 / 一段代码**是否站得住脚时，别让模型（或你自己）
+轻易点头。人和 LLM 面对「这个对吗？」都有**迎合反射**——倾向于附和、补论据、越夸越顺。
+本 skill 的目的：用「反向提问」把这种迎合反射**翻转成怀疑反射**，再用举证纪律把怀疑落到实处，
+最终把发现诚实地分成 🔴 真问题 / ⚪ 误报 / 🟡 待澄清。
+
+## 方法一：把问题转成「表面反向的提问」（扳机）
+
+**永远不要问「X 对不对 / X 是否正确」，要问「X 是不是错的 / X 哪里站不住脚」。**
+
+为什么仅仅换个问法就有用？因为**举证责任被翻转**了：
+
+- 问「X 对吗？」→ 回答者可以**零成本附和**（"对的、挺好"），不费力就能交差，迎合反射全开。
+- 问「X 错在哪？」→ 回答者**必须先假设它有错**，然后去枚举失败场景、找反例、回现场核对才能回答；
+  哪怕最后发现 X 其实成立，那也是**认真攻击过之后**的结论，而不是反射性点头。
+
+类比面试：问「你会不会用 X？」对方反射答「会」；但问「你是不是其实不会 X？」对方被迫拿出
+真凭实据来反驳你——被逼着深度思考、自证清白。对抗审查就是把**每一次判断**都塞进后一种问法里。
+
+> ⚠️ 「换问法」只是扳机，不是终点。光把问法反过来，模型同样可能编出**看似合理却牵强**的
+> 假问题来"完成证伪任务"，那是在制造新的误报。所以扳机必须接上「方法二：举证纪律」。
+
+## 方法二：举证纪律（引擎）
+
+反向提问扣动扳机后，每条判断都要过这三关，否则不算数：
+
+1. **拆成原子主张**：把审查对象切成一条条**能被单独证伪**的主张。整段"感觉对"没意义，可攻击的最小单元才有。
+2. **举证责任在主张方**：每条主张默认**未被证实**，靠具体反例 / 现场核对 / 可查依据来支撑或推翻。判定一律附证据，不附证据的判定本身就是错的。
+3. **去现场，不凭记忆**：涉及代码 / 事实的主张，一律 Read / Grep 核对原文。用脑内印象当证据是制造误报的头号来源。
+
+**误报和漏报一样有害。** 把成立的主张硬说成问题，和放过真问题一样是审查失败——这与「默认怀疑」同等重要。
+
+## 反向提问转换示例（按情况直接套用）
+
+把用户原本（或心里）的「迎合式问法」翻成「反向式问法」，再走方法二的纪律：
+
+| 你想确认的事（迎合式 ❌） | 反向提问的问法（✅ 套这个） |
+|---|---|
+| 这个方案对吗？ | 这个方案**是不是错的**？它在什么输入 / 场景 / 规模下会崩？哪一步的假设最可能不成立？ |
+| 这份代码评审准吗？ | 这份评审里**哪些是误报、哪些是真问题**？逐条去现场核对它说的代码是否真这样。 |
+| 我刚写的这段代码没问题吧？ | 这段代码**哪里有 bug**？给我一个能让它出错的具体输入 / 边界 / 并发时序。 |
+| X 这个事实成立吗？ | X **在什么情况下是假的**？反例是什么？它的依据经得起核对吗？ |
+| 该选方案 A 吗？ | 选 A **会在什么场景下变成错误决定**？A 比 B 差在哪？A 的隐藏代价是什么？ |
+| 这个回答 / 总结完整吗？ | 这个回答**漏了什么**？哪个边界 / 失败路径 / 反例没覆盖？ |
+| 这个重构安全吗？ | 这个重构**会悄悄破坏什么**？哪些调用方 / 测试 / 契约依赖了被改掉的行为？ |
+| 文档 / 注释和代码一致吗？ | 文档**哪一句和代码对不上**？逐句拿去和实现核对，找出已经过时（stale）的描述。 |
+
+**worked example（评审复核——最常见场景）**
+
+输入：「上一阶段的改动，代码评审说有以下 N 个问题，是不是误报？」
+
+- ❌ 迎合式追问「这些问题对吗？」→ 模型容易逐条附和"是的这是问题"，等于没审。
+- ✅ 反向式追问：「这 N 条里**哪些是误报、哪些是真问题，为什么**？每条都 Read 对应文件去现场核对它
+  描述的代码是否属实；拿得出反例/实证的才标 🔴 真问题，只是'觉得没充分说明'但推不倒的标 🟡 待澄清，
+  确认其实成立的标 ⚪ 误报并给出它为何成立。」
+- 效果：模型被迫**为每条结论举证**（无论判真还是判误报），迎合空间被挤掉——这正是本 skill 要的。
+
+## Quick Reference
+
+| 步骤 | 操作 |
+|------|------|
+| 1 | 用 Read 读取被审查对象（结论/计划/评审/设计/代码）；必要时 Grep/Glob 取证，去现场核对而非凭记忆 |
+| 2 | 把对象拆成一条条**独立、可被单独证伪**的原子主张 |
+| 3 | 对每条问「哪里站不住脚」（见下方拷问清单），强迫找反例与证据 |
+| 4 | 给每条分类：🔴 真问题 / ⚪ 误报 / 🟡 待澄清 |
+| 5 | 每条都附**证据**与**为什么**（凭什么这么判，证据指向哪里）；没证据就别下 🔴 结论 |
+
+## 第 3 步：对每条主张的拷问清单
+
+逐条追问，任意一条命中就标记下来：
+
+- **证据不足？** —— 它的依据是什么？依据本身可靠吗，还是空口断言？
+- **把假设当事实？** —— 哪些是已验证的事实，哪些只是"应该是这样"的假设被当成了前提？
+- **想当然 / 跳步？** —— 推导链有没有缺环？"因为 A 所以 C"中间的 B 被默认了吗？
+- **有反例？** —— 能不能举出一个让它崩掉的具体场景、输入、边界条件？
+- **被现有代码/事实推翻？** —— 去 Grep/Read 核对，它描述的代码真长这样吗？实现真按它说的走吗？
+
+### 证明不了 ≠ 错
+
+一段文本里很多成立的主张本就不会附带完整证据——**省略不等于错误**。所以：
+
+- 你能拿出反例 / 找到被现有代码推翻的实证 → 标 **🔴 真问题**。
+- 你只是觉得它"没充分举证"、但也举不出反例 → 标 **🟡 待澄清**，并写明「缺哪个证据才能判定」，**不要**直接判 🔴。
+
+把「主张错误」与「主张未充分举证」混为一谈，是这类审查最常见的误报来源。
+
+## 输出格式
+
+三类同等呈现，不预设哪类一定有内容（真问题为 0 条是合法且常见的结论）：
+
+```
+## 对抗审查结果
+
+### 🔴 真问题（拿得出反例/实证的）
+1. [主张/位置] 这条为什么站不住脚 → 证据（文件:行 / 反例 / 事实）→ 影响
+2. ...
+（若无：「真问题：0 条——下方列出已尝试的攻击角度」）
+
+### ⚪ 误报（曾被怀疑、但其实成立）
+1. [主张/位置] 原审查/结论怀疑的点 → 为什么它其实成立 → 证据
+2. ...
+
+### 🟡 待澄清（未充分举证、但也推不倒）
+1. [主张/位置] 缺什么证据才能判定 → 需要用户/作者补充什么
+2. ...
+
+### 结论
+一句话定调：整体站得住脚 / 有 N 个真问题需修 / 关键前提待澄清。
+```
+
+## 注意事项
+
+- **误报和漏报一样有害**（已在核心段强调，这里重申落地）。不要为了"显得严格"就把成立的结论硬说成问题——驳回一条主张同样要给证据，凭感觉拍砖等于制造新的误报。
+- **找不到真问题就如实说**。如果对象本身扎实、你认真攻击后确实推不倒它，就直说"未发现真问题"，并**列出你尝试过的反驳角度**（找过哪些反例、核对过哪些代码、质疑过哪些假设），证明你是真的攻击过、而非偷懒放水。
+- **去现场，别凭记忆**。涉及代码/事实的主张，一律 Read/Grep 核对原文，不要用脑内印象当证据。
+- **边界**：本 skill 用于质疑「结论 / 计划 / 既有评审 / 设计是否站得住脚」。若用户只是想给代码找冗余 / 反模式 / 做常规质量改进，那是 /simplify 的活，不要套用这里的「默认有罪」框架。

package/workflows/plan.yaml

@@ -1,28 +1,26 @@
 # ============================================================
-#  workflows/plan.yaml —— 复刻 Claude Code「plan」流程的动态工作流
+#  workflows/plan.yaml —— 复刻 Claude Code「plan」流程（Analyze→Verify→Synthesize→Critic→Gate）
 # ------------------------------------------------------------
-#  旗舰演示 AskUserQuestion + 「受工作流指导的有界 TAOR」+ 人机交互：
-#    探索（agent 只读调研） → 澄清（直接用工具问用户，带推荐项）
-#      → 产出计划（agent 综合上下文落盘，遇取舍再回头问用户拍板） → 守门 assert。
-#
-#  与 adaptive-research 的区别：那条线演示「指导 + 随机应变」的旋钮，
-#  这条线把「交互（向用户提问）」也编进确定性骨架里 —— 既有 agent 节点的自主，
-#  又有 tool: AskUserQuestion 节点的「停下来问人」，二者共骑同一座 askBridge。
-#
-#  非交互宿主（-p / gateway / 子进程）下没有 UI handler，AskUserQuestion
-#  会自动选每题首项（约定=推荐项），整条流程照常跑完、绝不挂起。
+#  把 Ultracode 动态工作流的多阶段编进确定性 DAG，全用现有 StepKind（不改引擎）：
+#    Analyze   : analyze(agent 只读探索) → extract_findings(llm 固化成可验证 claims) → clarify_depth(AskUserQuestion 人机交互)
+#    Verify    : verify_findings(type:vote 红队对抗——对每条 finding 反向提问证伪，存活的才进下游)
+#    Synthesize: draft_plan(agent 综合"通过验证的结论"+用户选择，写 ./PLAN.md)
+#    Critic    : critic_plan(skill:adversarial-review 反向提问审稿，把审稿意见追加进 ./PLAN.md)
+#    Gate      : verify(assert 守门，确认 ./PLAN.md 确实生成)
+#  非交互宿主(-p/gateway)下 AskUserQuestion 自动选推荐项、vote 走 LLM，整条流程照常跑完。
+# ------------------------------------------------------------
+#  注：critic 阶段用 skill: 节点 dogfood 仓库自带的 adversarial-review skill —— 演示
+#  「同一套对抗审查方法既能 standalone（/adversarial-review）用、也能在 workflow 里被复用」。
+#  skill 双源查找（cwd 优先、packageRoot fallback）；万一异地 cwd 缺该 skill，
+#  critic 的 onError:continue 兜底——审稿出岔不应推翻已写好的计划。
 # ============================================================
 name: plan
 description: |
-  受工作流指导 + 可向用户提问 + 有界 TAOR 的动态计划流程。
-  - 先用有界子 agent 只读调研目标，梳理关键事实与未决点（不写盘、不副作用）；
-  - 再用 AskUserQuestion 直接问用户「计划要做到多详细」（带推荐项的单选）；
-  - 然后子 agent 综合调研与用户选择产出中文实现计划落到 ./PLAN.md，
-    遇到取舍 / 模糊点可再调 AskUserQuestion 让用户拍板；
-  - 最后 assert 守门，确认 PLAN.md 确实生成。
-  这是 minimal-agent 的旗舰演示：把「探索→澄清→（带推荐的）选择→产出计划」
-  编成确定性骨架，每个 agent 节点内是有界 TAOR，交互骑在 tool_call 回路上。
-version: "0.1"
+  受工作流指导 + 红队对抗验证 + 反向提问审稿 + 人机交互的动态计划流程。
+  Analyze(探索+固化+问深度) → Verify(vote 红队证伪候选结论) → Synthesize(综合通过验证的结论写 PLAN.md)
+  → Critic(反向提问审稿，把意见追加进 PLAN.md) → Gate(assert 守门确认文件生成)。
+  minimal-agent 的旗舰演示。
+version: "0.2"
 
 inputs:
   - name: goal
@@ -31,19 +29,41 @@ inputs:
     description: "要做的事 / 目标"
 
 steps:
-  # 1. 探索：agent 只读调研，自主用 Read/Grep/Glob 梳理事实与未决点（不写盘）
-  - id: research
+  # ===================== Analyze =====================
+  # [Analyze-1] 只读探索：agent 自主用 Read/Grep/Glob 摸清现状（不写盘、不副作用）
+  - id: analyze
     agent: |
       只读调研目标「${inputs.goal}」相关的代码 / 资料：用 Read、Grep、Glob 工具
-      （不要写文件、不要执行副作用命令）摸清现状，梳理出 3-6 条关键事实
-      以及 1-3 个仍然未决 / 需要用户拍板的点。
-      用简洁的中文 markdown 列点整理后直接作为你的最终回答返回，供后续步骤参考。
+      （不要写文件、不要执行副作用命令）摸清现状，整理出 3-6 条候选关键事实
+      以及 1-3 个仍未决 / 需用户拍板的点，用简洁中文 markdown 列点返回。
     allowed_tools: [Read, Grep, Glob]
     capture:
-      content: findings
+      content: analysis
+
+  # [Analyze-2] 固化成可验证 claims：llm 单轮 + output_schema，把笔记抽成数组（供 vote 逐条验证）
+  - id: extract_findings
+    llm: |
+      从下面的调研笔记中抽取「候选关键事实」与「未决问题」，原样保留信息、不要新增臆测。
+      调研笔记：
+      ${analysis}
+    output_schema:
+      type: object
+      additionalProperties: false
+      required: [findings, open_questions]
+      properties:
+        findings:
+          type: array
+          items: { type: string }
+          description: "每条独立成句的候选关键事实（便于逐条对抗验证）"
+        open_questions:
+          type: array
+          items: { type: string }
+          description: "仍需进一步验证 / 用户拍板的点"
+    capture:
+      findings: findings
+      open_questions: open_questions
 
-  # 2. 澄清：直接用 AskUserQuestion 工具问用户「计划深度」（演示 tool 节点交互）
-  #    第一个选项是推荐项（label 末尾标「(推荐)」），非交互宿主会自动选它。
+  # [Analyze-3] 人机交互：直接用 AskUserQuestion 问「计划深度」（第一项=推荐，非交互自动选它）
   - id: clarify_depth
     tool: AskUserQuestion
     args:
@@ -60,30 +80,68 @@ steps:
     capture:
       content: depth_answer
 
-  # 3. 产出计划：agent 综合 findings + 用户选择落盘 ./PLAN.md，
-  #    遇取舍/模糊点可再调 AskUserQuestion 让用户拍板（带推荐项），写完用 Read 自检。
+  # ===================== Verify =====================
+  # [Verify] 红队对抗：vote 节点对每条 finding 反向提问证伪（voter 默认倾向 refuted=true）
+  #          refuted 票数 >= threshold 的 finding 被驳回，只有存活的进下游 —— 杜绝未证实结论污染计划。
+  #          注：voter 偏向证伪，存活集可能偏少甚至为空；下游 draft_plan 对此做了 graceful degrade（见其提示）。
+  - id: verify_findings
+    type: vote
+    input: "findings"
+    voters_count: 3
+    threshold: 2
+    rules: |
+      判断这条「调研结论」是否站得住脚。不要问"它对不对"，要问"它哪里是错的"：
+      是否证据不足、把假设当事实、想当然、会被反例或现有代码/资料推翻。
+      只有当你找不到任何合理反驳、且它确有依据时，才认定成立（refuted=false）。
+    capture:
+      survived: verified_findings
+      kept: kept_count
+      total: total_count
+
+  # ===================== Synthesize =====================
+  # [Synthesize] 综合产出：agent 用"通过验证的结论"+用户选择落盘 ./PLAN.md，遇取舍可再问用户
   - id: draft_plan
     agent: |
-      综合下面两份输入，为目标「${inputs.goal}」写一份中文实现计划，
-      用 Write 工具落到 ./PLAN.md（目录不存在就先创建）。
+      综合下列输入，为目标「${inputs.goal}」写一份中文实现计划，用 Write 落到 ./PLAN.md
+      （目录不存在先创建）。
+
+      —— 通过红队对抗验证的结论（${kept_count}/${total_count} 条存活）——
+      ${verified_findings}
 
-      —— 调研结论（findings）——
-      ${findings}
+      —— 仍未决的问题 ——
+      ${open_questions}
 
-      —— 用户对计划深度的选择 ——
+      —— 用户选择的计划深度 ——
       ${depth_answer}
 
       要求：
       - 计划详细程度遵循用户上面的选择；
-      - 若过程中遇到方案取舍或关键信息模糊、继续做风险大，调用 AskUserQuestion
-        让用户拍板（每题第一个选项放你的推荐并在 label 末尾标「(推荐)」），
-        据用户回答继续；
-      - 写完后用 Read 自检 ./PLAN.md 内容确实落好了再收尾。
+      - 关于上面"存活结论"为空的两种情形请分别处理：若原本就没抽出 finding，按目标从头调研；
+        若是被红队全部驳回（存活 0 但 total>0），别盲信被否的结论，用 Read/Grep/Glob 重新取证后再写；
+      - 若遇方案取舍或关键信息模糊、继续做风险大，调 AskUserQuestion 让用户拍板
+        （每题第一个选项放推荐并在 label 末尾标「(推荐)」），据回答继续；
+      - 写完用 Read 自检 ./PLAN.md 内容确实落好了再收尾。
     allowed_tools: [Read, Grep, Glob, Write, AskUserQuestion]
     capture:
       content: plan_text
 
-  # 4. 守门：确认计划文件确实生成，否则给出中文排查提示
+  # ===================== Critic =====================
+  # [Critic] 反向提问审稿：dogfood 仓库自带的 adversarial-review skill —— 同一套对抗审查
+  #          方法，既能 standalone（/adversarial-review）用，也能在 workflow 里被 skill: 复用。
+  #          产出由 skill 子 agent 直接 Edit/Write 追加进 ./PLAN.md（不 capture——下游无人消费）。
+  #          onError:continue —— 审稿出岔（含异地 cwd 缺 skill）不应推翻已写好的计划。
+  - id: critic_plan
+    skill: adversarial-review
+    maxTurns: 25
+    input: |
+      对当前目录下的 ./PLAN.md 做一次对抗审查（先用 Read 读它）。审完用 Edit / Write 在文件
+      末尾追加一节 "## 审稿意见（反向提问对抗审查）"，按 skill 的输出格式分
+      「🔴 真问题 / ⚪ 误报 / 🟡 待澄清」三类列出并附结论（真问题为 0 条也如实写）。
+      只新增这一节，不要重写或删改计划正文。
+    onError: continue
+
+  # ===================== Gate =====================
+  # [Gate] 守门：确认计划文件确实生成
   - id: verify
     type: assert
     condition: 'fileExists("./PLAN.md")'