| content |
{"Commits":[{"Sha1":"a8c2c315c {"Commits":[{"Sha1":"a8c2c315c5987714bc084f534c364ca525639562","Message":"chore(governance): 清扫后重跑统一门禁入口并回写报告\n\n阻断性 7/7 通过；仅记录 3 道仍失败，但内容已变：\ncheck-workspace-consistency 22 → 4（L8 1 / L9 2 / L10 1），\ncheck-domain-layer 19 → 16（D3 三条已关），audit-platform-openings 5 条不变。\n\n剩下 25 条没有一条能由执行者单方面关闭：L8 要重做 CHG-001 补丁并重新基线；L9 两条\n卡在\"api-nestjs 与 enterprise-idp 两个 project 的共用卷里数据属于谁\"；L10 最后一条\n在 active 的 Scope 仓内，而该仓正因\"收尾提交连带改文档\"被判红，随手改一句话正好\n制造它警告的失败；D5 = CHG-007（材料齐备、模拟器绿，等 Catalog Owner）；D9 等 PF-04\n阶段 2；D2 / D4 / D6 / D7 / D10 是跨层的数据与装载动作；D11 要给工单 20 道、设备云\n17 道门禁各补负向探针；audit-platform-openings 五条等 E1 或那次 A / B / C 取舍。\n\n两份报告不带 provenance，工作树中另一会话的三份在途改动不影响本次结论。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-15T03:07:04-07:00"},{"Sha1":"cc81a45fecbf4ea14e8b9198270061f14ab89544","Message":"docs(governance): 企业控制面的横向梳理、十八个派生仓的移除路径、门禁清扫记录\n\n三份只读盘点，均不改 Catalog、不改模块状态、不下裁决。\n\n- 企业控制面完整梳理：把目录、真源、规则落点、Catalog 登记、门禁、运行与缺口\n 合到一张表上。实测 18 个派生仓的独有规则已全部迁出（模块域 6、契约包域 9、\n 网关与观测两处由组件配置承接），并标出六处已被事实推翻的旧陈述——README 的\n 架构图六框表、项目完整能力表 E02/E06、CHG-003 材料的机器事实基线。\n\n- 十八个派生仓的移除路径：把\"移除\"拆成冻结写入 / 解除登记依赖 / 物理删除三件事。\n 历史安全性已不是问题（18 仓全部有 Gitea 远端且 origin/main == HEAD，另有 18 份\n bundle）；94% 的体积与治理无关（18 GB / 947,810 个磁盘文件，受控文件只有 5,486\n 个）。按 delta 语义逐仓模拟 CHG-002/003/006 合并后，9 个仓证据残余归零、9 个不归零，\n 此前无任何文档给过这个分档。四类阻塞里只有 directory 双向绑定没有任何变更包覆盖。\n\n- 三道仅记录门禁的清扫记录：本轮清扫的执行记录与未关项的归属。\n\n当日实跑推翻一条旧记录：CHG-002/003/006/007 四个模拟器全部 passed、formalMutated\nfalse，而 CHG-006 README 记的 2026-09-14 实测是三个 blocked、\"CHG-001 重做是前置\"。\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-15T03:05:39-07:00"},{"Sha1":"edfd2ec2814c85007a5019d02e1d6b0d0b258061","Message":"fix(governance): 三道仅记录门禁的清扫 —— 报出来的每一条都应当是能直接去改的\n\n`check-workspace-consistency` 22 → 4。三道 report-only 门禁长期全红，正落在\n`门禁消费登记.json` 自己写的那句判词里：门禁能跑、结果无人看，于是稳定在\"永远红\"\n或\"永远绿\"，两种都不携带信息。\n\n门禁改造两处：\n\n- L3 / L10 放过冻结派生仓。13 个 archived-20260910 仓由 check-archived-derived-repos\n （阻塞档）断言 tag = HEAD ∧ 工作树 clean，改一个字节它就红——也就是说 L3 / L10 在\n 那里报出来的东西没有一条能直接去改，与 L10 自己立的收敛原则正相反。新增\n frozenDerivedRepoPrefixes / isFrozenDerivedRepo，只放过 archived 一档：active 的\n 5 个仍在视野内，清扫后剩下的唯一一条 L10 就在其中，没被误放过。\n\n- 冻结物的二次替换由 L2 改归 L8。L2 要求改掉字符串、L7 要求字节与 sha256 相符，\n 同一份文件两个相反的要求。L8（摘要相符、内容却仍是旧布局）本来就是为这种情形\n 存在的，其处置口径——重做变更包并重新基线——才执行得了。staleLayoutHits 增收\n 二次替换，L2 跳过审批记录登记的冻结物。该条仍是红的，只是红在正确的位置。\n\nD3 的前提订正：旧判据照抄契约 linter 的 productId === app.id ∧ productVersion ===\napp.version，而 DEC-009（2026-09-12 批准）写明\"三清单独立 Schema / Owner / 版本，\n跨清单只存引用\"——把一条已批准的裁决反过来写。linkSatisfiability 按新前提重写，\n唯一剩下的不可满足情形是\"产品列表里多于一个产品\"。契约侧的规则重写另仓提交。\n\n正文订正 22 处：DEC-010 / 031 / 032 于 2026-09-10 批准，其余 27 条于 2026-09-12\n决策会批准，各处按裁决原文改写，把\"卡在裁决\"与\"卡在没做\"分开。集中观测那条不是\n滞后而是被事实推翻——Collector 已在 stack/otel 部署并由 check:otel 守着。\n\n五个文件加 `一致性门禁豁免: L10` 并写明理由：两份 DEC 草案与待裁决架构事项逐条\n转录裁决原文，其中\"Workload Identity 待 DEC-024 后复评\"是裁决自带的条件条款，不是\n对 DEC-024 审批状态的断言，不得为了让门禁变绿而改写。\n\n回灌台账 U-33 关闭，两次订正的轨迹保留：第一次把\"规则写错了\"误判成\"各仓没补数据\"，\n第二次才查到规则与已批准的裁决冲突——判定前提本身可能是错的，这类缺口按\"谁没做\"\n派活会一直派错人。\n\n核验：tests/workspace-consistency 19 → 24，tests/domain-layer 47/47，平台治理/基础\n全量 302（297 通过 / 5 跳过）；run-foundation-gates 阻塞档 7/7；\ncheck-archived-derived-repos 13/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-15T03:05:31-07:00"}],"HeadCommit":{"Sha1":"a8c2c315c5987714bc084f534c364ca525639562","Message":"chore(governance): 清扫后重跑统一门禁入口并回写报告\n\n阻断性 7/7 通过；仅记录 3 道仍失败，但内容已变：\ncheck-workspace-consistency 22 → 4（L8 1 / L9 2 / L10 1），\ncheck-domain-layer 19 → 16（D3 三条已关），audit-platform-openings 5 条不变。\n\n剩下 25 条没有一条能由执行者单方面关闭：L8 要重做 CHG-001 补丁并重新基线；L9 两条\n卡在\"api-nestjs 与 enterprise-idp 两个 project 的共用卷里数据属于谁\"；L10 最后一条\n在 active 的 Scope 仓内，而该仓正因\"收尾提交连带改文档\"被判红，随手改一句话正好\n制造它警告的失败；D5 = CHG-007（材料齐备、模拟器绿，等 Catalog Owner）；D9 等 PF-04\n阶段 2；D2 / D4 / D6 / D7 / D10 是跨层的数据与装载动作；D11 要给工单 20 道、设备云\n17 道门禁各补负向探针；audit-platform-openings 五条等 E1 或那次 A / B / C 取舍。\n\n两份报告不带 provenance，工作树中另一会话的三份在途改动不影响本次结论。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-15T03:07:04-07:00"},"CompareURL":"luoanwu/platform-governance/compare/1a4d98035c3dd75f82c2ac63f1c7e557ddb764d6...a8c2c315c5987714bc084f534c364ca525639562","Len":3}... |