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

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

结论与授权边界

本地实现与自动化完成：F1/F2/F3 已实现，diagnostics追加修复后的新快照全量3588/3588、定向37/37、tsc/lint通过；标准DB40/40，首页Static、完整28资源gzip+0.040085%。主会话独立DB40/40、diagnostics最终定向40/40+tsc通过。未推送、未部署，受控真人验收仍缺口，BUG-984保持investigating。 以下保留授权前记录，最新状态以文末「授权恢复」为准。

• 执行树：.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。

授权恢复与最终实现（2026-09-20）

产品明确回复继续并授权 B：只新增向后兼容函数体迁移、仅修回执聚合，不改表结构/已应用迁移/历史行，保留 owner/turn/attempt 与重试语义，真跑标准 test:db。恢复时 HEAD 6dd62207eb1ab04aaac8f6755146980b7abac8b2。原停点是正确执行历史，不删除或改写。

主会话补报前置 run2819 completed/success，staging health 的 deployment.gitCommit 与 apiGitCommit 均等于 3f39bafc4a1fb7fc9d0a257d2528ea1a64295792。前置部署确认完成；本 agent 未访问线上，这不是本补丁受控身份验收。

F1 / F2 / F3

• minute 与 block_scan 共用算法+策略完整 pair、证据指纹、范围/基线资料指纹；完整 env 保留明确覆盖语义，部分 env 补查 native pair、冲突 fail closed，不拿前端默认常量冒充部署覆盖。时段来源 policy/range 指纹只写新 JSON，不回填历史。
• 真实原生虚构输入 golden 经 normalize_rectification_request→api_service.block_scan 生成；旧 -7/当前 -8 minute 和 late-night 缓存均实跑应用链，旧重算、当前命中。F1 红测 11 项中 4 红（partial/unknown/旧block/当前block未探测），修后全绿。
• B 迁移 20260920010000_rectification_receipt_result_identity.sql 与旧函数除注释外仅身份 SELECT 不同：选中 successful attempt，否则 latest attempt；仅 completed 非空身份，started_at DESC、id DESC。真实 PostgreSQL 先红（8≠7）后绿，覆盖9/10、失败重试、同时间稳定排序、历史不重标与owner/turn/权限。
• 未知当前身份：旧结果只读、cached=false、来源不重标，不重算、不跑 oracle、不写 focus/inference/候选/验证；历史 GET/刷新、read-case、compare 同样显示「按旧算法产出」。新算响应与可信 pair 不同也保存真实来源并只读。
• 服务端写门覆盖 API direct accept、service accept/confirm、offer候选、选择/推断、block推进/拒绝、widen、tie-break、focus denial及闲置/出口修复。重查 dossier+当前身份，不信客户端flag；stage/source交叉缺失、非最新resultId、无source具体采用一律拒绝，正常空Case收集不误拦。无生产引用的旧 session.ts helper未扩改。
• 独立review发现 stale 与 unknown 同锁composer会造成旧结果无法升级，已修：旧候选仍不可写，但可信当前pair已知时、非终止Case可点「重新比较」，复用既有message入口；未知身份不显示，不自动重算。测试覆盖历史投影→read-case提示compare→实际compare新来源，以及按钮handler的stale/unknown/terminal/busy派发边界。
• 独立review再发现 diagnostics 未经过身份门，原六种failure测试没有调用该工具。补调用后22项16绿/6红，证明未知身份仍请求了diagnostics；现入口在读取compute/诊断前短路：旧来源+notice/read_only、diagnostics=null、can_confirm_exact_minute=false、executed_methods=[]，无source则engine_identity_unavailable。可信身份下仍独立诊断，新响应pair不匹配只读且不能确认，completed保持实际来源，9/10聚合用例保留；修后22/22。
• 不改Skill、input contract、评分/确认门、历史打开绑定，不删除或重标历史缓存；UI同步DESIGN，无Home状态增长。

F4 证据与复跑环境

检查	已完成结果
Linux基线全量（HEAD6dd62207应用代码）	3575/3575，fail/skip=0
身份及历史重算定向	22项；含minute/block、无/完整/部分env、冲突、接口异常/超时、来源缺失与滚动响应
最终四文件业务定向（加入stale测试之前）	112/112
Python日期+bridge+memoization	32/32；bridge重复收集已知，不称32个独立用例
标准 npm run test:db	执行方40/40，主会话独立40/40（304634ms），fail/skip=0，真实PostgreSQL17；独立日志 <临时目录>/bug984-independent-db.log
中间完整修复轮	3587项，3586通过/1源码断言失败：终止提示改为historyReadonly，已附三栏同步
中间build	首页 ┌ ○ /；25个首页直链JS/CSS gzip 655491→655584B，+93B/+0.0142%
保留的旧delivery全量	3588/3588，fail/skip/cancelled=0，307886ms；不替代追加diagnostics后的复跑
最终diagnostics全量	3588/3588，fail/skip/cancelled=0，259596ms；比基线3575增加13项
最终diagnostics build/gzip	┌ ○ / Static；完整28资源666078→666345B，+267B/+0.040085%，在±2%内。读取index.html全部src/href的/_next/ JS/CSS，去query后去重，各文件gzipSync默认参数求和；旧25资源655491→655758B为遗漏3资源的局部统计，由本完整口径替代
最终diagnostics/按钮/身份/spoken定向	37/37；含22项身份、六种故障的diagnostics调用、实际handler派发与历史read→compare行为
tsc/lint	最终diagnostics后退出0；lint 0 error/119 warning，不顺修warnings
BUG-621及最终独立补验	主会话先前43/43；身份+spoken（含按钮handler）+BUG-621独立40/40、tsc退出0；日志 <临时目录>/bug984-independent-final-targeted.log；diagnostics补丁后再次独立40/40且tsc0
隐私门	明确stage全部37个本单文件（含新增fixture/SQL）后 python -m pytest tests/test_repo_privacy_markers.py：62/62；删除文档内两处HOME_PREFIX，日志以临时目录占位符保留
本轮部署/真人	未进行，BLOCKED与真人清单保留

