需求：REQ-DW-SHARED-BASELINE
Dispatch policy: waves-v1 名称：跨域协同的共享事实与基础数据契约 状态：draft Owner：项目用户（正式审批身份待记录） PM / Architect：主会话；长期模型维护责任人待落实 版本：v0.1.0 创建日期：2026-10-01 UI impact：none
本稿为wave编排W0的共享基线§A提案，对应能力分析R00，未锁定、未绑定。W0内工程地基可按独立写入边界并行；单个Runtime只绑定一个REQ，不限制不同权威工作区并行。当前范围不修改界面，也不将后三端业务实现包装为UI无影响的基础需求。后续界面REQ须按自身影响和Foundation条件进入漏斗。
§A 理念（Why）
| 字段 | 内容 |
|---|---|
| A1 预期效果 | 为小程序、全局经营后台、控制中心及相关现场作业建立共同理解的事实和数据基础。公共身份/数值/时间/版本/操作结果有单一原生定义，核心交易对象的关系、Owner和未知恢复边界明确，使后续按域交付能直接联调并保持同一业务解释。 |
| A2 背景与痛点 | 当前已有多端原型、十域模型工作稿和部分候选状态机，但尚无实际业务消费者共享的完整可执行契约。原型本地数据和历史示例各有解释；若直接分别实现，订单、配送授权、钱货及监控事件容易被重复建模，客服办理与异常核验会在后期才发现缺口。 |
| A3 成功长什么样 | 下一业务REQ无需重新发明客户引用、金额、单位、截止、版本或操作结果；同一命令的受理、成功、拒绝和UNKNOWN在不同消费者中含义一致。实现者能找到唯一数据来源和验证样例，清楚哪些关系已确定、哪些政策尚未批准，不能用模板或Mock误报完成。 |
| A4-1 明确不做 | 不修改小程序、后台或控制中心页面；本需求交付公共契约基础，具体用户任务和可见状态在对应业务REQ精化。 |
| A4-2 明确不做 | 不一次性冻结十域全部实体、数据库表或API；只收敛公共原语、关键事实边界和后续必需的核心关系，避免脱离场景过度建模。 |
| A4-3 明确不做 | 不批准退款时点/留存、费档、超重责任、受托授权或订阅/增长模式；这些改变商业责任，仍归已有D项和业务REQ。 |
| A4-4 明确不做 | 不建设第二套模型注册表、每REQ私有Schema或全局万能status；使用既有模型/状态/合同体系和各事实Owner。 |
| A4-5 明确不做 | 不实现收款、切配或自动写入生产系统，不执行数据迁移或发布；运行基础和真实业务能力由后续REQ交付并验证。 |
用户和利益相关者：
| 角色 | 诉求 | 决策权 |
|---|---|---|
| 项目用户 / 业务负责人 | 按域协同开发，经营机制和实际办理一致，商业取舍不被技术预设 | 高 |
| 主架构会话及事实Owner | 唯一语义、合法写入与演进可维护；具体Owner人员待落实 | 技术设计责任；不代替业务批准 |
| 小程序/后台/控制中心/作业端实现者 | 共用可验证定义，知道接口结果与恢复，避免反复联调改字段 | 实现建议；消费验证责任 |
| 管理者及办理人员 | 同一客户、订单、钱货跨入口一致；合法人工干预有依据 | 场景与使用习惯输入 |
| 顾客 | 不重复付钱/确认，不因跨端状态不一致失去服务或资金 | 权利与体验约束输入 |
术语：
| 术语 | 含义 | 禁止混用 |
|---|---|---|
| 唯一事实Owner | 定义事实语义和合法写入责任；可有受控快照和投影 | 单个页面、所有数据放一张表 |
| 共享模型 | 项目当前原生数据定义，同一operation/slot由真实消费者共同验证或生成 | 前后台分别手抄接口、每REQ复制字段 |
| SYNC | 操作、时序、错误、并发与恢复契约 | 只有字段表或网络调用示意 |
| UNKNOWN | 尚未验证实际结果，需保持原目标和核验责任 | 确定失败、未发生、可直接再执行 |
| 控制中心 | 通用监控、响应和受控自动化的工作面 | 业务规则Owner、现场作业端 |
| 核心关系骨架 | 餐次/购买来源、订单/原款、授权/执行、结算/退款的身份和基数约束 | 已冻结全部生命周期和商业政策 |
§A建议：先建立有限且可验证的公共事实/契约基础，再按域增量扩展。替代方案为立即逐页面实现，其成本是数据与恢复语义在多端重复定义，后期返工不能只靠UI调整解决。需要确认的范围是：首个REQ优先交付该基础，而非将所有业务功能并成首批。
§B 方向与约束
待§A确认后展开。技术表示、具体文件、验证方式和相容性边界由下一层提案收敛；编排文档提供分析输入，不替代本层批准。
§C 具体需求
待§B确认后展开需求点、可判定验收、非功能约束、迁移库存与UI影响回显。本轮未填FR/AC，不宣称具备锁定条件。
§D 待澄清问题
| 编号 | 问题 | 影响范围 | 阻塞范围? | 状态 | 结论 |
|---|---|---|---|---|---|
| Q-001 | 首个REQ的§A优先范围是否采纳 | 理念/范围 | 是：进入§B前 | open | 推荐公共事实与数据契约先行；未记录确认 |
| Q-002 | 长期共享模型维护责任及正式绑定身份/分支/上游 | 演进/运行绑定 | 是：相应合同和绑定前 | open | 不从Git身份或对话昵称推断，当前不绑定 |
| Q-003 | 公共原生表示与真实消费验证方式 | 数据/验收 | 是：§B/§C收口前 | open | 按现有共享模型规则提出方案；示例Schema不作为真实消费者证据 |
§E 锁定记录与逐层拍板
| 日期 | 操作 | 操作人 | 说明 |
|---|---|---|---|
| 2026-10-01 | drafted | 主会话 | 按用户要求编排跨域REQ，提出首项§A；没有锁定或绑定授权 |
| 层 | 日期 | 拍板人 | 方式 |
|---|---|---|---|
| §A | 待确认 | 待记录 | 尚未批准 |
| §B | 未展开 | 待记录 | 不适用当前轮 |
| §C | 未展开 | 待记录 | 不适用当前轮 |
本轮§A自审：实现者需要可执行原生定义和实际消费证据，故不以文档目录完成为成功；使用者需要跨端结果一致，故保留UNKNOWN与恢复而不合并全部状态；维护者需要有限范围与演进责任，故保留事实Owner并排除模型副本。公共字段、精确测试范围与责任人尚未收敛；这不是锁定前全审结论。
变更记录
| 日期 | 版本 | 内容 |
|---|---|---|
| 2026-10-01 | v0.1.0 | 创建首个跨域基础REQ的§A提案，保留后续层及真实批准记录；编排引用调整为W0并行范围，未新增批准 |