X-Financial/document/development/2026-07-13/feature/ai-expense-closed-loop-and-value-proof/CONCEPT.md

# AI 费用闭环与价值证明 概念文档

更新时间：2026-07-17

文档路径：document/development/2026-07-13/feature/ai-expense-closed-loop-and-value-proof/CONCEPT.md

## 功能一句话

把申请、消费、票据、报销、审批、付款、入账、分析和持续学习连接成同一个费用事件，让员工少填表、审批人只处理例外、财务能确认真实节省，并让 AI 在可控边界内越用越准确。

## 背景与问题

- 当前现状：项目已经具备费用申请、AI 建单、票据夹、OCR、预算检查、风险预审、动态审批、员工画像、财务看板、知识库、Agent trace、反馈表和 few-shot 样本等较完整的功能骨架。容器运行时 OpenAPI 已覆盖 156 个业务操作，功能广度已经足够。
- 用户痛点：申请、票据、报销、审批和分析仍以多个页面、多个服务和多套状态存在。用户需要在不同入口之间理解系统，而不是由系统主动接住费用事件；移动端主流程仍有 mock；审批通过后的真实付款、回执、ERP 凭证和对账没有形成完整闭环。
- AI 痛点：当前系统能够记录会话、运行轨迹、风险反馈和员工画像，但没有统一记录“AI 建议了什么、用户改了什么、后来是否退回、最终是否付款或产生节省”。AI 能看到历史，却不能稳定把业务结果转化为下一次的个性化、自动化和风险校准。
- 企业痛点：现有看板主要回答花了多少、预算用了多少、发现了多少风险，尚不能可信回答省了多少钱、为什么省、哪些建议被执行、哪些费用仍可优化。
- 工程问题：旧 `ReimbursementRequest` 与当前 `ExpenseClaim` 能力重叠，申请与报销又复用部分字段和 JSON 标记；审批、预算、付款、归档和关系引用部分混入 `risk_flags_json`，不利于事务一致性、事件追溯和持续演进。
- 商业影响：如果不能持续证明处理效率、风险改善和真实节省，产品只能按“报销工具”定价；如果能形成价值闭环，则可以扩展为智能风控、预算经营、价值洞察和企业集成平台。
- 为什么现在需要做：现有模块已经足够支撑一条完整费用闭环，下一阶段继续横向新增页面会扩大编排和数据割裂。应先收口费用领域、业务事件、AI 决策、学习记忆和节省归因，再逐步开放自动化。

相关既有方案：

- `document/development/2026-07-03/feature/ai-data-flywheel/CONCEPT.md`：作为本功能的 AI 样本回流、评测门禁、Prompt 版本和 Canary 子能力，不重复建设。
- `document/development/AI意图规划器/UNIFIED_GATE_PIPELINE.md`：作为 AI 场景识别和后端唯一编排入口的架构前置，不在前端继续增加影子门控。

## 目标与非目标

### 目标

- [G1] 建立统一 `Expense Case`，把一次费用从需求表达、申请、票据、报销、审批、付款、入账到归档视为同一业务事件。
- [G2] 建立零录入报销体验，自动匹配申请、预算、票据、费用类型、项目、成本中心和历史偏好，让用户主要核对异常项。
- [G3] 建立按动作授权的安全自动化等级，从解释、建议、预填、可逆自动化逐步升级到低风险直通。
- [G4] 建立“AI 决策 → 用户反馈 → 工作流结果 → 分层记忆 → 再决策”的学习闭环。
- [G5] 建立节省机会、执行任务、实际结果和财务确认组成的 Savings Ledger，区分风险暴露、预计节省和已实现节省。
- [G6] 建立从描述性统计到异常归因、预算预测、供应商分析、政策模拟和节省任务的费用经营分析能力。
- [G7] 建立企业租户、用量计量、模型成本和客户价值指标，为年度订阅、用量超额和增值模块提供可审计基础。
- [G8] 保持高风险动作、资金支付、制度发布和敏感主数据变更的人为授权、审计和回滚能力。

### 非目标

- [NG1] 本轮不自建商旅、企业卡、银行或支付供应链网络，只定义标准连接器和业务事件契约。
- [NG2] 本轮不一次性替换所有现有报销接口；先建立统一费用事件和旁路事件账本，再分阶段迁移旧模型。
- [NG3] 本轮不做模型微调或无监督自训练，优先使用结构化反馈、few-shot、规则学习、Prompt 版本和回归门禁。
- [NG4] 本轮不允许 AI 无人值守执行资金支付、高风险批准/驳回、制度发布和收款账户变更。
- [NG5] 本轮不同时覆盖所有费用场景，首个试点只选择一个高频、可测量、可闭环的场景。
- [NG6] 本轮不做未经授权的跨租户学习和企业间明细 Benchmark；后续只允许严格聚合、隐私保护并获得授权的对标能力。
- [NG7] 本轮不把风险关联单据总额、暂缓付款金额或未采纳建议直接计为企业节省。

## 用户与场景

### 目标用户

1. 报销人/申请人：少填字段、少整理票据、少补件、少追问进度。
2. 审批人：只处理必要性、例外和高风险问题，快速获得证据与建议。
3. 财务运营：减少重复审核、退回、对账和月末整理，集中处理异常。
4. CFO/管理层：了解费用增长原因、预算趋势、节省机会和实际 ROI。
5. 风控/审计：查看规则依据、风险证据、算法版本、人工覆盖和审计结果。
6. 系统管理员/IT：配置租户、组织、权限、连接器、数据保留、模型成本和自动化上限。

### 使用入口

- AI 工作台自然语言入口。
- 统一费用事件详情页。
- 移动端拍票、报销和审批入口。
- 票据夹和自动票据收件箱。
- 审批例外工作台。
- CFO 费用价值看板。
- AI 记忆与自动化策略设置。

### 核心场景

1. 员工说“下周去上海出差三天”，系统自动生成合规申请、预算影响和可选节省方案，用户核对后提交。
2. 消费期间，邮箱发票、拍照票据、企业卡或商旅订单进入统一票据收件箱，系统按时间、金额、地点和商户自动归集到费用事件。
3. 行程结束后，系统自动生成报销草稿，只要求用户处理缺票、归属或异常金额。
4. 提交前，系统按事实、规则、证据和风险等级给出绿色通过、黄色修正、红色复核结果。
5. 审批人看到预算影响、历史相似单、政策依据、风险证据和建议意见，低风险单据进入快速通道。
6. 财务完成付款、回执、ERP 凭证和对账，所有结果回写费用事件并形成审计链。
7. 月末系统识别预算超支、供应商价格漂移、重复采购、异常路线和流程瓶颈，生成有负责人和目标金额的节省任务。
8. 用户修正字段、审批人覆盖建议、财务确认误报或节省结果后，系统更新用户、部门和企业记忆，下次减少重复操作。

### 异常场景

- OCR、模型、向量检索或外部连接器不可用时，回退到人工录入或稳定规则，不阻塞草稿保存和主链路。
- 票据、申请或费用事件匹配置信度不足时，只展示候选，不自动绑定。
- 企业规则与个人偏好冲突时，企业规则优先，必须解释冲突原因。
- 高风险、超金额阈值、敏感账户变更或证据不足时，强制人工确认。
- 自动化动作失败时必须幂等、可重试、可撤销，并保留错误状态和操作证据。
- 预计节省没有财务确认或实际结果时，只能标记为机会，不得计入客户 ROI。

## 功能能力

- [C1] 费用事件能力：统一表达申请、消费、票据、报销、审批、付款、入账和归档关系。
- [C2] 零录入能力：自动抽取并匹配申请、预算、票据、费用类型、项目、成本中心、参与人和历史偏好。
- [C3] 预审与修复能力：输出事实、规则、证据、判断和建议动作，并提供一键补件、修正和解释入口。
- [C4] 审批例外能力：风险分级、证据摘要、预算影响、推荐路由、意见草稿、批量处理、委托、转交、加签和超时升级。
- [C5] 支付入账能力：以连接器方式接收付款批次、支付回执、ERP 凭证、银行流水和对账结果。
- [C6] 学习记忆能力：记录 AI 建议、用户修改、审批覆盖、退回、付款和审计结果，形成用户、部门、企业三级记忆。
- [C7] 自动化策略能力：按动作、金额、场景、风险、置信度、证据、可逆性和抽检率配置自动化等级。
- [C8] 节省价值能力：把节省机会、建议动作、负责人、目标时间、预计节省、实际节省和财务确认形成闭环。
- [C9] 费用经营能力：费用结构、预算预测、异常归因、供应商分析、政策模拟、流程成本和客户 ROI。
- [C10] 商业计量能力：企业租户、套餐、配额、用量、模型/OCR 成本、增值模块、客户贡献毛利和价值证明。
- [C11] 状态与权限：服务端认证、租户隔离、角色权限、动作授权、审计日志和敏感数据保留策略。
- [C12] 边界与降级：外部依赖失败时主链路可用；高风险动作始终保留人工控制；所有学习与自动化可关闭、遗忘或回滚。

## 方案设计

### 前端

#### 统一费用事件

- 新增或重构费用事件详情容器，不再让用户理解申请单、票据夹、报销草稿、审批单和付款状态之间的内部关系。
- 页面按“计划 → 消费 → 报销 → 审批 → 付款/入账 → 复盘”展示时间线和当前待办。
- 每个 AI 填充字段显示来源、置信度和修改入口；低置信度字段集中进入“需要确认”区。
- 退回、补件和断点续办直接回到对应问题，不要求用户重新开始对话。

#### 零录入报销首个切片

