epic(chat): 人类实测三缺口 —— 普通对话零 planning / 100 轮历史断崖（20条上限）/ 文件上传零实现 + context engine 全量启用

人类 2026-08-11 晨间实测 devapp 后原话：

> 「我们提交一个问题以后，系统需要做planning，如果我做了100轮的来回，期间要有文件上传的支持，
> 上传各种文件，文件上传以后，context window超负荷了，怎么做context的管理，这些部分都还没有吧？」
> 「要把contextengine用上」

## 实测核实（origin/main，grep 真实实现，非注释）

| 缺口 | 现状 |
|---|---|
| planning 阶段 | 仅 deep-agent 路径（`completeWithProgress`）有规划句；**普通 provider 零 planning** |
| 100 轮对话 | `HISTORY_MAX_MESSAGES=20` / `HISTORY_MAX_CHARS=12k`——**第 80 轮前的内容对模型不存在** |
| 文件上传 | chat 输入区 **0 实现**（`upload/file/attach` 全仓 chat 域零命中） |
| context 超载管理 | V8 滚动摘要已合（#913）但默认关；只管文字不管文件 |

## 工作拆解（派 dev-chat-e2e 迭代线，coord-main 主持签核）

- **A. context engine 启用**：deps.log 观测行 → 开 `KERNEL_HISTORY_SUMMARY_ENABLED` →
V10 context-pack 接线（签核依据：人类逐字「要把contextengine用上」，按 agent-instructions
先例落 design-signoff）→ 20 条上限纳入分层历史设计
- **B. 普通对话 planning**：两路线评估（全切 deep-agent vs 轻量前置 planning 调用）→ coord-main 裁
- **C. V9 文件上传**：方向已人类确认，契约草案 + 待签材料准备，与 V10 一体设计
（文件是 context engine 的第一个大客户）

Refs #814（track B 的 1/2/4/6 项直接受益）

Start by reviewing the existing completeWithProgress path, the HISTORY_MAX_MESSAGES and HISTORY_MAX_CHARS limits, and the V8 summary work from #913. Check deps.log and the KERNEL_HISTORY_SUMMARY_ENABLED and V10 context-pack references before preparing the design-signoff material. Done means the planning, layered history, context-engine, and file-upload contracts are agreed and implementation scope is assigned.

Written by the indexing model from the issue text.