# Mtaa 多页面原型推进账本

## Round 14 — cross-page shared demo state slice
- Goal: 打通“店铺发布 → 买家读取 → 下单 → 运营推进 → 送达 → 钱包释放佣金”的一条跨页面演示链。
- Why now: 当前各页面有独立硬编码状态，无法验证无库存卖家 + 平台供货直发 + 卖家收益的核心闭环。
- Acceptance criteria:
  - 使用明确标注的原型级 `localStorage` 演示状态，不接真实后端、支付、物流或 WhatsApp API。
  - `store.html` 发布后，`storefront.html` 能读取同一已发布店铺/模板。
  - 买家下单后，`orders.html` 或 `ops-fulfillment.html` 能读取同一订单。
  - 订单推进到已送达后，`wallet.html` 能读取佣金释放结果。
  - 所有关键页面提供演示状态重置入口，避免旧状态污染下一次演示。
  - 原有页面入口、手机端买家体验和离线打开能力保持不变。
- Non-goals:
  - 不接真实支付、物流、WhatsApp、供应商 API 或生产数据库。
  - 不同时实现完整退款、争议、库存预占和多订单并发；这些留给后续 P0 slices。
  - 不触碰旧删除路径或旧单页原型。
- Interface delta:
  - Existing: 现有页面按钮和 HTML 路由保持。
  - Modify: 发布、下单、履约推进、钱包读取改为经过共享演示状态适配层。
  - Add: 状态重置动作、跨页状态提示和演示边界文案。
  - Preserve: 静态文件可直接打开、没有真实服务依赖。
- Domain delta:
  - Added/modified: `PublishedStore`、`DemoOrder`、`FulfillmentStatus`、`CommissionPayout` 及其最小状态转换。
- Verification:
  - 全目录本地链接扫描。
  - 所有涉及页面内嵌脚本 `node --check`。
  - DOM smoke test：发布后 storefront 读取布局；下单后 orders/ops 读取订单；推进送达后 wallet 显示佣金；重置后状态清空。
- Result 2026-08-24：10 passed, 0 failed, 0 runtime errors；默认演示订单 MT1003，送达后钱包显示 `$1.94` 可提现佣金，提现状态写入 `processing`。

## Round 15 — payment failure and retry slice
- Goal: 在买家结账页验证“支付失败不会生成订单，重试成功才进入履约链”的最小异常路径。
- Why now: Round 14 只覆盖成功支付；若失败、超时或重复扣款责任不清，平台直发的客服、退款和现金流成本会被成功反馈掩盖。
- Acceptance criteria:
  - `cart.html` 提供明确的支付异常演示入口和当前支付尝试状态。
  - 模拟失败后显示可理解的失败反馈，且共享状态没有 `DemoOrder`。
  - 从失败反馈点击重试，成功后才创建 `MT1003` 并进入现有 `track.html`。
  - 重置演示状态后支付尝试和订单同时清空。
  - 不破坏既有成功路径和手机端结账布局。
- Non-goals:
  - 不接真实支付、退款 API、支付网关 webhook、重复扣款对账或生产后端。
  - 不同时实现库存预占、退货争议和多订单并发。
- Interface delta:
  - Existing: 保留 `payNow()` 和结账页面路由。
  - Modify: 支付按钮和成功反馈读取/写入 `PaymentAttempt`。
  - Add: “模拟支付失败 / 重试支付”入口、失败状态文案和状态重置覆盖。
  - Preserve: `storefront.html → product.html → cart.html → track.html` 买家路径。
- Domain delta:
  - Added: `PaymentAttempt.status`（`idle` / `failed` / `succeeded`）及其与 `DemoOrder` 的先后约束。
- Verification:
  - DOM smoke test：失败分支无订单；重试后订单创建；既有跟踪链仍可推进；重置清空支付尝试和订单。
- Result 2026-08-24：9 passed, 0 failed, 0 runtime errors；失败分支反馈可见且无订单，重试后 `MT1003` 创建，packed/shipped/delivered 既有链路不受影响。

