Files

T

Jesse_ChenandClaude Opus 5 37e6c519f7 docs(tasks): 校正状态板 + 状态下沉第二批 + 后门单 + 对账清单

① 状态板校正：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

2026-09-16 01:13:26 +00:00

3.8 KiB

Raw Blame History

对账清单 · 这 7 份任务书到底做了没（2026-09-16）

给执行方 / 产品负责人的一页纸。不是任务书，不需要实现任何东西，只需要每行回一个「做了 / 没做」，并把做了的补一份 PROGRESS-*.md。

为什么要对账

docs/tasks/README.md 的状态板已被证明不可靠：2026-09-15～16 这一批共 10 份任务书，实现早就合进 staging 并经我逐单验收，状态板却仍然写着「待领取 / 待验收」（本轮已修正）。

所以对下面这 7 份，我不能拿 README 的状态当证据。我用的判据是两条客观事实：

docs/tasks/ 下没有对应的 PROGRESS-*.md；
但它们引用的 BUG-NNN 在 docs/BUG_HISTORY.md 里都是 resolved。

两条合起来有两种可能：(a) 被别的单顺带修了、执行方没单独留记录；(b) 压根没做，而那些 BUG 号是被更早的单闭环的。只有做过的人分得清。

要回答的 7 行

#	任务书	引用的 BUG
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 上复跑，仍然红：

.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 的「命名与归档」一节。

3.8 KiB Raw Blame History Unescape Escape