鼎味肉市小程序新原型：用户故事与验收锚点

当前定位：本目录是顾客小程序的备选回退与对照包；首选方向见 customer-miniapp 与 DFD-003。旧的传统版与组件化版只保留为历史输入；本包中的 REQ/产品/设计文档引用是历史来源，不是当前活动文档权威。

本包的设计代数为 v6.5。本轮重新定义了从选肉到支付的主路径：买肉页直接完成 SKU 选择，购物车降为可选预览，统一确认页一次性承载商品、金额、地址、配送时段和 Quote，支付通过微信原生支付完成。本文描述的是用户逻辑和目标验收，不是线上实现完成声明；当前 HTML 已用原生样式支付模拟层表达状态，真实支付接入和回调契约仍待实现。

同目录的 scenario-model.json、cases.json 和 fixture-contract.json 已同步 v6.5 中属于当前 CASE 的入口、预览和状态语义；真实保存菜谱持久化、Quote 服务、微信支付回调与幂等仍待实现，静态原型不作为线上能力证据。

1. 用户与核心任务

用户	触发	要完成的任务	不应被迫承担的理解成本
匿名顾客	想买这周的肉	先判断自己是按部位选，还是让系统按吃法安排	不登录也能理解入口；不把匿名态误画成可下单
自选采购顾客	已经知道要买什么	像电商/奶茶小程序一样浏览分类、选择 SKU、确认并支付	不先读品牌长文案；不在商品列表和购物车之间来回跳
有计划的顾客	想规划一周菜谱并一次买齐需要的肉	配置餐次、选择菜谱、记录计划，查看 SKU 需求并直接进入订单确认	不先填一堆抽象条件；不需要自己手算肉量；不把计划误认成购物车
已登录顾客	想买平时常买的肉	从首页“快速下单”进入常买 SKU，再打开详情或直接加入	不重新找目录；不把快捷入口误当成已经下单
回购顾客	想照上次继续	查看上一笔可复用内容并决定是否重新加入	不把历史内容当成新订单；不隐藏当前价格与配送事实
周期配送顾客	想管理未来周期	查看当前合约、下一次配送和可变更范围	不把公开供给摘要写成已分配批次；不误导“已扣款/已发货”
需要帮助的顾客	商品、地址、报价或支付出现异常	看到明确状态、恢复动作与事实边界	不用第二个主按钮重试；不在异常态继续假装成功

2. 故事清单

S-001 首页分流：找肉入口与周计划主任务

source_refs: REQ-001/FR-019, REQ-003/FR-004, REQ-003/FR-006
CASE / PATH: CASE-REDESIGN-001 / F-001, F-002, PATH-REDESIGN-HOME-DOORS
作为匿名或已登录顾客，我希望在熟悉的小程序首页结构中一眼看到“按部位找肉”和“开始做计划”两条主路，从而快速进入符合当前意图的流程；有购买记录时，我还希望看到常买 SKU 的“快速下单”入口。
Given：顾客进入首页，地址可见，身份可能匿名。
When：顾客选择 按部位找肉。
Then：进入 /pages/customer/buy，页面标题为“买肉”，左侧是商品分类，右侧直接展示 SKU 商品列表。
When：顾客选择 开始做计划。
Then：进入 /pages/customer/basket，页面先展示本周餐次和计划状态；无计划时提供“安排一顿”，已有草稿时提供“继续安排”，不先把顾客送进购物车。
When：已登录且有常买记录的顾客点击“快速下单”中的某个 SKU。
Then：进入买肉页对应 SKU 的当前目录位置，顾客可以直接打开详情，也可以由商品卡加入待选内容；快捷入口不代表已下单。
反例：首页不展示商品瀑布流、不展示促销角标、不把购物车或结算作为第三条同等级主门；常买 SKU 不能压过周计划主任务。
原型区域：home.html 的 .intent-bar、.home-focus、.quick-section；buy.html；basket.html。

S-002 商品目录采购：分类、详情、加入