## Round 16 — inventory reservation and out-of-stock slice
- Goal: 验证「平台直发承诺可以兑现」——卖的是真有货的东西：库存成为跨页共享状态，下单自动扣减，缺货在结账被拦截并给出明确反馈。
- Why now: 主链与支付异常已通（R14/R15），但库存仍是各页硬编码静态数字；平台直发如果卖出的是没有的货，承诺兑现、熟人信任与佣金成本都会失真。
- Acceptance criteria:
  - `demo-state.js` 新增 `inventory`（p1–p4 各一个数字）进入 `fresh()` 默认值，旧 localStorage 数据经 `read()` 兜底兼容。
  - `product.html` 库存标签、`catalog.html`、`ops-supply.html` 读取同一个共享数字。
  - 下单成功自动扣减对应 SKU 库存。
  - 库存为 0 时 `cart.html` 结账拦截：显示明确缺货反馈，只记 `PaymentAttempt=failed('out_of_stock')`，不生成订单。
  - `ops-supply.html` 提供「补货 +N」最小运营动作，写回共享状态后可再次下单。
  - 重置演示状态后库存还原默认值。
- Non-goals:
  - 不接真实仓储/供应商 API，不做并发锁或预占超时释放。
  - 不同时实现支付 timeout/cancelled/refunded、多订单并发、售后争议（留给后续 slices）。
  - 不动研究页面与旧单页原型。
- Interface delta:
  - Existing: `MtaaDemo.read/write/createOrder/product` 与三个页面现有库存展示位保留。
  - Modify: `createOrder` 增加库存校验与扣减；product/catalog/ops-supply 的库存数字改为读共享状态。
  - Add: `MtaaDemo.inventory()` 读表、`MtaaDemo.restock(sku, n)` 补货；cart 结账缺货拦截分支与反馈文案。
  - Preserve: R14 主链与 R15 支付异常既有行为不变。
- Domain delta:
  - Added: `Inventory{p1,p2,p3,p4}`（初始 p1=1、p2=4、p3=2、p4=6，p1 初始仅 1 件使缺货路径一键可演示）。
  - Constraint: `inventory[sku] ≤ 0` 时下单被拒且不产生 DemoOrder；成功下单 `inventory[sku] -= 1`；reset 还原默认值。
- Verification:
  - jsdom smoke：重建基线主链 10 用例 + 支付异常 9 用例入库，另加 Slice A 用例（初始读取一致 / 下单扣减 / 缺货拦截无订单 / 反馈可见 / 补货恢复可购 / 重置还原 / 无 runtime errors）。
  - `node --check` 全部 HTML 内嵌脚本 + demo-state.js；全目录链接扫描缺失 0。
- Result 2026-08-24：回归套件入库 `tests/`（smoke.test.js / check-scripts.js / check-links.js）。实测 `smoke.test.js` **28 passed / 0 failed / 0 runtime errors**（主链 11 + 支付异常 9 + Slice A 库存 8）；`check-scripts.js` 30 HTML / 24 段内嵌脚本 + demo-state.js 全过（历史口径"34 段"含 src 标签，现以入库脚本精确口径为准）；`check-links.js` 309 个本地引用缺失 0。部署 https://mtaa.pages.dev ：product/catalog/ops-supply/cart/gap-audit 均为 200 且含本轮特征串（productStock、catStock-p1、库存预占演示、out_of_stock、Round 16），06 Markdown 线上可读且含 Round 16 小节。

## Round 17 — payment exceptions completion & refund linkage slice
- Goal: 验证「失败不会悄悄变成坏账或静默丢单」——支付异常状态补全（处理中/超时/取消）与已送达订单的退款联动（钱包回退、佣金冻结可解释）。
- Why now: R15 只覆盖失败→重试；超时挂单和退款回账仍是空白，坏账与静默丢单风险未被验证。
- Acceptance criteria:
  - `PaymentAttempt.status` 扩展为 idle / pending / failed / timeout / cancelled / succeeded / refunded，旧数据兼容。
  - `cart.html` 异常演示面板可选择模拟：失败、超时、取消；超时路径为 处理中(pending) → 约1.2s后 超时(timeout) → 可重试。
  - 已送达订单在 `track.html` 可「模拟退款」：订单终态显示已退款，`wallet.available` 回退佣金，佣金标记已退/冻结。
  - `wallet.html` 提供佣金变动解释行，能说明每笔冻结/回退的原因。
  - 不破坏既有主链、R15 失败重试与 R16 库存拦截用例。
- Non-goals:
  - 不接真实退款 API、webhook 对账、部分退款、重复扣款冲正。
  - 不做多订单并发（Slice C）、争议责任链（Slice D）。
