P3.5: prop-acc 启用子模块嵌套(adhoc/),应对大型业务域扩展

背景:
单纯按 UDAS 严格扁平,prop-acc/scenarios/ 装齐 7 子模块后预计 100-150
篇 .md 单一文件夹,Explorer 无法浏览、Quartz folder page 无法阅读。

扩展规则(已写入 SKILL.md 多域章节 + multi-domain.md 第 10 节):
- 单类型文件夹文件数 > 30 且能按业务子模块分组时,启用嵌套
- 路径:<domain>/<type>/<sub-feature>/<file>.md
- 文件名去 <sub-feature>- 前缀(路径已表达)
- title 三段式:<domain> · <sub-feature> · <名>
- frontmatter 新增 sub_feature 字段(便于 RAG 过滤)
- 跨子模块文档落在 <domain>/<type>/(不进子文件夹),与"跨域→cross/"对称

本次迁移:
- prop-acc/concepts/adhoc-*.md (3)  → prop-acc/concepts/adhoc/*.md
- prop-acc/scenarios/adhoc-*.md (25) → prop-acc/scenarios/adhoc/*.md
- 每个文件:title 加 adhoc 段、aliases 追加旧 prop-acc · 前缀形式(兼容)、
  新增 sub_feature: adhoc 字段

WikiLink 解析未受影响:
- 既有 [[场景-A流-...]] 等 200+ 引用通过 aliases (含旧 basename) 解析
- 新引用可用 [[adhoc · 前台购买 IC 卡]] 或 [[prop-acc · adhoc · 前台购买 IC 卡]]
- 各域 knowledge-map.md 内 WikiLink 全部仍有效

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

prop-acc/concepts/adhoc/flow-a-vs-flow-b.md

@@ -0,0 +1,86 @@
+---
+title: prop-acc · adhoc · A 流与 B 流
+aliases:
+  - prop-acc · A 流与 B 流
+  - A 流与 B 流
+  - 概念-A流与B流
+tags:
+  - 概念
+  - prop-acc
+  - 一次性收费
+  - 核心概念
+audience:
+  - 业户
+  - 业务人员
+status: 已发布
+sub_feature: adhoc
+last_review: 2026-05-25
+code_version: 2026-05-22
+---
+
+# A 流与 B 流
+
+一次性收费支持两条独立购买路径,**底层用同一套数据表**,差别只在用户怎么发起。
+
+## 一句话区别
+
+> [!tip] 通俗版
+> - **A 流**:您**到柜台**找物业阿姨,付了钱当场出货
+> - **B 流**:您**自己在小程序**下单,微信付完,过来取(或者送到家)
+
+## 对照表
+
+| 维度 | A 流(线下即收即付) | B 流(线上订单—支付分离) |
+|---|---|---|
+| **典型用户** | 老人、不会用手机的业户 | 年轻业户、工作日没空到前台的人 |
+| **触发动作** | 业户走到前台 | 小程序下单 |
+| **付款时机** | 当场付(现金 / POS / 微信扫码) | 下单时锁定金额、付款分离 |
+| **生效时机** | 即时 — 一笔操作完成所有 | 两步:下单 → 支付回调 |
+| **失败模式** | 几乎不可能(人在柜台) | 可能超时未付、可能支付掉单 |
+| **取消方式** | 走 [[场景-已收款作废\|作废]] 流程 | 改主意可主动撤;或超时自动作废 |
+
+## 系统视角(流程图)
+
+```mermaid
+sequenceDiagram
+    participant 业户
+    participant 前台
+    participant 小程序
+    participant 系统
+    participant 支付网关
+
+    Note over 业户,系统: A 流(线下即收即付)
+    业户->>前台: 我要买 IC 卡
+    前台->>系统: 录入业户、项目、金额、付现金
+    系统->>系统: 一气呵成:建事件 + 建订单 + 建收据
+    系统-->>业户: 打印 / 微信收据立马拿到
+
+    Note over 业户,支付网关: B 流(订单—支付分离)
+    业户->>小程序: 下单 IC 卡
+    小程序->>系统: 建事件(Pending) + 建订单(Pending)
+    系统-->>业户: 锁价格、给您订单号
+    业户->>支付网关: 微信付款
+    支付网关->>系统: 支付回调
+    系统->>系统: 更新订单(Completed) + 自动出收据
+    系统-->>业户: 小程序通知:已付款,可来取货
+```
+
+## 为什么要两套?
+
+> [!info] 业户视角
+> - 老人不会用小程序 → A 流照顾他们
+> - 年轻人不想跑前台 → B 流方便
+> - **同一项业务两种付款方式都能用**
+
+> [!info] 系统视角
+> 两套**共用同一张 `AdHocEvent` 表 + 同一张 `CollectionOrder` 表**。差别只在:
+> - A 流一气呵成创建后,状态直接 `Completed`
+> - B 流先创建为 `Pending`,等支付回调才翻 `Completed`
+>
+> 这种设计的好处是**跨渠道补缴**天然支持 —— 详见 [[场景-跨渠道补缴]]。
+
+## 看完去哪?
+
+- 想了解购买后系统记了什么 → [[概念-CollectionOrder与Receipt]]
+- 想了解订单的几种状态 → [[概念-AdHocEvent状态机]]
+- 想看真实例子 → [[场景-A流-前台购买IC卡]] 或 [[场景-B流-小程序下单+微信支付]]