REQ怎么展开、并行和交付
2026-10-01 · v0.1.0 · 执行编排提案。不是分支创建、Runtime绑定或发布授权。
Wave归属与经营里程碑 · 逐REQ范围卡 · 模块目录
1. 每个REQ必须带走的完整责任
REQ交付一个可核对的业务能力切片。业务切片包括事实Owner、顾客入口、全局管理/客户下钻、相关作业入口、控制中心接入及人工恢复。不能将小程序页面合并算完成，再另等一个“后台系统REQ”补办理。
技术REQ可以没有业务页面，但必须给真实消费者可使用的能力、结果和限制；后续业务REQ负责实际消费，不让运行基础维护领域金额或状态。
每个范围卡提供：目标、触发习惯/操作动线、必要功能、跨端工作面、事实/目录、可观察出口、失败/边界/恢复、依赖/交接与政策阻塞。它们是逐REQ正式化的输入，不是已经走完REQ模板A→B→C确认的冻结需求。正式化仍用REQ模板，范围卡不另造生命周期。
2. 从范围卡到可执行REQ
| 顺序 | 要完成什么 | 输出/责任 | 不能代替什么 |
|---|---|---|---|
| 1 场景和目标 | 对卡中主任务、投入产出、排除范围和可跑业务核对上游事实；检查客服必要办理 | 逐REQ §A提案，主会话；按既有拍板程序确认 | 不能把本轮“深化”当全部REQ锁定 |
| 2 方向和约束 | 选定职责和实现方向、识别硬约束/政策/真实外部条件 | §B；领域规则/S2方案的前提 | 不能用可配置参数遮住未决商业责任 |
| 3 有限需求库存 | 场景逐项编号、FR/AC、角色/字段/范围、正常/失败/边界/竞争/迁移恢复、NFR | §C和适用迁移清单；人类确认后锁定 | 本文目标判据不是全部正式AC或CASE |
| 4 模块设计 | 按模块八项设计卡推导动作和意群；继承现有风格和导航，场景与系统规则双向检查 | S2架构/模块当前truth package，按正式流程签认 | 不按41个REQ复制stories/flows或画新皮肤 |
| 5 同源契约 | 模型与SYNC共同收口，再派生FE/BE；固定生成配置/样例/业务反例 | S3精确输入、公开操作和消费者 | Schema存在不等于Client已经可使用 |
| 6 分支任务 | 明确文件级write_paths、真实构件依赖、资源/Fixture分区、组合Owner | S4 TASK DAG和交接断言 | 同wave不等于所有TASK无依赖 |
| 7 持续集成 | 独立实现、最小真实交接、跨端联调、失败恢复验证、完整复验 | S5–S9依各自合同，结果回REQ开发分支 | 多个独立PASS不能拼成同候选完整通过 |
| 8 验收交接 | 对精确候选核对有限覆盖、反证、责任、运行条件 | S10审计→S11人类Gateway | 验收不自动合并、部署或发布 |
当前设计投入为extended，Foundation仍为provisional。requirement-funnel要求覆盖Surface的Foundation正式发布后才进入有UI变更REQ的正式A→B→C；本轮完成规划卡，未提前编造该批准。无UI的共享基线/工程公共范围可以继续按其真实前提正式化。UI任务的规划卡可审查，但不能据此开始受约束的产品实施。
3. Wave内部先立约，再并行实现
3.1 公共交接包
由本wave各Owner共同整理到已有项目模型/合同入口，不另建wave私有模型注册表：
- 本wave启用对象与唯一Owner、ID/版本、核心不变量及操作/事件库存。
- Operation/Slot原生Schema、合法样例/结构反例；授权、状态和竞争反例进入适用CASE/CT。
- 请求幂等/异载荷/冲突、时钟/截止、错误/UNKNOWN、原目标查询和人工恢复协议。
- 各端挂载、组合入口、能力未就绪、媒体/设备/Provider端口；真正存在的生成Client版本。
- Fixture租户/主体/命名空间/清理方法、外部配额、共用环境、迁移次序与兼容窗口。
- 本wave共同业务演示及反例库存，绑定精确集成版本与相关REQ的实际AC/CASE。
没有人被授权代写别的Owner语义；共用入口由一个组合Owner维护，其他分支交付公开能力。公共契约变化走变更控制，不能在冻结后就地刷新哈希逃避重新审查。
3.2 同wave存在三种等待
| 等待 | 示例 | 做法 |
|---|---|---|
| 语义/政策尚未确定 | 退款去向、超重责任、费用跨档、受托证据 | 相关合同不能冻结；独立功能可推进，不使用默认值伪造决策 |
| 公共构件尚未存在 | 生成器、框架挂载槽、可靠存储端口 | 提供者交最小真实TASK并集成后，再建立该构件的消费TASK；其余任务继续 |
| 对端实现尚未汇合 | 支付分支仍在开发，订单已可受理 | 可用隔离Stub开发/协议验证；汇合真实实现后才能证明购买付款闭环 |
这是依赖管理，不把W4人为改成报价REQ全过→订单REQ全过→支付REQ全过→确认REQ全过。
3.3 关键组合Owner与公共路径
| 共同工作面/资源 | 组合责任 | 其他REQ交接 |
|---|---|---|
| 顾客账户/地址与客户上下文 | CUSTOMER-ACCESS维护自助入口；BACKOFFICE-ACCESS维护全局/客户挂载 | Identity/Customer提供命令、解释和版本；后续域模块挂载，不改公共根 |
| W3商品浏览/详情 | CATALOG-PUBLICATION | 媒体、Supply可用性/追溯为独立组件/查询；首页引用相同发布版本 |
| W4购买核对/提交 | ORDER-BATCH维护购买旅程根和协调状态 | QUOTE交报价/权益；PAYMENT-FUNDS交支付/原结果；DELIVERY-CONFIRMATION交后续安排入口 |
| W4配送安排/代办详情 | DELIVERY-CONFIRMATION | Commerce交费用/资金/商业关闭结果；Fulfillment交原始能力；受托证据归各Owner核验 |
| W5作业/开工与称重上下文 | EXECUTION-WEIGHING | Supply交物料/质量接口，Package交封包入口；不从组合页直接改源事实 |
| W5客户账单/交易结算视图 | SETTLEMENT-REFUNDS | Payment交真实退款/额度；Finance交会计来源接受/阻塞，业务与会计结果分开 |
| W6售后分项处理 | AFTERSALES | 变化/资金/交付/回收为公开动作与分项结果；客服一次办理但不伪造全项完成 |
| 全局经营概览 | BACKOFFICE-ACCESS维护只读组合槽，各业务REQ交付本域实时查询 | ANALYTICS提供获批准口径/历史分析；W6之前概览也不能是假数字 |
| 原生Schema、生成配置、根路由/lockfile、迁移总次序、共用环境 | 指定公共维护/集成责任；具体人员执行前登记 | 领域分支按独立文件输出或提交队列，禁止多人共改同一公共根 |
| 模块当前stories/flows/场景/Fixture等共享设计文件 | 模块设计责任集中维护；修改走设计/变更队列 | 各REQ贡献有来源引用的增量，合入同一当前包；不复制按REQ/分支命名的设计包 |
上述名称为候选REQ责任标识，不是假定对应人员已到岗。没有实任Owner的高风险恢复/资源事项，在启用前保持阻塞。
当前后台原型多个功能共用admin-console设计包，是并行规划的实际共享路径。共同设计增量应在相关合同冻结前收口；冻结后新REQ再改同一被引用文件，会影响已冻结基线，须明确变更范围和重审，不能以“只是追加故事”绕过。若S2决定迁移成更细的业务模块包，须保留场景/来源/链接/验证覆盖并正式检查迁移，不在本轮复制或拆空目录。
4. 分支与Runtime隔离
- 指定本wave共同开发集成分支和最终发布上游；不默认
develop/main。记录公共交接commit及各REQ真实依赖闭包。 - 每个REQ有自己的权威主checkout、绑定开发分支和Runtime；主Runtime只绑定一个REQ。REQ主checkout与其内部Worker worktree遵守现行工作区集成规则。
- 不复制活跃
.claude/loop-state.json、journal、锁或凭据。Git分支不同并不能证明控制面隔离；多REQ主会话并发的Hook/Runtime/证据路径必须在工程地基中验证和记录。 - 公共交接必须提交并可读；新worktree不靠主会话未提交文件。独立REQ按命名规则派生TASK feature分支，不引入另一套生命周期CLI。
- TASK先回自己的绑定REQ开发分支；REQ成果按授权开发集成进入本wave共同分支。不得将Worker直接混入其他REQ或默认发布分支。
- 汇合后记录各模型/合同/Client/代码/迁移/配置版本。若汇合改变已完成REQ的冻结输入或行为，则重开适用变更/验证；不拿旧证据声称集成版通过。
多REQ调度不是目前单REQWorker协议已证明的能力。本轮没有执行这些动作；工程地基REQ需要交付并发隔离证据后才能采用该执行方式。
5. “立即联调”的具体节奏
| 交接时点 | 要看到的真实结果 |
|---|---|
| 公共合同和构件已可读 | 两端用同源Client，合法/错误/未知结果语义一致；未实现能力显示未就绪 |
| 第一个持久命令完成 | 经真实权限发出→Owner提交→跨端回读；回执丢失查同一原结果 |
| 第一段跨Owner协议完成 | 事件或命令重复/迟到/重启后仍守恒；人工能定位原目标及下一步 |
| 第一条共同业务链完成 | 同一集成版本走通本wave主业务，验证客户自助和工作人员办理、控制中心异常出口 |
| Wave拟结束 | 全部有限库存逐项核对、前轮回归、权限/竞争/恢复、实际责任与运行条件；未通过保留缺口和恢复路径 |
每次小步集成只证明该交接，不宣称完整S7。每个REQ按协议完成完整验证，最终wave/候选再核对真实链路；发现阻断问题进入S8→S9→新完整S7。S10只能补审计证据，发现产品缺陷回修复路径。
6. 第一轮实际怎样启动
- 先审共享基线现有§A，不改成一次性冻结全部领域规则；工程地基可在独立范围继续收敛提案。
- 在W0确定公共原生类型、生成/检查和模块扩展接口，同时把真实产品骨架、迁移机制及多REQ隔离验证落实到工程地基的有限交付。
- W1接口Owner可据W0公开构件并行；UI框架正式需求须先满足Foundation条件。W1出口明确是可靠领域能力/布局槽，W2才把基础办理接到真实入口。
- 之后按活动编排逐轮进入：每轮收口本轮必要政策，不提前替业务批准全部费用、退款、隐私、持续服务和推荐模式。
7. 反证与待办责任
会推翻“可并行”的证据包括：实际同文件写入冲突、公共构件尚未可用、政策影响双方合同、共享外部资源无隔离、跨REQRuntime串写、消费不同Schema或生成Client、集成版本无法复现。发现后拆最小交接TASK/分区/重审相关合同，保持其余独立责任继续；禁止靠复制DTO、复制Runtime或管理员直接改状态消除等待。
主会话维护编排与覆盖；领域Owner负责事实/协议；集成责任负责公共路径和精确候选；业务/现场/财务/安全/运行责任人在启用前落实。残余风险和恢复责任写入各REQ及正式审计，未检查保持UNKNOWN。本文没有授予人类生命周期动作、锁定或发布权限。