- 用户在小财管家上传已完成 OCR 的票据并发送后，附件关联任务必须以当前租户、当前员工和 `Expense Case` 为边界，优先寻找已审批申请自动生成的可编辑报销草稿。
- 匹配信号首期使用费用事件关系、申请状态、票据日期、行程城市、费用场景和草稿状态；返回结构化分数、置信度和命中原因，不把模型自由文本作为授权依据。
- 只有唯一高置信候选允许自动归集。低置信、多个接近候选、申请缺少系统生成草稿、票据已属于其他单据或证据不足时，任务以 `requires_confirmation=true` 成功返回候选和异常，不修改任何报销单或票据关系。
- 自动归集成功后直接返回费用事件、申请、报销草稿、归集数量、跳过数量、风险项、缺失项和可解释原因；前端只展示完成结果或“需要确认”异常，不要求用户再次上传同一票据。
- 自动归集是 L3 可逆动作，只允许写入草稿、票据关系和业务事件；不自动提交、审批、付款或重建历史遗留申请缺失的草稿。
- 相同租户、用户、票据和目标草稿重试必须幂等；已归集到同一草稿的票据计入跳过数，不重复创建费用明细、附件或业务事件。

#### 移动端

- 把拍照、相册选票、报销列表、审批列表和 AI 助手接入真实后端。
- 支持离线拍票、失败重试和后台上传状态。
- 未实现能力必须隐藏或明确标为不可用，不保留无响应的主按钮。

#### 审批例外工作台

- 以风险、金额、预算影响、等待时长和证据完整度排序。
- 支持批量处理低风险事项，行内保留真实按钮和键盘可访问入口。
- 高风险审批展示模型版本、规则版本、政策依据、证据和人工覆盖原因。
- 正式审批任务切片由 `/api/v1/approval-tasks` 返回租户安全的数据库分页投影，优先级由风险、SLA、金额和证据完整度共同计算；任务保存节点进入时间、处理人、乐观版本、批量资格和权威动作集合。旧 `/approval-workbench/items` 仍可承担 advisory-only 摘要，但不再作为“待我审核”的业务动作事实源。
- 批准、退回和付款均使用动作协议：客户端在确认时冻结 `request_id`、预期状态和预期审批节点；服务端以租户 + 操作人 + 请求 ID 唯一账本、请求指纹、PostgreSQL advisory lock、Claim 行锁和同事务业务事件确保相同请求可安全重放，不同内容或陈旧快照以 409 拒绝。
- 高风险门禁同时读取持久化风险观察和尚未落表的原始风险标记；未处置的严重/高危可行动风险在路由、预算和状态修改前阻断，原始重大风险持久化失败时 fail-closed。仅明确标记为 `route_review` 的路由型风险进入对应审批节点而不冒充已解决。
- 门禁只消费与当前单据业务阶段一致的显式风险：申请阶段不会被明确标记为 `reimbursement` 的风险阻断，反之亦然；缺少阶段的未知重大风险仍保守处理。`route_review` 是显式路由语义，审批路由可以继续但风险仍保留在证据和后续复核中。
- 风险处置采用判定与生命周期双状态：支持确认风险、误报、补件、开始整改、申请豁免、财务/管理层批准或拒绝豁免，以及完成处置；每个动作绑定请求指纹、预期版本、操作人和只追加事件。申请人不得自批/自拒，仅在职 finance/executive 且非申请人可决定，过期申请 fail-closed。完整证据只对管理员或当前审批人开放，风险池对财务/管理/预算角色开放。
- 并发锁顺序固定为 Claim → RiskObservation → RiskDisposition，审批动作、人工处置和 Hermes 扫描共用 Claim 锁。扫描在锁外计算、锁内校验状态与更新时间，过期快照丢弃并等待下一轮，避免旧图结果覆盖刚完成的人工处置。
- 所有单据动作首次完整 API 响应写入动作账本；风险处置首次完整响应在 append-only 事件 INSERT 前原子写入。相同请求重放只返回首次版本，风险旧事件无快照时也只从目标版本及以前的审计链重建，不读取当前 Claim、当前处置投影或后续事件。
- 审批任务支持低风险批量通过、委托/撤销委托、永久转交、顺序加签、并行会签和手动/调度 SLA 升级；SLA 以当前节点进入时间为基准。前端“待我审核”完全消费服务端分页、筛选、`available_actions` 与版本，筛选和页码可从详情返回恢复。尚未完成的主要边界是统一必要性/政策证据摘要、真实企微/钉钉/邮件触达及外部结果回写。

#### CFO 价值看板

- 首页优先展示财务确认现金节省、已核验工时价值、安全智能直通率和重大风险护栏。
- 支持按部门、项目、费用类型、供应商、城市、时间和费用事件下钻。
- 每项节省可打开来源、基线、建议、执行、确认和去重证据。

#### AI 记忆与自动化设置

- 用户可以查看“系统记住了什么、为什么记住、在哪里使用”，并支持修改、忘记和关闭个性化。
- 企业管理员配置部门/企业记忆边界、有效期、敏感等级和自动化上限。
- 首个个人记忆切片只在申请核对表展示“常用出行方式”来源、证据数量和可编辑状态，并提供“忘记此偏好”；不在本轮新建大型设置页，也不把风险画像当作个人偏好。

### 后端

#### 费用领域与编排

- 新增 `ExpenseCaseService` 作为跨阶段编排入口，避免继续扩大万能 `ExpenseClaimService`。
- `ExpenseCaseService` 只负责阶段协调，申请、票据、报销、审批、支付、入账、记忆和节省由独立协作者负责。
- 复用统一 AI 场景注册与 LangGraph 编排，前端只按后端返回的 plan/action 渲染，不再增加业务门控。
- 零录入票据归集由独立匹配器计算候选和证据，由独立关联编排器执行可逆写入；后台 Job 只负责身份绑定、状态保存和结果投影，不继续堆评分、附件和事件逻辑。
- 票据存储命名空间必须至少包含租户与用户；后台任务查看和执行同时校验租户及用户，平台管理员也不能跨租户读取任务结果。

#### 业务事件与 AI 决策

- 所有关键动作写入 append-only `business_events`，使用 `correlation_id` 串联同一费用事件、Agent run、审批和外部连接器事件。
- 业务状态变更与对应 Outbox 事件必须在同一数据库事务中持久化；消费者按事件 ID 幂等处理，避免审计、学习和 ROI 数据因异步失败永久丢失。
- 只有画像刷新、分析聚合和消息通知等可重建派生任务允许异步失败并重试，不得把申请、提交、退回、审批、支付和入账事件降级为可丢弃旁路日志。
- 每个 AI 输出写入 `ai_decisions`，记录建议值、置信度、证据、模型、Prompt、规则、政策版本、风险等级和自动化模式。
- 用户接受、修改、拒绝或忽略写入 `ai_decision_feedback`；审批、退回、付款和审计写入 `workflow_outcomes`。

#### 记忆与学习

- `memory_entries` 支持用户、部门、企业作用域，以及 candidate/active/suppressed 状态。
- `memory_evidence_links` 保留记忆与业务事件、决策、反馈、结果的来源关系。
- 企业制度优先于部门基线，部门基线优先于个人偏好；冲突时返回解释。
- 复用既有 AI 数据飞轮的 few-shot、golden case、Prompt 版本、Canary 和回归门禁。
- 首个切片使用关系库精确键检索，只允许低敏枚举 `travel_application.transport_mode`；不复用当前缺少完整租户键的 FewShot/Qdrant 或员工风险画像存储个人记忆。
- 记忆证据只从认证动作事务中的服务端核验纠正产生，关联 Decision、Feedback、Outcome 和 Expense Case；草稿、客户端观察、重复请求和同一 Case 多次修改不能重复计票。
- 个人记忆只填充当前申请的空白软字段；当前明确输入、服务端 HR/组织主数据、企业制度和规则计算结果都优先于个人记忆。每次应用或抑制都返回可解释原因，不把优先级交给 Prompt 或 LLM 自行判断。
- 分层记忆首个组织级切片继续只允许 `travel_application.transport_mode` 的“飞机/火车/轮船”。企业记忆由租户管理员显式确认，部门记忆必须绑定稳定的 `organization_unit_id` 并只把部门名称作为展示标签；隐式证据暂只生成个人 Candidate，不允许少量个人行为自动升级为部门或企业制度。
- 分层解析顺序固定为“当前显式输入/规则禁用 > 企业记忆 > 部门记忆 > 个人记忆”。不同层值冲突时只应用最高优先级可用项，并返回候选层级、冲突值、未采用原因、有效期和衰减后置信度；不得静默覆盖当前输入，也不得把优先级交给模型自由判断。
- 管理员显式确认的组织记忆可直接激活，但必须记录创建人、确认来源、适用作用域和有效期；隐式个人记忆仍使用 3 个不同 Case、2 次审批通过、证据跨 7 天的最小样本门槛。组织记忆过期、撤销或服务异常时降级到下一层，不阻塞申请预览。
- 已确认历史案例接入报销预审前，`few_shot_samples` 与 Qdrant payload 必须补齐租户、业务场景、制度/规则标识、规则版本和 active 状态；每次向量命中还必须回关系库按租户和样本状态二次校验，样本改判时删除或稳定覆盖旧向量，禁止跨租户或陈旧结论进入提示。
- 历史案例只能输出结构化 `historical_case_evidence`，明确标记 `advisory_only`、人工确认结论、相似度、制度和版本是否匹配；它不得修改确定性预审的 `decision`、`passed`、`blocking_count`，不得改变预算复核和审批路由。旧版本只可作为降权参考，Qdrant 或 Embedding 不可用时返回空证据并继续规则链。

#### 节省与价值

- `savings_opportunities` 记录基线、风险暴露、建议动作、预计节省、负责人和截止时间。
- `savings_realizations` 记录执行结果、实际节省、财务确认人、证据、归因状态和去重键。
- 风险关联金额、暂缓付款和未采纳建议不得自动转为实际节省。

