| content |
{"Commits":[{"Sha1":"01d0eabfa {"Commits":[{"Sha1":"01d0eabfa71ec061d876d39d4f399d2290530a15","Message":"chore(reports): runtime 30/30 + 静态 28/28 回绑 @ 56e6e57；锚点随批次刷新\n\nRedis 发布时限批次的三级证据，绑定 clean HEAD `56e6e57`（worktreeDirty:false）：\n\n· runtime 30/30 步、**776 tests / 0 failures**、行为矩阵 **204/204**（地板 204）；\n 776 = 759 + 本批 17 例（contracts 9 + 两后端各 4），与前置预测一致。\n dependency-resilience / multi-instance / write-capacity 这些真打 Redis 的\n 门禁全过——2 秒时限没有误伤健康链路。\n· 静态 28/28。\n· 依赖 pnpm audit --prod --audit-level high = 0 high / 3 moderate\n （npm 审计接口 503 重试两次后成功）。\n\n本提交按 C241 把锚点指向父提交 56e6e57；证据新鲜度的 runtime 行同步回绑。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:44:00-07:00"},{"Sha1":"56e6e57c22a534a07ac54bc5f8bf9da1c6806a03","Message":"chore(reports): 静态 28/28 回绑 @ 00cd95d；数字前置到本批实测值\n\nown-tests 96 → 99、own-test-cases 762 → 779（+3 文件 / +17 例：contracts 9 例判定单测\n与两后端各 4 例黑洞 Redis 验收；C70 只计 git 已跟踪文件，故必须在实现提交落地后才数得到）。\n\ntests-passing 759 → 776 是**预测值**（759 + 17），由下一轮 runtime 实测证实。\n前两批这条路子都验证过：预测被实测原样证实。\n\n锚点按 C241 指向父提交 00cd95d。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:31:04-07:00"},{"Sha1":"00cd95da0b4f2694db9528235f69d2f95a6707ab","Message":"fix(realtime): Redis 发布加可判责时限 + 批次预算刹车——此前一次 Redis 故障既不可判责也不收敛\n\nB3″ 登记的推迟项里有一条是真缺口，同日单独做掉。**先有证据再动手**：起一个「接受连接但\n永不应答」的 TCP 服务端（C63 已建模的半开/黑洞形态），用与本仓 publisher 完全相同的连接配置\n（maxRetriesPerRequest: null——BullMQ 的要求）打一次 publish，**8 秒后仍然挂着**。\n不是慢，是永远：ioredis 在该配置下无限重试，命令永不 reject。\n\n真正的后果不在「慢」，在它挂在 outbox 领取事务**之内**：\n\n 修复前 修复后\n 单行 publish 无限挂起 2s 抛 REALTIME_REDIS_COMMAND_TIMEOUT\n 该行 attempts 不增（整事务回滚） +1，事务提交\n 批内其余 49 行 一次都没试过 按预算尽量试，剩下留给下一跳\n 连续故障 每秒重开一个必然超时的事务，不收敛 10 跳后进死信，可判责终态\n 运维看到的错误 Prisma 事务超时，**指向数据库** 稳定前缀，指向 Redis\n\n**光加超时不够，这是最容易做漏的一半。** 故障时每行烧掉一个完整时限，一批 50 行 ×2s 远超\n15 秒事务预算——事务照样超时回滚、attempts 照样不增，只是从「挂着」变成「忙着」。\n所以有 realtimeDispatchBudget：每行开工前裁决「还剩不剩得下再试一行」，不够就 break，\n把剩下的留给下一跳，让本事务先把已累加的 attempts 提交掉。**收敛性来自这条刹车，不是超时。**\n\n超时**抛错不吞**：五个 publish 点各有自己的失败语义（dispatcher 累加 attempts 走死信，\n进程内扇出向上传播）。在 helper 里吞掉就变成事件静默丢失，比挂住更糟。\n\n证据：\n· contracts 9 例判定单测——含「超时后底层 promise 迟到 reject 不产生 unhandledRejection」\n 与「15s 预算最多放行 7 行」（关键不是 7，是它 \u003c 50）；\n· 两后端各 4 例真实 ioredis 打黑洞服务端验收，**直接测生产类**\n （new EventBus(hungRedis) / new EventBusService(hungRedis, ...)）——在测试里另写一份\n publish 只能证明 helper 能用，证明不了生产路径接了它；\n· check:dual-backend 增 12 条 targeted 断言（五个 publish 点 + 两处刹车 + 黑洞用例本身）\n + 1 个受控断线负探针，dualBackendParityNegativeProbes 3 → 4。\n负向实测：摘掉 Fastify 生产 EventBus.publish 的时限 → 该用例挂满 30 秒测试上限后红、\n其余三例仍绿（精确命中）；已恢复现场。\n\n顺带调了一个既有断言并注明理由：G16 的「提交后才发投递样本」用 4200 字节邻近窗口，预算刹车\n合法地把两点推远约 600 字节，放宽到 4800。它是邻近性启发式不是语义判据，意图未变；\n我也把预算日志挪到 observeDelivery 之后，尽量少动它的相邻性。\n\ncontracts 升 1.24.0（expand-only），两把锁重签，下游 fixture 源码未改即通过。\n\n证据：typecheck 13/13；pnpm check 28/28。runtime 整轮与报告回绑在下一提交。\n锚点按 C241 指向父提交 94ec469。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:29:12-07:00"}],"HeadCommit":{"Sha1":"01d0eabfa71ec061d876d39d4f399d2290530a15","Message":"chore(reports): runtime 30/30 + 静态 28/28 回绑 @ 56e6e57；锚点随批次刷新\n\nRedis 发布时限批次的三级证据，绑定 clean HEAD `56e6e57`（worktreeDirty:false）：\n\n· runtime 30/30 步、**776 tests / 0 failures**、行为矩阵 **204/204**（地板 204）；\n 776 = 759 + 本批 17 例（contracts 9 + 两后端各 4），与前置预测一致。\n dependency-resilience / multi-instance / write-capacity 这些真打 Redis 的\n 门禁全过——2 秒时限没有误伤健康链路。\n· 静态 28/28。\n· 依赖 pnpm audit --prod --audit-level high = 0 high / 3 moderate\n （npm 审计接口 503 重试两次后成功）。\n\n本提交按 C241 把锚点指向父提交 56e6e57；证据新鲜度的 runtime 行同步回绑。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T18:44:00-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/94ec469fbac4eeda3fb9d0f0545be831e8eeb2cb...01d0eabfa71ec061d876d39d4f399d2290530a15","Len":3}... |