# 会话交接摘要

> 一轮会话结束时写，下一轮开始时读。让接手的人（或 agent）快速了解现状。
> 短会话可以不写；会话长、或项目有多个并行区域时，它很关键。
> **每次交接覆盖写这一份**（历史记录累积在 `progress.md` 里）。

## 当前已验证

<!-- 哪些是确认能用的，跑过什么验证。写命令和结果，不要写"应该没问题"。 -->

- 生产构建：`npm run build` 通过（最近一次：Session 000）
- 接口适配层：对新协议的端到端验证通过（普通问答 / 政策推荐 / 公司补问 / 候选确认 / 翻页 / 取消）

## 本轮改动

<!-- 改了什么代码或基础设施。列文件路径。 -->


## 仍损坏或未验证

<!-- 已知问题和风险区。诚实记录，不要美化。 -->

- `file-upload`：未开始，阻塞于后端契约未定（见 `feature_list.json` 的 notes）
- `chat-markdown-format`：阻塞于方案未拍板（同上）
- 政策「更多」面板的部门筛选：按用户要求保持最初实现，新接口部门是全称，选中会筛出空列表——
  这是刻意状态，**不要去"修"**
- 仓库尚无 git 提交

## 下一步最佳动作

<!-- 下一轮该做什么，哪些东西不要动。 -->

- 确认 `file-upload` 的后端契约（后端扩展请求体 / OSS 地址拼进 question / 文件登记接口），
  确定后把该功能切到 `in_progress` 开始实现
- **不要动**：`src/components/stream-message-coordinator.ts`（旧协议，保留未用）；
  政策「更多」面板的部门筛选逻辑；项目的样式基线

## 命令

```bash
bash harness/init.sh     # 安装依赖 + 验证 + 打印启动命令
git add -A && git commit -m "..." && git push origin main   # 每次改动完成即提交推送
npm run dev              # 开发服务器 → https://localhost:8083
npm run build            # 生产构建（提交前必过）
npm run test             # jest（可选）
```