source_refs: REQ-001/FR-021, REQ-003/FR-010
CASE / PATH: CASE-REDESIGN-007 / F-001, PATH-REDESIGN-TRACE-SUMMARY
作为顾客，我希望像使用奶茶或电商小程序一样，从左侧分类快速浏览 SKU，点进详情确认，或直接加入并尽快进入一次统一确认。
Given：顾客从“按部位找肉”、首页常买 SKU 或买肉 Tab 进入买肉页；当前配送地址可见，目录状态已知或正在加载。
When：顾客进入买肉页。
Then：左侧分类和右侧 SKU 商品列表立即可见；每个商品卡只突出商品图、商品名、标准规格、固定价格和加入按钮，不放解释性长文案。
When：顾客点击左侧分类。
Then：商品列表切换到该分类，分类选中态清楚可见，不改变待选内容。
When：顾客点击商品行的 加入。
Then：只把该 SKU 加入待选内容，按钮显示当前数量并更新购物车入口；顾客可以继续选，也可以直接进入统一订单确认，不强制经过完整购物车页。
When：顾客点击商品图片或商品名称。
Then：进入独立的 /pages/customer/product-detail 商品详情页；详情页提供规格事实和加入动作，加入后可回买肉或进入确认。
事实边界：列表和详情显示 500g/份 · 标准规格 与固定价格；不在浏览阶段显示预分配的实际 Lot ID。
失败边界：目录加载中保留可理解的骨架；商品下架、价格缺失或供给不可用时保留原因并关闭加入；地址失效时提示重新确认配送范围。
反例：不能把搜索框、供给公告、回购建议或解释性标题放在商品列表前抢焦点；不能使用“约 ¥xx”暗示 V1 会二次结算；不能显示内部 catalog/Quote 版本。
原型区域：buy.html 的分类侧栏、SKU 商品卡和购物车入口；product-detail.html 的详情与加入动作。

S-003 计划编排：从家庭菜谱到一周采购

source_refs: REQ-001/FR-020, REQ-003/FR-006
CASE / PATH: CASE-REDESIGN-003, CASE-REDESIGN-004 / F-002, PATH-REDESIGN-WEEKLY-PLAN, PATH-REDESIGN-PLAN-EMPTY

当前 CASE 已覆盖计划编辑、SKU 汇总和“按本周计划进入统一订单确认”的可见路径；照片/配方菜谱持久化、Quote 服务和真实支付仍属于后续实现，不把静态原型误报为线上能力。

作为顾客，我希望把家庭常用的菜谱保存下来，排入一周餐次，让系统按每条菜谱对应的 SKU 和份量汇总本周采购，并在计划完成后直接进入一次订单确认。
Given：顾客进入计划页，可能没有计划，也可能已经有本周草稿和已保存菜谱。
When：顾客进入页面。
Then：第一眼看到当前周、已保存状态和已安排状态；随后用七日时间轴查看每天状态，点击某天后只展开当天餐次；空餐次直接提供“安排一顿”，已有餐次直接显示菜谱和 SKU 需求。
When：顾客点击某个日期，或在当天切换午餐/晚餐。
Then：时间轴保留整周概览，下面只展示选中日期和时段的内容；已安排时显示菜谱卡、照片、配方文字、SKU、份量和人数，未安排时显示“安排一顿”。
When：顾客点击“安排一顿”。
Then：菜谱选择器先提供“我的菜谱 / 推荐菜谱”；保存过的菜谱可以直接排入当前餐次，推荐菜谱可以先保存再使用。
When：顾客新建一条自己的菜谱。
Then：只需上传照片、写配方文字、确认对应 SKU 和份量；保存后留在当前选择流程，并可以立即排入当前餐次。
When：顾客替换菜谱、删除餐次或调整份量。
Then：计划自动保存，当前餐次的 SKU 数量和本周汇总立即重算；相同 SKU 的多顿需求合并展示来源。
When：顾客查看本周采购清单。
Then：按 SKU 汇总显示需求量、购买量、包装余量和来源餐次；当前标准规格为 500g/份时，明确显示包装余量。
When：计划达到完成条件。
Then：主动作从“继续安排”切换为“按本周计划下单”，直接生成本次采购快照并进入统一订单确认，不先进入普通购物车页。
When：顾客离开后再次进入计划页。
Then：自动恢复家庭计划、菜谱记录和保存状态；如果已生成采购快照后计划发生变化，明确提示需要同步。
When：顾客已经完成支付。
Then：本周计划保留为“已下单”记录，并提供查看订单和复制到下一周的入口；复制生成新计划，不修改历史订单。
眼位：第一眼是“本周状态与下一步”，第二眼是“选中餐次的照片、配方和 SKU”，第三眼是“本周 SKU 汇总与按计划下单”。
反例：不能把菜谱做成复杂食材知识库，不能要求用户先维护家庭资料才能安排一顿，不能把计划完成后停留在普通购物车语义，也不能把下单画成已经支付完成。
事实边界：配方文字是家庭记忆，SKU 和份量是采购事实；计划采购快照与最终订单分开，计划阶段不绑定实际 Lot。
失败边界：SKU 下架、价格变化、地址失效或配送不可用时，保留菜谱和计划记录，阻止生成无效采购快照，并提示恢复动作。
原型区域：basket.html 的周状态、七日时间轴、选中日餐次、菜谱选择器和采购清单；profile.html 的 Top 2 菜谱预览；recipes.html 的完整管理；订单确认目标为 checkout.html。