Linux保真方式：git archive HEAD 保留真实symlink，增量文件在打包时替换；从不将Windows整个checkout覆到Linux。首轮基线3575/3571/4，失败为缺Git index/PyYAML/rsync；装备后3575全绿。源树git ls-files -z精确建立tracked index，临时repo无完整历史。基线目录带新增B迁移与原DB文件新增断言，但应用源码是HEAD；DB仍同一个test，应用基线总数不变。

• 保留 Docker runner bug984-runner（node22-bookworm）、DinD bug984-docker、volume bug984-validation；无线上数据/凭据。
• 基线 /repo/frontend；中间 /repo/bug984-fixed/frontend、/repo/bug984-final/frontend；最终 /repo/bug984-delivery/frontend。这些是容器内路径，主会话复验不要用Windows主检出路径。
• diagnostics追加修复使用新快照 /repo/bug984-diagnostics/frontend，旧delivery与其证据不覆盖；最终30个修改/新增frontend文件在stage前与新快照逐文件SHA256相同（0差异），含SQL与DB测试；stage后diff-check发现新增SQL/golden的CRLF，已仅转为LF（内容/JSON/SQL语义不变），最终字节比较28相同、这2项去CRLF后相同。快照文档为创建时点；之后只补最终数字/独立证据，不影响源码测试。新增三文件也按明确清单加入临时tracked index。
• 标准复跑：MSYS_NO_PATHCONV=1 docker exec -w /repo/bug984-diagnostics/frontend bug984-runner npm test；同命令末尾换 npm run test:db、npm run build、./node_modules/.bin/tsc --noEmit、npm run lint。SQL和DB测试在diagnostics补丁中未改，沿用两方实际40/40，不伪称重复跑DB。
• 日志（volume内绝对路径）：/repo/baseline-equipped-tests.log、/repo/baseline-build.log、/repo/baseline-gzip.json；/repo/fixed-standard-db.log（标准40/40）；/repo/fixed-tests.log、/repo/final-tests.log（中间失败留存）；旧delivery /repo/delivery-tests.log、/repo/delivery-build.log、/repo/delivery-gzip.json；最终 /repo/diagnostics-tests.log、/repo/diagnostics-targeted.log、/repo/diagnostics-lint.log、/repo/diagnostics-build.log、/repo/diagnostics-gzip.json。
• 曾同步覆盖基线被权限系统拒绝，未重试覆盖，改为创建全新目录；首次final build抢在依赖copy完成前报next not found，等待copy完成再建成功。没有改业务/依赖声明来规避平台问题。

本轮既有断言/fixture调整（三栏）

原值	新值	原因
部分policy env返回algorithm null、旧cache可用、0fetch	native完整pair、旧cache不可用、1fetch	部分身份不能绕过算法核验；完整pair仍0额外fetch
版本接口失败旧cache reusable=true	false并只读	策略b，保留显示不等于当前缓存命中
业务test-support无显式部署身份	与其fixture一致的rectification-v5/policy-v2完整env	正常业务回归有受控可信身份，故障测试单独清env；不放宽生产
block业务fixture algorithm=test、无policy	与受控env一致的v5/policy-v2	不改blocks/分数/选择预期，仅补真实身份语义
两个业务score替身algorithm误用event-contract-v2	rectification-v5，event_contract_version保持原值	与test-support可信部署一致，不把滚动不一致误算正常业务
直接accept/confirm及collect替身没有dossier重读RPC	补原candidate/dossier fixture	新服务端写门必须重读，权限/确认/问题预期不变
native policy滞后测试继承fixture env	测试内清pair并恢复	必须真实走versions替身，不被完整env覆盖
无source采用返回candidate_not_found	RPC前result_identity_read_only	提前拒绝不可核验具体结果，不能产生候选
question/current_question/choice_card无只读分支，GET同步projection	只读null，GET await可信projection	历史直接刷新同样受保护，非删除断言
终止UI源码readonly &&	historyReadonly &&	身份不可核验不等于Case已结束；不诱导强制新建

新增源形合同全部采用真实native golden；既有业务替身只是补身份或RPC，不声称为新合同golden。所有示例明确虚构，未使用用户账号或资料。