- Interface delta:
  - Existing: `recordPaymentAttempt(status,lastError)` 保留并扩展枚举。
  - Add: `MtaaDemo.refundOrder()`（仅 delivered 可退）；cart 面板「模拟支付超时/取消」按钮；track 已送达终态「模拟退款」入口；wallet 解释行。
  - Modify: cart sync 分支覆盖 pending/timeout/cancelled；track 终态渲染支持 refunded。
  - Preserve: 成功支付主链、失败重试路径、库存拦截行为。
- Domain delta:
  - Added: `DemoOrder.status ∈ …|refunded`、`commissionRefunded` 标记；约束：仅 delivered 订单可退，退款后 available 回退 commission 并置 commissionReleased=false。
- Verification:
  - smoke 新增 Slice B 用例：三种异常按钮存在 / 取消无订单 / pending→timeout 时序 / 超时重试成功建单 / 退款回退钱包至 $0.00 / track 与 paymentAttempt 均为 refunded / wallet 解释行 / 无 runtime errors；全量回归必跑。
  - `node --check` + 链接扫描基线保持。
- Result 2026-08-24：`smoke.test.js` **39 passed / 0 failed / 0 runtime errors**（主链 11 + 支付异常 9 + 库存 8 + Slice B 新增 11）；`check-scripts.js` 30 HTML / 24 段内嵌脚本 + demo-state.js 全过；`check-links.js` 309 引用缺失 0。退款实测：delivered 后 refundOrder 使 wallet.available $1.94→$0.00、order.refunded+commissionRefunded、attempt=refunded；重复退款与非 delivered 退款均返回 null。部署 https://mtaa.pages.dev ：cart（超时/取消按钮）、track（模拟退款）、wallet（解释行）、gap-audit、06 Markdown 均 200 且含 R17 特征串。

## Round 18 — multi-order concurrency slice（结构切片）
- Goal: 验证「多个买家同时下单时，钱货流仍然各自可追踪」——单 DemoOrder 升级为 `orders[]` 列表，单号自增，旧数据迁移，列表页与汇总页全部接线。
- Why now: R14–R17 的能力都建立在「全场只有一单」的假设上；没有并发订单就无法验证运营队列、按单跟踪和钱包汇总是不是真实语义。
- Acceptance criteria:
  - `demo-state.js` 内部状态改为 `orders[]`：单号自增（首单仍为 MT1003，其后 MT1004…）；旧 localStorage 单 `order` 数据在 `read()` 时自动迁移为数组。
  - 新增接口 `MtaaDemo.orders()` / `getOrder(id)`；`setOrderStatus(id,status)` 支持按 id 定位（保留无 id = 最新单的兼容调用）；`refundOrder(id)` 按 id 退款（缺省 = 最新可退的 delivered 单）。
  - `storefront/cart` 买家路径不受影响：cart 支持连续下单（成功后出现「再下一单」，库存允许即可再购）。
  - `orders.html` 与 `ops-fulfillment.html` 渲染实时共享订单列表（含状态标签与按单跟踪链接）。
  - `track.html` 支持 `?id=` 定位订单，缺省显示最新一单。
  - `wallet.html` 汇总所有订单：pending/available 为全局口径，解释行给出单数与释放/待结算分布。
  - 全量回归（含迁移用例）全绿。
- Non-goals:
  - 不做真实并发控制/锁/幂等键；不做服务端分页；不改静态历史示例行（MT1001 等保留为固定布景）。
- Interface delta:
  - Existing: `createOrder/setOrderStatus/refundOrder/inventory/restock/read/write` 名称保留。
  - Modify: `createOrder` 追加式建单并自动编号；`wallet.pending` 变为未释放佣金合计；`statusLabel` 取最新单并显示总单数。
  - Add: `orders()/getOrder(id)`、两页实时列表区、cart「再下一单」、track `?id=`。
  - Preserve: 主链/异常/库存/退款既有用例行为（断言从 `state.order` 迁移到最新单读取）。
- Domain delta:
  - Modified: `DemoOrder` 单对象 → `DemoOrder[]`；新增迁移规则（旧 `order` 包装进数组并删除原键）；约束：单号唯一自增、`wallet.pending = Σ未释放佣金`、delivered 才可退且按单结算。
- Verification:
  - smoke 新增 Slice C 用例：旧数据迁移 / 自增续号 / 多单并存 / orders 页渲染 / track 缺省最新 / `?id=` 定位 / wallet 汇总数值 / 按单退款隔离 / 无 runtime errors；既有 39 用例全部改造为 orders 口径后必须继续全绿。
  - `node --check` + 链接扫描基线保持。