#### 连接器

- 定义统一 `ExpenseConnector` 协议，覆盖票据邮箱、税务验真、企业卡、商旅、支付、银行流水、ERP、HR、SSO、企微/钉钉。
- 外部事件必须具备幂等键、来源系统、原始事件 ID、发生时间、处理状态、错误码和重试次数。

#### 商业计量

- 以租户、套餐、模块和时间窗口记录模型、OCR、文档、分析任务、连接器与人工实施用量。
- 成本事件与客户价值事件分开记账，支持计算客户贡献毛利、实施成本摊销和私有部署成本。
- 套餐与配额只控制商业权益，不改变安全规则、租户隔离和高风险人工复核边界。

### 算法与规则

#### 自动化决策

- 自动化等级按动作计算，不按 Agent 整体授权。
- 动作风险、模型置信度、证据完整度、历史命中率、金额阈值、可逆性、企业上限和抽检率共同决定是否执行。
- L0 只读解释；L1 建议；L2 预填；L3 可逆自动化；L4 低风险直通；L5 资金支付和高风险决策始终保留人工。

#### 记忆激活

- 明确偏好后续可由用户认证确认后立即激活；首个切片只实现隐式候选，不把普通字段编辑冒充明确授权。
- 隐式出行方式偏好需要同租户、同员工、同场景和同归一化值的 3 个不同 Expense Case 服务端核验纠正，其中至少 2 个出现 `application_approved`，且首尾证据至少跨 7 天；同一 Case、重试、草稿续签只计一票。
- `accepted`、`client_observed`、`draft_saved` 和单纯 `application_submitted` 只能作为观察信息，不能单独激活；退回、反向纠正、结果 reversed 或制度冲突会抑制现有记忆。
- Candidate 默认 90 天有效，Active 默认 180 天；状态支持 `candidate / active / suppressed / expired / revoked`。相反值先抑制旧记忆并建立新候选，不原地覆盖；用户“忘记”后立即 revoked，清除可恢复值且不可自动复活。
- 错误标注、违规习惯、一次性例外、自由文本和敏感字段不能直接变为默认记忆。

#### 风险与预审

- 统一输出事实、规则、证据、风险、建议和可执行修复动作。
- 报销提交必须先完成服务端预审握手。预审结果至少包含稳定 `review_id`、输入指纹、规则集指纹、流水线版本、`ready / needs_fix / ready_with_review` 决策、结构化发现和修复动作；客户端不得仅凭旧的 `passed` 标记提交。
- 输入字段、明细、票据、风险事实或规则集发生变化时，旧预审自动失效并在提交事务内重算；同一输入和规则集重复预审复用相同 `review_id`，避免生成重复事件。
- 只有 high/critical 且 `fixable_by_submitter` 的未解决风险阻断提交；预算治理、领导判断和财务复核风险随单进入对应审批角色，不把所有高风险简单放行或全部拦截。
- `needs_fix` 必须在预算占用和 `claim_submitted` 之前阻断，保持草稿状态并返回 HTTP 409 结构化整改信息；可提交结果的预审事件与提交事件共享 correlation，并通过 causation 形成可追溯链路。
- 使用已确认正/负样本校准误报与漏检；规则或 Prompt 发布前运行 golden case。
- 新策略先进入 shadow，再 Canary，最后按动作开放自动化。

#### 费用分析与节省

- 描述性分析回答“发生了什么”；诊断分析回答“为什么”；建议分析回答“做什么”；价值闭环回答“是否执行并产生了多少结果”。
- 供应商、费用类型、城市、项目和部门基线必须保存数据窗口、样本量、算法版本和政策版本。
- 节省归因必须区分现金节省、可释放工时价值和不可货币化效率改善。

### 数据与契约

#### 核心数据对象

- `expense_cases`：统一费用事件和当前阶段。
- `expense_case_links`：连接申请、报销、票据、审批、付款、凭证和外部对象。
- `business_events`：append-only 业务事件账本。
- `ai_application_preview_decisions`：申请落单前由服务端重新规范化并短期签发的预览建议；不创建空 Expense Case，不保存建议明文，动作成功后一次消费。
- `ai_decisions`：结构化 AI 建议与版本证据。
- `ai_decision_feedback`：接受、修改、拒绝和忽略。
- `workflow_outcomes`：退回、补件、审批、付款、审计和最终结果。
- `memory_entries`：按租户、作用域主体、场景、字段和值指纹保存候选/激活/抑制/过期/撤销状态，只允许白名单低敏值可恢复。
- `memory_evidence_links`：把记忆与服务端 Decision、Feedback、Outcome、Expense Case 和业务结果关联；唯一键保证同一 Case 对同一候选最多计一票。
- `automation_policies` / `automation_grants`：动作级自动化策略和授权。
- `profile_baseline_snapshots`：持久化员工、部门、供应商、费用和流程基线。
- `savings_opportunities` / `savings_realizations`：节省机会和实现结果。
- `usage_meter_events`：租户、模块、模型、OCR、文档和分析用量。

#### 零录入附件关联任务契约

- 保留现有 `status`、`message`、`claim_id`、`claim_no`、`uploaded_count`、`skipped_count` 字段，追加字段保持前端向后兼容。
- 任务追加 `resolution`、`requires_confirmation`、`expense_case_id`、`application_claim_id`、`application_claim_no`、`confidence`、`confidence_score`、`match_reasons`、`exceptions`、`missing_fields`、`risk_items` 和 `candidates`。
- `status=succeeded` 只表示匹配流程完成；`resolution=auto_associated` 表示已经完成可逆归集，`resolution=requires_confirmation` 表示没有业务写入，需要用户选择候选或处理异常。
- 候选最少返回目标类型、费用事件 ID、申请 ID/编号、草稿 ID/编号、分数、置信度和命中原因；不得返回其他租户或当前员工数据范围之外的候选。
- `receipt_received` 和 `attachment_associated` 使用票据 ID 与目标草稿组成稳定幂等键，并与票据 Link、附件写入在同一数据库事务中完成；若文件存储写入失败，数据库事务回滚且任务进入失败态。

#### 最小事件词典

- `expense_case_created`
- `historical_claim_imported`：迁移前旧单的当前快照；只证明已纳入统一费用事件，不重建或伪造迁移前审批历史。
- `application_generated` / `application_submitted` / `application_approved`
- `application_pre_review_completed` / `claim_pre_review_completed`
- `receipt_received` / `receipt_verified` / `ocr_corrected`
- `field_suggested` / `field_accepted` / `field_edited` / `field_rejected`
- `attachment_associated` / `draft_saved` / `claim_submitted`
- `claim_returned` / `supplement_completed`
- `risk_flagged` / `risk_confirmed` / `risk_false_positive`
- `route_suggested` / `route_overridden`
- `claim_approved` / `payment_requested` / `payment_completed`
- `accounting_entry_created` / `reconciliation_completed`
- `saving_opportunity_created` / `saving_action_completed` / `saving_confirmed`

#### 状态枚举

- Expense Case：`planning` / `approved_to_spend` / `spending` / `claiming` / `reviewing` / `paying` / `accounting` / `closed` / `cancelled`。
- AI Decision：`suggested` / `accepted` / `edited` / `rejected` / `ignored` / `executed` / `rolled_back`。
- Memory：`candidate` / `active` / `suppressed` / `expired` / `revoked`。
- Automation：`explain` / `recommend` / `prefill` / `reversible_auto` / `low_risk_straight_through` / `human_only`。
- Savings：`identified` / `accepted` / `in_progress` / `realized` / `verified` / `rejected` / `expired`。

#### 兼容策略

- 迁移初期可用 shadow 事件校验现有 `ExpenseClaim` 的映射；某个状态一旦正式纳入事件模型，其业务写入与 Outbox 事件必须进入同一事务。
- 迁移前已有 `ExpenseClaim` 通过显式维护命令写入一条 `historical_claim_imported` 快照事件：事件发生时间使用真实回填时间，原创建、发生、提交和更新时间只进入内部 payload；`history_reconstructed=false`，不得按当前状态反推并伪造历史提交、审批或付款动作。
- 历史回填默认 dry-run，必须显式提供租户、创建时间边界和数据库目标；apply 还要求精确目标确认、迁移 head、advisory lock 和分批事务。稳定幂等键、源快照指纹、已有 Link 跳过及孤立 Event 冲突拒绝共同保证可审计重跑。
- 历史快照事件使用 `delivery_status=suppressed`，供时间线和分析读取，但不进入实时 Outbox 投递；用户态 API 仍只返回事件白名单，不暴露回填批次、源指纹、幂等键和投递状态。
- 旧 `ReimbursementRequest` 进入只读兼容和迁移状态，停止新增第二套业务编排。
- 现有 `risk_flags_json` 保持读取兼容，新审批、付款、归档和关系事件写入结构化表。
- API 新字段优先追加，不在同一阶段破坏现有前端契约。
- 从未成功签发 `decision_id` 的旧申请预览，或签发接口失败且服务端没有当前会话有效决策时，保存/提交继续走现有 `client_observed` 路径；当前会话一旦存在有效服务端决策，省略 `decision_id` 必须拒绝，不能主动降级绕过核验。兼容路径不得在用户已经编辑后把最终值反向登记成“原始建议”。
- 新预览使用 30 分钟有效的服务端 `decision_id`。保存草稿或提交成功后一次消费；保存草稿会尽力签发基于已保存事实的新 `decision_id`，供后续提交继续核验，但续签属于业务提交后的派生能力，续签失败不能把已成功保存返回为失败。相同动作请求 ID、动作和最终指纹允许安全重放，其他重放拒绝。
- AI 工作台、小财管家和通用 Orchestrator 的结构化申请预览统一复用服务端签发/消费工作流。小财管家签发失败时保持可编辑和可重试，但保存、提交必须 fail-closed，不再降级到旧 Orchestrator 副作用；只有没有结构化预览的历史消息保留旧兼容入口。
- Orchestrator 将已签发 decision 保存在服务端会话状态，后续保存/提交只消费该状态，不采信浏览器回传的 preview 或 decision。保存草稿返回的新 decision 继续写回会话，服务端消息中的结构化预览可在刷新或换端后恢复。
- 迁移桥接期集中维护 migration-owned 表集合；所有 legacy bootstrap 只能创建集合之外的表。标准启动在 `alembic upgrade head` 前只读核对 revision 与自有表集合，发现漂移时拒绝启动，不自动猜测、stamp 或修复。
- 所有表结构通过 Alembic 迁移，不继续在请求路径执行 DDL。

