/align — 跨边界行为契约

仅当至少两个责任方/系统需要对齐可观察行为，或接口歧义可能造成明显返工时使用。单一负责人改内部实现通常不需要新契约。

1. 找到需要对齐的边界

• 有 /probe 决策简报时复用；没有也可根据当前上下文工作，不要求完整发现流程。
• 复用前序事实台账时，同时继承每项的证据状态和最新更正。用户明确撤回/更正的旧值视为已被新值取代；不得在理由、契约表或交接摘要中再次引用旧值为“已确认”。历史冲突无法判定时保留 Unknown，指出冲突并请求澄清。
• 明确调用方、提供方、双方负责人、用户可见行为、数据/安全边界，以及最合适的现有公开接口/交接点。
• 有仓库访问时读取相关项目规范、现有接口和测试，沿用项目词汇与格式；没有仓库/文件访问时标为 Unknown 或追问，不声称读过实现、测试或项目约定。不要为了满足 SpecFlow 引入新协议、Schema 语言、框架、CI 平台或状态机。
• 如果不存在真实的跨边界分歧，说明原因并跳过契约生成。
• 若生成或维护契约状态，区分“已评审”和“已确认”：已确认表示有权的业务决策人对本次范围/验收行为完成确认，技术负责人确认接口与实现边界；涉及数据、安全或设备风险时，补充对应责任人的确认。记录确认人角色、范围/版本和日期。授权人或确认记录缺失时保持草稿/待确认，不把文档状态解释为生产批准。

2. 对齐可观察行为

只定义当前边界所需的最小内容：

• 将各方描述保留为“已报告说法”，直到现有实现/测试证据或有权负责人确认；不要因一方声称“后端现在就是这样”便判其正确，也不要把建议写成现行规则。新状态、失败语义、幂等、重试/回调和超时只列为待确认决策，除非已有证据支持或负责人明确确认。
• 输入/触发条件与预期输出/效果；
• 关键成功、歧义/边界和失败行为；
• 责任归属、鉴权和副作用边界；
• 仅在相关时讨论超时、重试、取消、幂等或部分结果；没有实现证据或负责人确认时，将它们列为待决项，不写成既定规则；
• 验收证据和测试边界，并说明该测试不能证明什么。

优先用简洁行为表或项目原生规格，不生成大套契约包。只有工具链或多个调用方确实需要时才加机器可读 Schema。不要强制所有 AI 功能都有 confidence、source_quote、统一状态枚举或 CI Job。

默认把最小行为表直接回复在对话中。只有用户明确要求可交接/留档产物，或双方确实需要持久契约时，才创建文件；“帮我们对齐”本身不代表要写文件。需要文件且项目没有既有格式时，读取 references/contract-template.md 并删除不适用字段。即使生成文件，也只保留本次已确认内容和待决项，不为完整度填入未确认规则。

3. 技术选择随项目和边界决定

• 有 OpenAPI、JSON Schema、Protobuf、类型定义、API 描述、测试框架或 CI 时沿用现有标准。
• 只有实际采用流式、异步或 CLI 时，才定义相应通信细节。
• 软件连接传感器/执行器或机器人时，约定相关命令限制、单位/坐标、状态反馈、断连行为、人工接管和停止方式。契约不能替代独立设备保护措施或安全审批。
• 校验优先扩展项目现有测试，并在双方约定的公开边界上验证。不要为了演示而默认引入 Python、固定 Fixture 或新的 CI Job。
• 仅当仓库有对应 CI 且能校验本次代码/测试生成的产物时才给 CI 接线。说明是否阻断合并还取决于仓库策略。

4. 交接

把已对齐行为、责任人、验收证据、未决阻断项和产物位置记入项目现有系统。不要为流程仪式生成文件。不得声称书面契约能强制运行时行为或保证零漂移。