Files
Jyotisha/docs/testing/report-density-20260922.md
T
Jesse_ChenandClaude Opus 5.5 88e89e10d9 docs(tasks): accept the report density fix and brief the database test repair
Acceptance of a12f2c0d against TASK-report-density-fix-20260923: F1 to F6
all pass. On the fixture the fact tables are 130 rows across 600 visible
cells with no engine key, no array index and no long decimal, and every
sourcePath resolves back into the packet. The first major period reads 18
years. Python and TS appendix cleaning are byte-identical. Removing the
writer table guard turns four of its six tests red. Under Node 22 the
frontend goes from 3,730 tests / 26 failing to 3,748 / 26 with an identical
list; the Python quick gate goes from 946 passed / 1 failed to 948 / 0.

One thing still fails: the database test for the report snapshot passes a
428,557-byte SQL string to psql as a single argument, past Linux's 131,072
byte limit, so it dies with E2BIG before reaching Postgres. The snapshot row
has never run against a real database. Recorded as BUG-1011 with a fix brief.

The real-person checklist the executor's tool refused to write is added here.

Privacy scan on this tree before push: zero findings.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017eEAG8HD3mm8gsKXgk8uU8
2026-09-23 15:42:29 +08:00

36 lines
3.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 报告密度:真人浏览器清单
对应任务书 `TASK-report-density-20260922.md` 与修复单 `TASK-report-density-fix-20260923.md`(BUG-1003~1007、1009、1010)。
自动化已验到这里为止(Claude 2026-09-23,实现 `a12f2c0d`):Node 22 前端 3,748 条测试,失败名单与基线逐条一致;事实表在 fixture 上 130 行、600 个可见格里没有引擎键名、数组下标或多位小数;首页仍是静态页。**下面每一条都需要登录态和真浏览器,没有做过,不能写成通过。**
前提:staging 已部署到含 `a12f2c0d` 的版本(看 `https://staging.jyotisha.chat/api/health` 的 `deployment.gitCommit`)。用受控测试账号;用虚构或公开名人的出生资料,**不要用真实个人资料**。必须是部署之后**新生成**的报告,旧报告不会补出事实表。
## 报告页
- [ ] 打开 `/reports/<id>`,正文照常,底部多出「分盘核对」和「计算数据核对表」两段。
- [ ] 「分盘核对」里的盘一张张排开、不互相压住;向下滚动不卡顿、不闪回顶部。
- [ ] 「计算数据核对表」默认收起。逐个点开 8 组:Vimshottari 主运、SAV 八分力、Shadbala 六分量、功能吉凶、Avastha 行星状态、附属星点与特殊上升点、Sade Sati 阶段框架、年度盘。
- [ ] 每张表的表头是中文列名;表格里看不到带下划线的英文字段名(形如 `sign_idx`)、方括号编号(形如 `[0]`)或一长串小数。
- [ ] Vimshottari 主运表里,每段的「年数」是整段长度(例如 18、16、19),不是 0.72 这类零头;出生时剩余年数写在表头下的说明里。
- [ ] 当前主运、当前分运那一行的「当前」是「是」,其余是「否」。
- [ ] Sade Sati 表只有上升 / 高峰 / 下降三个阶段和星座,说明里写着没有三轮起止日期。这是已知缺口,不算错。
- [ ] 手机宽度(约 390px)下,宽表只在表格区域内横向滑动,整页不横向滚动。
## 两个下载
- [ ] 点「导出报告(.md)」,下载的文件和改动前一样:只有正文,没有事实表,也没有 `parameter_sensitive`、`PyJHora`、`PL9` 这类词。
- [ ] 点「下载原始附录」,得到一份很长的 Markdown(几千行,上千行表格)。在文件里搜 `parameter_sensitive`、`PyJHora`、`JHora`、`PL9`、`cmd_full_reading`、`第 `+数字+` 页`,全部搜不到;表格里的英文字段名(如 `sign_cn`)保留,这是设计。
- [ ] 原始附录结尾有「辅助时间轴适用性」表,每个大运族一行,写明适用或不适用的原因。
- [ ] 对一份部署**之前**生成的旧报告点「下载原始附录」,应提示暂无原始附录或给出旧版附录,不应报错白屏。
## 打印
- [ ] 在「计算数据核对表」全部收起的状态下点「打印」,打印预览里 8 组表全部展开、表头每页都在、一行不被拆到两页。
- [ ] 关掉打印预览后,页面上的表恢复成打印前的收起 / 展开状态。
- [ ] 另存为 PDF,翻到事实表部分,确认 Vimshottari、SAV、BAV、Shadbala 四张表完整。
## 记录方式
每条写「通过 / 不通过 / 没法测」,不通过的截图(截图里不要带出生资料),附报告生成时间。结果交给 Claude 回填到 `docs/tasks/PROGRESS-report-density-20260922.md`。