#### 版本与审计

- 事件记录 actor、tenant、source、run、model、Prompt、rule、policy 和 schema 版本。
- 记忆、自动化策略、规则、Prompt 和基线均支持 supersede、有效期和回滚。
- 高风险人工覆盖必须记录原因、证据和审批主体。

### 权限与安全

- 登录后签发服务端可验证会话或 JWT，服务端从会话和数据库解析用户、租户、角色和数据范围。
- 移除客户端 `X-Auth-*` 作为授权事实来源；管理面、Bootstrap、设置和模型连通性接口必须受平台管理员保护。
- P0 采用不透明 Bearer 会话：明文 token 仅在登录成功时返回，数据库只保存 SHA-256 摘要；每次请求从服务端会话和员工数据重新解析当前身份与角色，过期、撤销或不存在的 token 统一拒绝。
- Web 端只在 `sessionStorage` 保存 token 和过期时间，普通请求、流式请求及页面关闭收尾统一携带 Bearer；任一 `401` 触发本地会话清理，登出时会话指标与 token 撤销在同一事务完成。
- 已初始化系统的 Bootstrap 状态只返回脱敏信息，Bootstrap 写入、系统设置、模型连通性、缓存、审计与系统日志等敏感管理面由平台管理员权限保护；Vite 本地 Setup 桥在初始化完成后锁定重新配置入口。
- P0 数据契约即引入最小 `tenant_id`、数据库约束、行级过滤、向量库命名空间和对象存储前缀隔离；删除传播、数据导出和私有部署加固可在商业化阶段继续完善。
- Expense Case 用户态查询只返回流程摘要：Case 基础状态、关系类型、事件类型、操作人、发生时间及白名单业务载荷；不返回关联资源 ID、幂等键、correlation、causation、聚合标识或 Outbox 投递状态。有权查看入口单据的本人、当前审批人、财务和管理员可查看整 Case 的安全摘要，无权限与跨租户查询继续以 404 隐藏资源存在性。
- 申请预览签发与消费同时绑定 `tenant_id`、actor、Bearer 登录会话和会话 ID；动作入口按这些服务端事实锁行校验，不能只凭随机 UUID 授权。浏览器提供的模型来源、`finalValue`、用户和角色声明均不作为可信事实。
- 个人记忆主体优先使用服务端 `employee_id`，缺失时才使用规范化用户名；所有唯一键、读取、证据外键和忘记动作都必须以 `tenant_id` 开头。同邮箱或同员工号在不同租户形成完全独立的记忆。
- 记忆值采用 deny-by-default 白名单；首个切片仅保存规范枚举“飞机/火车/轮船”。事由、地点、日期、金额、客户/项目自由文本、附件、银行卡、收款人与支付账户均不得进入记忆明文、Prompt、向量 payload 或日志。
- 外部 `/orchestrator/run` 的用户消息、定时任务和系统事件都必须携带有效登录会话，不能由请求体中的 `source` 自行声明可信内部来源；其中 `schedule` / `system_event` 只允许平台管理员触发。服务端使用登录态覆盖用户、租户、角色、管理员、员工、审批人和调度操作人别名，并移除客户端 preview/decision 状态。最近会话查询与删除只使用当前登录用户和租户，查询参数中的 `user_id` 仅保留协议兼容，不参与授权。
- 预览与学习账本中的字段值使用独立、可版本化的费用申请密钥计算 HMAC-SHA256 指纹，密钥目录和文件权限分别为 `0700`、`0600`；核验旧决策必须使用其签发版本，缺失版本直接拒绝，不静默生成替代密钥。字段指纹同时编码“字段是否存在”，避免新增或删除字段被误判为采纳；训练资格仍保持关闭，直至审批、付款或人工核验闭环完成。
- 自动化权限按动作、金额、场景、风险和有效期授予，不使用全局“允许 Agent 自动执行”开关。
- 收款账户变更、资金支付、制度发布、高风险驳回和敏感主数据变更执行双人或更高等级复核。

### 降级策略

- LLM 不可用：回退到规则和人工填写。
- OCR 不可用：文件保留并进入待识别队列，用户可手工补录。
- Qdrant/few-shot 不可用：使用 stable Prompt 和基础规则，不阻塞主流程。
- 历史案例证据只返回固定的脱敏标签与摘要，不返回样本 ID、费用单号、人工评论或历史结论原文；它只能辅助复核，不参与确定性规则、阻断数量、预算复核和审批路由计算。
- 外部支付/ERP/税务连接器不可用：事件进入 retryable 状态，保留人工处理入口和幂等键。
- 记忆冲突或可信度不足：只展示建议，不自动应用。
- 结构化预览签发超时或不可用：允许继续编辑和重新签发，但保存、提交保持 fail-closed；只有不存在结构化预览的历史兼容入口保留原有降级路径，且只能记录 `client_observed` 行为证据。
- 记忆服务不可用、过期或校验失败：回退为“无个人记忆 + 当前规则”，不阻塞预览，也不读取跨租户、旧缓存或无租户向量样本。
- Savings 证据不足：保留机会状态，不进入已实现节省。

## 算法与公式

### 自动化资格分数

```text
automation_score
= w1 * model_confidence
 + w2 * evidence_completeness
 + w3 * historical_precision
 + w4 * reversibility
 - w5 * action_risk
 - w6 * amount_risk
```

变量说明：

- `model_confidence`：模型或规则对当前建议的置信度。
- `evidence_completeness`：发票、申请、预算、合同、订单和政策证据完整度。
- `historical_precision`：相同租户、场景、动作和版本的历史正确率。
- `reversibility`：动作是否可以无损撤销或回滚。
- `action_risk`：动作类型风险，支付和制度发布最高。
- `amount_risk`：金额相对企业阈值和历史基线的风险。
- `w1...w6`：按企业和动作配置的权重。
- 适用边界：分数只决定候选自动化等级，仍需满足企业硬性白名单、金额上限、抽检率和人审要求。

### 记忆激活置信度

```text
memory_confidence
= consistent_evidence_weight
 + outcome_success_weight
 + explicit_confirmation_weight
 - conflict_weight
 - age_decay
```

变量说明：

- `consistent_evidence_weight`：多次一致修改或选择产生的证据。
- `outcome_success_weight`：建议最终一次通过、付款或审计确认的权重。
- `explicit_confirmation_weight`：用户或管理员明确确认的权重。
- `conflict_weight`：与企业制度、部门规则或其他记忆冲突的惩罚。
- `age_decay`：记忆随时间衰减。
- 适用边界：敏感信息、一次性例外和违规行为不得依赖分数自动激活。

### 安全智能直通率

```text
safe_straight_through_rate
= qualified_completed_cases_without_manual_correction_or_return
 / eligible_completed_cases
```

分子还必须满足必要审批完成，且事后抽样审计未发现重大问题。

### 客户可验证 ROI

```text
verified_value
= verified_cash_savings
 + verified_releasable_labor_value

customer_roi
= (verified_value - customer_total_cost) / customer_total_cost
```

变量说明：

- `verified_cash_savings`：客户财务确认的重复支付阻止、超标准调整、采购或预算优化等实际现金节省。
- `verified_releasable_labor_value`：基于上线前后人工分钟、单据量和角色完全成本计算，并经客户认可的工时价值。
- `customer_total_cost`：订阅、用量、实施、集成和客户内部运营成本。
- 适用边界：现金节省和工时价值分开披露；风险暴露、未采纳建议和暂缓付款不得计入。

### 客户贡献毛利

```text
customer_contribution_margin
= subscription_revenue
 + usage_revenue
 + module_revenue
 + verified_savings_share
 - llm_ocr_storage_cost
 - third_party_cost
 - support_cost
 - amortized_implementation_cost
```

用于判断高收入但高度定制或私有部署客户是否实际盈利。

## 测试方案

### 后端

- Expense Case 状态机、关系绑定、幂等和非法状态跃迁单元测试。
- 历史 ExpenseClaim 回填的 dry-run 零写、租户/时间边界、快照真实性、批次回滚、冲突拒绝、重复执行和数据库目标防误连测试。
- Business Event、AI Decision、Feedback、Outcome、Memory、Automation Policy、Savings Ledger service 单元测试。
- 服务端会话、租户隔离、角色和动作权限的正向/越权测试。
- 连接器事件幂等、重试、回执、失败恢复和重复支付防护测试。
- Alembic baseline、升级、回滚边界和旧数据迁移测试。
- 现有报销、预算、风险、知识库和 Agent 回归测试。

### 前端

- 费用事件时间线、异常确认、断点续办和操作反馈视图模型测试。
- 移动拍票、上传失败恢复、真实列表和审批 mutation 测试。
- 审批例外工作台键盘操作、焦点管理和权限态测试。
- CFO 价值看板对预计/实际/确认节省的展示和下钻测试。
- AI 记忆查看、修改、忘记和关闭个性化测试。
- 生产构建、lint、typecheck 和浏览器关键流程测试。

### 算法与规则

