Jyotisha/docs/tasks/PROGRESS-rectification-cross-midnight-fix-20260920.md

BUG-984 缓存与成功结果身份补单进度（2026-09-20）

结论与授权边界

blocked：F2 方案 A 已完成局部实现，实测证实同一 turn 可出现不同身份的多个 completed，按补单须升级 B；未获 SQL 迁移授权，依指令停止进一步业务实施。F1 / F3 / F4 未完成，不可交付为 BUG-984 修复。

• 执行树：.worktrees/rectification-cross-midnight-fix-20260920，分支 codex/rectification-cross-midnight-fix-20260920。
• 前置代码基线：3f39bafc4a1fb7fc9d0a257d2528ea1a64295792。主会话已成功推 staging 并核对 ls-remote，前轮 Gitea 写认证 blocker 已解除；保留旧失败历史，不把它当本轮阻塞。
• 本轮 fetch 发现补充文档 f09f3d809a538a48979b94f1c851d1dc528e49ba，干净树快进到该提交。它仅修改任务书与索引，代码仍为上述基线。
• 已读 AGENTS、前端三规范、BUG-621/981/984 完整记录与错误台账。最大 Bug 编号 985，本轮续写 BUG-984，不占新号。
• 不 push、不调用线上、不读取凭据、不改 workflow/main/DNS/SQL/Skill/input contract/评分常数/确认门，不删除或重标历史缓存。

F2 实测与应用层可行性

A 的局部实现

createRectificationV9Tools() 的 compare / diagnostics started 与 failReceipt 不再携带部署声称版本；completed 只记录实际返回的 algorithmVersion，compare 缺失时不回退前端默认版本。

同一真实 golden 用例先红后绿：原实现 started 仍写 -8，修改断言后 6 pass / 1 fail；局部修复并补两条测试后 9 pass / 0 fail。

已构造出的 B 触发条件

frontend/tests/rectification-engine-version-cross-midnight.test.ts 的 runGoldenToolSequence() 通过实际 createRectificationV9Tools() 构造一个 Case/turn，依次运行 compare、diagnostics；RPC/fetch 为受控替身，响应结构和数值来自既有原生引擎虚构输入 golden，仅算法身份标签被替换以模拟滚动版本。未声称执行未来 -9/-10 算法。

行	实际工具	状态	写入身份
1	compare	started	null
2	compare	completed	scoring-9
3	diagnostics	started	null
4	diagnostics	completed	scoring-10

两条 completed 的 turn_id 相同；最新成功来自 scoring-10，但字符串最大值是 scoring-9。测试保留的是缺陷诊断证据，不是“聚合已修”的验收绿灯。并未运行真实 PostgreSQL 聚合，因此不宣称数据库端到端已验证。

• compare 与 diagnostics 各自独立调用引擎；两次完成之间没有“同 turn 必须同算法”的锁或一致性检查。部署滚动/环境来源差异不会被 A 消除。
• 现有 get_agentic_rectification_turn_receipt() SQL 按 selected successful attempt 过滤后仍执行 max(tr.engine_version)，活动只返回 tool/status/methods/timing/fingerprint，不含各 completed 的 engine_version。
• loadV9TurnReceipt() 只能读这个聚合字段；既有历史 compare fingerprint 仅含 hash/timings，diagnostics fingerprint 仅为 hash。因此应用层拿既有 RPC 输出无法无损恢复各历史成功行身份，也不能把当前 dossier 最新结果冒充历史 turn 来源。
• 在新 fingerprint 塞身份只能处理新数据，修不了历史 max 污染；引入第二条服务角色原始表读取会另造回执权限/attempt/重试排序投影，不是本单 A，且任务书已明确“构造成立就升 B”。因此不绕过授权另造旁路。
• 建议下一步 B：新增向后兼容函数体迁移，保留 owner/turn/attempt 过滤，仅从实际成功行取身份；明确多工具/失败重试语义，使用 started_at 与 id 稳定排序，不依赖字符串版本序。不得原地改已应用迁移。产品负责人明确授权迁移后再实施并真跑 test:db；主会话审查不代替该授权。

任务状态