- Result 2026-08-24：`smoke.test.js` **51 passed / 0 failed / 0 runtime errors**（主链 11 + 支付异常 9 + 库存 8 + 异常退款 11 + Slice C 新增 12）；静态基线全绿（30 HTML / 26 段内嵌脚本 + demo-state.js、311 引用缺失 0，脚本口径随新增渲染脚本 +2）。实测要点：旧单 JSON 打开任意页即迁移为 orders[] 且钱包读数不变；连续购买得 MT1004/MT1005 三单并存；track 推进仅作用于定位单（MT1005 packed 时 MT1004 仍 paid）；wallet 汇总 $3.88/$1.94 且解释行含「共 3 单」；refundOrder('MT1003') 按单隔离回退 $1.94，paid 单退款返回 null。部署 https://mtaa.pages.dev ：orders/ops-fulfillment 实时列表、track ?id、cart 再下一单、demo-state getOrder、gap-audit（R14–R18 DONE 卡）、06 Markdown 均 200 含本轮特征串。

## Round 19 — dispute responsibility chain slice
- Goal: 验证「出了售后问题，钱和责任都能说清楚」——买家可对已送达订单开争议，佣金即时冻结，运营按责任方（物流/卖家/平台）判定结案，三种责任对应三种可解释的钱包结果。
- Why now: R17 的退款是无差别的「全额退+佣金没收」；真实私域电商里多数争议需要先定责再处置，否则卖家激励与买家信任互相打架。
- Acceptance criteria:
  - `demo-state.js` 新增 `disputes[]`：争议单号自增（DP2001 起），字段含 orderId/reason/status/responsible；状态机 open → in_review → resolved。
  - 新接口：`openDispute(orderId, reason)`（仅 delivered 且无进行中争议，成功即冻结该单佣金 available→frozen）、`acceptDispute(id)`（受理）、`resolveDispute(id, responsible)`；`wallet.frozen` 入域并兼容旧数据迁移。
  - 三种责任三种结果：判物流=订单视为已履约、佣金解冻发还；判卖家=订单转 refunded、冻结佣金扣除不发放；判平台=平台兜底、买家获赔但佣金解冻发还卖家。
  - track 已送达终态出现「申请售后」，开争议后展示争议状态且不可重复开；ops-trust 新增实时争议处理队列（受理 + 三键判定）；wallet 解释行出现「争议冻结 $X」。
  - 全量回归全绿，既有用例零改动通过（纯增量接口）。
- Non-goals:
  - 不做部分退款、举证材料上传、仲裁升级流程；不做真实赔付打款。
- Interface delta:
  - Existing: 全部既有接口签名不变。
  - Modify: `statusLabel` 不变；wallet 解释行逻辑追加冻结分支。
  - Add: openDispute/acceptDispute/resolveDispute/disputes()、track 售后入口、ops-trust 队列区与 demo-state 引入。
  - Preserve: 主链/异常/库存/退款/多订单既有行为。
- Domain delta:
  - Added: `Dispute` 实体（id/orderId/reason/status/responsible/openedAt/resolvedAt）与 `wallet.frozen` 口径。
  - Modified: delivered 订单的佣金生命周期增加「冻结」中间态；约束：一单同时至多一个进行中争议、仅 delivered 可开、结案必须给出责任方。
- Verification:
  - smoke 新增 Slice D 用例：paid 单守卫 / 开争议冻结 / track 状态联动 / ops-trust 受理 / 三种责任路径的钱包结果差异 / 无 runtime errors；既有 51 用例不改断言必须继续全绿。
- Result 2026-08-24：`smoke.test.js` **65 passed / 0 failed / 0 runtime errors**（主链 11 + 异常 9 + 库存 8 + 退款 11 + 多订单 12 + Slice D 新增 14，既有用例零改动通过）；静态基线全绿（30 HTML / 27 段内嵌脚本、312 引用缺失 0）。实测要点：delivered 单开争议 DP2001 即冻结佣金 $1.94→可用 $0.00；重复申请与不存在订单均被拒；track 转争议态且无重复入口；ops-trust 受理后三责判定钱包结果各异——物流赔付发还 $1.94（订单保持 delivered）、卖家担责转 refunded 且冻结扣除、平台兜底发还至 $3.88 并标记 platformSubsidized。部署 https://mtaa.pages.dev ：track 申请售后、ops-trust disputeQueue、demo-state 三接口、wallet 冻结解释行、gap-audit（R15–R19 卡）、DEMO-GUIDE §2.8、06 md 第 10 轮小节均 200 含特征串。