- 自动化分数、硬阈值、金额上限、动作白名单和抽检策略测试。
- 记忆候选、激活、冲突、过期、撤销和污染样本测试。
- 风险规则、Prompt、few-shot 和 golden case 回归门禁测试。
- Savings 去重、基线、归因和确认状态测试。

### 集成

- 一句话申请 → 票据归集 → 自动报销 → 预审 → 审批 → 付款事件 → 入账 → 归档端到端。
- 持久开发库只读流式克隆 → Alembic 升级 → 历史回填 dry-run/apply/重复 apply → 服务端登录 → 旧单时间线查询 → 持久库不变验证。
- AI 建议 → 用户修改 → 退回/通过 → 记忆候选 → 下次建议变化闭环。
- 常用出行方式 1/2 次纠正保持候选，第 3 个不同 Case 且至少 2 次审批通过、跨 7 天后激活；当前输入覆盖、跨租户拒绝、忘记后不再预填。
- 风险命中 → 人工确认/误报 → few-shot → 新版本回放 → Canary/回滚闭环。
- 节省机会 → 负责人执行 → 实际结果 → 财务确认 → ROI 看板闭环。
- 多租户同名员工、同号单据、向量检索和对象存储隔离测试。

### 容器验证

所有后端、集成、数据库迁移和外部依赖验证必须在项目容器内执行，单条测试命令最大超时 60s：

```bash
docker exec -w /app -e SERVER_VENV_DIR=/tmp/x-financial-server-venv \
  x-financial-local-linux \
  /tmp/x-financial-server-venv/bin/pytest -q server/tests/test_expense_case_service.py
```

如果本地 Compose 使用不同容器名，先通过 `docker ps` 确认当前主应用容器，不得改为宿主机直接运行后端测试。

### 手工验证

- 在真实容器页面完成申请、拍票、报销、退回补件、审批、付款和价值看板流程。
- 检查每个 AI 建议是否能展示来源、置信度、修改结果和后续业务结果。
- 检查用户能否查看、修改和忘记 AI 记忆。
- 检查高风险动作无法绕过人工，低风险可逆动作能够撤销和回放。
- 检查每项实际节省能够追溯到基线、建议、执行、确认人和证据。

## 指标与验收

以下目标在缺少真实客户基线前均为首轮试点的方向性目标，正式数值必须在试点基线采集后冻结。

- [A1] 全流程验收：任一费用事件可以从申请追溯到票据、报销、审批、付款、凭证、归档、AI 决策和节省结果。
- [A2] 体验指标：首个试点场景报销创建时间 P50 目标不超过 60 秒。
- [A3] 自动化指标：可结构化字段的自动填充率方向性目标不低于 85%，且字段修改率持续下降。
- [A4] 质量指标：首次提交完整率方向性目标不低于 90%，退回率和每单人工触点低于试点基线。
- [A5] 智能指标：AI 字段采纳率、重复纠正率、建议接受率和记忆复用成功率可按租户、场景、版本统计。
- [A6] 风险护栏：重大风险漏检率、误报干扰率、人工覆盖率和抽样审计结果可计算；自动化提升不得以护栏恶化为代价。
- [A7] 价值指标：每项节省区分机会、预计、执行、实现和财务确认；客户月度 ROI 可回放。
- [A8] 商业指标：早期可计算付费试点转年度合同率、持续产生可验证价值的客户率和按客户贡献毛利；成熟后计算 NRR。
- [A9] 性能指标：同步页面接口 P95、AI 预填 P95、OCR 队列等待、后台任务恢复和连接器重试达到试点 SLA，具体阈值在基线后确定。
- [A10] 安全指标：客户端无法伪造管理员、跨租户访问返回拒绝、敏感动作具备二次授权和审计。
- [A11] 可观测性：每个费用事件、AI 决策、工具调用、连接器事件、自动化执行和失败重试使用统一 correlation ID。
- [A12] 工程验收：相关后端定向测试、前端测试、lint、typecheck、构建和端到端验证在容器事实环境中通过。

## 风险与开放问题

### 风险

- 范围过大：费用闭环、AI 学习、价值分析和商业化不能同时全量实现，需要按 P0/P1/P2 阶段交付。
- 领域模型迁移：旧 `ReimbursementRequest`、`ExpenseClaim` 和 JSON 状态并存，必须旁路记录、小步迁移和双读校验。
- 历史证据边界：旧单快照只表达回填时可确认的当前状态，迁移前逐节点办理过程仍以原单据和既有审计为准；后续分析不得把快照事件误当成历史审批事实。
- 认证和租户：当前客户端身份头不适合自动化和 SaaS，多租户、记忆和高风险动作开发前必须修复。
- 会话运维：不透明会话已经替代客户端身份头，但仍需补充定时清理、活跃会话查看/全部退出、密钥轮换策略、登录限流和企业 SSO；当前 `tenant_id` 仍是最小契约，不代表跨租户查询守卫已经完成。
- Agent 会话租户边界：Orchestrator 与 Steward 动作运行时都把可信 `tenant_id` 写入会话状态；创建、恢复、幂等检查点重放、单条删除和批量删除同时校验租户与用户名，同名用户不能跨租户复用 decision 或动作结果。历史无租户状态的会话在认证入口 fail-closed，不会被恢复或删除。`agent_conversations` 仍缺少独立 `tenant_id` 列和数据库复合约束，后续迁移需要把当前应用层守卫下沉为结构化租户键。
- 费用事件读取边界：用户态精简 DTO 和首批 HTTP 权限测试已完成；剩余风险是同一 URL 若已有外部客户端依赖旧内部字段会产生契约变更，且未来新增敏感 payload 字段必须继续显式进入白名单，不能恢复任意字典透传。
- 反馈投毒：一次点击或违规习惯不能直接成为记忆，需要候选态、最小样本、制度约束和结果权重。
- 记忆值恢复：现有学习账本只保存 HMAC 指纹，无法恢复具体偏好值；必须由独立记忆表在认证事务中只提取白名单枚举，不能为了复用把自由文本重新塞回账本。
- 记忆与制度冲突：首个切片的三种交通方式当前均只有估价和舱等规则，没有“禁止某种交通方式”的制度维度；后续一旦增加按职级、路线或金额禁用交通方式的规则，必须先提供服务端允许性判定、抑制原因和回归用例，再允许个人记忆参与预填。
- 自动化失控：高准确率不代表高风险动作可以无人值守，必须按动作授权并支持 shadow、Canary、抽检和回滚。
- 虚假节省：风险暴露金额、暂缓付款和工时估算容易被夸大，必须由客户财务确认并执行去重。
- 外部依赖：税务、支付、银行、商旅、ERP 和消息平台连接器存在可用性、资质和交付周期风险。
- 移动端成熟度：拍票基础已有，但主业务仍有 mock，必须先完成真实登录、列表、草稿和审批闭环。
- 成本失控：高频 LLM、OCR、向量检索和私有部署可能降低毛利，需要按租户和模块计量成本。
- 数据稀疏：本地开发库缺少报销、反馈、风险和 golden 样本，正式目标必须来自真实试点而不是演示数据。

### 已处理依赖

- 已有预算、票据夹、OCR、报销草稿、风险规则、审批路由、知识库、员工画像、Agent trace、few-shot 和财务看板可复用。
- 已有 AI 数据飞轮概念与阶段 1 few-shot 实现，不重复建设样本检索底座。
- 已有统一门控管道设计，可作为 AI 场景收口依据。

### 待确认

- 首个目标客户规模和部署形态：中小 SaaS、中大型企业 SaaS 或集团私有部署。
- 首个 90 天付费试点场景：差旅报销、业务招待、日常费用或预算风控。
- 是否进入企业支付、商旅预订或公司卡领域；如果不进入，应明确聚焦 AI 费控与经营分析。
- 客户是否接受工时价值进入 ROI，以及对应角色完全成本口径。
- L3/L4 自动化允许的动作、金额阈值、抽检率和授权主体。
- 税务验真、银行、ERP、企微/钉钉等连接器的首批合作范围。
- SaaS 定价的员工档位、包含用量、超额计价和增值模块边界。

### 降级策略

- 首期只选择一个费用场景做完整闭环，其他场景保留现有流程。
- 正式切换前允许 shadow 事件用于一致性校验；正式切换后的关键业务状态与 Outbox 事件必须原子提交，失败时整体回滚并向用户返回可重试状态。
- 画像刷新、分析聚合、消息通知等可重建派生任务失败时进入重试/死信队列，不阻塞已成功提交的关键业务状态。
- 自动化默认停留在 L1/L2，只有试点评估和风险护栏通过后才逐项开放 L3/L4。
- 外部连接器未完成前保留人工导入、确认和对账入口，但状态语义和审计事件按正式契约记录。

## 本轮实现记录

