chore(polish): integrate toasts, reports paging, loading motion; login centring floor for short windows; load-more uses notifyError; round records

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N4f2nya58RoRu4yEmJgRGE

docs/tasks/PROGRESS-notice-loading-polish-20260930.md

@@ -0,0 +1,40 @@
+# PROGRESS：提示浮层 / 登录页 / 我的报告 / 加载动画 / 星盘气泡（2026-09-30）
+
+直接执行模式（产品 2026-09-30「请你继续」）。基线 `origin/staging` 3177ffe6 → 90b1b6fb。三个 fork 并行、Claude 合并并独立验收。
+
+## 产品决策
+
+| 项 | 决定 |
+| --- | --- |
+| 性别入口 | 只在星盘档案编辑表单；个人资料删掉（BUG-1119，已部署 90b1b6fb） |
+| 提示位置 | 顶部居中浮层；成功/信息 3 秒，报错 6 秒带关闭；带「重试」的页面级失败状态留在页面 |
+| 星盘加载 | 宫位依次点亮（去掉中间 logo 圆环） |
+| 报告分页 | 每次 10 份 +「加载更多」 |
+
+## 交付
+
+| 提交 | 内容 | BUG |
+| --- | --- | --- |
+| `3e29b697` | 个人资料删性别 | 1119 |
+| `90b1b6fb` | 星盘气泡频闪（全局 tooltip 规则关掉舞台指针事件）；表格圆角 | 1120 |
+| fork B `4ffc0ab2` | `/reports` 静态外壳 + 复用预取；游标分页 10 份 +「加载更多」 | 1123、1124 |
+| fork C `d2e24fcb` | 宫位依次点亮；档案/人物切换用轨道动画；今日一句不再揭幕后跳入 | 1125 |
+| fork A `dd28089e` | 全站操作结果/报错改顶部浮层（`src/lib/notify.ts`）；登录卡居中 | 1121、1122 |
+| 合并补丁 | 报告「加载更多」失败走 `notifyError`；登录页去掉仅顶部内边距、行下限 56px、卡片最小高度 `100dvh - 128px`（验收中发现窗口 ≤760px 时页脚压卡片） | 1122 |
+
+## 验收（Claude，合并后分支 `codex/polish-integrate-20260930`）
+
+| 项 | 结果 |
+| --- | --- |
+| `tsc --noEmit` | 0 |
+| `npm run lint` | 0 error（126 warning，均为既有） |
+| `npm test` | 4,487 条，失败 24 条，与基线 `sf8.fails` 逐条相同；0 cancelled |
+| `next build` | 通过；`/`、`/reports`、`/people`、`/chart` 均 ○ Static（`/reports` 由 ƒ 变 ○） |
+| 首屏 gzip-9 | 652,948 → 652,838 B（−0.02%） |
+| 本机 Chromium | 星盘气泡：同一移动序列下气泡不再移除/插入；表格圆角截图；登录页 1440×900 / 760 / 700 卡片上下留白相等、页脚不压卡片；未勾同意 → 顶部红色提示 + 勾选框描红；关闭按钮在提示右侧 |
+| 环境缺口 | 本机无登录后端，发送验证码成功路径、`/people`、`/reports` 真数据、首页冷启动今日一句未在浏览器走，列入 `docs/testing/notice-loading-polish-20260930.md` |
+
+## 验收中的教训
+
+- 本机 `next build` 复用了 `.next` 下的旧 CSS 块（Turbopack 缓存），第一轮截图全是旧样式；清掉 `.next` 重建后才正确。浏览器验收前先确认页面引用的 CSS 块含本轮新规则。
+- 旧 `next-server` 进程仍占 3917 端口时，新 `next start` 静默失败，页面拿到旧 HTML 引用已删除的 CSS。

docs/tasks/README.md

