Files
Jyotisha/docs/tasks/PROGRESS-beta-safety-net-fix-20261015.md
T
jesse-uxandGrok (agent loop) 5c0d895391 fix(release): daily backups no longer replace the recovery point
Product chose to keep the scheduled backup, but the current recovery point must stay the one created by hand. Daily runs still encrypt and restore-verify, then record a separate latest-backup note.

Co-Authored-By: Grok (agent loop)
2026-10-15 16:16:48 +08:00

3.4 KiB

进度 · 内测安全网修复(2026-10-15)

  • 分支:codex/beta-safety-net-20261014
  • 任务书:docs/tasks/TASK-beta-safety-net-fix-20261015.md
  • 上一轮已推送:53d8df257ddef8918034acef36df0b4b7daade2c
  • 产品选 A:每天的自动备份照做,但不改当前恢复点。

做了什么

  • 先合并最新 origin/staging,没有改写已经推送的提交。合并时本分支的 BUG-1354 和更早的答题强度记录撞号,安全网三条顺延为 BUG-1355、BUG-1356、BUG-1357。这次的修复是 BUG-1358。
  • 用已经存在的 RECOVERY_BASENAME_PREFIX=production-daily 当开关,没有另加模式参数。这个前缀下,脚本仍完成导出、加密、还原核对(含表权限、列权限、属主)并写校验文件,但跳过 recovery-baseline.env。标准错误打印 baseline_updated=false。另写 .state/daily-backup-latest.env,只有文件名、sha256、核对时间、BACKUP_FORMAT=2。
  • 不设这个前缀时,仍写 recovery-baseline.env,里面有 RECOVERY_FORMAT=2,标准错误打印 baseline_updated=true,不改已经存在的每日记录。
  • 标准输出仍是原来的 7 行。因此没有改 .gitea 里「恰好 7 行」的检查,也没有改四个已有生产工作流。
  • 再确认清理脚本只删严格匹配的过期 production-daily- 文件。既有测试里的 production-pre-migration- 手动恢复点仍被保留。
  • docs/operations/production-release-runbook-20261014.md 和 deploy/README.md 写明:每日备份只是存档和核对,上线前仍要手动点 Create production recovery。

跑过的检查

检查 命令 结果
安全网与隐私 .venv\Scripts\python.exe -m pytest tests/test_beta_safety_net.py tests/test_repo_privacy_markers.py -q 78 通过(安全网 16,隐私 62),退出码 0
前端合同 node node_modules/tsx/dist/cli.mjs --test tests/runtime-sources-no-test-imports.test.ts tests/staging-backend-workflows.test.ts 46 项:41 通过,5 失败,0 取消。失败是本机缺口,见下方偏离。恢复点工作流的文本检查通过
shellcheck 无 本机没有这条命令
前端 tsc / lint / 全量测试 未跑 没有改网页
Python 快速门 未跑 按本轮约定不跑
数据库测试 未跑 没有改数据库

偏离

  • baseline_updated 打在标准错误,避免把每日备份和手动恢复点工作流对标准输出「恰好 7 行」的检查撑破。没有改 .gitea/**。
  • 测试要在临时目录里跑脚本。生产路径检查保持原样;只有 JYOTISHA_RECOVERY_FIXTURE=1 时才允许别的目录。会调用恢复脚本的两个工作流都没有设置这个变量。
  • 本机 Git Bash 没有 flock,pytest 的临时目录也不能改 Unix 权限。测试只在自己的 PATH 里放了假的 docker、sudo、df、install、chmod、flock。生产脚本仍调用真命令。
  • 没有在这台 Windows 上安装到生产,没有点任何生产按钮。主机安装和一次恢复演练仍留给产品。
  • 前端合同 5 项失败都不是这次改的脚本:本机 Python 没有 yaml 模块(直接跑时退出码 9009)、没有 rsync(退出码 127)、临时目录不能改权限(install 报 Permission denied)、文档范围脚本退出码 49。这四类脚本本次都没改。恢复点脚本的语法检查和文本合同是通过的。