- 2026-07-16（审批任务正式化）：新增 `approval_tasks` 与 append-only `approval_task_events`，报销提交、批准、退回和下一节点推进统一生成/完成任务。支持数据库分页筛选、可解释优先级、当前节点 SLA、委托/撤销、转交、顺序加签、并行会签、手动/调度升级、独立事务批量部分成功、乐观版本和不可变幂等响应；历史回填默认 dry-run。
- 2026-07-16（风险豁免决定）：豁免申请新增范围、条件与到期时间，只有在职 finance/executive 且非申请人可批准或拒绝；过期 fail-closed。风险变更在同一事务刷新开放审批任务的风险、证据、批量资格和优先级，不重置 SLA 窗口；前端展示完整追加审计链并在到期时刷新权威投影。
- 2026-07-16（审批工作台接入）：单据中心“审核单”切换到 `ApprovalTaskWorkspace`，移除旧 Claim 预览列表和静态“批量通过 23 条”提示。工作台提供真实批准、退回、委托、转交、加签、会签、升级和批量动作；未筛选 pending 摘要与队列筛选结果分离，详情返回恢复任务筛选/页码，相同负载安全重试、编辑负载自动换新幂等键。
- 2026-07-16（阶段验证）：容器内相关后端 `122 passed, 4 skipped`、前端审批/单据中心/风险专项 `60 passed`、Ruff 与 Vite 构建通过；一次性 PostgreSQL 17 空库迁移循环 `1 passed`、审批任务和风险并发 `3 passed`。完整前端套件未新增真实回归，仍有 31 项既有陈旧断言/质量债待后续硬化阶段清理。
- 2026-07-16（审批动作协议）：批准、退回和付款统一接入租户化幂等账本、请求指纹、乐观状态/节点前置条件、advisory lock 与 Claim 行锁；完全相同的网络重试不重复扣减预算、写审批、生成事件或付款，不同内容和陈旧状态稳定返回 409。前端确认流在用户确认时冻结请求和前置条件，并保持服务端状态与展示标签分离。
- 2026-07-16（风险门禁与处置）：高危/严重可行动风险在任何审批副作用前阻断；类型化风险处置覆盖确认、误报、补件、整改、豁免申请和完成处置，具备乐观版本、权限守卫和只追加审计。门禁合并持久观察与未匹配原始风险，重大观察落库失败 fail-closed；审批、处置和 Hermes 扫描通过 Claim 公共锁协调，扫描过期快照不会覆盖新事实。
- 2026-07-16（审批工作台）：审批中心接入可解释优先级投影，展示风险、预算、金额、等待时长、证据完整度和 advisory-only AI 建议；风险证据卡读取真实持久字段、显示生命周期和明确动作，但不提供绕过风险门禁的直接审批入口。
- 2026-07-16（审批与风险验证）：容器内审批/风险/费用服务组合 174 项、迁移/所有权 54 项、前端 73 项及 Vite 生产构建通过；一次性 tmpfs PostgreSQL 17 完成 13 项迁移和 1 项真实并发验证，临时数据库自动清理且持久开发库未修改。变更 Python 文件 Ruff F/I 与 `git diff --check` 通过。
- 2026-07-16（严格响应重放）：修复审批和风险动作只保证副作用幂等、却在重放时返回当前投影的问题。审批账本保存完整 `ExpenseClaimRead`；风险 append-only 事件通过 `20260716_0012` 保存完整处置响应。单据或风险后续推进后，旧请求只返回首次快照和当时事件，不暴露后续状态；历史无快照事件按目标版本安全重建。门禁同步增加申请/报销阶段匹配和显式 `route_review` 路由语义。容器内审批、费用 Case、路由、风险和严格重放组合 182 项通过，一次性 PostgreSQL 17 迁移与并发共 17 项通过。
- 2026-07-16（分层组织记忆）：`travel_application.transport_mode` 已形成当前输入/规则 > 企业 > 部门 > 个人的解析链。租户管理员可维护 30-365 天有效的企业/部门低敏记忆；同级冲突 fail-closed，低级覆盖、过期和撤销均返回可解释但脱敏的状态。创建、更新、撤销使用作用域锁、稳定幂等键和请求指纹，响应丢失可安全重放，请求内容变化返回冲突。
- 2026-07-16（租户化历史案例）：风险观测、人工反馈、few-shot 关系数据和 Qdrant 向量统一绑定租户、场景、制度和规则版本；Hermes 按租户分别构建图与历史，风险规则生成不再回落到默认租户。报销预审与 AI 助手接入只读 `historical_case_evidence`，旧版本显式标 stale，检索故障降级为空证据。
- 2026-07-16（历史证据隐私边界）：公开协议仅返回“历史已确认/历史误报，仅供复核”的固定摘要，不暴露样本 ID、费用单号、人工评论和历史结论原文；历史命中不改变 review ID、规则 findings、passed、blocking count、预算复核或审批路由。
- 2026-07-16（分层学习验证）：容器内分层与组织记忆 44 项、历史案例/风险/预审/规则生成 90 项、报销接口与费用服务 137 项、Golden 与历史注入 28 项、迁移/模型/租户组合 70 项通过；前端 18 项和 Vite 生产构建通过。一次性 tmpfs PostgreSQL 17 完整迁移循环 9 项通过，临时容器自动清理且开发数据库未修改；变更 Python 文件 Ruff F/I、compileall 与 `git diff --check` 通过。
- 2026-07-16（P0 提交前预审握手）：新增稳定预审决策契约、输入/规则/动态 findings 指纹和结构化整改动作；申请与报销提交前均由服务端重新计算完整风险上下文，可整改重大风险在预算占用前返回 409，握手期间风险变化返回 `PRE_REVIEW_CHANGED`，预算治理和人工判断风险继续进入领导与 P8。
- 2026-07-16（P0 费用事件续接）：新增 `application_pre_review_completed` / `claim_pre_review_completed` 时间线语义，预审与提交共享 correlation/causation；票据归集完成后刷新预审，申请批准生成空报销草稿时 Expense Case 保持 `approved_to_spend`，首张票据归集后再进入 `claiming`。
- 2026-07-16（租户与路由修复）：AI 草稿、申请预览、Steward 和差旅测算透传真实租户；Claim 核心访问和关联草稿后台任务按 CaseLink 与服务端租户隔离；仅未整改的人工判断/预算治理高风险申请进入同部门 P8，已解决风险不再重复升级。
- 2026-07-16（结构化风险回填）：409 findings 保留原始 source、business stage、risk domain 与 actionability，前端即使详情刷新失败也能生成可见整改卡，不再被 `ai_pre_review` 汇总过滤规则丢弃。
- 2026-07-16（工程拆分）：提取申请关联、职级标准调整、预审端点、风险清单指纹与租户查询范围职责，所有本轮触及的核心服务、端点和前端提交模块均回到 800 行硬上限以内。
- 2026-07-16（验证）：容器内费用服务与审批路由 126 项、费用事件/接口/租户/票据关联 63 项、报销接口全量 20 项和前端预审/时间线 24 项通过；Vite 生产构建、Python compileall、关键未定义符号检查与 `git diff --check` 通过。

