| content |
{"Commits":[{"Sha1":"94ec469fb {"Commits":[{"Sha1":"94ec469fbac4eeda3fb9d0f0545be831e8eeb2cb","Message":"chore(reports): runtime 30/30 + 静态 28/28 回绑 @ 1b228ba；锚点随批次刷新\n\nB3″ 三级证据绑定 clean HEAD `1b228ba`（worktreeDirty:false）：\n\n· runtime 30/30 步、**759 tests / 0 failures**、行为矩阵 **204/204**（地板 204）；\n 759 = 747 + 本批 12 例，与 1b228ba 前置写下的预测值一致。\n 信封加了可选 context 之后矩阵仍 204/204——它本来就比不到这个字段\n （outbox 快照只取 type + payload），这也正是本批另建 14 条绊网的理由。\n· 静态 28/28。\n· 依赖 pnpm audit --prod --audit-level high = 0 high / 3 moderate。\n\n**一轮过**。上一批因锚点没跟着提交走白跑 25 分钟，这批把锚点写进了每个提交，没有复发。\n\n本提交按 C241 把锚点指向父提交 1b228ba；证据新鲜度的 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:13:05-07:00"},{"Sha1":"1b228baf0006555572a2e829ae95f67960da7e98","Message":"chore(reports): 静态 28/28 回绑 @ aa62fba；数字前置到本批实测值\n\nown-tests 94 → 96、own-test-cases 750 → 762（+2 文件 / +12 例信封上下文验收，C70 只计\ngit 已跟踪文件，故必须在实现提交落地后才数得到）。\n\ntests-passing 747 → 759 是**预测值**（747 + 本批 12 例），由下一轮 runtime 实测证实；\n不等于 759 就按报告改文档。上一批已验证过这条路子：预测值被实测原样证实。\n理由同上批：改变用例数的批次结构上要两轮 runtime，先写预测能让 runtime 报告直接绑 clean HEAD。\n\n锚点按 C241 指向父提交 aa62fba——上一批就是漏在这里，白跑了一轮 25 分钟。\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:00:51-07:00"},{"Sha1":"aa62fba5da4448840228f6699f42085fb2bdeae8","Message":"feat(kernel-repin): B3″ realtime 双向合并——信封请求上下文真正贯通到 outbox\n\n内核 0.6.0 给信封加了 `context {requestId, traceId}`，但**只给了字段，没给它怎么进来**：\n写入端如何落库、读出端如何还原、无入站请求时如何表达「不知道」，三件事都留给下游发明。\n最省事的实现——投递时从当前 ALS 取一份填进去——恰好是最坏的：照着那个 requestId 去查日志\n只会查到 dispatcher 自己，「信封可追溯」就此变成假象。本批按三段落地：\n\n· 写入：outbox 加 request_id / trace_id 两列（两后端字节一致迁移，纯 additive 可空），\n 由 **Prisma 客户端扩展单点注入**。不逐处改两后端各 74 处 tx.outbox.create——那是\n 148 处一次性改动外加一条永久漂移缝：新写链忘了带就静默缺席，而少一个可空字段\n 不会让任何门禁红。扩展在交互式事务内同样生效，P4 的「outbox 与业务写同 tx」不变。\n 装配顺序固定：扩展在最内层、RLS 代理在最外层——反过来 $extends 会作用到代理的\n 目标对象上，代理当场失效。\n· 读出：dispatcher 与重放各自**从行上取**，经 contracts envelopeContextOf 还原；\n requestId 缺席即整体缺席（半份上下文既对不上日志，也不能声称知道来源）。\n· 缺席：无入站请求（worker / dispatcher / 触发器）时两列 NULL，信封里干脆没有 context。\n\n独立列而非塞 payload：payload 是领域事实，掺进基建相关性标识会被双后端行为矩阵当成领域\n差异比较——它的 outbox 快照恰好只取 type + payload。\n\n这是**合并不是 pin**：内核那版没有 resourceRefs，也没有 realtimeChannelForDatabase，\n直接 pin 会丢掉产品扩展参与订阅的唯一途径与「同 Redis 实例多环境不得互相收事件」的结构解\n（13 个消费者）。分歧已登记进迁移手册 §6，上游同步不得用内核版覆盖本文件。\n\n守护（行为矩阵**结构上证明不了这条**：上下文走独立列，矩阵只比 type + payload，\n删掉任一侧的注入或读出，204 例仍全绿）：\n· check:dual-backend 增 14 条 targeted 断言（注入点/读出点/迁移/负例本身）+ 1 个受控断线\n 负探针，dualBackendParityNegativeProbes 由 2 收紧到 3；\n· 两侧各 6 例真实 DB 验收，断言集逐条对等：落库两列 / 无请求即 NULL / dispatcher 读出 /\n 重放保留 / 半份整体缺席 / 显式值不被覆盖。\n负向实测：摘掉 Fastify 注入扩展 → 精确 3 例红；摘掉重放读出 → 精确 1 例红；均已恢复现场。\n\ncontracts 升 1.23.0（expand-only），packages/downstream 两把锁重签，下游 fixture 源码未改\n即通过（同 major 兼容成立）。顺带实测到一个门禁盲区并如实登记为 U-42：check:kernel-packages\n的 apiDigest **只哈希入口 .d.ts 字节、不含再导出的模块**，所以本批加 3 个公开导出它不会红——\n「同版本改公开 API 即红」对 barrel 式入口基本不成立，版本是自觉升的。\n\n本批明确不做、逐条登记在立项书 §5.3：内核的 defineRealtimeEventTypes 组合式事件类型、\n两个未接线的内核常量（LIVE_BUFFER_LIMIT / REDIS_COMMAND_TIMEOUT_MS——后者对应一个真实的\nRedis publish 无超时缺口）、产品事件路径（走 raw SQL，扩展覆盖不到，目前没有 context）、\nworker 派生事件继承原始请求。前三项是范围取舍，最后一项的后果是那些行 context 为 NULL——\n缺席是诚实的，不构成假象。\n\n证据：typecheck 13/13；pnpm check 28/28；两侧信封上下文验收各 6/6（真实 DB\ndigital_employee_os_acceptance_20260918 @127.0.0.1:55470 + redis :6404/3）。\nruntime 整轮与报告回绑在下一提交。锚点按 C241 指向父提交 34aab5d。\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-18T17:59:16-07:00"}],"HeadCommit":{"Sha1":"94ec469fbac4eeda3fb9d0f0545be831e8eeb2cb","Message":"chore(reports): runtime 30/30 + 静态 28/28 回绑 @ 1b228ba；锚点随批次刷新\n\nB3″ 三级证据绑定 clean HEAD `1b228ba`（worktreeDirty:false）：\n\n· runtime 30/30 步、**759 tests / 0 failures**、行为矩阵 **204/204**（地板 204）；\n 759 = 747 + 本批 12 例，与 1b228ba 前置写下的预测值一致。\n 信封加了可选 context 之后矩阵仍 204/204——它本来就比不到这个字段\n （outbox 快照只取 type + payload），这也正是本批另建 14 条绊网的理由。\n· 静态 28/28。\n· 依赖 pnpm audit --prod --audit-level high = 0 high / 3 moderate。\n\n**一轮过**。上一批因锚点没跟着提交走白跑 25 分钟，这批把锚点写进了每个提交，没有复发。\n\n本提交按 C241 把锚点指向父提交 1b228ba；证据新鲜度的 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:13:05-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/34aab5dea31113ee2688fd236eea3f382402027e...94ec469fbac4eeda3fb9d0f0545be831e8eeb2cb","Len":3}... |