系统跑在哪、改动怎么管理
这篇收尾：系统部署在什么环境、数据怎么备份、代码改动遵循什么流程、目前有哪些已知问题。是整套文档的"运维入口"。
部署环境
- 跑在群晖 NAS 上的 Hermes 容器里，用 Python 虚拟环境。
- 数据库是项目目录下的 rideshare.db，是唯一事实源。
- 定时任务用 Hermes cron，no_agent 模式自动跑。
- 网页面板由静态服务托管，有看门狗定时保活。
数据备份
- 每天 12:00 做一次全量打包，实测包含 rideshare.db。
- 每次录单、每日还会生成数据库副本。
- 改数据库结构前先手动复制一份、做完整性检查，再动手。
改动怎么登记
- 凡是改生产代码、配置、定时任务、数据库结构或运行机制，先登记再动手。
- 登记内容：日期、类型、改了什么、为什么，改完回填验证结果。
- 只读查询、单纯跑测试不需要登记。
版本规则（SemVer）
- patch：修 bug、小维护，包括同一目标的补完。
- minor：新功能、明显能力增加，或业务口径不变的纯架构重构。
- major：架构或兼容性的重大变化、用户可见的换代。
- 拿不准影响哪个版本就先标"待定"，版号由本人最终拍板，不自己跳号。
封版流程
- 封版 = 把待发变更搬进 CHANGELOG、更新 VERSION/STATUS、清空待发区、提交一次版本记录。
- 这套动作会定死版号，必须等本人明确下令才做；AI 只报告"可以封版"。
- 月报每月 1 日、重大版本上线观察无回滚后，是常规封版时机。
改完怎么验证
- check_consistency：核对几处报告数字同源。
- 独立 SQL 重算对拍：不依赖统计层，另算一遍验证。
- 面板 UI 回归：桌面和手机双端，检查零横向溢出、布局不跳动。
- 写库的改动要在副本上做冒烟测试，验完才上生产。
已知情况
- 天气能力只保留数据采集，统计和关联分析长期暂缓，不主动推进。
- 飞书多维表格做展示镜像的方案经过验证后已放弃，避免维护第二份数据。
- 早期 Excel 导出已退役，历史月报保留生成时的旧口径，不重渲染。
当前版本、数据基准和完整待办分别以 VERSION、BASELINE、ROADMAP 为唯一真源，文档里不手抄会变的数字。