需求域商户侧设计方案 v1.0

🕐 时效标注（2026-09-13 文档治理）：近期设计件，口径以 TASKS 现行与契约 v1.3 为准。

版本：v1.0 ｜日期：2026-09-02 ｜起草：波波（云端）｜状态：~~设计定稿，待义父派工口令~~ ✅ 已落地（WIP-133 M1-M3 全验收通过，commit df1fbdd：DemandHall 需求大厅 + DemandDetail 双模式动作区 + MyDemands 我的接单）｜状态词修正 2026-09-09（波波 WIP-237 倒挂治理，刘总授权）

依据：小齐 09-02 交付需求域 M2 后端全套（demand 路由/通知服务/expire_demands 定时过期/035 迁移）

定位：B 端 H5 工作台的第 15 个入口（14 业态之外的平台撮合面板）。

一、总架构判词：需求域不产生新资金流

游客发需求→商户接单→成交必须落回既有下单-核销链（复用唯一可信设施）。商户应约/报价动作本身不收款，平台不经手、不撮合担保任何资金——与主理人四不同一法度。

二、边界声明

无福钥参与（义父 16:04 拍板）：需求域箭头=游客发起、商户响应，商户无"出预算买行为"动作，福钥任务模型装不进去；若未来平台补贴游客发需求暖市场，走平台拉活预算，不得挪福钥账
需求单过期由后端 expire_demands 定时消化，前端只做状态呈现

三、H5 页面清单（三件，全在商户工作台）

页	内容	交互
需求大厅（panel）	游客需求流卡片：品类/日期/人数/预算(插槽)/备注	按商户帽子过滤可接品类；红点=新需求数（接 notifications）
需求详情页	需求全文+游客脱敏信息+过期倒计时	接单动作（按模式开关，见 §四）
我的接单（panel）	已接需求列表+状态流转	点开落回下单链

四、接单两模式（模式开关=数字回填清单 #7）

模式	动作	成交路径
报名制	商户点"我来接"→游客从报名者中选	选中后生成对应品类订单，走既有支付-核销链
报价制	商户出价（价=商户自填）→游客比选	选中后同上；报价仅是意向表达，平台不收款不担保

两模式可并存或单选，开关属运营数字；首版建议报名制先开（流程最短）

五、状态机

open（可接）→ responded（有人接）→ matched（游客选中）→ 订单态（落回既有链）

任意前置态 → expired（定时过期）

matched 之后的履约/退款完全复用既有订单链，需求域不留任何履约职责

六、与其他线的咬合

C 端（WIP-130）：游客发需求页已有 service（demand.ts），本方案只管商户侧承接
H5 载体决议 v1.1：三页全部手机端优先，登录态复用工作台骨架（依赖 WIP-131）
派工建议：依赖 131 骨架（panels 渲染器），建议排 131 验收后；派工指令权在义父