用途
SecondEye 用于对 CocoPlus 生命周期工件进行多模型对抗式评审。它通过并行启动多个不同视角的评审者（Critic），从效率、完整性、风险、反方论证和边缘用例等角度审视同一份工件，并将发现项聚合为结构化报告，帮助开发者在进入构建阶段前识别阻断性问题、重要问题和改进建议。
主要能力
- 多模型并行评审：默认并行启动五个评审视角——效率（Haiku）、完整性（Sonnet）、风险（Opus）、魔鬼代言人（Sonnet）、边缘用例猎手（Haiku）。每个视角有明确的关注范围：效率视角检查冗余步骤、过度设计、token 开销过大的方案；完整性视角检查缺失需求、未解决的依赖、spec 与 plan 之间的差距；风险视角检查难以逆转的决策、可能失败的外部依赖、数据丢失场景、安全缺口；魔鬼代言人视角构造“计划不应按原样推进”的最强论证；边缘用例猎手识别评估盲点、罕见输入形态、数据分布偏移等。
- 单模型模式：通过 --model 参数可仅启动一个指定模型的完整性视角评审。
- 发现项聚合与去重：读取五个评审输出，合并描述同一问题的发现项并标记 [Consensus]；按六级严重度标签（blocking、important、nit、suggestion、learning、praise）汇总；每条聚合发现包含来源视角、证据、可操作建议和置信度。
- HITL/AFK 与 BLOCKING/MINOR 分类：为每条发现项标注需要人工判断（HITL）还是可在下一轮 build 中自动解决（AFK），以及必须由开发者解决（BLOCKING）还是可自动处理（MINOR）。
- 结论推导：存在 blocking 标签发现项则结论为 BLOCKING；仅有 important 标签则结论为 CONCERNS；仅剩非升级标签（nit、suggestion、learning、praise）则结论为 APPROVE。
- 表扬强制检查：要求每个评审视角至少产出一条 praise 发现项，若缺失则在报告中明确注明。
- 影子规则：支持通过 $secondeye shadow-add 交互式添加候选规则到 .cocoplus/secondeye/shadow-rules.json；影子规则与活跃评审并行运行，其发现项写入 shadow-findings.json，不影响 HITL/AFK、BLOCKING/MINOR、严重度或结论；通过 $secondeye shadow-report 计算每条规则的激活率和开发者接受率，达到阈值后可用 $secondeye shadow-promote <rule-id> 晋升为活跃规则。
- 报告输出与确认门控：报告写入 .cocoplus/lifecycle/secondeye-[timestamp].md，包含 frontmatter（secondeye_id、artifact、models_used、critical_open、acknowledged、action_summary 等）和分节内容。若存在 critical 发现项，$build 处于软门控状态，需通过 $secondeye acknowledge --hitl-only 或 --blocking-only 确认。
使用方式
前提：当前目录下存在 .cocoplus/ 目录，否则输出提示并要求先运行 $pod init。
命令参数：--artifact [spec|plan|review] 指定目标工件（默认 plan），对应路径为 .cocoplus/lifecycle/spec.md、plan.md、review.md；--model [haiku|sonnet|opus] 启用单模型模式。
执行流程：解析参数并验证工件文件存在 → 创建临时目录 .cocoplus/lifecycle/.secondeye-staging/[timestamp]/ → 写入各评审任务提示文件 → 并行启动评审子代理 → 等待全部完成 → 读取并聚合发现项、去重、分类、排序 → 写入报告 → 删除临时目录 → 输出摘要（含 critical 发现项列表、门控提示和确认命令）。
适用场景
适用于 CocoPlus 生命周期中的 spec、plan、review 工件评审，尤其适合在进入构建阶段前需要多角度对抗性审查、识别阻断性风险和边缘用例的场景。
限制
依赖 .cocoplus/ 目录存在；影子规则的晋升需先通过 shadow-report 确认达到配置阈值；影子规则发现项不影响最终结论；报告中的发现项需附带证据和可操作建议。详细配置阈值和 shadow-report 的具体计算参数暂未提供。