# 开源对照与可执行性审查输入

本轮由用户明确授权多sub agent，统一`gpt-6-luna`、`max`。三个域范围研究覆盖41个候选REQ，另加后台体验和端到端反例两个横向专项；受平台并发上限限制分批执行。主会话综合证据，不代替被派发者完成其责任。

## 调度和边界

- [范围清单](assignments.json)记录只读责任。它不是已注册Runtime的S5/S7 manifest，不伪造正式Agent状态/结果。
- [输入指纹](inputs.json)记录派发时当前工作区59份实际文件，包括未提交文档；正式产品阶段仍需正式提交和冻结链。
- 初始Runtime为inactive/S0，无bound REQ。已检查项目`agent-dispatch`技能、`document-verifier`及`delivery-verifier`角色；这两类角色分别以正式S5/S7的冻结链为前提并禁止WebSearch/WebFetch，不能假作本轮联网研究角色。因此本轮为该职责之外的一次性只读研究，未隐式替换正式审查角色/控制面。
- 已核对`runtime register-workgroup --help`的CLI实际返回，不据空usage判断命令不存在；没有以S0资料伪造可接受的正式ReviewPlan、REQ锁定/绑定或人类批准。
- Agent先向主会话发计划，再继续只读资料/官方开源文档；不写产品/需求/证据文件、不提交、不运行产品测试。主会话保存返回材料和综合报告。

## 审查判准

每REQ必须有明确覆盖项和理由，不以审查员看到文档就判可执行。发现要说明：本地位置、需求/不变量、具体反例/后果、属于当前规划缺口还是以后实施证据、开源官方证据/适配限制、建议与替代成本、关闭证据及职责。

严重度区分阻塞正式化、阻塞实施、阻塞发布、优化；这是研究分类，不是新Runtime gate。缺代码、运行人员或生产环境如本来属于后续阶段，不能单独当S0方案缺陷；未决商业政策不能默定。已有业务确认、全局后台/客户下钻、通用监控优先于场景的方向作为固定审查前提。

开源对照区分完整底座、可复用组件、仅可借鉴的模式；版本/许可证/付费边界以直接官方源为准，未核实保持UNKNOWN。推荐候选不等于已经适配/实施；重复引用同一官方能力不等于多份独立证据。

主会话复核反例是否被既有主讲覆盖，排除误报/重复，归并跨Owner问题；不借本轮审查未经确认修改所有候选范围、波次或技术栈。审查结论是规划质量/可行性评价，不产生产品验收、发布授权或完整S7 PASS。