Jesse_ChenandClaude Opus 5
37e6c519f7
① 状态板校正：09-15～16 这 10 份任务书的实现早已合入 staging 并经逐单 验收，状态板却仍写「待领取 / 待验收」。改成「已验收」并补上落点 SHA 与验收要点；顺带补齐 8 个 PROGRESS 列。防复发写进「命名与归档」： 实现合入的同一次推送必须同时改状态板那一行。 ② 新增 TASK-home-state-lowering-batch2-20260916（不占 BUG 号）： 第一批f8e607c2已验收（useState 66→52、useRef 41→39、散装 rectification* 归零）。本单搬剩下三簇 session*10 / profile*6 / synastry*4，目标 52→≤36；并修第一批尾巴—— createRectificationShellSetters 每帧新身份多出的那条 exhaustive-deps warning（119→120），正解是稳住 setter 身份而不是塞进 deps。 ③ 新增 TASK-api-server-backdoor-close-20260916（不占 BUG 号）： 实测四处 __new__ 的传递闭包只有 8 方法 / 314 行且 0 个碰 HTTP 上下文， 占全类 4%。所以关后门不必捆绑 2,000+ 行体量搬运。产品拍板阶段 2/3 不立单，由3b17c1b2换好的门禁长期推进。原 decomposition 单标为已取代。 ④ 新增 RECONCILE-20260916：另外 7 份 09-10～14 的单没有 PROGRESS、但 引用的 BUG 号都是 resolved，无法从 README 判断，列成一页纸让执行方 回填；另附三条确定没做的证据、两条未闭环状态、BLK-001 仍红。 纯文档推送，不触发门禁、不发布镜像、不部署。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JUei7K13cYxLHE3Axe4A45
65 lines
3.8 KiB
Markdown
65 lines
3.8 KiB
Markdown
# 对账清单 · 这 7 份任务书到底做了没（2026-09-16）
|
||
|
||
给执行方 / 产品负责人的一页纸。**不是任务书，不需要实现任何东西**，只需要每行回一个「做了 / 没做」，并把做了的补一份 `PROGRESS-*.md`。
|
||
|
||
## 为什么要对账
|
||
|
||
`docs/tasks/README.md` 的状态板已被证明不可靠：2026-09-15～16 这一批共 **10 份**任务书，实现早就合进 staging 并经我逐单验收，状态板却仍然写着「待领取 / 待验收」（本轮已修正）。
|
||
|
||
所以对下面这 7 份，**我不能拿 README 的状态当证据**。我用的判据是两条客观事实：
|
||
|
||
1. `docs/tasks/` 下**没有**对应的 `PROGRESS-*.md`；
|
||
2. 但它们引用的 `BUG-NNN` 在 `docs/BUG_HISTORY.md` 里**都是 `resolved`**。
|
||
|
||
两条合起来有两种可能：**(a)** 被别的单顺带修了、执行方没单独留记录；**(b)** 压根没做，而那些 BUG 号是被更早的单闭环的。**只有做过的人分得清。**
|
||
|
||
## 要回答的 7 行
|
||
|
||
| # | 任务书 | 引用的 BUG | 做了没？（请填） | 若做了，落在哪个 commit |
|
||
| --- | --- | --- | --- | --- |
|
||
| 1 | `TASK-rectification-after-pool-empty-decision-20260913.md` | 见文内 | | |
|
||
| 2 | `TASK-rectification-delivery-vs-collect-split-20260914.md` | 见文内 | | |
|
||
| 3 | `TASK-rectification-invite-copy-and-assertions-fix-20260915.md` | 见文内 | | |
|
||
| 4 | `TASK-rectification-precision-adaptive-boundary-research-20260914.md` | 研究单 | | |
|
||
| 5 | `TASK-rectification-spoken-orphan-and-engine-representative-20260914.md` | 见文内 | | |
|
||
| 6 | `TASK-rectification-tiebreak-hold-exit-fix-20260914.md` | 见文内 | | |
|
||
| 7 | `TASK-rectification-probe-supply-research-20260913.md` | 无 BUG 号（研究单） | | |
|
||
|
||
填法：
|
||
|
||
- **做了** → 补一份 `docs/tasks/PROGRESS-<同名>.md`，哪怕只有三行（做了什么、落在哪个 commit、有没有让步），并在状态板上把该行改成实际状态。
|
||
- **没做** → 在状态板上写明「待领取」，并说一句它现在还成不成立（有些旧单可能已被后来的轮次取代）。
|
||
- **已被取代** → 写明被哪一份取代，参照 `TASK-rectification-exhausted-gate-exit-20260910.md` 那行的写法（「已被取代（并入采集重设计单）」）。
|
||
|
||
## 顺带确认的三件事
|
||
|
||
这三条我已经查到**确定没做**的证据，不需要对账，直接派活即可：
|
||
|
||
| 任务书 | 我的证据 |
|
||
| --- | --- |
|
||
| `TASK-rectification-title-repair-migration-20260915.md` | `frontend/supabase/migrations/` 下**没有**对应的迁移文件 |
|
||
| `TASK-settings-dialog-size-and-nav-20260915.md` | BUG-698 在 `docs/BUG_HISTORY.md` 里**查无此号** |
|
||
| `TASK-rectification-record-conflict-copy-20260914.md` | BUG-691 **查无此号** |
|
||
|
||
另两条状态未闭环，也不需要对账：
|
||
|
||
| 任务书 | 状态 |
|
||
| --- | --- |
|
||
| `TASK-rectification-tied-first-premature-delivery-fix-20260914.md` | BUG-684 仍是 `investigating` |
|
||
| `TASK-rectification-unstampable-probe-and-naked-card-20260914.md` | BUG-559 只到 `mitigated`，记录里自注「点选同年复发见 BUG-592」 |
|
||
|
||
## 还有一条长期红
|
||
|
||
`BLOCKED.md` 的 **BLK-001** 我 2026-09-16 在 `4f643aa0` 上复跑，**仍然红**：
|
||
|
||
```bash
|
||
.venv/bin/python -m pytest -q \
|
||
"tests/test_active_rectification_api.py::test_long_real_conversation_reaches_vedastro_after_local_range_is_narrow"
|
||
```
|
||
|
||
当初的处置是「只记录，不改引擎、不改门槛、不改断言让它变绿」。它从 2026-09-06 挂到今天。**这一条需要产品决定**：继续挂着，还是立一份单去查（查的是 BUG-560 那条根因——分钟级原始分的区分力≈随机）。
|
||
|
||
## 防复发
|
||
|
||
状态板与现实脱节这件事本身要治：**任务书合入 staging 的同一次推送里，必须同时把状态板那一行改掉**。这条建议加进 `docs/tasks/README.md` 的「命名与归档」一节。
|