## Round 20 — address / pickup point / delivery fee & ETA slice
- Goal: 验证「买家在哪收货、花多少运费、多久到手」在原型里是一等公民——Lagos 三档预设地址（含自提点），配送费与时效进下单总额与订单快照。
- Why now: R16–R19 的订单只有商品金额；非洲电商的信任钩子恰恰是「运费透明 + 时效明确 + 可自提」，不进订单就无法验证后续履约与争议场景。
- Acceptance criteria:
  - `demo-state.js` 新增三档 Lagos 预设地址：Yaba 公寓（$1.50 · 2–4 天）、Ikeja 办公室（$2.00 · 3–5 天）、Surulere Mtaa 取货点（免运费 · 次日自提）；`checkout` 状态默认 home，旧数据自动补齐。
  - 新接口：`ADDRESSES` 常量、`setAddress(id)`、`currentAddress()`、`getAddress(id)`；`createOrder` 把所选地址连同费用/时效写入订单 `addressSnapshot` 与 `deliveryFee`。
  - cart 出现地址选择卡（三档按钮 + 费用/时效说明），支付前显示「送货 · 配送费 · 预计」摘要；切换即写入共享状态。
  - orders 页订单卡显示快照目的地；佣金口径不受运费影响（commission 仍按商品金额计）。
  - 全量回归全绿，既有用例零改动通过。
- Non-goals:
  - 不做地址编辑/新增表单、邮编校验、物流商 API 与实时轨迹；ETA 为演示常量。
- Interface delta:
  - Existing: 全部既有接口签名不变（createOrder 仅扩展可选 input.addressId）。
  - Modify: cart 支付面板上方插入地址选择区；orders 卡片增加送货行。
  - Add: ADDRESSES/setAddress/currentAddress/getAddress、checkout 状态域、order.addressSnapshot/deliveryFee 字段。
  - Preserve: 主链/异常/库存/退款/多订单/争议全部既有行为。
- Domain delta:
  - Added: `DeliveryTarget` 值对象（preset 三档）与 `order.addressSnapshot`；`state.checkout` 选择域。
  - Modified: DemoOrder 增加 deliveryFee/addressSnapshot 可选字段（旧单缺省视为无配送信息，页面需容错）。
- Verification:
  - smoke 新增 Slice E 用例：预设三档与默认值 / 切换写入共享状态 / 自提免运费快照 / 办公室运费入单 / 摘要文案 / orders 快照展示 / 佣金不受运费影响 / 无 runtime errors；既有 65 用例不改断言必须继续全绿。
- Result 2026-08-24：`smoke.test.js` **73 passed / 0 failed / 0 runtime errors**（主链 11 + 异常 9 + 库存 8 + 退款 11 + 多订单 12 + 争议责任链 14 + Slice E 新增 8，既有用例零改动通过）；静态基线全绿（30 HTML / 27 段内嵌脚本、312 引用缺失 0）。实测要点：三档预设含 Surulere 自提免费档、默认 home；点选即写 `checkout.addressId` 并更新摘要与动态合计（自提 $12.90 / Ikeja $14.90）；下单生成 `addressSnapshot`+`deliveryFee`（pickup=true fee=0；office fee=$2.00）；两单佣金均 $1.94、pending=$3.88 不受运费影响；orders 卡显示 📍 Ikeja 快照。部署 https://mtaa.pages.dev ：cart addrOpts/deliverySummary/grandTotal、orders addressSnapshot、demo-state setAddress、gap-audit（Round 20 卡与 NEXT）、DEMO-GUIDE §2.9、06 md 第 11 轮小节均 200 含特征串。

## Round 21 — WhatsApp referral attribution slice + final gap summary
- Goal: 验证「卖家的分享真的带来订单」——分享链接带 `?ref=卖家`，买家端可见来源横幅，订单记录归因，运营侧从共享状态实时汇总各来源的订单数与佣金。
- Why now: R16–R20 打通了交易闭环，但「熟人电商」的增长引擎——谁分享谁受益——还没有数据支撑；没有归因就无法验证卖家持续分享的动机。
- Acceptance criteria:
  - `demo-state.js` 新增归因状态域：`state.attribution.ref`（缺省 null → 订单记 `organic`）；接口 `setReferrer(ref)` / `referrer()` / 派生 `shareStats()`（按来源聚合订单数与佣金，全部由共享 orders 实时推导，无独立计数器）。
  - `createOrder` 把当前来源写入 `order.attribution`；佣金口径不受影响。
  - storefront 支持 `?ref=`：进入即写入共享状态并展示来源横幅（「来自 xx 的分享 · 下单后佣金将归属 TA」）；orders 卡显示 🔗 来源；ops-resellers 新增实时「分享归因统计」表。
  - gap-audit 给出六片完成后的「剩余缺口终态总结」。
  - 全量回归全绿，既有用例零改动通过。
