feat: 财务看板口径重构与半年模拟数据及报销状态注册表

- 重构 finance_dashboard 口径计算，新增模拟公司画像数据生成与筛选
- 引入 expense_claim_status_registry 统一报销状态流转
- 完善报销草稿流程、Item Sync 与本体解析器
- 优化总览页趋势图、分页组件与请求进度步骤
- 增强报销申请快速预览、本体工具与详情展示
- 新增半年报销模拟数据种子脚本与状态审计工具
- 补充财务看板、报销状态注册与模拟数据测试覆盖

document/development/半年报销模拟数据/CONCEPT.md

@@ -0,0 +1,154 @@
+# 半年报销模拟数据概念文档
+
+## 功能一句话
+
+为本地演示环境生成 2026 年上半年公司报销、预算和员工组织样本，让财务看板与预算中心能直接呈现半年经营分析效果。
+
+## 背景与问题
+
+当前容器数据库已有员工与预算基础表，但报销样本很少，无法观察半年维度的费用趋势、部门支出结构、预算使用率和风险预警效果。用户希望把公司人数扩充到 100 人，并模拟半年报销数据，用于查看整体分析和预算管控效果。
+
+现状只读检查结果：
+
+- `employees=82`
+- `expense_claims=3`
+- `budget_allocations=240`
+- `budget_transactions=241`
+- `risk_observations=0`
+- 尚无 `SIM2026` 员工、`SIM-EXP-2026` 报销单和 `SIM-BUD-2026` 预算数据。
+
+## 目标与非目标
+
+目标：
+
+- 把本地演示公司员工补齐到 100 人，不删除已有员工。
+- 生成 2026 年 1 月到 6 月的报销单、报销明细和风险观察样本。
+- 生成或复用预算额度，并写入预算核销台账，让预算中心能看到真实使用率、预警和超支。
+- 保证脚本默认 dry-run，只有显式 `--apply` 才写数据库。
+- 生成完成后能用容器内 DB 统计和真实 API 返回值验证。
+
+非目标：
+
+- 不接入真实生产 API，不导入真实个人敏感数据。
+- 不删除或重置用户已有数据；如未来需要清理模拟数据，应另走显式确认。
+- 不改造预算中心、财务看板和报销审批页面结构。
+- 不把模拟数据写入启动流程，避免每次启动自动膨胀数据。
+
+## 用户与场景
+
+- 财务负责人：查看半年费用趋势、待审批金额、风险数量和 SLA。
+- 预算管理者：查看部门和费用科目的预算使用率、预警线和剩余额度。
+- 产品演示者：用 100 人组织规模演示智能费控、预算中心和分析看板的联动。
+
+## 功能能力
+
+### 输入
+
+- 目标员工数：默认 100。
+- 模拟窗口：默认 `2026-01-01` 到 `2026-06-30`。
+- 随机种子：固定值，确保样本可复现。
+- 执行模式：默认 dry-run，`--apply` 写入数据库。
+
+### 输出
+
+- 新增员工：只补齐缺口，员工编号前缀 `SIM2026`。
+- 新增报销单：编号前缀 `SIM-EXP-2026`。
+- 新增明细：按报销单生成 1 到 3 条费用明细。
+- 新增预算额度：编号前缀 `SIM-BUD-2026`，按部门、季度、费用科目覆盖差旅、招待、办公和通信。
+- 新增预算交易：编号前缀 `SIM-BTX-2026`，对已通过、待付款、已付款和完成状态写入 `consume` 台账，对待审批状态写入 `reserve` 台账。
+- 新增风险观察：编号前缀 `SIM-RISK-2026`，用于财务看板风险混合和异常数统计。
+
+### 边界
+
+- 如果员工数已经大于等于 100，只新增 0 人，不删除已有员工。
+- 如果同编号模拟数据已存在，脚本跳过，保证重复执行不重复膨胀。
+- 预算使用率通过交易台账计算，不直接改写预算余额字段。
+- 预算超支样本允许存在，用于展示预算效果和预警，但需要控制比例，避免所有部门都显示异常。
+
+## 方案设计
+
+### 后端脚本
+
+新增独立服务模块：
+
+- `demo_company_simulation_seed.py`：封装模拟数据规划、dry-run 统计和 apply 写入。
+
+新增命令脚本：
+
+- `seed_half_year_expense_demo.py`：解析参数并调用服务模块。
+
+### 数据策略
+
+- 组织：复用现有 `OrganizationUnit`，优先使用部门节点和成本中心。
+- 员工：补齐到 100 人，按部门规模权重分配，职级覆盖 P3-P8。
+- 报销单：按员工、月份、费用类型生成，低频员工 1-2 单，高频角色 4-8 单。
+- 风险：约 12%-18% 的报销单带风险标记和 `RiskObservation`。
+- 预算：按部门、季度、科目创建模拟预算额度，Q2 相比 Q1 有 8%-18% 增长，部分市场、技术部门科目接近 80% 预警线。
+
+### 运行命令
+
+```bash
+docker exec -w /app -e SERVER_VENV_DIR=/tmp/x-financial-server-venv x-financial-main \
+  /tmp/x-financial-server-venv/bin/python server/scripts/seed_half_year_expense_demo.py
+```
+
+写入时使用：
+
+```bash
+docker exec -w /app -e SERVER_VENV_DIR=/tmp/x-financial-server-venv x-financial-main \
+  /tmp/x-financial-server-venv/bin/python server/scripts/seed_half_year_expense_demo.py --apply
+```
+
+## 算法与公式
+
+### 员工缺口
+
+$$
+new\_employees = \max(target\_employees - current\_employees,\ 0)
+$$
+
+### 报销金额
+
+每类费用按基础金额、部门系数、职级系数和月度季节系数生成：
+
+$$
+claim\_amount = base\_amount(type) \times dept\_factor \times grade\_factor \times month\_factor \times noise
+$$
+
+### 预算使用率
+
+预算中心沿用现有计算口径：
+
+$$
+usage\_rate = \frac{reserved\_amount + consumed\_amount}{original\_amount + adjusted\_amount} \times 100
+$$
+
+### 风险样本概率
+
+风险概率按金额分位和预算压力提升：
+
+$$
+risk\_probability = base\_risk + amount\_boost + budget\_pressure\_boost
+$$
+
+## 测试方案
+
+- 单元测试：在 SQLite 内存库里验证 dry-run、员工补齐、幂等写入和预算交易统计。
+- 容器验证：在 `x-financial-main` 内运行定向测试，单次不超过 60s。
+- 运行时验证：执行 dry-run 后检查计划数量；执行 apply 前必须人工确认。
+- API 验证：写入后请求财务看板和预算汇总接口，确认 JSON 中员工、报销、预算使用率和风险指标有数据。
+
+## 指标与验收
+
+- 员工总数达到 100。
+- `SIM-EXP-2026` 半年报销单不少于 300 单。
+- 预算汇总接口返回 Q1、Q2 趋势，且至少有 1 条预算预警。
+- 财务看板 `has_real_data=true`，风险数、费用分类、部门排行和预算摘要均非空。
+- 重复执行脚本不会新增重复模拟数据。
+
+## 风险与开放问题
+
+- 批量写入数据库属于高风险操作，执行 `--apply` 前必须获得用户明确确认。
+- 如果当前数据库已有大量非模拟员工，脚本不会删除员工来凑精确 100 人，只保证不少于目标数。
+- 财务看板趋势接口当前最多按 90 天标签解析；半年分析主要依赖预算中心 Q1/Q2 趋势和自定义日期范围。
+- 如果后续要支持页面一键生成，需要另行设计权限、审计和清理机制。