S-004 统一确认与支付：只保留一个承诺动作

source_refs: REQ-003/FR-005, REQ-003/FR-010
CASE / PATH: CASE-REDESIGN-005, CASE-REDESIGN-006 / F-001, F-002, PATH-REDESIGN-CART-CHECKOUT, PATH-DESIGN-PURCHASE-CONFIRM, PATH-DESIGN-PAYMENT-RESULT
作为顾客，我希望在一个最终确认页内统一核对“买什么、买多少、多少钱、送到哪里、什么时候送”，然后明确发起一次支付，而不是在购物车、结算、地址和支付之间来回跳转。
Given：顾客已经从买肉页选出 SKU，或从计划页生成了本次采购快照。
When：顾客进入统一订单确认页。
Then：同一页面依次显示置顶配送卡、只读商品明细与唯一应付合计、支付方式及唯一的 确认并支付 主动作；地址和时段点击后才从底部选择层展开。
When：顾客从买肉页点击购物车入口。
Then：待选内容只显示一张商品编辑卡和底部“合计 + 去确认”；顾客可以继续浏览、修改数量，也可以点击 去确认 进入 checkout.html。来源说明、配送信息和 Quote 不进入购物车画布，完整购物车页也不是自选采购的必经页面。
When：顾客从计划页点击 按本周计划下单。
Then：跳过购物车预览，直接进入 checkout.html；商品明细显示本次采购快照的 SKU、数量和行金额，不再加入来源解释文案。
When：顾客修改地址或配送时段。
Then：在确认页底部选择层内完成，并重新校验 Quote、配送范围和配送能力；主页面仍只显示一个当前地址和一个当前时段。
When：顾客需要修改商品数量。
Then：返回买肉待选内容或计划采购清单修改后重新进入确认页；确认页本身不再同时承担商品编辑和最终承诺。
When：顾客点击 确认并支付。
Then：以同一操作上下文调用微信原生支付；不能把点击按钮直接画成“支付完成”。
When：支付成功。
Then：进入支付结果页，明确订单号、配送时段和订单状态；订单详情是可选后续动作。
When：支付取消、失败或状态未知。
Then：回到确认页或显示“支付状态确认中”，保留已选内容和原因；重试使用原 operationId，不创建第二笔订单。
反例：不出现“购物车 → 确认配送 → 支付”三个连续的全屏决策页；不在确认页放两个同等级实心按钮；不提前展示实际 Lot、最终称重或支付成功。
事实边界：浏览阶段是目录固定价，确认阶段是服务端 Quote，履约后才有实际批次与包裹事实。
原型区域：checkout.html 的 .checkout-items、.checkout-address、.checkout-slot-*、.checkout-confirm 和支付状态；当前 cart.html 仅作为可选待选内容预览，真实后端确认与支付契约尚未合并。