项	状态	剩余工作
F1 minute / block_scan 缓存	pending	真实 golden 时段旧缓存红测、统一可信身份复用条件；当前完全未改
F2 成功回执	blocked	A 局部完成；多 completed 实证触发 B，等待迁移授权
F3 策略 b	pending	只读标注及所有服务端写入口拒绝尚未实现，不是只藏按钮
F4 完整回归/交付	pending	全量、build Static/gzip、DB 与受控 staging minute/late-night 验收未完成

已执行检查

检查	结果
pre_work_check（Python 3.11.7）	remote verified；focused 23 pass / 1 fail，历史 .workbuddy 镜像路径断言；与台账已知症状一致，未造目录
工具能力	Node 22.23.2；Docker daemon 29.8.0 可用；node:22-bookworm / postgres:17-alpine 已有
算法身份文件基线	7 / 7 pass
A 红测	6 pass / 1 fail，started 身份断言
A + 多成功来源诊断	9 / 9 pass；含缺陷存在证明，不是 F2 总体验收通过
tsc --noEmit	0 error
定向五文件（含 BUG-621、case-service、skill-registry、activity）	61 tests / 57 pass / 4 fail；四项均 Windows symlink EPERM，详见下列名单；尚未另跑基线逐条对照，不标全绿
lint	0 error / 120 warnings；未顺手修改既有 warnings
全量 / build / Static / gzip / 标准 DB	因必须 B 的授权停点而暂缓，未执行；不是预设工具缺失

定向四项失败来自未改动的 skill-registry.test.ts，单文件复跑 16 tests / 12 pass / 4 fail，失败标题精确如下：

1. checked-in registry verifies hashed product packages and leaves consult on the live skill
2. path traversal and symlink escape fail closed
3. symbolic links are rejected even when their target stays inside the project root
4. live consult skill reads a hand-updated tree without a registry hash

没有以修改业务代码或弱化安全断言消红。DESIGN 未修改：本轮在 F2 授权停点终止，尚未实施任何 UI 标注/形状变化；后续 F3 必须同提交更新 DESIGN。

断言调整说明

原值	新值	原因
新 Case compare/diagnostics started 回执身份为 CURRENT	started 为 null，completed 保持真实 CURRENT	F2 A 的明确授权；开始阶段未产生结果，不能冒充成功来源

新增两条：diagnostics 503 的 failed 身份为空；同 turn 两工具 completed -9/-10 与字符串最大值相冲突。未知身份的既有缓存降级测试仍如实锁现状，F3 未开始，不声称已修。

部署与后续独立验收

本 agent 无线上访问。主会话通知前置 run2819 validate 已 success、publish 尚 in_progress，最近通知的 staging health 仍为旧 SHA；这不构成本轮部署或身份验收证据。

独立验收重点：工具 started/failed 实参、完成态来源无默认回退、混版本诊断测试的边界、旧回执按绑定 Skill 打开不变。F1/F3 的实现与完整测试须在解除 B 授权阻塞后继续。真人清单：docs/testing/rectification-cross-midnight-fix-20260920.md。

主会话独立复核（2026-09-20）

• 审查本地实现提交 d575e89a：仅修改工具身份写入与定向测试，未改 SQL、缓存、UI 或评分。核对最新定义仍为 20260902020000_rectification_tool_activity_timing.sql：活动输出未含各成功行版本，140–146 行仍跨阶段做 max(engine_version)。认可 A 的局部修复及触发 B 的诊断结论，不将本轮标为完整验收通过。
• 独立实跑身份文件 9 / 9 通过；BUG-621 历史打开与 case-service 两文件 29 / 29 通过；tsc --noEmit 退出 0；前置 Python 跨午夜 bridge 9 / 9 通过。混版本项只证明缺陷可达，未执行数据库聚合验收。
• 前置 Gitea run2819（SHA 3f39bafc4a1fb7fc9d0a257d2528ea1a64295792）的 validate 已 success，最后查询整轮仍 in_progress。staging /login 200、匿名 /api/account 401；健康响应的 web/API 部署均仍 539d4daee4d0065f5ef3b974903ea8d639a249c6，所以前置部署尚未确认完成。这些匿名检查不能代替缓存身份受控会话验收。
• 局部实现未推送；按任务书迁移授权停点报告，F1/F3/F4 保持 pending。