document/development/半年报销模拟数据/TODO.md

@@ -0,0 +1,23 @@
+# 半年报销模拟数据 TODO
+
+## 调研与契约
+
+- [x] [CONCEPT: 背景与问题] 读取员工、报销、预算和财务看板现有模型，确认模拟数据要写入 `employees`、`expense_claims`、`expense_claim_items`、`budget_allocations`、`budget_transactions`、`budget_reservations` 和 `risk_observations`。
+- [x] [CONCEPT: 背景与问题] 在 `x-financial-main` 容器内完成只读规模检查，当前员工 82 人、报销单 3 单、模拟前缀数据为 0。
+- [x] [CONCEPT: 方案设计] 明确脚本默认 dry-run，批量写入必须使用 `--apply` 并先得到用户确认。
+
+## 数据生成
+
+- [x] [CONCEPT: 数据策略] 新增模拟数据服务模块，封装员工、预算、报销、明细、风险观察的生成逻辑。证据：`demo_company_simulation_seed.py` 与 `demo_company_simulation_catalog.py`。
+- [x] [CONCEPT: 输入] 新增命令脚本，支持 `--target-employees`、`--start-date`、`--months`、`--seed`、`--apply`。证据：`seed_half_year_expense_demo.py`。
+- [x] [CONCEPT: 边界] 实现幂等逻辑：已存在的 `SIM2026`、`SIM-EXP-2026` 和 `SIM-BUD-2026` 数据不重复创建。证据：`test_half_year_simulation_preview_and_apply_are_idempotent`。
+- [x] [CONCEPT: 预算使用率] 通过 `BudgetTransaction` 和 `BudgetReservation` 形成预算使用效果，不直接改余额。证据：`test_half_year_simulation_feeds_budget_summary`。
+
+## 验证
+
+- [x] [CONCEPT: 测试方案] 新增定向单元测试，覆盖 dry-run、apply、员工补齐和幂等性。证据：`server/tests/test_demo_company_simulation_seed.py`。
+- [x] [CONCEPT: 测试方案] 在容器中以 60s 超时运行定向测试。证据：`pytest -q server/tests/test_demo_company_simulation_seed.py` 通过，2 passed。
+- [x] [CONCEPT: 运行命令] 执行 dry-run，输出计划写入规模。证据：dry-run 计划新增 18 名员工、495 张报销单、855 条明细、34 个预算池、459 条预算交易、83 条预占、55 条风险观察。
+- [x] [CONCEPT: 风险与开放问题] 获得用户确认后执行 `--apply` 写入本地数据库。证据：`seed_half_year_expense_demo.py --apply` 成功写入。
+- [x] [CONCEPT: 指标与验收] 用容器内 DB 统计确认员工数、模拟报销单、预算交易和风险观察。证据：员工 100 人，模拟报销 495 单、预算交易 459 条、风险观察 55 条。
+- [x] [CONCEPT: 指标与验收] 用真实 API 验证财务看板与预算汇总 JSON 已出现半年模拟数据效果。证据：预算汇总 API 返回 `warning_count=10`、`over_budget_count=3`；财务看板 API 返回 `has_real_data=true`、`riskCount=57`。