@@ -381,6 +381,7 @@
 | `TASK-rectification-cross-midnight-dasha-fix-20260920.md` | `PROGRESS-rectification-cross-midnight-fix-20260920.md` | **BUG-984 缓存与结果身份补单（BUG-981 的端到端阻塞项）**：`scoreAndPersistCurrentEvidence()` 的 `block_scan` 分支只比 `evidenceLedgerFingerprint` 即返回 `cached:true` 与旧 `algorithmVersion`，该返回发生在 `readV9EngineScoringIdentity()` **之前**；`minute` 分支则有身份门。F3 已查证完整调用链到 `merge_transition_proximity()`，故核心修复合入后，**证据未变的历史跨午夜时段缓存命中仍返回修复前分数**——在本单闭环前不得声称跨午夜问题已修。边界已按源码收窄：`late_night`(23:00–03:59) 跨日；`unknown`(00:00–23:59) 虽 >120 分钟但**本身同日**，选中跨午夜子时段后才触发（此处修正了 Claude 先前把两者并列的说法）。产品 2026-09-20 放行且**同日拍板 F3 策略选 b**：版本接口取不到可信身份时，旧缓存**只读展示 + 显著标注「按旧算法产出」**，否决 a（重算，会把接口抖动放大成长等待，时段扫描受 `JYOTISH_HEAVY_COMPUTE_CONCURRENCY=2` 限流）与 c（照常复用，与已定原则冲突）。b 的三条边界：只读结果**服务端拒绝采用/确认**（靠删不靠藏，须有定向用例）、标注必须用户可见并对照 `VOICE.md`（涉界面同提交更新 `DESIGN.md`）、回执来源身份仍是产出它的版本。**F2 的 SQL 问题已查清并定序（A 先上 / B 兜底 / 第 10 版前必须解决）**：`engine_version` 一个字段被「部署声称的版本」（started/failed 行，取前端常量）与「实际产出结果的版本」（completed 行，命中旧缓存即旧版本）共用，聚合却用与版本先后无关的字符串 `max`。**该缺陷此前一直撞对，`aa46da10` 之后才变真错**：它把 `v9EngineVersion()` 缺省由 `rectification-v5` 改为 `…scoring-8`，started 行遂在字符串序上反超 completed 行 → 回执显示第 8 版而分数来自第 7 版缓存；已核 `deploy/`、`.gitea/` 未设 `RECTIFICATION_ENGINE_VERSION`，走缺省，**是真实行为**。第二个缺陷：实跑 `max("…-10","…-9") = "…-9"`，**该聚合在第 10 版静默反向**（现为第 8 版）。A＝started/failed 不再写版本（应用层，必做）；A 的漏洞（同 turn 多个 completed 行版本不同）**必须实测取证，不得以「应该不会」结案**；B＝聚合改取成功结果那一行（只改函数体，向后兼容）；C＝拆列本单不做。**四项全部可开工。**硬红线：不重标/不删历史结果，不 bump Skill，不改 V4 input contract，不引入按 `engineVersion` 拒绝打开历史会话。串行：BUG-985 合入 → 本单。BUG-984 | **已合入（无独立验收记录）**：执行方自报全量 3588 全绿、标准 DB 40/40；`d575e89a` + `8d0359fc` 已在 staging 并部署（run 2824）；BUG-984 仍 investigating，受控真人欠 | `d575e89a`（F2 A）+ `8d0359fc`（B 与 diagnostics 追加，迁移 `20260920010000_rectification_receipt_result_identity.sql`） |
 | `TASK-rectification-midnight-final-grok-20260921.md` | `PROGRESS-rectification-midnight-date-anchor-20260920.md` | **日期锚点最终验收接续（Grok）**：测试契约复验、扩展身份四模块、真实新 freeze 与 20/900、final-3 全门。不 commit/push/deploy。 | **已验收**（并入 `b85c4a68`，见下一行）：隔离 Linux 门通过（tsc/lint0、前端3649、DB56、quick、AA 21/21、0 新增 Python 失败）；四既存失败仍在；真人缺口见 BLOCKED | `b85c4a68`（分支 `codex/rectification-midnight-date-anchor-20260920` 提交后合入 staging） |
 | `TASK-rectification-midnight-date-anchor-20260920.md` | `PROGRESS-rectification-midnight-date-anchor-20260920.md` | **跨午夜的日期锚点与簇跨度（BUG-982 + BUG-983 合并一单）**：两条同根——线上契约只传钟点、日期不在契约里，后端按钟点大小**猜**哪端跨日。**BUG-983 是静默算错盘**：`_candidate_datetimes()` 把起始钟点无条件绑在申报日期上，前端零补偿。Claude 实测（申报日 2000-06-15）：申报 `00:10` → 候选 `06-15 23:55`…`06-16 00:25`，**申报分钟本身落在 `06-16 00:10`，+1 天**；`00:02` 同样 +1 天；`12:00` 对照正确。受影响：申报落在午夜后半径内者（±15≈1.0%、±30≈2.1%、±60≈4.2%、±120≈8.3%）；`late_night`(23:00–03:59) 更重，其 `00:00`–`03:59` 共 240 分钟**全部落在用户没申报过的日期上**。**BUG-982 影响面比原记录大**：同缺陷在链路上出现三处（`_cluster_span` / `unionStillValidRange` / `indistinguishableWidthMinutes`），原记录只写了 Python 两处。实测跨午夜簇 `23:58/23:59/00:00` 报告宽度 **1440 分钟**（真实 3）、`23:50/23:55/00:05` 报 **1431**（真实 16）；该链经 `reportWidth` 直达 **交付卡「范围 X 分钟」**，深夜用户会看到候选其实差几分钟却被告知范围一千多分钟。**与 BUG-981 的关系**：981 让每个候选按自己日期算 Dasha 是对的，但 983 给的日期本身就错，**983 不修则 981 在申报近午夜的场景等于没上线**。**产品 2026-09-20 三点全部拍板**：D1 `late_night` **先问用户「午夜前还是午夜后」，答不上退「同日两段」`[D 00:00–03:59] ∪ [D 23:00–23:59]`，一律不得跨到 `D+1`**（连锁范围：退路产生**不连续候选集**，枚举/聚类/簇跨度/交付区间/宽度/交付卡都要支持两段，**不得用「取两段最小到最大」糊成一段**——那正是 982 的同型错误）；D2 **允许窗口跨到前一天**，但交付层必须说明「若落在 23:5x 则出生日期是前一天」，不得静默改用户的出生日期（依据 Part B B4 真值覆盖率优先）；D3 **加窗口相对序号**，排序/取首尾/算跨度一律用序号、钟点只作展示 —— 序号入契约会改候选身份与缓存指纹，**必须核对 BUG-984 的 `scoringIdentityMatches` 并确认历史结果只读不被重标**。硬红线：不调打分常数/确认门阈值；不得以排除真值换窄宽度；不得只修 `_cluster_span` 就宣称 982 已修；非跨午夜必须逐位不变且用同机 A/B（不得写死跨机浮点哈希，见 BUG-985）。沿用 BUG-982/983，不新开号 | **已验收通过并合入 staging**（2026-09-21，`b85c4a68`）；已部署 staging（run 2831）；真人验收待完成 | Claude 独立复核（用当初复现两条 Bug 的同一探针重跑）：**BUG-983** 新契约下申报 `00:10`/`00:02` 的申报分钟落在**申报日**（+0 天），`late_night` 300 个候选**全在同一日**、两段；**BUG-982** 跨午夜 3 分钟簇 → **3 分钟**（原 1440），同日两段 → **300 分钟**（未糊成 1440）。三处（`decision_policy.py`/`credible-range.ts`/`candidate-plateau.ts`）均已改。**非跨午夜分数同机 A/B 6/6 逐位相同**；新测试在基线 6 条红、修复后全绿；Python `test_rectification_*` 基线 216 → **272 passed / 0 failed**；`tsc --noEmit` 退出 0。红线全清：打分常数零改动、`status=not_ready`、coverage 0、`holdout_passed()` False、Skill 未动、`official_eval_trial_count` 仍 0。D1 追问 4 选项含「不知道」「跳过」，均退同日两段、从不去 `D+1`，明写不计分可跳过；D2 交付层显示「（前一天）」；D3 用 `window_index`/`segment_index`，`interval_union_width` 按段求和（注释 “never fill a declared segment gap”）。超出要求的设计：`candidate_intervals` 拒绝重复钟点；engine-client 对 dated 路径 fail-closed 抛 `engine_invalid_candidate_decisions`。环境缺口：3 条前端测试在 Claude 机器红，但**同样的 `@/` 别名错误在既有测试上一模一样复现**（`ephemeris-route`、`api-service-unavailable`），非回归；无 Docker 故 `test:db` 未跑。**遗留待确认**：无 `cluster_intervals` 的行仍走旧按钟点算法（宽度仍 1440），应确认除修复前旧缓存外没有别的生产路径会产生无日期行 |
+| （直接执行，无任务书） | `PROGRESS-notice-loading-polish-20260930.md` | 性别只在档案（1119）、星盘气泡频闪与表格圆角（1120）、全站顶部浮层提示（1121/1122）、我的报告提速与分页（1123/1124）、宫位点亮等待与今日一句不跳（1125） | **已验收，推 staging**；真机清单 `docs/testing/notice-loading-polish-20260930.md` 待产品 | 合并分支 `codex/polish-integrate-20260930` |
 
 ## 命名与归档