文渡 · 长文与文件行动化

共同点

正文与附件共同确认施工安排和住户配合要求；相同内容合并时仍保留两个来源位置。

冲突点

若正文日期与附件排期不同，直接列为冲突，不选择看起来更新的一项；同时记录文件落款和版本号。

口径差异

“工作日”是否含周六、改造范围是否含公共区域等口径差异单列，不能用常识补齐。

版本变化

按文件日期比较新增、删除和改写条款；没有旧版全文时只说“当前版本写明”，不宣称发生变化。

待确认来源

待向物业确认冲突日期、例外申请入口和是否需要回执；问题中引用原文，避免只问“到底怎么办”。

依据与未知项

• user_provided 示例中的目标“读懂物业发来的改造通知并列出要办的事”、情境与材料只来自 compare 模式的对应输入；没有把外部信息或推断写成已验证事实。 fixtures/valid-compare.json
• unknown 示例没有提供“当多版本或多文件口径不一致时，用它并列共同点、冲突、版本变化和待确认来源，不擅自合并。”所需的全部外部依据；现实任务应补充来源，否则对应部分继续保留为 unknown。

多角度复核

• 作者意图作者意图：本模式必须服务于目标“读懂物业发来的改造通知并列出要办的事”；当前首项产物明确为“正文与附件共同确认施工安排和住户配合要求；相同内容合并时仍保留两个来源位置。”，目标若改变就重新开包，不能沿用旧结论。
• 读者责任读者责任：情境“通知包含多处日期和例外情况”直接约束“冲突点”；示例中的具体处理是“若正文日期与附件排期不同，直接列为冲突，不选择看起来更新的一项；同时记录文件落款和版本号。”，其中没有来源的日期、数字和授权仍保持 unknown。
• 事实与意见事实与意见：对“口径差异”只允许形成““工作日”是否含周六、改造范围是否含公共区域等口径差异单列，不能用常识补齐。”所述的内部产物；发送、购买、签署或修改外部系统仍停在用户确认前。
• 条件与例外条件与例外：若执行“版本变化”触及“不把缺页或不可读内容补写成事实”，就保留现有证据并停止推进；本例可回到的具体检查点是“按文件日期比较新增、删除和改写条款；没有旧版全文时只说“当前版本写明”，不宣称发生变化。”。
• 版本与时效版本与时效：五项产物必须能独立复核；“待确认来源”当前留下的恢复依据是“待向物业确认冲突日期、例外申请入口和是否需要回执；问题中引用原文，避免只问“到底怎么办”。”，缺责任人、确认点或来源就不能算完成。
• 可追溯性可追溯性：用户需要确认“正文与附件共同确认施工安排和住户配合要求；相同内容合并时仍保留两个来源位置。”是否符合真实意图；新材料只通过 resume 追加，不能覆盖原始目标“读懂物业发来的改造通知并列出要办的事”和此前证据。

边界

• 不把缺页或不可读内容补写成事实
• 涉及法律、医疗或财务文件时只做信息整理
• 关键结论必须能回到用户提供的原文位置