document/development/财务看板口径重构与画像模拟/CONCEPT.md

@@ -0,0 +1,167 @@
+# 财务看板口径重构与画像模拟概念文档
+
+## 功能一句话
+
+把财务看板从“审批过程展示”调整为“财务费用经营分析”，并让半年模拟数据自然形成部门、预算、风险和员工画像。
+
+## 背景与问题
+
+当前财务看板存在三类偏差：
+
+- 费用结构里直接展示 `travel_application` 等技术枚举，业务用户无法理解，且申请类口径不应混入报销费用结构。
+- 风险异常分布缺少完整中文映射，`missing_material`、`budget_pressure` 等风险信号以英文或半翻译方式泄露到页面。
+- 趋势图和底部卡片仍围绕审批量、审批时长展开，不符合财务看板的核心诉求。
+
+半年模拟数据也需要服务于看板分析，不能只堆单据。它必须能支撑多部门费用排行、预算消耗、风险分布和员工画像。
+
+## 目标
+
+- 费用结构只展示费用科目中文名称，申请类技术值不裸露。
+- 风险异常分布统一中文化，并覆盖预算压力、材料缺失、预算超支等常见信号。
+- 趋势图改为每日报销数量和每日报销金额。
+- “审批瓶颈”改为财务关注项，展示预算、待付款、材料待补、风险金额等财务指标。
+- 部门排行按费用金额统计，而不是只看待处理审批金额。
+- 模拟数据在写入后可生成员工行为画像快照，画像与报销单据、预算压力和风险观察一致。
+
+## 非目标
+
+- 不重做财务看板整体视觉框架。
+- 不新增一套独立画像算法。
+- 不修改生产环境数据；所有批量修复只作用于 `SIM2026`、`SIM-EXP-2026`、`SIM-BUD-2026` 等模拟前缀数据。
+
+## 用户与场景
+
+- 财务经理：查看半年费用趋势、部门费用结构、预算执行和风险异常。
+- 部门负责人：理解本部门费用消耗和预算压力。
+- 审批人：查看员工画像时，能看到基于半年模拟数据形成的费用和流程质量画像。
+- 系统演示人员：用 100 人规模的模拟数据演示端到端效果。
+
+## 功能能力
+
+### 费用结构
+
+输入为当前时间范围内有效报销单。
+
+输出为费用科目金额占比：
+
+- 排除草稿、退回、驳回、删除等非有效支出状态。
+- `travel_application` 等申请类值不直接展示；若历史数据仍存在，则归一为“差旅费”或从费用结构中排除申请类虚拟项。
+- 所有展示名称必须是中文。
+
+### 风险异常分布
+
+输入为风险观察和报销单风险标记。
+
+输出为中文风险类型分布：
+
+- `missing_material`：材料不完整
+- `budget_pressure`：预算压力偏高
+- `budget_overrun`：预算超支
+- `duplicate_invoice`：重复发票
+- `split_billing`：拆分报销
+- `amount_outlier`：金额异常
+
+未知枚举用“风险观察”兜底，不能把英文下划线文案直接展示给用户。
+
+### 每日报销趋势
+
+趋势图按天返回：
+
+- `claimCount`：每日有效报销单数量
+- `claimAmount`：每日有效报销金额
+
+前端使用柱线组合图展示，左轴为单量，右轴为金额。
+
+### 财务关注项
+
+替代原“审批瓶颈”：
+
+- 预算超支：超支预算池数量和金额。
+- 预算预警：预算使用率接近上限的池数量。
+- 材料待补：材料不完整风险数量。
+- 风险金额：当前范围内风险单据金额。
+- 待付款：已审批待付款金额。
+
+### 员工画像
+
+模拟数据写入后触发现有 `EmployeeBehaviorProfileService`：
+
+- 生成 30、90、180 天画像快照。
+- 画像类型沿用费用支出、流程质量、AI 使用和审批行为。
+- 不伪造画像结果，只用模拟报销单、审批记录和风险数据驱动算法。
+
+## 方案设计
+
+### 后端
+
+- 在 `FinanceDashboardService` 中新增费用类型与风险信号归一化方法。
+- 将 `_trend` 改为统计每日有效报销数量和金额，同时保留旧字段兼容前端灰度。
+- 将 `_department_ranking` 改为按有效费用金额统计。
+- 将 `_bottlenecks` 的返回语义改为财务关注项，字段名暂保留，降低接口破坏面。
+- 模拟数据脚本增加画像刷新入口，调用现有画像服务生成快照。
+
+### 前端
+
+- `TrendChart` 文案改为“报销单量”和“报销金额”。
+- `OverviewView` 标题改为：
+  - 报销数量与金额趋势
+  - 部门报销排行（费用金额）
+  - 财务关注项
+- 底部列表继续复用现有紧凑卡片样式，不引入新视觉体系。
+
+### 数据
+
+- 部门分布按业务权重分配，避免只有市场部或技术部。
+- 近 10 日和本月窗口保证各核心部门都有可见费用。
+- 风险样本覆盖材料缺失、预算压力、重复发票、金额异常等类型。
+- 预算台账与报销单金额一致，能体现预警和超支。
+
+## 算法与公式
+
+费用金额：
+
+$$
+amount_d = \sum_{c \in C_d} claimAmount(c)
+$$
+
+其中 \(C_d\) 为某日有效状态报销单集合。
+
+部门费用排行：
+
+$$
+deptSpend_i = \sum_{c \in C_i} claimAmount(c)
+$$
+
+预算使用率：
+
+$$
+usageRate = \frac{reservedAmount + consumedAmount}{totalAmount} \times 100\%
+$$
+
+风险金额：
+
+$$
+riskAmount = \sum_{c \in C, hasRisk(c)=true} claimAmount(c)
+$$
+
+## 测试方案
+
+- 后端单元测试：验证费用类型中文化、风险信号中文化、趋势字段、部门排行和财务关注项。
+- 容器接口测试：在 `x-financial-main:/app` 调用 `/api/v1/analytics/finance-dashboard`。
+- 前端构建：使用项目现有 `npm.cmd` 构建路径。
+- 数据脚本 dry-run：确认模拟修复仅作用于 `SIM` 前缀数据。
+- 画像验证：确认 `employee_behavior_profile_snapshots` 生成模拟员工的快照。
+
+## 指标与验收
+
+- 财务看板接口不再返回 `travel_application`、`missing material`、`budget pressure` 等裸英文展示名。
+- 趋势字段包含 `claimCount` 和 `claimAmount`，前端标题不再出现“审批趋势”。
+- 部门排行至少覆盖 6 个核心部门的有效费用金额。
+- 财务关注项不再显示审批节点或平均处理时长。
+- 半年模拟数据可生成 100 人规模下的员工画像快照。
+
+## 风险与开放问题
+
+- 历史非模拟数据可能仍有 `待补充` 部门，当前方案只保证模拟数据合理，不强行修复历史数据。
+- 批量修复模拟数据涉及数据库更新和重建模拟预算台账，执行 `--apply` 前需要用户明确确认。
+- 前端浏览器验证若环境不稳定，可降级为接口 JSON、构建和容器内测试证据。

