| content |
{"Commits":[{"Sha1":"001e16da9 {"Commits":[{"Sha1":"001e16da960e9c44fcb2f943d149bb374c710e33","Message":"chore(reports): health 采纳的四十一份三级证据 回绑 @ fc147d3，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 fc147d3（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=fc147d3、worktreeDirty:false）：\n静态 28 + 运行态 13。静态整轮 28/28（退出码 0）；运行态 735 tests / 行为矩阵 204/204 /\n87 项指标零违规。\n\nhealth 换成内核 buildHealthResponse 后**行为中性**：四处调用点、两个 dispatcher 的\n200/503 映射、NestJS 的 ServiceUnavailableException、依赖弹性用例（14 故障 + 14 恢复 +\n半开 4 + 延迟 4）全过。开工时列的三个风险点（响应形状、503 映射、超时语义）一个都未兑现。\n\n用例数 733 → 735（health 3 例改写为 5 例，覆盖面上升）；地板 683 未动——地板只在全绿后用\n--update-baseline 收紧，不随一次上浮改。\n\n本批跑了两轮 runtime，第一轮红在末尾的 docs-truth 复核（动态数字仍写 733）。\n**这是结构性自指，不是缺陷**：任何改变用例数的批次，第一轮 runtime 必然在自己最后一步的\n数字校验上失败——数字只有跑完才知道，而跑的最后一步要校验数字。已把「改动影响用例数时\n预期两轮 runtime」记进 fc147d3 的提交信息，与「先提交再跑」是同一类流程教训\n（后者本批已用上，第一轮即 clean 绑定）。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\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-18T16:31:29-07:00"},{"Sha1":"fc147d377061ea86c37cdd24e1afb0c441a6e2fe","Message":"docs(治理): 动态数字随 health 用例增补对齐——733 → 735 tests\n\nhealth 由 3 例改写为 5 例后 runtime 用例数 733 → 735，CLAUDE.md 动态区两处随之更新：\n证据新鲜度行的「(733 tests / 0 failures)」与动态表的 tests-passing 行。地板 683 不动\n（地板只在全绿后用 --update-baseline 收紧，不随一次上浮改）。\n\n**这一轮红是结构性自指，不是缺陷：** 任何改变用例数的批次，第一轮 runtime 必然在自己\n最后一步的 docs-truth 复核上失败——数字只有跑完才知道，而跑的最后一步要校验数字。\n本轮测试本身全过（735 tests / 0 failures、行为矩阵 204/204、87 项指标零违规），\n红的只有 governance-number-evidence-consistency 的两处漂移字段。修正后重跑即闭合。\n\n顺带记一条可复用的顺序：**改动会影响用例数时，预期两轮 runtime**——第一轮取真实数字，\n更新文档后第二轮取 clean 绑定的 passed 证据。与「先提交再跑」是同一类流程教训。\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-18T16:19:20-07:00"},{"Sha1":"bfc3ef5a82a201c649688dd76b3ed22704560888","Message":"feat(health): B3 余采纳内核可扩展健康检查；同批订正 B4 的分类误判\n\n两件事，都是「实测推翻先前判断」的后续。\n\n一、B4 调查结论写回立项（不改代码）\n\n先前把 `rls` 归为「同名不相干、二选一」——0% 导出重合被读成互斥，实际是**解决不同问题**：\n框架 tenant-rls 管**姿态与探测**（resolveTenantRlsMode 生产拒绝 off、assertRlsCapableRole\n启动拒绝 superuser/BYPASSRLS、tenantRlsRoleNames 派生角色名），本仓 rls 管**清单与纪律**\n（67 张表/模型登记、角色名常量、SET LOCAL ROLE 的租户 id 校验）。两者互补。\n\n调查顺带查出一个真缺口并登记进 §6：**应用不在启动时探测连接角色**。现有保护全在门禁时——\ncheck:db-credential-separation 供给角色、查 pg_roles、断言不特权（8 负例含 runtime-superuser\n探针），验的是「供给对不对」而非「应用会不会拒绝启动」。若部署时 DB URL 指向超级用户，应用\n照常启动，所有不走 tenantTx 的查询都没有 RLS。补它的前提是先采纳双 URL 模型——\nDATABASE_RUNTIME_URL 在本仓只被 scripts/with-platform-dev.mjs 用到，**两个应用根本不读它**。\n故 B4 重定义为「采纳双 URL RLS 模型 + 启动探测」，属部署面变更，独立批次。\n**没有顺手先迁 tenant-rls 契约**——那会再造一块零消费面，同一个错误不在一次会话里犯第二遍。\n\n二、health 采纳内核可扩展形态（框架 0.19.0，受理基础设施仓 FR-1）\n\n本仓原实现是固定两键 checks + evaluateHealthDependencies，属 0.19.0 之前的形态。框架把\nchecks 改为 { database; redis } \u0026 Record\u003cstring, HealthCheckState\u003e——**纯增键，既有消费者逐字\n不受影响**——并给出附加子检查登记点与名字 fail-closed（占用核心名 / 重复登记在登记这一刻抛错）。\n\n为什么现在采纳：本仓已知有拿不出来的健康维度（缺失梳理 §3 记着「消费组滞后无指标」）。\n固定两键下这类维度无处安放；换成可扩展形状后，Kafka 消费者滞后、平台端口状态才有登记位。\n\n替换而非合并：框架 buildHealthResponse + probeHealthCheck 覆盖本仓 evaluateHealthDependencies\n的全部语义，并把 service / uptime / timestamp 一并产出——四处适配器此前各自手拼这三个字段，\n正是 G17 行为漂移的老来源（两侧曾一个回浮点进程 uptime、一个回整数应用 uptime）。\n输出逐字兼容：无 extras 时 every(up) 等价于原先 database \u0026\u0026 redis，timestamp 同为 toISOString()。\n\n四处调用点全改：两个 dispatcher + Fastify 路由 + NestJS 控制器。\n\n**测试覆盖上升而非下降**：health.test.ts 由 3 例改写为 5 例——原三条语义（ok / 逐项判责 /\n超时 fail-closed）逐条在新 API 上重验，另加两条覆盖新能力（附加子检查参与 degraded 判定、\n名字 fail-closed）。contracts 312 → 314，own-test-cases 736 → 738。\n\n三处门禁断言随符号改名同步（C45 双后端 health、C58 两个 dispatcher、O11 运维平面）。\n**断言意图未变**，改的只是符号名。三条都做了实活验证：把符号换成不含原串的名字后 C45/C58/O11\n如期转红，还原复验绿。（第一次探针用 buildHealthResponseX，正则仍匹配前缀而未触发——\n探针本身的设计错误，已重做。）\n\n@repo/contracts 1.21.0 → 1.22.0；三把锁重签（exports 42 模块 / 751 导出）；接入手册锁行同步；\nCLAUDE.md 动态表 own-test-cases 随报告更新。静态整轮 28/28。\n运行态在本提交后重跑回绑——health 端点实现已换，必须验。\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-18T16:08:02-07:00"}],"HeadCommit":{"Sha1":"001e16da960e9c44fcb2f943d149bb374c710e33","Message":"chore(reports): health 采纳的四十一份三级证据 回绑 @ fc147d3，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 fc147d3（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=fc147d3、worktreeDirty:false）：\n静态 28 + 运行态 13。静态整轮 28/28（退出码 0）；运行态 735 tests / 行为矩阵 204/204 /\n87 项指标零违规。\n\nhealth 换成内核 buildHealthResponse 后**行为中性**：四处调用点、两个 dispatcher 的\n200/503 映射、NestJS 的 ServiceUnavailableException、依赖弹性用例（14 故障 + 14 恢复 +\n半开 4 + 延迟 4）全过。开工时列的三个风险点（响应形状、503 映射、超时语义）一个都未兑现。\n\n用例数 733 → 735（health 3 例改写为 5 例，覆盖面上升）；地板 683 未动——地板只在全绿后用\n--update-baseline 收紧，不随一次上浮改。\n\n本批跑了两轮 runtime，第一轮红在末尾的 docs-truth 复核（动态数字仍写 733）。\n**这是结构性自指，不是缺陷**：任何改变用例数的批次，第一轮 runtime 必然在自己最后一步的\n数字校验上失败——数字只有跑完才知道，而跑的最后一步要校验数字。已把「改动影响用例数时\n预期两轮 runtime」记进 fc147d3 的提交信息，与「先提交再跑」是同一类流程教训\n（后者本批已用上，第一轮即 clean 绑定）。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\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-18T16:31:29-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/85a263fb1667d12318daa5601f7e6e23284c5dfd...001e16da960e9c44fcb2f943d149bb374c710e33","Len":3}... |