Merge remote-tracking branch 'origin/staging' into codex/upstream-sync8-finish-20261018

# Conflicts:
#	CHANGELOG.md

docs/tasks/PROGRESS-people-archive-limit-20-20261017.md

@@ -0,0 +1,29 @@
+# 进度：星盘档案上限 20 人（2026-10-17）
+
+基线 `origin/staging` = `e7bf60c1f`。分支 `codex/people-archive-limit-20-20261017`。不新增 BUG 编号。
+
+星盘档案现在最多 20 人（本人 + 19 个其他人）。第 19 个其他人可以保存，第 20 个其他人被拒绝。界面上的限额句由常量拼出。人多时，档案列表和标题旁 / 聊天里的人物菜单在自己的框里上下滚动。
+
+生产部署前要先跑迁移 `frontend/supabase/migrations/20261017010000_chart_profiles_limit_20.sql`。旧迁移文件没有改。建档仍不扣点。
+
+| 检查 | 命令 | 结果 |
+| --- | --- | --- |
+| 数据库：第 19 个他人可存，第 20 个他人被拒；并发锁仍在新门槛上生效 | `npx tsx --test --test-concurrency=1 tests/database-chart-subject.test.ts` | 4 通过，0 失败 |
+| 同上两条在全量里 | `npm test` 中的对应子测试 | `ok`（全量编号 1643、1645、2114） |
+| 20 人列表限高并纵向滚动 | `tests/people-archive-view.test.tsx` | 通过，含新增「twenty saved people…」 |
+| 类型检查 | `npx tsc --noEmit` | 0 错误 |
+| 代码规范 | `npm run lint` | 0 个错误，123 条原有警告 |
+| 前端全量 | `npm test` | 5037 条：通过 4971，失败 66，取消 0，退出码 1 |
+| 首页构建 | `npm run build` | 成功。`/`、`/people`、`/chart`、`/ephemeris`、`/reports` 仍是静态页 |
+
+66 条失败都是这台 Windows 机器上的环境问题，不是这次限额断言：
+
+- 31 条：`tsx` 解析 `tailwind-merge` 失败
+- 4 条：路径被拼成重复盘符 `G:\G:\...`
+- 其余：shell 脚本退出码 9009、临时目录被占用、`docker ENAMETOOLONG`
+
+没有一条失败名是档案上限、限额句或 20 人滚动。本机没有再对 `e7bf60c1f` 单独构建一次，所以没有改动前后的首屏 gzip 对照数。这次进首屏的代码只有人物菜单的上限常量，样式只加了两段限高滚动。
+
+`frontend/src` 里已经没有写死的「5 个人」。测试注释里的「原值」仍保留这句，用来对照改过的断言。更早的任务书仍写着当时的 5 人决定，没有改写。
+
+真人核对仍按 `docs/testing/people-archive-p1-20260924.md` 和 `docs/testing/people-ephemeris-ui-20260926.md`：满 20 人时三处列表可滚动，手机宽 390px 不出现横向滚动。

docs/tasks/README.md

@@ -500,7 +500,7 @@
 | `TASK-api-server-service-extract-20261013.md` | — | API 单体第一阶段：拆出不带 HTTP 的计算类，生产伪造 handler 归零 | 待领取（排队：dasha-unify） | `codex/api-server-service-extract-20261013` |
 | `TASK-data-layer-types-20261013.md` | `PROGRESS-data-layer-types-20261013.md` | 数据访问层改用自己的 DataClient 类型第一阶段（BUG-1351；任务书预留的 1343 已被更大编号越过） | 待验收 | `codex/data-layer-types-20261013` |
 | `TASK-contracts-helpers-dedupe-20261013.md` | — | 前后端契约与小工具去重第一阶段 | 待领取（排队：frontend-dead-code、consult-route-split） | `codex/contracts-helpers-dedupe-20261013` |
-| `TASK-people-archive-limit-20-20261017.md` | — | 星盘档案上限 5→20 人（触发器新迁移 + 常量 + 文案；婚恋合盘前置单） | 待领取 | `codex/people-archive-limit-20-20261017`；动表，需 test:db |
+| `TASK-people-archive-limit-20-20261017.md` | `PROGRESS-people-archive-limit-20-20261017.md` | 星盘档案上限 5→20 人（触发器新迁移 + 常量 + 文案；婚恋合盘前置单） | 待验收 | `codex/people-archive-limit-20-20261017` |
 | `TASK-marriage-match-p1-20261017.md` | #79 | 婚恋合盘引擎（搬上游 bde5d615：marriage_match + 合盘证据包；35 分七项、不分男女；第六版不扣点、不做页面）（BUG-1370 起） | 待执行（不再等 #78） | `codex/marriage-match-p1-20261017`；动表 |
 | `TASK-full-reading-module-parity-20261018.md` | #81 | full-reading 补齐上游 5 个模块（西占层文件没搬致永远 blocked、Navamsha / Niryaana 用我们自己的实现填键、Lagna Vargottamamsa / Pushkara / Punarphoo）（BUG-1375 起） | 待执行（可与 #78 并行） | `codex/full-reading-module-parity-20261018` |
 | `TASK-synastry-full-report-20261018.md` | #82 | 婚恋合盘：选人页 + 完整合盘报告（关系画像九节：结论+折叠的分析逻辑+关系时间线+技术依据摘要；英文按需；计费键 synastry.full） | 排队（等 #78、#79、#81） | `codex/synastry-full-report-20261018`；动表 |