document/development/财务看板口径重构与画像模拟/STATUS_AUDIT.md

@@ -0,0 +1,99 @@
+# 数据库状态字段审查
+
+## 审查范围
+
+- 容器：`x-financial-main`
+- 数据库：当前运行时 PostgreSQL
+- 字段范围：所有 `status`、`stage`、`approval`、`state` 相关列
+- 审查方式：只读查询 `information_schema` 与各表状态值分布
+
+## 总体结论
+
+- 当前数据库没有 `status_code`、`state_code`、`stage_code` 这类数字状态码字段。
+- 所有匹配到的状态字段类型都是 `character varying`。
+- 非业务运行态表，例如 agent 运行、工具调用、预算池、风险观察，主要使用英文机器码。
+- 报销主表 `expense_claims` 是当前最需要修复的表：`status` 使用英文码，`approval_stage` 同时混入英文码和中文节点名。
+
+## 报销主表现状
+
+`expense_claims` 当前共 498 条。
+
+按单据类型拆分：
+
+- 申请类单据：2 条，阶段为 `审批完成`、`直属领导审批`。
+- 普通报销单：1 条，阶段为 `待提交`。
+- 半年模拟报销单：495 条，主要问题都集中在这里。
+
+`expense_claims.status` 当前值：
+
+- `paid`：212
+- `approved`：98
+- `pending_payment`：67
+- `finance_review`：43
+- `submitted`：41
+- `returned`：17
+- `rejected`：13
+- `draft`：7
+
+`expense_claims.approval_stage` 当前值：
+
+- `payment`：279
+- `completed`：97
+- `finance_review`：43
+- `manager_review`：40
+- `supplement`：17
+- `rejected`：13
+- `draft`：6
+- `审批完成`：1
+- `待提交`：1
+- `直属领导审批`：1
+
+## 问题判断
+
+现在不是单纯中文显示问题，而是字段职责混乱：
+
+- `status` 被当作流程机器状态使用。
+- `approval_stage` 既被当作流程节点，也被历史模拟数据写成英文状态码。
+- 单据中心和审批权限逻辑依赖 `submitted + 中文审批阶段`。
+- 旧模拟数据中的 `finance_review/manager_review/payment/completed` 会导致审核、归档、报销单分类偏差。
+
+## 建议契约
+
+短期先采用当前代码最接近的契约：
+
+- `status`：稳定机器码，继续使用英文枚举。
+- `approval_stage`：当前流程节点，统一使用中文节点名。
+- 前端和接口展示层：只展示中文标签，不直接暴露机器码。
+
+中期如要数字状态码，需要单独迁移：
+
+- 增加 `status_code`、`approval_stage_code` 或独立状态字典表。
+- 保留现有字符串字段作为兼容层，避免一次性改动所有查询、权限、看板和智能体逻辑。
+- 完成迁移后再逐步让业务代码改读数字码。
+
+## 报销主表修复映射
+
+建议先只修 `expense_claims` 的模拟数据和历史异常阶段：
+
+- `status=finance_review` → `status=submitted`，`approval_stage=财务审批`
+- `approval_stage=manager_review` → `直属领导审批`
+- `approval_stage=budget_review` → `预算管理者审批`
+- `approval_stage=finance_review` → `财务审批`
+- `status=pending_payment` → `approval_stage=待付款`
+- `status=paid` → `approval_stage=已付款`
+- `status=approved` 且为报销单 → `approval_stage=归档入账`
+- `status=approved` 且为申请单 → `approval_stage=审批完成`
+- `status=returned` → `approval_stage=待补充`
+- `status=rejected` → `approval_stage=已驳回`
+- `status=draft` → `approval_stage=待提交`
+
+## 后续动作
+
+- 已完成：只读审查数据库状态字段。
+- 已完成：模拟数据修复脚本支持 dry-run 和中文阶段归一化。
+- 已完成：新增报销状态注册表，统一状态码、标签、阶段别名与历史值归一化。
+- 已完成：新增只读审计脚本 `audit_expense_claim_statuses.py`，用于修复前后核对状态一致性。
+- 已验证：当前 498 张单据中 495 张模拟报销单需要归一化，集中在 `payment`、`completed`、`finance_review`、`manager_review` 等历史阶段值。
+- 待确认：执行模拟数据修复脚本 `--apply --refresh-profiles`。
+- 待确认：执行 mock 附件脚本 `--apply`。
+- 待开发：如确认要数字状态码，新增状态字典/状态码迁移方案。