S-005 周期配送：看清当前合约与未来影响

source_refs: REQ-001/FR-020, REQ-003/FR-010, REQ-003/FR-004
CASE / PATH: CASE-REDESIGN-008, CASE-REDESIGN-011, CASE-REDESIGN-012 / F-004, PATH-REDESIGN-TRACE-BOUNDARY, PATH-REDESIGN-SUBSCRIPTION-ACTIVE, PATH-REDESIGN-SUBSCRIPTION-EMPTY
作为周期配送顾客，我希望知道下一次配送的时间窗口、当前计划供给摘要和修改边界，从而决定是否继续或调整未来周期。
Given：顾客有或没有有效周期合约。
When：进入订阅页。
Then：有合约时先显示当前合约和下一次配送；无合约时显示说明和可选方案行。
Then：文案使用“计划供给摘要 / 实际批次随订单与包裹可查”，不提前承诺 Lot。
When：选择变更。
Then：明确“只影响未来周期”，不修改已进入履约的事实。
原型区域：subscription.html 的 .account-card、.row-list。

S-006 我的：把身份、菜谱预览和服务入口放在可预期的位置

source_refs: REQ-003/FR-004, REQ-003/FR-007
CASE / PATH: CASE-REDESIGN-013, CASE-REDESIGN-014 / F-005, PATH-REDESIGN-ACCOUNT-SERVICE, PATH-REDESIGN-ACCOUNT-GATE
作为顾客，我希望先在我的页确认身份，并快速预览最近的两条菜谱；需要完整管理时，再进入独立的“我的菜谱”页面，而不是在服务列表里寻找。
Given：匿名顾客可以浏览公开壳；登录后可看到受保护服务。
When：点击我的页。
Then：显示头像、昵称和身份；“我的菜谱”只展示 Top 2 预览并提供“管理全部”；订单和地址保留在我的页，售后、配送、称重和追溯说明收敛为一个“帮助与规则”入口，进入独立页面；匿名态的写操作要求登录。
反例：不显示 customerId、Actor、权限快照等内部元数据；不把服务入口做成互不一致的装饰卡片。
原型区域：profile.html 的 .profile-identity、.profile-recipe-library、.row-list 与 profile-help；订单列表位于 orders.html，地址管理位于 address.html，完整菜谱管理位于 recipes.html，帮助说明位于 help.html。

S-007 失败与恢复：状态要可解释且不能重复提交

source_refs: REQ-002/FR-005, REQ-003/FR-005, REQ-003/FR-009, REQ-003/FR-010
CASE / PATH: CASE-REDESIGN-002, CASE-REDESIGN-004, CASE-REDESIGN-006, CASE-REDESIGN-009, CASE-REDESIGN-010, CASE-REDESIGN-012, CASE-REDESIGN-014, CASE-REDESIGN-016 / F-005, PATH-REDESIGN-SESSION-GATE, PATH-REDESIGN-PLAN-EMPTY, PATH-REDESIGN-CART-UNKNOWN, PATH-REDESIGN-OFFLINE, PATH-REDESIGN-NOT-READY, PATH-REDESIGN-ACCOUNT-GATE, PATH-DESIGN-PAYMENT-RECOVERY
作为顾客，我希望在加载、空集合、离线、图片失败、权限失效、报价变化和支付异常时知道发生了什么，并知道下一步能否恢复。
Then：
- loading 只显示加载骨架/说明，不伪造商品；
- empty 明确“暂无内容”，给出回到入口的动作；
- offline 说明当前仅可看已缓存内容，写操作暂停；
- image failed 保留文字事实，不让主路径消失；
- permission denied 给出重新认证；
- quote changed 要求重新确认金额或配送能力；
- payment cancelled / failed 回到确认页，不重复创建；
- payment unknown 使用原操作查询，不创建第二笔支付或订单。
反例：UNKNOWN 不出现第二个“重新提交”主按钮；不把 NOT_READY、支付失败或待确认填成成功空态。
原型区域：states.html 的 .state-grid；支付异常目标状态位于 checkout.html / order-success.html。

S-008 回购：从订单记录重新核对

