docs(tasks): 回填 BUG-739 门禁 SHA 与 staging 部署证据

docs/tasks/PROGRESS-session-capacity-bool-assert-20260916.md

@@ -3,7 +3,7 @@
 工作树：`.worktrees/session-capacity-bool-assert-20260916`  
 分支：`codex/session-capacity-bool-assert-20260916`  
 基线：`origin/staging` @ `8cb1877e`（最近门禁路径 SHA `1e3570b4`，Gitea run `2683` failure）  
-修复提交：推送 `HEAD:staging` 后回填 40 位 SHA。
+修复提交：`7061d0d1f33b2ff6a5653004c4d5b57a6e487fb9`（已快进 `origin/staging`；门禁 run `2684` / #1336 进行中）
 
 本机 Windows。无 Docker。未改生产 SQL、未改 `.gitea/workflows/**`、未 bump Skill、未动 `page.tsx`。
 
@@ -32,4 +32,16 @@
 | `npx tsx --test tests/database-consultation-session-capacity.test.ts` | **1 skipped**（`docker unavailable on this host`），不得写成通过 |
 | `npm run test:db` | **blocked**：本机无 Docker |
 
-门禁重跑证据写在推送之后。
+## 门禁与部署
+
+| 项 | 结果 |
+| --- | --- |
+| `origin/staging` | `7061d0d1f33b2ff6a5653004c4d5b57a6e487fb9` |
+| Independent Staging Quality Gate run `2684` / #1336 | **success**（validate + publish） |
+| Migrate Staging Database run `2685` / #1337 | **success** |
+| Deploy staging run `2686` / #1338 | **success** |
+| `GET https://staging.jyotisha.chat/api/health` `.deployment.gitCommit` | `7061d0d1f33b2ff6a5653004c4d5b57a6e487fb9` |
+| `GET /login` | 200 |
+| 未登录 `GET /api/account` | 401 |
+
+本机无 Docker，真实 `test:db` 由门禁 validate 步覆盖；该步 conclusion=success。

docs/tasks/README.md

@@ -243,7 +243,7 @@
 | `TASK-consultation-external-evidence-cache-20260915.md` | `PROGRESS-consultation-external-evidence-cache-20260915.md` | **普通聊天性能单（Python；2026-09-15 产品拍板改为排在 api-server-decomposition 之前）**：每轮每域同步等外网，cProfile 前三名全是 `api.vedastro.org` 的 HTTPS 往返（0.801 + 0.786 + 0.206 s），本地 swisseph 只有 0.022 s。三个护栏数字凑不齐：前台等 1.5 s、后台跑 8 s、线程池只有 2 个 worker，且超时**不 cancel** → 每 4 秒一轮就长期饱和，之后每轮白等再拿 `official_blocked`（BUG-727）。另 `western_evidence_packet` 122 KB 前端零读取点（BUG-728）。**产品定案**：按「出生数据+岁差+交点+UTC 日期」缓存（与引擎 `_official_snapshot_reference_date` 同键，否决自定 TTL），同日 0 等待 / 跨日先用旧的（≤7 天）后台刷新 / `daily_starlanguage` 要求当天 / 冷启动才走 1.5 s。**不许「干脆不调」——那会重开 BUG-301。** 另含 staging 单域耗时实测单（代码注释里的 21 s 与本机 0.5 s 差 40 倍，三域上限就是从它推的）。BUG 段 727–728 | 已验收 | `e61535f4`（BUG-727/728）。缓存目录与 `_api_chart_cache` 分开、超时 `pending.cancel()`、`daily_starlanguage` 拒隔夜；`jyotish_api_server.py` 反而净降 43 行 |
 | `TASK-consultation-context-memory-20260915.md` | `PROGRESS-consultation-context-memory-20260915.md` | **记忆三缺口（TS，可并行）**：历史超预算时从最老整轮丢弃，`droppedCount` 算了却**全仓零读取点**，模型不知道少看了几轮——单条截断有「省略 N 字」标记，整轮丢弃没有（BUG-729，BUG-555 防复发只写了「头部截断」所以漏网）；写摘要阈值写死 16,000，历史预算却是 `clamp((窗口−60k)×1.5, 4k, 40k)`，窗口 < **70,667** 时预算低于阈值 → 每轮静默丢（BUG-730，后台上架中等窗口模型即触发）；写满时服务端存着摘要，`continueInNewChat` 只带问题不带摘要，而 `context_summary` 根本不在任何会话接口的列里（BUG-731）。**产品定案：静默继承**，且摘要文本永远不许由客户端提供（`chatSessionCreateSchema` 只收来源会话 uuid）。BUG 段 729–731 | 已验收 | `149e1ec4`（BUG-729～731）。丢整轮有两种诚实措辞；阈值由预算派生且越界直接 throw；静默继承只收来源会话 uuid，schema 仍 `.strict()` 无 `context_summary` |
 | `TASK-consultation-session-capacity-20260915.md` | `PROGRESS-consultation-session-capacity-20260915.md` | **对话上限单（一份迁移，可并行；不碰 route.ts）**：`append_consultation_question` 的 200,000 字符额度里，`thinkingText`(≤4,000) + `thinkingSections`(实测 1,521/2,243/2,977) 占一半以上，而 `techniqueTruth`/`workflowReceipt`/`agentExecutionReceipt` 照样入库却不计入——同一条上限身兼二职且两职都没做好，约 **19 轮** 就「已写满」（200 条那档永远碰不到）。**产品定案：思考文本不计入**，额度只数用户读得到的正文（约 19 → 约 50 轮），另设一条按 `length(elem::text)` 把全部字段算全的物理上限（算式取 1,000,000，写进迁移注释）护住数据库行；两档都返回同一个 `session_full`。保留 advisory lock / 幂等 / 满员拒绝（BUG-464 防复发）。BUG 段 732 | 已验收 | `dcfc2f15` / `51a65d92`（BUG-732） |
