feat: add historical data management

findings.md

@@ -1,5 +1,50 @@
 # 景区排队叫号系统：调研发现与决策台账
 
+## Phase 42 运营统计模块标题区呼吸空间优化（2026-07-16）
+
+- 用户通过截图明确指出“每日趋势、项目对比、状态分布、高峰时段”几个模块的标题和副标题贴近边框，整体缺少呼吸空间。
+- 截图证据显示问题集中在卡片标题区的上下内边距和标题区到首个数据区的间隔，不是数据内容本身或模块顺序问题。
+- 本轮采用统一规则：桌面卡片增加 24px 上下内边距与 32px 水平内边距；标题区副标题使用更舒展的行高，标题区下方增加 24px 留白；移动端收敛为 20px 内边距并保留 20px 标题区间隔。
+- 不改变趋势、项目比较、状态列表、高峰列表的 DOM 数据结构和下钻交互，只调整 CSS 节奏与标题区/内容区边界。
+
+## Phase 41 运营统计页视觉层级与排版精修（2026-07-16）
+
+- 本轮按 `design-taste-frontend` 的“保留式重设计”处理：不改变历史数据页路由、导航、数据契约、权限、导出和项目下钻，只调整视觉层级、排版和空值表达。
+- 设计读法为可信、轻量、低干扰的后台复盘工具；参数设为 `DESIGN_VARIANCE=4`、`MOTION_INTENSITY=2`、`VISUAL_DENSITY=5`，不引入营销页式动效、渐变或新图片。
+- `ui-ux-pro-max` 设计系统仍推荐数据密集型看板，但要求统一字体层级、8px 间距节奏、足够对比度、无横向溢出，以及少于 4 个时间点不用折线图。
+- 当前页面筛选区复用了记录页的 6 列网格，统计页隐藏字段后仍留下不均衡空白；五个 KPI 各自成卡，导致第一层指标像五个同级模块；趋势、项目和节奏卡片的边界同质，主次不够明显。
+- 精修方案：统计页筛选网格收敛为日期、项目、操作；KPI 合并成单一指标轨道；趋势与项目保持主内容宽卡，状态与运营节奏作为次级双栏；移动端统一单列并保持 8px 触控间距。
+- 页面 visible copy 需要避免使用破折号作为缺省值，统一为“暂无/未提供/日期至日期”等可读文案；小时分布文字改用已定义的深色文本 token，修复变量未定义导致的继承不确定性。
+
+## Phase 40 运营统计看板布局与 UI/UX 收敛（2026-07-16）
+
+- 用户明确要求删除运营统计看板中的“需要关注”模块；本轮只移除前端展示与相关引导文案，不改变项目下钻、历史查询和实时运营概览职责。
+- `ui-ux-pro-max` 设计系统推荐数据密集型经营看板：以有限层级的网格承载多个 KPI、趋势和排序比较；配色沿用现有管理端 token，不新增依赖或视觉体系。
+- UI/UX 检索要求响应式页面避免横向溢出、保持连续标题层级、避免加载时布局跳动；图表检索建议时间序列使用折线图、离散项目使用排序比较，并保留可读数值。
+- 当前实现的主要布局问题是趋势与“需要关注”并列导致主内容被压缩，项目对比与高峰时段再次并列造成卡片碎片化，窄屏项目行的三列声明又承载四组内容。
+- 收敛后的结构固定为：核心指标 → 全宽每日趋势 → 全宽项目对比 → 状态分布与高峰/小时节奏；少于 4 个营业日时趋势区域改为日卡片摘要，避免单点折线误导。
+
+## Phase 39 运营统计经营复盘看板优化（2026-07-16）
+
+- 用户已确认运营统计模块按“经营复盘看板”优化，不做实时值班监控；实时排队继续由现有“运营概览”负责。
+- 当前 `/api/admin/history/summary` 只返回四类汇总指标、状态分布字段和按小时聚合；缺少按营业日趋势、项目维度对比、峰值时段排名、异常项目/日期摘要。
+- 当前 `HistoryPage` 的“运营统计”只有 4 张汇总卡片、状态分布和按小时长条列表，信息密度偏低，无法快速回答“哪天/哪个项目变差、差在哪里”。
+- 既有日期范围最多 31 天、项目筛选和 Asia/Shanghai 小时聚合可以复用；新增接口字段应继续服从项目权限与同一日期筛选口径。
+- 小时统计实现已校正为分开按 `joined_at` 统计取号量、按 `called_at` 统计叫号量；两者可能落在不同本地小时，集成夹具已覆盖这一情况。
+- 推荐看板结构：顶部筛选与数据新鲜度；第一层核心 KPI；第二层每日趋势（取号量、完成率、平均等待）；第三层项目排行/对比；第四层峰值时段和需要关注的异常摘要；支持点击项目或日期回到排队记录筛选。
+- 继续使用现有原生 CSS 和管理端 token，不新增图表依赖；趋势图用轻量 SVG/HTML 图形，避免引入包和造成项目风格分裂。
+
+## Phase 37 后台历史数据管理功能规划（2026-07-16）
+
+- 现有管理端导航为运营概览、项目管理、账号管理和大屏中心，历史数据适合新增单一“历史数据”入口，内部采用排队记录、叫号记录、运营统计三个视图。
+- 现有 `queue_sessions` 以 `project_id + business_date` 定位营业日，`queue_tickets` 已保存号码、同行人数、状态和取号/叫号/到场/完成/过号时间，`call_batches` 与 `call_batch_tickets` 可还原叫号批次；首期不需要新建独立历史事实表。
+- 现有管理 API 仅允许 `ADMIN` 角色进入，管理员默认跨项目；历史接口仍需把项目授权作为服务端过滤条件，不能信任客户端项目参数。
+- 当前数据库维护任务会在终态数据到期后清除手机号、姓氏和称谓，并保留号码及统计所需字段；历史页面应把这类记录显示为“已匿名化”，不能再通过手机号检索。
+- 既有产品/设计文档要求原始排队业务事件 90 天后不可逆匿名化，但现有代码主要实现的是终态个人字段 30 天清理和审计 1 年过期删除，二者存在待统一的策略差异。
+- 推荐首期做只读历史查询、叫号批次追溯、统计聚合和 CSV 受控导出；不允许直接修改历史状态/号码/同行人数，不首期引入数据仓库、冷归档或复杂审批流。
+- 详细方案已写入 `docs/history-data-management-plan.md`，当前唯一必须确认的高影响决策是 90 天后原始业务事件究竟保留匿名明细还是只保留统计。
+- 用户已确认：90 天后保留匿名业务明细和长期统计，删除手机号、姓氏等个人关联信息，且不可恢复；该口径纳入后续清理任务、查询权限、导出字段和验收标准。
+
 ## Phase 36 员工端取号同行人数输入修复（2026-07-16）
 - 用户反馈员工端取号页的“同行人数”输入框存在默认值 `1` 被固定、无法顺畅改成其他人数的问题。
 - 本轮只修复输入交互与相应回归测试，不改变项目配置的人数上下限、取号 API 契约或服务端校验。