- Non-goals:
  - 不接真实 WhatsApp API / 短链服务 / 点击埋点；不做多级分销或佣金分成规则；消息失败反馈不在范围。
- Interface delta:
  - Existing: 全部既有接口签名不变。
  - Modify: storefront 顶部插入来源横幅区；orders 卡追加归因行；ops-resellers 首次接入共享状态。
  - Add: `setReferrer/referrer/shareStats`、`state.attribution` 域、`order.attribution` 字段、gap-audit 终态总结块。
  - Preserve: 主链/异常/库存/退款/多订单/争议/地址配送全部既有行为。
- Domain delta:
  - Added: `Attribution` 值对象（ref 会话级来源）与派生视图 `shareStats`（纯函数，无持久化冗余）。
  - Modified: DemoOrder 增加 attribution 可选字段（旧单缺省视为 organic，页面容错）。
- Verification:
  - smoke 新增 Slice F 用例：organic 缺省 / ?ref 写入与横幅 / 归因入单 / 多来源切换 / shareStats 推导数值 / ops-resellers 渲染 / orders 来源行 / 无 runtime errors；既有 73 用例不改断言必须继续全绿。


- Goal: 卖家仪表盘 → 选品 → 店铺管理
- Why now: 这是平台模式最核心的供给侧闭环；先验证页面分层与导航是否清晰。
- Acceptance criteria:
  - 每个页面是独立 HTML 文件，不依赖 tab 切换。
  - 页面间有真实链接：dashboard → catalog → store。
  - 共享视觉系统与侧边导航保持一致。
  - 选品页能看成本、售价、毛利、库存和质量评分。
  - 店铺页能看买家视角预览、已上架商品和分享入口。
  - 页面可直接打开，静态检查通过。
- Non-goals:
  - 本轮不实现买家结账、平台运营控制台、真实后端持久化。
  - 不修改旧的单页原型。
- Verification:
  - HTML 标签配平。
  - 页面链接目标存在。
  - 在浏览器打开 dashboard 并手动点击 catalog/store。


## Round 3 — seller conversion-to-cash slice
- Goal: 分享中心 → 订单履约 → 收益钱包
- Why now: 这条路径把熟人关系转成订单，再转成可提现收入，是平台商业模式的经营闭环。
- Acceptance criteria:
  - 三个页面独立存在，统一侧边导航与真实链接。
  - 分享页能生成场景化文案、显示触达和来源。
  - 订单页能展示履约时间线、SLA 风险和卖家反馈动作。
  - 钱包页能区分待结算、可提现、处理中，并有提现反馈。
  - 本轮页面无死链，HTML 标签配平。
- Non-goals:
  - 不接真实 WhatsApp、支付 API 或后端订单系统。
  - 不在本轮实现平台运营端。
- Verification:
  - 扫描所有本地 href 目标。
  - 浏览器手动走分享中心→订单→钱包。


## Round 4 — platform control-room slice
- Goal: 平台运营总览 → 货源目录 → 履约队列
- Why now: 平台需要把系统动力学里的订单、供给、产能、积压和 SLA 变成可执行的运营页面。
- Acceptance criteria:
  - 三个独立运营页面，统一运营侧导航与真实链接。
  - 总览同时显示订单、产能利用率、积压、信任/质量风险。
  - 货源页能看 SKU 成本、售价、库存、质量和推送策略。
  - 履约页能看订单状态、SLA 风险、产能提示和运营动作反馈。
  - 页面无死链，HTML 标签配平。
- Non-goals:
  - 本轮不实现卖家增长、信任质量和杠杆策略详页。
  - 不接真实仓库、物流或数据库。
- Verification:
  - 扫描所有本地 href 目标。
  - 浏览器从 ops-overview → ops-supply → ops-fulfillment 走一遍。


