|
31220
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"dea10cf11 {"Commits":[{"Sha1":"dea10cf1124b0e7714fe60f395709cda0be55fdb","Message":"docs(计划): 登记推送结果与两条实测更正 @ a178ba3\n\n三处远端均已推送并核对 SHA 一致。过程中查出 main 分支保护整个消失(404 Branch not\nprotected,非只摘必需检查)与计费仍未恢复(run 35410044850 三 job failure、注解逐字\n未变)两条,已补进 CLAUDE.md 云端治理段。\n\n按事实作用域,现在只能说到「远端已有该 SHA」,不能说「远端 CI 已通过」。保护由谁摘、\n为何摘未知,本会话未改动任何 GitHub 设置,留给仓库管理权限持有者二选一收口。\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:45:36-07:00"}],"HeadCommit":{"Sha1":"dea10cf1124b0e7714fe60f395709cda0be55fdb","Message":"docs(计划): 登记推送结果与两条实测更正 @ a178ba3\n\n三处远端均已推送并核对 SHA 一致。过程中查出 main 分支保护整个消失(404 Branch not\nprotected,非只摘必需检查)与计费仍未恢复(run 35410044850 三 job failure、注解逐字\n未变)两条,已补进 CLAUDE.md 云端治理段。\n\n按事实作用域,现在只能说到「远端已有该 SHA」,不能说「远端 CI 已通过」。保护由谁摘、\n为何摘未知,本会话未改动任何 GitHub 设置,留给仓库管理权限持有者二选一收口。\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:45:36-07:00"},"CompareURL":"luoanwu/platform-governance/compare/0bd8704df3bd5cfbed6e6b06cbcf6d211d0da76f...dea10cf1124b0e7714fe60f395709cda0be55fdb","Len":1}...
|
1789778936
|
Edit
Delete
|
|
31219
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"b90d7a151 {"Commits":[{"Sha1":"b90d7a151e5e9451fa12fb6e883b8898552124df","Message":"chore(reports): C 组三份真实验收回绑 @ 8a621fd —— 在 adversarial 隔离栈上跑,共享底座与 ms23 均未触碰\n\nC 组(runtime-acceptance / mainline-acceptance / revocation-sla)需要真实 PG + Redis + Redpanda。\nms23 那套 35 分钟前刚被并行会话用过(容器 Exited),按 docs/持久主线本地验收.md「同名 project 即使\n容器刚启动也不能直接 up 覆盖,该名称已占用时应协调或选择已有获准且无人使用的测试环境」,改用\nadversarial(PG 55473 / Redis 56382 / Broker 59095,2026-09-12 获准、闲置 3 天、其 Broker 已在故障\n注入白名单)。全程 docker start 既有容器,未 compose up 覆盖任何 project。\n\n结果(均在干净检出 8a621fd 上产出,worktreeDirty=false):\n runtime-acceptance passed 1001 tests(地板 775)、tenantRlsEnforced=1、双后端差分 0\n mainline-acceptance passed\n revocation-sla partial p95 5027ms / max 5041ms / 20 samples——远低于 MS-3 的 30s;\n partial 来自 employmentScope 链仍 pending-scope-consumer-enforcement,\n 以及生产投送/负载/staging 四项 unverified,是既定状态不是失败\n conformance-differential 作为 runtime 验收的副产物一并刷新(同样已登记 severity=warn)\n\n过程中一处失败是我搭环境搭错的,记下来免得下次再犯:首轮 e2e/identity-profile 断言\n`elevated=false` 实测 true——mainline:prepare 只为 fact/permission/audit/owner/consumer 建非超级用户\n角色,identity/credential/scope/aigateway 四个库是我用管理员 platform 手建的,identity 的连接因此是\n特权角色。REASSIGN OWNED 不适用(platform 持有系统对象),改为重建该库并 OWNER 给\nplatform_identity_test_app、以该角色重新 deploy 迁移后转绿。credential / scope 没有\nprisma:migrate:deploy 脚本是对的——它们是 state=shape 模块,按仓纪律不得有迁移。\n\n隔离与收尾:凭据只经仓外 0600 文件(/tmp/c3-mainline.env、/tmp/c3-env.sh),不入仓、不打印;\n验收在独立 worktree 里 pnpm install 自己的 node_modules,不软链主检出,避免与并行会话抢 .prisma;\nadversarial 三容器跑完恢复为 Exited(与我接手前一致)。主检出里并行会话另有十余份报告 WIP,一份没碰。\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:45:56-07:00"},{"Sha1":"a178ba36c65d82fab8106fa7395dd65f927876ad","Message":"docs(治理): 云端治理段补 2026-09-19 实测——分支保护已整个消失,而计费仍未恢复\n\n推送本会话提交时实测到两条与在案记录对不上的事实:\n\n① main 的分支保护整个没了,不是摘掉那条必需检查而已:\n gh api .../branches/main/protection → 404 \"Branch not protected\"。\n 镜像因此重新推得动,直推 54e6324..12093b8 成功并已核对 github/main 与本地一致;\n 「镜像停在 3308542」这句作废。谁摘的、何时、为什么未知,gh 查不到保护变更历史。\n 本会话未恢复保护、未改动任何 GitHub 设置——不知原委时自行配回去,风险大于留着不动。\n\n② 计费没解决,原记录前半截仍成立:该次直推触发的 run 35410044850 三 job failure、\n 五 skipped,注解逐字仍是 recent account payments have failed。\n\n故「镜像推得动」≠「远端验过了」:这批提交在 GitHub 上一次门禁都没跑过,远端只是有了代码。\n\n第三条是写给下一个人的:本条与同段「不要靠摘必需检查绕过」的口径现在对不上现实,须由\n仓库管理权限持有者二选一收口——恢复保护,或把「为什么现在不设保护」写成显式裁决并给\n复核期。保持现状而不记录,等于让一条在案的治理资产无声消失。\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:45:16-07:00"}],"HeadCommit":{"Sha1":"b90d7a151e5e9451fa12fb6e883b8898552124df","Message":"chore(reports): C 组三份真实验收回绑 @ 8a621fd —— 在 adversarial 隔离栈上跑,共享底座与 ms23 均未触碰\n\nC 组(runtime-acceptance / mainline-acceptance / revocation-sla)需要真实 PG + Redis + Redpanda。\nms23 那套 35 分钟前刚被并行会话用过(容器 Exited),按 docs/持久主线本地验收.md「同名 project 即使\n容器刚启动也不能直接 up 覆盖,该名称已占用时应协调或选择已有获准且无人使用的测试环境」,改用\nadversarial(PG 55473 / Redis 56382 / Broker 59095,2026-09-12 获准、闲置 3 天、其 Broker 已在故障\n注入白名单)。全程 docker start 既有容器,未 compose up 覆盖任何 project。\n\n结果(均在干净检出 8a621fd 上产出,worktreeDirty=false):\n runtime-acceptance passed 1001 tests(地板 775)、tenantRlsEnforced=1、双后端差分 0\n mainline-acceptance passed\n revocation-sla partial p95 5027ms / max 5041ms / 20 samples——远低于 MS-3 的 30s;\n partial 来自 employmentScope 链仍 pending-scope-consumer-enforcement,\n 以及生产投送/负载/staging 四项 unverified,是既定状态不是失败\n conformance-differential 作为 runtime 验收的副产物一并刷新(同样已登记 severity=warn)\n\n过程中一处失败是我搭环境搭错的,记下来免得下次再犯:首轮 e2e/identity-profile 断言\n`elevated=false` 实测 true——mainline:prepare 只为 fact/permission/audit/owner/consumer 建非超级用户\n角色,identity/credential/scope/aigateway 四个库是我用管理员 platform 手建的,identity 的连接因此是\n特权角色。REASSIGN OWNED 不适用(platform 持有系统对象),改为重建该库并 OWNER 给\nplatform_identity_test_app、以该角色重新 deploy 迁移后转绿。credential / scope 没有\nprisma:migrate:deploy 脚本是对的——它们是 state=shape 模块,按仓纪律不得有迁移。\n\n隔离与收尾:凭据只经仓外 0600 文件(/tmp/c3-mainline.env、/tmp/c3-env.sh),不入仓、不打印;\n验收在独立 worktree 里 pnpm install 自己的 node_modules,不软链主检出,避免与并行会话抢 .prisma;\nadversarial 三容器跑完恢复为 Exited(与我接手前一致)。主检出里并行会话另有十余份报告 WIP,一份没碰。\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:45:56-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/12093b843ef69d300370e5da16fcca3399c14d40...b90d7a151e5e9451fa12fb6e883b8898552124df","Len":2}...
|
1789778893
|
Edit
Delete
|
|
31218
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"0bd8704df {"Commits":[{"Sha1":"0bd8704df3bd5cfbed6e6b06cbcf6d211d0da76f","Message":"docs(计划): 登记 docs-truth 那条红的修复 @ 8a621fd / 12093b8\n\n动态区 UI 条目实为三处漂移(SHA、端口、验收库),门禁只抓得到 SHA 一处;只换 SHA 会把红\n变绿却留着两句假话,故三处一并订正。同时记下 freshness-sha-* 的覆盖边界:它只断言 SHA\n的声明形式,同条目里的端口与库名可以静默漂移——绿不代表整行都对。\n\nruntime check 现 exit 0、16 项全过;报告在干净 worktree 整批重出回绑,check:evidence\n降至 0 error。\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:34:13-07:00"},{"Sha1":"f84a1e12c72975d9a25af5f9fe62413314b9a280","Message":"docs(计划): 登记盲区复核第二轮结果——无新洞,并自查本轮新增的两处接线\n\n四类结果与首轮一致:够不到的检查器 1 个(dev helper 非门禁)、登记报告 0 份无产出方、\n未构建检出逐道跑无新的空跑即绿、流外门禁 5 道复核期均未过期。\n\n自查本轮自己新加的两样是否变成同类盲区:check:fixture-coverage 四处接线齐全;identity\n的两条 freshness 断言经递归展开确认 CI 的 identity job 可达。\n\n同时写清边界:接线正确不等于当前在把关——GitHub Actions 因计费停摆、Gitea 镜像通道从未\n启用,两条均已在案,故这些门禁当前实际把关仍只在本机。\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:29:40-07:00"},{"Sha1":"4a26207d8d4f89aa1b24b7ad4698b6091cc92361","Message":"docs(计划): 登记 identity docs-truth 补 freshness-sha 断言 @ 1f3ff8c / 6687aec\n\n出口二选一取 ②。口径移植自 runtime 版并保留其三条设计判断(不含静态级、未接线跳过而非\n恒红、必须是声明形式);唯一差异是认本仓实际写法 clean commit `sha`。负向三项实做,含\n上游记载过的「SHA 只出现在提交区间里」那条自我假绿陷阱。\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:25:17-07:00"},{"Sha1":"32f549d3f61c3729d1a00abb65f50df542c84c39","Message":"docs(计划): 登记全仓盲区复核结果与 identity 漂移订正 @ a48cbd6\n\n系统性扫描四类形态,唯一真发现是 identity/reports 完全在新鲜度扫描面之外,且已造成\n一处数字漂移(文档 255 @ 85d538b vs 报告 261 @ 25ead3e),当日已修并补处置说明。\n其余四类均核过且干净,含未构建检出里逐道跑根链验证无新的空跑即绿。\n\n另记本轮自己的三次假阳性及其成因,均在报出前复验修正。\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:20:38-07:00"},{"Sha1":"c3ae79df23ed6c5e055ef1c5ac6862f14bc477fe","Message":"docs(计划): 登记 fixture-coverage 升格为门禁 @ ab28a95 / 83a5542\n\nOwner 裁方案 B。升格前提是先修掉它自己的假绿:不构建直接跑时 15 个套件全跳过而两个\n总数双双为 0、退出码 0,naive 接进 CI 就是永远绿。只阻断 wiringTotal,nowhereTotal 因\n改进过程中非单调只记不拦。另修一处证据污染:显式 --suite 不再写仓级报告。\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:13:51-07:00"}],"HeadCommit":{"Sha1":"0bd8704df3bd5cfbed6e6b06cbcf6d211d0da76f","Message":"docs(计划): 登记 docs-truth 那条红的修复 @ 8a621fd / 12093b8\n\n动态区 UI 条目实为三处漂移(SHA、端口、验收库),门禁只抓得到 SHA 一处;只换 SHA 会把红\n变绿却留着两句假话,故三处一并订正。同时记下 freshness-sha-* 的覆盖边界:它只断言 SHA\n的声明形式,同条目里的端口与库名可以静默漂移——绿不代表整行都对。\n\nruntime check 现 exit 0、16 项全过;报告在干净 worktree 整批重出回绑,check:evidence\n降至 0 error。\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:34:13-07:00"},"CompareURL":"luoanwu/platform-governance/compare/b0c8f85aaf3e0d5d8581c460a2bebbe2c14e9a85...0bd8704df3bd5cfbed6e6b06cbcf6d211d0da76f","Len":8}...
|
1789778300
|
Edit
Delete
|
|
31217
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"34aab5dea {"Commits":[{"Sha1":"34aab5dea31113ee2688fd236eea3f382402027e","Message":"chore(reports): runtime 30/30 + 静态 28/28 回绑 @ 47e6fe3;锚点随批次刷新\n\n三级证据本批首次同时绑定 clean HEAD `47e6fe3`(worktreeDirty:false):\n\n· runtime 30/30 步、**747 tests / 0 failures**、行为矩阵 **204/204**(地板 204);\n 七包测试、迁移 deploy/status、auth-startup、db-credential-separation、tracing、\n dependency-resilience、capacity、write-capacity、multi-instance 全通过。\n 747 = 735 + 本批 12 例,与 b71b745 前置写下的预测值一致——预测被实测证实,\n 不是反过来改文档迁就。\n· 静态 28/28。\n· 依赖 pnpm audit --prod --audit-level high = 0 high / 3 moderate(收尾清单硬条目)。\n\nauth-startup 现有**三类拒启各 2/2**:无验签器、显式 demo、**生产缺 APP_ID**。第三类是本日\n新增,`missingAppIdRejected: 2` 是两个后端都真的起不来的机器回执——它抓到的正是本批自己\n第一版的惰性解析缺陷,不是事后补的装饰。\n\n跑了三轮 runtime,如实记账:\n ① 红在 auth-startup —— 真缺陷(惰性 APP_ID),已修(47e6fe3 的父提交);\n ② 实质全绿但红在收尾 docs-truth 的快照锚点滞后 —— 锚点停在 3949dcc 而 HEAD 已走两步,\n 打穿 C232 的 +1 自指窗。修复提交已把锚点折进去指向其父提交;\n ③ 30/30 全绿,即本提交回绑的这一份。\n第 ② 轮暴露的是我自己的流程错:改变用例数的批次天然要两轮,但锚点该在每个提交里跟着走,\n不该等到最后一个提交才想起来——C241 写的就是这条,这次仍然踩了。\n\n本提交按 C241 把锚点指向父提交 47e6fe3;证据新鲜度里 runtime 与 auth-startup 两行同步回绑。\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:38:01-07:00"},{"Sha1":"47e6fe38803a863e867b9f8a6141540da75736ee","Message":"fix(kernel-repin): APP_ID 改为装配期强制解析——惰性解析让生产「起得来但每个请求 500」\n\n本批 runtime 第一轮就红在 auth-startup,抓到的是我自己引入的缺陷,不是环境问题:\n\n首版 appId() 是**惰性**的(第一次请求才解析)。于是生产缺 APP_ID 时进程**正常启动**,\n随后 /api/health 与每个业务请求各 500 一次——栈顶就是 request-context 插件。内核对\nresolveAppId 写明的语义是「生产缺失即抛错,起不来好过匿名运行」,惰性版把它退化成\n「运行但全错」,而且把一个配置错误伪装成运行时故障。假绿五形态里的「假健康读模型」\n换了个方向:健康检查自己 500,但进程活着、编排层看不出是配置问题。\n\n改法:\n· appId() 解析失败时包一层稳定归因码 `[APP_ID_REQUIRED]`(与 C51 的 AUTH_VERIFIER_REQUIRED、\n C153 的 secret 读取同款——门禁判定归因码,不去匹配内核的中文消息);\n· 新增 assertRequestContextStartup(),在**四个入口**启动期强制解析:\n NestJS create-app.ts / Fastify app.ts(紧挨 assertTenantAuthStartup)\n + 两个 dispatcher 的 main()(contextFromJob 同样以 APP_ID 标识来源应用);\n· check:auth-startup 增加**第三类拒启负例**:生产 + required + 有 verifier、但显式拿掉\n APP_ID → 必须起不来。指标 missingAppIdRejected 入棘轮(floor 2);\n· 八个启动生产入口的 runner 显式提供 APP_ID——它们本来就该像真实编排那样配齐环境,\n 这不是放宽判据:判据是「缺了要拒启」,由上面那条负例证明,不是靠别的 runner 顺带不配。\n\n绊网加厚:check:dual-backend 的 RequestContext 断言由 7 条扩到 14 条,覆盖四个入口的启动闸、\n两份持有模块的归因码,以及那条负例本身——防惰性解析回潮(它在 typecheck 和行为矩阵下都是绿的)。\n\n第一轮 runtime 的其余结果(报告已随失败轮作废,此处只作判断依据,不作证据引用):\n21 个步骤 status=0,**testsPassed=747——与上一提交前置的预测值一致**,两个 request-context\n验收文件各 6 例都在里面;唯一红的是 auth-startup。行为矩阵未执行(在 auth-startup 之后)。\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:14:16-07:00"},{"Sha1":"b71b745a36f3b4786d177604aa7034bf5a43ba39","Message":"chore(reports): 静态 28/28 回绑 @ 3949dcc;数字前置到本批实测值\n\n静态 28 份报告在实现提交上重新生成并回绑(`check:kernel-admission` 42 模块 / 751 导出、\n`check:kernel-boundaries` 147/147 受管面 / 245/245 锁定文件、`check:dual-backend` 负探针 2/2)。\n\nCLAUDE.md 动态数字随本批改动前移:\n own-tests 92 → 94 (+2 个 request-context 验收文件,C70 只计 git 已跟踪,\n 故必须在实现提交落地后才数得到)\n own-test-cases 738 → 750 (+12 例,与 governance.latest.json 实测一致)\n tests-passing 735 → 747 (**这一个是预测值**:735 + 本批 12 例,尚未被 runtime 实测)\n\n「tests-passing 写在实测之前」是本仓已知的结构性自指,不是抄数:任何改变用例数的批次\n都会在自己第一次 runtime 的收尾 docs-truth 上红——C231/C244 把该复验放在 canonical 报告\n写下之后,而正确数字只有跑完才知道。两条出路都要跑两轮 runtime(先跑得数再改文档,或\n先写预测再跑),这里选后者,好处是 runtime 报告能直接绑定 clean HEAD。\n**若下一轮实测不等于 747,以报告为准修正本行,不反过来迁就文档。**\n\n快照锚点按 C241 指向实现提交 3949dcc。\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:59:31-07:00"},{"Sha1":"3949dcccd743f991487c1438db85ddb11277cc4c","Message":"feat(kernel-repin): RequestContext 从 HTTP 层贯通——两后端回显 x-request-id / x-trace-id\n\nB2c-2 与 B3″ 的共同前置(立项 §5.2)。形状与解析全部取自 contracts `request-context.ts`\n(转发自 `@juhai/kernel` 0.22.0),本仓只写 AsyncLocalStorage、APP_ID 解析与两个框架各自的\n入口适配——不复制第二份判定。\n\n修的是一个真缺陷,不只是搬代码:本仓此前**不回显任何相关性标识**,调用方拿到 500 之后\n没有任何能交给运维去查日志的句柄。现在固定回显 x-request-id;有合法 traceparent 时另回\nx-trace-id。入站 requestId 合法即沿用(跨服务相关性的唯一意义),非法即丢弃重生成——不把\n外部字符串反射进响应头与日志。\n\n装配(两侧必须最先,鉴权在其后才能 enrich,响应头回显要覆盖其后所有分支):\n NestJS create-app.ts 第一个 app.use(先于 trace 中间件)\n Fastify app.ts 第一个 register(先于 setErrorHandler 与既有 hook)\n\n与既有 rls-context 并存、刻意不合并:那一份持有 RLS 执行身份(tenant/system 两态),\n这一份持有请求可追溯性。失败语义不同,合成一个 store 会让「租户缺失」与「上下文缺失」\n不可区分。\n\n⚠️ 部署侧同批改动:resolveAppId 在生产缺 APP_ID 时抛错拒绝启动,\ndeploy/production/compose.yml 的 x-api-environment 与 x-dispatcher-environment 两个锚点\n都已写入 APP_ID。漏掉任一个,对应进程起不来——不能等下一批补。\n\n为什么额外建绊网:行为矩阵**结构上证明不了这条**。x-request-id 是实例噪声,被显式排除在\n22 个稳定响应头白名单之外(两端值必然不同),所以删掉任一侧的装配点,矩阵 204 例仍全绿。\n补两层:\n · check:dual-backend 新增 7 条 targeted 断言(含装配顺序、两个 compose 锚点各一)\n + 一个受控断线负探针;dualBackendParityNegativeProbes 由 1 收紧到 2;\n · 两侧各 6 例真实 HTTP 验收 request-context.acceptance.test.ts,断言集逐条对等:\n 无头生成 / 合法沿用 / 非法重生成 / traceparent 取 trace-id / 畸形不猜 / 404 也回显。\n\n负向实测(已恢复现场):注释掉 Fastify 的 register → 该侧 6/6 精确红;注释掉 NestJS 的\napp.use → 该侧 6/6 精确红。\n\n本批没做、也不声称:outboxContext() 与 decisionContext() 目前**零调用方**——把 context\n写进 outbox 行是 B3″,接进权限判定是 B2c-2(仍卡 ADR 0011 裁决)。本批只交付「上下文在\n请求入口真实存在、可被下游取用、且对外可见」。\n\n边界归属:新增 3 个源码文件按 CORE 归属,kernel.boundaries.lock 重签,受管面 146→147、\n锁定文件 242→245,CLAUDE.md 同步。baseline 只收紧本批真正改变的那个字段\n(dualBackendParityNegativeProbes 1→2)——其余若干地板确实落后于现值(ownTests 83 vs 92、\nrlsProtectedTables 65 vs 67 等),那是另一件事,不在本批顺手扫掉。\n\n证据:typecheck 13/13;pnpm check 28/28;两侧 request-context 验收各 6/6(真实 DB\ndigital_employee_os_acceptance_20260918 @127.0.0.1:55470 + redis :6404/3)。\nruntime 整轮与报告回绑在下一提交。\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:56:13-07:00"}],"HeadCommit":{"Sha1":"34aab5dea31113ee2688fd236eea3f382402027e","Message":"chore(reports): runtime 30/30 + 静态 28/28 回绑 @ 47e6fe3;锚点随批次刷新\n\n三级证据本批首次同时绑定 clean HEAD `47e6fe3`(worktreeDirty:false):\n\n· runtime 30/30 步、**747 tests / 0 failures**、行为矩阵 **204/204**(地板 204);\n 七包测试、迁移 deploy/status、auth-startup、db-credential-separation、tracing、\n dependency-resilience、capacity、write-capacity、multi-instance 全通过。\n 747 = 735 + 本批 12 例,与 b71b745 前置写下的预测值一致——预测被实测证实,\n 不是反过来改文档迁就。\n· 静态 28/28。\n· 依赖 pnpm audit --prod --audit-level high = 0 high / 3 moderate(收尾清单硬条目)。\n\nauth-startup 现有**三类拒启各 2/2**:无验签器、显式 demo、**生产缺 APP_ID**。第三类是本日\n新增,`missingAppIdRejected: 2` 是两个后端都真的起不来的机器回执——它抓到的正是本批自己\n第一版的惰性解析缺陷,不是事后补的装饰。\n\n跑了三轮 runtime,如实记账:\n ① 红在 auth-startup —— 真缺陷(惰性 APP_ID),已修(47e6fe3 的父提交);\n ② 实质全绿但红在收尾 docs-truth 的快照锚点滞后 —— 锚点停在 3949dcc 而 HEAD 已走两步,\n 打穿 C232 的 +1 自指窗。修复提交已把锚点折进去指向其父提交;\n ③ 30/30 全绿,即本提交回绑的这一份。\n第 ② 轮暴露的是我自己的流程错:改变用例数的批次天然要两轮,但锚点该在每个提交里跟着走,\n不该等到最后一个提交才想起来——C241 写的就是这条,这次仍然踩了。\n\n本提交按 C241 把锚点指向父提交 47e6fe3;证据新鲜度里 runtime 与 auth-startup 两行同步回绑。\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:38:01-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/2ef8d2fea20dcc03a7397ed3fc71312b675a70d9...34aab5dea31113ee2688fd236eea3f382402027e","Len":4}...
|
1789778300
|
Edit
Delete
|
|
31216
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"12093b843 {"Commits":[{"Sha1":"12093b843ef69d300370e5da16fcca3399c14d40","Message":"chore(reports): runtime 静态门禁链 18 份回绑 @ 8a621fd\n\n8a621fd 订正动态区 UI 条目后,docs-truth 的作用域(含 runtime/CLAUDE.md)随之过期;\nruntime check 是一条链、跑一次重出全部 16 项,故整批回绑而不是只挑一份——绑定一致比\n少改几个文件重要(同 b60cc18 的口径)。顺带清掉此前 error 级的 runtime-governance\n(绑 7fc7f02,作用域内 3 个文件已变)。\n\n在 HEAD 的干净 worktree(企业控制面/.worktrees/)装依赖 + prisma:generate 后跑\npnpm --dir runtime check:exit 0、16 项全过;只带回 provenance 绑 8a621fd 且\nworktreeDirty=false 的 18 份。\n\n刻意未带回 4 份:runtime-acceptance / ui-acceptance / conformance-differential 需真实\nDB 与浏览器,不由静态链产出,保持各自原绑定(08c3788 / 67e8193);framework-migration\n至今没有嵌套 provenance,已在 evidence-scopes 未登记账里具名。\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:33:42-07:00"},{"Sha1":"8a621fdb03a44cebc985f97332ead8bbb785a685","Message":"docs(runtime): 动态区 UI 条目订正三处——SHA、端口、验收库;check:docs-truth 转绿\n\nc4ec6f6 把 ui-acceptance 重绑到 67e8193 后没回灌动态区,check:docs-truth 的\nfreshness-sha-ui 从那时起一直红。逐项核对报告后发现**这一行有三处与报告对不上,\n而门禁只抓得到其中一处**:\n\n clean `1b23285` → 报告绑 `67e8193`(门禁抓到的就这条)\n web :3120 / api :3222 → 报告是 web :3100 / api :3202\n 「同上验收库与 Redis」 → UI 用的是 enterprise_platform_ui_acceptance,\n 与上一行 runtime 那轮的 enterprise_platform_acceptance_20260918\n 不是同一个库;Redis 逻辑库(:56380 db7)才是相同的\n\n只换 SHA 会把红变绿却留着后两句假话,故三处一并订正,并把「不是同一个库」写明——\n这一行紧跟在 runtime 条目之后,「同上」原本就容易被读成同一套基座。\n\n顺带记下门禁的覆盖边界:freshness-sha-* 只断言「动态区是否以声明形式写出报告当前的\nSHA」,同一条目里的端口、库名、用例描述都不在它的判据内,可以静默漂移——本次两处正是\n这样漂的。这不是缺陷而是取舍(把整行结构化对账会把门禁变成文档格式检查器),但读的人\n要知道绿不代表整行都对。\n\n核验:pnpm --dir runtime check 现 exit 0、16 项全过(本会话首次整条绿);\ncheck:governance-docs 绿(AGENTS.md 符号链接一致)。本次跑链改脏的 runtime/reports\n已全部还原,报告另在干净检出重出。\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:32:06-07:00"}],"HeadCommit":{"Sha1":"12093b843ef69d300370e5da16fcca3399c14d40","Message":"chore(reports): runtime 静态门禁链 18 份回绑 @ 8a621fd\n\n8a621fd 订正动态区 UI 条目后,docs-truth 的作用域(含 runtime/CLAUDE.md)随之过期;\nruntime check 是一条链、跑一次重出全部 16 项,故整批回绑而不是只挑一份——绑定一致比\n少改几个文件重要(同 b60cc18 的口径)。顺带清掉此前 error 级的 runtime-governance\n(绑 7fc7f02,作用域内 3 个文件已变)。\n\n在 HEAD 的干净 worktree(企业控制面/.worktrees/)装依赖 + prisma:generate 后跑\npnpm --dir runtime check:exit 0、16 项全过;只带回 provenance 绑 8a621fd 且\nworktreeDirty=false 的 18 份。\n\n刻意未带回 4 份:runtime-acceptance / ui-acceptance / conformance-differential 需真实\nDB 与浏览器,不由静态链产出,保持各自原绑定(08c3788 / 67e8193);framework-migration\n至今没有嵌套 provenance,已在 evidence-scopes 未登记账里具名。\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:33:42-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/6687aecfababeb5c03b9fa56d306e8212e79e107...12093b843ef69d300370e5da16fcca3399c14d40","Len":2}...
|
1789778290
|
Edit
Delete
|
|
31215
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"6687aecfa {"Commits":[{"Sha1":"6687aecfababeb5c03b9fa56d306e8212e79e107","Message":"chore(reports): identity docs-truth 回绑 @ 1f3ff8c —— 含新增的两条 freshness 断言\n\n绑 1f3ff8c、worktreeDirty=false、docsTruthViolations=0。该门禁自身零依赖,故在 HEAD 的\n干净 worktree 里直接 node 即可跑出,不需要 install。\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:24:55-07:00"},{"Sha1":"1f3ff8c8f7d688955cc786f83cc79cc21fd73cc2","Message":"feat(identity): check:docs-truth 补 freshness-sha 断言,证据处置出口 ② 落地\n\na48cbd6 登记的二选一出口,门禁 Owner 取 ②。identity 的报告此前两头都照不到:\nidentity/reports 不在 governance/check-evidence-freshness.mjs 的扫描面内(那边只扫\nreports/ 与 runtime/reports/),而 identity 自带的 check:docs-truth 有 0 条 freshness\n断言(runtime 版有 4 条)。当日实测它已真的漂了一次——动态区写 255 / 12 @ 85d538b,\n报告实际是 25ead3e(261 项)与 90cda56(UI 12)。\n\n口径移植自 runtime/scripts/check-docs-truth.mjs,保留其三条设计判断,逐条都有理由:\n\n 刻意不含静态级——governance.latest.json 每次 check 都重绑当时 HEAD,对它断言等价于\n 「每次提交都必须改文档」,提交报告后必红,那是会误杀的门禁不是有牙的门禁。\n\n 未接线的级别跳过而不是判红——恒红门禁不携带信息。本仓只接了 check:runtime 与 check:ui,\n 故只有这两条;deployment / production 两级在 identity 不存在,未列入。\n\n 必须是声明形式——上游实锤过一次自我假绿:条目为说明陈旧度写了提交区间 A..B,裸 includes\n 命中散文里的顺带提及,于是「文档声明 A、报告是 B」这个断言唯一要防的形态被整个绕过。\n\n与上游的唯一差异:本仓动态区写法是 clean commit `sha`(上游是 clean `sha`),两种都认——\n让断言认识本仓真实措辞,而不是为迁就工具去改文档。\n\n负向三项实做:① 把 runtime 条目 SHA 改回 85d538b → exit 1 并点名期望形式;② SHA 只出现在\n提交区间里(clean commit `85d538b`(区间 85d538b..25ead3e))→ 仍 exit 1,即上游那条陷阱\n在本仓也拦得住;③ UI 条目单独篡改 → exit 1。三项还原后均 exit 0。\n\nevidence-scopes 的处置说明同步更新:② 标记为已实施并记下负向证据;① 明示未做且暂不做\n(identity 按仓纪律 7 本就与根链分离,扩面会把 15 份一次性拖进根链账),现状是「identity\n的报告由 identity 自己的门禁守新鲜度」,边界清楚。本条仍随 PF-07 阶段 2 折入后作废。\n\n报告未随本提交:identity/reports/docs-truth.latest.json 我跑出来的那份绑脏树,已还原,\n按纪律在干净检出重出后另起 chore(reports)。\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:24:38-07:00"},{"Sha1":"a0145351979f7cf18de29b182000f791d6f5de05","Message":"chore(reports): release-manifest 与 port-conformance 回绑 @ e3b9d12 —— 离线可跑的那批收口\n\n排查 7 条过期证据后分三组:A 组离线可跑、B 组要重建镜像并重启容器、C 组要真实 DB / Redpanda 验收。\n本次收 A 组。sbom 那条已由并行会话 e3b9d12 先收(包清单一字未变,因为镜像还是 106 个提交前那个),\n故 A 组实收两条。\n\n- release-manifest:结论仍是 partial,缺 signature(缺少与本次 registry 镜像绑定且 cosign 验证成功的\n 签名,§3A D-2)。回绑的是「当前确实缺这一项」这个事实,不是把它跑绿。\n- port-conformance:passed。\n\n回绑做法同前几次:企业控制面/.worktrees/rebind-a 开 detached 干净检出(HEAD e3b9d12),软链主检出的\nnode_modules(写进本地 info/exclude,用后删除),build contracts / modules / clients 后逐条跑,\n只把这两份 report 拷回主检出、按 pathspec 单独提交——主检出里并行会话另有十余份报告 WIP,一份没碰。\n\n过程中一处返工:首次跑 port-conformance 失败于 `Command \"vitest\" not found`——runtime/test 是独立\nworkspace 包,我第一轮软链只覆盖了 modules / packages / apps / clients,漏了它。补上软链后 passed。\n失败那份报告没有拷回。\n\n结果:两份 provenance 均 gitSha=e3b9d12、worktreeDirty=false;e3b9d12..HEAD 未触及这两份的作用域输入,\n绑定仍成立。\n\n未收(已登记,需你决定):\n B 组 deployed-runtime —— BUILT_IMAGE_SOURCE_BEHIND,运行容器镜像源 05e3826,HEAD 已有 23 个运行时\n 输入变更(其中含本会话接线那批 fixture-evaluator 与夹具)。要 image:build 重建 + 重启 runtime 容器。\n C 组 runtime-acceptance / mainline-acceptance / revocation-sla —— 要真实 PostgreSQL + Redis + Redpanda\n 验收;本机 dev 底座 13 个容器在跑,但会真实读写隔离库。\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:24:14-07:00"}],"HeadCommit":{"Sha1":"6687aecfababeb5c03b9fa56d306e8212e79e107","Message":"chore(reports): identity docs-truth 回绑 @ 1f3ff8c —— 含新增的两条 freshness 断言\n\n绑 1f3ff8c、worktreeDirty=false、docsTruthViolations=0。该门禁自身零依赖,故在 HEAD 的\n干净 worktree 里直接 node 即可跑出,不需要 install。\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:24:55-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/e3b9d12525448038fd8d8ac3f3c1470552ce4ff7...6687aecfababeb5c03b9fa56d306e8212e79e107","Len":3}...
|
1789777575
|
Edit
Delete
|
|
31214
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"e3b9d1252 {"Commits":[{"Sha1":"e3b9d12525448038fd8d8ac3f3c1470552ce4ff7","Message":"chore(reports): sbom 回绑——包清单一字未变,因为镜像还是 106 个提交前那个\n\nlockfile 模式扫 reports/image-digest.json 指向的镜像(sha256:c0869934…,本机 docker 里还在),\n268 个包,worktreeDirty=false。\n\n**这次回绑没有改变任何实质结论:** 触发过期的是 63ff31f 改的 runtime/pnpm-lock.yaml(把 clients\n三包的 devDeps pin 成 exact),而 SBOM 描述的是镜像里的物料——镜像绑的源提交 05e3826 距当前 HEAD\n106 个提交,那些改动根本还没进镜像。逐包比对确认:新旧两份的包清单完全一致,变的只有 SPDX 生成时间戳。\n\n诚实读法:**provenance.gitSha 说「我是在哪跑的」,sourceSha 说「我描述的是 05e3826 的镜像」——\n两者相距 106 个提交。** 作用域纳入 runtime/pnpm-lock.yaml,是为了在锁文件变动时提醒「SBOM 可能\n不再反映当前源码」;正确回应是**重建镜像**(需 BuildKit + Gitea token,不在本机这轮范围),\n而不是重跑一遍生成器。回绑只是让证据链不挂着一条无人处理的红,没有解决镜像落后本身。\n\ncoverage 仍是 partial:只含 /srv/runtime/apps/api-nestjs 的 Node 依赖,不含基础镜像的 Debian 包。\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:22:33-07:00"},{"Sha1":"a48cbd69d9411a1c7bc85e0fb97520c4392d1e73","Message":"docs(证据): 补 identity/reports 的扫描面处置说明,并修掉它已造成的一处数字漂移\n\n全仓盲区复核查出的唯一真发现:check-evidence-freshness.mjs 只扫 reports/ 与\nruntime/reports/ 两个目录(写死在源码里),identity/reports/ 的 15 份报告既不在作用域\n登记里、也不在未登记账里——不是「未登记」,是压根没被看见。\n\nidentity 是 PF-07 阶段 1 的过渡工作区,按仓纪律 7 其三级门禁不进根 pnpm check 链,这层\n分离是有意的;但报告新鲜度的失察不是:那 15 份确实被当证据用(verify:candidate 从\nidentity/reports/baseline.json 读测试地板,docs/项目完整能力表.md E03 直接引用两份),\n而 identity 自带的 check:docs-truth 有 0 条 freshness-sha-* 断言(runtime 版有 4 条),\n于是「报告往前跑了、文档没跟上」这类漂移没有任何一道门禁能发现。\n\n它已经真的发生了。三处文档写 runtime 255 / UI 12 @ 85d538b,而报告实际绑:\nruntime-acceptance @ 25ead3e(2026-09-12,261 项 / 地板 255)、ui-acceptance @ 90cda56\n(2026-09-13,12 项)、dual-backend-behavior @ 25ead3e(差分 0)。三处按文档既有的\n「当前 + 历史」体例改正,85d538b 那轮移入历史;该次报告未记录的细节(新 UI 运行的\nWeb / API 端口)不补写,明示未记录。\n\n处置说明写进 undeclaredNote,含二选一出口(纳入扫描面逐份登记,或给 identity 的\ncheck-docs-truth 补 freshness-sha-* 断言)并注明 PF-07 阶段 2 后此条作废——但在那之前\n不得把「将来会消失」当作现在不管的理由。归门禁 Owner 裁。\n\n核验:check:evidence 未登记账仍 10 份 0 份无说明;identity check:governance-docs 与\ncheck:docs-truth 均绿;工作区一致性 L4 / L10 / L13 均 0。\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:20:16-07:00"}],"HeadCommit":{"Sha1":"e3b9d12525448038fd8d8ac3f3c1470552ce4ff7","Message":"chore(reports): sbom 回绑——包清单一字未变,因为镜像还是 106 个提交前那个\n\nlockfile 模式扫 reports/image-digest.json 指向的镜像(sha256:c0869934…,本机 docker 里还在),\n268 个包,worktreeDirty=false。\n\n**这次回绑没有改变任何实质结论:** 触发过期的是 63ff31f 改的 runtime/pnpm-lock.yaml(把 clients\n三包的 devDeps pin 成 exact),而 SBOM 描述的是镜像里的物料——镜像绑的源提交 05e3826 距当前 HEAD\n106 个提交,那些改动根本还没进镜像。逐包比对确认:新旧两份的包清单完全一致,变的只有 SPDX 生成时间戳。\n\n诚实读法:**provenance.gitSha 说「我是在哪跑的」,sourceSha 说「我描述的是 05e3826 的镜像」——\n两者相距 106 个提交。** 作用域纳入 runtime/pnpm-lock.yaml,是为了在锁文件变动时提醒「SBOM 可能\n不再反映当前源码」;正确回应是**重建镜像**(需 BuildKit + Gitea token,不在本机这轮范围),\n而不是重跑一遍生成器。回绑只是让证据链不挂着一条无人处理的红,没有解决镜像落后本身。\n\ncoverage 仍是 partial:只含 /srv/runtime/apps/api-nestjs 的 Node 依赖,不含基础镜像的 Debian 包。\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:22:33-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/d7d9fe5adc753a199dba41ec4be184d3db5053c4...e3b9d12525448038fd8d8ac3f3c1470552ce4ff7","Len":2}...
|
1789777366
|
Edit
Delete
|
|
31213
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"d7d9fe5ad {"Commits":[{"Sha1":"d7d9fe5adc753a199dba41ec4be184d3db5053c4","Message":"chore(reports): 工作台两份快照回绑 @ a157074\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑,两份均绑 a157074 /\nworktreeDirty=false。两份由同一脚本(build-workbench-snapshots.mjs)产出,rebind 登记要求\n一起带回——分开提交会让它们绑不同提交,「同一次快照」这个前提就没了。\n\nops-snapshot 此前绑 73e36fd 过期,触发是并行会话的 21d7c1a 改了 docs/runbook.md\n(该报告的作用域含它)。回绑前先还原了 reports/evidence-freshness.latest.json——\n那份是本会话跑 pnpm check 时就地覆写的脏树产物(绑 5116dc5、dirty=true),\n它落在 ops-snapshot 的作用域里,不还原 rebind 会因「作用域内有未提交输入」拒绝。\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:18:31-07:00"}],"HeadCommit":{"Sha1":"d7d9fe5adc753a199dba41ec4be184d3db5053c4","Message":"chore(reports): 工作台两份快照回绑 @ a157074\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑,两份均绑 a157074 /\nworktreeDirty=false。两份由同一脚本(build-workbench-snapshots.mjs)产出,rebind 登记要求\n一起带回——分开提交会让它们绑不同提交,「同一次快照」这个前提就没了。\n\nops-snapshot 此前绑 73e36fd 过期,触发是并行会话的 21d7c1a 改了 docs/runbook.md\n(该报告的作用域含它)。回绑前先还原了 reports/evidence-freshness.latest.json——\n那份是本会话跑 pnpm check 时就地覆写的脏树产物(绑 5116dc5、dirty=true),\n它落在 ops-snapshot 的作用域里,不还原 rebind 会因「作用域内有未提交输入」拒绝。\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:18:31-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/a15707432a286d35400876ba0420d6953cdee0fa...d7d9fe5adc753a199dba41ec4be184d3db5053c4","Len":1}...
|
1789777125
|
Edit
Delete
|
|
31212
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a15707432 {"Commits":[{"Sha1":"a15707432a286d35400876ba0420d6953cdee0fa","Message":"docs(提案): 补裁决结果——Owner 取方案 B,已实施 @ ab28a95 / 83a5542\n\n提案正文 §1—§6 保留提出时原貌不回改,结果另起 §7;抬头改为「已裁定并实施完毕」,\n免得它腐烂成一份看起来还未决的提案。§7 另记一处提案里没写、实施时才发现的证据污染:\n显式 --suite 写仓级报告等于拿合成套件的结论冒充全仓结论,现只有全量扫描才产出。\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:13:23-07:00"},{"Sha1":"a81cb95d81f556b81cfd37184dda2ee9e6ee816e","Message":"chore(reports): check:fixtures 回绑 @ ab28a95 —— 补上 10 处接线那一批欠的回绑\n\nreports/fixtures.latest.json 此前绑在 62c9d95(17 套件 468 例),check:evidence 报 EVIDENCE_STALE:\n作用域内 18 个文件已变更。增量来自本会话接线那一批六条提交——475704b(跨域流程 refresh)、\na2a86a7(scope)、f28f8f9(credential)、fe96fe6(ai-gateway)、68116db(fact)、71a04df(audit\n+ permission 残留)。每轮都写了「本次不回绑」(工作树有并行会话 WIP,拿不到 worktreeDirty=false),\n后续没人补,成了欠账。\n\n回绑做法同上一次:在 企业控制面/.worktrees/rebind-fixtures-2 开 detached 干净检出(HEAD ab28a95),\n把主检出的 node_modules 软链进去(软链不被 .gitignore 的 node_modules/ 目录规则匹配,故写进本地\ninfo/exclude,用后删除,不改仓内 .gitignore),build contracts 与七模块后跑 check:fixtures,\n确认 git status 为空再出报告,最后只把这一份 report 拷回主检出、按 pathspec 单独提交。\n\n只拷这一份:主检出里并行会话另有一批报告 WIP,以及他们刚加的 reports/fixture-coverage.latest.json\n(fixture-coverage 由诊断升格为门禁后的首份产物,已由他们自己在 83a5542 回绑),一个都没碰。\n\n结果:provenance gitSha=ab28a95、worktreeDirty=false,17 套件 701 例 0 失败 0 不可用(此前 468 例)。\n83a5542 只新增了 reports/fixture-coverage.latest.json,不在本报告作用域内,故 ab28a95 的绑定仍成立。\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:13:20-07:00"},{"Sha1":"4ead62835b2d39b84f434f333175e42d45885486","Message":"chore(reports): check:gate-flow 回绑 @ 83a5542\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑,绑 83a5542 / worktreeDirty=false。\n\n此前工作区里那份是脏树产物(绑 1de65fb、dirty=true,是本会话跑 pnpm check 时就地覆写的),\n已还原后重跑。gate-flow 的作用域含根 package.json,1de65fb 之后它又被改过,所以绑定要跟到当前 HEAD。\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:13:19-07:00"},{"Sha1":"83a554271fb7d176e403778575e45d1cd480aae9","Message":"chore(reports): check:fixture-coverage 首份回绑 @ ab28a95\n\n本门禁在 ab28a95 升格后的第一份仓级证据:15 个套件、未接线 0 处、夹具与单测都没有 0 条,\nstatus=passed;provenance 绑 ab28a95、worktreeDirty=false。\n\n主工作区常驻并行会话在途文件、拿不到干净树,按偏差 #34-A 的路径在 HEAD 开 worktree\n(落在 企业控制面/.worktrees/)装依赖、构建 dist 后跑门禁再带回。本门禁依赖 runtime 七模块\n与 contracts 的 dist,故与 check:fixtures 同属 reports:rebind 工具拒绝的那一类,手工补上\ninstall 与 build 两步。\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:12:44-07:00"},{"Sha1":"ab28a95de59f5253872b51b3d03bb8f7a4c6598c","Message":"feat(governance): fixture-coverage 由诊断工具升格为门禁并串进 check 链(Owner 裁方案 B)\n\n按 docs/夹具覆盖度探针接入提案-2026-09-18.md,门禁 Owner 裁定方案 B。提案 §4.2 的三条\n实测约束逐条落地,其中第一条是升格的前提:\n\n① 空跑即红。此前在干净检出里不构建直接跑,15 个套件全部「(未构建,跳过)」,而 --json\n 的 nowhereTotal / wiringTotal 双双为 0、退出码 0——人读的输出诚实,机器读的那份假绿,\n naive 接进 CI 就是一道永远绿的门禁。现照 check-fixtures.mjs 的既有语义:未构建的套件\n 计入 unavailable,默认失败关闭;--allow-unavailable 只降级「部分不可用」,不放行\n 「一个都跑不了」。\n\n② 只阻断 wiringTotal(未接线判定面)。它单调,适合做阻断项。\n\n③ nowhereTotal 只记不拦。它在改进过程中非单调(permission 实测 0 → 40 → 0:接线让新面\n 第一次被走到,钉完才回零),拿它阻断会拦住正在改进覆盖的那条提交本身。\n\n另修一处会污染证据的设计:显式 --suite 是定向排查与单元测试的用法,让它写\nreports/fixture-coverage.latest.json 等于拿合成套件的结论冒充全仓结论(本仓 pnpm test\n曾因此覆盖真实报告)。现只有全量扫描才产出仓级报告。\n\n接线位置紧跟 check:fixtures,复用它已建好的 dist,增量 1.4 秒;两份 CI 的 static job 跑的\n就是根 pnpm check,故无需改工作流。evidence-scopes 登记一条(error 级,作用域 = 套件清单 +\n探针 + 两侧 evaluator + 夹具用例文件)。check:gate-flow 因其已在链内不再需要具名登记。\n\n负向实做四项,全部转为回归用例(governance 测试 366 → 370):空跑 exit 1、\n--allow-unavailable 仍不放行空跑、未接线 exit 1、全接线 exit 0;另有一项手工实做——\n把 dist 里的 planner.refresh( 改成等价的 planner[\"refresh\"]((运行时行为不变,只是正则\n不再匹配),门禁精确报出 LocalAuditAppendAdmissionPlanner.refresh() 并 exit 1,还原后 exit 0。\n\n根链跑到本门禁为 passed(15 套件 / 未接线 0 / 都没有 0)。链上唯一的红是 check:docs-truth,\n与本轮无关:c4ec6f6 把 ui-acceptance 重绑到 67e8193 却没回灌 runtime/CLAUDE.md 动态区,\n已在 HEAD 干净检出复现。\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:12:04-07:00"}],"HeadCommit":{"Sha1":"a15707432a286d35400876ba0420d6953cdee0fa","Message":"docs(提案): 补裁决结果——Owner 取方案 B,已实施 @ ab28a95 / 83a5542\n\n提案正文 §1—§6 保留提出时原貌不回改,结果另起 §7;抬头改为「已裁定并实施完毕」,\n免得它腐烂成一份看起来还未决的提案。§7 另记一处提案里没写、实施时才发现的证据污染:\n显式 --suite 写仓级报告等于拿合成套件的结论冒充全仓结论,现只有全量扫描才产出。\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:13:23-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/1de65fbbf4f2ae73c374662b9e342934b925556b...a15707432a286d35400876ba0420d6953cdee0fa","Len":5}...
|
1789776809
|
Edit
Delete
|
|
31211
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1de65fbbf {"Commits":[{"Sha1":"1de65fbbf4f2ae73c374662b9e342934b925556b","Message":"feat(治理): 删除 G-12 本地旁路开关——在计费尚未恢复时删,此后发布只有 CI 一条路\n\nG-12 开头把这条通道登记为「临时设施」,约定「计费恢复、CI 发布链可用后应删除」。\n实际走向是它被用了**五趟**(rc.2 / rc.3 / rc.4 / rc.5 / rc.6),成了常态通道。\n\n**在计费尚未恢复时就删,是有意的。** 按原约定等计费恢复再删,等于把退场时机交给一件谁也不知道\n什么时候发生的事;而每多走一趟,「顺手再走一次」的门槛就低一分。删除当天实测:GitHub Actions\n最新 run 35404565689(2026-09-18T23:09,main)仍 failure,job 形态仍是计费停摆的典型\n(两个 failure + 其余 skipped),GitHub 镜像落后 46 条。\n\n改动:publish-rc.mjs 删去 localBypass 分支与 PLATFORM_RELEASE_BYPASS_CI_EVIDENCE 判读,\n守门回到 if (!dir || process.env.GITHUB_ACTIONS !== 'true')。\nprepare-package-release.mjs 的七道 require 未动,一条也没放宽。\n\n验证(退出码直取、不经管道):非 CI 环境退出码 1;**带已废弃开关退出码同样是 1**,\n脚本内对该变量的引用数为 0。\n\n**直接后果是有意接受的:CI 发布链不可用期间发不了任何 RC**,想发就得先去修 Billing。\n沉没成本一并记清楚:contracts / governance 的 rc.0—rc.6 七个版本永远不会有阶段门证据——\npublish-rc.mjs 拒绝以不同字节覆盖已发布版本,而 CI 版本必然含不同的 provenance.json,\n这七个版本号无法被 CI 重发。\n\nG-12 追加「关闭记录」一节(本文自己要求的),前五节留在原处不动:它们是这条通道存在过、\n以及它如何从「临时」变成「常态」的完整账。CLAUDE.md 的 contracts 条目同步。\n要重新启用须经裁决并在 G-12 追加记录,不要直接把那段代码改回去。\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:08:52-07:00"}],"HeadCommit":{"Sha1":"1de65fbbf4f2ae73c374662b9e342934b925556b","Message":"feat(治理): 删除 G-12 本地旁路开关——在计费尚未恢复时删,此后发布只有 CI 一条路\n\nG-12 开头把这条通道登记为「临时设施」,约定「计费恢复、CI 发布链可用后应删除」。\n实际走向是它被用了**五趟**(rc.2 / rc.3 / rc.4 / rc.5 / rc.6),成了常态通道。\n\n**在计费尚未恢复时就删,是有意的。** 按原约定等计费恢复再删,等于把退场时机交给一件谁也不知道\n什么时候发生的事;而每多走一趟,「顺手再走一次」的门槛就低一分。删除当天实测:GitHub Actions\n最新 run 35404565689(2026-09-18T23:09,main)仍 failure,job 形态仍是计费停摆的典型\n(两个 failure + 其余 skipped),GitHub 镜像落后 46 条。\n\n改动:publish-rc.mjs 删去 localBypass 分支与 PLATFORM_RELEASE_BYPASS_CI_EVIDENCE 判读,\n守门回到 if (!dir || process.env.GITHUB_ACTIONS !== 'true')。\nprepare-package-release.mjs 的七道 require 未动,一条也没放宽。\n\n验证(退出码直取、不经管道):非 CI 环境退出码 1;**带已废弃开关退出码同样是 1**,\n脚本内对该变量的引用数为 0。\n\n**直接后果是有意接受的:CI 发布链不可用期间发不了任何 RC**,想发就得先去修 Billing。\n沉没成本一并记清楚:contracts / governance 的 rc.0—rc.6 七个版本永远不会有阶段门证据——\npublish-rc.mjs 拒绝以不同字节覆盖已发布版本,而 CI 版本必然含不同的 provenance.json,\n这七个版本号无法被 CI 重发。\n\nG-12 追加「关闭记录」一节(本文自己要求的),前五节留在原处不动:它们是这条通道存在过、\n以及它如何从「临时」变成「常态」的完整账。CLAUDE.md 的 contracts 条目同步。\n要重新启用须经裁决并在 G-12 追加记录,不要直接把那段代码改回去。\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:08:52-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/aac7c6046805e0336f73206b88fdd993afc991b9...1de65fbbf4f2ae73c374662b9e342934b925556b","Len":1}...
|
1789776552
|
Edit
Delete
|
|
31210
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"aac7c6046 {"Commits":[{"Sha1":"aac7c6046805e0336f73206b88fdd993afc991b9","Message":"docs(提案): fixture-coverage 探针是否接进门禁流——请门禁 Owner 裁三件事\n\n不是裁决,未实施任何接线。提案的核心事实是一条结构性盲区:check:gate-flow 的扫描面是\n根 package.json 的 scripts,而这个探针根本不是一个 script——于是它对那道「专门用来抓\n门禁的失败信号没人看」的门禁结构性不可见,既不在统一流内也不在任何 CI 链里。\n\n价值证据是今天一天的实况:仅靠手动敲它,报出六个模块 10 处判定面「评估器没接线」\n(含 393 行、734 行两整支规则),驱动 permission 夹具 11 → 68、audit 27 → 82,并暴露出\n「按字段存在与否判放行」这一 bug 类。这些对当时在跑的每一道门禁都不可见——check:fixtures\n只能证明已登记的用例都对,证明不了该登记的都登记了。\n\n三个必须先解决的设计问题均已实测,其中第一条最要命:在干净检出里不构建直接跑,15 个\n套件全部跳过,而 --json 的两个总数双双为 0、退出码 0——naive 接进 CI 就是一道永远绿的\n门禁。另两条是陈旧 dist 会假红(本会话被 fact 误报咬过一次),以及 nowhereTotal 在改进\n过程中非单调(permission 实测 0 → 40 → 0),对它上棘轮会阻断正在改进覆盖的提交本身。\n\n推荐紧跟 check:fixtures 之后接(复用其构建,增量 1.4 秒)、空跑失败关闭、只对\nwiringTotal 上棘轮;若认为改造暂不值当,至少给它一条带复核期的登记。\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:07:21-07:00"}],"HeadCommit":{"Sha1":"aac7c6046805e0336f73206b88fdd993afc991b9","Message":"docs(提案): fixture-coverage 探针是否接进门禁流——请门禁 Owner 裁三件事\n\n不是裁决,未实施任何接线。提案的核心事实是一条结构性盲区:check:gate-flow 的扫描面是\n根 package.json 的 scripts,而这个探针根本不是一个 script——于是它对那道「专门用来抓\n门禁的失败信号没人看」的门禁结构性不可见,既不在统一流内也不在任何 CI 链里。\n\n价值证据是今天一天的实况:仅靠手动敲它,报出六个模块 10 处判定面「评估器没接线」\n(含 393 行、734 行两整支规则),驱动 permission 夹具 11 → 68、audit 27 → 82,并暴露出\n「按字段存在与否判放行」这一 bug 类。这些对当时在跑的每一道门禁都不可见——check:fixtures\n只能证明已登记的用例都对,证明不了该登记的都登记了。\n\n三个必须先解决的设计问题均已实测,其中第一条最要命:在干净检出里不构建直接跑,15 个\n套件全部跳过,而 --json 的两个总数双双为 0、退出码 0——naive 接进 CI 就是一道永远绿的\n门禁。另两条是陈旧 dist 会假红(本会话被 fact 误报咬过一次),以及 nowhereTotal 在改进\n过程中非单调(permission 实测 0 → 40 → 0),对它上棘轮会阻断正在改进覆盖的提交本身。\n\n推荐紧跟 check:fixtures 之后接(复用其构建,增量 1.4 秒)、空跑失败关闭、只对\nwiringTotal 上棘轮;若认为改造暂不值当,至少给它一条带复核期的登记。\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:07:21-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/64bc6f5489ead3c65b23869f5e8866202e60b855...aac7c6046805e0336f73206b88fdd993afc991b9","Len":1}...
|
1789776505
|
Edit
Delete
|
|
31209
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"64bc6f548 {"Commits":[{"Sha1":"64bc6f5489ead3c65b23869f5e8866202e60b855","Message":"fix(modules): audit 追加准入 plan() 补请求体检——兜底 deny-all 此前也抛\n\n71a04df 把本域接进了门禁(10 处未接线全部收口),但没动判定本身。实测 dist:\nplan(undefined) 在 request.auditEventId 上抛 TypeError,createRuntimeAuditAppendAdmissionPlanner()\n的 bundled deny-all 走同一条路——\"什么都不放行\"的最后一道在畸形入参下抛异常,等于没有兜底。\n请求来自 JSON(夹具、Owner 写入口载荷),声明类型只约束调用方。\n\n本域其余部分改前就已失败关闭,一行未动:plan({}) → REJECT、details 非对象 → REJECT、\nchanges 非数组 → REJECT、refresh(undefined) → applied:false、快照 validated 非真在 create 期抛、\ndetails 带 password → AUDIT_DETAIL_FORBIDDEN 且回 forbiddenDetails、outcome 大写 → REJECT。\n\n补 AUDIT_APPEND_REQUEST_INVALID 一条稳定原因码并钉进夹具(71a04df 的 81 例未覆盖它——\n该原因码此前不存在)。夹具 81 → 82 例(正 11 / 反 71)0 失败;模块单测 136 例;\n负向实做:把该例声明原因改成不会产生的串,门禁 exit 1 并点名,还原后 exit 0。\n覆盖度探针两档归零(未接线 0 处、夹具与单测都没有 0 条)。\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:03:47-07:00"},{"Sha1":"71a04df0f09c8ff265e6f87c0f9016b61f84b4eb","Message":"test(runtime): audit 追加准入接进门禁,10 处未接线全部收口——三档归零,17 套件 706 例\n\n最后一处:LocalAuditAppendAdmissionPlanner(734 行、本仓最大的一支 planner、三个公开方法)整支未接线。\n既有四条规则走的是事件预检与提交协议;追加准入——服务与动作登记、环境 allowlist、结果与理由码\nallowlist、details / changes 白名单与上限、权限与 Scope 决策引用、时钟偏移与事件时效、快照热更——\n一条都不在门禁上。补 append-plan / append-refresh 两条规则,判定按 kind(BLOCKED 携带 blockers)。\n接上后新暴露 41 条,逐条钉完回到 0。夹具 27 → 81 例(正 11 / 反 70)。\n\n顺带补掉 permission 的 2 条残留「仅单测」(ACTOR_CREDENTIAL_MISMATCH / TENANT_ID_INVALID)——\n那个模块的三支判定由并行会话 2822c4d 接线,这两条是接线后新暴露、尚未钉住的。夹具 68 → 70 例。\n\n至此 CLAUDE.md 登记的 10 处未接线全部收口,接线顺序与新暴露的原因码数:\n 跨域流程 refresh +4 / scope 整支 +15 / credential 整支 +6 / ai-gateway 路由与 planAiRoute +7 /\n fact 导出准入 +34 / permission 三支(并行会话,残留 2 条本次补)/ audit 追加准入 +41\n合计 109 条原因码此前任何入口都走不到——这正是「读数为 0 不等于收口」的量级。\nCLAUDE.md 同段已从「均未处理」改为已收口,并留下这份接线顺序与数字。\n\n证据:pnpm check:fixtures 17 套件 706 例 0 失败 0 不可用(此前 468 例);\nfixture-coverage 三档(都没有 / 仅单测 / 未接线)15 个套件全为 0;\nmodule-audit test 135/135、module-permission test 110/110、两模块 typecheck 绿;\n工作区一致性门禁只剩既有的 L9 compose project 撞名。\n规则源码一行未改——七次接线动的都只是评估器与夹具。本次不回绑任何 reports/。\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:03:02-07:00"},{"Sha1":"68116db133192fb66e0a6f84ee7b34cac74c9667","Message":"test(runtime): fact 的生产侧导出准入不在门禁上——补 export-plan / export-refresh,10 处的第 6 处\n\n结构比对报出 LocalFactExportAdmissionPlanner(549 行、三个公开方法)整支未接线:本模块此前只有\ndelivery 一条规则,管的是消费侧分类(重复 / 乱序 / 缺口 / 毒消息);生产侧的导出准入——事实登记、\n生产者应用与主体、Schema 摘要与兼容性、实体前缀、目录版本水位、双时间顺序、快照热更——一条都不在\n门禁上。判定逻辑一行未改,判定按 kind(BLOCKED 携带 blockers 而非 reasons)。\n\n接上后新暴露 33 条「夹具与单测都没有」+ 1 条「仅单测」,是本批到目前为止最多的一次——因为这支\nplanner 的请求体检面最宽(26 个字段)。逐条钉完回到 0。\n\n覆盖:夹具 10 → 56 例(正 5 / 反 51),规则 1 → 3;三档均为 0。新钉住的包括\nFACT_SCHEMA_NOT_REGISTERED / FACT_PRODUCER_APP_MISMATCH / FACT_PRODUCER_PRINCIPAL_NOT_REGISTERED /\nFACT_SCHEMA_DIGEST_MISMATCH / FACT_ENTITY_ID_PREFIX_MISMATCH / FACT_CATALOG_VERSION_MISMATCH /\nRECORDED_AT_BEFORE_EFFECTIVE_AT——\"谁有资格往事实流里写\"这一整面此前门禁上一条没有。\n\n工具化:这轮把「按探针给出的触发路径逐条生成用例并用真实产出回填」写成了一次性脚本跑(34 例),\n比手写快得多,也避免了我前几轮那种\"挑错底例\"的手误;每例生成后仍逐条核了\"确实拒绝\"。\n\n证据:pnpm --dir runtime --filter @juhai/module-fact test 94/94、typecheck 绿、\n该套件夹具 56/56 失败 0、fixture-coverage 三档全 0。本次不回绑任何 reports/。\n\n进度:10 处已收 6 处。余 4 处在 permission 3 / audit 1。\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:01:01-07:00"}],"HeadCommit":{"Sha1":"64bc6f5489ead3c65b23869f5e8866202e60b855","Message":"fix(modules): audit 追加准入 plan() 补请求体检——兜底 deny-all 此前也抛\n\n71a04df 把本域接进了门禁(10 处未接线全部收口),但没动判定本身。实测 dist:\nplan(undefined) 在 request.auditEventId 上抛 TypeError,createRuntimeAuditAppendAdmissionPlanner()\n的 bundled deny-all 走同一条路——\"什么都不放行\"的最后一道在畸形入参下抛异常,等于没有兜底。\n请求来自 JSON(夹具、Owner 写入口载荷),声明类型只约束调用方。\n\n本域其余部分改前就已失败关闭,一行未动:plan({}) → REJECT、details 非对象 → REJECT、\nchanges 非数组 → REJECT、refresh(undefined) → applied:false、快照 validated 非真在 create 期抛、\ndetails 带 password → AUDIT_DETAIL_FORBIDDEN 且回 forbiddenDetails、outcome 大写 → REJECT。\n\n补 AUDIT_APPEND_REQUEST_INVALID 一条稳定原因码并钉进夹具(71a04df 的 81 例未覆盖它——\n该原因码此前不存在)。夹具 81 → 82 例(正 11 / 反 71)0 失败;模块单测 136 例;\n负向实做:把该例声明原因改成不会产生的串,门禁 exit 1 并点名,还原后 exit 0。\n覆盖度探针两档归零(未接线 0 处、夹具与单测都没有 0 条)。\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:03:47-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/03af35c77d7373f504875531e22ec6fb8e078898...64bc6f5489ead3c65b23869f5e8866202e60b855","Len":3}...
|
1789776378
|
Edit
Delete
|
|
31208
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"03af35c77 {"Commits":[{"Sha1":"03af35c77d7373f504875531e22ec6fb8e078898","Message":"docs(发布): rc.6 产物行补 total files 与 shasum——37→39 是「两个文件进包」最直接的证据\n\n原记录只写了包大小(96.9→101.3 kB)。发布输出里有更精确的数字:governance 的 total files\n由 rc.5 的 37 变为 39,多出来的正是 check-fact-pii.mjs(8.6 kB) 与 fact-pii-rules.json(1.8 kB);\nbin/cli.mjs 3.9→4.0 kB 是注册子命令那行。三包 shasum 一并记入,便于事后核验。\n\n记录与发布输出已逐项核对一致(三包大小、文件数、包内容)。\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:00:41-07:00"}],"HeadCommit":{"Sha1":"03af35c77d7373f504875531e22ec6fb8e078898","Message":"docs(发布): rc.6 产物行补 total files 与 shasum——37→39 是「两个文件进包」最直接的证据\n\n原记录只写了包大小(96.9→101.3 kB)。发布输出里有更精确的数字:governance 的 total files\n由 rc.5 的 37 变为 39,多出来的正是 check-fact-pii.mjs(8.6 kB) 与 fact-pii-rules.json(1.8 kB);\nbin/cli.mjs 3.9→4.0 kB 是注册子命令那行。三包 shasum 一并记入,便于事后核验。\n\n记录与发布输出已逐项核对一致(三包大小、文件数、包内容)。\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:00:41-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/db1b4721f85189353d42e1b67586d66ba6041c88...03af35c77d7373f504875531e22ec6fb8e078898","Len":1}...
|
1789776044
|
Edit
Delete
|
|
31207
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"db1b4721f {"Commits":[{"Sha1":"db1b4721f85189353d42e1b67586d66ba6041c88","Message":"docs(部署): 记录补 §17——D-15 只说对了一半,放开 scope 在信任锚未改前无效;拆出 D-16\n\n动手处理 D-15 前先验前提,结论是前提不成立:就算放开 platform:ops,真实 IdP 令牌照样进不来。\n\n实验:用 IdP 自己的 dev 签名私钥签一个 RS256 access token(形状与真实令牌一致),把三重守卫\n的输入全部凑齐——sub 用 §16 订正后的 users.subject、azp 用白名单里的 demo-console、scope 含\nplatform:ops——打 GET /api/platform/ops/definitions,得 401 INVALID_TOKEN。不是 403、不是 scope、\n不是白名单,是签名根本没被验过:容器 AUTH_JWKS_URI 为空,token-verifier.ts:98 因此走 hs256Secret\n分支,算法集只有 HS 一族。用 IdP 真私钥而不是随便造一把,是为了堵住「那只是密钥不对」的解释。\n\n再深一层:token-verifier.ts:47-50 只认单个 key source 与单个 issuer/audience,而 IdP 是每租户\n一个 issuer、每租户一份 JWKS。单租户 dev 下是配一个 URL 的事,多租户下不是——两边模型没对齐。\n\n本轮不擅自改,两处代价都不小:改 AUTH_JWKS_URI 等于换掉整个运行时的信任锚、所有 HS256 令牌\n当场失效,而这台容器是并行会话共用的常驻 dev 运行时;给客户端放 platform:ops 则因管理 API 没有\n改已有客户端的端点,要新建客户端并同步 PLATFORM_OPS_CLIENT_IDS,且本身是安全裁决。\n\nD-15 照此改写(§16.3 那行改为指向 §17.3,避免两处并存),新拆 D-16 记信任锚与模型不匹配。\n在 D-16 未裁之前,单独放开 scope 是无效功。\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:00:37-07:00"}],"HeadCommit":{"Sha1":"db1b4721f85189353d42e1b67586d66ba6041c88","Message":"docs(部署): 记录补 §17——D-15 只说对了一半,放开 scope 在信任锚未改前无效;拆出 D-16\n\n动手处理 D-15 前先验前提,结论是前提不成立:就算放开 platform:ops,真实 IdP 令牌照样进不来。\n\n实验:用 IdP 自己的 dev 签名私钥签一个 RS256 access token(形状与真实令牌一致),把三重守卫\n的输入全部凑齐——sub 用 §16 订正后的 users.subject、azp 用白名单里的 demo-console、scope 含\nplatform:ops——打 GET /api/platform/ops/definitions,得 401 INVALID_TOKEN。不是 403、不是 scope、\n不是白名单,是签名根本没被验过:容器 AUTH_JWKS_URI 为空,token-verifier.ts:98 因此走 hs256Secret\n分支,算法集只有 HS 一族。用 IdP 真私钥而不是随便造一把,是为了堵住「那只是密钥不对」的解释。\n\n再深一层:token-verifier.ts:47-50 只认单个 key source 与单个 issuer/audience,而 IdP 是每租户\n一个 issuer、每租户一份 JWKS。单租户 dev 下是配一个 URL 的事,多租户下不是——两边模型没对齐。\n\n本轮不擅自改,两处代价都不小:改 AUTH_JWKS_URI 等于换掉整个运行时的信任锚、所有 HS256 令牌\n当场失效,而这台容器是并行会话共用的常驻 dev 运行时;给客户端放 platform:ops 则因管理 API 没有\n改已有客户端的端点,要新建客户端并同步 PLATFORM_OPS_CLIENT_IDS,且本身是安全裁决。\n\nD-15 照此改写(§16.3 那行改为指向 §17.3,避免两处并存),新拆 D-16 记信任锚与模型不匹配。\n在 D-16 未裁之前,单独放开 scope 是无效功。\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:00:37-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/fe35d013ca78dcfcec4b634a312cd0266527fe2b...db1b4721f85189353d42e1b67586d66ba6041c88","Len":1}...
|
1789776041
|
Edit
Delete
|
|
31206
|
5
|
9
|
5
|
116
|
0
|
0
|
refs/tags/packages-v1.0.0-rc.6
|
0
|
{"Commits":null,"HeadCommit":{" {"Commits":null,"HeadCommit":{"Sha1":"7eadfb1a5af353077f1a32eef51389f4a6f7fbfa","Message":"chore(release): 三包推到 1.0.0-rc.6——check:fact-pii 这次真的随包出去\n\nrc.5 发的时候 check-fact-pii.mjs 还不在 governance 包的 files 里,消费者拿到的 rc.5 不含它。\neb275b1 把它与 fact-pii-rules.json 加进 files、在 CLI 注册 check:fact-pii 子命令,\n并补上了让它在消费者仓真跑得起来的两处(--dir 指定 Fact schema 目录、判据回落到包内自带)。\n这趟车就是为了把那些送出去。\n\n自 rc.5 源 cf05344 起的随车内容:\n governance 7 文件 / 2 提交(fact-pii 进包 + 消费者可用性)\n contracts 3 文件 / 1 提交\n runtime/clients/fact 0 文件 / 0 提交 —— **完全没有变化,纯跟车**(同 rc.5)\n\n通道:本地旁路(G-12 第五次)。2026-09-18 实测 GitHub Actions 仍停在 run 35404565689\n(failure,计费),没有新 run;GitHub 镜像落后 35 条。正道仍不可满足。\n\n按 CL-5 打 tag packages-v1.0.0-rc.6(连续第三趟)。\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:56:38-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/0000000000000000000000000000000000000000...7eadfb1a5af353077f1a32eef51389f4a6f7fbfa","Len":0}...
|
1789776004
|
Edit
Delete
|
|
31205
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"fe35d013c {"Commits":[{"Sha1":"fe35d013ca78dcfcec4b634a312cd0266527fe2b","Message":"docs(发布): 记录 rc.6 列车——fact-pii 这次真出去了,并记下五趟旁路的累积代价\n\nrc.6 三包 2026-09-18 发出,源 7eadfb1,tag packages-v1.0.0-rc.6(连续第三趟按 CL-5 打上)。\n动因是补 rc.5 的缺口:那时 check-fact-pii.mjs 还不在 governance 包的 files 里,消费者拿到的\nrc.5 不含它。governance 包从 96.9 kB 涨到 101.3 kB,涨的正是那两个文件。\n\n**这一趟的验证比前四趟硬。** 前几趟只能依赖 publish-rc.mjs 的 integrity 自校验;这次把\nRegistry 登记的 dist.integrity 与本地备料 tarball 的 sha512 逐包比对,三包全部一致——\n证明架上的就是会话备的那批料,中间没有被替换或重打包。\n\n顺带纠正一个前几趟被骗过的点:npm view \u003cpkg\u003e versions 在 Gitea 的 npm registry 上静默返回空,\n查具体版本(npm view \u003cpkg\u003e@\u003cversion\u003e dist.integrity)才有结果。此前以为「Registry 查不了」,\n是被这个 API 差异骗的,不是权限问题。\n\n**记下累积代价:** 旁路第五次使用后,contracts / governance 的 rc.0—rc.6 七个版本号已全部被\n本地包永久占用,永远不会有阶段门证据;计费恢复后 CI 只能从 rc.7 发起。开关当初登记为\n「临时设施」,五趟之后它显然已是常态通道——这不是它该有的角色。计费恢复时该做的是删掉\n这个分支并让 CI 发 rc.7,而不是让它继续顺手可用。这句话写进了 G-12,免得下一趟又顺手发第六次。\n\nCLAUDE.md 的 contracts 条目同步到 rc.6,并记下 check:fact-pii 自 rc.6 起随包。\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:59:52-07:00"},{"Sha1":"fe96fe64bdb8753331280a2b3396c8237b08b9d3","Message":"test(runtime): ai-gateway 的选路本身不在门禁上——补 router-route / router-refresh / route-plan,10 处的第 4、5 处\n\n结构比对报出 LocalAiGovernanceRouter(316 行、三个公开方法)整支未接线、planAiRoute() 未接线。\n既有三条规则(action / route / egress)走的都是纯函数——动作治理、单条路由体检、外发分类判据——\n而选路本身(租户 allowlist、能力匹配、区域 / 安全层级 / 留存期、禁止静默回退、快照热更)\n与 planAiRoute 的串联(鉴权 → 外发分类 → 选路)一条都不在门禁上。判定逻辑一行未改。\n\n补三条规则,判定按 kind / outcome,不用 `\"reasons\" in`。\n\n接上后照例先变差,冒出 7 条「夹具与单测都没有」(EXPLICIT_FALLBACK_REQUIRED 与 refresh 侧六条\n策略字段守卫),逐条钉完回到 0。\n\n过程中一处预期被实测推翻:我按「删掉 allowFallback 就该拒」造 N21,实跑返回 []——主路由仍然匹配,\n删这个布尔位不构成拒绝。真要触发 EXPLICIT_FALLBACK_REQUIRED 得让快照里只剩 fallback 路由可选。\n按实现重造该例,没有反过来改实现。\n\n覆盖:夹具 16 → 35 例(正 8 / 反 27),规则 3 → 6;三档(都没有 / 仅单测 / 未接线)均为 0。\n新钉住的包括 NO_APPROVED_MODEL_ROUTE(租户越界 / 能力不符 / 无快照三条路径)、\nSENSITIVE_PROVIDER_NOT_APPROVED、EGRESS_CLASS_REQUIRES_SENSITIVE_FLAG、PERMISSION_DENIED:\u003ccode\u003e\n——AI 出站的准入闸门此前在门禁上只有纯函数那一半。\n\n证据:pnpm --dir runtime --filter @juhai/module-ai-gateway test 53/53、typecheck 绿、\n该套件夹具 35/35 失败 0、fixture-coverage 三档全 0。本次不回绑任何 reports/。\n\n进度:10 处已收 5 处(跨域流程 refresh、scope、credential、ai-gateway 两处)。\n余 5 处在 permission 3 / audit 1 / fact 1。\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:59:00-07:00"},{"Sha1":"2822c4d34a1b519fc87a21fe30b035028502d297","Message":"fix(modules): permission 三支判定接进夹具门禁,并修两处崩溃面——此前整支不在门禁上\n\n起因是 governance/fixture-coverage.mjs 的结构比对:六个运行时模块共 10 处判定面\n「评估器没接线」,permission 占 3 处(LocalPermissionDecisionPlanner、\nLocalEmploymentScopeInvalidationPlanner、evaluateCatalogAdmission)。\n\n先确认不是有意留白,三条证据:① 探针自述把「未接线」定义为「该面完全不在门禁上」,\n并在同日把契约包侧四次同形全部修掉;② 各模块夹具 description 确实声明过取舍,但都在\n另一个轴上(吊销即时性 / 配额熔断 / 查询越权,一律「属权威实现,DEC-xxx 后」),\n没有一条提到这些 planner;③ 决定性的一条——f7a0cbb 先迁入 planner,8a95879 才建夹具,\n建的时候这些文件就在同一目录里,而 8a95879 自述评估器「只调用迁入的纯规则」,\n按它自己的话这些面本就该在。\n\n实测先行,查出两处真缺陷(均已修):\n\n evaluateCatalogAdmission([null, \"x\"], …) 抛 TypeError——守了 routes 非数组,\n 没守条目非对象;目录来自快照 JSON。\n\n LocalPermissionDecisionPlanner.plan(undefined) 抛,兜底的 deny-all 也抛。\n 注意光守 preflight 不够:plan() 在 preflight 之后仍直接解引用 request.actorType 等,\n 故两处都要守。preflightCataloguedPermissionDecision 的 catalog 非数组 / 条目非对象 /\n actions 非数组一并收口。\n\n三支 employment 的 plan 是本域最结实的一支,畸形入参改前就已 REJECT,未动其判定。\n\n接线五条规则(decision-plan / employment-invalidation / catalog-admission 加两个\nplanner 的 refresh),非放行出口一律按 kind 显式映射:本域 PermissionDecisionPlanResult\n的 BLOCKED 带的是 blockers,EmploymentScopeInvalidationResult 的 SKIP_DUPLICATE 与\nACKNOWLEDGE_STALE 连原因字段都没有——按 `\"reasons\" in r` 判会把它们全判成 ACCEPT\n(该形状已在契约包侧四个域各咬过一次)。\n\n按探针自述「补规则后覆盖度会先变差,把新暴露的原因码钉完再收工」执行:接线后\n「夹具与单测都没有」由 0 涨到 40,用探针 --json 的 trigger 机械生成钉住用例并逐条实跑\n确认可复现(38 条自动 + 2 条手工,其中 ASSIGNMENT_ID_MUST_CHANGE 的 trigger 提示不准,\n删字段实得 NEW_ASSIGNMENT_ID_INVALID,按语义改为新旧指派相同才复现)。\n\n核验:夹具 11 → 68 例(正 7 / 反 61)0 失败;模块单测 63 → 108 例;探针 permission 两档\n双双归零(未接线 3 → 0、都没有 40 → 0),全仓「都没有」合计 47 → 0、未接线 10 → 4;\n负向实做:把 SKIP_DUPLICATE 的声明原因改成不会产生的串,门禁 exit 1 并点名该例,还原后\nexit 0;门禁另自行抓到我一处声明写错(PERMISSION_ADMISSION_SNAPSHOT_VERSION_NOT_FORWARD\n实为 PERMISSION_ADMISSION_VERSION_NOT_FORWARD)。\n\nruntime 静态链 12 道绿、第 13 道 check:docs-truth 红,但与本轮无关:c4ec6f6 把\nui-acceptance 重绑到 67e8193 却没回灌 runtime/CLAUDE.md 动态区,已在 HEAD 干净检出复现。\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:58:45-07:00"}],"HeadCommit":{"Sha1":"fe35d013ca78dcfcec4b634a312cd0266527fe2b","Message":"docs(发布): 记录 rc.6 列车——fact-pii 这次真出去了,并记下五趟旁路的累积代价\n\nrc.6 三包 2026-09-18 发出,源 7eadfb1,tag packages-v1.0.0-rc.6(连续第三趟按 CL-5 打上)。\n动因是补 rc.5 的缺口:那时 check-fact-pii.mjs 还不在 governance 包的 files 里,消费者拿到的\nrc.5 不含它。governance 包从 96.9 kB 涨到 101.3 kB,涨的正是那两个文件。\n\n**这一趟的验证比前四趟硬。** 前几趟只能依赖 publish-rc.mjs 的 integrity 自校验;这次把\nRegistry 登记的 dist.integrity 与本地备料 tarball 的 sha512 逐包比对,三包全部一致——\n证明架上的就是会话备的那批料,中间没有被替换或重打包。\n\n顺带纠正一个前几趟被骗过的点:npm view \u003cpkg\u003e versions 在 Gitea 的 npm registry 上静默返回空,\n查具体版本(npm view \u003cpkg\u003e@\u003cversion\u003e dist.integrity)才有结果。此前以为「Registry 查不了」,\n是被这个 API 差异骗的,不是权限问题。\n\n**记下累积代价:** 旁路第五次使用后,contracts / governance 的 rc.0—rc.6 七个版本号已全部被\n本地包永久占用,永远不会有阶段门证据;计费恢复后 CI 只能从 rc.7 发起。开关当初登记为\n「临时设施」,五趟之后它显然已是常态通道——这不是它该有的角色。计费恢复时该做的是删掉\n这个分支并让 CI 发 rc.7,而不是让它继续顺手可用。这句话写进了 G-12,免得下一趟又顺手发第六次。\n\nCLAUDE.md 的 contracts 条目同步到 rc.6,并记下 check:fact-pii 自 rc.6 起随包。\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:59:52-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/21d7c1aaae83d8d5e40aa185b1bd86d3a8d8d99f...fe35d013ca78dcfcec4b634a312cd0266527fe2b","Len":3}...
|
1789776003
|
Edit
Delete
|
|
31204
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"21d7c1aaa {"Commits":[{"Sha1":"21d7c1aaae83d8d5e40aa185b1bd86d3a8d8d99f","Message":"docs(部署,runbook): 记录补 §16——D-13 从推断变成实测、订正并复验,另登记 D-15\n\nD-13 此前只是读代码推断(判定链对不上)。本轮先做成可证伪的实测:用 dev 的 HS256 密钥\n手工签发三个只差 sub 的 token 打 GET /api/platform/ops/definitions——\n\n sub = users.subject(IdP 令牌的实际形态) 订正前 403 OPS_FORBIDDEN → 订正后 200\n sub = users.id(白名单原值) 订正前 200 → 订正后 403\n 同上但不带 platform:ops(对照) 两次都是 403 OPS_SCOPE_REQUIRED\n\n第三行是对照组,证明守卫顺序是 scope 在前、白名单在后,前两行的差异确实出在白名单这一关。\nsub 的实际形态取自 §14 那次真实登录的令牌,不是猜的。\n\n订正落在仓外 .secrets(PLATFORM_OPS_ADMIN_SUBJECTS 由 users.id 改为 users.subject,\n并在键上方留三行注释说明判定链),force-recreate 重建 runtime 容器后复验,健康探针 200。\nD-13 闭环。\n\n同时订正一个我自己此前过于保守的判断:原以为「必须等 canonical 租户分支合并后与 D-4 一并验」,\n实际 D-4 挡的是执行那一步,定义面的读取不受影响,守卫这一层现在就能独立验证。\n\n新登记 D-15:当前没有任何 OIDC 客户端的 allowedScopes 含 platform:ops(三个客户端全是\nopenid profile [idp:manage]),真实 IdP 令牌因此卡在 scope 关——不是白名单、也不是 D-4。\n给客户端放这个 scope 等于把平台运维权发给浏览器里的公开客户端,属安全裁决,留 Owner。\n\nrunbook §2.1 的警告块同步更新:那处现已订正,并指向 §16 与 D-15。\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:58:15-07:00"},{"Sha1":"f28f8f9935231e083402f5fa47269576a96eb38d","Message":"test(runtime): credential 的租约 planner 整支不在门禁上——补 lease-plan / lease-refresh,10 处未接线的第 3 处\n\n结构比对报出 LocalMachineCredentialLeasePlanner(308 行、三个公开方法)整支未接线:本模块此前只有\nlease-request 一条规则,走的是 preflight 纯规则;planner 的策略快照准入、主体登记、受众 / Scope\nallowlist、TTL 上限、授权版本水位与热更一条都不在门禁上。判定逻辑一行未改。\n\n判定按 kind:MachineCredentialLeaseResult 的 BLOCKED 携带 blockers 而非 reasons。\n\n接上规则后照例先变差:冒出 6 条「夹具与单测都没有」(归属三件套、授权版本、请求时钟,以及 refresh\n侧的版本 / 修订 / 主体策略),逐条钉完回到 0。\n\n覆盖:夹具 10 → 27 例(正 4 / 反 23),规则 1 → 3;三档(都没有 / 仅单测 / 未接线)均为 0。\n新钉住的策略面包括 AUDIENCE_NOT_ALLOWED / SCOPE_NOT_ALLOWED / TTL_OUT_OF_POLICY / STALE_AUTHORIZATION\n/ MACHINE_PRINCIPAL_NOT_REGISTERED / AI_DELEGATION_REQUIRED——凭据签发的准入闸门此前在门禁上一条没有。\n\n证据:pnpm --dir runtime --filter @juhai/module-credential test 46/46、该套件夹具 27/27 失败 0、\nfixture-coverage 三档全 0。本次不回绑任何 reports/。\n\n进度:10 处未接线已收 3 处(跨域流程 refresh、scope、credential)。余 7 处在 ai-gateway 2 /\npermission 3 / audit / fact 各 1。\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:57:26-07:00"},{"Sha1":"7eadfb1a5af353077f1a32eef51389f4a6f7fbfa","Message":"chore(release): 三包推到 1.0.0-rc.6——check:fact-pii 这次真的随包出去\n\nrc.5 发的时候 check-fact-pii.mjs 还不在 governance 包的 files 里,消费者拿到的 rc.5 不含它。\neb275b1 把它与 fact-pii-rules.json 加进 files、在 CLI 注册 check:fact-pii 子命令,\n并补上了让它在消费者仓真跑得起来的两处(--dir 指定 Fact schema 目录、判据回落到包内自带)。\n这趟车就是为了把那些送出去。\n\n自 rc.5 源 cf05344 起的随车内容:\n governance 7 文件 / 2 提交(fact-pii 进包 + 消费者可用性)\n contracts 3 文件 / 1 提交\n runtime/clients/fact 0 文件 / 0 提交 —— **完全没有变化,纯跟车**(同 rc.5)\n\n通道:本地旁路(G-12 第五次)。2026-09-18 实测 GitHub Actions 仍停在 run 35404565689\n(failure,计费),没有新 run;GitHub 镜像落后 35 条。正道仍不可满足。\n\n按 CL-5 打 tag packages-v1.0.0-rc.6(连续第三趟)。\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:56:38-07:00"},{"Sha1":"a2a86a7161102dba3d3ef227b89545ea65612273","Message":"test(runtime): scope 的 410 行 planner 整支不在门禁上——补 plan / refresh 两条规则,10 处未接线的第 2 处\n\n结构比对报出 LocalScopeResolutionPlanner(三个公开方法)整支未接线:本模块此前只有 snapshot 一条规则,\nplanner 的请求体检、应用登记、目录版本、路由匹配与热更一条都不在门禁上。判定逻辑一行未改。\n\n判定按 kind 而不是 `\"reasons\" in`:ScopeResolutionPlanResult 的 BLOCKED 携带的是 blockers,\n按字段存在与否判会被当成放行——注册中心那次就是这么漏的,这里一开始就避开。\n\n接上规则后覆盖度先变差,同样是预期的:plan / refresh 两面第一次被变异探针走到,冒出 15 条\n「夹具与单测都没有」(十条请求字段守卫 + 路由未登记 + refresh 侧四条),逐条钉完回到 0。\n\n覆盖:夹具 8 → 35 例(正 4 / 反 31),规则 1 → 3;该套件三档(都没有 / 仅单测 / 未接线)均为 0。\n模块夹具与 test/negative/*.fixtures.test.ts 同源(it.each 直接遍历夹具文件),单测随夹具自动同步。\n\n证据:pnpm --dir runtime --filter @juhai/module-scope test 53/53、typecheck 绿、\n该套件夹具 35/35 失败 0、fixture-coverage 三档全 0。本次不回绑任何 reports/。\n\n进度:10 处未接线已收 2 处(跨域流程 refresh、scope)。余 8 处在 ai-gateway 2 / permission 3 /\naudit / credential / fact 各 1,planner 308—734 行,按模块逐个收。\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:56:05-07:00"}],"HeadCommit":{"Sha1":"21d7c1aaae83d8d5e40aa185b1bd86d3a8d8d99f","Message":"docs(部署,runbook): 记录补 §16——D-13 从推断变成实测、订正并复验,另登记 D-15\n\nD-13 此前只是读代码推断(判定链对不上)。本轮先做成可证伪的实测:用 dev 的 HS256 密钥\n手工签发三个只差 sub 的 token 打 GET /api/platform/ops/definitions——\n\n sub = users.subject(IdP 令牌的实际形态) 订正前 403 OPS_FORBIDDEN → 订正后 200\n sub = users.id(白名单原值) 订正前 200 → 订正后 403\n 同上但不带 platform:ops(对照) 两次都是 403 OPS_SCOPE_REQUIRED\n\n第三行是对照组,证明守卫顺序是 scope 在前、白名单在后,前两行的差异确实出在白名单这一关。\nsub 的实际形态取自 §14 那次真实登录的令牌,不是猜的。\n\n订正落在仓外 .secrets(PLATFORM_OPS_ADMIN_SUBJECTS 由 users.id 改为 users.subject,\n并在键上方留三行注释说明判定链),force-recreate 重建 runtime 容器后复验,健康探针 200。\nD-13 闭环。\n\n同时订正一个我自己此前过于保守的判断:原以为「必须等 canonical 租户分支合并后与 D-4 一并验」,\n实际 D-4 挡的是执行那一步,定义面的读取不受影响,守卫这一层现在就能独立验证。\n\n新登记 D-15:当前没有任何 OIDC 客户端的 allowedScopes 含 platform:ops(三个客户端全是\nopenid profile [idp:manage]),真实 IdP 令牌因此卡在 scope 关——不是白名单、也不是 D-4。\n给客户端放这个 scope 等于把平台运维权发给浏览器里的公开客户端,属安全裁决,留 Owner。\n\nrunbook §2.1 的警告块同步更新:那处现已订正,并指向 §16 与 D-15。\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:58:15-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/eb275b10c470d5db1907473c40e6c831d1e7a1c6...21d7c1aaae83d8d5e40aa185b1bd86d3a8d8d99f","Len":4}...
|
1789775899
|
Edit
Delete
|
|
31203
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"eb275b10c {"Commits":[{"Sha1":"eb275b10c470d5db1907473c40e6c831d1e7a1c6","Message":"feat(治理): check:fact-pii 进 @juhai/governance 包——并补上让它在消费者仓真能跑的两处\n\n把 check-fact-pii.mjs 与 fact-pii-rules.json 加进包的 files、在 bin/cli.mjs 注册\ncheck:fact-pii 子命令。但**只加 files 是个摆设**,装到消费者仓会是个永远扫到 0 个 Fact、\n永远 exit 0 的门禁——它原先硬编码扫 contracts/schemas/facts,还硬读仓内的\ngovernance/fact-pii-rules.json。两处都补了:\n\n --dir \u003c目录\u003e… 指定 Fact schema 目录(可重复),缺省仍是本仓那两处。消费者的 Fact\n 定义不在 contracts/schemas/facts,指不过去这道门禁就没有判据对象。\n 判据回落 仓内 governance/fact-pii-rules.json 优先,缺失则用包自带的那份。\n 消费者仓没有 governance/ 目录,硬读仓内路径会让门禁在他们那儿直接崩。\n 要收紧就在自己仓里放一份同名文件覆盖。\n\n一个 Fact 都没扫到时打警告而不是静默通过——多半是目录指错了,不是「真的没有 Fact」。\n报告里记下 scanDirs 与 rulesSource,事后能看出这次扫的是哪儿、判据是谁的。\n\n消费者场景端到端验过(临时目录,无 governance/、Fact 放在 domain/facts/):\n juhai-governance check:fact-pii --root \u003cdir\u003e --dir domain/facts\n → 抓到 buyer_phone、exit 1;报告 rulesSource=bundled、scanDirs=[\"domain/facts\"]\n → 不给 --dir 时明确警告「未找到任何 Fact schema」\n本仓行为不变:21 个 Fact / 116 字段 / 0 违规,rulesSource=repo。测试 8 → 10 例。\n\nREADME 两处同步(判据表 + check 链顺序)——它随包发布,说明必须与实现一致。\n\n**时间差要知道:rc.5 昨天刚发,这些进不了 rc.5。** 包里现在这道门禁的代码要等下一个 RC\n才出得去;在那之前消费者拿到的 @juhai/governance@1.0.0-rc.5 仍不含 fact-pii。\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:54:59-07:00"},{"Sha1":"475704b56896c09a0408e1e95a87d9a9994b0667","Message":"test(contracts): 跨域流程接上 refresh——10 处未接线的第 1 处,也是我自己那轮留下的\n\ngovernance/fixture-coverage.mjs 加上结构比对后第一轮就报出 LocalWorkflowPlanner.refresh() 未接线:\nplanner 三个公开方法里只有 plan 有规则,「版本必须前进」「坏候选保留 last-known-good」两条纪律\n此前只有单测看着。这是我 13c7eb7 那轮留下的口子。\n\n顺带把 plan 的判据从 `\"reasons\" in r` 改为按 kind。今天 WorkflowPlannerResult 只有 PLAN / REJECT\n两支、行为逐字不变,但按字段存在与否判放行意味着将来加一个不带 reasons 的非放行出口就会被静默放过\n——注册中心的 BLOCKED 正是这么漏的。\n\n接上规则后覆盖度先变差,这是预期的:refresh 那一面第一次被变异探针走到,立刻冒出 4 条「夹具与单测\n都没有」(WORKFLOW_ID_REQUIRED / WORKFLOW_DOMAINS_REQUIRED / WORKFLOW_TENANTS_REQUIRED /\nWORKFLOW_REVISION_REQUIRED)与 1 条「仅单测」(WORKFLOW_VERSION_INVALID),逐条钉完回到 0。\n\n覆盖:夹具 18 → 28 例(正 3 / 反 25),规则数 3 → 4;该套件三档(都没有 / 仅单测 / 未接线)均为 0。\n判定逻辑一行未改,只动评估器与夹具。\n\n剩余 9 处未接线全在运行时模块侧(ai-gateway 2 / permission 3 / audit / credential / fact / scope 各 1),\n每个 planner 300—734 行、各自要造一份合法快照,按模块逐个收。\n\n证据:node --test contracts/test/*.test.mjs 408/408、该套件夹具 28/28 失败 0、fixture-coverage 三档全 0。\n负向实测:把 N20(通配租户那条)的声明改成 WORKFLOW_VERSION_NOT_FORWARD → 门禁 exit 1 并点名该例,\n还原后 exit 0。本次不回绑任何 reports/。\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:54:50-07:00"}],"HeadCommit":{"Sha1":"eb275b10c470d5db1907473c40e6c831d1e7a1c6","Message":"feat(治理): check:fact-pii 进 @juhai/governance 包——并补上让它在消费者仓真能跑的两处\n\n把 check-fact-pii.mjs 与 fact-pii-rules.json 加进包的 files、在 bin/cli.mjs 注册\ncheck:fact-pii 子命令。但**只加 files 是个摆设**,装到消费者仓会是个永远扫到 0 个 Fact、\n永远 exit 0 的门禁——它原先硬编码扫 contracts/schemas/facts,还硬读仓内的\ngovernance/fact-pii-rules.json。两处都补了:\n\n --dir \u003c目录\u003e… 指定 Fact schema 目录(可重复),缺省仍是本仓那两处。消费者的 Fact\n 定义不在 contracts/schemas/facts,指不过去这道门禁就没有判据对象。\n 判据回落 仓内 governance/fact-pii-rules.json 优先,缺失则用包自带的那份。\n 消费者仓没有 governance/ 目录,硬读仓内路径会让门禁在他们那儿直接崩。\n 要收紧就在自己仓里放一份同名文件覆盖。\n\n一个 Fact 都没扫到时打警告而不是静默通过——多半是目录指错了,不是「真的没有 Fact」。\n报告里记下 scanDirs 与 rulesSource,事后能看出这次扫的是哪儿、判据是谁的。\n\n消费者场景端到端验过(临时目录,无 governance/、Fact 放在 domain/facts/):\n juhai-governance check:fact-pii --root \u003cdir\u003e --dir domain/facts\n → 抓到 buyer_phone、exit 1;报告 rulesSource=bundled、scanDirs=[\"domain/facts\"]\n → 不给 --dir 时明确警告「未找到任何 Fact schema」\n本仓行为不变:21 个 Fact / 116 字段 / 0 违规,rulesSource=repo。测试 8 → 10 例。\n\nREADME 两处同步(判据表 + check 链顺序)——它随包发布,说明必须与实现一致。\n\n**时间差要知道:rc.5 昨天刚发,这些进不了 rc.5。** 包里现在这道门禁的代码要等下一个 RC\n才出得去;在那之前消费者拿到的 @juhai/governance@1.0.0-rc.5 仍不含 fact-pii。\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:54:59-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/3baec4ad9f8c27a94f514af7e4e340c1c763b923...eb275b10c470d5db1907473c40e6c831d1e7a1c6","Len":2}...
|
1789775710
|
Edit
Delete
|
|
31202
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"3baec4ad9 {"Commits":[{"Sha1":"3baec4ad9f8c27a94f514af7e4e340c1c763b923","Message":"docs(部署): §15.4 改写 + 新增 §15.5——ui-acceptance 已真跑回来,D-14 闭环\n\n回绑提交 c4ec6f6:passed,nestjs/ws 5/5(地板 5),绑 67e8193 / worktreeDirty=false;\n67e8193..HEAD 之间作用域零变更,绑定对当前代码仍成立。\n\n同轮补两条环境教训:\n\n1. 隔离栈 enterprise-platform-ms23 那台 PG 的库又被清空了,验收库得重建。与 §9 末尾\n 「不能假定上一轮还在」同一条,这是第二次撞上——可以当常态而不是意外。\n2. §9 的三条前置少写了一条:临时检出只 install + prisma:generate 不够,必须再 pnpm build。\n 缺它时 api-nestjs 的 tsc 以 Cannot find module '@juhai/module-kit' / '@repo/telemetry' 失败,\n 是 workspace 包没构建,不是回归。该次失败停在构建阶段、未写报告,主工作区那份旧报告\n 全程没被覆盖——这正是在独立检出里跑的意义。\n\n§15.4 标题与结尾同步订正:原文写「本轮只登记」,现已不成立。\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:53:58-07:00"},{"Sha1":"c4ec6f6ad12a7b415db4bdd07de48ed64c26bde8","Message":"chore(reports): ui-acceptance 重跑回绑 @ 67e8193\n\nD-14 登记的那份过期报告已真跑回来:passed,nestjs/ws 组合 5/5(地板 5),\nprovenance gitSha=67e8193 / worktreeDirty=false / runner=local。\n67e8193..HEAD 之间作用域(runtime/apps、runtime/packages、modules.json)零变更,\n因此该绑定对当前代码仍然成立。\n\n跑法按 §9 的口径:HEAD 的独立 git worktree 干净检出(主工作区有并行会话 WIP,\n跑在那里必 worktreeDirty=true)+ 隔离栈 enterprise-platform-ms23(PG :55471 /\nRedis :56380 逻辑库 7,本轮重新 docker start 并新建 enterprise_platform_ui_acceptance 库\n——那台 PG 里的库又被清空过一次,与 §9 末尾记的教训一致)。\n\n踩到一条 §9 三条前置之外的:**临时检出只 install + prisma:generate 还不够,必须再\npnpm build**。缺它时 api-nestjs 的 tsc 以 Cannot find module '@juhai/module-kit' /\n'@repo/telemetry' 失败——workspace 包没构建,不是回归。CLAUDE.md「开发命令」节的三步\n本来就写了 build,是我漏了第三步。该次失败发生在构建阶段、未写报告,主工作区那份\n旧报告全程未被覆盖(这正是在独立检出里跑的意义)。\n\n本提交只含这一个报告文件:同时有 18 份 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-18T16:53:21-07:00"}],"HeadCommit":{"Sha1":"3baec4ad9f8c27a94f514af7e4e340c1c763b923","Message":"docs(部署): §15.4 改写 + 新增 §15.5——ui-acceptance 已真跑回来,D-14 闭环\n\n回绑提交 c4ec6f6:passed,nestjs/ws 5/5(地板 5),绑 67e8193 / worktreeDirty=false;\n67e8193..HEAD 之间作用域零变更,绑定对当前代码仍成立。\n\n同轮补两条环境教训:\n\n1. 隔离栈 enterprise-platform-ms23 那台 PG 的库又被清空了,验收库得重建。与 §9 末尾\n 「不能假定上一轮还在」同一条,这是第二次撞上——可以当常态而不是意外。\n2. §9 的三条前置少写了一条:临时检出只 install + prisma:generate 不够,必须再 pnpm build。\n 缺它时 api-nestjs 的 tsc 以 Cannot find module '@juhai/module-kit' / '@repo/telemetry' 失败,\n 是 workspace 包没构建,不是回归。该次失败停在构建阶段、未写报告,主工作区那份旧报告\n 全程没被覆盖——这正是在独立检出里跑的意义。\n\n§15.4 标题与结尾同步订正:原文写「本轮只登记」,现已不成立。\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:53:58-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/e79e5f2b943a633299851dbc7709455247a415ef...3baec4ad9f8c27a94f514af7e4e340c1c763b923","Len":2}...
|
1789775643
|
Edit
Delete
|
|
31201
|
5
|
9
|
5
|
116
|
0
|
0
|
refs/tags/packages-v1.0.0-rc.5
|
0
|
{"Commits":null,"HeadCommit":{" {"Commits":null,"HeadCommit":{"Sha1":"cf05344e117a84fedf092613be5fc13b7a07072b","Message":"chore(release): 三包推到 1.0.0-rc.5——pins 三层判据随包出去,fact-pii 有意留在仓内\n\n动因:check:pins 的三层判据(63ff31f)还不在任何已发布版本里,而 @juhai/governance 的\nrc.0—rc.4 已全部被占用,按 G-12 的边界只能往前发下一个 RC。\n\n**发布物里有什么、没有什么,说清楚免得下一个人误读:** check-pins.mjs 在 governance 包的\nfiles 里,所以三层判据随包出去,消费者仓跑 juhai-governance check:pins 会拿到新判据\n(他们没有 pins-baseline.json,第三方层不启用,行为与 rc.4 一致——这是设计好的向后兼容)。\n而 check-fact-pii.mjs 与 fact-pii-rules.json **有意不进 files**:它扫的是\ncontracts/schemas/facts/ 与 contracts/candidates/facts/,消费者仓根本没有这两个目录,\n发过去是道跑不起来的门禁。它属于本轮源码,但不是本轮发布物的一部分。\n\n自 rc.4 源 557a95c 起的随车内容(比 rc.4 那趟小得多):\n contracts 14 文件 / 6 提交(7 个代码文件,三个域的 fixture-evaluator 与其单测)\n governance 10 文件 / 3 提交(两道新门禁 + 夹具覆盖度算法入文档)\n runtime/clients/fact 1 文件 / 1 提交 —— **只有 package.json,零内容变更,纯跟车**\n\n通道:本地旁路(G-12 第四次使用)。2026-09-18 实测:GitHub Actions 最新 run 35404565689 仍\nfailure(两个 job failure、其余 skipped,计费停摆的典型形态),正道仍不可满足。\n\n**一处新情况:推送死锁已解开。** rc.4 那趟记的是「GitHub 镜像落后 237 条、因分支保护的\nrequired check 跑不起来而推不动」;本次实测镜像落后已降到 24 条,github/main 指向 54e6324,\n说明有人把提交推上去了。但 Actions 仍不启动,所以正道仍差这一半——计费恢复后即可直接走正道,\n不必再先解死锁。\n\n按 CL-5 打 tag packages-v1.0.0-rc.5。\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:45:09-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/0000000000000000000000000000000000000000...cf05344e117a84fedf092613be5fc13b7a07072b","Len":0}...
|
1789775554
|
Edit
Delete
|
|
31200
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"e79e5f2b9 {"Commits":[{"Sha1":"e79e5f2b943a633299851dbc7709455247a415ef","Message":"feat(governance): 覆盖度探针自己查「整支规则没接进评估器」——那是它此前按设计看不见的盲区\n\n上一条(62c9d95)把盲区与绕开它的两步写进了 CLAUDE.md,但那只是文档约束,人不比对就不会发现。\n本次把两项结构比对做进 governance/fixture-coverage.mjs:它们不依赖夹具,因而看得见「从没有用例的那一面」。\n\n1. 未接线列:导入域的 index.js,把导出的判定函数(assess|review|classify|select|decide|plan|preflight|\n evaluate 打头)与 planner 原型方法逐个对评估器源码里的引用,没被引用的报出来。\n2. !!! 行:评估器写成 `\"reasons\" in r ? … : []` 时提醒——该规则结果联合体里一旦出现不带 reasons 的\n 非放行出口(BLOCKED / SKIP_DUPLICATE / DLQ / DUPLICATE_NOOP / USE_LAST_KNOWN_GOOD)就会被静默判成 ACCEPT。\n\n对着 15 个真实套件跑,逮到两类误报,都已修,并写成用例钉住:\n- planner 多数经 createRuntimeX() 工厂到达,类名根本不出现在评估器里。按「类名没出现」判整支未接线会把\n 跨域流程、Webhook、public-file 等全报一遍。改成按「一个方法都没被调」判,并排除 status/get 这类\n 只读访问器与错误类(AiRouteRequestRejected / AuditRequestRejected 不是判定面)。\n- cost-capacity 与 notification-webhook 把旧写法 `\"reasons\" in d ? [...] : []` 抄在注释里当变更记录,\n 按原文匹配会把两个已经改对的域报成缺陷。改成先去注释再匹配。\n措辞也相应收敛:`!!!` 行现在说「今天未必已经出错,但联合体里一旦出现…就会被静默判成 ACCEPT」,\n而不是断言它已经错了——跨域流程那处就属于「今天正确、但脆」。\n\n新增 governance/test/fixture-coverage.test.mjs(3 例):该脚本此前是 governance/ 下唯一没有测试的。\n用临时自足域验三件事——只报没被调的方法、经工厂到达的类不报整支未接线、注释里的旧写法不报。\n\n当前读数(均未处理,已登记进 CLAUDE.md 同段):\n 九个契约包域 未接线 1 处:LocalWorkflowPlanner.refresh()\n 运行时模块侧 未接线 9 处:ai-gateway 2 / permission 3 / audit / credential / fact / scope 各 1\n\n证据:pnpm test(governance)364/364;check-fixtures 17 套件 468 例 0 失败;\n「夹具与单测都没有」仍 0 条;工作区一致性门禁只剩既有的 L9 compose project 撞名。\n脚本仍是诊断而非门禁——不写报告、不进 pnpm check,故本次不涉及 reports 回绑。\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:51:13-07:00"},{"Sha1":"fed1fd024bc60a4feef89dff7c2ec028e0bcb066","Message":"docs(发布): 当场记录 rc.5 列车——三层判据随包出去,fact-pii 有意留在仓内\n\nrc.5 三包 2026-09-18 经本地旁路发出,源 cf05344,tag packages-v1.0.0-rc.5(连续第二趟按 CL-5\n打上)。三包均 registry integrity verified;产物 contracts 183.0 kB / governance 96.9 kB /\nclient-fact 17.4 kB,shasum 记在文档里。\n\n记录里写清了三件容易被误读的事:\n\n1. 发布物里有什么、没有什么。check-pins.mjs 在 governance 包的 files 里,三层判据随包出去,\n 消费者仓拿到新判据后因无 pins-baseline 而第三方层不启用,行为与 rc.4 一致(设计好的向后兼容)。\n check-fact-pii.mjs 与 fact-pii-rules.json **有意不进 files**——它扫 contracts/schemas/facts/,\n 消费者仓没有那个目录,发过去是道跑不起来的门禁。\n2. **CI 死锁解开了一半。** rc.4 那趟记的是双重不可用;本次实测 GitHub 镜像落后已从 237 条降到\n 24 条,推送死锁解开,但 Actions 最新 run 35404565689 仍 failure。计费一恢复即可直接走正道,\n 不必再先解死锁——这是四趟以来第一次出现的松动。\n3. 发布前验证的真实范围:构建 BUILD_EXIT=0、逐包核对产物内容与 provenance;**完整 pnpm check\n 没有在发布前跑**,发布后补跑(真实退出码 1,唯一失败是并行会话的 workbench-ops-snapshot 过期,\n 判据类全绿:pins、fact-pii、测试 361/361)。\n\n发布那一步由 Owner 在自己终端执行:本会话的 auto mode 安全分类器以 [Safety Bypass Flag] 拒绝了带\nPLATFORM_RELEASE_BYPASS_CI_EVIDENCE 的命令。那不算误伤,这个开关就是绕过 CI 证据链的。\n备料与验证由会话完成,最后一步由人按下——这个分工也记进了文档。\n\nCLAUDE.md 的 contracts 条目同步推到 rc.5,并记下 fact-pii 不随包这一条。\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:50:56-07:00"},{"Sha1":"5116dc5951412d8e6f037aafb4fe532fa38207a7","Message":"chore(reports): check:fixtures 回绑 @ 62c9d95 —— 配置开关补的 10 例还没进报告\n\n已提交版绑 748492c、记 458 例;其后 contracts/src/domain/configuration-feature-flags/\nfixture-evaluator.ts 与对应夹具各有一次变更,现测 17 套件 468 例、失败 0、不可用 0。\n按「作用域内有无变更」判定该回绑,非按提交距离。产出绑 62c9d95、worktreeDirty=false\n(生成时主工作区恰好干净,未用临时检出)。\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:49:08-07:00"}],"HeadCommit":{"Sha1":"e79e5f2b943a633299851dbc7709455247a415ef","Message":"feat(governance): 覆盖度探针自己查「整支规则没接进评估器」——那是它此前按设计看不见的盲区\n\n上一条(62c9d95)把盲区与绕开它的两步写进了 CLAUDE.md,但那只是文档约束,人不比对就不会发现。\n本次把两项结构比对做进 governance/fixture-coverage.mjs:它们不依赖夹具,因而看得见「从没有用例的那一面」。\n\n1. 未接线列:导入域的 index.js,把导出的判定函数(assess|review|classify|select|decide|plan|preflight|\n evaluate 打头)与 planner 原型方法逐个对评估器源码里的引用,没被引用的报出来。\n2. !!! 行:评估器写成 `\"reasons\" in r ? … : []` 时提醒——该规则结果联合体里一旦出现不带 reasons 的\n 非放行出口(BLOCKED / SKIP_DUPLICATE / DLQ / DUPLICATE_NOOP / USE_LAST_KNOWN_GOOD)就会被静默判成 ACCEPT。\n\n对着 15 个真实套件跑,逮到两类误报,都已修,并写成用例钉住:\n- planner 多数经 createRuntimeX() 工厂到达,类名根本不出现在评估器里。按「类名没出现」判整支未接线会把\n 跨域流程、Webhook、public-file 等全报一遍。改成按「一个方法都没被调」判,并排除 status/get 这类\n 只读访问器与错误类(AiRouteRequestRejected / AuditRequestRejected 不是判定面)。\n- cost-capacity 与 notification-webhook 把旧写法 `\"reasons\" in d ? [...] : []` 抄在注释里当变更记录,\n 按原文匹配会把两个已经改对的域报成缺陷。改成先去注释再匹配。\n措辞也相应收敛:`!!!` 行现在说「今天未必已经出错,但联合体里一旦出现…就会被静默判成 ACCEPT」,\n而不是断言它已经错了——跨域流程那处就属于「今天正确、但脆」。\n\n新增 governance/test/fixture-coverage.test.mjs(3 例):该脚本此前是 governance/ 下唯一没有测试的。\n用临时自足域验三件事——只报没被调的方法、经工厂到达的类不报整支未接线、注释里的旧写法不报。\n\n当前读数(均未处理,已登记进 CLAUDE.md 同段):\n 九个契约包域 未接线 1 处:LocalWorkflowPlanner.refresh()\n 运行时模块侧 未接线 9 处:ai-gateway 2 / permission 3 / audit / credential / fact / scope 各 1\n\n证据:pnpm test(governance)364/364;check-fixtures 17 套件 468 例 0 失败;\n「夹具与单测都没有」仍 0 条;工作区一致性门禁只剩既有的 L9 compose project 撞名。\n脚本仍是诊断而非门禁——不写报告、不进 pnpm check,故本次不涉及 reports 回绑。\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:51:13-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/62c9d953569c6a146215a0e5511efc292e3f7740...e79e5f2b943a633299851dbc7709455247a415ef","Len":3}...
|
1789775554
|
Edit
Delete
|
|
31199
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"62c9d9535 {"Commits":[{"Sha1":"62c9d953569c6a146215a0e5511efc292e3f7740","Message":"docs(治理): 覆盖度探针读数为 0 不等于该域已收口——把最大的盲区和先做结构比对写进 CLAUDE.md\n\nfixture-coverage.mjs 的局限第一条「只变异夹具已有用例的字段」,实际后果比字面严重:\n整支规则若一条夹具用例都没有,它根本不进统计,读数会一直显示 0/0。只看读数会以为收完了。\n\n2026-09-18 四次命中同一形状,当时四个域的读数都是 0:\n collaboration-messaging plan 分不出 ADMIT 与 SKIP_DUPLICATE\n notification-webhook decideProviderOutcome 没有规则(退避与 Retry-After 钳制全在里面)\n application-contract-registry plan 把 BLOCKED 判成放行,且没有一条用例带合法快照\n configuration-feature-flags configuration-client.ts(167 行,本域最大的一支)整个文件没有规则\n\n补进去的是可操作的两步,不是结论:\n1. 先做结构比对再看读数——把 index.ts 导出的规则函数与 planner 的公开方法(plan / refresh / status /\n 域特有方法)列出来逐个对 *_FIXTURE_RULES,对不上的先补规则、补一条带合法快照的正例。\n2. 连带查评估器判据——写成 `\"reasons\" in r` 这类按字段存在与否判放行的,凡是不带 reasons 的非放行出口\n (BLOCKED / SKIP_DUPLICATE / DLQ / DUPLICATE_NOOP / USE_LAST_KNOWN_GOOD)都会被判成 ACCEPT,\n 一律改成按 kind 判定。\n并写明:补规则后覆盖度会先变差(新面第一次被走到),那是对的,把新暴露的原因码钉完再收工。\n\n顺带把同段的例数从 458 更正为 468(C13 那轮 +10),按实跑 check:fixtures 的输出校对过。\n\n证据:check:fixtures 17 套件 468 例 0 失败 0 不可用;fixture-coverage 15 套件两档仍全 0;\n工作区一致性门禁只剩既有的 L9 compose project 撞名,无新增 L4 / L13。\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:47:21-07:00"}],"HeadCommit":{"Sha1":"62c9d953569c6a146215a0e5511efc292e3f7740","Message":"docs(治理): 覆盖度探针读数为 0 不等于该域已收口——把最大的盲区和先做结构比对写进 CLAUDE.md\n\nfixture-coverage.mjs 的局限第一条「只变异夹具已有用例的字段」,实际后果比字面严重:\n整支规则若一条夹具用例都没有,它根本不进统计,读数会一直显示 0/0。只看读数会以为收完了。\n\n2026-09-18 四次命中同一形状,当时四个域的读数都是 0:\n collaboration-messaging plan 分不出 ADMIT 与 SKIP_DUPLICATE\n notification-webhook decideProviderOutcome 没有规则(退避与 Retry-After 钳制全在里面)\n application-contract-registry plan 把 BLOCKED 判成放行,且没有一条用例带合法快照\n configuration-feature-flags configuration-client.ts(167 行,本域最大的一支)整个文件没有规则\n\n补进去的是可操作的两步,不是结论:\n1. 先做结构比对再看读数——把 index.ts 导出的规则函数与 planner 的公开方法(plan / refresh / status /\n 域特有方法)列出来逐个对 *_FIXTURE_RULES,对不上的先补规则、补一条带合法快照的正例。\n2. 连带查评估器判据——写成 `\"reasons\" in r` 这类按字段存在与否判放行的,凡是不带 reasons 的非放行出口\n (BLOCKED / SKIP_DUPLICATE / DLQ / DUPLICATE_NOOP / USE_LAST_KNOWN_GOOD)都会被判成 ACCEPT,\n 一律改成按 kind 判定。\n并写明:补规则后覆盖度会先变差(新面第一次被走到),那是对的,把新暴露的原因码钉完再收工。\n\n顺带把同段的例数从 458 更正为 468(C13 那轮 +10),按实跑 check:fixtures 的输出校对过。\n\n证据:check:fixtures 17 套件 468 例 0 失败 0 不可用;fixture-coverage 15 套件两档仍全 0;\n工作区一致性门禁只剩既有的 L9 compose project 撞名,无新增 L4 / L13。\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:47:21-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/cf05344e117a84fedf092613be5fc13b7a07072b...62c9d953569c6a146215a0e5511efc292e3f7740","Len":1}...
|
1789775276
|
Edit
Delete
|
|
31198
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"cf05344e1 {"Commits":[{"Sha1":"cf05344e117a84fedf092613be5fc13b7a07072b","Message":"chore(release): 三包推到 1.0.0-rc.5——pins 三层判据随包出去,fact-pii 有意留在仓内\n\n动因:check:pins 的三层判据(63ff31f)还不在任何已发布版本里,而 @juhai/governance 的\nrc.0—rc.4 已全部被占用,按 G-12 的边界只能往前发下一个 RC。\n\n**发布物里有什么、没有什么,说清楚免得下一个人误读:** check-pins.mjs 在 governance 包的\nfiles 里,所以三层判据随包出去,消费者仓跑 juhai-governance check:pins 会拿到新判据\n(他们没有 pins-baseline.json,第三方层不启用,行为与 rc.4 一致——这是设计好的向后兼容)。\n而 check-fact-pii.mjs 与 fact-pii-rules.json **有意不进 files**:它扫的是\ncontracts/schemas/facts/ 与 contracts/candidates/facts/,消费者仓根本没有这两个目录,\n发过去是道跑不起来的门禁。它属于本轮源码,但不是本轮发布物的一部分。\n\n自 rc.4 源 557a95c 起的随车内容(比 rc.4 那趟小得多):\n contracts 14 文件 / 6 提交(7 个代码文件,三个域的 fixture-evaluator 与其单测)\n governance 10 文件 / 3 提交(两道新门禁 + 夹具覆盖度算法入文档)\n runtime/clients/fact 1 文件 / 1 提交 —— **只有 package.json,零内容变更,纯跟车**\n\n通道:本地旁路(G-12 第四次使用)。2026-09-18 实测:GitHub Actions 最新 run 35404565689 仍\nfailure(两个 job failure、其余 skipped,计费停摆的典型形态),正道仍不可满足。\n\n**一处新情况:推送死锁已解开。** rc.4 那趟记的是「GitHub 镜像落后 237 条、因分支保护的\nrequired check 跑不起来而推不动」;本次实测镜像落后已降到 24 条,github/main 指向 54e6324,\n说明有人把提交推上去了。但 Actions 仍不启动,所以正道仍差这一半——计费恢复后即可直接走正道,\n不必再先解死锁。\n\n按 CL-5 打 tag packages-v1.0.0-rc.5。\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:45:09-07:00"},{"Sha1":"ff80f7e1b91b7fb012f0488736bce79b33db3ad5","Message":"docs(记录): 一个会话的契约包入参硬化与证据收口——重点是四次自我更正\n\n把散在提交信息与开发计划登记行里的结论汇到一处。写的是单个会话的范围,不代为总结\n同日并行会话在九个域做的同类工作;凡带数字的当前状态一律标注为落盘时点快照。\n\n四次更正里三次是判断错了、一次是方法缺了一步:\n\n1. 注册中心那套被放弃是对的,且不是风格之争。我当时报的「远端那版大部分相当,唯一\n 差异是原因码命名」是靠读代码比对得出的,后被 7523bd0 的双向交叉实测推翻——被放弃\n 那套有 4 个实缺陷,其中一条是它自己的注释抱怨「同一摘要两种写法等于两个身份」,\n 却只在入口拒大写、升级比较那条路上没修完。整个会话的方法论是先实测再下结论,\n 对自己的产物我没照做。\n2. module-imports 那次回绑是多余的,已撤回未提交。判据应为「这份报告现在是否被判\n 过期」,而不是「作用域是否干净」。\n3. 独立索引提交后必须 git reset 刷回共享索引,否则并行会话下次从索引提交会把已提交\n 改动带回去——本会话实际发生过一次。\n4. 上述回退事件一度被我误判为对方回退,实为 --amend 改写 SHA 叠加 BSD grep 的 \\| 不是\n 或运算符导致核实命令恒返回 0。核实要用 grep -E,且以内容为准不以 SHA 为准。\n\n另记回绑需构建产物门禁的两条实操约束:检出必须落在工作区内(workspaceRelative 套件\n要向上找 workspace.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:44:30-07:00"},{"Sha1":"bf834ce6bcb9551474ff6a18abaa832f2302739f","Message":"test(contracts): 配置与开关最大的一支规则不在门禁上——refresh 的六条原因码一条没钉,含明文密钥那条\n\n覆盖度探针对本套件的读数是「都没有 0 / 仅单测 0」,看上去已收口。但它按自述只变异夹具已有用例的\n字段,而 configuration-client.ts(167 行,LocalConfigurationClient 的 create / status / get / refresh)\n一条夹具用例都没有——整支规则从来不在它的统计口径里。两个规则文件零改动,只动夹具评估器。\n\n1. refresh() 的六条原因码一条都没钉:SNAPSHOT_FORMAT_INVALID、SNAPSHOT_VERSION_NOT_FORWARD、\n SNAPSHOT_NOT_APPROVED、SNAPSHOT_SCHEMA_INVALID、PLAINTEXT_SECRET_FORBIDDEN、SNAPSHOT_VERSION_STALE。\n 其中 PLAINTEXT_SECRET_FORBIDDEN 有两条到达路径——候选显式标注,以及键名命中密钥模式\n (normalizeSnapshot 把两者 OR 起来,apiToken 这样的键足以触发)——都在门禁之外。\n 新增 client 规则:按 active 建客户端再喂候选热更,APPLIED 为放行,否则返回 KEPT_LAST_KNOWN_GOOD\n 给出的 reasons;create 在两份快照都不可用时会抛,评估器收敛成 CONFIGURATION_UNAVAILABLE: 原因码,\n 而不是让整套夹具塌成 configurationError。\n\n2. snapshot 把 USE_LAST_KNOWN_GOOD 判成放行:候选被拒退回上一版与候选被采纳在夹具里是同一个结果,\n 实测「候选未批准」「候选含明文密钥」两种退回都判 ACCEPT。这一条改的是既有的、有意为之的口径\n (原评估器抬头写着「只有 USE_CANDIDATE / USE_LAST_KNOWN_GOOD 算放行」),理由是与同仓兄弟域对齐——\n 通知与 Webhook 的评估器写着「DUPLICATE / RETRY / DLQ / REJECT_REPLAY 都如实返回,因为它们在消费侧的\n 后果都不是『这次投递成功了』」。退回上一版同样不是「这次配置更新成功了」。\n 原 P04-falls-back-to-last-known-good 随之改名 N15-(门禁强制 id 前缀与 expect 一致)。\n\n一处明写不覆盖:refresh() 的 SNAPSHOT_VERSION_STALE 按构造不可达——active 建客户端时已过版本下限、\n候选又必须比 active 前进,合起来候选不可能低于下限;configuration-client.ts 抬头自己写明那是防御性\n补的一笔。N24 改钉「两份快照都不可用时 create 抛 CONFIGURATION_UNAVAILABLE:」这条真实出口。\n\n覆盖:夹具 18 → 28 例(正 4 / 反 24),定向测试 21 → 25 例,前一轮断言一条未改;\nfixture-coverage 稳定码 8 → 11,两档仍 0 / 0。变异探针(28 例 × 14 种脏值)4200 个变异点、0 处抛异常。\n\n未做(越界):分桶、发布状态机、kill switch 仍不在本仓,C13 按缺失模块完善清单仍是「裁决」;\nCatalog 登记未动(仍 module_e2、code_truth 指向工单仓 packages/configuration-client)。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 408/408、该套件夹具 28/28 失败 0。\n负向实测:把 N23(密钥键名那条)的声明改成 SNAPSHOT_NOT_APPROVED → 门禁 exit 1 并点名该例,还原后 exit 0。\n本次不回绑任何 reports/。\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:44:11-07:00"}],"HeadCommit":{"Sha1":"cf05344e117a84fedf092613be5fc13b7a07072b","Message":"chore(release): 三包推到 1.0.0-rc.5——pins 三层判据随包出去,fact-pii 有意留在仓内\n\n动因:check:pins 的三层判据(63ff31f)还不在任何已发布版本里,而 @juhai/governance 的\nrc.0—rc.4 已全部被占用,按 G-12 的边界只能往前发下一个 RC。\n\n**发布物里有什么、没有什么,说清楚免得下一个人误读:** check-pins.mjs 在 governance 包的\nfiles 里,所以三层判据随包出去,消费者仓跑 juhai-governance check:pins 会拿到新判据\n(他们没有 pins-baseline.json,第三方层不启用,行为与 rc.4 一致——这是设计好的向后兼容)。\n而 check-fact-pii.mjs 与 fact-pii-rules.json **有意不进 files**:它扫的是\ncontracts/schemas/facts/ 与 contracts/candidates/facts/,消费者仓根本没有这两个目录,\n发过去是道跑不起来的门禁。它属于本轮源码,但不是本轮发布物的一部分。\n\n自 rc.4 源 557a95c 起的随车内容(比 rc.4 那趟小得多):\n contracts 14 文件 / 6 提交(7 个代码文件,三个域的 fixture-evaluator 与其单测)\n governance 10 文件 / 3 提交(两道新门禁 + 夹具覆盖度算法入文档)\n runtime/clients/fact 1 文件 / 1 提交 —— **只有 package.json,零内容变更,纯跟车**\n\n通道:本地旁路(G-12 第四次使用)。2026-09-18 实测:GitHub Actions 最新 run 35404565689 仍\nfailure(两个 job failure、其余 skipped,计费停摆的典型形态),正道仍不可满足。\n\n**一处新情况:推送死锁已解开。** rc.4 那趟记的是「GitHub 镜像落后 237 条、因分支保护的\nrequired check 跑不起来而推不动」;本次实测镜像落后已降到 24 条,github/main 指向 54e6324,\n说明有人把提交推上去了。但 Actions 仍不启动,所以正道仍差这一半——计费恢复后即可直接走正道,\n不必再先解死锁。\n\n按 CL-5 打 tag packages-v1.0.0-rc.5。\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:45:09-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/67e81931c6da187ea61adff37ad74a4d9b672e8e...cf05344e117a84fedf092613be5fc13b7a07072b","Len":3}...
|
1789775181
|
Edit
Delete
|
|
31197
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"67e81931c {"Commits":[{"Sha1":"67e81931c6da187ea61adff37ad74a4d9b672e8e","Message":"docs(部署): 记录补 §15——D-12 修掉(实为两处),以及重建产物撞出的两个部署坑\n\n实现提交 59265a6。本节记三件事:\n\n一、D-12 登记的是顶栏,实际是两处同病,第二处(登录页的 typeof window 分支)每次打开都在报、\n与有没有会话无关。它还改写了一条既有结论:同源托管记录 §4.3 记的那个「缺配置」就是产物原文,\n客户端随后整片换掉了——当时看到的渲染没错,但那是水合失败后重渲染的结果,不是水合成功。\n定位用对照实验(清空会话重载不报、植入会话即报),不是读代码猜。\n\n二、重建静态产物撞出两个坑,都会让人误判成「发好了」:\n① next build 把 .env.local 烤进产物——第一次重建后 out/ 里出现 localhost:3098 与工作台\n clientId,而这份产物是给网关同源托管的,API 基地址本该为空。在有 .env.local 的开发机上\n 直接 build,等于把 dev 配置发到网关。\n② next build 删目录再造 out/,inode 变了,caddy 的绑定挂载失效、/srv/workbench 变空,\n 而网关照样回 200——发的是 25 字节占位响应。「200 且有内容」不等于「发的是你刚建的产物」。\n force-recreate 后恢复。时序上坑 ① 那份产物从未真正对外发过,因为坑 ② 同刻已让挂载失效。\n\n三、ui-acceptance 因改动落在 runtime/apps 按作用域过期,Owner 定:先提交、过期登记在案、\n重跑排到下一轮(D-14,与 D-13 同批)。在那之前该报告不覆盖本次工作台改动。\n\n同轮把已修的 D-12 从 §14.5 未闭环表摘出并指向 §15。\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:41:54-07:00"}],"HeadCommit":{"Sha1":"67e81931c6da187ea61adff37ad74a4d9b672e8e","Message":"docs(部署): 记录补 §15——D-12 修掉(实为两处),以及重建产物撞出的两个部署坑\n\n实现提交 59265a6。本节记三件事:\n\n一、D-12 登记的是顶栏,实际是两处同病,第二处(登录页的 typeof window 分支)每次打开都在报、\n与有没有会话无关。它还改写了一条既有结论:同源托管记录 §4.3 记的那个「缺配置」就是产物原文,\n客户端随后整片换掉了——当时看到的渲染没错,但那是水合失败后重渲染的结果,不是水合成功。\n定位用对照实验(清空会话重载不报、植入会话即报),不是读代码猜。\n\n二、重建静态产物撞出两个坑,都会让人误判成「发好了」:\n① next build 把 .env.local 烤进产物——第一次重建后 out/ 里出现 localhost:3098 与工作台\n clientId,而这份产物是给网关同源托管的,API 基地址本该为空。在有 .env.local 的开发机上\n 直接 build,等于把 dev 配置发到网关。\n② next build 删目录再造 out/,inode 变了,caddy 的绑定挂载失效、/srv/workbench 变空,\n 而网关照样回 200——发的是 25 字节占位响应。「200 且有内容」不等于「发的是你刚建的产物」。\n force-recreate 后恢复。时序上坑 ① 那份产物从未真正对外发过,因为坑 ② 同刻已让挂载失效。\n\n三、ui-acceptance 因改动落在 runtime/apps 按作用域过期,Owner 定:先提交、过期登记在案、\n重跑排到下一轮(D-14,与 D-13 同批)。在那之前该报告不覆盖本次工作台改动。\n\n同轮把已修的 D-12 从 §14.5 未闭环表摘出并指向 §15。\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:41:54-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/ac4f5b8ef04795013b51bcb9bb6d4c353e091311...67e81931c6da187ea61adff37ad74a4d9b672e8e","Len":1}...
|
1789774924
|
Edit
Delete
|
|
31196
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ac4f5b8ef {"Commits":[{"Sha1":"ac4f5b8ef04795013b51bcb9bb6d4c353e091311","Message":"chore(reports): check:module-imports 回绑 @ 59265a6\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑,绑 59265a6 /\nworktreeDirty=false,扫描 397 个源文件、0 处违规。\n\n上一次绑 557a95c,之后作用域内有两批改动:63ff31f 把 clients 三包的 devDeps pin 到 exact,\n59265a6 给 workbench 加了客户端状态 hook。397 = 上次的 396 + 新增的\nruntime/apps/workbench/src/lib/use-mounted.ts,数字对得上。\n\n这份报告此前卡了一轮:它的证据作用域含 runtime/apps,而并行会话正在改 workbench,\nrebind 按判据拒绝回绑(作用域内有未提交输入)。等其提交后抢的窗口。\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:41:33-07:00"}],"HeadCommit":{"Sha1":"ac4f5b8ef04795013b51bcb9bb6d4c353e091311","Message":"chore(reports): check:module-imports 回绑 @ 59265a6\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑,绑 59265a6 /\nworktreeDirty=false,扫描 397 个源文件、0 处违规。\n\n上一次绑 557a95c,之后作用域内有两批改动:63ff31f 把 clients 三包的 devDeps pin 到 exact,\n59265a6 给 workbench 加了客户端状态 hook。397 = 上次的 396 + 新增的\nruntime/apps/workbench/src/lib/use-mounted.ts,数字对得上。\n\n这份报告此前卡了一轮:它的证据作用域含 runtime/apps,而并行会话正在改 workbench,\nrebind 按判据拒绝回绑(作用域内有未提交输入)。等其提交后抢的窗口。\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:41:33-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/59265a6ffc4d0d4ffda878fd880a5d5a308720bb...ac4f5b8ef04795013b51bcb9bb6d4c353e091311","Len":1}...
|
1789774905
|
Edit
Delete
|
|
31195
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"b0c8f85aa {"Commits":[{"Sha1":"b0c8f85aaf3e0d5d8581c460a2bebbe2c14e9a85","Message":"docs(治理): 总架构 §1 表前五项复核改记 2026-09-18,图 1 / 图 2 图注同步对齐\n\n按原复算方式对活契约与 runtime/modules.json 重读平台项目 21 / 裁决 39 / 事实 11 /\n实体 168 / 运行时模块 7 五项,取值与 09-17 完全一致,故观测时刻改记 2026-09-18,\n并在 §1 表下补一段复核记:复核是工作区内只读直读,未产出登记报告,证据只绑定本地\n工作区。两张图(图 1 五层与依赖方向、图 2 现存跨应用关系)的图注观测时刻一并改到\n09-18,与表对齐;§0 增补段补一句指向这次改记。\n\n未重跑的五项——派生仓分档、框架版本 L11 / L12、docker ps、文档口径一致性——\n保持 2026-09-17 不动。本轮复跑 check-workspace-consistency.mjs 仍只有 L9 一条\n(COMPOSE_PROJECT_COLLISION,7 个仓共用 api-nestjs project 名),与文中写法一致。\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:34:29-07:00"}],"HeadCommit":{"Sha1":"b0c8f85aaf3e0d5d8581c460a2bebbe2c14e9a85","Message":"docs(治理): 总架构 §1 表前五项复核改记 2026-09-18,图 1 / 图 2 图注同步对齐\n\n按原复算方式对活契约与 runtime/modules.json 重读平台项目 21 / 裁决 39 / 事实 11 /\n实体 168 / 运行时模块 7 五项,取值与 09-17 完全一致,故观测时刻改记 2026-09-18,\n并在 §1 表下补一段复核记:复核是工作区内只读直读,未产出登记报告,证据只绑定本地\n工作区。两张图(图 1 五层与依赖方向、图 2 现存跨应用关系)的图注观测时刻一并改到\n09-18,与表对齐;§0 增补段补一句指向这次改记。\n\n未重跑的五项——派生仓分档、框架版本 L11 / L12、docker ps、文档口径一致性——\n保持 2026-09-17 不动。本轮复跑 check-workspace-consistency.mjs 仍只有 L9 一条\n(COMPOSE_PROJECT_COLLISION,7 个仓共用 api-nestjs project 名),与文中写法一致。\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:34:29-07:00"},"CompareURL":"luoanwu/platform-governance/compare/8e5cc87f027dab462c6f3f5bf8f0e42894778016...b0c8f85aaf3e0d5d8581c460a2bebbe2c14e9a85","Len":1}...
|
1789774905
|
Edit
Delete
|
|
31194
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"59265a6ff {"Commits":[{"Sha1":"59265a6ffc4d0d4ffda878fd880a5d5a308720bb","Message":"fix(workbench): 客户端独有的状态不得进首帧——修掉两处水合不一致(D-12)\n\nD-12 登记的是顶栏那一处,查下来是两处同病,其中一处每次打开登录页都在报:\n\n- `app-nav.tsx` 直接渲染会话里的 subject。工作台是 output: \"export\",HTML 在构建期定死,\n 里面不可能有会话,而首帧客户端已经有了。只在 sessionStorage 有令牌时触发。\n- `login/page.tsx` 的 `typeof window === \"undefined\" ? null : readOidcConfig(...)`:服务端恒为\n null(渲染「缺配置」),浏览器算得出配置(渲染登录按钮),**必然**对不上,与有没有会话无关。\n 同源托管记录 §4.3 记的那个「缺配置」就是产物原文,客户端随后整片换掉了。\n\n定位用的是对照实验而不是读代码猜:清空 sessionStorage 重载 / 不报错,植入会话再重载即报;\n重载 /login/ 在无会话时也报。\n\n修法统一为新增的 useMounted():客户端独有的状态(sessionStorage 会话、window.location)\n等挂载之后再渲染,首帧与构建期产物逐字一致。没有复用 store 的 hydrated 标志——那面旗由\nProviders 的 effect 翻,时序上依赖别的组件;组件自己的 useState(false) 在水合那一帧恒为 false。\n\n登录页因此多出第三种状态「读取中」。这与本仓一贯口径一致:配置还没读到时,既不能说\n「缺配置」也不能说「可登录」。\n\n验证:workbench typecheck / lint 通过;next build 六路由导出;重载 /login/ 与植入会话硬跳转 /\n均不再新增 hydration 报错。\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:41:05-07:00"}],"HeadCommit":{"Sha1":"59265a6ffc4d0d4ffda878fd880a5d5a308720bb","Message":"fix(workbench): 客户端独有的状态不得进首帧——修掉两处水合不一致(D-12)\n\nD-12 登记的是顶栏那一处,查下来是两处同病,其中一处每次打开登录页都在报:\n\n- `app-nav.tsx` 直接渲染会话里的 subject。工作台是 output: \"export\",HTML 在构建期定死,\n 里面不可能有会话,而首帧客户端已经有了。只在 sessionStorage 有令牌时触发。\n- `login/page.tsx` 的 `typeof window === \"undefined\" ? null : readOidcConfig(...)`:服务端恒为\n null(渲染「缺配置」),浏览器算得出配置(渲染登录按钮),**必然**对不上,与有没有会话无关。\n 同源托管记录 §4.3 记的那个「缺配置」就是产物原文,客户端随后整片换掉了。\n\n定位用的是对照实验而不是读代码猜:清空 sessionStorage 重载 / 不报错,植入会话再重载即报;\n重载 /login/ 在无会话时也报。\n\n修法统一为新增的 useMounted():客户端独有的状态(sessionStorage 会话、window.location)\n等挂载之后再渲染,首帧与构建期产物逐字一致。没有复用 store 的 hydrated 标志——那面旗由\nProviders 的 effect 翻,时序上依赖别的组件;组件自己的 useState(false) 在水合那一帧恒为 false。\n\n登录页因此多出第三种状态「读取中」。这与本仓一贯口径一致:配置还没读到时,既不能说\n「缺配置」也不能说「可登录」。\n\n验证:workbench typecheck / lint 通过;next build 六路由导出;重载 /login/ 与植入会话硬跳转 /\n均不再新增 hydration 报错。\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:41:05-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/63ff31f256e45886e0a52d5e819ef7b3730eba9b...59265a6ffc4d0d4ffda878fd880a5d5a308720bb","Len":1}...
|
1789774882
|
Edit
Delete
|
|
31193
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"63ff31f25 {"Commits":[{"Sha1":"63ff31f256e45886e0a52d5e819ef7b3730eba9b","Message":"feat(治理): check:pins 扩到第三方依赖——发布包严格,应用侧走存量基线\n\n此前 check:pins 只管 @juhai/*,第三方 pin 完全不看。量了一下:256 个第三方依赖声明里\n218 个(85%)是 range。直接全判红等于让门禁第一天就红 218 处;全量 pin 则要改 218 处并\n重建 runtime / identity 两个 lockfile、触碰整棵依赖树——而 lockfile + --frozen-lockfile\n已经保证了日常构建可复现,range 的真实风险只是有人跑 pnpm update 时意外升级。\n目录负责人裁决:分层。\n\n三层判据:\n\n 1. @juhai/* 一律 exact / workspace:*(原有)\n 2. 对外发布包 第三方依赖也一律 exact。判定依据是 publishConfig 的存在——它是「这个包会被\n 发出去」的机器特征,比硬编码包目录好:新增发布包自动纳入,不必记得回来改门禁。\n 消费者装到的是发布时解析的那棵树,range 在他们那边会解析成别的版本。\n 3. 其余(应用) 存量 209 处登记在 governance/pins-baseline.json,登记外的新增必须 exact。\n 基线**只减不增**:登记项对应的依赖删了条目也要删,否则 BASELINE_STALE 判红。\n\n配套把 clients 三包的 9 处 devDeps pin 掉(@types/node 22.19.20 / typescript 5.9.3 /\nvitest 2.1.9,取自 lockfile 已解析的版本)。lockfile 只动了 9 行 specifier,\n**resolution 变更 0 行**,依赖树没变;pnpm install --frozen-lockfile 复验通过。\n\n**一处会炸下游的设计,改掉了:** 初版把「无基线」当空基线 fail closed。但 @juhai/governance\n是发布给消费者仓(HR / OS)的 CLI,他们跑 juhai-governance check:pins --require @juhai/contracts\n时仓里没有本仓基线,按空基线判会把他们全部第三方 range 判红——一次判据扩展直接炸掉所有下游。\n改为:无基线则第三方层不启用,且**在输出里明说**(不静默关闭)。测试钉住了这条契约。\n\n本机实测:本仓 37 处 @juhai/* + 第三方 256 处(47 exact,含发布包 17 处严格;209 处在基线内)\nexit 0;模拟消费者仓(无基线)exit 0 且第三方层未启用;四种违规场景(发布包 range、\n基线外新增、基线腐烂、无基线)行为逐一验过,退出码直取、不经管道。测试 10 → 17 例。\n\ngovernance/README.md 同步(它随包发布,判据表必须与实现一致);CLAUDE.md 纪律 4 同步。\npins-baseline.json 不进 governance 包的 files——它是本仓的存量账,对消费者无意义。\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:37:14-07:00"},{"Sha1":"8939e8fc35a7c42d4957e2297c8dcb8eb58cb663","Message":"chore(reports): check:fixtures 回绑 @ 748492c —— 补上本会话四轮夹具增量欠的那一笔\n\nreports/fixtures.latest.json 此前绑在 7523bd0(17 套件 316 例),check:evidence 报 EVIDENCE_STALE:\n作用域内 14 个文件已变更。变更的大头是本会话四条加夹具的提交——1a1b37e(IM)、bdb662d(数据分析)、\n7a4b693(成本容量)、0b3dab6(Webhook)、4f36e22(注册中心)、4df190d(最后 9 条仅单测)。\n每轮提交信息里都写了「本次不回绑」,当时理由成立(工作树有并行会话 WIP,拿不到 worktreeDirty=false),\n但后续没人补,就成了欠账。\n\n回绑做法:在 企业控制面/.worktrees/rebind-fixtures 开 detached 干净检出(HEAD 748492c),\n把主检出的 node_modules 软链进去(软链不被 .gitignore 的 node_modules/ 目录规则匹配,故写进\n本地 info/exclude,不改仓内 .gitignore),build contracts 与七模块后跑 check:fixtures,\n确认 git status 为空再出报告,最后只把这一份 report 拷回主检出、按 pathspec 单独提交——\n主检出里并行会话另有 11 份报告在改,一份都没碰。\n\n结果:provenance gitSha=748492c、worktreeDirty=false,17 套件 458 例 0 失败 0 不可用\n(此前 316 例,+142 例即本会话四轮的夹具增量)。\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:33:25-07:00"}],"HeadCommit":{"Sha1":"63ff31f256e45886e0a52d5e819ef7b3730eba9b","Message":"feat(治理): check:pins 扩到第三方依赖——发布包严格,应用侧走存量基线\n\n此前 check:pins 只管 @juhai/*,第三方 pin 完全不看。量了一下:256 个第三方依赖声明里\n218 个(85%)是 range。直接全判红等于让门禁第一天就红 218 处;全量 pin 则要改 218 处并\n重建 runtime / identity 两个 lockfile、触碰整棵依赖树——而 lockfile + --frozen-lockfile\n已经保证了日常构建可复现,range 的真实风险只是有人跑 pnpm update 时意外升级。\n目录负责人裁决:分层。\n\n三层判据:\n\n 1. @juhai/* 一律 exact / workspace:*(原有)\n 2. 对外发布包 第三方依赖也一律 exact。判定依据是 publishConfig 的存在——它是「这个包会被\n 发出去」的机器特征,比硬编码包目录好:新增发布包自动纳入,不必记得回来改门禁。\n 消费者装到的是发布时解析的那棵树,range 在他们那边会解析成别的版本。\n 3. 其余(应用) 存量 209 处登记在 governance/pins-baseline.json,登记外的新增必须 exact。\n 基线**只减不增**:登记项对应的依赖删了条目也要删,否则 BASELINE_STALE 判红。\n\n配套把 clients 三包的 9 处 devDeps pin 掉(@types/node 22.19.20 / typescript 5.9.3 /\nvitest 2.1.9,取自 lockfile 已解析的版本)。lockfile 只动了 9 行 specifier,\n**resolution 变更 0 行**,依赖树没变;pnpm install --frozen-lockfile 复验通过。\n\n**一处会炸下游的设计,改掉了:** 初版把「无基线」当空基线 fail closed。但 @juhai/governance\n是发布给消费者仓(HR / OS)的 CLI,他们跑 juhai-governance check:pins --require @juhai/contracts\n时仓里没有本仓基线,按空基线判会把他们全部第三方 range 判红——一次判据扩展直接炸掉所有下游。\n改为:无基线则第三方层不启用,且**在输出里明说**(不静默关闭)。测试钉住了这条契约。\n\n本机实测:本仓 37 处 @juhai/* + 第三方 256 处(47 exact,含发布包 17 处严格;209 处在基线内)\nexit 0;模拟消费者仓(无基线)exit 0 且第三方层未启用;四种违规场景(发布包 range、\n基线外新增、基线腐烂、无基线)行为逐一验过,退出码直取、不经管道。测试 10 → 17 例。\n\ngovernance/README.md 同步(它随包发布,判据表必须与实现一致);CLAUDE.md 纪律 4 同步。\npins-baseline.json 不进 governance 包的 files——它是本仓的存量账,对消费者无意义。\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:37:14-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/748492c2a1013dbf03b6234f2a85dea73af7e9e6...63ff31f256e45886e0a52d5e819ef7b3730eba9b","Len":2}...
|
1789774676
|
Edit
Delete
|
|
31192
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"2ef8d2fea {"Commits":[{"Sha1":"2ef8d2fea20dcc03a7397ed3fc71312b675a70d9","Message":"chore(reports): realtime 依赖登记的二十八份静态证据 回绑 @ 5f38077,刷新快照锚点\n\n本批次最后一个提交,按 C241 同时刷新快照锚点到 5f38077(声明落后 0,本提交自身使实测\n落后 1,在 +1 自指窗内)。\n\n二十八份 reports/*.latest.json 全部 clean 绑定(gitSha=5f38077、worktreeDirty:false)。\n静态整轮 28/28(退出码 0)。\n\n未跑运行态:本批只动立项文档,未改任何运行代码,runtime 证据仍绑 fc147d3\n(735 / 204-204 / 零违规)且未失效。\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:35:01-07:00"},{"Sha1":"5f38077645e9e39fc5b2b1a44387d3aeb72b1b5f","Message":"docs(planning): 登记 realtime 双向分歧与 RequestContext 贯通这个共同前置\n\n接 realtime 时发现它不该现在做,原因值得单独记:\n\n**realtime 是双向分歧,不是本仓落后。** makeEnvelope 两边各自演进过——\n 本仓:resourceRefs 支持(resourceRefsFromData + 去重),与 subscription 同一条扩展协议\n 框架:options.context → envelope.context { requestId, traceId }(0.6.0 上下文贯通)\n另有 realtimeChannelForDatabase(按 Redis 逻辑库分区频道,13 个消费者,正是此前 runtime\n长期假红的根因所在)是本仓独有。整份转发会丢掉本仓那半,故按迁移手册 §6 走分歧账本。\n\n**更要紧的是它暴露了一个共同前置。** 框架那一半依赖 RequestContext 从 HTTP 层贯通,\n而这正是 B2c-1 明确推迟的 ALS 工作。两个挂起批次因此指向同一件没做的事:\n\n B2c-2 平台端口接线 —— decide() 入参是 RequestContext。服务层拿不到 HTTP 头,\n 只能合成 requestId:对权限判定无妨(端口只用 tenantId + actorId + action),\n 但**审计关联失效**。这就是 B2c-2 只接权限端口、不接审计端口的原因。\n B3″ realtime —— envelope.context 取自 propagatedContextOf(RequestContext)。\n 没有真实上下文,这个字段要么缺席、要么填合成值——**后者比缺席更糟**,\n 它让「信封可追溯」成为假象。\n\n本仓**已有 AsyncLocalStorage**(两后端各一份 rls-context.ts 用于 RLS 租户绑定),\n不是从零起;缺的是把 buildRequestContext 的产物在请求入口塞进 ALS 并让下游取用。\n框架 0.4.0 / 0.6.0 的两后端接线可直接对照。\n\n登记它而不是顺手做:贯通请求上下文会改变两后端的请求入口与队列载荷(0.6.0 的\noutboxContext 把 context 带进 outbox 行),属跨切面改动,应当独立批次并配完整 runtime\n验证,不该作为别的批次的副产品。\n\n本批只动文档,静态 28/28,未改运行代码。\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:33:37-07:00"}],"HeadCommit":{"Sha1":"2ef8d2fea20dcc03a7397ed3fc71312b675a70d9","Message":"chore(reports): realtime 依赖登记的二十八份静态证据 回绑 @ 5f38077,刷新快照锚点\n\n本批次最后一个提交,按 C241 同时刷新快照锚点到 5f38077(声明落后 0,本提交自身使实测\n落后 1,在 +1 自指窗内)。\n\n二十八份 reports/*.latest.json 全部 clean 绑定(gitSha=5f38077、worktreeDirty:false)。\n静态整轮 28/28(退出码 0)。\n\n未跑运行态:本批只动立项文档,未改任何运行代码,runtime 证据仍绑 fc147d3\n(735 / 204-204 / 零违规)且未失效。\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:35:01-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/001e16da960e9c44fcb2f943d149bb374c710e33...2ef8d2fea20dcc03a7397ed3fc71312b675a70d9","Len":2}...
|
1789774505
|
Edit
Delete
|
|
31191
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"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}...
|
1789774292
|
Edit
Delete
|
|
31190
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"748492c2a {"Commits":[{"Sha1":"748492c2a1013dbf03b6234f2a85dea73af7e9e6","Message":"chore(reports): fact-pii / gate-flow / ci-mirror 三份回绑 @ bb26784\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑,三份均绑 bb26784 /\nworktreeDirty=false:\n\n fact-pii 21 个 Fact / 116 个字段,0 处 PII 形状与开放结构,25 个自由文本登账待裁\n gate-flow 47 个脚本、35 个有消费入口(新门禁已被推导为在链上),12 个流外且已具名\n ci-mirror 规范化 462 行逐行相同(两份工作流同步加了 check:fact-pii)\n\n后两份的作用域含本轮改动的 package.json 与两份 workflow,故一并回绑。\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:28:00-07:00"},{"Sha1":"bb26784b4f44517b57389d78fbfacac5915a0317","Message":"feat(治理): 补上 check:fact-pii——仓纪律 4 的三件事里,Fact payload 禁 PII 此前无人守\n\n纪律 4 把三件事并列:禁 ^/~(check:pins 守)、禁跨模块 import(check:module-imports 守)、\nFact payload 禁止复制 PII(**没有任何机器在守**)。check:facts 只校验「声明的 Fact 类型是否\n登记」,从不看 payload 里装什么——往某个 Fact schema 加一个 user_email 字段,全链门禁一片绿。\nFact 是跨域流转的事件:个人信息应当留在权威域里按权限查,不随事件复制到每个消费者的\nInbox 与审计链上。\n\n两条判红:\n\n PII_SHAPED_KEY 字段名命中 PII 模式且未显式豁免。按 (^|_)pattern($|_) 的词边界匹配——\n 裸子串会让 principal_id(princ-ip-al)、storage_kind(stor-age)误报,\n 门禁第一天就会被当成坏了而绕过。测试钉住了这一条。\n UNBOUNDED_PAYLOAD 对象缺 properties 或未禁 additionalProperties。这条不是锦上添花:\n 开放结构能装任意键,键名规则对它完全无效,不堵住它前一条只是君子协定。\n\n一条**不判红**:unconstrainedText——无 enum/pattern/format 约束的字符串字段(现有 25 个,\nbuyer_snapshot 这种名字含糊、maxLength 200 的自由文本最典型)。它们确实是 PII 的入口,\n但「这个字段实际装什么」是业务语义。这 25 个字段**全部没有 description**,我写不出可靠的\n豁免理由,编造 25 条登记只会污染治理真源。如实登账进报告,留给人裁定。\n\n判据单源是 governance/fact-pii-rules.json(63 条模式 + 豁免登记),不写死在脚本里——\nPII 形状会随业务扩张,写死就意味着每次扩张都要改门禁代码并重跑它的测试。与 otel-attributes.json\n同思路。豁免按 \u003cFact\u003e:\u003c字段路径\u003e 登记,不是裸键名:同名字段在不同 Fact 里性质可以不同。\n\n扫描面含 contracts/candidates/facts——候选必须一起扫,否则 PII 字段可以先进候选、\n再随批准转正,绕开本门禁。不扫 compatibility/baselines:历史兼容基线按定义不可改,报红也无从修。\n\n接入:根 check 链(check:facts 之后)、两份 CI 工作流(check:ci-mirror 守逐行一致,462 行通过)、\nevidence-scopes 作用域登记。本机实测:21 个 Fact / 116 字段 0 违规;篡改必红两种形态\n(加 PII 字段、改开放结构)均 exit 1,还原后 exit 0;门禁测试 8 例全过。\n\n顺带把纪律 4 里 check:pins 的判据范围写明为 @juhai/* —— 原措辞未限定,读起来像全仓禁 ^/~。\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:26:28-07:00"}],"HeadCommit":{"Sha1":"748492c2a1013dbf03b6234f2a85dea73af7e9e6","Message":"chore(reports): fact-pii / gate-flow / ci-mirror 三份回绑 @ bb26784\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑,三份均绑 bb26784 /\nworktreeDirty=false:\n\n fact-pii 21 个 Fact / 116 个字段,0 处 PII 形状与开放结构,25 个自由文本登账待裁\n gate-flow 47 个脚本、35 个有消费入口(新门禁已被推导为在链上),12 个流外且已具名\n ci-mirror 规范化 462 行逐行相同(两份工作流同步加了 check:fact-pii)\n\n后两份的作用域含本轮改动的 package.json 与两份 workflow,故一并回绑。\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:28:00-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/832a54f24c1bf763ba06cf5513f7f7bd53b28e45...748492c2a1013dbf03b6234f2a85dea73af7e9e6","Len":2}...
|
1789774131
|
Edit
Delete
|
|
31189
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"832a54f24 {"Commits":[{"Sha1":"832a54f24c1bf763ba06cf5513f7f7bd53b28e45","Message":"docs(部署): 记录补 §14.6——D-11 闭环,forward_auth 的 200 分支第一次在服务端实测到\n\n三个分支实测(网关 :58080):无令牌 401 / 伪造令牌 401 / **真实 IdP 令牌 200**;\n对照同一令牌直连容器 :53001 也是 200。返回体的 mode=fail-closed 与四个 ledger 端口\n确认打到的是容器而不是 dev 进程(:3101 那条链回的是 mode=local)。\n\nD-11 此前卡在一个操作顾虑而不是技术障碍:令牌只在浏览器里,搬进 shell 就会经过对话记录。\n这次用一次性本地接收端绕开——只听 127.0.0.1:45999、收到第一个 POST 就落盘(600)并自毁,\n页面把令牌 POST 过去(Content-Type: text/plain 在 CORS 安全列表内,不触发预检),shell 从\n文件读,用完 shred。方法一并写进记录,免得下次重新想。\n\n同轮把 D-11 从「未闭环」表摘掉(闭环项留在未闭环表里是自相矛盾),并把 §14 开头\n「后者只关掉一半」收窄为:服务端语义与服务端直连都已验证,唯一仍测不到的是浏览器跨源\n带令牌那条路,而它测不到的原因是预检带不了令牌(§14.4),属设计使然、不是缺证据。\n\n也写明这个令牌验不了 D-13:工作台客户端 scope 只有 openid profile,没有 platform:ops,\nevaluateOpsAccess 第一关就以 OPS_SCOPE_REQUIRED 挡下,到不了 admins.has(auth.subject)。\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:26:00-07:00"},{"Sha1":"4df190ddfc1fdc7d3fe7ac71f4094a1641484eca","Message":"test(contracts,runtime): 把最后 9 条「仅单测」钉进夹具——两档归零,17 套件 458 例\n\n覆盖度探针的「都没有」在同日已全部归零(契约包九个域 + 运行时模块侧 4 条由 91ae216 补齐),\n但「仅单测」还剩 9 条。逐条看过,它们都不属于该工具自述里 ③ 说的两类豁免(基线闸门登记位\n*_BASELINE_NOT_READY / G3 / G5、演进对比类),而是普通字段守卫——守卫删掉只有 contracts:test\n或模块单测会红,门禁不会:\n\n module-permission APP_ID_REQUIRED(preflight 缺 appId)\n cross-domain-workflow WORKFLOW_IDENTITY_INVALID(定义缺 id)\n WORKFLOW_SCOPE_VERSION_INVALID(计划请求缺 scopeVersion)\n collaboration-messaging MESSAGE_CONTEXT_REQUIRED(消息缺 tenantId)\n OWNER_COMMAND_REQUIRED(动作卡缺 ownerDomain)\n notification-webhook WEBHOOK_SOURCE_EVENT_ID_REQUIRED\n WEBHOOK_TEMPLATE_VERSION_INVALID\n WEBHOOK_VARIABLES_INVALID\n\n跨域流程那两条是本会话同日第一条补强(13c7eb7)自己新增/收紧的判定,当时只补了单测没进夹具,\n本轮补齐——自己留的口子自己收。\n\n构造用例时踩到的坑:自动「从同规则里挑最完整的一条用例作底」会挑到已经带别的缺陷的负例,\n产出里混进无关原因码(实测跨域流程那条挑到了「两步共用幂等键」、IM 那条挑到了「senderType 大小写错」)。\n改为一律从该规则的正例派生、只做一处改动,每例产出单一原因码;reasons 按规则真实返回值逐字回填,\n不用前缀蒙混。\n\n覆盖:module-permission 10 → 11、cross-domain-workflow 16 → 18、collaboration-messaging 42 → 46、\nnotification-webhook 39 → 42;根链 check:fixtures 17 套件 458 例 0 失败 0 不可用。\n模块夹具与 test/negative/*.fixtures.test.ts 同源(it.each 直接遍历夹具文件),module-permission 的\n用例数随夹具自动同步,pnpm --dir runtime --filter @juhai/module-permission test 51/51。\n\n结果:15 个套件的「都没有」与「仅单测」两档现均为 0。口径与数字同步写进仓根 CLAUDE.md 那一段,\n并留了一句「后续新增规则请照此维持,或在本行注明保留理由」。\n\n证据:node --test contracts/test/*.test.mjs 404/404、typecheck 绿、check:fixtures 17 套件 458 例 0 失败。\n负向实测:把 IM 新增那条的声明改成 SENDER_TYPE_INVALID → 门禁 exit 1 并点名该例\n(reasons=[\"OWNER_COMMAND_REQUIRED\"]),还原后 exit 0。\n工作树另有并行会话的 check-fact-pii WIP,故本次不回绑任何 reports/。\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:23:53-07:00"},{"Sha1":"2f9175b43d249cdf68a65071a9cba4a5c214c0f1","Message":"test(contracts): 会话追加的 STALE 与 REJECT 两个出口没钉——订正我把它判成探针误报的结论\n\nfixture-coverage 把 collaboration-messaging 的 REJECT 与 STALE 报成「仅单测」,我一度判为探针把\n「决策 kind」误当原因码统计、准备去改探针。判错了。\n\n这套 kind-as-reason 是评估器有意的约定:同一份夹具里 DUPLICATE / GAP / NOT_MEMBER /\nTENANT_MISMATCH / CONVERSATION_BINDING_REQUIRED / CONVERSATION_MISMATCH / STATE_INVALID 七个出口\n都是这么声明的,notification-webhook 的 DUPLICATE / DLQ 同理。探针的分类是对的,该补的是夹具。\n\nclassifyConversationAppend 有 10 个出口,夹具此前钉了 7 个,缺的两个:\n STALE incomingSequence 不前移——乱序或重放(conversation-message.ts:76)\n REJECT 消息自身 preflight 就没过(:67)\n前者是「重放的消息不能覆盖已处理序列」这条纪律在门禁上的唯一出口。\n\n补:夹具 42 → 44 例(N39 / N40)。该域「仅单测」由 4 降至 2。\n\n负向实测:把 N39 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例,恢复后转绿。\n\n教训写进 SOURCE.md:探针报出来的要逐条回源码核,不能因为「看着像 kind 不像 code」就判成误报——\n这套契约包里 kind 就是 code。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、定向 32/32、contract-collaboration-messaging 44/44。\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:22:38-07:00"}],"HeadCommit":{"Sha1":"832a54f24c1bf763ba06cf5513f7f7bd53b28e45","Message":"docs(部署): 记录补 §14.6——D-11 闭环,forward_auth 的 200 分支第一次在服务端实测到\n\n三个分支实测(网关 :58080):无令牌 401 / 伪造令牌 401 / **真实 IdP 令牌 200**;\n对照同一令牌直连容器 :53001 也是 200。返回体的 mode=fail-closed 与四个 ledger 端口\n确认打到的是容器而不是 dev 进程(:3101 那条链回的是 mode=local)。\n\nD-11 此前卡在一个操作顾虑而不是技术障碍:令牌只在浏览器里,搬进 shell 就会经过对话记录。\n这次用一次性本地接收端绕开——只听 127.0.0.1:45999、收到第一个 POST 就落盘(600)并自毁,\n页面把令牌 POST 过去(Content-Type: text/plain 在 CORS 安全列表内,不触发预检),shell 从\n文件读,用完 shred。方法一并写进记录,免得下次重新想。\n\n同轮把 D-11 从「未闭环」表摘掉(闭环项留在未闭环表里是自相矛盾),并把 §14 开头\n「后者只关掉一半」收窄为:服务端语义与服务端直连都已验证,唯一仍测不到的是浏览器跨源\n带令牌那条路,而它测不到的原因是预检带不了令牌(§14.4),属设计使然、不是缺证据。\n\n也写明这个令牌验不了 D-13:工作台客户端 scope 只有 openid profile,没有 platform:ops,\nevaluateOpsAccess 第一关就以 OPS_SCOPE_REQUIRED 挡下,到不了 admins.has(auth.subject)。\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:26:00-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/2156538deab81264dd796a4ed668509522dbff45...832a54f24c1bf763ba06cf5513f7f7bd53b28e45","Len":3}...
|
1789773970
|
Edit
Delete
|
|
31188
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"2156538de {"Commits":[{"Sha1":"2156538deab81264dd796a4ed668509522dbff45","Message":"docs(部署): D-13 归属改为与 D-4 一并验,并写明为什么不先单独改\n\nOwner 2026-09-18 定:等 feat/identity-canonical-tenants 合并后连 D-4 一起验。\n\n归属列同时写下理由,而不只写「等」。D-13 看上去是两行就能改完的配置错误\n(.secrets 里换一个 UUID + 重建容器),容易被顺手改掉再顺手记一句「已修复」——\n但单独改它最多验到「守卫这关过了」:M3 写路径仍会挂在 D-4 的 CANONICAL_TENANT_REQUIRED,\n证不出「受控执行面对 IdP 令牌可用」。把这句话留在表里,是为了让下一个人别拿\n半条证据当整条用。\n\n依赖关系现在三处一致:§6 D-4、§14.5 D-13、未合并分支登记-2026-09-15.md 的\nfeat/identity-canonical-tenants 行。\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:22:14-07:00"}],"HeadCommit":{"Sha1":"2156538deab81264dd796a4ed668509522dbff45","Message":"docs(部署): D-13 归属改为与 D-4 一并验,并写明为什么不先单独改\n\nOwner 2026-09-18 定:等 feat/identity-canonical-tenants 合并后连 D-4 一起验。\n\n归属列同时写下理由,而不只写「等」。D-13 看上去是两行就能改完的配置错误\n(.secrets 里换一个 UUID + 重建容器),容易被顺手改掉再顺手记一句「已修复」——\n但单独改它最多验到「守卫这关过了」:M3 写路径仍会挂在 D-4 的 CANONICAL_TENANT_REQUIRED,\n证不出「受控执行面对 IdP 令牌可用」。把这句话留在表里,是为了让下一个人别拿\n半条证据当整条用。\n\n依赖关系现在三处一致:§6 D-4、§14.5 D-13、未合并分支登记-2026-09-15.md 的\nfeat/identity-canonical-tenants 行。\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:22:14-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/4f36e22448f8fdf4611af3f5fa34305ae58769ef...2156538deab81264dd796a4ed668509522dbff45","Len":1}...
|
1789773742
|
Edit
Delete
|
|
31187
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"4f36e2244 {"Commits":[{"Sha1":"4f36e22448f8fdf4611af3f5fa34305ae58769ef","Message":"test(contracts): 注册中心 plan 把 BLOCKED 判成了放行——裁决没批、候选自带 blocker,夹具都说通过\n\n前一轮(91216b5)补了入参体检的门禁覆盖。本轮按「公开方法 × 出口」再盘,查出的是\ngovernance/fixture-coverage.mjs 按设计查不到的一类:它只变异夹具已有用例的字段,\n夹具从没构造过的入口不会被发现。三个规则文件零改动,只动夹具评估器的可见性。\n\n1. plan 把 BLOCKED 判成放行。评估器原判据是 `\"reasons\" in r`;ManifestAdmissionResult 三个出口里\n BLOCKED 携带的是 blockers 不是 reasons,于是返回空数组 = ACCEPT。实测两种 BLOCKED 都被夹具判为通过:\n 候选自带 blockedBy([\"CHG-001\"])、所需裁决仍 pending([\"DECISION_PENDING:DEC-011\"])——\n 而它们明写着 activationAllowed: false / registryWriteAllowed: false。\n 同一文件下面的 upgrade 规则本来就写对了(... : [...d.blockers]),plan 与自己的兄弟规则不一致。\n\n2. 没有任何一条 plan 用例带合法快照。整条「有策略」分支(清单字段校验、裁决闸门、READY_FOR_REVIEW)\n 在门禁上根本不存在,唯一那条 N05 是「无策略即拒」。\n\n3. refresh 没有夹具规则:planner 第三个公开方法零门禁覆盖。\n\n修完之后覆盖度一度变差,这是对的。补上带快照的 plan 用例后,此前够不着的清单校验分支第一次被变异探针\n走到,fixture-coverage 随即报出 12 条「夹具与单测都没有」(SERVICES_REQUIRED / PERMISSIONS_REQUIRED /\nPRODUCED_FACTS_REQUIRED / CONSUMED_FACTS_REQUIRED / DEPENDENCIES_REQUIRED / MANIFEST_BLOCKERS_REQUIRED /\nMANIFEST_KIND_INVALID / OWNER_DOMAIN_REQUIRED 与 refresh 侧四条)——它们一直都在,只是之前没人能看见。\n连同 4 条「仅单测」一并钉住后回到 0 / 0。\n\n另修一处本轮自己的松懈:N42 的 reasons 写成了前缀 MANIFEST,任何 MANIFEST* 都能匹配,已改为确切原因码。\n\n一处明写不覆盖:plan() 的 DECISION_MISSING:\u003cid\u003e 按当前控制流不可达——缺一条必需裁决在 normalizePolicy\n装载时就抛 MANIFEST_DECISION_STATUS_INVALID:\u003cid\u003e,运行时工厂退回 deny-all。N39 钉这条真实路径,\nN49 钉装载侧原因码,不为不可达分支造用例。\n\n覆盖:夹具 41 → 70 例(正 7 / 反 63),定向测试 59 → 63 例,前一轮断言一条未改。\n变异探针(70 例 × 14 种脏值)38374 个变异点、0 处抛异常。\n\n未做(越界):C01.04 五个关键应用的固定版本消费(今 2 个 pin)与 C01.06 只读目录查询入口属接线,\n不在本轮;Catalog 登记未动。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 404/404、该套件夹具 70/70 失败 0、fixture-coverage 该套件 0 / 0。\n负向实测:把 N37 的 blocker 声明改成 CHG-999 → 门禁 exit 1 并点名该例,还原后 exit 0。\n本次不回绑任何 reports/。\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:21:01-07:00"}],"HeadCommit":{"Sha1":"4f36e22448f8fdf4611af3f5fa34305ae58769ef","Message":"test(contracts): 注册中心 plan 把 BLOCKED 判成了放行——裁决没批、候选自带 blocker,夹具都说通过\n\n前一轮(91216b5)补了入参体检的门禁覆盖。本轮按「公开方法 × 出口」再盘,查出的是\ngovernance/fixture-coverage.mjs 按设计查不到的一类:它只变异夹具已有用例的字段,\n夹具从没构造过的入口不会被发现。三个规则文件零改动,只动夹具评估器的可见性。\n\n1. plan 把 BLOCKED 判成放行。评估器原判据是 `\"reasons\" in r`;ManifestAdmissionResult 三个出口里\n BLOCKED 携带的是 blockers 不是 reasons,于是返回空数组 = ACCEPT。实测两种 BLOCKED 都被夹具判为通过:\n 候选自带 blockedBy([\"CHG-001\"])、所需裁决仍 pending([\"DECISION_PENDING:DEC-011\"])——\n 而它们明写着 activationAllowed: false / registryWriteAllowed: false。\n 同一文件下面的 upgrade 规则本来就写对了(... : [...d.blockers]),plan 与自己的兄弟规则不一致。\n\n2. 没有任何一条 plan 用例带合法快照。整条「有策略」分支(清单字段校验、裁决闸门、READY_FOR_REVIEW)\n 在门禁上根本不存在,唯一那条 N05 是「无策略即拒」。\n\n3. refresh 没有夹具规则:planner 第三个公开方法零门禁覆盖。\n\n修完之后覆盖度一度变差,这是对的。补上带快照的 plan 用例后,此前够不着的清单校验分支第一次被变异探针\n走到,fixture-coverage 随即报出 12 条「夹具与单测都没有」(SERVICES_REQUIRED / PERMISSIONS_REQUIRED /\nPRODUCED_FACTS_REQUIRED / CONSUMED_FACTS_REQUIRED / DEPENDENCIES_REQUIRED / MANIFEST_BLOCKERS_REQUIRED /\nMANIFEST_KIND_INVALID / OWNER_DOMAIN_REQUIRED 与 refresh 侧四条)——它们一直都在,只是之前没人能看见。\n连同 4 条「仅单测」一并钉住后回到 0 / 0。\n\n另修一处本轮自己的松懈:N42 的 reasons 写成了前缀 MANIFEST,任何 MANIFEST* 都能匹配,已改为确切原因码。\n\n一处明写不覆盖:plan() 的 DECISION_MISSING:\u003cid\u003e 按当前控制流不可达——缺一条必需裁决在 normalizePolicy\n装载时就抛 MANIFEST_DECISION_STATUS_INVALID:\u003cid\u003e,运行时工厂退回 deny-all。N39 钉这条真实路径,\nN49 钉装载侧原因码,不为不可达分支造用例。\n\n覆盖:夹具 41 → 70 例(正 7 / 反 63),定向测试 59 → 63 例,前一轮断言一条未改。\n变异探针(70 例 × 14 种脏值)38374 个变异点、0 处抛异常。\n\n未做(越界):C01.04 五个关键应用的固定版本消费(今 2 个 pin)与 C01.06 只读目录查询入口属接线,\n不在本轮;Catalog 登记未动。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 404/404、该套件夹具 70/70 失败 0、fixture-coverage 该套件 0 / 0。\n负向实测:把 N37 的 blocker 声明改成 CHG-999 → 门禁 exit 1 并点名该例,还原后 exit 0。\n本次不回绑任何 reports/。\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:21:01-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd...4f36e22448f8fdf4611af3f5fa34305ae58769ef","Len":1}...
|
1789773705
|
Edit
Delete
|
|
31186
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"73d03c062 {"Commits":[{"Sha1":"73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd","Message":"docs(runbook): 补 §2.1——demo 租户重建的完整应对,含「哪一列」这个会咬人的细节\n\nidentity 库被清掉(db.sh --fresh / 手工重建 / 从早于 09-16 的 dump 恢复)之后,租户、\n管理员、应用与两个 OIDC 客户端会一起没——它们只在库里,不在任何配置文件里;而管理员\n明文口令全机只有 .secrets/idp-demo-admin.txt 一份(库存散列,备份 dump 里也搜不到明文)。\n\n本节写清四件此前只能靠翻代码才知道的事:两个 bootstrap 各自的一次性约束\n(TENANT_SLUG_CONFLICT / ADMINISTRATION_ALREADY_BOOTSTRAPPED)与「库还在时只能走管理 API」;\n两条 bootstrap 的确切载荷(按 zod schema 核对,password ≥ 12、redirectUri 只收 https 或\nloopback);工作台客户端为什么必须先有人工登录才能登记,且不得给它 idp:manage;以及\n四个 UUID 换新后要同步的四处配置,每处配上漏掉时的具体症状。\n\n其中 PLATFORM_OPS_ADMIN_SUBJECTS 填 users.subject 而不是 users.id——现存 dev 值就是错的,\n见 dev 部署记录 D-13。改 PLATFORM_OPS_* 必须重建容器,只 restart 不带新环境。\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:18:51-07:00"},{"Sha1":"3ed10d6c9473aca115f12b9f32aac435aa79e3ee","Message":"docs(部署): 登记 D-13——PLATFORM_OPS_ADMIN_SUBJECTS 的 dev 值填的是 users.id,不是令牌里的 sub\n\n判定链是 token-verifier.ts:136(subject = payload.sub)→ AuthContext.subject →\nplatform-ops.adapter.ts:22(admins.has(auth.subject)),而 IdP 访问令牌的 sub 取自\nusers.subject。当前 dev 配的是该管理员的 users.id(4782bc0d-…),实际 sub 是\ne6783482-…,两者不同——**IdP 签发的管理员令牌打受控执行面会 403 OPS_FORBIDDEN**。\n\nsub 是从 §14 那次真实登录拿到的令牌里解出来的,不是推断。之所以此前没暴露:§5\n「三重守卫齐全 200」的取证用的是手工签发的合成令牌,值自然与白名单对得上;真实 IdP\n令牌这条路是 §14 才第一次走通的。\n\n本轮只登记不改:订正它要动仓外 .secrets 并重建容器,且正向验证需要再走一次人工登录。\n重建 demo 租户时该填哪一列,写在 runbook §2.1。\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:18:43-07:00"},{"Sha1":"91ae21671f2d958ef5e228e525cc931a8e586d40","Message":"test(runtime): 补掉覆盖度探针在两个模块查出的 4 条——夹具与单测都没走到\n\ngovernance/fixture-coverage.mjs 落仓后第一次全量扫描(15 个套件)查出的 4 条,全在运行时模块侧:\n\n module-permission ACTION_REQUIRED / RESOURCE_REQUIRED / RESOURCE_ID_REQUIRED\n module-audit AUDIT_COMMIT_MODE_INVALID\n\npermission 的 preflight 已经钉了 tenant / request / trace / actor / scopeVersion 五项(N01–N03),\n唯独「资源三件套」一条用例都没有——那三条守卫删掉,check:fixtures 与模块单测都不会红。\naudit 的 commit 模式同理:mode 不在册时拒绝这条判定此前无人走到。\n\n补:permission 夹具 9 → 10 例(N08,三条原因一条用例同时钉住,门禁要求逐条出现)、\naudit 26 → 27 例(N18,mode=\"best-effort\" 这种看着合理但不在册的取值)。\n模块夹具与 test/negative/*.fixtures.test.ts 同源——单测 it.each 直接遍历夹具文件,所以加夹具用例\n即同时加单测,本次没有另写测试代码。\n\npermission 的夹具是 prettier 按宽度折行的混合风格,JSON round-trip 会把整份重排成 180 行噪音;\n改用文本插入,diff 保持 +8/-1。\n\n负向实测:把 N08 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例,恢复后转绿。\n\n补后 15 个套件的「夹具与单测都没有」全为 0,CLAUDE.md 同步改口。\n\n证据:module-permission 50/50、module-audit 81/81(vitest 无库单测);\ncheck:fixtures 两套件 37/37;fixture-coverage 全量 0。\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:18:36-07:00"}],"HeadCommit":{"Sha1":"73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd","Message":"docs(runbook): 补 §2.1——demo 租户重建的完整应对,含「哪一列」这个会咬人的细节\n\nidentity 库被清掉(db.sh --fresh / 手工重建 / 从早于 09-16 的 dump 恢复)之后,租户、\n管理员、应用与两个 OIDC 客户端会一起没——它们只在库里,不在任何配置文件里;而管理员\n明文口令全机只有 .secrets/idp-demo-admin.txt 一份(库存散列,备份 dump 里也搜不到明文)。\n\n本节写清四件此前只能靠翻代码才知道的事:两个 bootstrap 各自的一次性约束\n(TENANT_SLUG_CONFLICT / ADMINISTRATION_ALREADY_BOOTSTRAPPED)与「库还在时只能走管理 API」;\n两条 bootstrap 的确切载荷(按 zod schema 核对,password ≥ 12、redirectUri 只收 https 或\nloopback);工作台客户端为什么必须先有人工登录才能登记,且不得给它 idp:manage;以及\n四个 UUID 换新后要同步的四处配置,每处配上漏掉时的具体症状。\n\n其中 PLATFORM_OPS_ADMIN_SUBJECTS 填 users.subject 而不是 users.id——现存 dev 值就是错的,\n见 dev 部署记录 D-13。改 PLATFORM_OPS_* 必须重建容器,只 restart 不带新环境。\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:18:51-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/45a6bd523973c97e88f31faa12604773150cec87...73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd","Len":3}...
|
1789773540
|
Edit
Delete
|
|
31185
|
5
|
9
|
5
|
116
|
0
|
0
|
refs/tags/packages-v1.0.0-rc.4
|
0
|
{"Commits":null,"HeadCommit":{" {"Commits":null,"HeadCommit":{"Sha1":"557a95c4422518cf3d9fdff04d261114ab389169","Message":"chore(release): 三包推到 1.0.0-rc.4——clients 扫描面与这轮 contracts 硬化一起上车\n\n发 rc.4 的直接动因:e61bfcf 给 check:module-imports 补的 clients 扫描面与两条规则\n(CLIENT_FORBIDDEN_IMPORT / ESCAPES_CLIENT)不在任何已发布版本里,而 @juhai/governance\n的 rc.0—rc.3 已全部被占用,按 G-12 的边界只能往前发下一个 RC。\n\n随车发出的远不止这些。自 rc.3 的源 036a308 起:\n contracts 147 个文件 / 51 条提交(九域规则的入参体检与门禁覆盖那一大轮)\n governance 61 个文件 / 48 条提交\n runtime/clients/fact 5 个文件 / 5 条提交\n三包版本一致,符合 CL-5「一次发布 = 一个 tag = 一组同版本包」;包目录单源仍是\ngovernance/release-packages.json。\n\n通道:本地旁路(G-12 第三次使用)。CI 正道 2026-09-18 实测双重不可用——GitHub Actions\n最近三次 run 全部 failure(账户计费,最新 35215270797 即 CLAUDE.md 记的那条注解),\n且 GitHub 镜像落后 237 条提交、因分支保护的 required check 跑不起来而推不动,\ne61bfcf 的代码根本不在 GitHub 上。按 G-12 边界,rc.4 同样不得宣称经过发布门禁验证。\n\n本次按 CL-5 补打 tag packages-v1.0.0-rc.4——rc.2 / rc.3 两趟都漏了这一步。\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:15-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/0000000000000000000000000000000000000000...557a95c4422518cf3d9fdff04d261114ab389169","Len":0}...
|
1789773457
|
Edit
Delete
|
|
31184
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"45a6bd523 {"Commits":[{"Sha1":"45a6bd523973c97e88f31faa12604773150cec87","Message":"docs(发布): 当场记录 rc.4 列车——三包已发,tag 这趟补上,并写清验证的真实范围\n\nrc.4 三包(contracts / governance / client-fact)2026-09-18 经本地旁路发出,源 557a95c,\nRegistry 实查确认在架、三包均 registry integrity verified。与前两趟不同,本次是当场记录。\n\n这趟补上了 CL-5 要求的 tag packages-v1.0.0-rc.4——rc.2 / rc.3 都漏了这一步,\nprovenance.tag 因此第一次不是 null。构建与发布在 .worktrees/rc4-release 的 detached\n干净检出里做,所以 worktreeDirty:false 是真的(主检出当时有并行会话在改 contracts)。\n\n记录里写清了两件容易被夸大的事:\n\n1. rc.4 远不止触发它的那两条 clients 规则。自 rc.3 源 036a308 起,contracts 147 文件 /\n 51 提交、governance 61 文件 / 48 提交随车发出,包含九域规则入参体检那一整轮。\n2. 发布前只跑了 check:fixtures(17 套件 394 例)与 check:module-imports(396 文件),\n 退出码均 0;**完整 pnpm check 是发布后补跑的**(真实退出码 0,check:evidence partial:\n 36 新鲜 / 5 过期,过期项均属其他任务 WIP)。按 G-12 边界,这些都不构成阶段门证据。\n\nCLAUDE.md 的 contracts 条目同步推到 rc.4,并顺手修掉一处自相矛盾:该条前半句还写着\nrc.2 源 eb3cf2c,而后半句已说明按 provenance 订正为 6d3900a。\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:17:05-07:00"},{"Sha1":"df90a19192218b2b65c7cde7326968ac81d03de0","Message":"chore(reports): check:module-imports 回绑 @ 557a95c\n\n在 .worktrees/rc4-release 的干净检出(detached 557a95c = packages-v1.0.0-rc.4)里重跑,\n绑 557a95c / worktreeDirty=false,扫描 396 个源文件、0 处违规。\n\n同批在该检出里跑的 check:fixtures 也是 0 失败(17 套件 394 例),但那份报告**没有提交**:\nfixtures 的证据作用域含 contracts,而并行会话正在高频改 contracts,绑 557a95c 的快照\n落地即过期,回绑节奏交还给正在改那片的人。\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:14:43-07:00"},{"Sha1":"0b3dab61a1072d682d5a921e00025f46431c95d3","Message":"test(contracts): decideProviderOutcome 在门禁上零覆盖——退避被供应商压短这条修过的规则,没人盯着它别被改回去\n\n前两轮收了入参硬化(c190a6a)与请求体检/出站 allowlist 的用例(d950aa2)。本轮按「公开方法 × 出口」\n重新盘了一遍,两类空白。两个规则文件零改动,只动夹具评估器、夹具与测试。\n\n1. decideProviderOutcome 在门禁上零覆盖。planner 四个公开方法(status / plan /\n decideProviderOutcome / refresh)里,夹具只有 plan 与 refresh 两条规则。既有的 provider 规则走的是\n 独立函数 classifyProviderOutcome——它只看状态码与次数,不认路由策略:退避基数 baseBackoffSeconds、\n 上界 maximumBackoffSeconds、Retry-After 的钳制全在 planner 方法里,夹具一条都看不到。\n 而那里恰好有一条修过的规则:Retry-After 可以把退避拉长到策略上界,但不能把批准过的退避拉短\n (原实现 min(maximumBackoff, retryAfter),供应商回一个 Retry-After: 0 即可令退避清零)。\n 规则改对了,门禁却看不见它有没有被改回去。\n\n 新增 route-outcome 规则,并把 RETRY 连同算出来的秒数一并返回(RETRY:\u003c秒\u003e)——否则夹具只能看见\n 「重试了」,看不见「退避是不是被压短了」。负向实测:把 N33 的声明由 RETRY:20 改成 RETRY:10,\n 门禁 exit 1 并点名该例,秒数确实被钉住。\n\n2. plan() 八条出口此前门禁上没走过:请求非对象、目的地不在册、effectId 非请求派生、尝试次数越界、\n 未授权重放、模板版本未批准、变量越出模板 allowlist、敏感载荷落在未批准敏感数据的模板上。\n 构造用例时注意 effectId = tenant:sourceEvent:destination:template:v\u003c版本\u003e 是派生值,改 templateVersion\n 必须同步改 effectId,否则先撞 WEBHOOK_EFFECT_ID_MISMATCH,测不到目标那条。\n\n一处预期被实测推翻,按实现订正:retryAfterSeconds 超出 [0, 3600] 不是「钳到上界」,而是整条回执判\nPROVIDER_OUTCOME_INVALID。两条边界各钉一例(3600 → RETRY:60;9999 → 拒)。\n\n覆盖:夹具 25 → 39 例(正 4 / 反 35);定向测试 28 → 30 例,补上唯一一条「门禁有、单测没有」的\nWEBHOOK_TEMPLATE_NOT_APPROVED 以及 Retry-After 取值域。前两轮断言一条未改。\n变异探针(39 例真实 payload × 14 种脏值)14560 个变异点、0 处抛异常。\n\n未做(越界):模板审批流、多渠道 Provider、签名防重放、渠道切换仍不在本仓,C12 按缺失模块完善清单\n仍是「裁决」;Catalog 登记未动(notification-webhook 仍 module_e2、code_truth 指向工单仓)。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 400/400、contract-notification-webhook 夹具 39/39 失败 0。\n本次不回绑任何 reports/。\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:13:04-07:00"},{"Sha1":"0b30631d9c45ceff29558ddf821e6cb5a5c7cd00","Message":"docs(治理): 夹具覆盖度的算法写进 CLAUDE.md,并把探针从 /tmp 落进仓里\n\n今天九个契约包的门禁空白有一半是靠一个临时脚本找出来的,光看用例名一个也发现不了。方法写进文档\n而脚本留在 /tmp,下次没人跑得起来——所以一并落仓。\n\ngovernance/fixture-coverage.mjs(诊断,不是门禁:不写报告、不进 pnpm check):\n由 governance/fixtures/*.suite.json 驱动,新增套件自动纳入,不写死域名单。拿每个夹具用例的真实\npayload 逐个叶子字段换脏值,走门禁自己的 evaluateFixturePayload 入口,收集规则实际吐出的原因码,\n分三档——已钉(被某条用例的 reasons 声明过,守卫回退必红)/ 仅单测 / 都没有(守卫删掉任何一道都\n不会红)。--list 连「仅单测」一并列出,--json 出机器格式。\n\n三条读法都写进了脚本抬头与 CLAUDE.md:散文式校验消息不是稳定码,单列「非码」不计缺口;插值原因码\n词汇表无界,按前缀过滤;「仅单测」不等于缺陷——§5 迁入时的设计就是夹具只固定失败关闭一侧。\n\n落仓后第一次全量扫描立刻有新发现:九个契约包「都没有」全为 0(今天收口的结果),但运行时模块侧\n还有 4 条——module-permission 的 ACTION_REQUIRED / RESOURCE_REQUIRED / RESOURCE_ID_REQUIRED、\nmodule-audit 的 AUDIT_COMMIT_MODE_INVALID。已在 CLAUDE.md 记为尚未处理;那是 runtime/ 的纪律范围,\n本次不动。\n\n证据:在仅含本提交改动的导出树上跑通(模块未构建时按 unavailable 跳过,与 check:fixtures 同因)。\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:12:09-07:00"}],"HeadCommit":{"Sha1":"45a6bd523973c97e88f31faa12604773150cec87","Message":"docs(发布): 当场记录 rc.4 列车——三包已发,tag 这趟补上,并写清验证的真实范围\n\nrc.4 三包(contracts / governance / client-fact)2026-09-18 经本地旁路发出,源 557a95c,\nRegistry 实查确认在架、三包均 registry integrity verified。与前两趟不同,本次是当场记录。\n\n这趟补上了 CL-5 要求的 tag packages-v1.0.0-rc.4——rc.2 / rc.3 都漏了这一步,\nprovenance.tag 因此第一次不是 null。构建与发布在 .worktrees/rc4-release 的 detached\n干净检出里做,所以 worktreeDirty:false 是真的(主检出当时有并行会话在改 contracts)。\n\n记录里写清了两件容易被夸大的事:\n\n1. rc.4 远不止触发它的那两条 clients 规则。自 rc.3 源 036a308 起,contracts 147 文件 /\n 51 提交、governance 61 文件 / 48 提交随车发出,包含九域规则入参体检那一整轮。\n2. 发布前只跑了 check:fixtures(17 套件 394 例)与 check:module-imports(396 文件),\n 退出码均 0;**完整 pnpm check 是发布后补跑的**(真实退出码 0,check:evidence partial:\n 36 新鲜 / 5 过期,过期项均属其他任务 WIP)。按 G-12 边界,这些都不构成阶段门证据。\n\nCLAUDE.md 的 contracts 条目同步推到 rc.4,并顺手修掉一处自相矛盾:该条前半句还写着\nrc.2 源 eb3cf2c,而后半句已说明按 provenance 订正为 6d3900a。\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:17:05-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d...45a6bd523973c97e88f31faa12604773150cec87","Len":4}...
|
1789773436
|
Edit
Delete
|
|
31183
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ec0f1c04d {"Commits":[{"Sha1":"ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d","Message":"docs(部署): 记录补 §14——工作台登录第一次真正走通,以及 200 分支为什么在浏览器里测不了\n\n同源托管记录 §6 那一行挂着「工作台 OIDC 公开客户端仍未在身份模块登记」,以及由此导致的\n「forward_auth 的 200 分支未实测」。本节走通前者,后者只关掉一半。\n\n卡住的不是配置。登录页显示「缺配置」容易读成填个环境变量就行,实际是 demo 租户里\n根本没有回调为 http://localhost:3010/callback/ 的客户端;而登记它要过 IdpManagementGuard\n(idp:manage ∧ 管理客户端 ∧ 活跃管理员授权),也就是必须先有人以管理员身份走完托管登录——\n那一步要人工提交口令,这正是它一直没做的原因。\n\n登记出来的客户端只给 openid profile,不给 idp:manage:登记用的是 demo-console 的管理权,\n不是把管理权发给一个跑在浏览器里的公开客户端。\n\n实测走通全链(作用域 = 本机 dev,证据等级 = 运行态链路 + 真实浏览器):SSO 未再要口令、\n同意屏、换令牌、令牌只落 sessionStorage 两键(无 localStorage 无 cookie)、登录页显示出\n与库中 admin@demo.test 一致的 subject(即没踩同源托管记录的 D-10)、userinfo 200、\n带令牌读 modules 200。userinfo 正是 forward_auth 的校验端点,服务端语义上 200 分支成立。\n\n但浏览器跨源那一半关不掉,且是设计使然:带 Authorization 的跨源请求先发 OPTIONS 预检,\n预检按规范不带该头,forward_auth 收到无令牌的 OPTIONS 就 401,真请求发不出去。终态是\n同源托管故无影响,但 :3010 这个 dev 形态永远走不通网关。这与 §11「两个键、两个进程」\n是同一族问题的两面:跨源这件事,代理和网关都不替你解决。\n\n新登记 D-11(服务端直连验 200 分支未做——本轮令牌只在浏览器里,不把有效 bearer 打进\n命令行与日志)与 D-12(登录后顶栏的 hydration 告警)。\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:11:45-07:00"}],"HeadCommit":{"Sha1":"ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d","Message":"docs(部署): 记录补 §14——工作台登录第一次真正走通,以及 200 分支为什么在浏览器里测不了\n\n同源托管记录 §6 那一行挂着「工作台 OIDC 公开客户端仍未在身份模块登记」,以及由此导致的\n「forward_auth 的 200 分支未实测」。本节走通前者,后者只关掉一半。\n\n卡住的不是配置。登录页显示「缺配置」容易读成填个环境变量就行,实际是 demo 租户里\n根本没有回调为 http://localhost:3010/callback/ 的客户端;而登记它要过 IdpManagementGuard\n(idp:manage ∧ 管理客户端 ∧ 活跃管理员授权),也就是必须先有人以管理员身份走完托管登录——\n那一步要人工提交口令,这正是它一直没做的原因。\n\n登记出来的客户端只给 openid profile,不给 idp:manage:登记用的是 demo-console 的管理权,\n不是把管理权发给一个跑在浏览器里的公开客户端。\n\n实测走通全链(作用域 = 本机 dev,证据等级 = 运行态链路 + 真实浏览器):SSO 未再要口令、\n同意屏、换令牌、令牌只落 sessionStorage 两键(无 localStorage 无 cookie)、登录页显示出\n与库中 admin@demo.test 一致的 subject(即没踩同源托管记录的 D-10)、userinfo 200、\n带令牌读 modules 200。userinfo 正是 forward_auth 的校验端点,服务端语义上 200 分支成立。\n\n但浏览器跨源那一半关不掉,且是设计使然:带 Authorization 的跨源请求先发 OPTIONS 预检,\n预检按规范不带该头,forward_auth 收到无令牌的 OPTIONS 就 401,真请求发不出去。终态是\n同源托管故无影响,但 :3010 这个 dev 形态永远走不通网关。这与 §11「两个键、两个进程」\n是同一族问题的两面:跨源这件事,代理和网关都不替你解决。\n\n新登记 D-11(服务端直连验 200 分支未做——本轮令牌只在浏览器里,不把有效 bearer 打进\n命令行与日志)与 D-12(登录后顶栏的 hydration 告警)。\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:11:45-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/7a4b69367b18f4e284218704981b54c0ee10d2b6...ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d","Len":1}...
|
1789773116
|
Edit
Delete
|
|
31182
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"8e5cc87f0 {"Commits":[{"Sha1":"8e5cc87f027dab462c6f3f5bf8f0e42894778016","Message":"docs(计划): 登记本轮五件事,并订正 image-smoke「本机解决不了」与镜像落差 116\n\n§8 加一行:① 目录快照发布维度补 not-in-manifest——「Manifest 落后 HEAD」是一个全局\n事实,此前被复制成 21 条目各自的 release.status=stale,其中 14 条没有运行时模块、\nManifest 从未收录过;② runtime 动态区回灌两级验收 SHA(报告已绑 08c3788 / 1b23285,\n动态区还写 765300b);③ 完整 pnpm --dir runtime check 让 18 份静态子报告同绑一次运行,\nreportProvenanceViolations 归零——单跑一道门禁做不到这条;④ 镜像冒烟本机真跑 6/6 后\n补绑定,check:evidence 在 95b88d3 上到 passed / 41 新鲜 / 0 过期;⑤ runbook §7 补\n--env-file 来源,连带回绑两份工作台快照;⑥ 镜像同步被 GH006 拒绝并留证。\n\n订正上一条登记:image-smoke 被记成「不是本机静态能解决的」,实测不是——它的 sourceSha\n与 image-digest.json 一致,说明冒的是当前镜像、结论有效,过期只是绑定落后,本机真跑一次\n即清。但 §5 那条「CI 在 build 与 sbom 之间插一步冒烟」的登记不因此关闭。\n\n另记一条机制发现:直推镜像 main 在机制上走不通(workflow 只在 pull_request /\npush:[main] / workflow_dispatch 触发,而保护要求 check 挂在被推的 commit 上,该 commit\n没到过 GitHub 就没有 check,要跑就得先推上 main)。可行路线只剩合 PR #45 或侧分支\ndispatch 后推同一 SHA,都要计费先恢复。\n\n三处「落后 116 个提交」按实测改为 245,并写明实测日期与「引用前重测」——这个数每天在涨,\n写死一个数就是下一次误判的来源。\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:09:33-07:00"}],"HeadCommit":{"Sha1":"8e5cc87f027dab462c6f3f5bf8f0e42894778016","Message":"docs(计划): 登记本轮五件事,并订正 image-smoke「本机解决不了」与镜像落差 116\n\n§8 加一行:① 目录快照发布维度补 not-in-manifest——「Manifest 落后 HEAD」是一个全局\n事实,此前被复制成 21 条目各自的 release.status=stale,其中 14 条没有运行时模块、\nManifest 从未收录过;② runtime 动态区回灌两级验收 SHA(报告已绑 08c3788 / 1b23285,\n动态区还写 765300b);③ 完整 pnpm --dir runtime check 让 18 份静态子报告同绑一次运行,\nreportProvenanceViolations 归零——单跑一道门禁做不到这条;④ 镜像冒烟本机真跑 6/6 后\n补绑定,check:evidence 在 95b88d3 上到 passed / 41 新鲜 / 0 过期;⑤ runbook §7 补\n--env-file 来源,连带回绑两份工作台快照;⑥ 镜像同步被 GH006 拒绝并留证。\n\n订正上一条登记:image-smoke 被记成「不是本机静态能解决的」,实测不是——它的 sourceSha\n与 image-digest.json 一致,说明冒的是当前镜像、结论有效,过期只是绑定落后,本机真跑一次\n即清。但 §5 那条「CI 在 build 与 sbom 之间插一步冒烟」的登记不因此关闭。\n\n另记一条机制发现:直推镜像 main 在机制上走不通(workflow 只在 pull_request /\npush:[main] / workflow_dispatch 触发,而保护要求 check 挂在被推的 commit 上,该 commit\n没到过 GitHub 就没有 check,要跑就得先推上 main)。可行路线只剩合 PR #45 或侧分支\ndispatch 后推同一 SHA,都要计费先恢复。\n\n三处「落后 116 个提交」按实测改为 245,并写明实测日期与「引用前重测」——这个数每天在涨,\n写死一个数就是下一次误判的来源。\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:09:33-07:00"},"CompareURL":"luoanwu/platform-governance/compare/2395fff75b12126982536526d4ae47676954a0b2...8e5cc87f027dab462c6f3f5bf8f0e42894778016","Len":1}...
|
1789773007
|
Edit
Delete
|
|
31181
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"7a4b69367 {"Commits":[{"Sha1":"7a4b69367b18f4e284218704981b54c0ee10d2b6","Message":"test(contracts): 成本容量的门禁覆盖——29 个原因码只有 20 个在夹具上走过,M0 后计费字段禁入那条一片空白\n\n与同日 bdb662d(数据分析)同一套做法:把 29 个原因码逐条与夹具的实际产出比对——跑每个用例、\n收集真实返回值,不读代码推断。判定逻辑一行未改,resource-tags.ts 本轮零改动。\n\n1. 9 条从未在门禁上走过:\n - POST_M0_BINDING_FORBIDDEN:M0 阶段禁止把 invoice / price / budget / quota / chargeback 这类\n 计费与容量动作字段写进用量记录(23 个禁入词),是本域最靠近红线的一条,门禁上一片空白。\n - TAG_VALUE_INVALID:标签取值字符集。此前只有「缺标签」有夹具,「标签值乱写」没有。\n - CORRECTION_REFERENCE_INVALID:更正引用必须成对(id 与 reasonCode 同在或同不在)且不得自指。\n - SOURCE_CLASSIFICATION_DOWNGRADE:记录分级不得低于来源登记分级。\n - 六条基线旗标里除 G3_NOT_REACHED 外的全部五条:G5 产品窗口、应用登记、服务身份、审计、资源标签目录。\n\n2. 反方向 4 条门禁有、单测没有:RESOURCE_TAGS_INVALID / CONTENT_DIGEST_INVALID /\n METER_VERSION_INVALID / USAGE_LINEAGE_REQUIRED,补进单测。\n\n覆盖:夹具 32 → 41 例(正 3 / 反 38),新增 N30—N38 九例且每例只产出一条原因(逐例核过实际返回值);\n定向测试 28 → 32 例;原因码门禁覆盖 20/29 → 29/29,单测覆盖 25/29 → 29/29。上一轮用例一条未改。\n\n写单测时两处预期被实测推翻,按实现订正而不是反过来改实现——夹具与用例的作用正在于此:\n① RESOURCE_TAGS_INVALID 不是标签面自己报的码。assessResourceTags 对非对象入参报的是\n REQUIRED_TAG_MISSING 并把八个必填键全列进 missing;RESOURCE_TAGS_INVALID 是 assessUsageRecord\n 把「内嵌标签没过体检」收敛成的一条。\n② meterVersion 的 semver 模式接受预发布后缀,1.0.0-rc.1 合法。\n两条都写成用例固定住,免得下次被当成缺陷「修」掉。\n\n夹具变异探针(41 例真实 payload × 14 种脏值,走 evaluateFixturePayload 入口):\n22792 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做(越界):全资源计量账本、AI 成本明细(依赖 M7)一件未建,C19 按缺失模块完善清单仍是「裁决」;\nCatalog 登记未动。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 398/398、contract-cost-capacity 夹具 41/41 失败 0。\n负向实测:把 N32 的声明原因改成 USAGE_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n(reasons=[\"POST_M0_BINDING_FORBIDDEN\"]),还原后 exit 0。本次不回绑任何 reports/。\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:09:29-07:00"},{"Sha1":"557a95c4422518cf3d9fdff04d261114ab389169","Message":"chore(release): 三包推到 1.0.0-rc.4——clients 扫描面与这轮 contracts 硬化一起上车\n\n发 rc.4 的直接动因:e61bfcf 给 check:module-imports 补的 clients 扫描面与两条规则\n(CLIENT_FORBIDDEN_IMPORT / ESCAPES_CLIENT)不在任何已发布版本里,而 @juhai/governance\n的 rc.0—rc.3 已全部被占用,按 G-12 的边界只能往前发下一个 RC。\n\n随车发出的远不止这些。自 rc.3 的源 036a308 起:\n contracts 147 个文件 / 51 条提交(九域规则的入参体检与门禁覆盖那一大轮)\n governance 61 个文件 / 48 条提交\n runtime/clients/fact 5 个文件 / 5 条提交\n三包版本一致,符合 CL-5「一次发布 = 一个 tag = 一组同版本包」;包目录单源仍是\ngovernance/release-packages.json。\n\n通道:本地旁路(G-12 第三次使用)。CI 正道 2026-09-18 实测双重不可用——GitHub Actions\n最近三次 run 全部 failure(账户计费,最新 35215270797 即 CLAUDE.md 记的那条注解),\n且 GitHub 镜像落后 237 条提交、因分支保护的 required check 跑不起来而推不动,\ne61bfcf 的代码根本不在 GitHub 上。按 G-12 边界,rc.4 同样不得宣称经过发布门禁验证。\n\n本次按 CL-5 补打 tag packages-v1.0.0-rc.4——rc.2 / rc.3 两趟都漏了这一步。\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:15-07:00"},{"Sha1":"2c3928d388603168f2510c6f1450b41804c429cf","Message":"test(contracts): 统一体验的 21 条原因码只有单测——门禁一条没有\n\n这是九个契约包里最后一块成规模的门禁空白,也是唯一一个判定与单测都齐全、只差夹具的域——所以本条\n一条单测都没加,补的全是夹具。\n\n21 条分四组:\n 贡献自身的体检(归属、类型、分级、双时间、投影修订与新鲜度、Owner Command 声明) 9 条\n 与来源登记的四项比对 4 条\n 派发前动作复核的会话 / 租户 / 源版本 / 幂等键 4 条\n 四条基线闸门真正未就绪时的阻断 4 条\n\n用例按语义写而不是删字段:类型 / 分级填不在册的值、生效时间不可解析、投影修订超过源修订、\nmaxAgeSeconds=1 触发过期、maxRevisionLag=0 触发落后、动作声明 reauthorize=false、会话 expired、\n源修订漂移 5。其中「登记前缀是壳根 /」是规则注释自己点名的红线——根前缀会让「登记应用前缀下」的约束\n失效,等于授权该应用深链到任意其他应用的路由,而门禁此前看不到这条。\n\n补:夹具 18 → 36 例(正 3 / 反 33)。本域「夹具无但单测有」由 21 归 0,「哪里都没有」保持 0。\n\n负向实测:把壳根那条的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例,恢复后转绿。\n\n本条只补覆盖,没有改任何判定,也没有改单测;experience-contribution.ts 一行未动。\n九个域的门禁覆盖至此收口:「哪里都没有」全为 0,「夹具无但单测有」由 77 降至 29。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、定向 35/35、contract-enterprise-experience 36/36。\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:07:54-07:00"}],"HeadCommit":{"Sha1":"7a4b69367b18f4e284218704981b54c0ee10d2b6","Message":"test(contracts): 成本容量的门禁覆盖——29 个原因码只有 20 个在夹具上走过,M0 后计费字段禁入那条一片空白\n\n与同日 bdb662d(数据分析)同一套做法:把 29 个原因码逐条与夹具的实际产出比对——跑每个用例、\n收集真实返回值,不读代码推断。判定逻辑一行未改,resource-tags.ts 本轮零改动。\n\n1. 9 条从未在门禁上走过:\n - POST_M0_BINDING_FORBIDDEN:M0 阶段禁止把 invoice / price / budget / quota / chargeback 这类\n 计费与容量动作字段写进用量记录(23 个禁入词),是本域最靠近红线的一条,门禁上一片空白。\n - TAG_VALUE_INVALID:标签取值字符集。此前只有「缺标签」有夹具,「标签值乱写」没有。\n - CORRECTION_REFERENCE_INVALID:更正引用必须成对(id 与 reasonCode 同在或同不在)且不得自指。\n - SOURCE_CLASSIFICATION_DOWNGRADE:记录分级不得低于来源登记分级。\n - 六条基线旗标里除 G3_NOT_REACHED 外的全部五条:G5 产品窗口、应用登记、服务身份、审计、资源标签目录。\n\n2. 反方向 4 条门禁有、单测没有:RESOURCE_TAGS_INVALID / CONTENT_DIGEST_INVALID /\n METER_VERSION_INVALID / USAGE_LINEAGE_REQUIRED,补进单测。\n\n覆盖:夹具 32 → 41 例(正 3 / 反 38),新增 N30—N38 九例且每例只产出一条原因(逐例核过实际返回值);\n定向测试 28 → 32 例;原因码门禁覆盖 20/29 → 29/29,单测覆盖 25/29 → 29/29。上一轮用例一条未改。\n\n写单测时两处预期被实测推翻,按实现订正而不是反过来改实现——夹具与用例的作用正在于此:\n① RESOURCE_TAGS_INVALID 不是标签面自己报的码。assessResourceTags 对非对象入参报的是\n REQUIRED_TAG_MISSING 并把八个必填键全列进 missing;RESOURCE_TAGS_INVALID 是 assessUsageRecord\n 把「内嵌标签没过体检」收敛成的一条。\n② meterVersion 的 semver 模式接受预发布后缀,1.0.0-rc.1 合法。\n两条都写成用例固定住,免得下次被当成缺陷「修」掉。\n\n夹具变异探针(41 例真实 payload × 14 种脏值,走 evaluateFixturePayload 入口):\n22792 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做(越界):全资源计量账本、AI 成本明细(依赖 M7)一件未建,C19 按缺失模块完善清单仍是「裁决」;\nCatalog 登记未动。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 398/398、contract-cost-capacity 夹具 41/41 失败 0。\n负向实测:把 N32 的声明原因改成 USAGE_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n(reasons=[\"POST_M0_BINDING_FORBIDDEN\"]),还原后 exit 0。本次不回绑任何 reports/。\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:09:29-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/54e6324c8b404aba56e1fa681cbcbe67019128c0...7a4b69367b18f4e284218704981b54c0ee10d2b6","Len":3}...
|
1789773006
|
Edit
Delete
|
|
31180
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/docs/registry-blueprint-record
|
0
|
{"Commits":[{"Sha1":"3bd0c5896 {"Commits":[{"Sha1":"3bd0c5896c9b7842434caa9c60d32d7bfbd686c4","Message":"docs(domain): 注册中心蓝图补记后四笔,并把「现状」改成指向机器报告而不是复写活数字\n\n蓝图是 Catalog 给本模块登记的 evidence 之一,它的「2026-09-18 规则加固」节此前只记了\n92a6b8e 一笔:三条缺陷、数字停在单测 44 例 / 夹具 15 例。同日 94366bc / 91216b5 /\n5f3f608 / d860eb6 四笔在蓝图里没有任何痕迹。本条只补记录,不改任何规则与 Catalog。\n\n补进去的四条缺陷(表格 3 行 → 7 行):\n- 第 4 条(94366bc):四条就绪闸门写作 !context.x,传 \"false\" / 1 / \"no\" / {} 一律判为\n 已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW;改为 !== true。92a6b8e 只收了入参\n 形状,漏了这四个布尔位。\n- 第 5 条(94366bc + 91216b5):snapshot-upgrade-review.ts 那 393 行在夹具评估器上零\n 覆盖;补 upgrade 规则后重算 snapshot / transition 侧,24 个分支里仍有 12 个没走到。\n- 第 6 条(5f3f608):upgrade 用例全对着四条闸门,闸门下面的请求校验有 15 条原因码\n 哪里都没有。\n- 第 7 条(d860eb6):证据本身可不可信这一层,13 条原因码只有单测、门禁看不到;其中\n TARGET_SOURCE_MUST_BE_CLEAN 与本仓「证据只能绑干净树」同源,两条 *_LINEAGE_MISMATCH\n 是「写着通过了、说的却是别的版本」,比没有证据更危险。\n\n写法上的一处改动,起因是这份文档已经过期过两次:「现状」段不再复写单测与夹具的绝对数,\n改成给出取数命令并指向 reports/fixtures.latest.json。该模块一天内被连续补了四轮覆盖,\n任何写进正文的活数字都会在下一笔提交后失真。逐笔证据里的数字保留——它们绑各自 SHA,\n是历史口径,不随后续变化。另加一段提醒:那份报告此刻仍绑 7523bd0、check:evidence 判\nEVIDENCE_STALE,回绑前其例数不代表当前代码。\n\n核验(本分支 clean 树,rebase 到 origin/main 之后):文中给的 check-fixtures 命令实跑通过\n(0 失败;例数有意不写进文档);check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写一致;Catalog 四字段与六条 blockers 逐项核对;runtime/modules/ 下确无本模块;相对链接\n../缺失模块完善清单-2026-09-16.md 可解析;表格 9 行各 4 列;「现状」段已无任何绝对数。\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-18T15:58:17-07:00"},{"Sha1":"54e6324c8b404aba56e1fa681cbcbe67019128c0","Message":"test(contracts): 四个域共享的快照版本号分支,外加会话准入的两条同组兄弟\n\nnormalizeSnapshot(或其等价物)在四个域里是同一个形状,而「version 必须是正整数」这一条四个域都\n没钉:FILE_ACCESS_POLICY_VERSION_INVALID、WEBHOOK_POLICY_VERSION_INVALID、\nCONVERSATION_POLICY_VERSION_INVALID、NO_USABLE_LAST_KNOWN_GOOD(配置开关)。版本号是「最后良好\n快照」向前比较的唯一依据,比不出来就不能换。\n\n四个域各补一条夹具用例(version: 0;缺失 / 负数 / 字符串 / 小数走同一路,由单测覆盖全部五种)与\n一条单测。配置开关的后果与其余三个不同——它不是「整份拒收」而是保留最后良好快照,所以那条单测断的是\n「活动版本不得被无效候选改动」,这才是该分支的真正断言。\n\n顺带把 collaboration-messaging 的两条同组兄弟一并补上(CONVERSATION_POLICY_REVISION_REQUIRED、\nCONVERSATION_TENANT_POLICIES_REQUIRED)——它与 public-file 的 N26 / N27 是同一形状,三条一起钉住\n才算完整。补后该域「哪里都没有」由 2 归 0。\n\n夹具:public-file 31 → 32、notification-webhook 24 → 25、collaboration-messaging 40 → 42、\nconfiguration-feature-flags 17 → 18。\n\n负向实测:public-file 与 notification-webhook 各把新用例的声明原因改成不会产生的串 → 门禁 exit 1,\n恢复后转绿。\n\n本条只补覆盖,没有改任何判定。至此九个域「哪里都没有」全部为 0。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、四域定向 104/104、四个套件 117/117。\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:06:26-07:00"},{"Sha1":"52fe066412543b57b729791de298ac0b5898b52b","Message":"docs(部署): D-8 裁决落地——dev 面配上现签令牌,并记下它当场被实证的代价\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:04:51-07:00"},{"Sha1":"bdb662d439cf7e24d8caef596c9ebf5d5e38b12d","Message":"test(contracts): 指标契约的门禁覆盖——34 个原因码只有 21 个在夹具上走过,G3 前运维绑定那条一片空白\n\n同日 daa226b 把崩溃面、枚举零校验与真值旗标收了。本轮只问一件事:这些判定门禁看得见几条。\n做法是把 34 个原因码逐条与夹具的实际产出比对——跑每个用例、收集真实返回值,不读代码推断。\n\n判定逻辑一行未改:metric-contract.ts 本轮零改动,只动夹具与测试。\n\n1. 12 条从未在门禁上走过,只有单测看着:CDC_CAPTURE_CONTRACT_REQUIRED、DIMENSION_ID_DUPLICATED、\n OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3,演进的五条不可变断言(METRIC_ID_CHANGED /\n METRIC_NAME_CHANGED / METRIC_OWNER_CHANGED / METRIC_SOURCE_CHANGED / EPISTEMIC_STATUS_CHANGED)、\n REFRESH_SLA_REGRESSION,以及六条基线旗标里的三条(FACT_OR_CDC / IDENTITY_SCOPE /\n DATA_CLASSIFICATION_BASELINE_NOT_READY)。其中 OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3 是本域最\n 靠近红线的一条——G3 前不得把 sql / dburl / outputTable 之类写进契约——门禁上此前一片空白。\n\n2. 1 条走到过但没人钉住:METRIC_CLASSIFICATION_TOO_LOW 由别的用例顺带产出,没有任何用例声明它,\n 改坏了门禁不会红。\n\n3. 反方向一条:REFRESH_SLA_INVALID 门禁有、单测没有,补进单测,连同「演进时 SLA 只能收紧」的正反向。\n\n覆盖:夹具 27 → 40 例(正 3 / 反 37),新增 N25—N37 十三例且每例只产出一条原因(逐例核过实际返回值,\n不靠门禁的前缀包含蒙混);定向测试 25 → 27 例;原因码门禁覆盖 21/34 → 34/34。上一轮用例一条未改。\n\n另跑一遍夹具变异探针(40 例的真实 payload,逐个叶子字段换 14 种脏值,走 evaluateFixturePayload 入口):\n13552 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做(越界):采集、语义层、查询 API 一件未建,C17 按缺失模块完善清单仍是「裁决」;Catalog 登记未动。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 390/390、contract-data-analytics 夹具 40/40 失败 0。\n负向实测:把 N27 的声明原因改成 METRIC_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n(reasons=[\"OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3\"]),还原后 exit 0。\n工作树另有并行会话在跑全链门禁,故本次不回绑任何 reports/。\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:04:20-07:00"},{"Sha1":"d860eb62560ba66297681a63c1466cf47c40d12f","Message":"test(contracts): 注册中心 upgrade 的证据链可信度——13 条原因码只有单测,门禁看不到\n\n前两轮补的是「请求缺字段」;这一轮是证据本身可不可信,它是九个契约包里唯一一处成规模的门禁空白。\n\n13 条分四组:\n 目标制品的身份四要素与来源工作树是否干净 5 条\n 兼容性证据是否通过 / 时间可解析 / 血缘对得上 3 条\n 影响面证据是否定稿 / 可计时 / 同源 3 条\n 复核时钟与候选状态 2 条\n\n其中 TARGET_SOURCE_MUST_BE_CLEAN 尤其要紧:目标制品自己声明是从脏工作树构建的,这类制品不该被\n采信——和本仓报告纪律是同一条(证据只能绑干净树),而门禁此前看不到这条路径。\nCOMPATIBILITY_EVIDENCE_LINEAGE_MISMATCH / IMPACT_EVIDENCE_LINEAGE_MISMATCH 同理:一份「通过了」\n但说的是别的版本、别的提交的证据,比没有证据更危险。\n\n补:夹具 32 → 41 例(N28–N36,九条用例覆盖 13 个原因,每条都是有语义的场景而不是单纯删字段),\n单测 53 → 59 例。本域「夹具无但单测有」由 23 降至 10,「哪里都没有」保持 0。\n\n负向实测:把 N29 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例,恢复后转绿。\n\n本条只补覆盖,没有改任何判定;snapshot-upgrade-review.ts 一行未动。\n全仓「夹具无但单测有」由 77 降至 64,其中约 15 条是各域基线闸门的登记位,按已知口径保留。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、定向 59/59、contract-application-contract-registry 41/41。\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:03:45-07:00"}],"HeadCommit":{"Sha1":"3bd0c5896c9b7842434caa9c60d32d7bfbd686c4","Message":"docs(domain): 注册中心蓝图补记后四笔,并把「现状」改成指向机器报告而不是复写活数字\n\n蓝图是 Catalog 给本模块登记的 evidence 之一,它的「2026-09-18 规则加固」节此前只记了\n92a6b8e 一笔:三条缺陷、数字停在单测 44 例 / 夹具 15 例。同日 94366bc / 91216b5 /\n5f3f608 / d860eb6 四笔在蓝图里没有任何痕迹。本条只补记录,不改任何规则与 Catalog。\n\n补进去的四条缺陷(表格 3 行 → 7 行):\n- 第 4 条(94366bc):四条就绪闸门写作 !context.x,传 \"false\" / 1 / \"no\" / {} 一律判为\n 已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW;改为 !== true。92a6b8e 只收了入参\n 形状,漏了这四个布尔位。\n- 第 5 条(94366bc + 91216b5):snapshot-upgrade-review.ts 那 393 行在夹具评估器上零\n 覆盖;补 upgrade 规则后重算 snapshot / transition 侧,24 个分支里仍有 12 个没走到。\n- 第 6 条(5f3f608):upgrade 用例全对着四条闸门,闸门下面的请求校验有 15 条原因码\n 哪里都没有。\n- 第 7 条(d860eb6):证据本身可不可信这一层,13 条原因码只有单测、门禁看不到;其中\n TARGET_SOURCE_MUST_BE_CLEAN 与本仓「证据只能绑干净树」同源,两条 *_LINEAGE_MISMATCH\n 是「写着通过了、说的却是别的版本」,比没有证据更危险。\n\n写法上的一处改动,起因是这份文档已经过期过两次:「现状」段不再复写单测与夹具的绝对数,\n改成给出取数命令并指向 reports/fixtures.latest.json。该模块一天内被连续补了四轮覆盖,\n任何写进正文的活数字都会在下一笔提交后失真。逐笔证据里的数字保留——它们绑各自 SHA,\n是历史口径,不随后续变化。另加一段提醒:那份报告此刻仍绑 7523bd0、check:evidence 判\nEVIDENCE_STALE,回绑前其例数不代表当前代码。\n\n核验(本分支 clean 树,rebase 到 origin/main 之后):文中给的 check-fixtures 命令实跑通过\n(0 失败;例数有意不写进文档);check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写一致;Catalog 四字段与六条 blockers 逐项核对;runtime/modules/ 下确无本模块;相对链接\n../缺失模块完善清单-2026-09-16.md 可解析;表格 9 行各 4 列;「现状」段已无任何绝对数。\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-18T15:58:17-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/ba752059ee2e67443d3a4b9a1c023c80573bd584...3bd0c5896c9b7842434caa9c60d32d7bfbd686c4","Len":5}...
|
1789772915
|
Edit
Delete
|
|
31179
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"6908c19f9 {"Commits":[{"Sha1":"6908c19f9faf3b006d73054657b97c6cb8f945d9","Message":"fix(quotation): 通知投递显式传重试上限——领取与死信判定不再各用一份常数\n\n服务里的 MAX_ATTEMPTS = 3 只进领取查询与死信清扫,decideNotificationFailure 没传 maxAttempts、\n走的是 @repo/notification-delivery 的包默认 3。今天两个 3 相等所以看不出来,改任一边即静默不一致:\n领取按新上限继续捡,死信判定仍按旧上限提前把行判死。同仓 event-delivery.service.ts 一直是显式传的。\n\n两后端各一行,语义不变。验证:typecheck 绿;pnpm check 22 道全绿;包单测 4/4 未受影响。\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:06:42-07:00"}],"HeadCommit":{"Sha1":"6908c19f9faf3b006d73054657b97c6cb8f945d9","Message":"fix(quotation): 通知投递显式传重试上限——领取与死信判定不再各用一份常数\n\n服务里的 MAX_ATTEMPTS = 3 只进领取查询与死信清扫,decideNotificationFailure 没传 maxAttempts、\n走的是 @repo/notification-delivery 的包默认 3。今天两个 3 相等所以看不出来,改任一边即静默不一致:\n领取按新上限继续捡,死信判定仍按旧上限提前把行判死。同仓 event-delivery.service.ts 一直是显式传的。\n\n两后端各一行,语义不变。验证:typecheck 绿;pnpm check 22 道全绿;包单测 4/4 未受影响。\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:06:42-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/ec9e07de44a5619a8a6b5648f00f5ea7f7dcafcf...6908c19f9faf3b006d73054657b97c6cb8f945d9","Len":1}...
|
1789772844
|
Edit
Delete
|
|
31178
|
5
|
5
|
5
|
81
|
0
|
0
|
refs/heads/main
|
1
|
{"Commits":[{"Sha1":"cc4e7d4da {"Commits":[{"Sha1":"cc4e7d4da3cd396ee608a41307d2b9a496b8d3dd","Message":"fix(service): 通知投递未知异常不再默认重试,并显式传重试上限\n\n两处与同名包在其余消费仓的语义漂移:\n\n- packages/notification-delivery:decideNotificationFailure 对非 NotificationDeliveryError 的\n 异常默认 retryable=true。模板体检失败(assertRegisteredNotificationTemplate 在 try 内)这类\n 确定性错误因此会白烧三次重试预算才进死信。改为只有投递层明确标了可重试才重试。\n- 同批补 NotificationTemplateError 的消息分支:缺它时 lastError 会把模板错误写成\n 「NOTIFICATION_PROVIDER_UNAVAILABLE」,运维照着这条记录去查供应商,查不到任何东西。\n- 两后端 decideNotificationFailure 显式传 maxAttempts: MAX_ATTEMPTS。此前领取查询用本地常数 3、\n 死信判定用包默认 3,靠巧合对齐,改任一边即静默不一致。\n\n验证:typecheck 绿;包单测 5/5(新增未知异常与模板错误两条断言);dual-backend /\nconcurrency-guard / migrations / governance-docs / docs-truth / mobile / provenance 逐道绿。\ncheck:os-product 红,与本次无关:它按 ../Digital Employee OS 找 OS 仓(该路径已不存在),指到真实\n路径后卡在锁定的 OS 基线 SHA,本次改动前即如此。\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:06:35-07:00"}],"HeadCommit":{"Sha1":"cc4e7d4da3cd396ee608a41307d2b9a496b8d3dd","Message":"fix(service): 通知投递未知异常不再默认重试,并显式传重试上限\n\n两处与同名包在其余消费仓的语义漂移:\n\n- packages/notification-delivery:decideNotificationFailure 对非 NotificationDeliveryError 的\n 异常默认 retryable=true。模板体检失败(assertRegisteredNotificationTemplate 在 try 内)这类\n 确定性错误因此会白烧三次重试预算才进死信。改为只有投递层明确标了可重试才重试。\n- 同批补 NotificationTemplateError 的消息分支:缺它时 lastError 会把模板错误写成\n 「NOTIFICATION_PROVIDER_UNAVAILABLE」,运维照着这条记录去查供应商,查不到任何东西。\n- 两后端 decideNotificationFailure 显式传 maxAttempts: MAX_ATTEMPTS。此前领取查询用本地常数 3、\n 死信判定用包默认 3,靠巧合对齐,改任一边即静默不一致。\n\n验证:typecheck 绿;包单测 5/5(新增未知异常与模板错误两条断言);dual-backend /\nconcurrency-guard / migrations / governance-docs / docs-truth / mobile / provenance 逐道绿。\ncheck:os-product 红,与本次无关:它按 ../Digital Employee OS 找 OS 仓(该路径已不存在),指到真实\n路径后卡在锁定的 OS 基线 SHA,本次改动前即如此。\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:06:35-07:00"},"CompareURL":"luoanwu/juhai-after-sales-service-system/compare/2085f1a31a52687344dd74911761be941a185b3c...cc4e7d4da3cd396ee608a41307d2b9a496b8d3dd","Len":1}...
|
1789772844
|
Edit
Delete
|
|
31177
|
5
|
5
|
5
|
82
|
0
|
0
|
refs/heads/main
|
1
|
{"Commits":[{"Sha1":"601955837 {"Commits":[{"Sha1":"601955837eb8caa25a91a2c2da96d9a06f8ea455","Message":"fix(ticket): 通知投递补认领凭据与显式重试上限\n\n领取此前只看 PENDING/FAILED,且完成回写只按 status=\"SENDING\" 匹配:进程崩在 deliver() 里的那行\n会永远停在 SENDING,没有任何路径能把它捡回来。另有一处重试上限双份常数——领取查询没有上限,\n死信判定走的是 @repo/notification-delivery 的包默认 3,两边靠巧合对齐,改任一边即静默不一致。\n\n- notifications 表加 claim_owner / claim_expires_at(两后端各一份 schema 与迁移),领取写认领、\n 完成按 claimOwner 回写并清空,与其余两个消费仓的 claim 列同形。\n- 领取前先把预算烧完的行(含认领过期仍卡在 SENDING 的)扫成死信;领取查询新增「SENDING 且\n 认领已过期」一支,并显式限定 attempts \u003c NOTIFICATION_MAX_ATTEMPTS。\n- 重试上限收敛为一个常数,同时进领取查询、死信清扫和 decideNotificationFailure。\n- 迁移不建索引:本仓迁移红线把非 CONCURRENTLY 的 CREATE INDEX 判为高危 DDL(首版实测被 exit 1\n 拦下),过期 SENDING 那一支由既有 notifications_tenant_status_next_attempt_idx 的\n (tenant_id, status) 前缀服务;要加 (tenant_id, status, claim_expires_at) 须按\n expand→migrate→contract 单独提,不混在这条加列迁移里。\n- packages/notification-delivery:未知异常不再默认可重试(模板体检失败这类确定性错误重发多少次\n 都是同一个结果),并补 NotificationTemplateError 的消息分支——缺它时 lastError 会把模板错误\n 写成「供应商不可用」。与报价仓的同名包语义就此一致。\n\n验证:pnpm check 全绿(15 道静态门禁 + lint + typecheck,含 write-guard / dual-backend /\nmigrations / write-chain);包单测 9/9。领取与清扫 SQL 在本机 Postgres 建临时库实跑:清扫只命中\n「预算烧完 + 认领过期」那一行,领取只取到「到期 PENDING」与「认领过期 SENDING」,正确跳过活认领、\n他租户与 next_attempt_at 未到的行,临时库跑完已删。\n\n未跑:两后端新增的认领回收验收用例(NestJS/Fastify 逐条镜像)属 check:runtime 级别,需 pgvector\n的真实库 + Redis + 附件基础设施,本机 PG 无 pgvector,未硬凑环境,故本次不声称该级证据。\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:06:27-07:00"}],"HeadCommit":{"Sha1":"601955837eb8caa25a91a2c2da96d9a06f8ea455","Message":"fix(ticket): 通知投递补认领凭据与显式重试上限\n\n领取此前只看 PENDING/FAILED,且完成回写只按 status=\"SENDING\" 匹配:进程崩在 deliver() 里的那行\n会永远停在 SENDING,没有任何路径能把它捡回来。另有一处重试上限双份常数——领取查询没有上限,\n死信判定走的是 @repo/notification-delivery 的包默认 3,两边靠巧合对齐,改任一边即静默不一致。\n\n- notifications 表加 claim_owner / claim_expires_at(两后端各一份 schema 与迁移),领取写认领、\n 完成按 claimOwner 回写并清空,与其余两个消费仓的 claim 列同形。\n- 领取前先把预算烧完的行(含认领过期仍卡在 SENDING 的)扫成死信;领取查询新增「SENDING 且\n 认领已过期」一支,并显式限定 attempts \u003c NOTIFICATION_MAX_ATTEMPTS。\n- 重试上限收敛为一个常数,同时进领取查询、死信清扫和 decideNotificationFailure。\n- 迁移不建索引:本仓迁移红线把非 CONCURRENTLY 的 CREATE INDEX 判为高危 DDL(首版实测被 exit 1\n 拦下),过期 SENDING 那一支由既有 notifications_tenant_status_next_attempt_idx 的\n (tenant_id, status) 前缀服务;要加 (tenant_id, status, claim_expires_at) 须按\n expand→migrate→contract 单独提,不混在这条加列迁移里。\n- packages/notification-delivery:未知异常不再默认可重试(模板体检失败这类确定性错误重发多少次\n 都是同一个结果),并补 NotificationTemplateError 的消息分支——缺它时 lastError 会把模板错误\n 写成「供应商不可用」。与报价仓的同名包语义就此一致。\n\n验证:pnpm check 全绿(15 道静态门禁 + lint + typecheck,含 write-guard / dual-backend /\nmigrations / write-chain);包单测 9/9。领取与清扫 SQL 在本机 Postgres 建临时库实跑:清扫只命中\n「预算烧完 + 认领过期」那一行,领取只取到「到期 PENDING」与「认领过期 SENDING」,正确跳过活认领、\n他租户与 next_attempt_at 未到的行,临时库跑完已删。\n\n未跑:两后端新增的认领回收验收用例(NestJS/Fastify 逐条镜像)属 check:runtime 级别,需 pgvector\n的真实库 + Redis + 附件基础设施,本机 PG 无 pgvector,未硬凑环境,故本次不声称该级证据。\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:06:27-07:00"},"CompareURL":"luoanwu/juhai-ai-work-order-system/compare/7c4b197f018b02f5ed675758af3f5be5dbd1de02...601955837eb8caa25a91a2c2da96d9a06f8ea455","Len":1}...
|
1789772841
|
Edit
Delete
|
|
31176
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"2395fff75 {"Commits":[{"Sha1":"2395fff75b12126982536526d4ae47676954a0b2","Message":"docs(计划): 注册中心取舍行补交叉实测证据——「大部分好或相当」可以收紧成「放弃那套实有 4 个缺陷」\n\n第 196 行原写「远端那版大部分比本地那版做得好或相当」,是对现行实现单向复测得出的。另一会话随后做了\n双向交叉实测(两套实现各自编译成 dist 后互喂夹具与单测),结论更明确:被放弃的 9ac9914 实有 4 个缺陷——\nN10 放行可变版本标签、N11 拒错原因(其 \\d+\\.\\d+\\.\\d+ 收下 1.02.0)、P03 与 P04 两处误拒(后者会拒掉\n平台自己在发的 1.0.0-rc.x);根因是它三个文件各带一套版本文法,远端抽 registry-primitives.ts 正为收敛这三套。\n\n反向也测了:9ac9914 的 19 例夹具喂当前实现 13 通过,6 例不通过里 5 例只是原因码改名(同一输入两侧都拒)、\n1 例是摘要大小写的设计取向差异,无任何输入类别失守;其 40 例单测喂当前实现 36 通过。\n\n只补证据与出处(真源仓 7523bd0 的 contracts/SOURCE.md),不改该行原有的复测结论与实现取舍。\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:07:14-07:00"}],"HeadCommit":{"Sha1":"2395fff75b12126982536526d4ae47676954a0b2","Message":"docs(计划): 注册中心取舍行补交叉实测证据——「大部分好或相当」可以收紧成「放弃那套实有 4 个缺陷」\n\n第 196 行原写「远端那版大部分比本地那版做得好或相当」,是对现行实现单向复测得出的。另一会话随后做了\n双向交叉实测(两套实现各自编译成 dist 后互喂夹具与单测),结论更明确:被放弃的 9ac9914 实有 4 个缺陷——\nN10 放行可变版本标签、N11 拒错原因(其 \\d+\\.\\d+\\.\\d+ 收下 1.02.0)、P03 与 P04 两处误拒(后者会拒掉\n平台自己在发的 1.0.0-rc.x);根因是它三个文件各带一套版本文法,远端抽 registry-primitives.ts 正为收敛这三套。\n\n反向也测了:9ac9914 的 19 例夹具喂当前实现 13 通过,6 例不通过里 5 例只是原因码改名(同一输入两侧都拒)、\n1 例是摘要大小写的设计取向差异,无任何输入类别失守;其 40 例单测喂当前实现 36 通过。\n\n只补证据与出处(真源仓 7523bd0 的 contracts/SOURCE.md),不改该行原有的复测结论与实现取舍。\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:07:14-07:00"},"CompareURL":"luoanwu/platform-governance/compare/9a8b716a056597786b9fcbc8fd57bff6c5b44722...2395fff75b12126982536526d4ae47676954a0b2","Len":1}...
|
1789772837
|
Edit
Delete
|
|
31175
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"54e6324c8 {"Commits":[{"Sha1":"54e6324c8b404aba56e1fa681cbcbe67019128c0","Message":"test(contracts): 四个域共享的快照版本号分支,外加会话准入的两条同组兄弟\n\nnormalizeSnapshot(或其等价物)在四个域里是同一个形状,而「version 必须是正整数」这一条四个域都\n没钉:FILE_ACCESS_POLICY_VERSION_INVALID、WEBHOOK_POLICY_VERSION_INVALID、\nCONVERSATION_POLICY_VERSION_INVALID、NO_USABLE_LAST_KNOWN_GOOD(配置开关)。版本号是「最后良好\n快照」向前比较的唯一依据,比不出来就不能换。\n\n四个域各补一条夹具用例(version: 0;缺失 / 负数 / 字符串 / 小数走同一路,由单测覆盖全部五种)与\n一条单测。配置开关的后果与其余三个不同——它不是「整份拒收」而是保留最后良好快照,所以那条单测断的是\n「活动版本不得被无效候选改动」,这才是该分支的真正断言。\n\n顺带把 collaboration-messaging 的两条同组兄弟一并补上(CONVERSATION_POLICY_REVISION_REQUIRED、\nCONVERSATION_TENANT_POLICIES_REQUIRED)——它与 public-file 的 N26 / N27 是同一形状,三条一起钉住\n才算完整。补后该域「哪里都没有」由 2 归 0。\n\n夹具:public-file 31 → 32、notification-webhook 24 → 25、collaboration-messaging 40 → 42、\nconfiguration-feature-flags 17 → 18。\n\n负向实测:public-file 与 notification-webhook 各把新用例的声明原因改成不会产生的串 → 门禁 exit 1,\n恢复后转绿。\n\n本条只补覆盖,没有改任何判定。至此九个域「哪里都没有」全部为 0。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、四域定向 104/104、四个套件 117/117。\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:06:26-07:00"}],"HeadCommit":{"Sha1":"54e6324c8b404aba56e1fa681cbcbe67019128c0","Message":"test(contracts): 四个域共享的快照版本号分支,外加会话准入的两条同组兄弟\n\nnormalizeSnapshot(或其等价物)在四个域里是同一个形状,而「version 必须是正整数」这一条四个域都\n没钉:FILE_ACCESS_POLICY_VERSION_INVALID、WEBHOOK_POLICY_VERSION_INVALID、\nCONVERSATION_POLICY_VERSION_INVALID、NO_USABLE_LAST_KNOWN_GOOD(配置开关)。版本号是「最后良好\n快照」向前比较的唯一依据,比不出来就不能换。\n\n四个域各补一条夹具用例(version: 0;缺失 / 负数 / 字符串 / 小数走同一路,由单测覆盖全部五种)与\n一条单测。配置开关的后果与其余三个不同——它不是「整份拒收」而是保留最后良好快照,所以那条单测断的是\n「活动版本不得被无效候选改动」,这才是该分支的真正断言。\n\n顺带把 collaboration-messaging 的两条同组兄弟一并补上(CONVERSATION_POLICY_REVISION_REQUIRED、\nCONVERSATION_TENANT_POLICIES_REQUIRED)——它与 public-file 的 N26 / N27 是同一形状,三条一起钉住\n才算完整。补后该域「哪里都没有」由 2 归 0。\n\n夹具:public-file 31 → 32、notification-webhook 24 → 25、collaboration-messaging 40 → 42、\nconfiguration-feature-flags 17 → 18。\n\n负向实测:public-file 与 notification-webhook 各把新用例的声明原因改成不会产生的串 → 门禁 exit 1,\n恢复后转绿。\n\n本条只补覆盖,没有改任何判定。至此九个域「哪里都没有」全部为 0。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、四域定向 104/104、四个套件 117/117。\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:06:26-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/52fe066412543b57b729791de298ac0b5898b52b...54e6324c8b404aba56e1fa681cbcbe67019128c0","Len":1}...
|
1789772828
|
Edit
Delete
|
|
31174
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"9a8b716a0 {"Commits":[{"Sha1":"9a8b716a056597786b9fcbc8fd57bff6c5b44722","Message":"docs(回灌): 订正 U-40——「gitSha 为空」不成立,字段叫 sourceSha 且有值,落点随之改向\n\nU-40 原文称 registry 上的 @juhai/client-fact@1.0.0-rc.3 其 provenance.json 为 gitSha:\"\" 空字符串,\n据此把落点定为「平台侧必须带真实 gitSha,本地旁路发布也不得留空」。一手实测推翻该前提:\n\n在真源仓 npm 作用域下 npm pack 拉取架上 tarball 读其 provenance.json,client-fact 与 contracts 的\nrc.3 两份一字不差,且都带 \"sourceSha\": \"036a308f27acf35a46f068c96fea7723ef74d05e\"。\n字段名是 sourceSha 不是 gitSha,且有真实值——提交号一直在包里。照原落点做,平台会去补一个已经存在的字段。\n\n本条结论仍成立、病因换了:不是「平台没写」,是两侧键名对不上,且基座判据根本没读产物的\nprovenance.json——复核 数字员工OS/digital-employee-os/scripts/check-platform-dependency-provenance.mjs,\n其中 gitSha / sourceSha 的命中全部属于它自己报告的 provenance,没有一处读依赖产物。\n\n落点改为两条:① 平台侧把 sourceSha 这个字段名写进对外契约(发布物 schema / 接入套件文档),\n使消费者不必靠猜;旁路车另缺 tag(tag:null,与 CL-5「一次发布 = 一个 tag = 一组同版本包」不符),该项仍欠。\n② 基座侧把判据从「解析来源」扩到「内容出处」,只需读包内 sourceSha 与期望提交比对,不必等平台改任何东西。\n\n状态 🔴 → 🟡:不再与 U-39 同一阻塞,两侧都可立即动工,不受 G-12 计费阻塞;仅 tag:null 仍挂在旁路车上。\n原落点文字保留删除线,不抹掉审计痕迹。\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:05:19-07:00"},{"Sha1":"63850ac3b7b1a51d74aac689837fdf7ed58905bb","Message":"docs(回灌): U-39 补 contracts 同版本不同内容的新实例——落差由一个提交扩大到一整轮硬化\n\n@juhai/contracts@1.0.0-rc.3 与 client-fact 同属 2026-09-13 那趟本地旁路车。实查架上包:其\nprovenance.json 自证 sourceSha=036a308,而仓内同版本源码已含 2026-09-18 九个契约包域\n(public-file / IM / 跨域流程 / 通知 / 数据分析 / 成本容量 / 统一体验 / 注册中心 / 配置与功能开关)\n的失败关闭硬化。消费者 exact pin 1.0.0-rc.3 拿到的是硬化前代码;./domain/* 是公开子路径导出,\n失败一侧行为已变。U-39 的「同版本不同内容」因此不是 client-fact 一例。\n\n不另开 U 号:本实例由基础设施自查发现、没有上层对接方,不符合本台账 §0「只有业务应用的开发轮次\n触发回灌」的驱动方口径,故并入 U-39 状态格,不新设真源。\n\n证据取自一手产物:在仓内 npm 作用域下 npm pack 拉取架上 tarball,读其 provenance.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:03:44-07:00"},{"Sha1":"fad563310502477427181b6cbe2b48af4aebb668","Message":"docs(计划): 登记四份过期证据回绑与一次撤回 @ 772b253\n\nrelease-manifest / sbom / naming / fork-readiness 四份在干净检出内重跑回绑,结论逐项\n对照无劣化;sbom 的 ref 更新后它描述的才是当前登记的镜像。check:evidence 由\n36 新鲜 / 5 过期 变为 40 新鲜 / 1 过期 / 0 error,仅剩 image-smoke(须 Secret 到位后\n由 CI 插一步冒烟,带复核期 2026-10-31)。\n\n另记一次撤回:module-imports 那次回绑是多余的——并行会话提交门禁改动时已连报告一起\n回绑,它早已新鲜。教训是判据应为「这份报告现在是否被判过期」,而不是「作用域是否干净」。\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-18T15:47:52-07:00"},{"Sha1":"80eced637aa8796ffec9c266cde6d6567e4fdb49","Message":"docs(计划): 登记注册中心就绪闸门补判与干净检出回绑 @ 94366bc / de532d4\n\n并更正上一行登记:注册中心 9ac9914 已被 7f82399 的合并整体放弃,上一行现在只对\n统一体验 caefbf6 成立。远端那版的摘要归一化比本地那版的「一律拒」更好,本轮采纳\n其口径;只补它仍缺的四条就绪闸门真值判定,并把零覆盖的 snapshot-upgrade-review.ts\n接进夹具门禁。\n\n回绑改走 #34-A 立的干净检出路径:主工作区 4 小时没出现干净树。附带记下一条坑——\n检出必须落在工作区内,否则 workspaceRelative 套件会以 unavailable 让门禁 exit 1。\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-18T12:26:45-07:00"},{"Sha1":"1d2416ab6482cf2ad8f2e4c311c62545daebfd16","Message":"docs(计划): 登记统一体验与注册中心两个契约包入参硬化 @ caefbf6 / 9ac9914\n\n两域各有一条同形缺陷(闸门用真值判断,\"false\" 一律放行——统一体验是 G3 本身与\n权限 / Scope 判定,注册中心是四条就绪闸门)与各自的崩溃面;注册中心另有 blockedBy\n传字符串时 .length 是字符数、摘要正则带 i 导致同一制品两个身份两处。修的都是同一\n文件里正确写法本来就在的那种。顺带补两块零门禁覆盖:统一体验持闸的两个公开函数、\n注册中心整份 393 行的升级复核。九个契约包域至此全部补强,套件合计 188 例 0 失败。\n\n另回写一条技术教训:独立索引提交后必须 git reset -- \u003c路径\u003e 把共享索引刷回 HEAD,\n否则并行会话下一次从索引提交会把已提交的改动带回去(2026-09-18 已实际发生一次)。\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-18T07:53:53-07:00"}],"HeadCommit":{"Sha1":"9a8b716a056597786b9fcbc8fd57bff6c5b44722","Message":"docs(回灌): 订正 U-40——「gitSha 为空」不成立,字段叫 sourceSha 且有值,落点随之改向\n\nU-40 原文称 registry 上的 @juhai/client-fact@1.0.0-rc.3 其 provenance.json 为 gitSha:\"\" 空字符串,\n据此把落点定为「平台侧必须带真实 gitSha,本地旁路发布也不得留空」。一手实测推翻该前提:\n\n在真源仓 npm 作用域下 npm pack 拉取架上 tarball 读其 provenance.json,client-fact 与 contracts 的\nrc.3 两份一字不差,且都带 \"sourceSha\": \"036a308f27acf35a46f068c96fea7723ef74d05e\"。\n字段名是 sourceSha 不是 gitSha,且有真实值——提交号一直在包里。照原落点做,平台会去补一个已经存在的字段。\n\n本条结论仍成立、病因换了:不是「平台没写」,是两侧键名对不上,且基座判据根本没读产物的\nprovenance.json——复核 数字员工OS/digital-employee-os/scripts/check-platform-dependency-provenance.mjs,\n其中 gitSha / sourceSha 的命中全部属于它自己报告的 provenance,没有一处读依赖产物。\n\n落点改为两条:① 平台侧把 sourceSha 这个字段名写进对外契约(发布物 schema / 接入套件文档),\n使消费者不必靠猜;旁路车另缺 tag(tag:null,与 CL-5「一次发布 = 一个 tag = 一组同版本包」不符),该项仍欠。\n② 基座侧把判据从「解析来源」扩到「内容出处」,只需读包内 sourceSha 与期望提交比对,不必等平台改任何东西。\n\n状态 🔴 → 🟡:不再与 U-39 同一阻塞,两侧都可立即动工,不受 G-12 计费阻塞;仅 tag:null 仍挂在旁路车上。\n原落点文字保留删除线,不抹掉审计痕迹。\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:05:19-07:00"},"CompareURL":"luoanwu/platform-governance/compare/a7075e40e9aed8fbe69edb7fb7f0ebc05e477214...9a8b716a056597786b9fcbc8fd57bff6c5b44722","Len":6}...
|
1789772759
|
Edit
Delete
|
|
31173
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"52fe06641 {"Commits":[{"Sha1":"52fe066412543b57b729791de298ac0b5898b52b","Message":"docs(部署): D-8 裁决落地——dev 面配上现签令牌,并记下它当场被实证的代价\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:04:51-07:00"},{"Sha1":"bdb662d439cf7e24d8caef596c9ebf5d5e38b12d","Message":"test(contracts): 指标契约的门禁覆盖——34 个原因码只有 21 个在夹具上走过,G3 前运维绑定那条一片空白\n\n同日 daa226b 把崩溃面、枚举零校验与真值旗标收了。本轮只问一件事:这些判定门禁看得见几条。\n做法是把 34 个原因码逐条与夹具的实际产出比对——跑每个用例、收集真实返回值,不读代码推断。\n\n判定逻辑一行未改:metric-contract.ts 本轮零改动,只动夹具与测试。\n\n1. 12 条从未在门禁上走过,只有单测看着:CDC_CAPTURE_CONTRACT_REQUIRED、DIMENSION_ID_DUPLICATED、\n OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3,演进的五条不可变断言(METRIC_ID_CHANGED /\n METRIC_NAME_CHANGED / METRIC_OWNER_CHANGED / METRIC_SOURCE_CHANGED / EPISTEMIC_STATUS_CHANGED)、\n REFRESH_SLA_REGRESSION,以及六条基线旗标里的三条(FACT_OR_CDC / IDENTITY_SCOPE /\n DATA_CLASSIFICATION_BASELINE_NOT_READY)。其中 OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3 是本域最\n 靠近红线的一条——G3 前不得把 sql / dburl / outputTable 之类写进契约——门禁上此前一片空白。\n\n2. 1 条走到过但没人钉住:METRIC_CLASSIFICATION_TOO_LOW 由别的用例顺带产出,没有任何用例声明它,\n 改坏了门禁不会红。\n\n3. 反方向一条:REFRESH_SLA_INVALID 门禁有、单测没有,补进单测,连同「演进时 SLA 只能收紧」的正反向。\n\n覆盖:夹具 27 → 40 例(正 3 / 反 37),新增 N25—N37 十三例且每例只产出一条原因(逐例核过实际返回值,\n不靠门禁的前缀包含蒙混);定向测试 25 → 27 例;原因码门禁覆盖 21/34 → 34/34。上一轮用例一条未改。\n\n另跑一遍夹具变异探针(40 例的真实 payload,逐个叶子字段换 14 种脏值,走 evaluateFixturePayload 入口):\n13552 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做(越界):采集、语义层、查询 API 一件未建,C17 按缺失模块完善清单仍是「裁决」;Catalog 登记未动。\n\n证据:pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 390/390、contract-data-analytics 夹具 40/40 失败 0。\n负向实测:把 N27 的声明原因改成 METRIC_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n(reasons=[\"OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3\"]),还原后 exit 0。\n工作树另有并行会话在跑全链门禁,故本次不回绑任何 reports/。\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:04:20-07:00"},{"Sha1":"d860eb62560ba66297681a63c1466cf47c40d12f","Message":"test(contracts): 注册中心 upgrade 的证据链可信度——13 条原因码只有单测,门禁看不到\n\n前两轮补的是「请求缺字段」;这一轮是证据本身可不可信,它是九个契约包里唯一一处成规模的门禁空白。\n\n13 条分四组:\n 目标制品的身份四要素与来源工作树是否干净 5 条\n 兼容性证据是否通过 / 时间可解析 / 血缘对得上 3 条\n 影响面证据是否定稿 / 可计时 / 同源 3 条\n 复核时钟与候选状态 2 条\n\n其中 TARGET_SOURCE_MUST_BE_CLEAN 尤其要紧:目标制品自己声明是从脏工作树构建的,这类制品不该被\n采信——和本仓报告纪律是同一条(证据只能绑干净树),而门禁此前看不到这条路径。\nCOMPATIBILITY_EVIDENCE_LINEAGE_MISMATCH / IMPACT_EVIDENCE_LINEAGE_MISMATCH 同理:一份「通过了」\n但说的是别的版本、别的提交的证据,比没有证据更危险。\n\n补:夹具 32 → 41 例(N28–N36,九条用例覆盖 13 个原因,每条都是有语义的场景而不是单纯删字段),\n单测 53 → 59 例。本域「夹具无但单测有」由 23 降至 10,「哪里都没有」保持 0。\n\n负向实测:把 N29 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例,恢复后转绿。\n\n本条只补覆盖,没有改任何判定;snapshot-upgrade-review.ts 一行未动。\n全仓「夹具无但单测有」由 77 降至 64,其中约 15 条是各域基线闸门的登记位,按已知口径保留。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、定向 59/59、contract-application-contract-registry 41/41。\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:03:45-07:00"}],"HeadCommit":{"Sha1":"52fe066412543b57b729791de298ac0b5898b52b","Message":"docs(部署): D-8 裁决落地——dev 面配上现签令牌,并记下它当场被实证的代价\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:04:51-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/95b88d34fca66f4030640c2652d3171ecfb05b97...52fe066412543b57b729791de298ac0b5898b52b","Len":3}...
|
1789772730
|
Edit
Delete
|
|
31172
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/docs/registry-blueprint-record
|
0
|
{"Commits":[{"Sha1":"ba752059e {"Commits":[{"Sha1":"ba752059ee2e67443d3a4b9a1c023c80573bd584","Message":"docs(domain): 注册中心蓝图补记后三笔——第 4—6 条缺陷与现状证据此前不在蓝图里\n\n蓝图是 Catalog 给本模块登记的 evidence 之一,但它的「2026-09-18 规则加固」节只记了\n92a6b8e 那一笔:三条缺陷、数字停在单测 44 例 / 夹具 15 例(正 4 反 11)。同日的\n94366bc / 91216b5 / 5f3f608 没有在蓝图留下任何痕迹,于是蓝图对本模块的描述既滞后\n又不完整。本条只补记录,不改任何规则与 Catalog。\n\n补进去的三条:\n- 第 4 条(94366bc):四条就绪闸门写作 !context.x,传 \"false\" / 1 / \"no\" / {} 一律\n 判为已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW;现改为 !== true,与同文件本来\n 就严格的 sourceWorktreeDirty !== false 对齐。92a6b8e 只收了入参形状,漏了这四个布尔位。\n- 第 5 条(94366bc + 91216b5):snapshot-upgrade-review.ts 这 393 行在夹具评估器上零\n 覆盖(规则只有 snapshot / transition / plan),而第 4 条的闸门正在这里;补 upgrade\n 规则后按变异重算 snapshot / transition 侧覆盖,24 个分支里仍有 12 个没有用例走到,\n 再补 N17—N20 到 24/24。\n- 第 6 条(5f3f608):upgrade 侧接进门禁后 6 个用例全对着四条就绪闸门,闸门下面那层\n 请求校验有 15 条原因码哪里都没有(两个 pin 的锁定四要素与消费者归属 10、目标制品\n schemaApiVersion 与 linter 证据 2、影响面清单比对 3);补 N21—N27 后归 0。\n\n逐笔证据按各自当时的口径分列,不混成一句。另新增两段:「现状」给本节写定时 clean 树\n上的实跑值;「注意别引错证据」写明 reports/fixtures.latest.json 此刻仍绑 7523bd0、\n本套件记 25 例,5f3f608 之后未回绑,check:evidence 判 EVIDENCE_STALE——现状那行目前\n只有本地实跑支撑,引机器证据前须先重跑回绑。\n\n核验(本分支 clean 树,rebase 到 main 之后):单测 53/53;check:fixtures 本套件 32 例\n(正 5 / 反 27)0 失败;check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写逐字一致(绑定 7523bd0 之后作用域内 3 个文件变更);Catalog 四字段与六条 blockers\n逐项核对;runtime/modules/ 下确无本模块;相对链接 ../缺失模块完善清单-2026-09-16.md 可解析;\n表格 8 行各 4 列。\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-18T15:58:17-07:00"},{"Sha1":"95b88d34fca66f4030640c2652d3171ecfb05b97","Message":"docs(治理): 记录 2026-09-18 镜像同步被分支保护拒绝——顺带是 G14 缺的半份远端拦截实证\n\ngit push github HEAD:main 被 GH006 拒绝:required check\n\"Release candidate verification + manifest\" 缺失。推之前核过是纯快进(github/main\n是本地 HEAD 的祖先,落差 237 个提交,零分叉、无需 force),所以拒绝不是分叉造成的。\n\n记下三件事:① 分支保护配置快照(enforce_admins=true,对管理员生效;\nallow_force_pushes=false),这是本仓少数几处真正生效的远端拦截;② 该 check 产不出来的\n病因是 Actions 计费付款失败——最近三次 run 的失败 job 起止相差 2 秒且无日志,runner\n从未领取;③ 推之前用 merge-tree 试算的 8 条 base=main 的 PR 影响(6 条会翻成冲突),\n留档说明当前「20 条全 MERGEABLE」是镜像落后造成的假象。\n\n明写这份证据的边界:本次被拒的原因是 check 缺失,不是 check 判红,所以只能支撑\n「远端存在拦截」,不能支撑「远端拦截有效」——G14 的受控失败 PR 仍未做,不得标 GREEN。\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:02:20-07:00"},{"Sha1":"1a1b37e4669cfd80f87650050894fede8aee6b90","Message":"test(contracts): 会话准入 planner 的门禁覆盖——20 个可达出口只有 1 个走过,ADMIT 与 SKIP_DUPLICATE 还是同一个结果\n\n同日第一条(5720165)把判定收紧了,但门禁看不到其中绝大部分。对 dist 逐条实测:\nplan() 有 20 个可达出口,check:fixtures 上只走过 1 个(N06 无策略即拒),整张租户策略矩阵\n与 appendRejections 全部 8 行映射都只有单测看着,其中四个出口连单测也没有。\n\n本次判定逻辑一行未改——conversation-message.ts 与 conversation-admission-planner.ts 零改动,\n只动 fixture-evaluator.ts 的可见性,加用例。\n\n1. ADMIT 与 SKIP_DUPLICATE 在夹具里是同一个结果。评估器 plan 分支的判据是 `\"reasons\" in r`,\n 两者都没有 reasons,于是都返回空数组 = ACCEPT。把 ADMIT 全改写成 SKIP_DUPLICATE(或反过来)\n 门禁不会红,而这两者的区别正是「这条消息要不要真的落账」。同一文件里的 append 规则本来就写成\n 「只有 APPEND 算放行」,plan 现在与之同口径:非 ADMIT 即列出出口名。\n\n2. refresh() 在门禁上零覆盖(与公共文件 793d0a1 同形)。planner 三个公开方法里它是唯一没有夹具\n 规则的,版本回退拒绝与坏快照保留 last-known-good 此前只有单测。新增 refresh 规则:\n applied=true 为放行,否则返回 planner 自己给的 reason。\n\n3. 四个出口此前任何地方都没走过,均补单测:TENANT_NOT_ALLOWED(策略里根本没有这个租户,与\n 「请求跨租户」不是一回事)、CONVERSATION_TYPE_NOT_ALLOWED、SENDER_TYPE_NOT_ALLOWED(凭据与\n 发送者类型配套、策略仍不允许该类型,须与 ACTOR_CREDENTIAL_MISMATCH 分开证明)、\n CONVERSATION_TENANT_MISMATCH(映射表把 classify 的 TENANT_MISMATCH 换成 planner 自己的码)。\n\n覆盖:夹具 14 例(正 2 / 反 12)→ 39 例(正 4 / 反 35);定向测试 23 → 30 例,第一轮的断言一条未动。\n并给此前只断言「拒绝」的 N05 / N06 补上 reasons 声明。plan 与 refresh 各留一例放行(P03 / P04)——\n只有放行一侧也钉住,SKIP_DUPLICATE 与 applied 的区分才有意义。\n\n一处明写不覆盖:appendRejections 的 REJECT → MESSAGE_APPEND_INVALID 按当前控制流不可达——\nclassifyConversationAppend 只在 preflight 失败时返回 REJECT,而 plan() 更早就返回了 preflight 拒绝。\n保留该行作纵深防御,但不造用例假装覆盖,理由写进夹具 description 与蓝图。\n\n未做(越界):会话 / 成员 / 消息账本、长连接服务、Fact、独立运行服务一件未建,C16 按缺失模块完善清单\n仍卡在「裁决 · 实现」(Owner ADR、三消费者、G4);Catalog 登记一律未动。\n\n证据:真实工作树 pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas\n无漂移、node --test contracts/test/*.test.mjs 382/382、contract-collaboration-messaging 夹具 39/39。\n负向实测两次:把 N19 的声明原因改成 ACTOR_CREDENTIAL_MISMATCH → 门禁 exit 1 并点名该例\n(reasons=[\"SENDER_TYPE_NOT_ALLOWED\"]);把 N13 的 expect 翻成 ACCEPT → 被 id/expect 一致性规则\n先挡下(exit 1)。两次还原后 exit 0。本次不回绑任何 reports/。\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:01:18-07:00"},{"Sha1":"ffdd21a2ae238023f2bb48a632deaabade5e88f1","Message":"docs(发布): 按产物内 provenance 订正 rc.2 的源——eb3cf2c 是写记录时的 HEAD,发布实际在 6d3900a\n\nG-12 表格原记「源 eb3cf2c」。rc.2 三个 tarball 内的 provenance.json 各自独立却一致记为\n6d3900a:该文件由 publish-rc.mjs 在发布那一刻写入,三包互证,是一手证据。\n三份产物的 sha512 与 Registry 登记的 integrity 也逐一核对一致,确认读的是架上那三个包。\n\neb3cf2c(21:26:55)与 6d3900a(21:42:24)相隔 15 分钟,其间只有一个纯文档提交\n(docs(ci),改 stack/ci/act-runner/README.md)——**未触及三个发布包**。\n所以两个源产出的包字节完全相同,provenance.sourceSha 是唯一能区分的证据;\n产物本身不受影响,受影响的只是「从哪个提交发的」这条事实记录。\n\n上一条提交里「不擅改、留给执行者确认」的处置随之改为已订正,三处同步:\nG-12 表格、G-12「补记时一并发现的两处偏离」第 2 条、CLAUDE.md 的 contracts 条目。\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:00:24-07:00"},{"Sha1":"5f3f6084506e2a173759f07f882713ffdd4111ae","Message":"test(contracts): 注册中心 upgrade 的请求体检面——15 条原因码只有实现没有用例\n\n同日「注册中心入参体检的门禁覆盖」补的是 snapshot / transition 两条规则;按同一口径把 upgrade 也算了\n一遍,15 条「哪里都没有」,全部在四条就绪闸门下面那层请求校验:\n\n 两个 pin 的锁定四要素(snapshotVersion / snapshotDigest / sourceCommit / lockMode=exact_digest)\n 与消费者归属 10 条\n 目标制品的 schemaApiVersion 与 linter 证据 2 条\n 影响面的受影响清单、已确认清单与消费者归属比对 3 条\n\n此前 6 个 upgrade 用例全部对着四条就绪闸门(independentGitSourceReady 等各一条真值用例,那部分做得\n完整)。闸门开了之后请求本身长什么样,门禁不看——这 15 条删掉不会红。我今天早些时候说「upgrade 那半边\n做得很扎实」是说窄了:说的是闸门,不是闸门下面的请求面。\n\n补:夹具 25 → 32 例(N21–N27),单测 49 → 53 例。成组声明是有意的——门禁要求声明的原因逐条出现,\n所以一条用例同时钉住四要素,比四条各钉一条更严。补后重算:本域「哪里都没有」归 0。\n\n负向实测:给 N21 加一条不会产生的声明原因 → 门禁 exit 1 并点名该例,恢复后转绿。\n\n本条只补覆盖,没有改任何判定;snapshot-upgrade-review.ts 一行未动。\n九个契约包至此「哪里都没有」全部归零。\n\n证据:在仅含本提交改动的导出树上 tsc 绿、定向 53/53、contract-application-contract-registry 32/32。\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-18T15:59:45-07:00"}],"HeadCommit":{"Sha1":"ba752059ee2e67443d3a4b9a1c023c80573bd584","Message":"docs(domain): 注册中心蓝图补记后三笔——第 4—6 条缺陷与现状证据此前不在蓝图里\n\n蓝图是 Catalog 给本模块登记的 evidence 之一,但它的「2026-09-18 规则加固」节只记了\n92a6b8e 那一笔:三条缺陷、数字停在单测 44 例 / 夹具 15 例(正 4 反 11)。同日的\n94366bc / 91216b5 / 5f3f608 没有在蓝图留下任何痕迹,于是蓝图对本模块的描述既滞后\n又不完整。本条只补记录,不改任何规则与 Catalog。\n\n补进去的三条:\n- 第 4 条(94366bc):四条就绪闸门写作 !context.x,传 \"false\" / 1 / \"no\" / {} 一律\n 判为已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW;现改为 !== true,与同文件本来\n 就严格的 sourceWorktreeDirty !== false 对齐。92a6b8e 只收了入参形状,漏了这四个布尔位。\n- 第 5 条(94366bc + 91216b5):snapshot-upgrade-review.ts 这 393 行在夹具评估器上零\n 覆盖(规则只有 snapshot / transition / plan),而第 4 条的闸门正在这里;补 upgrade\n 规则后按变异重算 snapshot / transition 侧覆盖,24 个分支里仍有 12 个没有用例走到,\n 再补 N17—N20 到 24/24。\n- 第 6 条(5f3f608):upgrade 侧接进门禁后 6 个用例全对着四条就绪闸门,闸门下面那层\n 请求校验有 15 条原因码哪里都没有(两个 pin 的锁定四要素与消费者归属 10、目标制品\n schemaApiVersion 与 linter 证据 2、影响面清单比对 3);补 N21—N27 后归 0。\n\n逐笔证据按各自当时的口径分列,不混成一句。另新增两段:「现状」给本节写定时 clean 树\n上的实跑值;「注意别引错证据」写明 reports/fixtures.latest.json 此刻仍绑 7523bd0、\n本套件记 25 例,5f3f608 之后未回绑,check:evidence 判 EVIDENCE_STALE——现状那行目前\n只有本地实跑支撑,引机器证据前须先重跑回绑。\n\n核验(本分支 clean 树,rebase 到 main 之后):单测 53/53;check:fixtures 本套件 32 例\n(正 5 / 反 27)0 失败;check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写逐字一致(绑定 7523bd0 之后作用域内 3 个文件变更);Catalog 四字段与六条 blockers\n逐项核对;runtime/modules/ 下确无本模块;相对链接 ../缺失模块完善清单-2026-09-16.md 可解析;\n表格 8 行各 4 列。\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-18T15:58:17-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/fb755985cca612c5a0ab2a117213fb41689c6521...ba752059ee2e67443d3a4b9a1c023c80573bd584","Len":11}...
|
1789772601
|
Edit
Delete
|
|
31171
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"95b88d34f {"Commits":[{"Sha1":"95b88d34fca66f4030640c2652d3171ecfb05b97","Message":"docs(治理): 记录 2026-09-18 镜像同步被分支保护拒绝——顺带是 G14 缺的半份远端拦截实证\n\ngit push github HEAD:main 被 GH006 拒绝:required check\n\"Release candidate verification + manifest\" 缺失。推之前核过是纯快进(github/main\n是本地 HEAD 的祖先,落差 237 个提交,零分叉、无需 force),所以拒绝不是分叉造成的。\n\n记下三件事:① 分支保护配置快照(enforce_admins=true,对管理员生效;\nallow_force_pushes=false),这是本仓少数几处真正生效的远端拦截;② 该 check 产不出来的\n病因是 Actions 计费付款失败——最近三次 run 的失败 job 起止相差 2 秒且无日志,runner\n从未领取;③ 推之前用 merge-tree 试算的 8 条 base=main 的 PR 影响(6 条会翻成冲突),\n留档说明当前「20 条全 MERGEABLE」是镜像落后造成的假象。\n\n明写这份证据的边界:本次被拒的原因是 check 缺失,不是 check 判红,所以只能支撑\n「远端存在拦截」,不能支撑「远端拦截有效」——G14 的受控失败 PR 仍未做,不得标 GREEN。\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:02:20-07:00"}],"HeadCommit":{"Sha1":"95b88d34fca66f4030640c2652d3171ecfb05b97","Message":"docs(治理): 记录 2026-09-18 镜像同步被分支保护拒绝——顺带是 G14 缺的半份远端拦截实证\n\ngit push github HEAD:main 被 GH006 拒绝:required check\n\"Release candidate verification + manifest\" 缺失。推之前核过是纯快进(github/main\n是本地 HEAD 的祖先,落差 237 个提交,零分叉、无需 force),所以拒绝不是分叉造成的。\n\n记下三件事:① 分支保护配置快照(enforce_admins=true,对管理员生效;\nallow_force_pushes=false),这是本仓少数几处真正生效的远端拦截;② 该 check 产不出来的\n病因是 Actions 计费付款失败——最近三次 run 的失败 job 起止相差 2 秒且无日志,runner\n从未领取;③ 推之前用 merge-tree 试算的 8 条 base=main 的 PR 影响(6 条会翻成冲突),\n留档说明当前「20 条全 MERGEABLE」是镜像落后造成的假象。\n\n明写这份证据的边界:本次被拒的原因是 check 缺失,不是 check 判红,所以只能支撑\n「远端存在拦截」,不能支撑「远端拦截有效」——G14 的受控失败 PR 仍未做,不得标 GREEN。\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:02:20-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/1a1b37e4669cfd80f87650050894fede8aee6b90...95b88d34fca66f4030640c2652d3171ecfb05b97","Len":1}...
|
1789772550
|
Edit
Delete
|