docs/tasks/TASK-marriage-match-p1-fix-20261018.md

@@ -0,0 +1,57 @@
+# TASK · 婚恋合盘第一期 · 修复单（issue #79，第 1 次打回）
+
+- 日期：2026-10-18
+- 被验提交：`cf063834ca9f9f62dc8559913dddb5ccb8578999`（分支 `codex/marriage-match-p1-20261017`）
+- 原任务书：`docs/tasks/TASK-marriage-match-p1-20261017.md` 第六版（下称「原单」）
+- 执行方：Grok，同一分支追加提交；`origin/staging` 前进时用 `git merge origin/staging`，不 rebase（合并时 `CHANGELOG.md`、`docs/tasks/README.md` 会有纯文档冲突，按两边都保留处理）
+- BUG 编号：沿用 BUG-1370～1374，不新开号
+
+## 验收结论（Claude，Linux）
+
+引擎与上游搬运部分**通过**；存储层（T4/T5）与原单不符，打回。
+
+| 项 | 结论 | 证据 |
+| --- | --- | --- |
+| T1 上游原样搬入 | 通过 | `scripts/marriage_match.py` 与 `docs/research/upstream_marriage_match_bde5d615/marriage_match.py.txt` 逐字相同；`skills/jyotish-full-synastry-reading/` 全部文件与副本（去 `.txt`）逐字相同；上游测试只改了调用那一处并写了三栏 |
+| T1 生产依赖 | 通过 | 屏蔽 `jhora` 后两位公开名人的证据包 `delivery_readiness = ready_for_narrative`，截取结果与 `frontend/tests/fixtures/synastry-full-dossier-truncated.json` 相同 |
+| T2 接口 | 通过 | 主文件只加 14 行薄注册；证据包接口进了 `HEAVY_COMPUTE_PATHS`，按两人出生资料 + 提交号做磁盘缓存 |
+| T3 退役 | 通过 | `scripts/synastry.py` 已删；CLI 改为 `marriage-match`；`calc_kuja_dosha` / `match_kuja_dosha` 标为旧版 |
+| **T4/T5 存储** | **未通过** | 见 F1、F2 |
+| 全量 pytest / 前端 | 见 issue 评论里的数字 | — |
+
+## F1 · 存了整份证据包，而且存了两份（必做）
+
+`frontend/src/lib/marriage-match-service.ts::readResolvedPair` 把引擎返回的整个包（`rules_version` + `dossier` + `raman_marriage_match`）同时写进 `report` 和 `structured_result` 两列。实测（爱因斯坦 × 乔布斯，公开盘）：整包约 **490 KB**，其中两个 profile 的 `marriage_match` 合计只有约 **19 KB**。
+
+问题：
+
+1. **与原单不符。** 原单 T5：「存结构结果（**两个 profile 的 `marriage_match`**）并返回证据包」；T4：加列存「结构化结果」。证据包是写作素材，不是要长期存的结构结果。
+2. **会过期。** 证据包里有 `parallel_timing_context` 等随「今天」变化的内容，而命中条件只有「两人出生资料指纹 + 规则版本」，不含日期。整包存下来，以后每次命中都会读到建档那天的时间背景。`marriage_match` 本身只依赖两张盘，没有这个问题。
+3. **一行近 1 MB。** 旧的合盘历史接口 `app/api/synastry-reports/route.ts` 的 GET 会 `select("id, partner_name, report, created_at")` 取最近 10 行；新行的 `report` 是整包，开了 `compatibility` 后一次就可能拉近 10 MB，而且形状不是旧卡片能读的。
+
+修法：
+
+- `structured_result` 只存 `{ rules_version, default: <dossier.marriage_match>, raman: <raman_marriage_match> }`（键名可定，写进进度）。
+- `report` 列（旧列，`not null` 且必须是对象）**不放证据包**：放同一份结构结果，或一个只含 `rules_version` 的小对象，二选一写进进度。
+- 函数返回值区分两种：现算时返回 `{ cached: false, structured, dossier }`；命中时返回 `{ cached: true, structured }`，**不返回旧证据包**。后续单 #82 需要证据包时自己调证据包接口（Python 侧有磁盘缓存）。在原单「后续单」一节或进度里写明这个约定。
+- 旧历史接口 GET 加过滤 `rules_version is null`，只列旧行；新行不进旧列表。
+
+验收：
+
+- 单测：存进去的 `structured_result` 不含 `dossier` / `chart_snapshots` 键；大小断言（如 < 64 KB）用 golden 结构结果。
+- 单测：命中时不调引擎，返回值不含证据包。
+- 旧历史接口有一条测试证明新行不出现在 GET 结果里（可用源码文本断言或现有 route 测试模式，按 AGENTS §7.8 不弱化旧断言）。
+
+## F2 · 并发同一对人时第二个写入报「存储失败」（必做，小）
+
+唯一索引 `synastry_reports_pair_fingerprint_uidx` 会让同时发起的第二次插入失败，现在直接抛 `store_failed`。改为：插入遇到唯一冲突（PostgreSQL `23505`）时重读一次已保存行并返回；重读仍为空才报 `store_failed`。加一条单测。
+
+## 不要做
+
+- 不改 `scripts/marriage_match.py`、`skills/jyotish-full-synastry-reading/**`（上游原样）。
+- 不做页面、不扣点（原单第六版）。
+- 迁移文件可以在同一份里改（还没上过 staging），不要另开第二份迁移去补救本单自己的列。
+
+## 回报
+
+issue #79 回报新 SHA，写明：结构结果的键名与大小、`report` 列选了哪种、旧历史接口的过滤和测试、`npm run test:db` 中 `database-marriage-match.test.ts` 的结果（Windows 已知失败名单逐条对照）。