## Round 5 — platform decision-quality slice
- Goal: 卖家增长 → 信任质量 → 杠杆策略
- Why now: 运营端不能只看到供给与履约；还必须控制收入门槛、信任损耗和政策干预，才可以持续增长。
- Acceptance criteria:
  - 三页从占位替换为真实独立决策页，保留统一运营导航。
  - 卖家增长页显示激活/首单/留存/人均收入并提供针对性动作。
  - 信任质量页显示准时率、退货、投诉、SKU/卖家风险和处理动作。
  - 杠杆策略页把预期扩容、质量门槛、精选 SKU、圈层深耕变成可切换的政策操作和可见反馈。
  - 全目录无死链、HTML 标签配平；随后进行跨角色链路验收。
- Non-goals:
  - 不接真实支付、物流、卖家或用户数据。
- Verification:
  - 扫描本地 href 目标与页面结构。
  - 手动验证 seller → buyer → order → wallet 与 ops 控制室入口链。

## Round 13 — final prototype acceptance slice
- Goal: 对商业模式页与多页面产品路径执行最终静态 / DOM 接受检查，并把残余占位和验证边界记录清楚。
- Why now: 主要功能 slice 已完成；关闭 goal 前必须以当前文件和实测结果确认 Hub→CLD→SFD→BoT、buyer、seller 和 ops 路径，而不是依赖前几轮报告。
- Acceptance criteria:
  - 用户要求的核心页面文件全部存在。
  - 商业模式阅读路径、买家购买路径、卖家收益路径和运营路径的本地链接无死链。
  - 全部内嵌 JavaScript 通过 `node --check`。
  - DOM smoke test 覆盖支付成功、履约终态、提现反馈和店铺组件模板交互。
  - 当前残余占位、模拟边界和无法完成的浏览器级检查写入最终报告。
- Non-goals:
  - 不在最终验收轮新增业务功能或删除旧版原型。
- Verification:
  - 执行全目录链接、脚本、文件存在性和关键 DOM 路径检查。

## Round 12 — live demo runbook slice
- Goal: 为演示者提供一条不靠聊天记忆的 Mtaa 多页面走读脚本，并明确每一步应观察的业务反馈。
- Why now: 页面和交互已经分散在多个角色目录；没有一份短 runbook，演示容易跳页、漏掉支付 / 履约 / 收益状态，无法稳定复现完整路径。
- Acceptance criteria:
  - DEMO-GUIDE.md 明确入口、角色、点击顺序和每一步预期反馈。
  - 覆盖商业模式 Hub → CLD → SFD → BoT 和产品 seller / buyer / ops 路径。
  - 明确原型模拟边界和当前待优化项。
- Non-goals:
  - 本轮不新增页面、不改业务交互、不接真实服务。
- Verification:
  - 指南中的每个页面文件真实存在。
  - 全目录本地链接扫描仍为 0 死链。
  - 用 DOM smoke test 复核 buyer checkout、tracking、wallet 三个关键状态。

## Round 11 — prototype route-map slice
- Goal: 在多页面入口页同时暴露 seller、buyer、wallet 和 ops 的真实演示路径。
- Why now: 各页面已分别可打开，但入口页仍主要讲 seller 供给侧三页，演示者需要从一个入口找到完整的“开店 → 成交 → 履约 → 收益”和平台控制室路径。
- Acceptance criteria:
  - index.html 显示 seller conversion、buyer journey、platform ops 三条路径。
  - 每条路径按真实页面顺序提供可点击入口。
  - 说明哪些动作是原型模拟，不让用户误解为真实支付或物流。
  - 旧版单页原型和既有页面不删除。
- Non-goals:
  - 本轮不重写各页面内部交互，不接后端，不新增生产路由。
- Verification:
  - DOM 检查三条路径的链接顺序和目标存在。
  - 全目录本地链接扫描。

## Round 10 — order tracking progression slice
- Goal: 让买家在手机订单跟踪页推进并理解“已付款 → 打包中 → 配送中 → 已送达”的履约状态。
- Why now: 结账页已经提供支付成功和跟踪入口，但 track.html 目前是静态时间线；没有状态推进就无法演示平台履约如何把支付转成送达和信任。
- Acceptance criteria:
  - 手机跟踪页显示当前状态、下一步和履约时间线。
  - 点击推进动作后，状态按顺序进入配送中、已送达，并更新反馈文案。
  - 到达已送达后不再继续推进，显示复购 / 回到店铺入口。
  - 不依赖真实物流 API，刷新前状态保存在内存中即可。
- Non-goals:
  - 不接真实物流、地图、推送或订单后端。
