references/output-contract.md
4.6 KB正触发固定十节，除安全整体停止外不得省略。负触发只写触发判定、路由和最小交接，不填十节实体结论。
判断只用 现有依据支持、现有依据不支持、依据不足，无法形成结论。正触发成果状态只用 已形成、部分形成并明确受限字段、因停止条件未形成。
禁止：只打红黄绿不给修改句；保证有效、对方接受或必然可执行；编造未给出的价款、工期、并发量、质保金；把已失效《合同法》技术合同章或《技术合同法》写入结论；把研发失败风险分担或按图必然交付写成可履行主路径；把未见约定写成著作权已经归委托方；把仅交安装包写成已完成核心交付；把技术开发/委托开发/承揽/许可当成已完成的本类型审查。
1. 触发、单方立场与成果状态
立场（委托方／开发方）、授权、签署状态、主要目标。负触发写路由，不启动实体审查。写明中文成果名称是「审查软件委托开发合同（技术类合同）」。
2. 来源登记与 MCP 调用表
S/D/A/C/L/I/G。MCP 未调用也留一行状态：not-registered / permission-denied / error / no-result / partial / conflict / verified-result。search_law 返回已失效《合同法》技术合同章、《技术合同法》及其实施条例、2004 年技术合同解释未修正文本时，记噪声，不得写入 L#。
3. 类型与加载路径
父级 技术类合同，子级 软件委托开发合同。定性理由、易混切开结果（技术开发研发不确定性、一般委托开发、承揽、软件许可/转让、技术服务）。加载路径必须写成：references/基本面.md 与 references/框架.md。写明只读这一对、未通读其他类型。知识库与硬闸冲突时，以 method 硬闸为准。
4. 主体、转包与文本版本
主体表：签约名、履行名、付款名、发票名、授权签字人、拟转包第三人。版本表：正文、SRS/PRD、设计方案、里程碑表、验收标准、开源清单、聊天确认；冲突并列。核心模块未见书面同意转包：该履行能力字段停止或必须改。
5. 给付闭环：源码、著作权、需求、验收与价款
核心给付是否可运行软件+源码；是否夹带研发失败分摊、按图承揽或现成许可；交付物清单是否含带注释源码；著作权买断或授权是否书面；开源清单与强传染协议；需求冻结与变更；初验/试运行/终验；最高比例款项是否以源码核验为前置；质保金。缺口标 G#。不输出第 858 条失败分摊主路径或承揽按图交付主路径。
6. 格式条款与强制规范
是否构成格式条款；免责限责、单方验收、最终解释权、管辖是否加黑提示。强制规范只按第 153 条和解释第 16 条区分，不用失效口诀。黑盒控制、逻辑炸弹只保留识别与停笔。无 search_law 引文则本节点法律结论字段停止，事实摘录和修改句草稿继续。
7. 风险表（必须回链文本位置）
固定列：编号｜文本位置｜原文摘录｜问题｜判断｜级别｜修改句或红线｜来源｜最强反方。
级别只用 红线、必须改、可接受可优化。每一行必须有修改句或明确停笔/转出口径。硬闸七项若文本触及或用户立场下原文沉默，必须各有至少一行。
8. 修改句
按已加载 框架.md 的六步组织：首部、交易条款、配套、尾部、语言、常见问题。每条含：定位、原句、建议句、理由、可退让点。未给出的商业数字用 【待填】。不得把框架里的“3-3-3-1”“变更 10%”写成法定期限。不得输出“研发失败由双方合理分担”或“只交安装包即完成交付”作为可履行建议句。
9. 谈判与签署提醒
谈判顺序：先红线（类型错位、只交安装包却买断收全款、无约定却写著作权已归委托方、GPL 闭源可用、研发失败分摊或按图交付主路径、倒签、黑盒控制），再必须改（源码清单与支付前置、著作权书面归属、开源清单、SRS 附件、初验/试运行/终验、核心转包书面同意、账号实名），最后可优化。签署提醒：双方公章；SRS、里程碑、验收标准、开源清单入附件。不指导倒签或补假验收。
10. 缺口、停止项与提示
G#、字段停止、整体停止、转介。审查模式成果不是整份起草终稿；起草模式见文末。不是履约交底、争议文书或效力保证，也不是技术开发、一般委托开发、承揽或软件许可审查。