docs/testing/people-archive-p1-20260924.md

@@ -2,7 +2,7 @@
 
 没有登录浏览器。下面每一步都还没在浏览器里做过。用虚构人物，不要填真实姓名、生日或坐标。
 
-1. 登录后打开「星盘档案」，添加四个虚构人物。第五个添加按钮应禁用，并看到「最多保存 5 个人的星盘」。本人不能删除。
+1. 登录后打开「星盘档案」，添加十九个虚构人物（连本人一共 20 人）。第十九个他人可以保存。第二十个他人应被拒绝，添加处看到「最多保存 20 个人的星盘」。本人不能删除。满 20 人时，档案列表、标题旁的人名、聊天里的人物选择都能上下滚动，不把页面撑出屏幕。手机宽 390px 时这三处都不出现横向滚动。
 2. 在对话、星盘、星历、我的报告之间切换当前人物。四个页面和侧栏历史应一起换成这个人，不要先闪出上一个人的盘。
 3. 在已经发过消息的对话里换成另一个人。应切换当前人物，并打开一段空对话。空对话里切换应直接改绑，不新开对话。
 4. 删除一个有对话和报告的虚构人物。确认句应是「将同时删除 N 个对话和 M 份报告，无法恢复。」确认后对话和报告一起消失。若删的是当前人物，回到本人。
@@ -33,6 +33,6 @@
 | 星语与资料更新 | 户主无分钟、他人完整；再修改他人资料 | 他人星语可加载；资料变化后指纹更新，不复用旧当天结果 | 待验 |
 | 合盘上下文 | 从他人档案点「和我合盘」 | 我为本人；该对话绑定本人，不改全局人物，题中对方正确 | 待验 |
 | 星历暖进/首败 | 同人物暖返回；冷进首请求模拟429/坏包再恢复 | 暖进无额外重复日期请求；首败可重试，不永久停在等待句 | 待验 |
-| 回填纠偏/上限 | 受控旧档案升级、两窗口同时抢最后名额 | 未验证JSON状态不冒充已校正；本人资料不变；最多四个他人 | 待验 |
+| 回填纠偏/上限 | 受控旧档案升级、两窗口同时抢最后名额 | 未验证JSON状态不冒充已校正；本人资料不变；最多十九个他人 | 待验 |
 
 发布验收另核对最终组合Linux Node22全量fail0、基线测试名称无消失、标准DB、build Static/gzip和staging health部署SHA。未完成前不写已部署或resolved。

docs/testing/people-ephemeris-ui-20260926.md

@@ -6,7 +6,7 @@
 
 1. 打开侧栏「星盘档案」：看到一张张人物卡片，不再挤成一行。每张卡有圆形头像、名字，本人后面有灰色「本人」小标签，下面一行是「出生日期 · 排盘时间 · 城市」，右边一个「›」。
 2. 顶栏「当前星盘」是谁，谁的卡片就是橙色描边 + 浅橙底。切到别人后回到这页，高亮跟着换。
-3. 最下面是虚线框「＋ 添加一个人」，下面小字「还可以保存 N 个人」。N = 5 − 现有人数。存满 5 个人时框变灰、点不动，下面写「最多保存 5 个人的星盘」。
+3. 最下面是虚线框「＋ 添加一个人」，下面小字「还可以保存 N 个人」。N = 20 − 现有人数。存满 20 个人时框变灰、点了会提示，下面写「最多保存 20 个人的星盘」。满 20 人时列表在自己的框里上下滚动，不把页面撑出屏幕。手机宽 390px 时档案列表、标题旁人名、聊天人物选择都不出现横向滚动。
 4. 点任意一个人：整页换成这个人的详情，顶部有「‹ 返回」。
 5. 点「‹ 返回」回到列表；再点进一个人后，用 Safari 左滑返回（或浏览器返回键），也回到列表，而不是离开这一页。
 6. 详情里：头像 + 名字 +「本人 · 出生地」（别人只写出生地）；两格时间卡「填报时间」「排盘时间」。做过生时校正并采用的本人，排盘卡是绿色、写「排盘时间 · 已校正」；没校正过的人两张卡都是普通白卡。