source_refs: REQ-003/FR-004, REQ-009/FR-008
CASE / PATH: CASE-REDESIGN-015, CASE-REDESIGN-016 / F-003, PATH-REDESIGN-REPEAT, PATH-REDESIGN-REPEAT-ABSENT
作为有完成订单的顾客，我希望从订单记录发起复购建议，但买肉页仍只负责正常的分类和 SKU 采购。
Given：顾客已登录且有至少一笔完成订单摘要。
When：点击 照上次。
Then：进入当前商品目录重新选择，历史内容只是待确认建议，不在商品目录中插入回购卡片，也不直接创建新订单。
反例：匿名顾客不显示该入口；历史摘要不能暴露给其他顾客；不能跳过当前事实、Quote 和支付核对。
原型区域：profile.html 的订单入口；首页由公开热度菜谱承接浏览兴趣，买肉页不承载回购入口。

3. 设计阶段扩展故事（暂不进入场景覆盖）

以下故事中，保存菜谱和真实支付契约尚未拆为正式 REQ、CASE 或浏览器覆盖；计划下单的可见路径已在 CASE-REDESIGN-003 与原型中对齐，当前阶段继续冻结用户逻辑、购买层级和视觉焦点。

DESIGN-STORY-RECIPE-SAVE 我的菜谱：保存一条可复用的 SKU 配方

source_refs：docs/product/workbench/customer-miniapp-plan-lifecycle-working.md
CASE / PATH：设计阶段路径，待设计冻结后进入场景覆盖。
作为顾客，我希望上传一张照片、写下配方并确认对应 SKU 和份量，把这条菜谱保存下来，下一周可以直接重复使用。
Given：顾客正在计划页选择某个餐次，点击计划页顶部的“管理我的菜谱”，或从我的页预览进入“管理全部”。
When：顾客点击“新建菜谱”。
Then：只出现照片、配方文字、SKU、份量四个必要字段；保存成功后留在菜谱管理页，或从计划选择器返回当前安排流程，不创建购物车、订单或支付事实。
When：顾客在“我的菜谱”管理页点击一条已保存记录。
Then：看到照片、配方文字、SKU 和份量，可以编辑、移除，或把它安排到本周某个餐次。
When：顾客在我的页点击 Top 2 预览中的“安排”。
Then：带着对应菜谱进入计划页的选择流程，不打开第二套菜谱管理器。
眼位：预览页第一眼是两条最近菜谱和“管理全部”；管理页第一眼是数量与新建，第二眼是照片/配方/SKU，第三眼才是编辑、移除或排入计划。
事实边界：照片和配方文字是用户记录，SKU 和份量是采购事实；不额外引入复杂配料映射。

DESIGN-STORY-PLAN-ORDER 按计划下单：从完成的一周计划到支付

source_refs：docs/product/workbench/customer-miniapp-plan-lifecycle-working.md
CASE / PATH：CASE-REDESIGN-003 覆盖可见的计划完成与进入统一确认路径；真实计划锁定、Quote 与支付契约仍待拆分。
作为顾客，我希望在一周计划完成后只发起一次“按本周计划下单”，由系统自动汇总 SKU，并带我在同一确认页完成报价、配送和支付。
Given：本周计划达到完成条件，计划中的菜谱都有可用 SKU 和份量。
When：顾客点击“按本周计划下单”。
Then：系统锁定当前计划版本，按 SKU 汇总采购数量，检查地址和配送能力，生成服务端 Quote，并直接进入统一订单确认页，不经过普通购物车页面。
When：顾客在确认页修改本次购买量。
Then：明确这是本次订单的调整；重新校验 Quote，不静默改变已保存的家庭计划。
When：顾客点击“确认并支付”。
Then：调用微信原生支付；成功进入支付结果，取消、失败或待确认回到可恢复的确认上下文。
When：顾客完成支付。
Then：计划保留为“已下单”，订单与计划采购快照相互独立。
When：采购快照生成后计划发生变化。
Then：显示“需要同步”，不能静默覆盖已生成的采购内容；用户更新后重新汇总并核对 Quote。
When：顾客准备下一周。
Then：提供“复制到下一周”，创建新的计划版本，不修改历史计划和订单。
眼位：第一眼是计划是否完成，第二眼是 SKU 汇总和事实异常，第三眼是“按本周计划下单”；统一确认页再用配送卡、订单明细卡和支付卡承载承诺，且每类事实只出现一次。
反例：不能把“加入购物车”当成计划闭环终点，不能绕过 Quote、配送和支付确认直接显示成功，也不能让下单后计划消失。

