docs: 完成治理文档与执行合同收口（A1-A2,R1-R2,S1-S2,P9A1-P9D1）

2026-02-10 11:29:20 +08:00
@@ -0,0 +1,60 @@
+# ADR: 企业卡/虚拟卡管控能力预研
+
+- **状态**: Accepted (PoC 完成)
+- **日期**: 2026-02-10
+- **关联 Issue**: S1
+
+## 背景
+当前报销流程为“事后报销”。随着费用规模增长，管理层希望评估“企业卡/虚拟卡”是否值得投入，以降低垫资与票据补录成本，并与预算控制联动。
+
+## 决策目标
+1. 明确能力边界（做什么/不做什么）。
+2. 给出最小可实施数据模型草案。
+3. 评估与预算控制联动价值与 ROI。
+4. 提供可回滚路径。
+
+## 方案对比
+### 方案 A：不做企业卡，持续优化现有报销
+- 优点：实现成本最低，不引入支付清结算风险。
+- 缺点：员工垫资与票据补录问题长期存在。
+
+### 方案 B：只做“虚拟卡授权 + 交易对账导入”（推荐）
+- 优点：
+  - 可在现有 `integration_outbox` + `travel_orders` 机制上增量扩展。
+  - 与预算池可形成“事前授权 + 事后核销”闭环。
+  - 不直接改造核心审批状态机，风险可控。
+- 缺点：需要第三方支付/发卡通道，需处理对账延迟与异常交易。
+
+### 方案 C：自建完整企业卡账务系统
+- 优点：掌控力最强。
+- 缺点：投入和合规成本过高，不符合当前阶段。
+
+## PoC 结论
+- 使用 mock 交易流水模型验证：
+  - 交易导入 -> 预算池扣减 -> 报销关联核销 可形成闭环。
+  - 交易失败/重复导入可通过幂等键控制。
+- 关键风险：
+  - 外部支付通道 SLA 不稳定；
+  - 对账日切与本地时区差异；
+  - 退款/撤销的反向台账一致性。
+
+## 推荐落地范围（P8+）
+1. 新增 `card_transactions`（最小字段：external_txn_id、employee_id、amount、currency、occurred_at、status、raw_payload）。
+2. 新增 `card_authorizations`（预算池授权额度快照）。
+3. 与预算台账联动：
+   - 授权占用 `kind=authorize`
+   - 核销 `kind=settle`
+   - 撤销 `kind=reverse`
+4. 不在首期引入自动拒付策略，仅做预警与冻结建议。
+
+## ROI 粗评估
+- 假设月均 3000 笔差旅相关支出：
+  - 票据补录和对账人工可减少约 30%~45%。
+  - 财务月结周期可缩短约 1~2 天。
+- 若企业卡通道费率高于节省人工成本，建议暂缓。
+
+## 回滚策略
+1. 关闭企业卡开关（保留历史数据）。
+2. 停止交易导入任务与对外同步。
+3. 预算恢复到“报销提交时校验”模式。
+4. 历史交易只读归档，不做数据删除。
@@ -0,0 +1,58 @@
+# ADR: 移动端路线决策（PWA vs RN vs 小程序）
+
+- **状态**: Accepted (PoC 完成)
+- **日期**: 2026-02-10
+- **关联 Issue**: S2
+
+## 背景
+当前系统为响应式 Web。业务关注移动场景下的“离线拍照、弱网上传、回填状态可追踪”。
+
+## 决策目标
+1. 选择下一阶段移动路线。
+2. 验证离线拍照与上传可靠性。
+3. 输出成本、风险、回滚方案。
+
+## 备选方案
+### 方案 A：PWA（推荐）
+- 优点：
+  - 基于现有 React/Vite 体系，团队学习成本低。
+  - 可快速实现离线草稿、上传重试队列、安装到桌面。
+  - 与现有鉴权与 API 契约兼容。
+- 缺点：
+  - iOS 对后台同步和离线能力有限制。
+
+### 方案 B：React Native
+- 优点：
+  - 原生能力强，上传/相机/本地缓存控制更细。
+- 缺点：
+  - 双端构建链路与发布流程显著增加。
+  - 需要新增移动端测试与运维能力。
+
+### 方案 C：微信/钉钉小程序
+- 优点：
+  - 企业内推广成本低，触达快。
+- 缺点：
+  - 生态绑定强，跨平台复用差。
+  - 审核与平台能力限制较多。
+
+## PoC 结果
+- PWA 原型验证：
+  - 离线缓存拍照元数据可行；
+  - 网络恢复后自动上传成功率高；
+  - 异常重试与失败提示可在现有前端框架中快速实现。
+- RN 原型验证：
+  - 能力更强，但初期投入约为 PWA 的 2~3 倍。
+
+## 决策
+- **主路线**：PWA 优先。
+- **触发升级条件**：当离线强需求占比持续提升，且 PWA 在 iOS 场景无法满足 SLA 时，再升级 RN。
+
+## 分阶段实施建议
+1. P7：补离线草稿与上传队列（仅票据上传）。
+2. P8：补断点续传、失败重放、可观测埋点。
+3. P9：基于指标评估是否进入 RN 立项。
+
+## 回滚策略
+1. 保留 Web 主站能力，PWA 特性可通过开关关闭。
+2. 关闭 Service Worker 后回退到纯在线模式。
+3. 离线缓存可按版本清理，不影响服务端数据。