docs(architecture): adopt authorized single-pass purchase

README.md

@@ -8,13 +8,14 @@
 ## 它做什么
 
 一笔外部订单进来，采购人员需要去拼多多找到同款、选对颜色尺码、下单、把订单号抄回系统。
-cmbuyer 把这个过程自动化，人只在两个点介入：**机器选对了吗**和**付不付款**。
+cmbuyer 把这个过程自动化：管理员明确“买什么、买多少、最多多少钱”并点击开始采购，系统只
+创建待付款订单，**是否付款始终由人决定**。
 
 ```text
 手工填链接（MVP）  ／  Excel · ERP（V2）
             │
             v
- 采购服务（admin/，Go）  建单 · 试选确认 · 下单授权 · 审计
+ 采购服务（admin/，Go）  建单 · 开始采购授权 · 围栏 · 审计
             │  HTTP
             v
 采购工具（client/，Python）  领任务 · 跑流程 · 回传
@@ -23,31 +24,22 @@ cmbuyer 把这个过程自动化，人只在两个点介入：**机器选对了
    Android 手机（拼多多 App）
 ```
 
-## 两趟执行
+## 单趟执行
 
-MVP 只做**任务自带商品链接**的情形，分两趟跑完：
+MVP 只做**任务自带商品链接**的情形：管理员先把任务保存为 `DRAFT`，再在表格中勾选并点击
+“开始采购（只创建待付款订单）”。该点击创建一次性授权，锁定商品、颜色、尺码、数量和最高总价。
 
-| 趟次 | 做什么 |
-| --- | --- |
-| **第一趟 · 试选** | 开商品 → 精确勾选颜色分类和尺码 → 读单价 → 截图 → **退出释放手机** → 回传 |
-| **人工确认** | 人在网页端看「机器选对了吗」→ 确认并**锁定单价** |
-| **第二趟 · 下单** | 重新开商品 → 重新选同一规格 → **三道价格闸门** → 提交订单一次 → 转「待付款」 |
-
-为什么分两趟：一台手机是瓶颈，不能停在规格面板上等人。代价是走两遍，换来手机不空闲，
-且第二趟能抓住价格变动。
-
-**三道价格闸门**：① 第一趟规格面板读价 ② 第二趟重读必须与授权价一致
-③ 订单确认页「实付款」不超上限。任一道读不到或不通过即停，转人工。
+采购工具领取后在同一次设备会话中完成：打开商品 → 精确选择规格 → 闸门一读 SKU 单价并校验
+上限 → 设置并复核数量 → 闸门二重读规格与同价 → 进入确认页 → 闸门三校验应付总额 → 服务端
+原子建立提交围栏 → 精确点击一次“提交订单” → 转待付款。中间不再回网页端等“机器选对了吗”。
 
 价格**只在规格面板和订单确认页读**——别处的价格文本被拆成多个节点、带券后前缀、
 实付价与原价混在一起，不可靠。
 
 ## 现在处于什么阶段
 
-**Phase 0 · 地基。仓库目前只有文档，尚未开始编码。**
-
-下一步：T-005（网页端 MVP 原型）与 T-006（桌面端 MVP 原型）的文件和自动检查已完成，
-请先人工确认 6 个 HTML 原型，再进入 T-001 / T-002 骨架和生产实现。
+**Phase 1 真机取证与 Phase 2 的安全服务端工作并行。** 两端骨架、基础模型、登录和真机基线已
+落地；T-111 正在冻结单趟采购契约，T-103 随后继续规格精确选择与读价，T-202 等待主审合入。
 详见 [`docs/current-state.md`](docs/current-state.md)。
 
 **生死线是 M2**：真机能按链接打开商品、精确勾选颜色分类和尺码、**读到该 SKU 单价**。
@@ -74,7 +66,7 @@ MVP 只做**任务自带商品链接**的情形，分两趟跑完：
 4. 规格按维度精确匹配，防前缀碰撞，找不到即停
 5. 数量设置后必须读回复核
 6. **三道价格闸门**，任一道读不到或不通过即停
-7. **第一趟绝不下单**——试选路径不得引用下单函数
+7. **能力分层**——T-103 规格验证路径不得引用数量、确认页或下单函数；后续能力逐段取证
 8. 检测到外部支付交接立即停止，不读取不保存凭据
 9. 检测到验证码 / 风控 / 人脸 / 短信校验立即停止，不绕过
 10. 只读非敏感摘要，不提取收货地址原文、手机号、支付凭据