fix(consult): drop traces, budget checkpoints, silent summary inherit

BUG-729: dropped history rounds leave an omission marker in the model-visible summary slot.
BUG-730: checkpoint threshold is 0.4 of historyBudgetChars (128k still 16,000).
BUG-731: session_full new chat copies owned context_summary on the server; clients send only continued_from_session_id.

docs/BUG_HISTORY.md

@@ -11332,3 +11332,51 @@
 - 相关记录：BUG-727
 - 复发自：无
 - 修复版本：待发布
+
+## BUG-729 | 咨询历史丢掉整轮时模型看不见任何痕迹
+
+- 状态：resolved
+- 首次发现：2026-09-15
+- 最近更新：2026-09-16
+- 影响面：`consultationHistoryWindow`、`consultationUserTurnContent`、`POST /api/consult`
+- 用户现象：历史超过模型预算后，追问「刚才你说的那个时间」时模型当成从没说过。单条超长会写「省略 N 字」，整轮被丢掉时什么都不留。
+- 触发条件：普通咨询多轮之后，尾巴字符数超过当前模型的历史预算，窗口从最旧整条丢弃。
+- 根因：`droppedCount` 算出来了，`route.ts` 只取 `.tail`。BUG-555 的防复发只写了「不得再按固定 12 条 × 头部截断静默砍结论」，整轮丢弃不在字面里，所以没拦住。
+- 修复：`droppedCount > 0` 时在摘要槽追加与 `omissionMarker` 同风格的说明。有摘要时写「更早的 N 轮问答已并入上面的会话摘要」；没有摘要时诚实写结论尚未并入。`droppedCount === 0` 不加这句话。
+- 验证：超预算历史的模型可见文本含丢弃说明且轮数等于 `droppedCount`；零丢弃不加这句话；源码合同断言 `route.ts` 读取 `historyWindow.droppedCount`。
+- 防复发：咨询历史任何形式的丢弃（截断单条、丢整轮）都必须在模型可见文本里留痕。
+- 相关记录：BUG-555
+- 复发自：BUG-555（防复发只覆盖头部截断）
+- 修复版本：待发布
+
+## BUG-730 | 写摘要的阈值写死 16,000，追不上按窗口算出的历史预算
+
+- 状态：resolved
+- 首次发现：2026-09-15
+- 最近更新：2026-09-16
+- 影响面：`historyBudgetChars`、`consultationHistoryCheckpointChars`、`shouldCheckpoint`、`checkpointSessionContextSummary`
+- 用户现象：后台上架中等上下文窗口的模型后，每轮静默丢掉最老的几轮问答，摘要却还没开始写。
+- 触发条件：模型 `context_window` 低于约 70,667（例如 64k / 32k）。历史预算已经小于写死的 16,000 字阈值。
+- 根因：`shouldCheckpoint` 用常量 16,000，`consultationHistoryWindow` 用 `historyBudgetChars()`。两个数各写各的，没有「阈值必须低于预算」的断言。
+- 修复：阈值改为预算的 0.4（默认 128k 窗口仍是 16,000）。运行时断言阈值 < 预算。检查点把会话模型的 `contextWindow` 传进去。
+- 验证：表驱动覆盖 200k / 128k / 64k / 32k / null，逐条 `checkpoint < budget`；128k 仍为 16,000。
+- 防复发：触发摘要的阈值必须由历史预算派生，并由一条断言钉死「阈值 < 预算」在所有合法上下文窗口下成立。
+- 相关记录：BUG-555
+- 复发自：BUG-555（检查点阈值与窗口预算未绑在一起）
+- 修复版本：待发布
+
+## BUG-731 | 对话写满后开新对话不继承服务端已有的会话摘要
+
+- 状态：resolved
+- 首次发现：2026-09-15
+- 最近更新：2026-09-16
+- 影响面：`chatSessionCreateSchema`、`POST /api/sessions`、`continueInNewChat`、`startNewChat`
+- 用户现象：这段对话已写满、点「开新对话」之后，模型对刚才的结论一无所知，用户被要求从零开始。
+- 触发条件：`append_consultation_question` 返回 `session_full`，客户端走「开新对话」。
+- 根因：新会话是空的。`context_summary` 不在列表 GET 列里，创建合同也不接收它。即便前端想带，也没有合法入口。
+- 修复：创建合同增加可选 `continued_from_session_id`（保持 `.strict()`，不加 `context_summary`）。服务端按当前用户读源会话摘要，读到才写入新行；读不到、不属于该用户、或为空都静默跳过，仍返回 201。写满出口把当前会话 id 带进创建请求。界面不加「接着上次聊」之类提示。
+- 验证：带来源 id 时新行摘要等于源会话；源会话属于别人时新行无摘要且 201；源码合同断言创建 schema 没有 `context_summary` 字段；写满后「开新对话」没有新增提示文案。
+- 防复发：会话满员后的「开新对话」出口必须由服务端继承 `context_summary`；摘要文本任何时候都不得由客户端提供。不得把 `messages` 加回列表 GET。
+- 相关记录：BUG-464、BUG-555
+- 复发自：无
+- 修复版本：待发布