-| `TASK-session-capacity-bool-assert-20260916.md` | `PROGRESS-session-capacity-bool-assert-20260916.md` | **门禁修复**：BUG-732 的真实 Postgres 合同把期望值写成 `"false:session_missing"`，但 `fixture.psql()` 把 `boolean::text` 的 `false` 规范成 `f`。Gitea run `2683`（`1e3570b4`）唯一失败即此，staging 从 `dcfc2f15` 起带红。只改测试期望值 + 无 Docker 源码合同。BUG-739 | 待验收 | `codex/session-capacity-bool-assert-20260916` |
+| `TASK-session-capacity-bool-assert-20260916.md` | `PROGRESS-session-capacity-bool-assert-20260916.md` | **门禁修复**：BUG-732 的真实 Postgres 合同把期望值写成 `"false:session_missing"`，但 `fixture.psql()` 把 `boolean::text` 的 `false` 规范成 `f`。Gitea run `2683`（`1e3570b4`）唯一失败即此，staging 从 `dcfc2f15` 起带红。只改测试期望值 + 无 Docker 源码合同。BUG-739 | 待验收 | `7061d0d1` |
 | `TASK-freeze-metric-change-20260915.md` | `PROGRESS-freeze-metric-change-20260915.md` | **规则单（后面两单的前置，无 BUG 号）**：两条增长冻结余量都用完（`page.tsx` 1,951/1,951 余 **0**；`jyotish_api_server.py` 11,334/11,363 余 **29**），冻结从「逼新代码往外走」退化成「拦路」。实证：`page.tsx` 行数砍 59% 但 `Home()` 的 `useState` 从 56 涨到 **66**（拆的是代码不是状态）；api server **225 个类方法只有 12 处真碰 HTTP 上下文**，4 处 `__new__` 伪造空壳就是这么来的。**产品拍板换口径**：主门改成「`Home()` 的 useState/useRef 不得增长」与「类方法数 + `__new__` 计数不得增长」，行数降级为粗护栏；**同时推翻 §6「参数式 hook 内部保持 0 个 React hook」**（那正是状态搬不走的原因）。改 `AGENTS.md` §6 + 两个合同测试，不碰业务代码 | 已验收 | `3b17c1b2`。`AGENTS.md` §6 已按新口径改写，两个合同测试到位 |
 | `TASK-home-state-lowering-20260915.md` | `PROGRESS-home-state-lowering-20260915.md` | **page.tsx 状态下沉第一簇（串行在 freeze-metric-change + C2 + R3 之后）**：66 个 state 里 `rectification*` 占 **15** 个，而它们服务的 `<ConversationalBirthTimeRectification>` 本来就是 `dynamic()` 懒加载子树、挂着 24 个 props；`useRectificationSurface` 要解构约 56 个参数。把这簇搬进子树，`Home()` 的 useState 从 66 降到 ≤ 53。**零行为变化**；第一步必须先把 15 个逐个分类（只服务子树 / 外壳也要读）。产品否决了 Context Provider 与外部 store 两条路。不占 BUG 号 | 已验收 | `f8e607c2`。实测 useState 66→52、useRef 41→39、残留散装 `rectification*` state 0；冻结基线**往紧里收**；全量套件两侧完全相同（3329/fail 31）。遗留：`createRectificationShellSetters` 身份不稳多 1 条 warning，已披露，并进第二批 |
 | `TASK-rectification-engine-memoization-fix-20260915.md` | `PROGRESS-rectification-engine-memoization-fix-20260915.md` | **验收修复单（只改测试，一行实现不许动）**：BUG-721 的实现**等价性成立**（我在改前 `6b3248bf` / 改后 `e4788dfc` 同机跑同一 payload，`candidate_scores` 逐字相同），9 条计数断言全过；但等价 golden 在本机复现不出来——4 处浮点尾数差（score 1.0e-4 ×2、`margin_percent` 1.1e-3 ×2）。**复发自 BUG-712**（「不得对全精度浮点做整体 `==`」，那一单只落在 ephemeris 一处）。而 `tests/test_rectification_*.py` 在 `CORE_PYTEST_TARGETS` 里，**staging 门禁靠机器舍入碰巧一致才是绿的**。修法：主证据换成**同进程差分**（把 static context 的四个缓存键置 `None` 即可回退旧路径，A/B 严格相等），golden 降为离散字段严格相等 + 浮点带容差（容差按实测 1.1e-3 推）；**禁止重建 golden 来「修」**。另含六份 golden 的仓库级排查。BUG-733 | 已验收 | `2b7b4565`（BUG-733）。同进程差分立为主证据，golden 降为离散严格+浮点容差；本机 14 条全绿 |