- 2026-07-13：完成产品能力、端到端费用旅程、AI 学习飞轮、KPI 和商业模式分析，形成总功能概念文档。
- 2026-07-13（规划阶段）：只沉淀功能规划，没有修改业务代码、数据库结构或现有接口。
- 2026-07-13（P0 基础切片）：新增 `ExpenseCase`、`ExpenseCaseLink`、`BusinessEvent` 模型与 `ExpenseCaseService`，提供 `/api/v1/expense-cases/by-claim/{claim_id}` 时间线查询接口。
- 2026-07-13（P0 基础切片）：草稿、提交、退回、审批、申请转报销、付款和申请归档开始旁写结构化事件；事件具备租户字段、correlation、causation、幂等键和待投递状态，并与业务状态在同一事务提交。
- 2026-07-13（事务修复）：关联申请归档/解绑的内部审计改为 `flush`，由外层业务事务统一提交，避免审计日志提前提交付款或归档状态。
- 2026-07-13（迁移桥接）：新增第一条 migration-owned schema revision；服务启动先执行 Alembic，旧 `create_all` 明确排除三张迁移表。完整历史 schema baseline、正式数据库 upgrade/rollback 和停止旧 DDL 仍未完成。
- 2026-07-13（验证）：容器内新增测试与既有差旅主链路回归共 24 项通过；Alembic PostgreSQL upgrade/downgrade 离线 SQL、启动脚本语法、OpenAPI 路由和新增文件静态检查通过。未对持久化开发数据库执行迁移。
- 2026-07-13（P0 认证安全切片）：新增 `AuthSession` 不透明 Bearer 会话及 `20260713_0002_auth_sessions.py`，登录 token 只返回一次、数据库只保存摘要；`/auth/me`、会话结束和登出均从服务端会话解析身份，登出与使用指标收尾原子提交。
- 2026-07-13（管理面收口）：移除生产代码中的 `X-Auth-*` 授权来源，保护 Settings、模型连通性、缓存、员工、分析、Agent 运行/轨迹、风险观测、审计及系统日志；已初始化 Bootstrap 返回脱敏状态并拒绝匿名重配置，Vite Setup 桥同步锁定。
- 2026-07-13（前端会话）：Web 请求、流式响应和页面关闭收尾统一使用 Bearer，token 与过期时间只保存在 `sessionStorage`，集中处理 `401`、空闲过期和服务端过期；业务经理不再被前端视为平台管理员。
- 2026-07-13（认证验证）：容器内认证/Bootstrap/费用事件/OpenAPI 定向测试 21 项通过，受保护业务端点回归 13 项通过，全量测试收集 805 项成功；前端会话、请求、Setup 锁和权限测试 17 项通过，生产构建通过。迁移仅生成并检查 upgrade/downgrade 离线 SQL，未写入持久化开发数据库。
- 2026-07-13（P0 提交一致性补缝）：AI 新建费用申请并直接提交时，先持久化为草稿，再统一委托 `ExpenseClaimService.submit_claim`；提交校验、预算预占、申请提交风险标记、`application_submitted` 事件和审批状态不再由 AI 入口分别维护。
- 2026-07-13（事务边界修复）：预算表运行时就绪检查改为复用当前 Session 连接，避免通过 Engine 执行 metadata 检查时隐式提交已 `flush` 的申请；即使预算预占后 Expense Case 事件写入失败，申请、预算额度、预算流水、预占和 Case 数据也会整体回滚。
- 2026-07-13（提交一致性验证）：容器内 AI 申请直接提交、失败回滚、保存草稿副作用、申请提交主链路及预算/Expense Case 回归共 21 项通过，`ruff --select F,I` 通过；未修改数据库结构，未对持久化开发数据库执行迁移。
- 2026-07-13（P0 前端时间线）：申请/报销详情在原有横向进度下接入真实 `/api/v1/expense-cases/by-claim/{claim_id}`，新增稳定排序、中文事件语义、状态迁移、退回原因、操作人和发生时间展示；未知事件使用通用文案，不暴露 correlation、幂等键或 Outbox 投递状态。
- 2026-07-13（前端兼容与验证）：单据切换时清空旧时间线并通过请求序列防止乱序覆盖；未纳入 Expense Case 的 404 显示非阻断兼容态，其他接口错误支持重试且不影响原有进度与单据操作。容器内 99 条定向前端测试和 Vite 生产构建通过。
- 2026-07-13（P0 用户态事件契约）：Expense Case 响应收口为 Case 基础状态、关系类型和事件安全摘要，事件载荷采用递归白名单；关联单据 ID、聚合信息、幂等与关联链、Outbox 投递字段及未知嵌套内部字段不再通过用户接口返回。
- 2026-07-13（P0 草稿事件补缝）：AI 工作台与小财管家新建/更新费用申请草稿分别写入 `claim_draft_created` / `claim_draft_updated`；租户从服务端身份透传，事件、Case、Link 与草稿同事务提交，失败整体回滚。动作幂等组合租户、操作人、run ID 与稳定草稿快照：完全相同的 HTTP 保存重放复用同一草稿和事件，并发竞争由稳定聚合 ID 与数据库主键仲裁，同一 run 内的真实内容变化仍保留独立事件。
- 2026-07-13（AI 申请身份边界）：申请预览快速入口不再接受请求体中的 `user_id`、管理员标记、角色、员工编号或其他身份字段作为授权事实，全部强制绑定服务端会话；伪造管理员身份编辑他人退回申请会返回 400，且原申请与费用事件不发生变化。
- 2026-07-13（安全与事务验证）：容器内受影响后端定向回归 36 项、Expense Case 前端兼容测试 9 项和 Python `ruff --select F,I` 通过；覆盖本人、当前审批人、财务、管理员、无权限、跨租户、整 Case 安全摘要、草稿新建/更新、失败回滚、HTTP 创建重放、相同快照去重、不同快照留痕、Steward 重放及伪造身份越权。未修改数据库结构，未执行持久化开发数据库迁移。
- 2026-07-13（联调边界）：当前持久化开发数据库尚无 `auth_sessions`、`expense_cases`、`expense_case_links` 和 `business_events` 表，浏览器登录无法获得有效认证凭证，因此本轮未声称完成真实页面端到端联调，也未擅自执行数据库迁移。计划、消费/票据、入账、对账和复盘事件仍待后续补齐。
- 2026-07-14（迁移所有权加固）：新增统一 `schema_ownership.py`，七个运行时初始化入口只创建 legacy 表；标准启动在 Alembic upgrade 前执行只读漂移预检，revision 与 migration-owned 表集合不一致时 fail-fast，且不会自动 stamp 或修改数据库。
- 2026-07-14（真实迁移验证）：在主应用容器连接的一次性 tmpfs PostgreSQL 17 中完成空库升级、重复升级、关键约束/索引、真实外键级联、降级到 base、legacy 哨兵保留、无版本自有表漂移拒绝和再次升级，`test_alembic_migrations.py` 4 项通过，最终 revision 为 `20260713_0002`；临时容器已自动清理，持久化开发数据库复查仍未迁移。
- 2026-07-14（剩余边界）：当前两条 revision 只覆盖 Expense Case、Business Event 和 Auth Session，完整 legacy schema baseline 及停止其余运行时 DDL 仍未完成；本轮受影响服务回归 46 项通过，既有员工目录历史部门归一化用例仍单独失败，未混入本次迁移安全范围。
- 2026-07-14（历史旧单接入）：新增独立 `ExpenseCaseLegacyBackfillService` 和 `backfill_legacy_expense_claim_cases.py`。命令只读取显式 `DATABASE_URL`，默认 dry-run；apply 强制目标核验、精确确认、迁移 head、advisory lock 和批次事务。每张旧单只创建一条 `historical_claim_imported` 系统快照，保留源时间和指纹、明确不重建历史，并以 `suppressed` 阻止实时投递。
- 2026-07-14（克隆库联调）：将持久开发库以只读 `pg_dump` 流式恢复到一次性 tmpfs PostgreSQL 17，原 40 张表、4 张费用单、105 名员工、248 条预算和 62 个 Agent 资产完整保留。升级到 `20260713_0002` 后首次 dry-run 识别 4 张旧单，apply 创建 4 组 Case/Link/Event，重复 apply 创建 0 条；隔离后端完成登录、`/auth/me`、旧单时间线 200 和登出，内部回填字段未出现在 API。临时数据库和隔离进程已清理，持久库复查仍为原数据签名且没有 migration-owned 表。
- 2026-07-14（安全复核与质量验证）：交叉审查后补齐超长租户幂等键稳定哈希、Link/Case 租户一致性、孤立 Case 冲突、URL 路由参数覆盖防护和部分批次失败进度摘要；前端将快照语义明确为“纳入时状态/节点”。容器内 65 项后端定向测试、11 项前端测试、Ruff 和 Vite 生产构建通过。全库代码体积门禁仍被本次未修改的 `RiskRuleGenerationService` 807 行存量问题阻断，未混入当前功能提交。
- 2026-07-14（AI 行为闭环首个切片）：新增 `AIDecision`、`AIDecisionFeedback` 和 `WorkflowOutcome` 三类独立事实，把申请预填建议、用户确认或显式字段纠正、草稿保存或申请提交结果通过稳定 `decision_id` 关联。只有已认证的申请预览快速入口显式传入服务端 `CurrentUserContext` 时才写账本；通用 User Agent、模板预览和单据详情编辑路径均不写入，避免伪造身份和非 AI 操作污染样本。
- 2026-07-14（字段纠正与隐私边界）：申请表编辑器在当前会话中维护首次建议值与最终显式编辑值，多次修改保留最初建议，改回原值会移除差异；日期调整同时记录 `time` 与派生 `days`。服务端最终值始终从解析后的申请 facts 重建，不信任客户端 `finalValue`；持久化层只保存字段名和带密钥版本的 HMAC-SHA256 值指纹，不复制事由、地点、人员、金额等原始值，原始对话、Prompt、模型全文、附件和支付敏感信息也不进入学习账本。
- 2026-07-14（可信度边界）：浏览器编辑轨迹仍标记为 `verification_status=client_observed`、`trust_level=behavioral_analytics_only` 且 `training_eligible=false`，只能用于受限产品统计；服务端签发预览消费后提升为 `server_verified`，仅证明“服务端签发快照与最终业务事实的差异已核验”，不证明浏览器声称的模型来源，也仍不直接训练模型、自动放行风险或激活企业记忆。
- 2026-07-14（事务与一致性）：学习三表与申请、预算及 Business Event 使用同一 Session，在最终 commit 前 `flush`，失败整体回滚；提交场景通过提交服务的事务内回调关联真实 `application_submitted` 事件。Case、Business Event 和 Decision 使用包含 `tenant_id + expense_case_id` 的复合外键，既拒绝跨租户，也拒绝同租户跨 Case 串联。前端估算使用消息级请求版本和输入指纹，只合并估算派生字段，旧响应不会覆盖后续编辑。
- 2026-07-14（0003 迁移与验证）：新增 `20260714_0003_ai_learning_loop.py`，三张学习账本表纳入集中迁移所有权；AgentRun 与旧 ExpenseClaim 保持带索引软引用以兼容空库迁移顺序。一次性 tmpfs PostgreSQL 17 的升级、重复升级、跨租户/同租户跨 Case 外键拒绝、降级和再次升级 4 项通过；容器内学习账本、入口边界和迁移所有权定向 29 项，日期联动及异步估算关键场景 5 项通过。持久开发库只读复查仍为 `40|4|105|248|62`，7 张 migration-owned 表数量为 0。
- 2026-07-14（服务端预览决策）：新增认证的 `POST /api/v1/reimbursements/application-previews`。服务端从原始申请文本和当前登录身份重新解析字段、重跑规则测算，再签发 30 分钟有效的 `decision_id`；浏览器返回的模型来源和建议值不被直接认证。预览绑定租户、actor、登录会话和 conversation，字段只保存独立版本密钥生成的 HMAC 指纹；字段存在性也纳入指纹，新增、删除和改值都能由服务端识别。
- 2026-07-14（消费与续签）：快速保存/提交显式携带动作类型、`decision_id` 和稳定请求 ID。服务端锁行校验后，在 Claim、Expense Case、Business Event、AIDecision、Feedback、Outcome 的同一事务中一次消费；当前会话已有有效决策时禁止省略 ID 降级。保存草稿提交成功后再尽力签发基于服务端事实的新 `decision_id`，续签失败只返回无新 ID，不反转已成功业务动作；相同请求安全重放不会重复建单或重复写学习账本。
- 2026-07-14（0004 迁移与验证）：新增 `20260714_0004_ai_application_preview_decisions.py`，预览决策表和正式 Decision 复合租户外键纳入集中迁移所有权。一次性隔离 PostgreSQL 17 完整 upgrade、重复 upgrade、约束/索引、downgrade 和再次 upgrade 4 项通过；容器内新增决策安全用例 9 项、旧快速保存/提交 4 项、申请学习账本 9 项、迁移与所有权 26 项通过且条件型 PostgreSQL 用例 1 项跳过，3 组前端定向测试及 Vite 生产构建通过。持久开发库只读确认 8 张 migration-owned 表数量仍为 0。
- 2026-07-14（多入口统一决策闭环）：抽取 `ExpenseApplicationPreviewWorkflow`，认证签发、锁行消费、动作幂等、学习落账和草稿续签不再由 HTTP 端点重复编排。Steward、小财管家结构化预览和通用 Orchestrator 均复用该工作流；用户纠正字段后仍消费原始 decision，使服务端能够把建议值与最终业务事实记为 `server_verified` 接受或纠正证据。
- 2026-07-14（Orchestrator 身份与会话边界）：外部用户消息、定时任务和系统事件统一强制认证，`schedule` / `system_event` 进一步要求平台管理员；登录态覆盖请求中的身份、租户和调度操作人别名，堵住匿名或普通用户伪造来源触发 Hermes 管理任务的路径。会话创建、恢复和删除同时绑定可信租户与用户名，历史无租户状态会话 fail-closed。申请 decision 只从服务端会话恢复，客户端 preview/decision 在进入编排前被移除；保存草稿后的 next decision 回写会话并支持刷新/换端恢复结构化预览。
- 2026-07-14（小财管家 fail-closed）：完整预览展示前先使用稳定 request ID 签发 canonical decision；签发失败时允许继续编辑和以同一 ID 重试，但禁止保存/提交且不回退旧副作用链路。保存/提交失败重试复用稳定 action request ID，保存成功同步草稿信息与 next decision。
- 2026-07-14（decision 生命周期加固）：同一租户、用户、登录会话、conversation 和 HMAC 快照即使使用不同签发 request ID，也复用当前 active decision，避免多个并行 decision 命中草稿幂等捷径后遗留未消费状态。动作发现 decision 过期、已消费或不可用时，前端清空旧 ID、生成新的签发 request ID 并开放重新签发。
- 2026-07-14（跨租户检查点加固）：Steward 动作会话创建显式写入服务端租户；租户 A/B 即使使用相同用户名、conversation 和 trace，也会获得独立会话与 decision，不再跨租户返回幂等结果或敏感预览内容。
- 2026-07-14（统一闭环验证）：容器内服务端预览、Steward 动作/图运行、Orchestrator 外部来源授权及决策消费组合回归 50 项通过，Python Ruff F/I 通过；前端结构化动作、会话恢复、工作台路由、富确认和动作脚本共 18 项通过，Vite 生产构建通过。并行读取用户正在变动的规则工作簿曾触发 `openpyxl` ZIP 句柄竞争，相关套件改为串行后全部通过，未修改规则工作簿。
- 2026-07-14（个人出行方式记忆）：新增租户化 `memory_entries` 与 `memory_evidence_links`，首个切片只存储 `travel_application.transport_mode` 的“飞机/火车/轮船”。同一租户、员工、场景和值需要 3 个不同 Expense Case 的服务端核验纠正、至少 2 个当前审批通过且证据跨 7 天才激活；Candidate/Active 默认有效期分别为 90/180 天。
- 2026-07-14（证据信任边界）：记忆证据严格绑定当前 tenant、actor、employee、Case owner 和 Claim owner，并要求 Decision、Feedback、Outcome 指向同一申请、同一 Case 和同一个真实 `application_submitted` 业务事件；事件聚合必须是对应 `expense_claim`。同 Case 重放、invalidated/reversed 事实、最新退回、反向纠正和非白名单纠正不会继续支持 active 记忆。
- 2026-07-14（应用、抑制与遗忘）：个人记忆只补空白出行方式，任何当前显式值都优先。命中后服务端重新计算交通与总额估算再签发 canonical decision；记忆异常降级为无记忆，不阻塞预览。反向或非白名单纠正抑制 active，用户忘记后状态改为 revoked、清空可恢复值和指纹，旧请求不可复活。
- 2026-07-14（前端记忆解释）：申请核对表新增独立 `TravelReimbursementMemoryPanel`，展示已应用的常用出行方式、证据数量、学习回执和“忘记此偏好”入口；本地会话快照支持跨刷新恢复，忘记偏好不会篡改当前申请字段。
- 2026-07-14（个人记忆验证）：容器内个人记忆专项 16 项、记忆/预览决策/迁移/所有权组合回归 56 项通过且 1 项条件跳过、前端申请与记忆组合 83 项通过；一次性 PostgreSQL 迁移循环、Ruff、Vite 生产构建和 `git diff --check` 均通过。当前规则中心尚不存在交通方式禁用维度，制度冲突守卫作为后续规则扩展的前置门禁保留，不以恒真占位判断冒充已实现。
- 2026-07-16（零录入票据首个闭环）：附件后台任务从“大而全”的内存编排中拆出只读 `ExpenseReceiptMatcher` 与可逆 `ExpenseReceiptAssociationService`。系统按当前租户、员工、Expense Case、已审批申请、票据日期、城市、路线和场景选择草稿；只有唯一高置信草稿自动归集，低置信、多候选、无草稿及仅有申请时均以需要确认的安全终态返回并保持零业务写入。
- 2026-07-16（事务、幂等与租户边界）：票据 Link、`receipt_received`、附件写入和 `attachment_associated` 由同一关联编排器提交，数据库快照与文件目录备份共同补偿中途失败，事件或文件元数据异常时恢复 Claim/Case/Link/Event/票据及旧附件目录；相同票据任务按租户、owner 和票据集合持久去重。票据目录加入无碰撞租户摘要，任务、候选 Claim 和票据同时绑定租户与本人，平台管理员也不能跨租户读取任务。
- 2026-07-16（持久任务与并发）：新增 migration-owned `attachment_association_jobs` 和 `20260716_0006`。任务状态、结构化结果、owner 上下文、attempt、租约与 generation 写入数据库；GET 可恢复 queued 或租约过期任务，`attempt_count + running` 作为栅栏阻止旧 worker 或迟到回调覆盖新终态。同票据和同 Claim 分别使用进程锁与 PostgreSQL advisory lock 串行化，Claim 锁内清理旧事务并重新匹配，避免不同票据并发选择同一空明细。待确认或失败任务保留原代历史，再次发起创建新 generation 并重新评估；已自动关联成功的代际继续幂等复用。评分改为纯只读查询，每份票据必须独立达到最小证据，避免无关票据被同批强证据带入。
- 2026-07-16（小财管家交互与验证）：任务结果新增 Case、申请、置信度、原因、异常、缺失项、风险项、候选和草稿载荷；前端可跨会话恢复，自动完成直接查看草稿，仅申请候选查看申请，待确认不伪装成功；幂等重放显示“已关联”，成功结果仍展示风险和复核要求。容器内后端归集专项 20 项、归集与相邻服务/迁移所有权组合回归 71 项、前端关联链路组合回归 29 项、Ruff F/I/UP 和 Vite 生产构建通过；一次性 tmpfs PostgreSQL 17 的 0006 完整迁移循环 4 项通过并已清理，持久开发库未修改。既有大型报销服务与接口套件仍存在旧审批、删除和风控断言失败，未把这些基线问题误报为已解决。
- 2026-07-16（保留边界）：预算、项目、成本中心和个人记忆偏好尚未接入票据候选评分；任务已持久化并支持租约恢复，但尚未建设独立消息队列、运维重试面板和死信治理；完整 G2 与平台级异步任务治理仍未完成。
- 2026-07-17（费用价值闭环）：新增 Savings Ledger、CFO 价值分析和财务确认/冲回链路；现金、工时、风险暴露和预计机会严格分账。住宿标准调整从服务端锁定原金额创建机会，付款/生产连接器回执产生 actual realization，独立财务确认后才进入现金 KPI，退款以负向追加事实冲回。
- 2026-07-17（财务连接器）：建立配置生命周期、HMAC、防重放、事件幂等、对账、ERP 入账、退款/冲回、operational event 和 mock/test/staging 隔离。端到端以本地自签的 production-mode 事件验证申请、票据、报销、预审、审批、回执、ERP、归档、Savings 与商业价值契约；它不代表真实银行/ERP 回执，模拟回执也不会改变核心财务事实。
- 2026-07-17（真实发布遥测）：规则发布从真实 observation、可信 disposition/reviewer label、独立盲审负样本和保守 recall 进入 Monitor/Guard；collecting、积压、聚合失败或低 precision 均不晋级并保持 stable。0023 提供 audit sample、双人票、append-only 和 PostgreSQL 并发保护。
- 2026-07-17（商业闭环）：新增套餐、订阅、账期、权益、配额、用量、成本、ROI、毛利和定价走廊；中央 Orchestrator、Runtime Chat、OCR、金融连接器和附件源文件写入按权威数量预占、结算或释放，客户价值、平台收入和内部成本不混账。
- 2026-07-17（全链租户安全）：新增 0025-0028，统一 Tenant、Employee、Claim、Agent Asset、Knowledge、Ontology、Hermes、Finance Report、Qdrant、文件和缓存作用域；ONLYOFFICE 改为数据库一次性会话与 SSRF/重放保护。审批员工解析按认证企业或结构化 Claim 企业首层过滤，跨租户身份和相同名称不再命中。
- 2026-07-17（工程收口验证）：176 个后端测试文件在主应用容器内分片或专项通过，费用主服务 121 项通过；fresh PostgreSQL 迁移/并发总探针 `87 passed / 0 skipped / 0 failed`，head 为 0028；Web 全量 `815 passed / 0 failed` 与 Vite build 通过；Mobile lint/typecheck、197 个新增 Python 文件 Ruff、目标 compileall、受门禁核心类/组件 800 行检查和 `git diff --check` 通过。
- 2026-07-17（完成边界）：工程代码和容器验收已收口；生产 ONLYOFFICE DNS/TLS、备份副本迁移演练、逐租户 SMTP、真实 provider/会计规则、移动/浏览器实机联调、30/90 天企业试点、客户财务签字和合同定价仍必须使用目标环境与真实业务证据完成，不能由 mock 或本地测试替代。总验收见 `document/development/2026-07-17/feature/engineering-closure-and-production-readiness/`。