docs/tasks/PROGRESS-consultation-context-memory-20260915.md

@@ -0,0 +1,60 @@
+# PROGRESS · 普通聊天的三条记忆缺口（2026-09-16）
+
+工作树：`.worktrees/consultation-context-memory-20260915`  
+分支：`codex/consultation-context-memory-20260915`  
+任务书基线：`origin/staging` @ `6b3248bf`；开工时本 worktree 在 `11893c7f`（任务书已合入 staging）。  
+本机 Windows。Skill **未 bump**。未改 `frontend/src/app/page.tsx`、数据库、依赖。
+
+开工核对：`docs/BUG_HISTORY.md` 最大号 **BUG-720**。校正四单预占 721–726、external-evidence-cache 预占 727/728，本单使用预占 **BUG-729 / 730 / 731**，无冲突。
+
+## 任务状态
+
+| 任务 | 状态 | BUG |
+| --- | --- | --- |
+| 5.2 写摘要阈值跟着预算走 | 完成 | BUG-730 |
+| 5.1 丢整轮必须留痕 | 完成 | BUG-729 |
+| 5.3 写满时静默继承摘要 | 完成 | BUG-731 |
+| 5.4 Bug 历史 | 完成 | 729/730/731 |
+
+## 实现要点
+
+- **BUG-730**：删除写死的 `CONSULTATION_HISTORY_TAIL_MAX_CHARS = 16_000`。新函数 `consultationHistoryCheckpointChars(window)` = `floor(historyBudgetChars(window) × 0.4)`，并运行时断言阈值 < 预算。128k 仍是 16,000。`shouldCheckpoint` / `checkpointSessionContextSummary` 吃 `contextWindow`；consult 把会话模型窗口传进去。
+- **BUG-729**：`droppedCount > 0` 时在 `consultationUserTurnContent` 的摘要槽追加与 `omissionMarker` 同风格的说明。有摘要：「更早的 N 轮问答已并入上面的会话摘要」；无摘要：「更早的 N 轮问答未能进入本轮上下文，结论尚未并入会话摘要」。`droppedCount === 0` 不加。`route.ts` 四条用户回合都读 `historyWindow.droppedCount`。
+- **BUG-731**：`chatSessionCreateSchema` 增加可选 `continued_from_session_id`（保持 `.strict()`，**不加** `context_summary`）。`POST /api/sessions` 按当前用户读源会话摘要，读到才写入新行；读不到 / 别人的 / 空都静默跳过，仍 201。`continueInNewChat` 把当前会话 id 传给 `startNewChat`。界面无新文案。
+
+未改摘要机制本身（800 汉字、15 秒 ref 计时器、乐观并发、结算后异步）。未用 `AbortSignal.timeout()` 替换摘要超时。未把 `messages` 加回列表 GET。未动数据库。
+
+## 既有断言改动
+
+| 文件 | 原值 | 新值 | 原因 |
+| --- | --- | --- | --- |
+| `session-context-summary.test.ts` | `CONSULTATION_HISTORY_TAIL_MAX_CHARS === 16_000`；`shouldCheckpoint` 只测 15_999 / 16_001 | `consultationHistoryCheckpointChars(128_000) === 16_000`；另测 64k 阈值 2_400 | BUG-730：阈值由预算派生，128k 行为与改前一致 |
+| `chat-session-write.test.ts` 源码合同 | `const { id, updated_at: _ignoredClientClock, ...values } = parsed.data` | 另拆 `continued_from_session_id`，不随 values 插入 | 该字段不是表列 |
+| `chat-session-url.test.ts` / `composer-isolation-contract.test.ts` | 切片起点 `async function startNewChat()` | `async function startNewChat(` | 可带来源会话 id |
+| `consultation-context-cache-contract.test.ts` | 检查点不传窗口 | 传 `sessionContextWindow`；历史文件不得再出现字面量 `16_000` | BUG-730 |
+
+128k 检查点阈值：**原值 16,000 / 新值 16,000 / 原因** 比例 0.4 × 预算 40,000。未弱化其它既有断言。
+
+## 测试
+
+| 命令 | 结果 |
+| --- | --- |
+| `./node_modules/.bin/tsc --noEmit` | **0 错** |
+| `npm run lint` | **0 error**（119 条既有 warning；本单未新增 error） |
+| 本单相关 `npx tsx --test`（history / summary / cache contract / chat-session-write / authority / url / composer-isolation / consultation-context） | **69 pass / 0 fail** |
+| `npx tsx --test tests/consultation*.test.ts tests/chat-session-*.test.ts tests/session-*.test.ts` | 264 项 / 252 pass / **12 fail**：3 个文件级失败 + 9 条 methodology，全是 Windows `SkillPackageRegistryError`（EPERM symlink），与本单文件无关 |
+| `npm test`（`tests/*.test.ts tests/*.test.tsx`） | `# tests 3110 / # pass 3023 / # fail 73 / # skipped 14`。失败清单不含本单文件。对照近期同机 `PROGRESS-chart-page-blocking-open-20260915.md` 的 fail **73**，**零新增失败** |
+| `page.tsx` | 未改 |
+| `npm run build` | compile + TypeScript 过；Collecting page data 死在既有 `SkillPackageRegistryError`（EPERM symlink `/api/daily-starlanguage`），与本单无关。未能从本机构建表确认 `/` 的 `○ Static` 与首屏 gzip。源码：`page.tsx` 无 `force-dynamic`；既有合同「home stays a client-read query on a static route」本单相关套件已绿 |
+
+## 环境缺口
+
+- 本机 Windows 无开发者模式 symlink：`skill-package-registry` 建 live runtime alias 报 EPERM。因此 `next build` 收集页面数据失败；若干 consult/methodology/skill-binding 测试整文件红。Linux CI / staging 不受影响。
+- 无 Docker：`tests/database-*.test.ts` 照常红，与基线同类。
+- 无登录态、无 Chrome：写满后「开新对话」的静默继承未做浏览器走查。界面无新文案，源码合同已锁「开新对话」按钮与禁止「接着上次聊」类句子。
+
+## 收尾限制
+
+- 摘要失败仍只 `console.warn("session context summary failed")`，不打印摘要正文。
+- 侧栏「新建对话」不带 `continued_from_session_id`，只有写满出口的「开新对话」会静默继承。
+- 源会话属于别人或没有摘要时新行 `context_summary` 为空，接口仍 201。