document/development/财务看板口径重构与画像模拟/TODO.md

@@ -0,0 +1,47 @@
+# 财务看板口径重构与画像模拟开发 TODO
+
+## 调研
+
+- [x] 核对财务看板接口字段和页面消费位置。[CONCEPT: 背景与问题] 证据：`FinanceDashboardService`、`TrendChart`、`OverviewView` 已确认。
+- [x] 核对员工画像现有服务是否可复用。[CONCEPT: 员工画像] 证据：`EmployeeBehaviorProfileService` 已支持批量扫描和按员工刷新。
+
+## 契约
+
+- [x] 将趋势字段调整为 `claimCount`、`claimAmount`，并保留旧字段兼容。[CONCEPT: 每日报销趋势] 证据：`FinanceDashboardService._trend` 已返回新字段，定向测试通过。
+- [x] 将底部 `bottlenecks` 展示替换为预算指标。[CONCEPT: 财务关注项] 证据：页面展示预算池数量、总预算、已用预算、预占预算、可用预算、预警预算池。
+- [x] 补齐费用类型和风险类型中文归一化规则。[CONCEPT: 费用结构] 证据：接口 JSON 不再包含 `travel_application`、`missing_material`、`budget_pressure`。
+- [x] 建立报销状态注册表，集中管理状态码、中文标签、阶段别名和历史值归一化。[CONCEPT: 数据] 证据：`expense_claim_status_registry.py` 已新增。
+- [x] 将财务看板主指标改为财务口径，移除风险异常展示。[CONCEPT: 指标与验收] 证据：KPI 改为本期报销金额、报销单数、待付款金额、单均金额、预算使用率、付款完成率。
+
+## 后端
+
+- [x] 修改 `FinanceDashboardService` 的费用结构、趋势、部门排行、个人排行、高额单据和预算指标计算。[CONCEPT: 方案设计] 证据：`server/src/app/services/finance_dashboard.py` 已更新。
+- [x] 补充后端定向测试，覆盖英文枚举不外露和趋势字段。[CONCEPT: 测试方案] 证据：`test_finance_dashboard_uses_financial_terms_instead_of_approval_terms` 已新增。
+
+## 前端
+
+- [x] 修改 `TrendChart` 为报销单量和报销金额图。[CONCEPT: 前端] 证据：`TrendChart.vue` 已改为双轴单量/金额。
+- [x] 修改财务看板标题和底部列表文案。[CONCEPT: 前端] 证据：`OverviewView.vue` 标题已更新。
+- [x] 确认页面不再出现审批趋势、审批瓶颈文案。[CONCEPT: 指标与验收] 证据：`rg` 检查财务看板相关文案已清理。
+- [x] 将趋势拆为“每日报销金额”和“每日报销数量”两个单指标图。[CONCEPT: 每日报销趋势] 证据：`OverviewView.vue` 和 `TrendChart.vue` 已更新。
+- [x] 新增个人报销排行和本月高额单据列表。[CONCEPT: 指标与验收] 证据：财务看板模板已新增 `个人报销排行（本月）`、`本月高额单据`。
+- [x] 移除财务页“财务关注项”卡片，新增预算指标网格。[CONCEPT: 指标与验收] 证据：财务页模板已展示 `预算指标`，不再展示 `财务关注项`。
+
+## 数据与画像
+
+- [x] 修复半年模拟数据部门分布脚本，保持 dry-run 可审计。[CONCEPT: 数据] 证据：`repair_half_year_expense_demo_distribution.py` dry-run 返回六部门重分布计划。
+- [x] 为模拟数据写入脚本增加画像刷新入口。[CONCEPT: 员工画像] 证据：seed 与 repair 脚本均支持 `--refresh-profiles`。
+- [x] 将模拟数据修复脚本中的审批阶段规范为中文业务阶段。[CONCEPT: 数据] 证据：待审单统一为 `submitted + 财务审批/直属领导审批`，归档/付款阶段写入中文阶段。
+- [x] 增加报销状态只读审计脚本。[CONCEPT: 指标与验收] 证据：`audit_expense_claim_statuses.py` 可输出需要归一化的状态组合。
+- [x] 提高半年模拟数据单据密度。[CONCEPT: 数据] 证据：seed dry-run 计划在现有 495 单基础上新增 690 单，总量约 1185 单。
+- [ ] 在用户确认后执行模拟数据修复 `--apply`。[CONCEPT: 风险与开放问题]
+- [ ] 验证模拟员工画像快照已形成。[CONCEPT: 指标与验收]
+
+## 验证
+
+- [x] 在 `x-financial-main` 容器内运行后端定向测试，超时不超过 60s。[CONCEPT: 测试方案] 证据：`pytest -q server/tests/test_finance_dashboard_service.py server/tests/test_demo_company_simulation_seed.py`，4 passed。
+- [x] 运行前端构建或等价静态验证。[CONCEPT: 测试方案] 证据：`npm.cmd run build` 成功。
+- [x] 调用财务看板 API，确认 JSON 中不再泄露英文枚举并包含新指标。[CONCEPT: 指标与验收] 证据：容器内服务调用返回 `claimCount`、`claimAmount`，英文枚举检查为 false。
+- [x] 验证单据中心财务角色可以看到公司报销单与归档单。[CONCEPT: 测试方案] 证据：`test_list_claims_returns_company_reimbursements_for_finance_document_center` 与归档测试通过。
+- [x] 验证财务看板真实 payload 不含风险展示文案，部门排行不含“待补充”。[CONCEPT: 指标与验收] 证据：容器内服务调用 `contains_risk_text=false`、`contains_pending_fill_department=false`。
+- [x] 验证预算指标真实 payload。[CONCEPT: 指标与验收] 证据：容器内服务调用返回 6 个 `budget_metrics`，且 `contains_focus_label=false`。