- Verification:
  - DOM smoke test 验证状态顺序和终态。
  - track 内嵌脚本 `node --check`。
  - 扫描全目录本地链接目标。

## Round 9 — store builder interaction audit slice
- Goal: 验证并补强店铺装修页的任意组件编辑路径与三种模板结构差异。
- Why now: `store.html` 是卖家后台与手机店铺预览之间的关键 seam；用户要求任意组件都能选中编辑，且三个模板必须是真结构差异，不能只换文案。
- Acceptance criteria:
  - 任意商品、主视觉、信任承诺组件都可以被点击选中并显示编辑状态。
  - 添加商品链接和信任承诺后，组件进入列表并出现在手机预览。
  - 组件顺序、尺寸和分组改变后，预览和列表状态同步。
  - curated / festival / daily 三模板分别对应纵向精选、双列网格、清单式布局。
- Non-goals:
  - 本轮不接后端保存、不实现真正拖拽、不修改买家结账和运营控制室。
- Verification:
  - DOM smoke test 逐项操作任意组件、模板、添加、排序、尺寸和分组。
  - `store.html` 内嵌脚本执行 `node --check`。
  - 扫描全目录本地链接目标。

## Round 8 — seller earnings withdrawal feedback slice
- Goal: 把卖家订单履约后的“可提现 → 申请提现 → 处理中”状态在钱包页做成可演示交互。
- Why now: orders.html 已有订单状态和 wallet.html 入口，但钱包的提现主动作需要明确反馈，才能完成卖家从订单到收入的闭环。
- Acceptance criteria:
  - wallet.html 保持桌面卖家工作台布局，并显示移动钱包账户。
  - 点击“申请提现”后显示提现金额、目标账户、状态“处理中”和预计到账时间。
  - 按钮进入已提交状态，重复点击不产生重复申请卡片。
  - orders.html → wallet.html 的真实入口保留。
- Non-goals:
  - 不接真实 M-Pesa API、银行 API、身份验证或后端余额持久化。
- Verification:
  - wallet 内嵌脚本 `node --check`。
  - DOM smoke test 验证申请、反馈和防重复。
  - 扫描全目录本地链接目标。


- Goal: 打通买家手机端“结账 → 支付反馈 → 订单跟踪”这一条可演示路径。
- Why now: storefront、product、cart、track 页面已经存在真实入口，但结账页需要一个明确的支付成功反馈，才能证明移动货币动作确实产生了下一步结果，而不是静态展示稿。
- Acceptance criteria:
  - cart.html 在手机壳内提供清晰的移动货币主动作。
  - 点击支付后显示成功反馈、订单号、预计送达和订单跟踪入口。
  - 支付按钮重复点击不会重复插入反馈。
  - track.html 仍保留已付款、履约中、已送达等用户可读状态。
  - storefront → product → cart → payment feedback → track 的本地链接目标全部存在。
- Non-goals:
  - 不接真实支付 API、手机号验证、后端订单持久化或真实物流。
  - 本轮不修改 seller store builder 或运营控制室。
- Verification:
  - 所有内嵌脚本 `node --check`。
  - 扫描全目录本地链接目标。
  - 使用 DOM smoke test 验证支付按钮点击后出现成功反馈和 track 链接。

## Round 6 — business-model narrative path slice
- Goal: 把商业模式解释页串成可讲解的 Hub → CLD → SFD → BoT 阅读路径。
- Why now: 四张图已有内容，但页面主要是“返回枢纽/页脚跳转”，第一次阅读者缺少当前步骤、下一步和业务语言的导览；先补齐叙事路径，才能把系统动力学说明变成可演示的产品原型。
- Acceptance criteria:
  - Hub 明确一页纸商业模式、角色/钱货流和四步阅读入口，不增加验证表格。
  - CLD、SFD、BoT 顶部均显示阅读进度，并提供上一步/下一步真实链接。
  - 每页有业务语言的“怎么读”和“对平台意味着什么”提示。
  - Hub → CLD → SFD → BoT → Hub 可点击闭环，目标文件真实存在。
- Non-goals:
  - 本轮不重写图表模型、不修改旧版单页原型、不实现买家/卖家业务交互。
  - 不处理平台目录中尚未完成的移动端结账和店铺装修细节。
- Verification:
  - 扫描商业模式页本地链接目标并检查入口闭环。
  - HTML 标签配平；提取每页内嵌脚本执行 `node --check`。
  - 在窄屏静态检查导航不溢出，并从 Hub 走读到 BoT。