docs/tasks/README.md

@@ -239,7 +239,7 @@
 | `TASK-rectification-settled-render-split-20260915.md` | — | **前端性能单（独占校正会话组件，可并行）**：`rectification-agentic-chat.tsx` 1973 行、`useMemo` 0 个、`memo` 0 个，`messages.map` 内联在组件体里且逐条新建时间轴数组与 choice card，`ChatMessageRow` 无 memo、结算态 Markdown 走没有缓存的 `renderProse`。流式每帧（~60/s）重渲整条会话并重跑每条已结算消息的 Markdown。BUG-473 在本文件只落地了 `stream-frame-buffer`，咨询面的 `SettledMessageList` + `HistoryMessageEntry` 拆分没有跟过来。**零行为变化**；验收必须有按帧驱动的渲染计数断言（照 `home-streaming-render-split.test.ts`）。BUG 段 725 | 待领取 | — |
 | `TASK-rectification-request-dossier-cache-20260915.md` | — | **低风险单，串行在 failure-attribution 之后（同改 `route.ts`）**：一轮 Agent 对话实测取 3.44 次整份 Case 档案（点选题 2.07 次），全仓约 40 个调用点、请求内零缓存；档案是「最近 50 轮 turns + 全部 evidence + 合成收据」的大 jsonb。做法是包装 `accounting` 客户端做**写即失效**的请求作用域缓存（两个只读投影命中缓存，其余任何 RPC 先清空再转发），**零调用点改动**。不得做成「请求内只读一次」——档案在请求内会变。BUG 段 726 | 待领取 | — |
 | `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 | 待验收 | `codex/consultation-external-evidence-cache-20260915` |
-| `TASK-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 | 待领取 | — |
+| `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 | 待验收 | `codex/consultation-context-memory-20260915` |
 | `TASK-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 | 待领取 | — |
 | `TASK-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 + 两个合同测试，不碰业务代码 | 待领取 | — |
 | `TASK-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 号 | 待领取 | — |