DESIGN-STORY-PAYMENT 支付边界：完成支付才显示支付成功

source_refs：docs/design/prototypes/customer-miniapp-redesign/flows.md、REQ-003/FR-010
CASE / PATH：设计阶段路径，待支付契约和 fixture contract 冻结后进入场景覆盖。
作为顾客，我希望知道自己究竟处于“待确认、待支付、已支付、支付失败还是支付状态未知”，从而不会重复付款或误以为订单已经完成。
Given：顾客已经在统一订单确认页完成商品、Quote、地址和时段核对。
When：点击 确认并支付。
Then：产生可追踪的支付操作上下文并调用微信原生支付；按钮进入处理中，不能再次并发提交。
When：支付成功回调已确认。
Then：显示支付成功与订单号；只有此时才可以使用“已支付”语义。
When：用户取消、支付失败或回调未知。
Then：保留确认页内容，展示明确原因或“确认中”，提供查询/重试；重试复用原操作，不创建第二笔订单。
反例：不能把自定义 order-success.html 的跳转本身当成支付成功；不能把订单创建、支付成功和实际批次绑定混成一个事实。

4. 统一验收标准

从买肉页直接加入后，顾客最多经过一个新的全屏页面即可进入统一订单确认；从首页开始最多经过买肉页和确认页两个全屏页面；商品详情只作为可选增加一层。
计划完成后直接进入统一订单确认，不再要求“计划 → 完整购物车 → 结算 → 地址页 → 确认”的连续跳转。
买肉页首屏能完成“选分类 → 找到 SKU → 看详情或加入”的连续理解；页面不放会抢商品焦点的解释性内容。
统一确认页只有一个当前任务：核对商品、数量、Quote、地址和时段，并以一个“确认并支付”主动作收束；购物车预览和地址管理不再各自抢主焦点。
计划页前三个视觉停留点依次回答“本周怎么安排”“这一顿吃什么、对应哪个 SKU”“本周要买多少并如何下单”。
菜谱变更、人数变更和餐次删除都会同步重算肉品需求，并能追溯到来源餐次；计划采购快照与订单快照分开保存。
购物车、地址管理和订单详情仍然可达，但都不是自选或计划采购的必经页面；它们的存在不能增加主路径跳数。
原型明确区分“订单已创建 / 待支付 / 支付成功 / 支付失败 / 支付状态未知”；当前没有真实支付接入时，不得用跳转回执伪造支付成功。
固定价、服务端 Quote、实际批次和最终称重四个事实层次不混用；所有失败分支都能指出当前状态、恢复动作和下一步页面。
视觉组件为语义服务：商品列表用分类+SKU 行，计划用时间轴与餐次，确认页用事实分组，服务入口用列表，不用统一卡片墙制造额外层级。

5. 本轮明确不做

不在首页加入促销、倒计时、商品墙或第二个结算入口。
不把完整购物车页、完整地址页或订单详情页放进每次购买的必经链路。
不在买肉页和计划页之间强行插入一个“为了有页面而有页面”的中转页。
不在没有真实支付契约和回调证据时，把 order-success.html 画成支付成功。
不在浏览页承诺最终 Lot、包裹或称重结果。
不在 V1 承诺“精确买到 300g”这样的可变重量能力；若要支持精确称重，必须另行设计可变重量 SKU、报价和履约规则。
不把非肉类食材伪装成鼎味肉市已提供的商品；菜谱中的非肉类材料显示为自备或未提供。
不把旧原型的问题通过在历史文件上继续打补丁来解决；本包是当前真相，历史包只用于追溯和回退比较。