From a4ac11a1c1a69f856a4c8ea31046cf5ad8fc3b93 Mon Sep 17 00:00:00 2001 From: AskaEth Date: Mon, 5 Oct 2026 22:23:44 +0800 Subject: [PATCH] =?UTF-8?q?docs(05):=20=E9=94=9A=E7=82=B9=E8=A1=A5?= =?UTF-8?q?=E8=AE=B0=E4=BA=8C=E5=8D=81=E5=9B=9B=E2=80=94=E2=80=94=E6=B5=81?= =?UTF-8?q?=E7=A8=8B=E6=95=99=E8=AE=AD=EF=BC=9A=E5=8A=A8=2002=20=E4=B9=8B?= =?UTF-8?q?=E5=89=8D=E9=99=A4=20git=20status=20=E8=BF=98=E8=A6=81=20diff?= =?UTF-8?q?=20=E5=AE=83=E6=9C=80=E6=96=B0=E5=87=A0=E5=8D=81=E8=A1=8C?= =?UTF-8?q?=EF=BC=88=E6=88=91=E5=B7=AE=E7=82=B9=E5=9C=A8=E6=B2=A1=E8=AF=BB?= =?UTF-8?q?=E5=90=8E=E7=AB=AF=E5=9B=9E=E6=89=A7=E7=9A=84=E6=83=85=E5=86=B5?= =?UTF-8?q?=E4=B8=8B=E7=BB=99=E5=90=8E=E7=AB=AF=E5=86=99=E4=BF=A1=EF=BC=89?= =?UTF-8?q?=EF=BC=9B=E5=B9=B6=E7=99=BB=E8=AE=B0=E5=90=8E=E7=AB=AF=E6=AD=A3?= =?UTF-8?q?=E5=9C=A8=E7=AD=89=E6=88=91=E4=BB=AC=E5=9B=9E=E7=9A=84=E5=9B=9B?= =?UTF-8?q?=E4=BB=B6=E4=BA=8B=E4=B8=8E=E3=80=8C=E6=AF=8F=E5=B1=8F=E4=B8=80?= =?UTF-8?q?=E6=9D=A1=20WS=E3=80=8D=E8=BF=99=E4=B8=AA=E8=BF=87=E6=97=B6?= =?UTF-8?q?=E5=89=8D=E6=8F=90?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- devdocs/05-开发进度与交接.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/devdocs/05-开发进度与交接.md b/devdocs/05-开发进度与交接.md index 4d1a643..8460e4c 100644 --- a/devdocs/05-开发进度与交接.md +++ b/devdocs/05-开发进度与交接.md @@ -1351,3 +1351,21 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \ > > ### 合并时的纪律（提醒下一轮的自己） > 两个 worktree 的基线都是 `df8df67`；合并要**分别** `--no-ff` + 全量 `assembleDebug`/`testDebugUnitTest` + 当场 `rm -rf` + `git worktree prune`，并**核对主仓 `git status` 只有 `02` 那笔私有改动**（曾有子代理误写主仓）。 + +> ## ★★ 锚点补记二十四（2026-10-06 深夜 · **一条流程教训**：写 `02` 之前必须先读它的最新追加） +> +> ### 我差点犯的错 +> 我给后端写了一整节（`7d1c56e`「我方依赖的线形状」）**之前只看了 `git status` 知道 `02` 是脏的，就假定那还是我上次看到的那批追加**。 +> **主人一句「你确定不先读一下？」把我拦住了** —— 一读发现后端**早已回了** `回执二十二 · 补`，里面有 **🔴 一条点名问我们的 P1** 和另外三问。 +> ⇒ **纪律（写死）：动 `02` 之前，除了 `git status`，还要 `git diff` 看它最新那几十行**（`git diff -- devdocs/02-… | grep '^+' | tail -45`）。**「脏」不等于「还是那批内容」。** +> +> ### 后端正在等我们回的四件事（`回执二十二 · 补`，原文节选） +> 1. **🔴 P1：主动消息会不会显示两次？** —— v0.72 起她主动说的话**既是实时帧、也是主会话历史里的一条真消息**，且帧里新增了 **`data.id`**（= 落库行权威 id）。若我们「用帧画一个气泡 + 拉历史再画一个」⇒ **同一条显示两次**；他们说 Web 侧已按 id 去重，问**我们做了没有**（**未做就是 P1 客户端项**）。好处：做了之后**刷新/重开 App，她主动说的话仍在**。 +> 2. **`tool_execution` 取哪个口径**：(a) 我们**只认 `.start`/`.end` + 按 `id` 关联` ⇒ 他们不再补 `.update`**；或 (b) 我们确实要不要 `.update`（中间进度）⇒ **他们排一片后端工作**。**要我们选一个。** +> 3. **我们那份待办清单的现状**（哪些要他们配合）—— 注意：他们列举里的「**`ChatScreen` 每屏一条 WS**」**已经是过时前提**（W28 早就收成**进程级唯一连接**了；剩下的是 VM 不回收），回信时要纠正。 +> 4. **移动端要不要系统推送**（形状层面）—— 主人说过**等他自建推送**再定。 +> 另两条无需回复的 FYI：**v0.70 起实时 `backthink` 帧带 `urgency`**（routine/warning/critical）；**v0.69~v0.75 除 v0.72/v0.74 外全是 admin 面**（对我们零改动）。 +> ⚠️ 我读到的只是他们追加的**尾部 45 行**，第 4 条的句子在 190 字处被截断 ⇒ **回信前要读全**。 +> +> ### 已派单核实 +> **只读排查**（`agent-8qtm01gd`）就为这两条取证并给出建议：问题一的「帧画的 vs 历史拉的会不会被按 id 合并成一条」（以及最小修法），问题二的「`.start`/`.update`/`.end` 三档各自是否解析 / 是否消费」以及**只发 start/end 时工具卡够不够用**。