root/Jyotisha
1
0
Fork 0
Code Issues 32 Pull Requests Actions Packages Projects Releases Wiki Activity

merge origin/staging into the beta safety net branch

Browse Source 
Safety-net records move to BUG-1358 through BUG-1361 because staging already uses BUG-1355 through BUG-1357 for capacity.

Co-Authored-By: Grok (agent loop)
This commit is contained in:
jesse-ux
2026-10-15 17:13:57 +08:00
co-authored by Grok (agent loop)
parent 5c0d895391 32b238cf86
commit 14897f0bf3
34 changed files with 1168 additions and 90 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/PROGRESS-beta-capacity-20261014.md
+43
View File
@@ -0,0 +1,43 @@
# 进度 · 内测容量（2026-10-15）
- 分支：`codex/beta-capacity-20261014`
- 基线：开工时 `origin/staging` `ef49257b734678ff944a840076347baa02d0323c`
- 任务书：`docs/tasks/TASK-beta-capacity-20261014.md`
- 前置：`origin/codex/node-runtime-resources-20261013` 与 `origin/codex/rect-scoring-perf-20261013` 都是该 staging 的祖先（`merge-base --is-ancestor` 退出码 0）。限流文件里已有过期清理。
## 做了什么
- T1：对话 10 次/分钟 + 120 次/小时，校正回合 5 次/分钟 + 40 次/小时，报告 3 次/小时（每天 5 份不变）。拒绝发生在预留点数之前，429 + `rate_limited` + `Retry-After`。开案路由不计数。
- T2：重计算并发仍是 2。满了最多等 8 秒，同时等待最多 4 个；等不到或等待已满仍是 429，`Retry-After` 不变。对话对这种 429 最多再试 2 次，等待合计不超过 15 秒。进度行「人有点多，排一下队」，失败句「人有点多，这一轮没排上，点数已经退回。」退点仍走原来的取消预留，代理路径用已有的一次结算。
- T3：后台已能批量生成（1–100 个、每码点数自填、初始 10）、按兑换账户查看、撤销未使用的码。说明在 `docs/operations/beta-invite-codes.md`。没有扩功能。
- T4：脚本 `frontend/scripts/research/beta-load-smoke.mts`。不从 `frontend/tests` 导入。本机没有跑。
- T5：BUG-1355、BUG-1356，CHANGELOG、VOICE、DESIGN、真机两条。
## 断言
旧测试仍要求「名额被占着就拒绝」，没有改拒绝码和 `Retry-After` 的期望值。
| 位置 | 原值 | 新值 | 原因 |
| --- | --- | --- | --- |
| `tests/test_api_heavy_compute_gate.py` 立刻拒绝的夹具和单测 | `reset()` / `reset(limit=1, retry_after_seconds=3)` | 增加 `wait_seconds=0` | 默认改为最多等 8 秒。这些测试继续锁 429 和 `Retry-After`，排队另有新测试 |
| `tests/test_api_chart_subprocess_gate.py` 两处占着名额再请求 | `reset(limit=1)` | `reset(limit=1, wait_seconds=0)` | 同上。仍锁同步排盘被拒绝、日志不出现请求正文 |
## 偏离与环境缺口
- T0：仓库文档里的目标规格，staging 与生产都是 2 vCPU / 4 GB，代码默认并发 2。这台 Windows 没有 staging 的登录壳，没有采到机器上的实际核数、内存和 `JYOTISH_HEAVY_COMPUTE_CONCURRENCY`。不能把文档规格当成已经登主机核对过。
- T4：没有 `STAGING_TEST_OTP`，没有对 staging 或生产发压测。改前、改后的并发数字都没有。服务器 CPU / 内存同样没有采样。脚本留给验收方在有测试验证码的环境重跑。20 并发档没有跑。
- 旧版对话（不走代理运行时）会重试，但进度行要等回答流开始才有，所以那条路径等待时看不到「排一下队」。现在的对话走代理运行时，进度行会换字。任务书允许把排队文案收成只多等。
- 没有改数据库，没跑 `test:db`。没有跑前端全量 `npm test`，没有跑 Python 快速门。
- `deploy/README.md` 有一句仍写「满了不排队」。改成了最多等 8 秒、等待不超过 4 个，避免操作说明和代码相反。没有改部署配置。
## 自测
| 检查 | 命令 | 结果数字 |
| --- | --- | --- |
| Python 闸门 | `.venv\Scripts\python.exe -m pytest tests/test_api_heavy_compute_gate.py tests/test_api_chart_subprocess_gate.py -q` | 17 通过（8 + 9），0 失败 |
| 前端相关测试 | `node node_modules/tsx/dist/cli.mjs --test tests/request-rate-limit.test.ts tests/consultation-workflow-retry.test.ts tests/personal-report-api.test.ts tests/runtime-sources-no-test-imports.test.ts` | 76 通过，0 失败 |
| 类型 | `frontend\node_modules\.bin\tsc --noEmit -p .` | 退出码 0 |
| 前端 lint | `npm run lint` | 0 错误，123 条原有警告 |
| 压测 | 未执行 `frontend/scripts/research/beta-load-smoke.mts` | 本机没有 `STAGING_TEST_OTP`。没有改前/改后并发数字，没有服务器 CPU/内存 |
没有改数据库，没跑 `test:db`。没有跑前端全量 `npm test`，没有跑 Python 快速门。
docs/tasks/PROGRESS-beta-capacity-fix-20261015.md
+46
View File
@@ -0,0 +1,46 @@
# 进度 · 内测容量修复（2026-10-15，第 1 次打回）
- 分支：`codex/beta-capacity-20261014`
- 被验 SHA：`a54f75e5e33775d5dc91f3058f5505a56b498bf2`
- 修复单：`docs/tasks/TASK-beta-capacity-fix-20261015.md`
- 原任务书：`docs/tasks/TASK-beta-capacity-20261014.md`
- 开工时本分支最大 Bug 编号：BUG-1356。本轮新增 BUG-1357。BUG-1351、BUG-1352、BUG-1353 已在本分支文件里，没有重用。
## 做了什么
- 先把最新 `origin/staging` 合并进本分支（不改写已推送的 `a54f75e5`）。合并只带进修复单和任务索引的一行。
- 语音合同：仍锁「工作流调用的入参是 `toolInput`」，以及用户轮不塞工具 JSON。不再要求 `await` 紧贴函数名。
- 隐私白名单：采用修复单推荐的做法 a。把「hourly rate limit returns 429」整段挪到 `personal-report-api.test.ts` 末尾，断言原文不变。`SAFE_LINES` 不改。三行回到 832、860、890，且整行与白名单一致。
- 业务代码不改。
## 断言
| 位置 | 原值 | 新值 | 原因 |
| --- | --- | --- | --- |
| `consultation-voice-contract.test.ts`「consult user turn no longer dumps tool JSON」 | `/await runConsultationWorkflow\(toolInput/` | `/runConsultationWorkflow\(toolInput/` | 调用包进 `retryOnConsultationRateLimit`，`await` 不再紧贴函数名。仍锁入参是 `toolInput` |
| `personal-report-api.test.ts` 小时限流测试的位置 | 插在「429 at the daily limit」和「502 model_unavailable」之间 | 文件末尾，断言原文不变 | 插在中部让三行白名单各下移 13 行。挪走后行号复原，不改 `SAFE_LINES` |
## 源码文本再搜一遍
在 `frontend/tests` 和 `tests` 里核对三条路由被改写的语句：
- 只有语音合同把 `await runConsultationWorkflow(toolInput` 写成必须匹配。已按上表改。
- `consultation-workflow-contract.test.ts` 是在代理分支里断言**不**出现 `await runConsultationWorkflow`，与这次包装无关，没改。
- 「暂时无法生成解读」仍在非排队失败的分支里，`consult-first-frame-and-pacing-20260928.test.tsx` 继续对得上，没改。
- `toNextResponse` 多了响应头，没有测试按旧函数签名做源码断言。
- Python 侧没有按这三处被改写语句做源码文本断言。
## 偏离与环境缺口
- 没有改数据库，没跑 `test:db`。没有跑前端全量 `npm test`，没有跑 Python 快速门。
- 并发压测 `frontend/scripts/research/beta-load-smoke.mts` 未跑。没有测试验证码，修复单也写明本机和执行侧都连不上测试服务器，不要登预发。没有改前/改后并发数字，没有服务器占用采样。
## 自测
| 检查 | 命令 | 结果数字 |
| --- | --- | --- |
| 前端相关测试 | `node node_modules/tsx/dist/cli.mjs --test tests/consultation-voice-contract.test.ts tests/runtime-sources-no-test-imports.test.ts tests/personal-report-api.test.ts` | 75 通过，0 失败，0 取消 |
| 隐私扫描 | `.venv\Scripts\python.exe -m pytest tests/test_repo_privacy_markers.py -q` | 62 通过，0 失败 |
| 类型检查 | `frontend\node_modules\.bin\tsc --noEmit -p .` | 退出码 0 |
| 前端 lint | `npm run lint` | 0 错误，123 条原有警告 |
| 并发压测 | 未跑 `beta-load-smoke.mts` | 没有测试验证码，没有登预发 |
docs/tasks/PROGRESS-beta-safety-net-20261014.md
+1 -1
View File
@@ -3,7 +3,7 @@
- 分支：`codex/beta-safety-net-20261014`
- 基线：开工时 `origin/staging` 为 `71f7fac3a13f817f91755ff01b25b8706380ae19`
- 前置：`09906cdc`（发布通路）和 `4c3485bc`、`3893783e`（#58）都已是这个基线的祖先。`deploy/docker-compose.server.yml` 在加日志段之前没有 #58 留下的未合入冲突。
- 编号：本文件最大号是 BUG-1353。本单当时写成 BUG-1354（没有每日备份）、BUG-1355（没有探活和磁盘告警）、BUG-1356（日志不轮转、不能按请求编号查）。合并 staging 后 BUG-1354 已被更早的答题强度记录占用，三条顺延为 BUG-1355、BUG-1356、BUG-1357。
- 编号：本文件最大号是 BUG-1353。本单当时写成 BUG-1354（没有每日备份）、BUG-1355（没有探活和磁盘告警）、BUG-1356（日志不轮转、不能按请求编号查）。合并 staging 后 BUG-1354 已被更早的答题强度记录占用，三条顺延为 BUG-1355、BUG-1356、BUG-1357。2026-10-15 再次合并 staging 时，这三个号已被内测容量占用，最终编号是 BUG-1358、BUG-1359、BUG-1360。
## 做了什么
docs/tasks/PROGRESS-beta-safety-net-fix-20261015.md
+1 -1
View File
@@ -7,7 +7,7 @@
## 做了什么
- 先合并最新 `origin/staging`，没有改写已经推送的提交。合并时本分支的 BUG-1354 和更早的答题强度记录撞号，安全网三条顺延为 BUG-1355、BUG-1356、BUG-1357。这次的修复是 BUG-1358。
- 先合并最新 `origin/staging`，没有改写已经推送的提交。合并时本分支的 BUG-1354 和更早的答题强度记录撞号，安全网三条顺延为 BUG-1355、BUG-1356、BUG-1357。这次的修复当时写成 BUG-1358。2026-10-15 再次合并 staging 后，BUG-1355～1357 归内测容量，本条修复最终是 BUG-1361。
- 用已经存在的 `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 行」的检查，也没有改四个已有生产工作流。
docs/tasks/README.md
+3 -2
View File
@@ -338,8 +338,9 @@
| `TASK-release-path-production-20261014.md` | `PROGRESS-release-path-production-20261014.md` | **发布通路 + 生产首发**：产品 10-14 授权改生产工作流（发布 SHA = 最近门禁成功提交 + 其后纯文档）；63 个迁移清单与演练脚本、首发 runbook；生产拒绝测试验证码。Grok 不 dispatch 生产工作流 | 第 2 次打回后续修 | `codex/release-path-production-20261014`（BUG-1348、BUG-1349） |
| `TASK-release-path-production-fix-20261014.md` | `PROGRESS-release-path-production-fix-20261014.md` | **#74 第 1 次打回**：发布规则成立；测试写死 Windows 路径（Linux 全红）、主机演练依赖主机 node 且会留下生产数据副本、docs-only 头时回滚被拒；另补 CHECK_RELEASE_GATE 断言与 OTP 守卫规范化 | 已修，第 2 次仍未过 | `codex/release-path-production-20261014` |
| `TASK-release-path-production-fix2-20261014.md` | `PROGRESS-release-path-production-fix2-20261014.md` | **#74 修复单 2（产品选 A）**：恢复点要带属主与权限，旧格式不得回退；演练按备份里的授权比对，并在真实 PostgreSQL 17 上跑通一次 | 待验收 | `codex/release-path-production-20261014` |
| `TASK-beta-safety-net-20261014.md` | `PROGRESS-beta-safety-net-20261014.md` | **内测安全网**：每日备份 + 恢复演练、探活告警、本地错误汇总、日志轮转、按 requestId 查日志。发布通路与 #58 已在开工时的 `origin/staging` 上。主机安装和一次演练留给产品 | 待验收 | `codex/beta-safety-net-20261014`（BUG-1355～1357） |
| `TASK-beta-safety-net-fix-20261015.md` | `PROGRESS-beta-safety-net-fix-20261015.md` | **#75 产品选 A**：每日备份照常做，但不改当前恢复点；另记 `daily-backup-latest.env` | 待验收 | `codex/beta-safety-net-20261014`（BUG-1358） |
| `TASK-beta-safety-net-20261014.md` | `PROGRESS-beta-safety-net-20261014.md` | **内测安全网**：每日备份 + 恢复演练、探活告警、本地错误汇总、日志轮转、按 requestId 查日志。发布通路与 #58 已在开工时的 `origin/staging` 上。主机安装和一次演练留给产品 | 待验收 | `codex/beta-safety-net-20261014`（BUG-1358～1360） |
| `TASK-beta-safety-net-fix-20261015.md` | `PROGRESS-beta-safety-net-fix-20261015.md` | **#75 产品选 A**：每日备份照常做，但不改当前恢复点；另记 `daily-backup-latest.env` | 待验收 | `codex/beta-safety-net-20261014`（BUG-1361） |
| `TASK-beta-safety-net-fix2-20261015.md` | — | **#75 修复单 2**：生产侧全过；飞书测试 env 文件权限 0644 在 Linux 上失败（会挡发布门禁）；新测试不在 quick 门禁；磁盘 ≥70% 后备份静默停摆；监控脚本缺 sudo 与 env 文件 | 待领取 | `codex/beta-safety-net-20261014` |
| `TASK-beta-capacity-20261014.md` | — | **内测容量**：按用户限流、重计算短排队与对话重试、兑换码当邀请码、staging 10/20 并发压测。**等 #58 合入后开工，压测等 #57 合入** | 待前置 | — |
| `TASK-beta-capacity-fix-20261015.md` | — | **#76 第 1 次打回**：`a54f75e5` 限流与短排队逻辑通过；源码文本断言未跟改、插入新测试使隐私白名单行号错位 | 待领取 | `codex/beta-capacity-20261014` |
| `TASK-special-lagnas-native-20261008.md` | `PROGRESS-special-lagnas-native-20261008.md` | **特殊上升点原生计算（线上缺陷）**：sync6 U6 运行时调 PyJHora，生产镜像没有 PyJHora → staging 上 Hora/Ghati/Sree/Indu/Pranapada 全 blocked；原生实现、PyJHora 只作冻结对照、快速门禁止运行时 import jhora；最先做 | 已验收（已部署 staging `795b8845`，BUG-1273） | `codex/special-lagnas-native-20261008`（未上线；部署以 `/api/health` 为准） |
docs/tasks/TASK-beta-safety-net-fix2-20261015.md
+45
View File
@@ -0,0 +1,45 @@
# TASK · 内测安全网修复单 2（issue #75）
- 日期：2026-10-15
- 前序：`TASK-beta-safety-net-20261014.md`、`TASK-beta-safety-net-fix-20261015.md`（产品选 A）
- 被验 SHA：`5c0d895391b5d0806c98de669a2e9cdcd61e3335`（`codex/beta-safety-net-20261014`）
- 执行方：Grok，同一分支续做（先 merge 最新 `origin/staging`，不改写已推历史）
- 红线不变：仍不改已有四个生产工作流与 staging 工作流、`gated-paths.txt`、`is-docs-only-range.sh`；不点生产按钮
## 1. 验收结论：面向生产的部分全部过；一条阻断 + 三条要一起修
已确认成立：每日工作流只从 main 跑、与恢复点工作流同一把锁 / 同样的密钥处理、不回显密钥；每日模式**任何路径都不写** `recovery-baseline.env`（只有手动分支写），失败时什么状态都不写；`daily-backup-latest.env` 只有 4 个键；发布 / 迁移 / 回退不读它；手动恢复点（含 `RECOVERY_FORMAT=2` 与权限比对）不变；清理脚本只认 `^production-daily-\d{8}T\d{6}Z\.dump\.enc$` 的普通文件，碰不到 `production-pre-migration-*`；错误分类只外发校验过的 errorCode / 路由 / UUID，不发用户内容；compose 只加了 6 个服务一致的 `logging`。
### B1（阻断）· 测试在 Linux 上失败
`tests/test_beta_safety_net.py` 约 616–634 行 `test_feishu_payload_keeps_only_allowed_fields`：约 76–77 行用 `write_text` 写 `monitor.env`，默认权限 0644；`deploy/monitor/notify-feishu.sh` 约 18–23 行在 Linux 上拒绝非 0600 的环境文件 → 退出 1。macOS / Windows 上跳过了这项检查所以没发现。`release-quality-gate.yml` 在 Linux 上跑全树 pytest，提升 main 会被它挡住。
- 修：测试里写完后 `os.chmod(env_file, 0o600)`。脚本里的检查是对的，不改。
### N1 · 新测试不进 staging 门禁
`scripts/run_quality_gate.py` 的 quick 清单（约 55–90 行）没有 `tests/test_beta_safety_net.py`，合同只在发布时才跑——B1 就是这样漏过去的。把它加进 quick 清单。
### N2 · 磁盘 ≥70% 后备份静默停摆
`run-production-recovery.sh` 约 149–153 行磁盘 ≥70% 拒绝；`backup-production-daily.yml` 约 145–146 行只在备份成功后才清理旧文件 → 一旦到 70%，旧文件永不清理、每天都失败；磁盘告警 80% 才响，也没人检查 `daily-backup-latest.env` 有多旧。
- 修：清理放在备份**之前**（或 `if: always()`）；`healthcheck-alert.sh` 增加「最近一次每日备份超过 36 小时」告警（读 `daily-backup-latest.env` 的 `verified_at`）。加测试。
### N3 · 两个监控脚本在生产主机上大概率跑不起来
`deploy/monitor/error-digest.sh` 约 54–59 行、`deploy/find-request-log.sh` 约 300–307 行直接调 `docker`，其它生产脚本与恢复演练都用 `sudo -n docker`；也没导出 `DATABASE_ENV_FILE`，`docker-compose.postgres.yml` 会回落到不存在的 `../.env.staging.database`，Compose 拒绝加载。错误汇总由 cron 每 5 分钟跑，会每次失败、什么都不发。
- 修：统一 `sudo -n docker`，显式传入生产的 compose 文件与 env 文件路径（与 `run-production-deploy.sh` 同一写法）；测试断言命令行形状。
## 2. 顺手修（不阻断，一并做）
- `notify-feishu.sh` 约 96–101 行：`curl` 加 `--fail`，并检查飞书返回体里的 `code == 0`；失败时不记成「已发送」。
- `error-digest.sh`：同一类告警 30 分钟内不重复发。
- `find-request-log.sh`：真实路径按时间戳排序（去掉 compose 前缀后再排），与 README 说法一致。
## 3. 验收标准
- Linux：`python3 -m pytest tests/test_beta_safety_net.py -q` 全绿；Claude 全量 pytest、前端全量无新增；`bash -n` 全过；quick 门禁包含新测试。
- 交回前本机跑上面那条 pytest（Windows 上请用 WSL 或在测试里显式断言 0600 已生效）。
## 4. 让步顺序
B1、N1、N3 不可让；N2 的「过旧告警」可写理由后让；第 2 节可让。