|
30701
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"7f5b2e680 {"Commits":[{"Sha1":"7f5b2e680072ff3c40ad39617334e9d268d49e14","Message":"docs(计划): 开发计划状态格同步 OPS-1——条件 A 仓内满足、交付阶段 ② 可开工\n\n精简改版落盘后并行会话实现了 OPS-1 受控执行面(真源仓 6378b6f + 回绑\n1ccb3b6),只补了 §8 一行,状态格仍写「条件 A 部分满足」。按机器证据同步:\n\n- 头部与 §1 标题:真源仓 HEAD 7ca5952 → 361a0e4(报告绑 1ccb3b6)\n- §1 仓与远端:工作树 clean、origin 1ccb3b6、GitHub 落后 116、41 条未合分支\n- §1 模块:M3 增受控运维运行时 permission-ops.ts(operationId 幂等键 + outbox 中继)\n- §1 证据新鲜度:26 新鲜 / 9 过期 warn / 1 豁免 @ 6378b6f\n- §1 工作台:受控执行面四条路径与验收计数,controlled_operations 转 recorded\n- §2 交付五步、§2A 交付 ② 判定:条件 A / D / E 均解除,判定补目标环境部分\n- §3A:OPS 组归入已完成,删去「OPS-3 第一条」开放行,余四操作与 OPS-4—6\n 前置改写,WB-1 前置清空\n- §4 M3 行、§5 ④、§7 两远端与并行会话两条风险\n\n未改证据口径,未改机器 Catalog。L4 / L10 / L13 CLEAN,全量门禁基线仍为\nL8 / L9 / L12 三条既有项;治理层 workspace-consistency 测试 35/35。\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-17T16:03:26-07:00"}],"HeadCommit":{"Sha1":"7f5b2e680072ff3c40ad39617334e9d268d49e14","Message":"docs(计划): 开发计划状态格同步 OPS-1——条件 A 仓内满足、交付阶段 ② 可开工\n\n精简改版落盘后并行会话实现了 OPS-1 受控执行面(真源仓 6378b6f + 回绑\n1ccb3b6),只补了 §8 一行,状态格仍写「条件 A 部分满足」。按机器证据同步:\n\n- 头部与 §1 标题:真源仓 HEAD 7ca5952 → 361a0e4(报告绑 1ccb3b6)\n- §1 仓与远端:工作树 clean、origin 1ccb3b6、GitHub 落后 116、41 条未合分支\n- §1 模块:M3 增受控运维运行时 permission-ops.ts(operationId 幂等键 + outbox 中继)\n- §1 证据新鲜度:26 新鲜 / 9 过期 warn / 1 豁免 @ 6378b6f\n- §1 工作台:受控执行面四条路径与验收计数,controlled_operations 转 recorded\n- §2 交付五步、§2A 交付 ② 判定:条件 A / D / E 均解除,判定补目标环境部分\n- §3A:OPS 组归入已完成,删去「OPS-3 第一条」开放行,余四操作与 OPS-4—6\n 前置改写,WB-1 前置清空\n- §4 M3 行、§5 ④、§7 两远端与并行会话两条风险\n\n未改证据口径,未改机器 Catalog。L4 / L10 / L13 CLEAN,全量门禁基线仍为\nL8 / L9 / L12 三条既有项;治理层 workspace-consistency 测试 35/35。\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-17T16:03:26-07:00"},"CompareURL":"luoanwu/platform-governance/compare/deae8475189dc2fbb2efb54b2f1f8ddccef56bf6...7f5b2e680072ff3c40ad39617334e9d268d49e14","Len":1}...
|
1789686326
|
Edit
Delete
|
|
30702
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"589467ea0 {"Commits":[{"Sha1":"589467ea0debc370a8800dc05cd744af7360cbbd","Message":"docs(计划): 开发计划梳理 09-14 标为已被取代——排序职责移交开发计划 §5\n\n开发计划 §5 于 2026-09-17 按阻塞链重排后,09-14 梳理成了第二份「现行领取\n表」,而它的完成判据自 09-15 起没再更新。逐条复核后确认大部分已被 09-16\n决策批次与 09-17 各 CHG 取代:\n\n- 统一审计 blockers 4 → 1(只余 ASSET_EVIDENCE_REVIEW_REQUIRED)\n- catalog:drift 的 drift 4 → 0(error 0 / info 5)\n- DEC-033—036 由 pending 转 rejected(候选平台随 CHG-015 撤销)\n- 派生仓 13 冻结仓 retirable 0/13 → 18 retired + 1 missing,active 0\n- 冻结副本已于 09-16 物理移除(PF-04 阶段 2 / CHG-013)\n- 阶段 B 的 B1/B2/B5 与阶段 C 的登记链均已签署或应用\n\n据此在其头部加状态段:声明不再是现行领取顺序、指向开发计划 §5、逐条列出\n判据差异,并点明仍然有效的只有 E2 的资产证据与 E7 ③。它仍是现行文档(被\n30 余处文档与脚本引用),故门禁例外保留,只把 workspace-consistency-core\n的理由注释与对应测试名从「现行领取表」改为「现行文档」,断言不动。\n\nL4 / L10 / L13 CLEAN;全量门禁基线仍为 L8 / L9 / L12 三条既有项;\nworkspace-consistency 测试 35/35。\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-17T16:08:19-07:00"}],"HeadCommit":{"Sha1":"589467ea0debc370a8800dc05cd744af7360cbbd","Message":"docs(计划): 开发计划梳理 09-14 标为已被取代——排序职责移交开发计划 §5\n\n开发计划 §5 于 2026-09-17 按阻塞链重排后,09-14 梳理成了第二份「现行领取\n表」,而它的完成判据自 09-15 起没再更新。逐条复核后确认大部分已被 09-16\n决策批次与 09-17 各 CHG 取代:\n\n- 统一审计 blockers 4 → 1(只余 ASSET_EVIDENCE_REVIEW_REQUIRED)\n- catalog:drift 的 drift 4 → 0(error 0 / info 5)\n- DEC-033—036 由 pending 转 rejected(候选平台随 CHG-015 撤销)\n- 派生仓 13 冻结仓 retirable 0/13 → 18 retired + 1 missing,active 0\n- 冻结副本已于 09-16 物理移除(PF-04 阶段 2 / CHG-013)\n- 阶段 B 的 B1/B2/B5 与阶段 C 的登记链均已签署或应用\n\n据此在其头部加状态段:声明不再是现行领取顺序、指向开发计划 §5、逐条列出\n判据差异,并点明仍然有效的只有 E2 的资产证据与 E7 ③。它仍是现行文档(被\n30 余处文档与脚本引用),故门禁例外保留,只把 workspace-consistency-core\n的理由注释与对应测试名从「现行领取表」改为「现行文档」,断言不动。\n\nL4 / L10 / L13 CLEAN;全量门禁基线仍为 L8 / L9 / L12 三条既有项;\nworkspace-consistency 测试 35/35。\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-17T16:08:19-07:00"},"CompareURL":"luoanwu/platform-governance/compare/7f5b2e680072ff3c40ad39617334e9d268d49e14...589467ea0debc370a8800dc05cd744af7360cbbd","Len":1}...
|
1789686509
|
Edit
Delete
|
|
30703
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ce042782a {"Commits":[{"Sha1":"ce042782a285d1d8a79e5c5a43636ea05f4868d3","Message":"feat(governance): 新增 check-deferred-ops 门禁——变更包延后 op 与活跃 Catalog 对账,并收口两条实际存在的坑\n\n起因:CHG-003 与 CHG-006 对同一条目同一字段(application-contract-registry.code_truth)各留一条 applyAfter op 且目标值不同,后者已由 CHG-013 于 2026-09-16 应用;delta 文件之间从不互相校验,谁按「把剩余延后 op 补完」执行,就会把已生效值回归成更粗的路径,且没有任何门禁会红。\n\n门禁(D1—D6,阻断性,进 run-foundation-gates)把每条 op 按 aspect(set 逐字段 + add_evidence 子集)与活跃 Catalog 对账:全部生效须登记 appliedBy、半生效须用 appliedBy.aspects 写明已落的一半、被取代须登记 withdrawn(缺 reason/authority/recordedAt 即红)、凭声明当已应用即红。11 例单测含逐规则负向;IO 层在真实材料与真实 Catalog 上跑。负向实测:去掉 withdrawn 即 exit 1。\n\n随之收口三处:\n- CHG-003 注册中心那条登记 withdrawn(依据决策批次 A-2 附条件),enterprise-idp 那条登记 appliedBy.aspects=[\"code_truth\"]——它是半应用,set 由 PF-07 阶段 1 实现提交 99c3f52(2026-09-12)直接改到位、三条 add_evidence 从未落;CHG-006 那条登记 appliedBy(CHG-013)。\n- check-new-platform-catalog-change-readiness 的 expectedFormalWithdrawn 收窄:原先连 decisions 总数与 pendingDecisions 一起钉死,而那两个数不是「撤销」决定的——CHG-002 按 A-2 登记 DEC-037—039 为 pending 后(36→39 / 0→3)该门禁与撤销无关地恒红。改为只断言撤销真正决定的项目数(21 / 19),四项不在册与四条 DEC rejected 由原有两个循环逐项断言(比总数更强)。八条自带负向用例仍全绿。\n- simulate-chg-007 在包已应用后不再因 tests.delta 锚点漂移崩溃,如实报 status=already-applied(formalMutated 仍 false);护栏的冻结基线判定从钉死整行改为只认函数调用(004/005 加 --contracts=active 后那一行变成三元表达式,被误判成活跃基线)。\n\n治理层 365 例 358 通过,余 1 为报告登记数待本次报告入 git;阻断性门禁 10/10。开发计划 §8 的登记留到并行会话的在途编辑落地后补。\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-17T16:14:54-07:00"},{"Sha1":"001e9af9cc570b2adb4ccdec0df1277d9b243730","Message":"docs(计划): PF-03 ⑤ 部分收口,偏差 #11 关闭(真源仓 41ca988)\n\n- §3 PF-03 行:⑤ 由「未做」改为「部分收口」,余项明确为 README 与\n CHANGELOG(后者自称「基础框架的版本轴」),退出条件改为三份文档正文\n 均不含框架仓状态声明\n- §6:偏差 #11 移入已关闭一行,附回灌内容与两道门禁结果\n- §8:增一行记录本轮,含「报告未回绑及其原因」\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-17T16:14:50-07:00"}],"HeadCommit":{"Sha1":"ce042782a285d1d8a79e5c5a43636ea05f4868d3","Message":"feat(governance): 新增 check-deferred-ops 门禁——变更包延后 op 与活跃 Catalog 对账,并收口两条实际存在的坑\n\n起因:CHG-003 与 CHG-006 对同一条目同一字段(application-contract-registry.code_truth)各留一条 applyAfter op 且目标值不同,后者已由 CHG-013 于 2026-09-16 应用;delta 文件之间从不互相校验,谁按「把剩余延后 op 补完」执行,就会把已生效值回归成更粗的路径,且没有任何门禁会红。\n\n门禁(D1—D6,阻断性,进 run-foundation-gates)把每条 op 按 aspect(set 逐字段 + add_evidence 子集)与活跃 Catalog 对账:全部生效须登记 appliedBy、半生效须用 appliedBy.aspects 写明已落的一半、被取代须登记 withdrawn(缺 reason/authority/recordedAt 即红)、凭声明当已应用即红。11 例单测含逐规则负向;IO 层在真实材料与真实 Catalog 上跑。负向实测:去掉 withdrawn 即 exit 1。\n\n随之收口三处:\n- CHG-003 注册中心那条登记 withdrawn(依据决策批次 A-2 附条件),enterprise-idp 那条登记 appliedBy.aspects=[\"code_truth\"]——它是半应用,set 由 PF-07 阶段 1 实现提交 99c3f52(2026-09-12)直接改到位、三条 add_evidence 从未落;CHG-006 那条登记 appliedBy(CHG-013)。\n- check-new-platform-catalog-change-readiness 的 expectedFormalWithdrawn 收窄:原先连 decisions 总数与 pendingDecisions 一起钉死,而那两个数不是「撤销」决定的——CHG-002 按 A-2 登记 DEC-037—039 为 pending 后(36→39 / 0→3)该门禁与撤销无关地恒红。改为只断言撤销真正决定的项目数(21 / 19),四项不在册与四条 DEC rejected 由原有两个循环逐项断言(比总数更强)。八条自带负向用例仍全绿。\n- simulate-chg-007 在包已应用后不再因 tests.delta 锚点漂移崩溃,如实报 status=already-applied(formalMutated 仍 false);护栏的冻结基线判定从钉死整行改为只认函数调用(004/005 加 --contracts=active 后那一行变成三元表达式,被误判成活跃基线)。\n\n治理层 365 例 358 通过,余 1 为报告登记数待本次报告入 git;阻断性门禁 10/10。开发计划 §8 的登记留到并行会话的在途编辑落地后补。\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-17T16:14:54-07:00"},"CompareURL":"luoanwu/platform-governance/compare/589467ea0debc370a8800dc05cd744af7360cbbd...ce042782a285d1d8a79e5c5a43636ea05f4868d3","Len":2}...
|
1789686899
|
Edit
Delete
|
|
30707
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"06cdd6f0f {"Commits":[{"Sha1":"06cdd6f0fdfa799a55c0c78b11bdcb0601bcb0e7","Message":"chore(reports): 延后op 报告回绑 @ ce04278\n\n上一条提交里的报告绑的是其父提交;重跑后绑到真正包含 check-deferred-ops 的提交。8 条延后 op(已登记生效 2、已撤销 1)0 违规。\n\nworktreeDirty 仍为 true 且如实记录:工作树里有并行会话的在途文件(开发计划.md、workspace-consistency.test.mjs 与三份门禁运行产物),本会话无法在 clean 树上取证,故该报告只绑定本地工作区,不作为「clean 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-17T16:16:31-07:00"}],"HeadCommit":{"Sha1":"06cdd6f0fdfa799a55c0c78b11bdcb0601bcb0e7","Message":"chore(reports): 延后op 报告回绑 @ ce04278\n\n上一条提交里的报告绑的是其父提交;重跑后绑到真正包含 check-deferred-ops 的提交。8 条延后 op(已登记生效 2、已撤销 1)0 违规。\n\nworktreeDirty 仍为 true 且如实记录:工作树里有并行会话的在途文件(开发计划.md、workspace-consistency.test.mjs 与三份门禁运行产物),本会话无法在 clean 树上取证,故该报告只绑定本地工作区,不作为「clean 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-17T16:16:31-07:00"},"CompareURL":"luoanwu/platform-governance/compare/ce042782a285d1d8a79e5c5a43636ea05f4868d3...06cdd6f0fdfa799a55c0c78b11bdcb0601bcb0e7","Len":1}...
|
1789686993
|
Edit
Delete
|
|
30708
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"22f145c7c {"Commits":[{"Sha1":"22f145c7cc1d26ac35b6ce4781f2c36621c17de7","Message":"chore(reports): 门禁运行 / 门禁消费 / 统一审计 / 延后op 回绑 @ 06cdd6f(clean 树)\n\n并行会话的在途文件落地后工作树转干净(非报告类脏文件 0),重跑取 clean 绑定:阻断性门禁 10/10 通过(含新增 check-deferred-ops),仅记录 3 道(workspace-consistency 3 条既有 + domain-layer 13 条,均不参与总账);延后op 8 条 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-17T16:17:04-07:00"}],"HeadCommit":{"Sha1":"22f145c7cc1d26ac35b6ce4781f2c36621c17de7","Message":"chore(reports): 门禁运行 / 门禁消费 / 统一审计 / 延后op 回绑 @ 06cdd6f(clean 树)\n\n并行会话的在途文件落地后工作树转干净(非报告类脏文件 0),重跑取 clean 绑定:阻断性门禁 10/10 通过(含新增 check-deferred-ops),仅记录 3 道(workspace-consistency 3 条既有 + domain-layer 13 条,均不参与总账);延后op 8 条 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-17T16:17:04-07:00"},"CompareURL":"luoanwu/platform-governance/compare/06cdd6f0fdfa799a55c0c78b11bdcb0601bcb0e7...22f145c7cc1d26ac35b6ce4781f2c36621c17de7","Len":1}...
|
1789687026
|
Edit
Delete
|
|
30709
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"96dbcd998 {"Commits":[{"Sha1":"96dbcd998453ba6720203ea63ab612caa4d34687","Message":"chore(reports): 延后op 回绑 @ 17b81dd(clean 树,worktreeDirty=false)\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-17T16:17:30-07:00"},{"Sha1":"17b81dde8df1c9c426b95261a8d7c1ad60054bd2","Message":"fix(governance): check-deferred-ops 改用治理层统一 provenance 口径\n\n原先自己数 `git status --porcelain` 行数判 worktreeDirty,把本轮要覆盖的 latest 报告也算成脏文件——字段随即恒为 true,一个永远为真的 provenance 字段没有信息量,也与真源仓 governance/lib/provenance.mjs、治理层 report-provenance.mjs 的既有口径(忽略本轮生成的 latest 报告)不一致。改为复用 governanceProvenance,一并得到 repository / dirtyPaths。11 例单测不变全绿。\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-17T16:17:30-07:00"}],"HeadCommit":{"Sha1":"96dbcd998453ba6720203ea63ab612caa4d34687","Message":"chore(reports): 延后op 回绑 @ 17b81dd(clean 树,worktreeDirty=false)\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-17T16:17:30-07:00"},"CompareURL":"luoanwu/platform-governance/compare/22f145c7cc1d26ac35b6ce4781f2c36621c17de7...96dbcd998453ba6720203ea63ab612caa4d34687","Len":2}...
|
1789687054
|
Edit
Delete
|
|
30710
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"25751af08 {"Commits":[{"Sha1":"25751af083e566216e1803734573cfdb8184e65b","Message":"docs(开发计划): §8 补「延后 op 门禁与两处收口」一行\n\n登记 check-deferred-ops 的建立、它当场抓出的两个真问题(CHG-003/006 同条目冲突的延后 op、CHG-003 enterprise-idp 的半应用)与随之收口的两处恒红/崩溃。一致性检查 L4 / L10 / 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-17T16:17:51-07:00"}],"HeadCommit":{"Sha1":"25751af083e566216e1803734573cfdb8184e65b","Message":"docs(开发计划): §8 补「延后 op 门禁与两处收口」一行\n\n登记 check-deferred-ops 的建立、它当场抓出的两个真问题(CHG-003/006 同条目冲突的延后 op、CHG-003 enterprise-idp 的半应用)与随之收口的两处恒红/崩溃。一致性检查 L4 / L10 / 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-17T16:17:51-07:00"},"CompareURL":"luoanwu/platform-governance/compare/96dbcd998453ba6720203ea63ab612caa4d34687...25751af083e566216e1803734573cfdb8184e65b","Len":1}...
|
1789687075
|
Edit
Delete
|
|
30711
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"15bce0f4b {"Commits":[{"Sha1":"15bce0f4b672fc7456786bc61d493b3ffc04e630","Message":"docs(平台治理): 收纳表随新增门禁改数——scripts 48→50、tests 32→33、reports 324→325(顶层 39→40)\n\ncheck-deferred-ops.mjs 与 lib/deferred-ops-core.mjs、deferred-ops.test.mjs、延后op.latest.json 四个新文件没同步收纳表,上一条提交(25751af)因此把 L13 三条漂移推了出去。本次补齐,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-17T16:18:34-07:00"}],"HeadCommit":{"Sha1":"15bce0f4b672fc7456786bc61d493b3ffc04e630","Message":"docs(平台治理): 收纳表随新增门禁改数——scripts 48→50、tests 32→33、reports 324→325(顶层 39→40)\n\ncheck-deferred-ops.mjs 与 lib/deferred-ops-core.mjs、deferred-ops.test.mjs、延后op.latest.json 四个新文件没同步收纳表,上一条提交(25751af)因此把 L13 三条漂移推了出去。本次补齐,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-17T16:18:34-07:00"},"CompareURL":"luoanwu/platform-governance/compare/25751af083e566216e1803734573cfdb8184e65b...15bce0f4b672fc7456786bc61d493b3ffc04e630","Len":1}...
|
1789687118
|
Edit
Delete
|
|
30712
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a9e489b08 {"Commits":[{"Sha1":"a9e489b08d6d8dd510c9f63dd663b94037d5f9f4","Message":"docs(计划): PF-03 收口完成(真源仓 a084c5e,报告回绑 a7a19ec)\n\n- §3 PF-03 行改为「✅ 完成」,退出条件落为「三份文档均声明本目录身份与\n 版本轴归属、不含框架仓状态声明」\n- §5 ⑤ 移除已完成的「PF-03 ⑤ 文档回灌」\n- §8 增一行,含 check:evidence 仍 partial 的如实登记\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-17T16:19:27-07:00"}],"HeadCommit":{"Sha1":"a9e489b08d6d8dd510c9f63dd663b94037d5f9f4","Message":"docs(计划): PF-03 收口完成(真源仓 a084c5e,报告回绑 a7a19ec)\n\n- §3 PF-03 行改为「✅ 完成」,退出条件落为「三份文档均声明本目录身份与\n 版本轴归属、不含框架仓状态声明」\n- §5 ⑤ 移除已完成的「PF-03 ⑤ 文档回灌」\n- §8 增一行,含 check:evidence 仍 partial 的如实登记\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-17T16:19:27-07:00"},"CompareURL":"luoanwu/platform-governance/compare/15bce0f4b672fc7456786bc61d493b3ffc04e630...a9e489b08d6d8dd510c9f63dd663b94037d5f9f4","Len":1}...
|
1789687171
|
Edit
Delete
|
|
30714
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"cfaef2fc8 {"Commits":[{"Sha1":"cfaef2fc83837096a19a0d330b709017c0f322dd","Message":"docs(计划): 登记偏差 #34——脏树绑定判据与作用域判据不一致,卡住报告回绑\n\n领取「九条过期证据里 port-conformance 是唯一纯本机项」后核出的机制缺口。\n\ncheck-evidence-freshness 对未提交输入已按作用域判(EVIDENCE_WORKTREE_CHANGED\n只在脏文件落进该报告 scope 才报),但 EVIDENCE_BOUND_DIRTY 仍取\nprovenance.worktreeDirty 这个仓级布尔(provenance.mjs 由全仓 git status 算,\n只排除 latest 报告自身)。\n\n实锤:pnpm check:port-conformance 重跑 41/41 passed,当时唯一脏文件是并行\n会话在改的 governance/check-catalog-drift.mjs 及其测试,不在该报告作用域\n(runtime/{modules,clients,packages} + 检查器 + lockfile)内,报告仍写\nworktreeDirty=true;提交后树一转干净即被判 error。因此本轮没有提交这次回绑,\n九份过期证据仍是九份。\n\n§6 增 #34 并给三个处置选项(维持现状 / 作用域化 / 折中声明式),标明待平台\n负责人裁、裁决前不得放宽也不得把脏绑报告当证据提交;§8 增一行。\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-17T16:21:58-07:00"}],"HeadCommit":{"Sha1":"cfaef2fc83837096a19a0d330b709017c0f322dd","Message":"docs(计划): 登记偏差 #34——脏树绑定判据与作用域判据不一致,卡住报告回绑\n\n领取「九条过期证据里 port-conformance 是唯一纯本机项」后核出的机制缺口。\n\ncheck-evidence-freshness 对未提交输入已按作用域判(EVIDENCE_WORKTREE_CHANGED\n只在脏文件落进该报告 scope 才报),但 EVIDENCE_BOUND_DIRTY 仍取\nprovenance.worktreeDirty 这个仓级布尔(provenance.mjs 由全仓 git status 算,\n只排除 latest 报告自身)。\n\n实锤:pnpm check:port-conformance 重跑 41/41 passed,当时唯一脏文件是并行\n会话在改的 governance/check-catalog-drift.mjs 及其测试,不在该报告作用域\n(runtime/{modules,clients,packages} + 检查器 + lockfile)内,报告仍写\nworktreeDirty=true;提交后树一转干净即被判 error。因此本轮没有提交这次回绑,\n九份过期证据仍是九份。\n\n§6 增 #34 并给三个处置选项(维持现状 / 作用域化 / 折中声明式),标明待平台\n负责人裁、裁决前不得放宽也不得把脏绑报告当证据提交;§8 增一行。\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-17T16:21:58-07:00"},"CompareURL":"luoanwu/platform-governance/compare/a9e489b08d6d8dd510c9f63dd663b94037d5f9f4...cfaef2fc83837096a19a0d330b709017c0f322dd","Len":1}...
|
1789687322
|
Edit
Delete
|
|
30716
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"d991c4494 {"Commits":[{"Sha1":"d991c449457408aed0e9b98accb23feffdcc3d92","Message":"fix(governance): L8 补冻结物的显式豁免出口——审批记录条目写明,缺理由不放行\n\nL2 有 pragma 与 frozenInputs 两条出口,L8 一条也没有:冻结物改一字节即触发 L7 摘要不符,\n文件内的`一致性门禁豁免`标记对它无效,于是命中即永久噪声,与本门禁自己立的收敛原则\n(报出来的每一条都应当是能直接去改的)相反。\n\n出口改为由审批记录条目写明 consistencyExempt + consistencyExemptNote,缺 note 不放行;\n豁免以 frozenExempted 计数与 frozenExemptions 明细出现在 JSON 输出里,不静默。\n两个字段都不进 packageFingerprint(只取 path + sha256),登记前后指纹实测未变 1fdc2e1666c5。\n\n首条登记:新增基础应用MachineCatalog完整变更.patch。核验结论是误报——命中只 1 处、位于\ndiff 的上下文行(补丁并未引入),且处在一句陈述「旧断言写成了迁移双替换产物、等于没断言」的\n注释里,是对缺陷的描述而非被使用的路径。解除条件:变更包合并或撤回归档后随条目移除。\n\n验证:一致性门禁 3 → 2(余 L9 compose 撞名、L12 内核 pin 落后,均有既定归属);\ntests/workspace-consistency.test.mjs 35/35;变更包就绪门禁与评审门禁 exit 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-17T16:22:29-07:00"}],"HeadCommit":{"Sha1":"d991c449457408aed0e9b98accb23feffdcc3d92","Message":"fix(governance): L8 补冻结物的显式豁免出口——审批记录条目写明,缺理由不放行\n\nL2 有 pragma 与 frozenInputs 两条出口,L8 一条也没有:冻结物改一字节即触发 L7 摘要不符,\n文件内的`一致性门禁豁免`标记对它无效,于是命中即永久噪声,与本门禁自己立的收敛原则\n(报出来的每一条都应当是能直接去改的)相反。\n\n出口改为由审批记录条目写明 consistencyExempt + consistencyExemptNote,缺 note 不放行;\n豁免以 frozenExempted 计数与 frozenExemptions 明细出现在 JSON 输出里,不静默。\n两个字段都不进 packageFingerprint(只取 path + sha256),登记前后指纹实测未变 1fdc2e1666c5。\n\n首条登记:新增基础应用MachineCatalog完整变更.patch。核验结论是误报——命中只 1 处、位于\ndiff 的上下文行(补丁并未引入),且处在一句陈述「旧断言写成了迁移双替换产物、等于没断言」的\n注释里,是对缺陷的描述而非被使用的路径。解除条件:变更包合并或撤回归档后随条目移除。\n\n验证:一致性门禁 3 → 2(余 L9 compose 撞名、L12 内核 pin 落后,均有既定归属);\ntests/workspace-consistency.test.mjs 35/35;变更包就绪门禁与评审门禁 exit 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-17T16:22:29-07:00"},"CompareURL":"luoanwu/platform-governance/compare/cfaef2fc83837096a19a0d330b709017c0f322dd...d991c449457408aed0e9b98accb23feffdcc3d92","Len":1}...
|
1789687361
|
Edit
Delete
|
|
30717
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"bc850cd56 {"Commits":[{"Sha1":"bc850cd56895bf917bf6ec91b565f582e3dc601d","Message":"docs(决策): C-12 drift 升档已执行(真源仓 8382c04)\n\n决策批次 C-12 的两个前置(A-2 合并、drift 清零)均满足后执行升档:catalog:drift 的 error 与 drift 两档一律 exit 1,去掉从无调用方的 --strict 开关。逐条登记实况比原裁决所记更弱的那一点(此前连 error 都不阻断),并记 CLI 层四段负向。开发计划 §8 同步一行。\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-17T16:23:08-07:00"}],"HeadCommit":{"Sha1":"bc850cd56895bf917bf6ec91b565f582e3dc601d","Message":"docs(决策): C-12 drift 升档已执行(真源仓 8382c04)\n\n决策批次 C-12 的两个前置(A-2 合并、drift 清零)均满足后执行升档:catalog:drift 的 error 与 drift 两档一律 exit 1,去掉从无调用方的 --strict 开关。逐条登记实况比原裁决所记更弱的那一点(此前连 error 都不阻断),并记 CLI 层四段负向。开发计划 §8 同步一行。\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-17T16:23:08-07:00"},"CompareURL":"luoanwu/platform-governance/compare/d991c449457408aed0e9b98accb23feffdcc3d92...bc850cd56895bf917bf6ec91b565f582e3dc601d","Len":1}...
|
1789687392
|
Edit
Delete
|
|
30718
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"d5f1b641b {"Commits":[{"Sha1":"d5f1b641b05f0b3a351c8792b64d7215f3356d38","Message":"docs(计划): 偏差 #34 补第二个缺陷;登记 evidence-scopes 口径修正(真源仓 ac396a0)\n\nEVIDENCE_BOUND_DIRTY 读工作区里的报告文件,判定严重级所用的 currentTreeDirty\n却走 gitProvenance(),而后者显式排除 *.latest.json。并行会话正在跑门禁、只有\n报告文件脏时,门禁认定「当前树干净」,把 4 份尚未提交的在途报告判成 error 并\n输出「脏绑报告被提交了」——该断言在此情形下为假:那 4 份的 HEAD 版本干净绑定\n8382c04,只有工作区版本绑 bd625a1 + dirty。对比工作区版本与 HEAD 版本即可分辨,\n门禁不该断言它没有核实的事。两点同属一条规则,建议一并处置。\n\n§8 同时登记 evidence-scopes 口径说明补第五类(真源仓 ac396a0)。\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-17T16:25:08-07:00"}],"HeadCommit":{"Sha1":"d5f1b641b05f0b3a351c8792b64d7215f3356d38","Message":"docs(计划): 偏差 #34 补第二个缺陷;登记 evidence-scopes 口径修正(真源仓 ac396a0)\n\nEVIDENCE_BOUND_DIRTY 读工作区里的报告文件,判定严重级所用的 currentTreeDirty\n却走 gitProvenance(),而后者显式排除 *.latest.json。并行会话正在跑门禁、只有\n报告文件脏时,门禁认定「当前树干净」,把 4 份尚未提交的在途报告判成 error 并\n输出「脏绑报告被提交了」——该断言在此情形下为假:那 4 份的 HEAD 版本干净绑定\n8382c04,只有工作区版本绑 bd625a1 + dirty。对比工作区版本与 HEAD 版本即可分辨,\n门禁不该断言它没有核实的事。两点同属一条规则,建议一并处置。\n\n§8 同时登记 evidence-scopes 口径说明补第五类(真源仓 ac396a0)。\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-17T16:25:08-07:00"},"CompareURL":"luoanwu/platform-governance/compare/bc850cd56895bf917bf6ec91b565f582e3dc601d...d5f1b641b05f0b3a351c8792b64d7215f3356d38","Len":1}...
|
1789687511
|
Edit
Delete
|
|
30721
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1e0ea0813 {"Commits":[{"Sha1":"1e0ea08130bcbed848d075740bb4b5c44c1ffde4","Message":"chore(reports): 治理层门禁报告回绑 @ 6e0d7aa\n\n清树重跑 run-foundation-gates:阻断性 10/10 通过,仅记录 3\n(工作区一致性 2 条 L9 / L12、域分层 13 条,均不参与总账)。\n三份报告 worktreeDirty=false,绑定 6e0d7aa。\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-17T16:30:08-07:00"},{"Sha1":"6e0d7aa2570ce0046c8e1860044a8547f8567c23","Message":"docs(治理): L9 收口为「根因已闭、扩散无渠道」,登记 N-11 交派活\n\n核到底的结论是 L9 不该按「待修的缺陷」处理:\n\n- 模板根因早已关闭。框架 0.17.0(实现提交 313137b)给 compose 写了\n name: ${COMPOSE_PROJECT_NAME:-base-framework} 与 ${REDIS_PORT:-6379},\n F14 在框架 pnpm check 链里守全仓每一份 compose,scaffold-derived.mjs\n 派生时重绑身份,变更请求文首已记「已受理并落地」。enterprise-platform\n 两份 compose 也已带身份。新建仓不再扩散该缺陷。\n- 但扩散没有发生,且没有渠道可走。回灌台账 §3 第 8 条指定的\n 框架新版本同步计划自述「同步波次事实上已无目标」(18 个派生仓已退役),\n 它也从不覆盖上层应用仓。L9 当日实测仍有 8 个应用仓共用 project\n api-nestjs,且这 8 个仓自己的门禁一个都不报:5 个带 F14 之前的旧版\n check-fork-readiness.mjs(文件内 F14 零命中),3 个没有该脚本——\n 它们的 pnpm check 在冲突状态下仍是绿的。\n- 台账原话「在模板修好前,任何两个仓不得同时 docker compose up」的前提\n 已不成立而风险未变,按实际判据改述为「上列 8 个仓两两之间不得同时 up」。\n\n治理层按回灌边界「不代业务应用仓提交」,不自行下手,本轮只落记录:\nC-15 与 §3 第 8 条加订正(append-only,不改写原文),新登记待裁决 N-11\n交目录负责人三选一,并写明 0.17.0 的 F14 是破坏性变更——改 project 名后\n首次 up 会建新空卷,旧卷 api-nestjs_* 的开发数据不跟着走,这正是 N-09\n当时搁置同步的那一条,选任一路线都要先答共用卷里的数据归谁。\n\nL9 保持红,不降级。\n\n证据:治理层 365 例 0 失败、阻断性门禁 10/10;工作区一致性仍 2 条\n(L9 / L12),无新增断链与措辞违规。报告在脏树上产出,不随本提交,\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-17T16:29:41-07:00"}],"HeadCommit":{"Sha1":"1e0ea08130bcbed848d075740bb4b5c44c1ffde4","Message":"chore(reports): 治理层门禁报告回绑 @ 6e0d7aa\n\n清树重跑 run-foundation-gates:阻断性 10/10 通过,仅记录 3\n(工作区一致性 2 条 L9 / L12、域分层 13 条,均不参与总账)。\n三份报告 worktreeDirty=false,绑定 6e0d7aa。\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-17T16:30:08-07:00"},"CompareURL":"luoanwu/platform-governance/compare/d5f1b641b05f0b3a351c8792b64d7215f3356d38...1e0ea08130bcbed848d075740bb4b5c44c1ffde4","Len":2}...
|
1789687811
|
Edit
Delete
|
|
30722
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1645e7288 {"Commits":[{"Sha1":"1645e7288b484ab39a4e3ebb2da44678e9b9e300","Message":"docs(计划): 偏差 #34 已裁决并实现,移入已关闭(真源仓 e5cc39f / 4b067cd)\n\n目录负责人 2026-09-17 裁决:\n- A「干净检出生成报告」:不放宽 worktreeDirty,改为 pnpm reports:rebind 在\n HEAD 开 git worktree 跑零依赖门禁、只带回干净绑定的报告\n- B「修正断言」:EVIDENCE_BOUND_DIRTY 按报告文件自身是否未提交区分,在途\n 产物降 info 并如实描述,已提交的脏绑仍 error\n\n§6 中 #34 由开放表移入已关闭一行并附实现与证据;§8 增一行记录裁决与实现细节\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-17T16:33:10-07:00"}],"HeadCommit":{"Sha1":"1645e7288b484ab39a4e3ebb2da44678e9b9e300","Message":"docs(计划): 偏差 #34 已裁决并实现,移入已关闭(真源仓 e5cc39f / 4b067cd)\n\n目录负责人 2026-09-17 裁决:\n- A「干净检出生成报告」:不放宽 worktreeDirty,改为 pnpm reports:rebind 在\n HEAD 开 git worktree 跑零依赖门禁、只带回干净绑定的报告\n- B「修正断言」:EVIDENCE_BOUND_DIRTY 按报告文件自身是否未提交区分,在途\n 产物降 info 并如实描述,已提交的脏绑仍 error\n\n§6 中 #34 由开放表移入已关闭一行并附实现与证据;§8 增一行记录裁决与实现细节\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-17T16:33:10-07:00"},"CompareURL":"luoanwu/platform-governance/compare/1e0ea08130bcbed848d075740bb4b5c44c1ffde4...1645e7288b484ab39a4e3ebb2da44678e9b9e300","Len":1}...
|
1789687994
|
Edit
Delete
|
|
30724
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"eca16cecb {"Commits":[{"Sha1":"eca16cecb1b0e54e66d69268589ffa59c2fe6eff","Message":"chore(reports): 治理层门禁报告回绑 @ 3ca6a19\n\n清树重跑 run-foundation-gates:阻断性 11/11 通过(check-domain-layer 首次\n以阻断位计入,基线口径 0 阻断),仅记录 2(工作区一致性 L9 / L12)。\n三份报告 worktreeDirty=false,绑定 3ca6a19。\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-17T16:37:02-07:00"},{"Sha1":"3ca6a19355e099d1643d6f03eeb59ae360011615","Message":"feat(governance): 域分层门禁转阻断位,按基线只拦新增\n\n查 L9 派活路径时撞见一条静音:门禁消费登记里 check-domain-layer 的接入\n条件写的是「D5(CHG-007 合并)与 D9(两份契约副本收敛)清零后转阻断位」,\n2026-09-17 实测 D5 = 0、D9 = 0——条件早已满足而无人察觉。\n\n根因:check-gate-consumption 的 G4 只断言 wireInWhen 非空,从不校验它是否\n已成立。该登记本是为治「门禁失败信号无人看」而建的,流外出口是它唯一的\n豁免口,而豁免口自己没有到期判据——用来防静音的机制在自己身上静音了。\n\n处置不能是直接翻阻断位:余下 13 条全在上层应用仓,治理层按回灌边界不代其\n提交,接入即恒红,而恒红正是该登记要治的病。原条件后半句「其余各条按\nOwner 各自的节奏消」已写明正确形态,只是从没人把它实现成基线。故:\n\n- 新增 域分层基线.json:13 条存量逐条具名 Owner 与复核期(D2 权威倒挂 3 ·\n D4 无事实出口 3 · D6 未装入基座 3 · D7 同版本分叉 1 · D10 已装内容不可\n 追溯 1 · D11 门禁零负向探针 2),来源登记指回台账 U-24 / U-32 / U-34 /\n U-36 与 §3 第 2 条。\n- 新增 scripts/lib/domain-layer-baseline.mjs:B1 新增 / B2 存量恶化 /\n B3 基线腐烂或缺 Owner / B4 过复核期,四类任一非空即阻断。B3 与 B4 守的是\n 基线自己——修好了必须删条目,过了复核期必须复核,否则基线会腐烂成豁免清单。\n- check-domain-layer 退出码改基线口径,--no-baseline 仍看未过滤的全量\n (13 条,退出 1);registry 里该条转 run-foundation-gates 阻断位。\n\n一处要点:棘轮只认单调变坏的量。D10 的 matched(命中源仓提交的文件数)与\nD11 的 probes(负向探针条数)都是越大越好,拿来当上限会把改进判成恶化、\n反过来把修复锁死;已在 findingCount 里排除并写明理由,现只有 D2 的 count\n做棘轮。这条有单测守着。\n\n顺带更正 check-workspace-consistency 那条已过期的基线文字:L8 已归零\n(并行会话登记了具名冻结豁免),L9 的「12 仓」按当日实测改为 8 个上层\n应用仓;其接入形态改写为照此先例走基线棘轮,不再用「全清零再接入」——\n否则又是一个可能长期悬空的流外出口。\n\n仍缺一道,已记台账 C-19:G4 至今不会因「wireInWhen 已成立」而判红,\n下一个流外出口还能同样悬空。\n\n证据:治理层 377 例 0 失败(新增 12 例负向)、阻断性门禁 11/11、\n工作区一致性仍 2 条(L9 / L12)。L13 当场抓出收纳表漂移,已随本提交改数\n(根文件 62→63、scripts 50→51、tests 33→34)。报告在脏树上产出,\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-17T16:36:39-07:00"}],"HeadCommit":{"Sha1":"eca16cecb1b0e54e66d69268589ffa59c2fe6eff","Message":"chore(reports): 治理层门禁报告回绑 @ 3ca6a19\n\n清树重跑 run-foundation-gates:阻断性 11/11 通过(check-domain-layer 首次\n以阻断位计入,基线口径 0 阻断),仅记录 2(工作区一致性 L9 / L12)。\n三份报告 worktreeDirty=false,绑定 3ca6a19。\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-17T16:37:02-07:00"},"CompareURL":"luoanwu/platform-governance/compare/1645e7288b484ab39a4e3ebb2da44678e9b9e300...eca16cecb1b0e54e66d69268589ffa59c2fe6eff","Len":2}...
|
1789688225
|
Edit
Delete
|
|
30725
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"693800cea {"Commits":[{"Sha1":"693800ceaf834b217a01466e19579af6a23925cf","Message":"chore(reports): 治理层门禁报告回绑 @ 87ec431\n\n清树重跑 run-foundation-gates:阻断性 11/11 通过,仅记录 2(工作区一致性\nL9 / L12)。三份报告 worktreeDirty=false,绑定 87ec431。\n\n(订正:本条信息初次写成「回绑 @ 9a5b3c0」,那是提交前预估的 SHA,实际\n实现提交是 87ec431。报告内容的绑定一直是对的,错的只是信息里的那串字。)\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-17T16:40:15-07:00"},{"Sha1":"87ec4315c77935405e16314c11789ddb6ae45e5a","Message":"feat(governance): G6 流外出口必须写复核期,缺失或过期即判红\n\n补上前一提交记为「仍缺一道」的缺口,不留登记而不建。\n\n根因:门禁消费登记的 G4 只断言 wireInWhen 非空,从不校验它是否已成立。\n流外出口是这份登记唯一的豁免口,而豁免口自己没有到期判据——用来防静音的\n机制在自己身上静音了。实锤就是前一提交处理的那条:check-domain-layer 的\n接入条件「D5 与 D9 清零」早已双双成立,G4 全绿,无人发现。\n\nG6 OUT_OF_FLOW_UNREVIEWED:流外条目必须写 conditionReviewBy(YYYY-MM-DD),\n缺失、格式不对或已过期即判红;当天不算过期;只对流外生效,阻断位条目每轮\n都在跑,不需要复核期。6 例负向覆盖这五种形态。\n\n守日期而不守条件是有意的:接入条件多半含人的判断(「框架同步波次扩散后」\n「再有派生仓开仓时」),机器判不了;能机器化的是「必须有人按期回来看一眼」。\n与同日落的域分层基线 B4 同形——缓期不是豁免。\n\n两条现存流外条目各自写了复核期与理由:\n- check-workspace-consistency 2026-10-31:L9 / L12 挂在活裁决 N-11 / C-14\n 上,六周内应有进展。\n- audit-platform-openings 2026-12-31:触发事件罕见,现存派生仓 0 个\n (派生仓状态.json 只剩 missing 1 + retired 18),不是六周尺度的事。\n\n台账 C-19 由「仍缺一道」改为已补,落点写明。\n\n证据:治理层 378 例 0 失败(新增 6 例负向)、阻断性门禁 11/11、\n工作区一致性仍 2 条(L9 / L12)。报告在脏树上产出,不随本提交。\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-17T16:40:01-07:00"}],"HeadCommit":{"Sha1":"693800ceaf834b217a01466e19579af6a23925cf","Message":"chore(reports): 治理层门禁报告回绑 @ 87ec431\n\n清树重跑 run-foundation-gates:阻断性 11/11 通过,仅记录 2(工作区一致性\nL9 / L12)。三份报告 worktreeDirty=false,绑定 87ec431。\n\n(订正:本条信息初次写成「回绑 @ 9a5b3c0」,那是提交前预估的 SHA,实际\n实现提交是 87ec431。报告内容的绑定一直是对的,错的只是信息里的那串字。)\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-17T16:40:15-07:00"},"CompareURL":"luoanwu/platform-governance/compare/eca16cecb1b0e54e66d69268589ffa59c2fe6eff...693800ceaf834b217a01466e19579af6a23925cf","Len":2}...
|
1789688425
|
Edit
Delete
|
|
30727
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"689e924f3 {"Commits":[{"Sha1":"689e924f3db984f90ee13c2e0dd1a0082a70c1d3","Message":"docs(计划): 过期证据 9 → 8 且 error 清零;§1 证据行按 f9cb195 重采\n\n偏差 #34 裁决落地后的首轮清理:port-conformance 重绑、runtime 静态链四份\n重绑(WB-1 使 runtime/apps 变动而落进作用域)、工作台两份快照经\npnpm reports:rebind 重绑。check:evidence 由 failed 转 partial(27/8/1,0 error)。\n余 8 份全部需真实环境重跑,已逐一点名。\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-17T18:22:48-07:00"}],"HeadCommit":{"Sha1":"689e924f3db984f90ee13c2e0dd1a0082a70c1d3","Message":"docs(计划): 过期证据 9 → 8 且 error 清零;§1 证据行按 f9cb195 重采\n\n偏差 #34 裁决落地后的首轮清理:port-conformance 重绑、runtime 静态链四份\n重绑(WB-1 使 runtime/apps 变动而落进作用域)、工作台两份快照经\npnpm reports:rebind 重绑。check:evidence 由 failed 转 partial(27/8/1,0 error)。\n余 8 份全部需真实环境重跑,已逐一点名。\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-17T18:22:48-07:00"},"CompareURL":"luoanwu/platform-governance/compare/693800ceaf834b217a01466e19579af6a23925cf...689e924f3db984f90ee13c2e0dd1a0082a70c1d3","Len":1}...
|
1789694571
|
Edit
Delete
|
|
30731
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"150e625ed {"Commits":[{"Sha1":"150e625ed2a33300a3bc051fd4e60fa6e76a7947","Message":"docs(计划): 真实环境八份证据重跑通过,证据零过期(真源仓 36e0423)\n\n§1 证据新鲜度行与运行/UI 证据行按 2026-09-18 实测重采;§8 增一行。\n\n重跑:runtime-acceptance 775(地板 652 → 775)、ui-acceptance 5、\nmainline-acceptance 四套件 11/17/19/18、mainline-restore 3 库逐库 SHA-256\n一致、revocation-sla、identity-ui 2。退役(目录负责人裁决):identity-http\n与 mainline-candidate-regression,两者仓内无生成脚本、永远无法重跑,结论\n已由自动化门禁覆盖。\n\ncheck:evidence:33 新鲜 / 0 过期 / 0 告警 / 1 例外。\n\n如实保留:invalidationPush 仍是 measured-with-harness-transport,生产传输\n未接线,不构成 MS-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-17T18:58:36-07:00"}],"HeadCommit":{"Sha1":"150e625ed2a33300a3bc051fd4e60fa6e76a7947","Message":"docs(计划): 真实环境八份证据重跑通过,证据零过期(真源仓 36e0423)\n\n§1 证据新鲜度行与运行/UI 证据行按 2026-09-18 实测重采;§8 增一行。\n\n重跑:runtime-acceptance 775(地板 652 → 775)、ui-acceptance 5、\nmainline-acceptance 四套件 11/17/19/18、mainline-restore 3 库逐库 SHA-256\n一致、revocation-sla、identity-ui 2。退役(目录负责人裁决):identity-http\n与 mainline-candidate-regression,两者仓内无生成脚本、永远无法重跑,结论\n已由自动化门禁覆盖。\n\ncheck:evidence:33 新鲜 / 0 过期 / 0 告警 / 1 例外。\n\n如实保留:invalidationPush 仍是 measured-with-harness-transport,生产传输\n未接线,不构成 MS-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-17T18:58:36-07:00"},"CompareURL":"luoanwu/platform-governance/compare/689e924f3db984f90ee13c2e0dd1a0082a70c1d3...150e625ed2a33300a3bc051fd4e60fa6e76a7947","Len":1}...
|
1789696719
|
Edit
Delete
|
|
30741
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a03bc2d77 {"Commits":[{"Sha1":"a03bc2d7789a81e0da6b79e51f2abb32fff2b906","Message":"docs(计划): stack-image-pins 退役,check:evidence 首次全绿(真源仓 a9fd6e8)\n\n第三份无生成脚本的手工记录按其例外自写的「倾向 ① 退役」执行。结论已由\nrelease-manifest 的 parseComposeImages 覆盖(同为 12 条 0 未锁,未锁进\nmissing,由真脚本产出自动保鲜)。evidence-scopes exceptions 自此为空。\n\n§1 证据行改为 passed(33 新鲜 / 0 过期 / 0 例外 / 0 告警);§8 增一行。\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-17T19:01:40-07:00"}],"HeadCommit":{"Sha1":"a03bc2d7789a81e0da6b79e51f2abb32fff2b906","Message":"docs(计划): stack-image-pins 退役,check:evidence 首次全绿(真源仓 a9fd6e8)\n\n第三份无生成脚本的手工记录按其例外自写的「倾向 ① 退役」执行。结论已由\nrelease-manifest 的 parseComposeImages 覆盖(同为 12 条 0 未锁,未锁进\nmissing,由真脚本产出自动保鲜)。evidence-scopes exceptions 自此为空。\n\n§1 证据行改为 passed(33 新鲜 / 0 过期 / 0 例外 / 0 告警);§8 增一行。\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-17T19:01:40-07:00"},"CompareURL":"luoanwu/platform-governance/compare/150e625ed2a33300a3bc051fd4e60fa6e76a7947...a03bc2d7789a81e0da6b79e51f2abb32fff2b906","Len":1}...
|
1789696904
|
Edit
Delete
|
|
30746
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"e81617fb8 {"Commits":[{"Sha1":"e81617fb827a3db190701bc33bca21cc14ce20c8","Message":"docs(计划): MS-4 判据输入纳入新鲜度监控;Manifest 缺项 4 → 6(真源仓 314c179)\n\nrelease-manifest / sbom / image-smoke / mainline-dev-deployment 此前被归为\n「没有 provenance.gitSha」,实为写了源 SHA 但平铺在顶层,check:evidence 只认\n嵌套形状。实锤危害:Manifest 绑 ac3683d 四天,其后结论输入改了 10 个文件,\n刷新后缺项 4 → 6,多出的 images.stack.* 未锁与 SBOM 不满足 D-2 两条都是真的\n——而 MS-4 的退出条件正是读这份 Manifest。\n\n§1 Release Manifest 行按刷新后的六项缺项重采;§1 证据行改为 35 份全新鲜;\n§8 增一行,含未做项与理由(image-smoke 待下次真实运行、mainline-dev-deployment\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-17T19:21:54-07:00"}],"HeadCommit":{"Sha1":"e81617fb827a3db190701bc33bca21cc14ce20c8","Message":"docs(计划): MS-4 判据输入纳入新鲜度监控;Manifest 缺项 4 → 6(真源仓 314c179)\n\nrelease-manifest / sbom / image-smoke / mainline-dev-deployment 此前被归为\n「没有 provenance.gitSha」,实为写了源 SHA 但平铺在顶层,check:evidence 只认\n嵌套形状。实锤危害:Manifest 绑 ac3683d 四天,其后结论输入改了 10 个文件,\n刷新后缺项 4 → 6,多出的 images.stack.* 未锁与 SBOM 不满足 D-2 两条都是真的\n——而 MS-4 的退出条件正是读这份 Manifest。\n\n§1 Release Manifest 行按刷新后的六项缺项重采;§1 证据行改为 35 份全新鲜;\n§8 增一行,含未做项与理由(image-smoke 待下次真实运行、mainline-dev-deployment\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-17T19:21:54-07:00"},"CompareURL":"luoanwu/platform-governance/compare/a03bc2d7789a81e0da6b79e51f2abb32fff2b906...e81617fb827a3db190701bc33bca21cc14ce20c8","Len":1}...
|
1789698116
|
Edit
Delete
|
|
30751
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ae6cf47e5 {"Commits":[{"Sha1":"ae6cf47e538de724c00c270f78ad014669585c8d","Message":"docs(计划): mainline-dev-deployment 退役,四份手工记录清零(真源仓 903f019)\n\n结论由 compose 的 redpanda 启用状态、四份更新的 runtime-up 记录与\ncheck:deployed 覆盖,三者都会自动保鲜;dev 栈此后已重建多轮,09-12 的\n快照早已不是当前事实。\n\n§1 证据行补第三步;§8 增一行。未登记 16 → 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-17T19:24:42-07:00"}],"HeadCommit":{"Sha1":"ae6cf47e538de724c00c270f78ad014669585c8d","Message":"docs(计划): mainline-dev-deployment 退役,四份手工记录清零(真源仓 903f019)\n\n结论由 compose 的 redpanda 启用状态、四份更新的 runtime-up 记录与\ncheck:deployed 覆盖,三者都会自动保鲜;dev 栈此后已重建多轮,09-12 的\n快照早已不是当前事实。\n\n§1 证据行补第三步;§8 增一行。未登记 16 → 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-17T19:24:42-07:00"},"CompareURL":"luoanwu/platform-governance/compare/e81617fb827a3db190701bc33bca21cc14ce20c8...ae6cf47e538de724c00c270f78ad014669585c8d","Len":1}...
|
1789698286
|
Edit
Delete
|
|
30776
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1b9402778 {"Commits":[{"Sha1":"1b940277848578801e16f969b874470ff90adce7","Message":"docs(治理): C-13 卷归属执行记录——备份 + 删卷已做,compose 半边未做\n\n决策批次 C-13 的附条件是「删卷前 dump 必须复验」,按字面执行:\n\n备份(/Users/hillao/AI产品/仓备份-2026-09-16/碰撞卷-C13/,24 MB)\n- 五个碰撞卷文件级 tar + 两个 PG 簇的 pg_dumpall,附 SHA256SUMS 与 README\n- 原卷全程 :ro,快照解到临时副本卷后在副本上起 PG 导出——在原卷上起 PG 会\n 触发 WAL 与恢复写入,而删不删当时尚未决定,不能先把它改了\n\n复验(不是「文件存在」)\n- 逻辑备份灌入全新空实例:4 库表数逐库一致,74 张表逐表 count(*) 零差异\n\n删除(核实确属历史遗留后)\n- 六个容器的工作目录全部指向迁移前旧布局,三条路径均已不存在,创建于\n 08-28—09-05;顺带清除一个漏网的同工程容器 api-nestjs-minio-init-1\n- 五卷 + 六容器清零,dev 常驻栈 13 容器未动、健康探针 200\n\n实测更正:api-nestjs_pgdata 占 47.8 MB 却是空簇(唯一库 0 张表),有数据的\n只有 enterprise-idp_pgdata(4 库 / 74 表 / ≈2088 行)。\n\n未做的半边:8 个上层应用仓的 compose 补顶层 name:,跨仓且待 N-11 裁决。\n因此 L9 仍报 1 条(它查 compose 声明,不是卷是否存在),C-14 抬内核 pin 的\n前置只部分满足——这一条同时写进了门禁消费登记,免得下次误读为「C-13 已完成」。\n\ncheck:gates 通过;gate-consumption 与 workspace-consistency 测试 46/46。\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-17T20:13:04-07:00"}],"HeadCommit":{"Sha1":"1b940277848578801e16f969b874470ff90adce7","Message":"docs(治理): C-13 卷归属执行记录——备份 + 删卷已做,compose 半边未做\n\n决策批次 C-13 的附条件是「删卷前 dump 必须复验」,按字面执行:\n\n备份(/Users/hillao/AI产品/仓备份-2026-09-16/碰撞卷-C13/,24 MB)\n- 五个碰撞卷文件级 tar + 两个 PG 簇的 pg_dumpall,附 SHA256SUMS 与 README\n- 原卷全程 :ro,快照解到临时副本卷后在副本上起 PG 导出——在原卷上起 PG 会\n 触发 WAL 与恢复写入,而删不删当时尚未决定,不能先把它改了\n\n复验(不是「文件存在」)\n- 逻辑备份灌入全新空实例:4 库表数逐库一致,74 张表逐表 count(*) 零差异\n\n删除(核实确属历史遗留后)\n- 六个容器的工作目录全部指向迁移前旧布局,三条路径均已不存在,创建于\n 08-28—09-05;顺带清除一个漏网的同工程容器 api-nestjs-minio-init-1\n- 五卷 + 六容器清零,dev 常驻栈 13 容器未动、健康探针 200\n\n实测更正:api-nestjs_pgdata 占 47.8 MB 却是空簇(唯一库 0 张表),有数据的\n只有 enterprise-idp_pgdata(4 库 / 74 表 / ≈2088 行)。\n\n未做的半边:8 个上层应用仓的 compose 补顶层 name:,跨仓且待 N-11 裁决。\n因此 L9 仍报 1 条(它查 compose 声明,不是卷是否存在),C-14 抬内核 pin 的\n前置只部分满足——这一条同时写进了门禁消费登记,免得下次误读为「C-13 已完成」。\n\ncheck:gates 通过;gate-consumption 与 workspace-consistency 测试 46/46。\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-17T20:13:04-07:00"},"CompareURL":"luoanwu/platform-governance/compare/ae6cf47e538de724c00c270f78ad014669585c8d...1b940277848578801e16f969b874470ff90adce7","Len":1}...
|
1789701193
|
Edit
Delete
|
|
30787
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"bc014de63 {"Commits":[{"Sha1":"bc014de63a169082ff81ff54e77012c5fda7e50f","Message":"docs(计划): 登记偏差 #35——C-14「抬内核 pin」的实际范围是框架同步 74 冲突\n\n按目录负责人指令动工后实测:裁决文本说的是抬 pin,机制成本是一次完整框架\n同步。已完整撤回,未提交任何 pin 改动、未做框架合并。\n\n做到哪一步:12 处 pin 全改 0.22.0,pnpm install 成功、锁文件更新、\ncheck:pins 通过、构建 17/17、类型检查 31/31 全过。\n\n卡在哪:F11(check:fork-readiness)要求 @juhai/kernel pin 必须等于本仓\npackage.json.version——框架版本轴 = 内核版本轴;仓版本又被 check:docs-truth\n的 changelog-version-matches-package 绑到 runtime/CHANGELOG.md。\n\n真实范围(migration:plan,以框架仓为源,只读):冲突 74(apps/api-nestjs 22、\napps/api-fastify 14、apps/web 8,另含 check-dual-backend-parity.mjs、\ncheck-docs-truth.mjs、CLAUDE.md、package.json、pnpm-lock.yaml)、safe-copy 55、\nmerge-sensitive 12。六版累加含 F14 compose 身份、C34 健康经内核聚合、C35 统一\n访问日志与 req 序列化变更、新增 Dockerfile 与生产编排、三个门禁脚本迁入。\napi-nestjs 那 22 个正是平台装配点(端口合成 / HTTP 适配 / 运维命令 API)。\n\n反向的好消息:内核包本身六个 minor 只有 364 增 / 3 删,纯新增八个导出,且\ntenantIdFromClaims 改为 tenant_id → tenantId → tid 读序——本仓 FR-4 已被框架\n受理,对 DEC-032 canonical 租户是白赚。风险全在框架源码同步,不在内核 API。\n\n给三个处置选项待裁,并写明不可接受的第四条:只改 pin + 仓版本 + 补 CHANGELOG\n而不取框架源码——F11 会过,但仓就在声称自己是 0.22.0 却没有 0.22.0 的门禁与\n中间件,迁移凭证会记下一个假事实。\n\n门禁消费登记同步:L12 的接入条件应读作「待框架同步立项并完成」,不是「待抬\n一次 pin」。check:gates 通过,相关测试 46/46。\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-17T20:54:37-07:00"}],"HeadCommit":{"Sha1":"bc014de63a169082ff81ff54e77012c5fda7e50f","Message":"docs(计划): 登记偏差 #35——C-14「抬内核 pin」的实际范围是框架同步 74 冲突\n\n按目录负责人指令动工后实测:裁决文本说的是抬 pin,机制成本是一次完整框架\n同步。已完整撤回,未提交任何 pin 改动、未做框架合并。\n\n做到哪一步:12 处 pin 全改 0.22.0,pnpm install 成功、锁文件更新、\ncheck:pins 通过、构建 17/17、类型检查 31/31 全过。\n\n卡在哪:F11(check:fork-readiness)要求 @juhai/kernel pin 必须等于本仓\npackage.json.version——框架版本轴 = 内核版本轴;仓版本又被 check:docs-truth\n的 changelog-version-matches-package 绑到 runtime/CHANGELOG.md。\n\n真实范围(migration:plan,以框架仓为源,只读):冲突 74(apps/api-nestjs 22、\napps/api-fastify 14、apps/web 8,另含 check-dual-backend-parity.mjs、\ncheck-docs-truth.mjs、CLAUDE.md、package.json、pnpm-lock.yaml)、safe-copy 55、\nmerge-sensitive 12。六版累加含 F14 compose 身份、C34 健康经内核聚合、C35 统一\n访问日志与 req 序列化变更、新增 Dockerfile 与生产编排、三个门禁脚本迁入。\napi-nestjs 那 22 个正是平台装配点(端口合成 / HTTP 适配 / 运维命令 API)。\n\n反向的好消息:内核包本身六个 minor 只有 364 增 / 3 删,纯新增八个导出,且\ntenantIdFromClaims 改为 tenant_id → tenantId → tid 读序——本仓 FR-4 已被框架\n受理,对 DEC-032 canonical 租户是白赚。风险全在框架源码同步,不在内核 API。\n\n给三个处置选项待裁,并写明不可接受的第四条:只改 pin + 仓版本 + 补 CHANGELOG\n而不取框架源码——F11 会过,但仓就在声称自己是 0.22.0 却没有 0.22.0 的门禁与\n中间件,迁移凭证会记下一个假事实。\n\n门禁消费登记同步:L12 的接入条件应读作「待框架同步立项并完成」,不是「待抬\n一次 pin」。check:gates 通过,相关测试 46/46。\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-17T20:54:37-07:00"},"CompareURL":"luoanwu/platform-governance/compare/1b940277848578801e16f969b874470ff90adce7...bc014de63a169082ff81ff54e77012c5fda7e50f","Len":1}...
|
1789703681
|
Edit
Delete
|
|
30788
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"3cbdf7409 {"Commits":[{"Sha1":"3cbdf7409759ef6652fe7811dee6e30fb84baaa5","Message":"docs(计划): 框架同步 0.16.1 → 0.22.0 立项,分 F-1—F-7 七批\n\n目录负责人指令:偏差 #35 选③「框架同步单独立项」。新增立项书\ndocs/框架同步立项.md,文件名刻意不带日期——否则会被一致性门禁的\nHISTORY_NAME_PATTERN 当历史快照而跳过 L3/L4/L10 扫描(教训出自\n开发计划梳理-2026-09-14 的同名坑)。\n\n立项前逐文件核实,三条比首轮更准的事实:\n\n1. 74 个冲突里 20 个本仓从未改过(仍逐字节等于框架 v0.16.1),可直接快进;\n 真需三方合并的是 53 个,另 1 个是两侧各自新增的 .dockerignore\n2. apps/api-nestjs 的 17 个真冲突里只有 1 个在 src/platform/——首轮按目录\n 粗计说「22 个正是平台装配点」不成立。平台自有的七模块 / clients /\n platform-tests 共 531 文件全在 target-only,框架同步根本不碰\n3. 两个前置都比裁决时乐观:C-13 的卷那一半已执行;F14 在本仓基本已合规\n (runtime 的 compose 已是 ${COMPOSE_PROJECT_NAME:-…} 形式,只剩\n stack/compose.yaml 改变量形式与 act-runner 补 name:)\n\n内核 API 不是风险源:六个 minor 只有 364 增 / 3 删,纯新增八个导出,唯一\n语义变更是 tenantIdFromClaims 改读序——本仓 FR-4 被受理,对 DEC-032 是白赚。\n风险全在框架源码的行为接线(C34 / C35 / C39 / F14)。\n\n七批各带机器退出条件,F-4 两后端接线标为高风险(唯一会动 platform-ports.module.ts\n的批次)。立项书显式禁止「只改 pin + 版本 + CHANGELOG 而不取框架源码」——\nF11 会过,但会伪造迁移凭证,与本仓当日清理的病同源。\n\n§3A 增领取行,§6 偏差 #35 结论改为已选③并立项,README 增索引。\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-17T20:57:38-07:00"}],"HeadCommit":{"Sha1":"3cbdf7409759ef6652fe7811dee6e30fb84baaa5","Message":"docs(计划): 框架同步 0.16.1 → 0.22.0 立项,分 F-1—F-7 七批\n\n目录负责人指令:偏差 #35 选③「框架同步单独立项」。新增立项书\ndocs/框架同步立项.md,文件名刻意不带日期——否则会被一致性门禁的\nHISTORY_NAME_PATTERN 当历史快照而跳过 L3/L4/L10 扫描(教训出自\n开发计划梳理-2026-09-14 的同名坑)。\n\n立项前逐文件核实,三条比首轮更准的事实:\n\n1. 74 个冲突里 20 个本仓从未改过(仍逐字节等于框架 v0.16.1),可直接快进;\n 真需三方合并的是 53 个,另 1 个是两侧各自新增的 .dockerignore\n2. apps/api-nestjs 的 17 个真冲突里只有 1 个在 src/platform/——首轮按目录\n 粗计说「22 个正是平台装配点」不成立。平台自有的七模块 / clients /\n platform-tests 共 531 文件全在 target-only,框架同步根本不碰\n3. 两个前置都比裁决时乐观:C-13 的卷那一半已执行;F14 在本仓基本已合规\n (runtime 的 compose 已是 ${COMPOSE_PROJECT_NAME:-…} 形式,只剩\n stack/compose.yaml 改变量形式与 act-runner 补 name:)\n\n内核 API 不是风险源:六个 minor 只有 364 增 / 3 删,纯新增八个导出,唯一\n语义变更是 tenantIdFromClaims 改读序——本仓 FR-4 被受理,对 DEC-032 是白赚。\n风险全在框架源码的行为接线(C34 / C35 / C39 / F14)。\n\n七批各带机器退出条件,F-4 两后端接线标为高风险(唯一会动 platform-ports.module.ts\n的批次)。立项书显式禁止「只改 pin + 版本 + CHANGELOG 而不取框架源码」——\nF11 会过,但会伪造迁移凭证,与本仓当日清理的病同源。\n\n§3A 增领取行,§6 偏差 #35 结论改为已选③并立项,README 增索引。\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-17T20:57:38-07:00"},"CompareURL":"luoanwu/platform-governance/compare/bc014de63a169082ff81ff54e77012c5fda7e50f...3cbdf7409759ef6652fe7811dee6e30fb84baaa5","Len":1}...
|
1789703862
|
Edit
Delete
|
|
30789
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"d70b1e5b6 {"Commits":[{"Sha1":"d70b1e5b6f3ed902a64adac86d0a4d953cadddb8","Message":"docs(计划): F-1 开工即证伪——「零判读快进」实收 0 个文件,本批取消\n\n按立项书从 F-1 起做,逐项审定 75 个候选(55 safe-copy + 20 个本仓从未改过的\n冲突文件)后实收 0 个,未改动仓内任何文件。\n\n拒收 44:\n- 30 个 packages/kernel/*:本仓不 vendor 内核源码,pin 的是已发布的\n @juhai/kernel;而 packages/* 在本仓 workspace 内,收进来会与 pin 直接冲突\n- 14 个示例 Order 域(orders.* / order.ts / orderMachine.ts / OrdersPanel.tsx):\n 本仓以 --strip-sample 建仓,实测 0 个同名文件,收回即让剥离回潮;仓内\n docs/strip-sample-domain.md 正是该机制的说明\n\n其余 31 个归位:F-2 门禁脚本 11、F-4 的 C34/C35/C39 接线面 12、F-5 部署物 4、\nF-3 COMPATIBILITY 1、F-6 文档 1,另 2 个保护路径延后判读。\n\n核心教训:migration:plan 的「safe-copy」标签指的是「目标没有这个文件」,不是\n「拿过来安全」。对一个 --strip-sample 且不 vendor 内核的派生仓,「目标没有」\n恰恰常常意味着「本仓刻意不要」。照单全收会同时干两件坏事:把剥离掉的示例域\n装回来、把 pin 的内核变成 vendor 的源码。\n\n立项书 §5.1 记下证伪与批次修正:不存在零判读快进层;余下六批内容不变,但每批\n开工须先逐文件审定,不得直接采信 migration:plan 的分类;F-2 成为实际起点。\n\n顺带修 L13:新增立项书使 平台治理/README.md 收纳表计数 157 → 158。\n全量一致性门禁回到 L9 / L12 两条常驻基线;测试 35/35。\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-17T21:01:00-07:00"}],"HeadCommit":{"Sha1":"d70b1e5b6f3ed902a64adac86d0a4d953cadddb8","Message":"docs(计划): F-1 开工即证伪——「零判读快进」实收 0 个文件,本批取消\n\n按立项书从 F-1 起做,逐项审定 75 个候选(55 safe-copy + 20 个本仓从未改过的\n冲突文件)后实收 0 个,未改动仓内任何文件。\n\n拒收 44:\n- 30 个 packages/kernel/*:本仓不 vendor 内核源码,pin 的是已发布的\n @juhai/kernel;而 packages/* 在本仓 workspace 内,收进来会与 pin 直接冲突\n- 14 个示例 Order 域(orders.* / order.ts / orderMachine.ts / OrdersPanel.tsx):\n 本仓以 --strip-sample 建仓,实测 0 个同名文件,收回即让剥离回潮;仓内\n docs/strip-sample-domain.md 正是该机制的说明\n\n其余 31 个归位:F-2 门禁脚本 11、F-4 的 C34/C35/C39 接线面 12、F-5 部署物 4、\nF-3 COMPATIBILITY 1、F-6 文档 1,另 2 个保护路径延后判读。\n\n核心教训:migration:plan 的「safe-copy」标签指的是「目标没有这个文件」,不是\n「拿过来安全」。对一个 --strip-sample 且不 vendor 内核的派生仓,「目标没有」\n恰恰常常意味着「本仓刻意不要」。照单全收会同时干两件坏事:把剥离掉的示例域\n装回来、把 pin 的内核变成 vendor 的源码。\n\n立项书 §5.1 记下证伪与批次修正:不存在零判读快进层;余下六批内容不变,但每批\n开工须先逐文件审定,不得直接采信 migration:plan 的分类;F-2 成为实际起点。\n\n顺带修 L13:新增立项书使 平台治理/README.md 收纳表计数 157 → 158。\n全量一致性门禁回到 L9 / L12 两条常驻基线;测试 35/35。\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-17T21:01:00-07:00"},"CompareURL":"luoanwu/platform-governance/compare/3cbdf7409759ef6652fe7811dee6e30fb84baaa5...d70b1e5b6f3ed902a64adac86d0a4d953cadddb8","Len":1}...
|
1789704064
|
Edit
Delete
|
|
30825
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"9a959dc86 {"Commits":[{"Sha1":"9a959dc86d101a8abfcd42db52f679d5dbb8de8c","Message":"docs(计划): 框架同步 0.16.1 → 0.22.0 完成,一致性门禁 L12 清零\n\n七批里 F-2a / F-2b / F-3 / F-4 / F-7 完成,F-1 证伪取消,F-5 撤回并提 FR-6,\nF-6 并入。真源仓 a63414a。\n\n验收(clean 765300b,与升级前逐项持平):runtime 775/775 且租户 RLS enforce、\nUI 5/5、主线四套件 11/17/19/18、恢复演练 passed、端口一致性 41/41,\ncheck:evidence passed 35 份全新鲜 / 0 过期 / 0 例外。\nmigration:record --mode sync 出凭证 frameworkVersion=0.22.0。\n\n立项书补两节:§5.2 执行记录(含同步过程中撞到的三件事:git show 重定向会造\n空文件、并入上游 CHANGELOG 带来跨仓断链、治理测试锚定旧 pin),§5.3 三级验收\n结果,并记下两次教训——\n- 一次假阴性:首轮报 682/775 失败 5 条,读错误码才发现是环境缺 MAINLINE_CHAOS_\n CONTAINER,不是代码回归。验收红了先读错误码,别先怀疑代码\n- 一次自伤:git checkout -- runtime/reports 连带把真跑出的六份验收证据还原成\n 旧版,只能重跑找回;还原前须按 provenance.gitSha 分辨本轮产出与脏绑\n\n常驻问题 L9 / L12 两条降为 L9 一条(8 个上层应用仓的 compose 身份,待 N-11)。\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-17T22:40:49-07:00"},{"Sha1":"48c5a9c821798dbd7b2aae8355a55aba95d68c20","Message":"docs(框架): 提 FR-6——四级新鲜度须按「该级别是否已接线」断言\n\n框架 0.22.0 把 check:docs-truth 的证据新鲜度断言由两级扩到四级,新增的部署 /\n生产两级在本仓无法成立:其证据生产者依赖 apps/api-nestjs/Dockerfile,而那份\n里写着 COPY packages/kernel/package.json——本仓按 DEC-010 / DEC-031 的分发口径\n只 exact pin 已发布的 @juhai/kernel,仓内不存在 packages/kernel,2026-09-18\n实测该镜像构建必然失败。本仓自己的制品镜像是另一套架构(runtime/Dockerfile,\nD-1),并存会变成两条镜像路径。\n\n结果是这道门禁在本仓只能恒红,而恒红门禁不携带信息——正是框架自己在 0.22.0\n里要治的失效模式的反面。\n\n请求:四级断言按该级别是否已接线判定——对应 pnpm 脚本在 package.json 里存在\n则断言照旧,不存在则打印 SKIPPED 并跳过。不接受占位报告,与 doctrine「诚实的\n空,不得用占位报告转绿」一致;接线了却让报告陈旧的仓仍照旧判红,门禁的牙一\n颗不少。\n\n临时处置已在本仓 runtime/scripts/check-docs-truth.mjs 落地,改动处带注释指向\n本 FR,框架受理后删除该段回到框架原文(同 FR-4 / FR-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-17T21:53:48-07:00"}],"HeadCommit":{"Sha1":"9a959dc86d101a8abfcd42db52f679d5dbb8de8c","Message":"docs(计划): 框架同步 0.16.1 → 0.22.0 完成,一致性门禁 L12 清零\n\n七批里 F-2a / F-2b / F-3 / F-4 / F-7 完成,F-1 证伪取消,F-5 撤回并提 FR-6,\nF-6 并入。真源仓 a63414a。\n\n验收(clean 765300b,与升级前逐项持平):runtime 775/775 且租户 RLS enforce、\nUI 5/5、主线四套件 11/17/19/18、恢复演练 passed、端口一致性 41/41,\ncheck:evidence passed 35 份全新鲜 / 0 过期 / 0 例外。\nmigration:record --mode sync 出凭证 frameworkVersion=0.22.0。\n\n立项书补两节:§5.2 执行记录(含同步过程中撞到的三件事:git show 重定向会造\n空文件、并入上游 CHANGELOG 带来跨仓断链、治理测试锚定旧 pin),§5.3 三级验收\n结果,并记下两次教训——\n- 一次假阴性:首轮报 682/775 失败 5 条,读错误码才发现是环境缺 MAINLINE_CHAOS_\n CONTAINER,不是代码回归。验收红了先读错误码,别先怀疑代码\n- 一次自伤:git checkout -- runtime/reports 连带把真跑出的六份验收证据还原成\n 旧版,只能重跑找回;还原前须按 provenance.gitSha 分辨本轮产出与脏绑\n\n常驻问题 L9 / L12 两条降为 L9 一条(8 个上层应用仓的 compose 身份,待 N-11)。\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-17T22:40:49-07:00"},"CompareURL":"luoanwu/platform-governance/compare/d70b1e5b6f3ed902a64adac86d0a4d953cadddb8...9a959dc86d101a8abfcd42db52f679d5dbb8de8c","Len":2}...
|
1789710053
|
Edit
Delete
|
|
30850
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"4be34a841 {"Commits":[{"Sha1":"4be34a8411ad6ac48125865937ecad8ec32abc1f","Message":"docs(计划): 登记偏差 #36——S-5 转正的前提不成立,试做后撤回\n\n框架同步带来 FR-1(HealthResponse.checks 可扩展,0.19.0 受理),本仓提该 FR\n的动机正是让 S-5 模块健康子检查从「过渡方案」转正、汇入 /api/health。\n\n试做后撤回:接线后真实 DB 验收由 775 跌到 561,e2e/identity-profile.test.ts\n两条失败。读用例才看清——其中一条的名字就写着「identity 依赖故障时宿主数据库\n仍健康」,第 188—189 行是成对断言:模块视图须报 degraded,而宿主 /api/health\n须仍为 200。本仓早已有意分离「模块依赖故障」与「宿主运行时不健康」,我的改动\n等于把模块故障提升成宿主故障,破坏既有设计。\n\n已完整撤回,真源仓回到 a63414a / dirty 0,未提交任何接线改动。\n\n§6 增偏差 #36,给三个处置选项(维持分离 / 汇入但不影响状态码,需另提 FR 支持\nobservational 子检查 / 按模块 state 分级传导,属设计问题);裁决前 S-5 保持\n过渡方案,不因 FR-1 已受理就当作可转正。\n\n方法上的教训:FR 被受理 ≠ 它解锁的工作就该做;转正前要先读既有用例在守什么。\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-17T23:36:51-07:00"}],"HeadCommit":{"Sha1":"4be34a8411ad6ac48125865937ecad8ec32abc1f","Message":"docs(计划): 登记偏差 #36——S-5 转正的前提不成立,试做后撤回\n\n框架同步带来 FR-1(HealthResponse.checks 可扩展,0.19.0 受理),本仓提该 FR\n的动机正是让 S-5 模块健康子检查从「过渡方案」转正、汇入 /api/health。\n\n试做后撤回:接线后真实 DB 验收由 775 跌到 561,e2e/identity-profile.test.ts\n两条失败。读用例才看清——其中一条的名字就写着「identity 依赖故障时宿主数据库\n仍健康」,第 188—189 行是成对断言:模块视图须报 degraded,而宿主 /api/health\n须仍为 200。本仓早已有意分离「模块依赖故障」与「宿主运行时不健康」,我的改动\n等于把模块故障提升成宿主故障,破坏既有设计。\n\n已完整撤回,真源仓回到 a63414a / dirty 0,未提交任何接线改动。\n\n§6 增偏差 #36,给三个处置选项(维持分离 / 汇入但不影响状态码,需另提 FR 支持\nobservational 子检查 / 按模块 state 分级传导,属设计问题);裁决前 S-5 保持\n过渡方案,不因 FR-1 已受理就当作可转正。\n\n方法上的教训:FR 被受理 ≠ 它解锁的工作就该做;转正前要先读既有用例在守什么。\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-17T23:36:51-07:00"},"CompareURL":"luoanwu/platform-governance/compare/9a959dc86d101a8abfcd42db52f679d5dbb8de8c...4be34a8411ad6ac48125865937ecad8ec32abc1f","Len":1}...
|
1789713415
|
Edit
Delete
|
|
30852
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"e393d2db5 {"Commits":[{"Sha1":"e393d2db524e2c16a517866d412b1d039c01640a","Message":"docs(计划): 偏差 #36 裁决「维持分离」,S-5 由过渡方案改判为终态\n\n目录负责人裁定选项 ①:模块依赖故障 ≠ 宿主运行时不健康。模块健康只在\nGET /api/platform/modules[/:id/health] 可见,/api/health 只反映宿主依赖。\n\n两处改判:\n- S-5 不再标「过渡方案」而是终态。这条分离由 e2e/identity-profile.test.ts\n 第 188—189 行的成对断言守着,是设计不是欠账;真源仓已给该用例补注释说明\n 裁决出处与那次 775 → 561 的实锤\n- 跨目录待办更新:FR-1—5 已随框架 0.22.0 全部到位(FR-1 健康子检查 0.19.0、\n FR-4 租户 claim 读序 0.20.0、FR-5 runner 三值 0.20.0),余 FR-6 待受理\n\n偏差 #36 移入已关闭,并在其中记下「FR 被受理 ≠ 它解锁的工作就该做」。\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-17T23:49:17-07:00"}],"HeadCommit":{"Sha1":"e393d2db524e2c16a517866d412b1d039c01640a","Message":"docs(计划): 偏差 #36 裁决「维持分离」,S-5 由过渡方案改判为终态\n\n目录负责人裁定选项 ①:模块依赖故障 ≠ 宿主运行时不健康。模块健康只在\nGET /api/platform/modules[/:id/health] 可见,/api/health 只反映宿主依赖。\n\n两处改判:\n- S-5 不再标「过渡方案」而是终态。这条分离由 e2e/identity-profile.test.ts\n 第 188—189 行的成对断言守着,是设计不是欠账;真源仓已给该用例补注释说明\n 裁决出处与那次 775 → 561 的实锤\n- 跨目录待办更新:FR-1—5 已随框架 0.22.0 全部到位(FR-1 健康子检查 0.19.0、\n FR-4 租户 claim 读序 0.20.0、FR-5 runner 三值 0.20.0),余 FR-6 待受理\n\n偏差 #36 移入已关闭,并在其中记下「FR 被受理 ≠ 它解锁的工作就该做」。\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-17T23:49:17-07:00"},"CompareURL":"luoanwu/platform-governance/compare/4be34a8411ad6ac48125865937ecad8ec32abc1f...e393d2db524e2c16a517866d412b1d039c01640a","Len":1}...
|
1789714159
|
Edit
Delete
|
|
30853
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"5b7a1c033 {"Commits":[{"Sha1":"5b7a1c033ef290f7fa48f58bf0eae5eaa38150aa","Message":"docs(框架): FR-6 提交框架 Owner——在送达入口 README 登记待受理\n\nFR-6 的正文 2026-09-18 已写入 基础设施仓框架变更请求-2026-09-12.md(48c5a9c),\n但那份文档本身不是送达入口:框架 Owner 是从 工程基础框架/README.md 的变更请求\n条目看待办的(FR-1 / FR-4 / FR-5 与另两份平台治理的请求都是这么送达并受理的)。\n此前只写了正文没更新入口,等于没提。\n\nREADME 该条更新为:FR-1 已落地 0.19.0、FR-4 / FR-5 已落地 0.20.0、**FR-6 新提\n待受理**、FR-2 / FR-3 仍未受理,并就地摘出 FR-6 的请求与依据:\n\ncheck:docs-truth 的四级证据新鲜度须按「该级别是否已接线」判定。起因是基础设施仓\n同步到 0.22.0 时实测,新增的制品部署 / 生产运维两级依赖 apps/api-nestjs/Dockerfile,\n而那份里有 COPY packages/kernel/package.json——该仓按 DEC-010 / DEC-031 只 exact\npin 已发布的 @juhai/kernel,仓内不存在 packages/kernel,构建必然失败,这道门禁\n在该仓只能恒红。恒红门禁不携带信息,正是 0.22.0 自己要治的失效模式的反面。\n\n请求对应 pnpm 脚本存在则断言照旧、不存在则 SKIPPED,不接受占位报告;接线了却让\n报告陈旧的仓仍照旧判红。影响面是框架仓单点改动加一条负向用例。基础设施仓已本地\n修正并在改动处注释指向 FR-6,受理后删除该段回到框架原文。\n\n未触碰框架仓 base-framework(其工作区有 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-17T23:57:57-07:00"}],"HeadCommit":{"Sha1":"5b7a1c033ef290f7fa48f58bf0eae5eaa38150aa","Message":"docs(框架): FR-6 提交框架 Owner——在送达入口 README 登记待受理\n\nFR-6 的正文 2026-09-18 已写入 基础设施仓框架变更请求-2026-09-12.md(48c5a9c),\n但那份文档本身不是送达入口:框架 Owner 是从 工程基础框架/README.md 的变更请求\n条目看待办的(FR-1 / FR-4 / FR-5 与另两份平台治理的请求都是这么送达并受理的)。\n此前只写了正文没更新入口,等于没提。\n\nREADME 该条更新为:FR-1 已落地 0.19.0、FR-4 / FR-5 已落地 0.20.0、**FR-6 新提\n待受理**、FR-2 / FR-3 仍未受理,并就地摘出 FR-6 的请求与依据:\n\ncheck:docs-truth 的四级证据新鲜度须按「该级别是否已接线」判定。起因是基础设施仓\n同步到 0.22.0 时实测,新增的制品部署 / 生产运维两级依赖 apps/api-nestjs/Dockerfile,\n而那份里有 COPY packages/kernel/package.json——该仓按 DEC-010 / DEC-031 只 exact\npin 已发布的 @juhai/kernel,仓内不存在 packages/kernel,构建必然失败,这道门禁\n在该仓只能恒红。恒红门禁不携带信息,正是 0.22.0 自己要治的失效模式的反面。\n\n请求对应 pnpm 脚本存在则断言照旧、不存在则 SKIPPED,不接受占位报告;接线了却让\n报告陈旧的仓仍照旧判红。影响面是框架仓单点改动加一条负向用例。基础设施仓已本地\n修正并在改动处注释指向 FR-6,受理后删除该段回到框架原文。\n\n未触碰框架仓 base-framework(其工作区有 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-17T23:57:57-07:00"},"CompareURL":"luoanwu/platform-governance/compare/e393d2db524e2c16a517866d412b1d039c01640a...5b7a1c033ef290f7fa48f58bf0eae5eaa38150aa","Len":1}...
|
1789714680
|
Edit
Delete
|
|
30854
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"650711d6c {"Commits":[{"Sha1":"650711d6cb4d48b6d77a3edea998d26d60f87567","Message":"docs(框架): FR-2 / FR-3 一并提交框架 Owner,附 2026-09-18 复核与新证据\n\n两项 2026-09-12 提出后一直未受理。复核后确认**仍成立**,而不是直接重提一份\n可能已过期的请求——内核 0.22.0 实测:\n\n- FR-2:createLocalPlatformPorts 的 auditLog 依旧是同步回调,实现只能表达\n 「记了 / 没记」,Q04 要求的「与业务写同事务落盘」在框架层没有接缝\n- FR-3:RealtimeEnvelope 仍只有 seq 与 context,无 ordering / aggregateKey /\n aggregateVersion,replay-buffer 只能按全局 seq 检缺口\n\n六天里本仓积累的新证据让两项更有说服力:\n\n- FR-2:已落地 audit-commit-protocol.ts(2026-09-16),把 Q04 两模式与六类\n 故障注入点写成机器可读的 AUDIT_FAULT_MATRIX 并以夹具 + 集成用例覆盖 M6 侧;\n 其中 F1 / F2 / F4 与 F6 的 Owner 侧义务只能由框架写链提供接缝,模块侧补不了。\n 受理后该矩阵即可两端对账\n- FR-3:DEC-013—016 Approval gate 材料 ④ 已备 Envelope v2 候选 schema\n (aggregate_version + previous_aggregate_version 必填,检查器判\n REQUIRED_PROPERTY_ADDED ⇒ 需发新主版本)。那是契约侧的轨,与本请求的内核侧\n 可选字段互不冲突,两轨可并行——这一点此前没写清,容易被误读为重复请求\n\n两项都向后兼容、默认关闭,不改现有派生仓行为。README 送达入口与原始 FR 正文\n两处同步补记,避免说法不一;并明写请求给一个受理或不受理的结论——长期悬空会\n让本仓的 Q04 / Q06 落地一直只能做半边。\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-17T23:59:35-07:00"}],"HeadCommit":{"Sha1":"650711d6cb4d48b6d77a3edea998d26d60f87567","Message":"docs(框架): FR-2 / FR-3 一并提交框架 Owner,附 2026-09-18 复核与新证据\n\n两项 2026-09-12 提出后一直未受理。复核后确认**仍成立**,而不是直接重提一份\n可能已过期的请求——内核 0.22.0 实测:\n\n- FR-2:createLocalPlatformPorts 的 auditLog 依旧是同步回调,实现只能表达\n 「记了 / 没记」,Q04 要求的「与业务写同事务落盘」在框架层没有接缝\n- FR-3:RealtimeEnvelope 仍只有 seq 与 context,无 ordering / aggregateKey /\n aggregateVersion,replay-buffer 只能按全局 seq 检缺口\n\n六天里本仓积累的新证据让两项更有说服力:\n\n- FR-2:已落地 audit-commit-protocol.ts(2026-09-16),把 Q04 两模式与六类\n 故障注入点写成机器可读的 AUDIT_FAULT_MATRIX 并以夹具 + 集成用例覆盖 M6 侧;\n 其中 F1 / F2 / F4 与 F6 的 Owner 侧义务只能由框架写链提供接缝,模块侧补不了。\n 受理后该矩阵即可两端对账\n- FR-3:DEC-013—016 Approval gate 材料 ④ 已备 Envelope v2 候选 schema\n (aggregate_version + previous_aggregate_version 必填,检查器判\n REQUIRED_PROPERTY_ADDED ⇒ 需发新主版本)。那是契约侧的轨,与本请求的内核侧\n 可选字段互不冲突,两轨可并行——这一点此前没写清,容易被误读为重复请求\n\n两项都向后兼容、默认关闭,不改现有派生仓行为。README 送达入口与原始 FR 正文\n两处同步补记,避免说法不一;并明写请求给一个受理或不受理的结论——长期悬空会\n让本仓的 Q04 / Q06 落地一直只能做半边。\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-17T23:59:35-07:00"},"CompareURL":"luoanwu/platform-governance/compare/5b7a1c033ef290f7fa48f58bf0eae5eaa38150aa...650711d6cb4d48b6d77a3edea998d26d60f87567","Len":1}...
|
1789714779
|
Edit
Delete
|
|
30881
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"6bf1e7d52 {"Commits":[{"Sha1":"6bf1e7d524a70a3ecd012c29ea6c627866c01c5c","Message":"docs(架构): 总架构配套图与口径订正——重画图 1 / 图 2,新增图 4 关系全景\n\n企业应用群总架构-2026-09-17.md 与图 3 已随 5b7a1c0 提交(暂存区被并行会话的\n提交扫走,不是有意合并进那个范围),本提交补齐其余部分。\n\n**图 1 / 图 2 重画。** 图 1 原写「基础设施(23 项)」、画着「四候选」框,应用名\n还是改名前的「嗨设首席」;图 2 把 OS 标成「Projection 未实现」、干线标成「持久\n投递待裁决」。四处都已被后续裁决推翻:四候选 2026-09-16 撤销(CHG-015)、Catalog\n现为 21 条,OS 投影 2026-09-14 已在 main,三条前置 DEC 全部批准。图 1 另加一条\n跨层治理带,把「平台治理不是第六层」画进图面。\n\n**新增图 4 现存关系全景。** 逐条查实全组的边:左半五类有边的关系,右半七条负\n结论。查证推翻了总架构初稿 §3.1 的一处判断——初稿用 grep '\"@juhai/…\"' 取依赖,\n同时命中了 name 字段,于是把报价的 @juhai/public-file 与智服的\n@juhai/service-contracts 当成「对下层消费」,实际两者都是该仓自己的 workspace 包。\n按带版本号的依赖项重取:四个业务应用对下层的跨仓包依赖为零,全组跨仓包依赖只有\nHR、OS、enterprise-platform 三个消费仓。\n\n由此改口径的另有两条:\n\n- 三项 module_e2(文件 / 通知 / 配置)在工单仓里是 @repo/* private 包,仓外零\n 消费者,只被本仓 api-fastify / api-nestjs 依赖——「已被业务应用消费」不成立,\n 三消费者规则的计数应从 0 算起\n- relationships.json 的 relationships 为 {},关系在机器层面没有登记;图 4 的边\n 全部由 package.json / kernel.products.json / facts.json / runtime/modules.json\n 推导,今天没有门禁能发现某条关系消失\n\n**四份下游文档按活跃 Catalog 改齐:** 分层与装配模型(23→21、派生仓 3→0、1/23\n的分母;§3.1 是带日期快照,只加订正行不改写正文)、基础/CLAUDE.md 分层词表段、\n基础/README 头段(「已退役 15 个、现存 3 个」是 09-16 白天的中间态)、企业领域\n应用层 README(引的 platform-contracts 已于 2026-09-16 物理移除,事实数 1→11)。\n平台治理 README 收纳表随新增文件改计数(基础/ 根文件 63→65,根散文件 9→10)。\n\n复跑:工作区一致性门禁 L1—L13 只剩既有的 L9(8 个仓共用 compose project 名\napi-nestjs),L4 / L13 均为 0;治理层 npm test 378 项 0 失败;check-domain-layer\n13/13 条全在基线内、无新增。未动任何冻结物、审批记录与机器 Catalog。\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-18T00:20:28-07:00"}],"HeadCommit":{"Sha1":"6bf1e7d524a70a3ecd012c29ea6c627866c01c5c","Message":"docs(架构): 总架构配套图与口径订正——重画图 1 / 图 2,新增图 4 关系全景\n\n企业应用群总架构-2026-09-17.md 与图 3 已随 5b7a1c0 提交(暂存区被并行会话的\n提交扫走,不是有意合并进那个范围),本提交补齐其余部分。\n\n**图 1 / 图 2 重画。** 图 1 原写「基础设施(23 项)」、画着「四候选」框,应用名\n还是改名前的「嗨设首席」;图 2 把 OS 标成「Projection 未实现」、干线标成「持久\n投递待裁决」。四处都已被后续裁决推翻:四候选 2026-09-16 撤销(CHG-015)、Catalog\n现为 21 条,OS 投影 2026-09-14 已在 main,三条前置 DEC 全部批准。图 1 另加一条\n跨层治理带,把「平台治理不是第六层」画进图面。\n\n**新增图 4 现存关系全景。** 逐条查实全组的边:左半五类有边的关系,右半七条负\n结论。查证推翻了总架构初稿 §3.1 的一处判断——初稿用 grep '\"@juhai/…\"' 取依赖,\n同时命中了 name 字段,于是把报价的 @juhai/public-file 与智服的\n@juhai/service-contracts 当成「对下层消费」,实际两者都是该仓自己的 workspace 包。\n按带版本号的依赖项重取:四个业务应用对下层的跨仓包依赖为零,全组跨仓包依赖只有\nHR、OS、enterprise-platform 三个消费仓。\n\n由此改口径的另有两条:\n\n- 三项 module_e2(文件 / 通知 / 配置)在工单仓里是 @repo/* private 包,仓外零\n 消费者,只被本仓 api-fastify / api-nestjs 依赖——「已被业务应用消费」不成立,\n 三消费者规则的计数应从 0 算起\n- relationships.json 的 relationships 为 {},关系在机器层面没有登记;图 4 的边\n 全部由 package.json / kernel.products.json / facts.json / runtime/modules.json\n 推导,今天没有门禁能发现某条关系消失\n\n**四份下游文档按活跃 Catalog 改齐:** 分层与装配模型(23→21、派生仓 3→0、1/23\n的分母;§3.1 是带日期快照,只加订正行不改写正文)、基础/CLAUDE.md 分层词表段、\n基础/README 头段(「已退役 15 个、现存 3 个」是 09-16 白天的中间态)、企业领域\n应用层 README(引的 platform-contracts 已于 2026-09-16 物理移除,事实数 1→11)。\n平台治理 README 收纳表随新增文件改计数(基础/ 根文件 63→65,根散文件 9→10)。\n\n复跑:工作区一致性门禁 L1—L13 只剩既有的 L9(8 个仓共用 compose project 名\napi-nestjs),L4 / L13 均为 0;治理层 npm test 378 项 0 失败;check-domain-layer\n13/13 条全在基线内、无新增。未动任何冻结物、审批记录与机器 Catalog。\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-18T00:20:28-07:00"},"CompareURL":"luoanwu/platform-governance/compare/650711d6cb4d48b6d77a3edea998d26d60f87567...6bf1e7d524a70a3ecd012c29ea6c627866c01c5c","Len":1}...
|
1789716065
|
Edit
Delete
|
|
30884
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"44686cc39 {"Commits":[{"Sha1":"44686cc39752ceb9b94fbfed9169b6fe0a2d6ea3","Message":"docs(计划): 登记两轮治理改动——未登记报告纳入机器记账、验收 runner 前置失败不得销毁证据\n\n§8 增两条当日记录:\n\n一、`check:evidence` 的未登记类此前只由 info 级 `SCOPE_UNDECLARED` 记着,处置口径\n写在 `evidence-scopes.json` 的散文里、无人机器核对,48 份报告里 13 份在此(27%)。\n已按例外机制的同一纪律搬成 `undeclared` 逐条登记,三条新规则判红两端。顺带订正\n「聚合报告」类的两处误归类,`runtime-governance` 与 `conformance-differential`\n转入正式登记(35 → 37)。\n\n二、为重跑被注释提交打过期的验收报告,照 runbook §7 逐字执行,复现两个缺陷:\n配方缺七个 `DATABASE_URL_\u003cMODULE\u003e`;三个验收 runner 在前置守卫失败时仍无条件写\n报告,把 775/775 覆盖成 failed。后者是证据完整性问题,三处已统一修并各自实测。\n\n三份需真实容器的验收报告仍未重跑,理由写在条目里:其设计中的保鲜路径是 CI。\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-18T00:29:15-07:00"}],"HeadCommit":{"Sha1":"44686cc39752ceb9b94fbfed9169b6fe0a2d6ea3","Message":"docs(计划): 登记两轮治理改动——未登记报告纳入机器记账、验收 runner 前置失败不得销毁证据\n\n§8 增两条当日记录:\n\n一、`check:evidence` 的未登记类此前只由 info 级 `SCOPE_UNDECLARED` 记着,处置口径\n写在 `evidence-scopes.json` 的散文里、无人机器核对,48 份报告里 13 份在此(27%)。\n已按例外机制的同一纪律搬成 `undeclared` 逐条登记,三条新规则判红两端。顺带订正\n「聚合报告」类的两处误归类,`runtime-governance` 与 `conformance-differential`\n转入正式登记(35 → 37)。\n\n二、为重跑被注释提交打过期的验收报告,照 runbook §7 逐字执行,复现两个缺陷:\n配方缺七个 `DATABASE_URL_\u003cMODULE\u003e`;三个验收 runner 在前置守卫失败时仍无条件写\n报告,把 775/775 覆盖成 failed。后者是证据完整性问题,三处已统一修并各自实测。\n\n三份需真实容器的验收报告仍未重跑,理由写在条目里:其设计中的保鲜路径是 CI。\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-18T00:29:15-07:00"},"CompareURL":"luoanwu/platform-governance/compare/6bf1e7d524a70a3ecd012c29ea6c627866c01c5c...44686cc39752ceb9b94fbfed9169b6fe0a2d6ea3","Len":1}...
|
1789716558
|
Edit
Delete
|
|
30902
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"34c5fecec {"Commits":[{"Sha1":"34c5fecec1074d5a01acd8b184e70c63c5ed947b","Message":"feat(governance): 报告登记门禁补 R7 / R8——让它去读登记里早就写着的 binding 口径\n\n治理层是给全工作区定证据纪律的那一层,却没对自己的报告用同一条。登记表里每条 latest\n都写着 `\"binding\": \"clean-head\"`,note 也写着「只在 clean HEAD 上提交」,但 R1—R6 里\n没有任何一条去读它——R4 只查 provenance.gitSha 存不存在。\n\n于是 `基础目录统一审计.latest.json` 绑在 589467e 且 worktreeDirty=true(当时 9 个脏\n文件)被提交了,一路绿灯。一份绑在脏树上的报告证明不了任何一个提交态,它既不对应\n589467e 的树,也不对应此后任何提交。已于 ad86507 在干净树上重跑回绑。\n\n R7 BINDING_NOT_CLEAN 声明 clean-head 却自称绑在脏树上,且该报告本身已提交\n R8 BINDING_OFF_HISTORY 绑定的 SHA 不在当前 HEAD 的历史上(换基 / 重写历史后遗留)\n\n两条都只对**登记已声明绑定口径**的条目判——不替没声明的条目另立规矩。R7 跳过报告\n自身未提交的情况:那是在途产物,也可能是并行会话正在跑的中间态(本工作区常有 2—3\n个会话同时写 reports/),判红只会误伤对方的回绑,与真源仓偏差 #34-B 同一口径。\nR8 取不到祖先关系时整条不判,非 git 环境退回原判据。缺 gitSha 的报告由 R4 单独报,\n不叠加成三条。\n\n登记门禁测试 8 → 13,治理层全量 383(377 过 / 6 跳 / 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-18T00:49:24-07:00"},{"Sha1":"ad86507edf7f52241c3918e8c634b804e8b81b58","Message":"chore(reports): 治理层四份 latest 回绑 @ 44686cc\n\n`基础目录统一审计.latest.json` 此前绑在 589467e 且 worktreeDirty=true(当时 9 个脏\n文件)并被提交——登记里写着 binding=clean-head、note 也写着「只在 clean HEAD 上提交」,\n但没有任何检查去读,于是这份证明不了任何提交态的报告一直挂在顶层。\n\n`pnpm run audit` 一次编排写三份,加上它触发的 check-gate-consumption 共四份,本轮一并\n在干净树上重跑回绑(governanceProvenance 忽略 latest 报告自身,故并行会话在途的报告\n不影响绑定判定)。四份现均为 44686cc / dirty=false。\n\n结论未变:审计仍 BLOCKED(FACT_DECISIONS_PENDING_OR_UNKNOWN、\nASSET_EVIDENCE_REVIEW_REQUIRED),assets 去掉 ageHours 后逐字相同。\n\n另记一笔:`门禁消费.latest.json` 相对它自己的输入 `门禁消费登记.json` 已经陈旧——\n登记表里 C-13 / C-14 那段 2026-09-18 的文字早已提交,报告却停在旧文本,无人察觉。\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-18T00:47:30-07:00"}],"HeadCommit":{"Sha1":"34c5fecec1074d5a01acd8b184e70c63c5ed947b","Message":"feat(governance): 报告登记门禁补 R7 / R8——让它去读登记里早就写着的 binding 口径\n\n治理层是给全工作区定证据纪律的那一层,却没对自己的报告用同一条。登记表里每条 latest\n都写着 `\"binding\": \"clean-head\"`,note 也写着「只在 clean HEAD 上提交」,但 R1—R6 里\n没有任何一条去读它——R4 只查 provenance.gitSha 存不存在。\n\n于是 `基础目录统一审计.latest.json` 绑在 589467e 且 worktreeDirty=true(当时 9 个脏\n文件)被提交了,一路绿灯。一份绑在脏树上的报告证明不了任何一个提交态,它既不对应\n589467e 的树,也不对应此后任何提交。已于 ad86507 在干净树上重跑回绑。\n\n R7 BINDING_NOT_CLEAN 声明 clean-head 却自称绑在脏树上,且该报告本身已提交\n R8 BINDING_OFF_HISTORY 绑定的 SHA 不在当前 HEAD 的历史上(换基 / 重写历史后遗留)\n\n两条都只对**登记已声明绑定口径**的条目判——不替没声明的条目另立规矩。R7 跳过报告\n自身未提交的情况:那是在途产物,也可能是并行会话正在跑的中间态(本工作区常有 2—3\n个会话同时写 reports/),判红只会误伤对方的回绑,与真源仓偏差 #34-B 同一口径。\nR8 取不到祖先关系时整条不判,非 git 环境退回原判据。缺 gitSha 的报告由 R4 单独报,\n不叠加成三条。\n\n登记门禁测试 8 → 13,治理层全量 383(377 过 / 6 跳 / 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-18T00:49:24-07:00"},"CompareURL":"luoanwu/platform-governance/compare/44686cc39752ceb9b94fbfed9169b6fe0a2d6ea3...34c5fecec1074d5a01acd8b184e70c63c5ed947b","Len":2}...
|
1789717791
|
Edit
Delete
|
|
30904
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"f4540e69b {"Commits":[{"Sha1":"f4540e69b1656232b677571584d3bd6ad57217be","Message":"docs(架构): 总架构增 §3.8——基座的装载 / 调用两个方向与接入能力归属\n\n起因是一次实际误读:`c433d57` 被当成「另一个 OS 产品」。它是数字员工OS 仓的提交\nSHA(2026-09-14),由 base-framework-os-product/os.upstream.json 连同 protocol\n1.3.0 钉住,用途是让「上游 OS 走动了」以 O0-SHA 显式变红。与基座并列的不是它,\n是 base-framework-os-product 这个仓——示例产品扩展加两道 OS 门禁,2026-09-10\n随 G26 自框架仓移出以保框架零依赖。误读本身说明这几件事在文档里没写清,本节补上。\n\n**两个方向。** PNG 给基座的定语「理解、编排、调用、执行」对应两个方向相反的接口:\n装载(OS → 应用)已有协议(KERNEL_EXTENSION_PROTOCOL_VERSION = 1.3.0,定义在 OS\n仓 packages/contracts/src/product-manifest.ts),真装 1 个;调用(应用 → OS)基本\n空白——协议草案 §4 已给出 ProductActivationIntent / ToolIntentReceipt 并写明「OS\n应提供、产品不再自建」,2026-09-18 复核 OS 仓 apps/ 下仍无 product-activations\n路由,智服已在自己仓内造了一套。两个方向归属不同,混谈会把落点找错。\n\n**接入形态实测已分叉成五种:** product.manifest.json(示例 / 设备云 / 知识云)、\nmanifest.json(HR,另有 ddl-authority / distribution / readiness 三个独有文件且无\npackage.json)、manifest.ts(工单,另有 kernel.products.entry.json)。只有示例与\n设备云带 os-host 测试配置。\n\n**为什么「每个应用继承一份」今天做不到**(两条方向相反的硬事实):OS 的包是\n@repo/* 仓内作用域名(@repo/contracts@1.16.0,与工单仓同名包撞名),外仓依赖不了,\n只能照抄;而协议 §2.1 又反向禁止产品导入宿主私有 @repo/*,宿主能力一律由组合根\n注入、产品契约要自包含。由此划边界:可继承的是契约 / Schema / 校验器 / 门禁,不可\n继承的是宿主运行时——搞混会废掉 §2.1 的 fail-closed import 扫描。\n\n**四个落点按依赖方向逐个判定:** 协议与 SDK 由基座以 @juhai/ 发布(合法,阻碍是\n@repo/* 命名);分发通道归基础设施(合法,DEC-031 已批准,缺口是契约包 pin 无门禁\n——HR 与 OS 停在 rc.1、源仓已 rc.3,不像 kernel 有 L12 守着);脚手架归框架(合法\n但受零依赖限制,只能给目录形状);**把装载协议搬进基础设施不合法**——基础设施要\n编码基座契约即反向依赖,撞图 1 的唯一硬约束。本节只判合法性,不选落点。\n\n另记一条门禁抓不到的过期陈述:协议草案 §4 写「DEC-006 / 007 pending 期间」,两条\n实际都已 approved;L10 只抓「等 / 待 / 尚未裁决」措辞,这句不在模式内。该文是\nDEC-009 材料,处置留给 OS Owner,本次未动。\n\n需走 DEC / CHG 的两件已列入 §9 不裁决清单:装载协议是否切出改名发布、走哪条通道、\n谁做 Owner;草案 §4 两个契约由基座实现的排期。\n\n门禁复跑:L3 / L4 / L10 / L13 均为 0,仍只剩既有的 L9;新增的两条跨层链接\n(os.upstream.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-18T00:54:12-07:00"}],"HeadCommit":{"Sha1":"f4540e69b1656232b677571584d3bd6ad57217be","Message":"docs(架构): 总架构增 §3.8——基座的装载 / 调用两个方向与接入能力归属\n\n起因是一次实际误读:`c433d57` 被当成「另一个 OS 产品」。它是数字员工OS 仓的提交\nSHA(2026-09-14),由 base-framework-os-product/os.upstream.json 连同 protocol\n1.3.0 钉住,用途是让「上游 OS 走动了」以 O0-SHA 显式变红。与基座并列的不是它,\n是 base-framework-os-product 这个仓——示例产品扩展加两道 OS 门禁,2026-09-10\n随 G26 自框架仓移出以保框架零依赖。误读本身说明这几件事在文档里没写清,本节补上。\n\n**两个方向。** PNG 给基座的定语「理解、编排、调用、执行」对应两个方向相反的接口:\n装载(OS → 应用)已有协议(KERNEL_EXTENSION_PROTOCOL_VERSION = 1.3.0,定义在 OS\n仓 packages/contracts/src/product-manifest.ts),真装 1 个;调用(应用 → OS)基本\n空白——协议草案 §4 已给出 ProductActivationIntent / ToolIntentReceipt 并写明「OS\n应提供、产品不再自建」,2026-09-18 复核 OS 仓 apps/ 下仍无 product-activations\n路由,智服已在自己仓内造了一套。两个方向归属不同,混谈会把落点找错。\n\n**接入形态实测已分叉成五种:** product.manifest.json(示例 / 设备云 / 知识云)、\nmanifest.json(HR,另有 ddl-authority / distribution / readiness 三个独有文件且无\npackage.json)、manifest.ts(工单,另有 kernel.products.entry.json)。只有示例与\n设备云带 os-host 测试配置。\n\n**为什么「每个应用继承一份」今天做不到**(两条方向相反的硬事实):OS 的包是\n@repo/* 仓内作用域名(@repo/contracts@1.16.0,与工单仓同名包撞名),外仓依赖不了,\n只能照抄;而协议 §2.1 又反向禁止产品导入宿主私有 @repo/*,宿主能力一律由组合根\n注入、产品契约要自包含。由此划边界:可继承的是契约 / Schema / 校验器 / 门禁,不可\n继承的是宿主运行时——搞混会废掉 §2.1 的 fail-closed import 扫描。\n\n**四个落点按依赖方向逐个判定:** 协议与 SDK 由基座以 @juhai/ 发布(合法,阻碍是\n@repo/* 命名);分发通道归基础设施(合法,DEC-031 已批准,缺口是契约包 pin 无门禁\n——HR 与 OS 停在 rc.1、源仓已 rc.3,不像 kernel 有 L12 守着);脚手架归框架(合法\n但受零依赖限制,只能给目录形状);**把装载协议搬进基础设施不合法**——基础设施要\n编码基座契约即反向依赖,撞图 1 的唯一硬约束。本节只判合法性,不选落点。\n\n另记一条门禁抓不到的过期陈述:协议草案 §4 写「DEC-006 / 007 pending 期间」,两条\n实际都已 approved;L10 只抓「等 / 待 / 尚未裁决」措辞,这句不在模式内。该文是\nDEC-009 材料,处置留给 OS Owner,本次未动。\n\n需走 DEC / CHG 的两件已列入 §9 不裁决清单:装载协议是否切出改名发布、走哪条通道、\n谁做 Owner;草案 §4 两个契约由基座实现的排期。\n\n门禁复跑:L3 / L4 / L10 / L13 均为 0,仍只剩既有的 L9;新增的两条跨层链接\n(os.upstream.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-18T00:54:12-07:00"},"CompareURL":"luoanwu/platform-governance/compare/34c5fecec1074d5a01acd8b184e70c63c5ed947b...f4540e69b1656232b677571584d3bd6ad57217be","Len":1}...
|
1789718060
|
Edit
Delete
|
|
30906
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"6fb129d40 {"Commits":[{"Sha1":"6fb129d40fb9e160af6f70871eb8881ff5eef743","Message":"chore(reports): 门禁消费回绑 @ 69784be\n\nR9 落地后第一条真实命中:69784be 改了 scripts/ 下两个文件,而 scripts/ 正是这份报告\n声明的输入之一(它拿 门禁消费登记.json 对盘受控脚本,读的是脚本内容不只是文件名)。\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-18T00:55:46-07:00"},{"Sha1":"69784be6b04c850ae1f2ea0b948344f9627738cf","Message":"feat(governance): 报告登记门禁补 R9 / R10——绑定干净不等于结论还成立\n\nR7 / R8 守的是绑定本身(不脏、在历史上)。这一轮补另一半:**一份绑得干干净净的报告,\n结论仍可能早已被推翻**。2026-09-18 实测 `门禁消费.latest.json` 相对它自己的输入\n`门禁消费登记.json` 已经陈旧——登记表改了并提交了,报告停在旧文本,R1—R8 一条都不响。\n\n R9 LATEST_STALE 登记声明了 inputs,绑定 SHA → HEAD 之间这些输入有变更\n R10 INPUTS_UNACCOUNTED latest 既没声明 inputs、也没写明为什么判不了\n\n判据与真源仓 check:evidence 同口径:不看「落后几个提交」,看**该报告自己覆盖的输入**\n动没动。同目录的 latest 报告不算输入,它们是产物。\n\n四份 latest 逐条给出口径,禁止留空白:\n 门禁消费 inputs:门禁消费登记.json + scripts/(它正是拿登记表对盘受控脚本)\n 基础目录统一审计 判不了——读其它仓的 HEAD / 工作树 / 验收报告,全在治理仓历史之外,\n 且 ageHours 每跑一次都变,本仓任何提交都决定不了它是否仍成立\n 延后op 判不了一半——决议材料在本仓,活跃 Catalog 在嵌套独立仓(治理仓忽略该\n 目录,git diff 看不见)。只声明能判的一半会给出假绿,比不判更坏\n 门禁运行 判不了——编排产物,写 inputs 只能写成 scripts/ 这种筐,真源仓\n evidence-scopes 的同一条纪律禁止为覆盖率造模糊作用域\n\n集成用例改为只在真实登记上断言**结构类**规则。仓纪律 5 要求两次提交(实现,然后在它\n的干净树上回绑),必然存在一个提交报告是陈旧的——那是纪律规定的流程,不是缺陷;在\n单测里断言它为零等于让 pnpm test 在自家流程的中间一步必红。「待回绑」四条由阻断性\n门禁 check:reports 把关。该用例原本就已按同一理由排除 LATEST_WITHOUT_PROVENANCE,\n本轮只是把这一类补全。\n\n登记门禁测试 13 → 19,治理层全量 389(383 过 / 6 跳 / 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-18T00:55:24-07:00"}],"HeadCommit":{"Sha1":"6fb129d40fb9e160af6f70871eb8881ff5eef743","Message":"chore(reports): 门禁消费回绑 @ 69784be\n\nR9 落地后第一条真实命中:69784be 改了 scripts/ 下两个文件,而 scripts/ 正是这份报告\n声明的输入之一(它拿 门禁消费登记.json 对盘受控脚本,读的是脚本内容不只是文件名)。\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-18T00:55:46-07:00"},"CompareURL":"luoanwu/platform-governance/compare/f4540e69b1656232b677571584d3bd6ad57217be...6fb129d40fb9e160af6f70871eb8881ff5eef743","Len":2}...
|
1789718149
|
Edit
Delete
|
|
30931
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a111b6977 {"Commits":[{"Sha1":"a111b6977a361ae62f190375ae1d4a3634ac8fda","Message":"docs(治理): README 补记 R7—R10——报告登记门禁现在会读 binding 与 inputs\n\n第 51 行原本只写「latest 类须有存在的生产脚本与 provenance.gitSha」,R7—R10 落地后这句\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-18T00:57:18-07:00"}],"HeadCommit":{"Sha1":"a111b6977a361ae62f190375ae1d4a3634ac8fda","Message":"docs(治理): README 补记 R7—R10——报告登记门禁现在会读 binding 与 inputs\n\n第 51 行原本只写「latest 类须有存在的生产脚本与 provenance.gitSha」,R7—R10 落地后这句\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-18T00:57:18-07:00"},"CompareURL":"luoanwu/platform-governance/compare/6fb129d40fb9e160af6f70871eb8881ff5eef743...a111b6977a361ae62f190375ae1d4a3634ac8fda","Len":1}...
|
1789718241
|
Edit
Delete
|
|
30996
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"f0d1f11ac {"Commits":[{"Sha1":"f0d1f11ac7747e845e2781e441cf35bf86717dd5","Message":"chore(reports): 门禁消费回绑 @ 50ea2d6\n\nR9 第二次命中:50ea2d6 又改了 scripts/ 下两个文件,而它们是这份报告声明的输入。\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-18T01:00:11-07:00"},{"Sha1":"50ea2d665e441c9f348dbfeb6009c77be43190ce","Message":"feat(governance): 报告登记门禁补 R11——消费者\"文件还在\"不等于\"还在被引用\"\n\n登记 note 写的是 evidence 类「至少被一份受控文档**按名引用**」,R5 却只查消费者文件\n存不存在。这两句不是一回事,而差的那一半恰好是本门禁要治的病:当年 reports/ 攒出\n263 个顶层条目、223 个无人引用——**那些消费文档一个不少地存在着**,只是正文里早已\n不再提到它们。照 R5 的判据,那 223 份当年一份都不会被报出来。\n\nR11 EVIDENCE_NOT_NAMED:消费者都在、却没有一份正文真提到这份报告即红。判据认全名,\n也认去掉 `.latest.json` 后仍有 ≥4 字的名字(中文报告名足够独特);词干太短的不认,\n否则 `reports/b.json` 的词干 `b` 会把任何正文都判成引用(用例钉住这条)。\n读不到正文时整条不判,保持原判据,不在读不到时误报。\n\n先测量再动手:全量 35 份 evidence 全部合格,0 违规。零违规时收紧最合适——现在加的是\n一道防漂移的闸,将来才不会又攒出一堆\"有消费者、没人提\"的条目。\n\n登记门禁测试 19 → 24,治理层全量 394(388 过 / 6 跳 / 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-18T01:00:00-07:00"}],"HeadCommit":{"Sha1":"f0d1f11ac7747e845e2781e441cf35bf86717dd5","Message":"chore(reports): 门禁消费回绑 @ 50ea2d6\n\nR9 第二次命中:50ea2d6 又改了 scripts/ 下两个文件,而它们是这份报告声明的输入。\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-18T01:00:11-07:00"},"CompareURL":"luoanwu/platform-governance/compare/a111b6977a361ae62f190375ae1d4a3634ac8fda...f0d1f11ac7747e845e2781e441cf35bf86717dd5","Len":2}...
|
1789718416
|
Edit
Delete
|
|
31056
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"392f0fde4 {"Commits":[{"Sha1":"392f0fde46813c5d061762b8985c74948f6bb088","Message":"docs(计划): 登记 check:gate-flow——真源仓补上「每个门禁的失败信号有谁在看」\n\n治理层 2026-09-14 已为自己建了门禁消费登记并写明病因,真源仓一直没问过这个问题。\n实测 44 个脚本里 12 个既不在 check 链、CI 也不调用,其中三个是真门禁;最实的一处是\nCI 的 image job 构建、生成 SBOM、签名镜像却从不启动它一次,而那六项冒烟正是 D-1 的\n退出条件——且 image-smoke 报告在未登记账里的搁置因此没有出口。\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-18T01:10:55-07:00"}],"HeadCommit":{"Sha1":"392f0fde46813c5d061762b8985c74948f6bb088","Message":"docs(计划): 登记 check:gate-flow——真源仓补上「每个门禁的失败信号有谁在看」\n\n治理层 2026-09-14 已为自己建了门禁消费登记并写明病因,真源仓一直没问过这个问题。\n实测 44 个脚本里 12 个既不在 check 链、CI 也不调用,其中三个是真门禁;最实的一处是\nCI 的 image job 构建、生成 SBOM、签名镜像却从不启动它一次,而那六项冒烟正是 D-1 的\n退出条件——且 image-smoke 报告在未登记账里的搁置因此没有出口。\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-18T01:10:55-07:00"},"CompareURL":"luoanwu/platform-governance/compare/f0d1f11ac7747e845e2781e441cf35bf86717dd5...392f0fde46813c5d061762b8985c74948f6bb088","Len":1}...
|
1789719058
|
Edit
Delete
|
|
31066
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ed4a869bd {"Commits":[{"Sha1":"ed4a869bde4de3243013e74e7f48454e053bd2fa","Message":"docs(框架): 提 FR-7——governance.rules 的 mode 与 ADR-0010 状态的耦合没有执行者\n\nADR-0010 正文写着「在本 ADR 仍为 Proposed 时,mode 固定为 observe」。这句话是整份\n17 条规则注册表**是建议还是约束**的唯一依据。2026-09-18 逐行走读实测:没有任何东西\n在执行它。\n\n governance.rules.schema.json 只把 mode 约束成枚举,管形状不管该是哪个\n check-governance-rules.mjs 校验了 profile 入口、例外到期、enforced 规则须有\n owner、依赖成环等多项,唯独从不判 mode——全文只在\n 成功行里把它打印出来\n generate-governance-status.mjs 按正则读了 ADR 状态,但只回显进报告,不参与判定\n\n两个方向的失效都是静默的:把 mode 翻成 enforced 而 ADR 仍 Proposed 会全绿;ADR 受理\n之后 mode 一直留在 observe 也全绿,17 条规则就此永远停在诊断态,既无提示也无复核期。\n这是「搁置没有出口」,而且落在治理模型的核心开关上。另有一处降级:decisionStatus\n取不到时静默退回 \"Unknown\" 并照常回显,ADR 标题改一个字就会让这条读取无声失效。\n\n请求逐字落实 ADR 已写的那句,不新增政策;不改 schema、不改任何规则的 severity 或\nenforcement、不改 mode 当前取值——今天跑起来仍全绿,只在有人动 mode 或动 ADR 状态时\n才说话。\n\n**本仓未做任何本地修正**:governance.rules.json、其 schema、check-governance-rules.mjs\n与 ADR-0010 四者在 enterprise-platform/runtime/ 下与框架仓逐字相同,本仓改它等于分叉\n框架治理核心,下次同步必冲突。这与 FR-6 的处置不同——那条本仓已本地修正是因为它只在\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-18T01:18:22-07:00"}],"HeadCommit":{"Sha1":"ed4a869bde4de3243013e74e7f48454e053bd2fa","Message":"docs(框架): 提 FR-7——governance.rules 的 mode 与 ADR-0010 状态的耦合没有执行者\n\nADR-0010 正文写着「在本 ADR 仍为 Proposed 时,mode 固定为 observe」。这句话是整份\n17 条规则注册表**是建议还是约束**的唯一依据。2026-09-18 逐行走读实测:没有任何东西\n在执行它。\n\n governance.rules.schema.json 只把 mode 约束成枚举,管形状不管该是哪个\n check-governance-rules.mjs 校验了 profile 入口、例外到期、enforced 规则须有\n owner、依赖成环等多项,唯独从不判 mode——全文只在\n 成功行里把它打印出来\n generate-governance-status.mjs 按正则读了 ADR 状态,但只回显进报告,不参与判定\n\n两个方向的失效都是静默的:把 mode 翻成 enforced 而 ADR 仍 Proposed 会全绿;ADR 受理\n之后 mode 一直留在 observe 也全绿,17 条规则就此永远停在诊断态,既无提示也无复核期。\n这是「搁置没有出口」,而且落在治理模型的核心开关上。另有一处降级:decisionStatus\n取不到时静默退回 \"Unknown\" 并照常回显,ADR 标题改一个字就会让这条读取无声失效。\n\n请求逐字落实 ADR 已写的那句,不新增政策;不改 schema、不改任何规则的 severity 或\nenforcement、不改 mode 当前取值——今天跑起来仍全绿,只在有人动 mode 或动 ADR 状态时\n才说话。\n\n**本仓未做任何本地修正**:governance.rules.json、其 schema、check-governance-rules.mjs\n与 ADR-0010 四者在 enterprise-platform/runtime/ 下与框架仓逐字相同,本仓改它等于分叉\n框架治理核心,下次同步必冲突。这与 FR-6 的处置不同——那条本仓已本地修正是因为它只在\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-18T01:18:22-07:00"},"CompareURL":"luoanwu/platform-governance/compare/392f0fde46813c5d061762b8985c74948f6bb088...ed4a869bde4de3243013e74e7f48454e053bd2fa","Len":1}...
|
1789719506
|
Edit
Delete
|
|
31069
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"58a896f8a {"Commits":[{"Sha1":"58a896f8a4030c0d72fa3b631d8f823f144d1650","Message":"docs(计划): 登记 FR-7 与 gate-flow 推导修正,并订正跨目录待办的 FR 清单\n\n跨目录待办原写「余 FR-6 待受理」,漏了 FR-2 / FR-3——两条 2026-09-12 提出、09-18 复核\n仍成立并补了新证据。现改为四条:FR-2 / FR-3 / FR-6 / FR-7。\n\nFR-7:governance.rules.json 的 mode 与 ADR-0010 状态的耦合没有执行者。ADR 写着「仍为\nProposed 时 mode 固定为 observe」,而 schema 只管枚举、check-governance-rules 只打印\n不判、generate-governance-status 只回显。翻成 enforced 没人拦,ADR 受理后留在 observe\n也没人报,17 条规则会永远停在诊断态。本仓未做本地修正:那四个文件与框架逐字相同。\n\n同轮修了 check:gate-flow 的一处真缺陷:推导在 CI 原文上按名匹配,而工作流里本就有\n带 `pnpm check` 的说明行,没被误判纯属侥幸。已改为先剥注释再匹配。\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-18T01:22:21-07:00"}],"HeadCommit":{"Sha1":"58a896f8a4030c0d72fa3b631d8f823f144d1650","Message":"docs(计划): 登记 FR-7 与 gate-flow 推导修正,并订正跨目录待办的 FR 清单\n\n跨目录待办原写「余 FR-6 待受理」,漏了 FR-2 / FR-3——两条 2026-09-12 提出、09-18 复核\n仍成立并补了新证据。现改为四条:FR-2 / FR-3 / FR-6 / FR-7。\n\nFR-7:governance.rules.json 的 mode 与 ADR-0010 状态的耦合没有执行者。ADR 写着「仍为\nProposed 时 mode 固定为 observe」,而 schema 只管枚举、check-governance-rules 只打印\n不判、generate-governance-status 只回显。翻成 enforced 没人拦,ADR 受理后留在 observe\n也没人报,17 条规则会永远停在诊断态。本仓未做本地修正:那四个文件与框架逐字相同。\n\n同轮修了 check:gate-flow 的一处真缺陷:推导在 CI 原文上按名匹配,而工作流里本就有\n带 `pnpm check` 的说明行,没被误判纯属侥幸。已改为先剥注释再匹配。\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-18T01:22:21-07:00"},"CompareURL":"luoanwu/platform-governance/compare/ed4a869bde4de3243013e74e7f48454e053bd2fa...58a896f8a4030c0d72fa3b631d8f823f144d1650","Len":1}...
|
1789719743
|
Edit
Delete
|
|
31080
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"d5323e2b1 {"Commits":[{"Sha1":"d5323e2b149e012cd3340f330a860c232d285738","Message":"docs(计划): 登记 check:ci-mirror——两条 CI 通道「只差四处必须同步改」此前没有执行者\n\nCLAUDE.md 与镜像文件自己的头注释都写着这条规则,而实测没有任何东西在比对它们。\n规范化后两份 461 行逐行相同,文件层面的差异恰好三类,据此立了 M1—M3 三条判据。\n\n值得有执行者的理由:镜像里那行 GOV_REPORT_RUNNER 是证据来源标注的唯一保证,\n不显式覆盖,这条通道产出的报告会冒充 github-actions 并被 verify-candidate 接受。\n\n顺带查出一处真实漂移但不替人裁决:头注释宣称的差异③「fork 判定改用 gitea.* 上下文」\n在文件里根本不存在。若 act_runner 不如实填充 pull_request.head.repo.full_name,\nQ12-A 的 fork 守卫在这条通道上就是失效的。归 SRE / 框架 Owner,该通道从未启用。\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-18T01:52:23-07:00"}],"HeadCommit":{"Sha1":"d5323e2b149e012cd3340f330a860c232d285738","Message":"docs(计划): 登记 check:ci-mirror——两条 CI 通道「只差四处必须同步改」此前没有执行者\n\nCLAUDE.md 与镜像文件自己的头注释都写着这条规则,而实测没有任何东西在比对它们。\n规范化后两份 461 行逐行相同,文件层面的差异恰好三类,据此立了 M1—M3 三条判据。\n\n值得有执行者的理由:镜像里那行 GOV_REPORT_RUNNER 是证据来源标注的唯一保证,\n不显式覆盖,这条通道产出的报告会冒充 github-actions 并被 verify-candidate 接受。\n\n顺带查出一处真实漂移但不替人裁决:头注释宣称的差异③「fork 判定改用 gitea.* 上下文」\n在文件里根本不存在。若 act_runner 不如实填充 pull_request.head.repo.full_name,\nQ12-A 的 fork 守卫在这条通道上就是失效的。归 SRE / 框架 Owner,该通道从未启用。\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-18T01:52:23-07:00"},"CompareURL":"luoanwu/platform-governance/compare/58a896f8a4030c0d72fa3b631d8f823f144d1650...d5323e2b149e012cd3340f330a860c232d285738","Len":1}...
|
1789721547
|
Edit
Delete
|
|
31099
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"6b045590e {"Commits":[{"Sha1":"6b045590e6ba93dd703453bc478b3b6c879491f3","Message":"docs(计划): 订正 contracts:check 的登记,并登记偏差 #37 / #38\n\n#38:真实 Catalog 的治理判定不在任何自动流里。contracts/scripts/check.mjs 只在\ncontracts check 里,链与 CI 用的都是 check:local。挡它在链外的历史理由(余 6 项待\nCHG-001)经实测已全部通过——又一次「条件早已满足而无人察觉」。\n\n#37:CHG-007 立的「闸门 blocked_by vs 溯源 decided_by」只应用在 facts 的一条事实上,\nrelationships 与 scopes 仍有 4 条阻断声明指向已批准的 DEC-002 / DEC-004,且当时没留\n探测器。改 Catalog 归 Catalog Owner,本轮只登记不改数据;也没给 linter 加探测器,\n因为给一道没人跑的门禁加规则是无用功,次序上要先解决 #38。\n\n同时订正前一轮把 contracts:check 登记成 tool 的错误,并记下本轮一次把并行会话文件\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-18T02:05:35-07:00"}],"HeadCommit":{"Sha1":"6b045590e6ba93dd703453bc478b3b6c879491f3","Message":"docs(计划): 订正 contracts:check 的登记,并登记偏差 #37 / #38\n\n#38:真实 Catalog 的治理判定不在任何自动流里。contracts/scripts/check.mjs 只在\ncontracts check 里,链与 CI 用的都是 check:local。挡它在链外的历史理由(余 6 项待\nCHG-001)经实测已全部通过——又一次「条件早已满足而无人察觉」。\n\n#37:CHG-007 立的「闸门 blocked_by vs 溯源 decided_by」只应用在 facts 的一条事实上,\nrelationships 与 scopes 仍有 4 条阻断声明指向已批准的 DEC-002 / DEC-004,且当时没留\n探测器。改 Catalog 归 Catalog Owner,本轮只登记不改数据;也没给 linter 加探测器,\n因为给一道没人跑的门禁加规则是无用功,次序上要先解决 #38。\n\n同时订正前一轮把 contracts:check 登记成 tool 的错误,并记下本轮一次把并行会话文件\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-18T02:05:35-07:00"},"CompareURL":"luoanwu/platform-governance/compare/d5323e2b149e012cd3340f330a860c232d285738...6b045590e6ba93dd703453bc478b3b6c879491f3","Len":1}...
|
1789722339
|
Edit
Delete
|
|
31112
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"7433af77e {"Commits":[{"Sha1":"7433af77e643c41f2ccb34fb8aebe363ec76e306","Message":"test(治理): L6 的判定搬进 core 并补负向用例——它此前是唯一零覆盖的一条\n\n一致性门禁 L1—L5 / L7—L13 的判定都在 lib/workspace-consistency-core.mjs 里、各有负向\n用例,**唯独 L6(worktree 两侧 gitdir)与文件系统读取缠在 check-workspace-consistency.mjs\n里**,全量扫描确认 tests/ 里没有任何一条用例触达它。它「能工作」的唯一证据是恰好没在\n实数据上报错——而「没报错」与「判不出来」在外部看来一模一样。\n\n本轮只搬不改:IO 函数改为只收集事实,判定交给新的纯函数 evaluateWorktreeGitdirs。\n**判词逐字未变,改前改后门禁 --json 输出实测完全相同**(status / counts / issues 三者\n逐字相等,prunableWorktrees 仍为 5、L9 仍为 1)。\n\n补 8 条负向用例,覆盖两个方向的全部分支:\n 方向一 .git 为空 / 指向不存在的登记 / 登记反指不回来(含反指读不出时须写「(空)」);\n 三种坏法互斥,前一种命中不再叠加后一种\n 方向二 gitdir 为空即红;目标还在就跳过(反指归方向一,不重复报);\n **目标没了且旁边没有同名工作树 = prunable,只计数不报**——那是 git worktree\n prune 的日常;目标没了但工作树就在旁边 = 失联,判红且不计入 prunable\n\n顺带核实两条初测假阳性,记在这里免得再查一遍:L9 的判定其实在 core 里且有用例\n(composeProjectName / composeProjectCollisions),只是测试里不出现「L9」这个字面量;\nL0 与 L28 是正则误匹配(一个字符类、一处注释里的行号)。\n\n一致性门禁测试 34 → 42,治理层全量 389 → 401(395 过 / 6 跳 / 0 失败);\n统一入口阻断性门禁 11/11。\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-18T02:39:16-07:00"},{"Sha1":"1e6a813a72945400129128947654df4ecdc8849d","Message":"docs(回灌): U-39 / U-40——发布物与源码同版本不同内容,且 provenance 无 gitSha\n\n新增 §2E 第 5 轮条目(基础基座 → 基础设施)。采集自 OS 执行「内核退回 pin 立项」B1\n(contracts exact pin @juhai/kernel@0.22.0)时对接已发布客户端包的实测。\n\nU-39 发布物与其源码同版本不同内容,peer 只是露出来的一角。已发布的\n @juhai/client-fact@1.0.0-rc.3 声明 peer @juhai/kernel: 0.16.1(发布物自证),而控制面仓\n 同版本源码声明 0.22.0——2026-09-17 框架同步只改了 runtime/clients/fact/package.json 未重发。\n 进一步拆开发布物:dist 里没有 Authorization 回查鉴权,源码 reader.ts:31 却发\n Bearer ${token}。消费侧对此完全不可见:pnpm 对未满足 peer 只打一行 WARN 就继续装。\n → 平台侧动作:重发 rc.4 携带正确 peer,发布前确认 dist 与源码同一提交。\n 基座侧已自保:新增 PEER_UNSATISFIED 判据 + 五字段登记(期限 2026-12-18)。\n\nU-40 本地旁路发布的发布物不可对账到提交。registry 上 rc.3 的 provenance.json 为\n runner:\"local\" / reports:[] / gitSha:\"\"——空字符串。任何消费者都无法验证装到的包出自哪次\n 提交,U-39 那种「同版本不同内容」因此无法被机器发现。这比 peer 错一版严重:peer 至少还有\n 一个可比的值,gitSha 为空是判据缺席。\n → 平台侧动作:发布物 provenance.json 必须带真实 gitSha,本地旁路也不得留空——旁路可以解除\n CI 身份检查,但不应连「这是哪次提交构建的」都放弃。\n\n两条均标 🔴 下层缺口,阻塞于平台发布列车(G-12 计费)。基座侧不停等:按立项 §6 三条出路\n裁为 ③(登记偏差 + 加判据),B2 / B3′ 继续推进。\n\n一致性门禁复跑:合计 1 条,仅 L9(8 仓共用 compose project api-nestjs),与本次改动无关——\n它正是 OS 在 framework-criteria.json 里登记为 missing 的框架 F14。\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-18T02:39:13-07:00"}],"HeadCommit":{"Sha1":"7433af77e643c41f2ccb34fb8aebe363ec76e306","Message":"test(治理): L6 的判定搬进 core 并补负向用例——它此前是唯一零覆盖的一条\n\n一致性门禁 L1—L5 / L7—L13 的判定都在 lib/workspace-consistency-core.mjs 里、各有负向\n用例,**唯独 L6(worktree 两侧 gitdir)与文件系统读取缠在 check-workspace-consistency.mjs\n里**,全量扫描确认 tests/ 里没有任何一条用例触达它。它「能工作」的唯一证据是恰好没在\n实数据上报错——而「没报错」与「判不出来」在外部看来一模一样。\n\n本轮只搬不改:IO 函数改为只收集事实,判定交给新的纯函数 evaluateWorktreeGitdirs。\n**判词逐字未变,改前改后门禁 --json 输出实测完全相同**(status / counts / issues 三者\n逐字相等,prunableWorktrees 仍为 5、L9 仍为 1)。\n\n补 8 条负向用例,覆盖两个方向的全部分支:\n 方向一 .git 为空 / 指向不存在的登记 / 登记反指不回来(含反指读不出时须写「(空)」);\n 三种坏法互斥,前一种命中不再叠加后一种\n 方向二 gitdir 为空即红;目标还在就跳过(反指归方向一,不重复报);\n **目标没了且旁边没有同名工作树 = prunable,只计数不报**——那是 git worktree\n prune 的日常;目标没了但工作树就在旁边 = 失联,判红且不计入 prunable\n\n顺带核实两条初测假阳性,记在这里免得再查一遍:L9 的判定其实在 core 里且有用例\n(composeProjectName / composeProjectCollisions),只是测试里不出现「L9」这个字面量;\nL0 与 L28 是正则误匹配(一个字符类、一处注释里的行号)。\n\n一致性门禁测试 34 → 42,治理层全量 389 → 401(395 过 / 6 跳 / 0 失败);\n统一入口阻断性门禁 11/11。\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-18T02:39:16-07:00"},"CompareURL":"luoanwu/platform-governance/compare/6b045590e6ba93dd703453bc478b3b6c879491f3...7433af77e643c41f2ccb34fb8aebe363ec76e306","Len":2}...
|
1789724358
|
Edit
Delete
|
|
31113
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"72c053ccb {"Commits":[{"Sha1":"72c053ccbb2b4effb1451b6b61e69faf9c313fd5","Message":"docs(治理): README 订正——「判定逻辑在 core」这句话此前对 L6 并不成立\n\n第 49 行写着「判定逻辑在 workspace-consistency-core.mjs,夹具用例 19/19」。前半句对\nL6 是假的(它的判定与文件系统读取缠在 IO 脚本里、测试零覆盖),后半句的 19 也早已陈旧。\n\nL6 的判定已于同日搬进 core 并补 8 条用例,这句话现在成立了;数字改为当前的 42,\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-18T02:39:56-07:00"}],"HeadCommit":{"Sha1":"72c053ccbb2b4effb1451b6b61e69faf9c313fd5","Message":"docs(治理): README 订正——「判定逻辑在 core」这句话此前对 L6 并不成立\n\n第 49 行写着「判定逻辑在 workspace-consistency-core.mjs,夹具用例 19/19」。前半句对\nL6 是假的(它的判定与文件系统读取缠在 IO 脚本里、测试零覆盖),后半句的 19 也早已陈旧。\n\nL6 的判定已于同日搬进 core 并补 8 条用例,这句话现在成立了;数字改为当前的 42,\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-18T02:39:56-07:00"},"CompareURL":"luoanwu/platform-governance/compare/7433af77e643c41f2ccb34fb8aebe363ec76e306...72c053ccbb2b4effb1451b6b61e69faf9c313fd5","Len":1}...
|
1789724399
|
Edit
Delete
|
|
31122
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"54738a32d {"Commits":[{"Sha1":"54738a32d101f97cc5dd3a5bca7ea426dceea9c6","Message":"feat(治理): L9 的完整仓名单带进 JSON——裁决输入不该每次重新推导\n\nL9 目前是全工作区唯一在报的那条,挂在 N-11 的裁决上,而裁决要回答的正是「哪些仓各自\n补 compose `name:`」。判定本来就算出了完整名单(composeProjectCollisions 返回\nrepos / files),但建 issue 时被丢掉:消息里只写前三个加「等 N 个」,JSON 里一个都没有。\n于是每次想知道是哪八个,都得重新推导一遍。\n\n`issue()` 增一个可选 extra 参数,只用于把**判定已算出、消息里放不下**的结构化数据带进\nJSON;没有 extra 的检查一个字段都不多(用例钉住 L13 的键仍是四个)。\n\n实测:门禁现在报出的 8 个仓与我按同一口径(排除 29 个工作树、按 .git 目录归仓)独立\n重推的结果完全一致——数字员工OS、知识云、AI项目与工单、AI人事系统、设备云、巨嗨智服、\n巨嗨报价系统、嗨赞造意/image-generation。counts 未变(total 1 / L9 1)。\n\n补两条用例:L9 的发现必须携带 repos 且数量与消息声称的一致、不得重复、files 不少于仓数;\n以及 issue() 的默认形状不变。前者守的是「有冲突时名单不得丢」,不是「必须有冲突」——\nL9 清零后它自然为空。\n\n一致性门禁测试 42 → 44,治理层全量 397 过 / 6 跳 / 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-18T02:46:51-07:00"}],"HeadCommit":{"Sha1":"54738a32d101f97cc5dd3a5bca7ea426dceea9c6","Message":"feat(治理): L9 的完整仓名单带进 JSON——裁决输入不该每次重新推导\n\nL9 目前是全工作区唯一在报的那条,挂在 N-11 的裁决上,而裁决要回答的正是「哪些仓各自\n补 compose `name:`」。判定本来就算出了完整名单(composeProjectCollisions 返回\nrepos / files),但建 issue 时被丢掉:消息里只写前三个加「等 N 个」,JSON 里一个都没有。\n于是每次想知道是哪八个,都得重新推导一遍。\n\n`issue()` 增一个可选 extra 参数,只用于把**判定已算出、消息里放不下**的结构化数据带进\nJSON;没有 extra 的检查一个字段都不多(用例钉住 L13 的键仍是四个)。\n\n实测:门禁现在报出的 8 个仓与我按同一口径(排除 29 个工作树、按 .git 目录归仓)独立\n重推的结果完全一致——数字员工OS、知识云、AI项目与工单、AI人事系统、设备云、巨嗨智服、\n巨嗨报价系统、嗨赞造意/image-generation。counts 未变(total 1 / L9 1)。\n\n补两条用例:L9 的发现必须携带 repos 且数量与消息声称的一致、不得重复、files 不少于仓数;\n以及 issue() 的默认形状不变。前者守的是「有冲突时名单不得丢」,不是「必须有冲突」——\nL9 清零后它自然为空。\n\n一致性门禁测试 42 → 44,治理层全量 397 过 / 6 跳 / 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-18T02:46:51-07:00"},"CompareURL":"luoanwu/platform-governance/compare/72c053ccbb2b4effb1451b6b61e69faf9c313fd5...54738a32d101f97cc5dd3a5bca7ea426dceea9c6","Len":1}...
|
1789724816
|
Edit
Delete
|
|
31123
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a7075e40e {"Commits":[{"Sha1":"a7075e40e9aed8fbe69edb7fb7f0ebc05e477214","Message":"docs(计划): 登记 L6 / L9 两处补强,并订正自己提交信息里的一句过头话\n\nL6 此前是唯一判定与 IO 缠在一起、测试零覆盖的规则,已搬进 core 并补 8 条用例,\n只搬不改、输出逐字相同;README 那句「判定逻辑在 core」此前对它是假的,已订正。\n\nL9 的完整仓名单现在进 JSON。但我在那条提交信息里写的「每次都得重新推导」过头了:\nN-11 正文 2026-09-17 就手写了这 8 个仓名。真实缺口是名单只有手抄的一份、门禁不产\n机器形态,两者可以无声分叉。本轮独立重推的 8 个与 N-11 手抄的完全一致。\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-18T02:47:33-07:00"}],"HeadCommit":{"Sha1":"a7075e40e9aed8fbe69edb7fb7f0ebc05e477214","Message":"docs(计划): 登记 L6 / L9 两处补强,并订正自己提交信息里的一句过头话\n\nL6 此前是唯一判定与 IO 缠在一起、测试零覆盖的规则,已搬进 core 并补 8 条用例,\n只搬不改、输出逐字相同;README 那句「判定逻辑在 core」此前对它是假的,已订正。\n\nL9 的完整仓名单现在进 JSON。但我在那条提交信息里写的「每次都得重新推导」过头了:\nN-11 正文 2026-09-17 就手写了这 8 个仓名。真实缺口是名单只有手抄的一份、门禁不产\n机器形态,两者可以无声分叉。本轮独立重推的 8 个与 N-11 手抄的完全一致。\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-18T02:47:33-07:00"},"CompareURL":"luoanwu/platform-governance/compare/54738a32d101f97cc5dd3a5bca7ea426dceea9c6...a7075e40e9aed8fbe69edb7fb7f0ebc05e477214","Len":1}...
|
1789724855
|
Edit
Delete
|
|
31141
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/claude/zealous-tu-6f0fca
|
0
|
|
1789740931
|
Edit
Delete
|
|
31142
|
5
|
5
|
5
|
117
|
0
|
0
|
refs/heads/claude/zealous-tu-6f0fca
|
0
|
{"Commits":[{"Sha1":"031878b2a {"Commits":[{"Sha1":"031878b2a7dbd2e2021b6dd71b0197e50cec3c96","Message":"docs(计划): 第四处同病改判已修(08c3788),并订正本条原先给错的一个修法\n\n登记时给了两个修法,取的是「把写报告挪到前置校验之后」;另一个「直接删掉占位写」被接手\n会话否掉,理由成立,本条一并订正:「跑起来但没跑完」确实该在盘上留 RUN_NOT_COMPLETED 而\n不是上一轮的 partial——这是用例自己写报告带来的责任,和「上轮结论已被后续提交推翻」不是\n同一个事实,不能用 check:evidence 判过期替代。\n\n实现是把那句抽成 markRunStarted(),调用点挪到模块库白名单通过、真实连库、API 子进程\n/health 就绪之后。两个方向都做了负向实测:同一条件下旧代码毁报告(sha256 变化),新代码\n测试照样失败而报告逐字节不变;正向确认 t+85s 兜底仍写 RUN_NOT_COMPLETED。\n\n受影响四份已重跑回绑 dfd4832(全绑 08c3788 / dirty=false,结果与修复前一致,说明动的只是\n写报告的时机);runbook §7 收尾同步改成已修(925eee8)。\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:13:53-07:00"},{"Sha1":"f7a6b8eb62651f612a8a0e9666b22a5413b4fb1a","Message":"docs(计划): 登记第四处「前置失败销毁好证据」——revocation-sla 由用例自己在 beforeAll 写 failed\n\nadda76a 把三个 runner(runtime / UI / 双后端差分)统一改成前置失败即退出、不碰报告,\n本表上一条据此记「三处同病」。复核接手会话的重跑计划时发现同族还有第四处,且不在那\n三个 runner 里:revocation-sla.latest.json 的写入者是用例自己,不是 runner。\n\n要害是写入时机。runtime/test/e2e/revocation-sla.test.ts:68 在 beforeAll 的第一句就\n无条件写下 status:failed / reason:RUN_NOT_COMPLETED,下一句才做 isolated() 库名校验\n(mainline-support.ts:11 要求 /platform_\u003ckind\u003e_(ms23|test|ci))。先毁证据再校验前置,\n恰是 adda76a 所确立口径的反面。\n\n触发面比「跑主线验收」宽:runtime/test 是工作区包 platform-tests,pnpm\nruntime:check:runtime 第 5 步的 turbo run test 就会跑到它。runbook §7 那句「前置守卫\n段已修复,但跑到一半失败仍会写 failed」对本处不成立——连跑到一半都不需要。\n\n当日由接手会话实测复现:七个模块库建成 platform_\u003cm\u003e_acc0918 后 e2e/chaos 整片失败,\n其独立检出里那份报告已被清成 RUN_NOT_COMPLETED 绑 46265a6;主工作区绑 765300b 的\npartial 因其在独立检出里跑而幸存。连带结论是七个模块库后缀只能是 ms23 / test / ci,\n且 check:runtime 与 mainline:check 本就该共用同一批库。\n\n本轮只登记不修:六份验收报告的重跑已移交主会话并在其独立检出里进行,改同一批文件必\n撞车。真源仓侧的代码修正与 runbook §7 的措辞订正留给接手会话。全程只读,未跑门禁、\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-18T02:04:54-07:00"}],"HeadCommit":{"Sha1":"031878b2a7dbd2e2021b6dd71b0197e50cec3c96","Message":"docs(计划): 第四处同病改判已修(08c3788),并订正本条原先给错的一个修法\n\n登记时给了两个修法,取的是「把写报告挪到前置校验之后」;另一个「直接删掉占位写」被接手\n会话否掉,理由成立,本条一并订正:「跑起来但没跑完」确实该在盘上留 RUN_NOT_COMPLETED 而\n不是上一轮的 partial——这是用例自己写报告带来的责任,和「上轮结论已被后续提交推翻」不是\n同一个事实,不能用 check:evidence 判过期替代。\n\n实现是把那句抽成 markRunStarted(),调用点挪到模块库白名单通过、真实连库、API 子进程\n/health 就绪之后。两个方向都做了负向实测:同一条件下旧代码毁报告(sha256 变化),新代码\n测试照样失败而报告逐字节不变;正向确认 t+85s 兜底仍写 RUN_NOT_COMPLETED。\n\n受影响四份已重跑回绑 dfd4832(全绑 08c3788 / dirty=false,结果与修复前一致,说明动的只是\n写报告的时机);runbook §7 收尾同步改成已修(925eee8)。\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:13:53-07:00"},"CompareURL":"luoanwu/platform-governance/compare/58a896f8a4030c0d72fa3b631d8f823f144d1650...031878b2a7dbd2e2021b6dd71b0197e50cec3c96","Len":2}...
|
1789740931
|
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
|