--field 可重复且保持请求顺序；--field-id 等价；二者不可混用，和显式 JSON / formatted 输出冲突。
SCENARIO 01 · TASK ANALYSIS
需求上下文不完整，CLI 行为必须自己补齐。
这不是抽象的“插件好不好”问题，而是一个公开目标明确、隐藏行为规格分散在 contract 里的 GitHub CLI 改动任务。
01 / 原始需求摘要
公开 prompt 说了什么？还没说什么？
改进gh project item-list，让用户不用先查 opaque field ID，就能通过可读字段名选择额外表格列；同时支持等价的重复--field-id形式，保持既有用法兼容，错误必须可行动，最后在本地完成验证。
中文摘要
用户要的是“给项目 item-list 增加可选字段列”。真正需要补齐的不是一个 flag，而是从解析、查询、分页、按 ID 映射，到各种 GitHub Project 字段值渲染的一整条行为链。
公开 prompt 还要求候选不要联网、不要恢复上游历史、只把当前仓库当工作区；如果需要产品信息，必须以 OPERATOR_QUESTION 结束。
名称大小写不敏感；显示 canonical name；未知或歧义选择要列出可行动的候选和稳定的 ID。
正常路径复用 item-list 已返回的 field definitions；只有需要且还有下一页时才补齐连接；失败不能先打印误导性半张表。
按 field node ID 对齐；文本、数字、select、date、iteration、milestone、labels、PR、users 等都要人类可读，CR/LF 不能破坏表格。
02 / 五条实际作业路径
同一场景，不同方法把时间花在哪里？
下表先给可审计的 per-run 均值，再解释每条路径实际增加了什么。点击方法名可打开该实验的独立页面。
Without
独立实验页 →原生直接执行
探索现有实践 → 修改产品 → focused test / 调试 → 交付
- 盲评分
- 81.67
- tool calls / 条
- 32.7
- dedup token / 条
- 2.08M
- 墙钟 / 条
- 8:36
候选没有被要求先做 GT 澄清或写计划，主要依靠公开 prompt、仓库现状和自己的判断补规格。这里不是“完全不测试”：三条 run 都留下 focused-test 日志；只是没有独立需求审批，也没有独立 reviewer 闭环。
对需求覆盖的影响：容易把字段分页、flag 冲突、歧义诊断、按 field ID 对齐和多值渲染等隐藏边界当成实现细节，而不是先列为行为契约。
Slim With
独立实验页 →Slim：一次澄清 + Plan-on
brainstorming → 一次 Operator 问答 → writing-plans → 同一 session 实施 / debug / verify
- 盲评分
- 83.17
- tool calls / 条
- 34.7
- dedup token / 条
- 2.27M
- 墙钟 / 条
- 9:10
它把一次外部行为澄清和计划前置，但不强制 Full 的 spec commit、TDD、子代理或独立 review；之后由同一 Codex session 原生完成。
对需求覆盖的影响：比 Without 多一个需求入口，但并不保证会循环追问到所有字段边界都获批。
Requirement Loop
独立实验页 →Requirement Loop：多轮设计获批
探索 → OPERATOR_QUESTION / ANSWER 循环 → DESIGN_REVIEW_REQUEST → DESIGN_APPROVED → plan → 实施
- 盲评分
- 97.67
- tool calls / 条
- 37.7
- dedup token / 条
- 2.87M
- 墙钟 / 条
- 11:27
candidate 不能在设计获批前修改产品；operator 只补充外部可观察行为、指出遗漏或标记 implementation-defined，不提供代码、路径或实现架构。
对需求覆盖的影响：把隐含规格变成明确的行为设计，重点覆盖 flag 冲突、名称 / ID 解析、分页安全、值渲染与失败时不输出误导性结果。
Requirement + Review Loops
独立实验页 →Requirement + Review Loops：需求闭环再加独立反馈
同 Requirement Loop → REVIEW_READY → reviewer findings → 修复 / 重测 → REVIEW_APPROVED → final verify
- 盲评分
- 99.50
- tool calls / 条
- 60.3
- dedup token / 条
- 4.88M
- 墙钟 / 条
- 20:44
独立 reviewer 只看公开任务、获批设计、问答、当前 diff、测试日志和必要 baseline；看不到 hidden contract、rubric、oracle、condition 或其他轨迹。
对需求覆盖的影响：把“已经理解需求”与“当前代码确实满足获批设计”分开检查；本次 canonical 轮数是 1、2、2，而不是固定一次。
Full With
独立实验页 →Full Superpowers：完整复合流程
brainstorming / spec → writing-plans → 任务拆分 / 多代理 → TDD / 实现 → 多层 review / 修复 → verification
- 盲评分
- 99.00
- tool calls / 条
- 244.0
- dedup token / 条
- 15.87M
- 墙钟 / 条
- 40:24
Full 是技能驱动的复合 treatment，不是单独某一个 skill。它把设计、计划、子代理协调、独立 review 和完成验证都纳入同一条流程；轮数由实际轨迹决定。
对需求覆盖的影响：资源显著增加，且 run-02 在 token cap 截止却拿到 100 分，说明产品分、流程依从性和隐藏验收代理必须分开读。
03 / 直接比较
差异不是“有没有写代码”，而是“什么时候把行为契约显式化”
观察点WithoutSuperpowers treatment结果证据
需求信息公开 prompt + 仓库探索，未强制 GT 闭环一次或多轮 operator 澄清；Full 还形成 spec / design / planRequirement Loop 97.67，Without 81.67
实现反馈测试 / 调试留在主 session，没独立 reviewer gateReview Loops 独立 reviewer 循环；Full 还带多层 review / 修复Review Loops 99.50；Full 99.00
资源结构root 为主，平均 32.7 tool calls / 2.08M tokenFull 有 child、guardian、operator 与大量 coordinationFull 244 tool calls / 15.87M token；coordinate 是最大增量阶段
隐藏验收0/6 strict Verified verdictFull 3/6，Review Loops 4/6；完全双判定通过均为 1/3 run高分不等于可靠的二元验收通过
04 / 证据与边界
这页的结论从哪里来？
- 公开 prompt / hidden contract / rubric：新仓库的 冻结实验输入。
- 每条轨迹的时间、阶段、actor、去 fork token：15 条 canonical results 中的 compact trajectory；原始 actor homes 和完整 JSONL 不公开。
- 盲评分和 Verified 代理：每条 run 两份
judge.final.json；Verified 不是协议定义的独立 integration gate。 - 阶段标签是分类器派生。尤其 coordinate 只表示可见的派发、等待、follow-up、审批、guardian/worktree 等过程动作，不是服务端直接给出的语义 token 归因。
- Slim treatment 固定于 四方法提交 fa07307f；后续五方法版本新增的
code-review不属于本次 treatment。