补首屏历史锚点的契约：切片新端边界只认订阅回执的 lastCompletedItemId

ADR 首屏锚点那条写清锚点语义：新端（较新一侧）边界含锚点条目，命令参数 throughItemId，更新条目只从运行态事件来，翻页仍用 firstItemId 的 beforeItemId 不含锚点
里程碑范围与已确认决策同步该口径，验收标准新增一条待验收行（首屏 throughItemId + 回执前不发请求）
实施计划第 6 步补上首屏读取等订阅回执、锚点缺失才退化取文件尾
决策记录新增 2026-09-17 条目，记下 manager 恒 None / commands 磁盘回填 / 前端自 1b40f030e 起不再读取的现状与本次决策

docs/project-memory/shared-memory/decision-log.md

@@ -3,6 +3,16 @@
 > 用途：记录已经确认、会影响后续开发的长期技术/产品/协作决策。短期讨论不要写在这里。
 > 当前口径：历史条目的旧路径、旧版本和已退役对象只用于追溯，不构成现行实现依据；如与当前代码或 `docs/README.md` 冲突，以当前代码和最新专题文档为准。
 
+## 2026-09-17 DirectProject 首屏历史锚点只认订阅回执的 lastCompletedItemId
+
+- 背景：ADR「首屏历史由 `subscribe` 返回的 `lastCompletedItemId` 锚定，再取最近切片」只落了一半。`DirectThreadManager` 是搬运层，内存里没有「已完成条目」的锚点，`subscribe` 一律返回 `last_completed_item_id: None`；`commands.rs` 的 `subscribe_direct_project_thread` 在为空时用 `read_direct_project_last_item_id_at` 从磁盘回填，所以线上回执里的值是真的（订阅那一刻文件里最后一条可显示条目的原始 item id）。前端侧：首屏一直在 `loadProjectConversation` 里用 `beforeItemId: null` 直接取文件尾一屏，`lastCompletedItemId` 自 `1b40f030e` 起不再被任何代码读取。
+- 决策（锚点语义）：首屏切片的新端（较新一侧）边界就是这个锚点，**含锚点条目本身**；切片命令新增 `throughItemId` 参数表达「取到这条为止」。比锚点更新的条目只从运行态事件来，历史切片与实时流因此不重叠（原来的文件尾读取会把订阅回执之后才完成的条目也拉进历史，与运行态事件同 id 重叠，只靠前端合并兜住）。
+- 决策（读取时机）：订阅回执到达之前不读首屏，也不退化成「取文件尾」；锚点缺失（订阅不可用 / 失败 / 历史为空）时才按文件尾取尾屏。`/history` 手动重读保持「按当前文件尾取尾屏」的恢复语义，不锚定。
+- 决策（翻页不变）：向后翻页仍用切片返回的 `firstItemId` 作 `beforeItemId`（不含锚点），`hasMore` 与连拉口径不变。
+- 影响范围：`agent/direct_project_history.rs`（切片锚点 + `through_item_id` 参数）、`commands.rs`（`read_direct_project_history_slice` 命令参数）、AGC 前端首屏读取接线与测试骨架。**未改**：DirectRuntime 的 `turn-stream.jsonl` / `tool-calls.jsonl` 写入与进度事件、`list_game_creator_direct_active_turns`、SpacetimeDB 与 HTTP 契约。
+- 验证方式（待跑）：Rust 侧 `direct_project_history` 定向用例（含锚点、排除更新的条目、锚点缺失报错）、前端首屏 `throughItemId` 的 appSurface 用例。
+- 关联文档：[ADR](../../adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md)、[里程碑](../plans/【里程碑】DirectProject聊天真相源收敛-2026-09-16.md)、[实施计划](../plans/【实施计划】DirectProject聊天真相源收敛-2026-09-16.md)。
+
 ## 2026-09-17 `agc_tools` 媒体资源提示词上限收敛为单一口径，并按 kind 暴露给模型
 
 - 背景：有人反馈「客户端没法由 agent 调用图片快速编辑功能以及背景音乐生成功能」。核查后工具本身都在（`agc_edit_image` / `agc_create_or_derive_resource`），图片快速编辑在 2026-09-14 的真实项目日志里也有成功记录；但存在三类真实缺陷：① `agc_create_or_derive_resource` 的 `prompt` 在 schema 里只声明 4000，真实上限却是按 kind 分的（背景音乐 140、音效 1900、视频/角色动画 4000、图片 32000），MCP 层还额外写死了一条 140 判断，模型从 schema 与 skill 都看不出 140/1900，写一句正常长度的背景音乐描述就当场被拒；② 客户端 UI 用同一口径但会截断并提示，agent 侧却只有硬拒，形成「UI 能做、agent 调不动」的观感；③ `sourceLocalAssetId` 不是已登记资源时只报「不属于当前项目已登记资源」，模型会原地重试而不会先登记。