|
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
|
|
30872
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"df678ac14 {"Commits":[{"Sha1":"df678ac14f88628a7bc48ce3b53e248f1b257e8b","Message":"chore(reports): check:evidence 回绑 @ e9d0779\n\n37 份已登记（+2：runtime-governance error、conformance-differential warn）、34 份新鲜、\n11 份未登记且全部有处置说明、evidenceUnaccounted=0。3 条 warn 为待重跑的验收报告。\n\nCo-Authored-By: Claude Opus 5 \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:14:15-07:00"},{"Sha1":"e9d07790cee2a6780ecc755cb6b6efe70890a727","Message":"feat(governance): 未登记的报告也要逐条记账——把散文口径搬成机器判据，并订正两处误归类\n\ncheck:evidence 的 SCOPE_UNDECLARED 是 info，本身不拦任何东西。于是「未登记作用域」\n这一类可以无声增长，而它恰恰是新鲜度门禁完全看不见的那部分：实测 48 份报告里 13 份\n在此，占 27%。这 13 份为什么不登，此前只写在 evidence-scopes.json 的 note 散文里，\n没有任何机器核对——明天多出一份新报告，它会自动落进这个黑箱，全链门禁一片绿。\n\n按例外机制的同一纪律（G-13：自带出口）把口径搬成逐条登记的 undeclared：\n UNDECLARED_UNACCOUNTED 报告存在，既无作用域也无账（新洞的唯一入口，判红）\n UNDECLARED_STALE 账指向的报告已登记作用域，或文件已不存在（判红）\n UNDECLARED_INCOMPLETE 缺 report/class/reason/recordedAt/resolveBy，或 class 非法\nclass 只允许 self / aggregate / provenance-missing / one-off-snapshot / no-generator。\n记账不是豁免：后两类的出口只有「补生成脚本后转正式登记」或「退役该报告」二选一。\n\n逐份走读生成脚本时发现 note 的 ③「聚合报告」类有两处归错，两份因此一直不受监控：\n runtime-governance 不聚合任何报告，直接走读 apps/ 源码与两份 prisma schema\n 判租户接线、outbox 事务、直写发布；纯静态零容器 → error\n conformance-differential 在 apps/api-nestjs 真跑 vitest，用例同时 import 了\n NestJS 与 Fastify 两个后端的装配；要真 DB → warn\n两份均已转入 entries（35 → 37 条），③ 实际只剩 governance 与 governance-status。\n\nclass=self 不查文件存在性：本门禁的报告是判定跑完之后才写的，判定当时它可以合法地\n不存在。这是集成用例抓出来的——起初一视同仁地查，临时仓第一次运行就被自己判红。\n\n门禁测试 277 → 283（新增 6 条负向用例，含「新报告悄悄落进 reports/ 必须判红」的\n集成证明）。pnpm check 全链通过；check:evidence 37 份已登记、34 份新鲜、11 份未登记\n且全部有处置说明、0 份无说明。余 3 份过期是注释提交 c9e0f59 落进验收作用域所致，\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:13:43-07:00"}],"HeadCommit":{"Sha1":"df678ac14f88628a7bc48ce3b53e248f1b257e8b","Message":"chore(reports): check:evidence 回绑 @ e9d0779\n\n37 份已登记（+2：runtime-governance error、conformance-differential warn）、34 份新鲜、\n11 份未登记且全部有处置说明、evidenceUnaccounted=0。3 条 warn 为待重跑的验收报告。\n\nCo-Authored-By: Claude Opus 5 \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:14:15-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/c9e0f59d11a533e7e5e3386f80eff8fb6d6ba6c8...df678ac14f88628a7bc48ce3b53e248f1b257e8b","Len":2}...
|
1789715664
|
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
|
|
30882
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"0abd15c28 {"Commits":[{"Sha1":"0abd15c28dd2b92c583289934db660363b202fd4","Message":"chore(reports): check:evidence 回绑 @ 34fresh\n\n37 份已登记、34 份新鲜、0 error；余 3 份过期为需真实容器重跑的验收报告\n（runtime-acceptance / mainline-acceptance / revocation-sla，warn 按设计）。\n\nCo-Authored-By: Claude Opus 5 \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:28:32-07:00"},{"Sha1":"a4b3d356f9d2f7a831198787a5b19194f4f763c8","Message":"chore(reports): 双后端差分验收重跑回绑 @ 746f323\n\n本轮把 conformance-differential 从「未登记的聚合报告」订正为登记条目后，它第一次\n被新鲜度门禁判为过期——触发者正是同轮改到的 check-conformance-differential.mjs，\n说明登记的作用域是对的。真实 DB + Redis 重跑：7 checkpoints × 2 backends，\n逐字段 0 differences。\n\nCo-Authored-By: Claude Opus 5 \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:28:10-07:00"},{"Sha1":"746f323c203531c4ced5f3ca60ea29a4c53c7c4d","Message":"chore(reports): 工作台两份快照回绑 @ adda76a\n\nrunbook §7 的订正落在运维快照作用域内（docs/runbook.md），经 reports:rebind 在\nHEAD 的干净检出里重跑，两份同源快照一并带回。\n\nCo-Authored-By: Claude Opus 5 \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:27:33-07:00"},{"Sha1":"adda76acfd8fa046e1f2a320c15b5384b4ddef73","Message":"fix(runtime): 前置守卫失败不得覆盖验收报告，并补「一模块一库」检查\n\n按 docs/runbook.md §7 的配方逐字重跑 runtime 验收，当场复现两个缺陷。\n\n一、配方本身是错的。§7 只写了 DATABASE_URL 与 REDIS_URL，而七个模块的\nprisma/schema.prisma 各自写死 url = env(\"DATABASE_URL_\u003cMODULE\u003e\")。照它执行时，\n前两步 nestjs/fastify-migrate-deploy 会通过，第三步 migrate-status 才以\nPrisma P1012 \"Environment variable not found\" 失败——报错指向 wasm 校验，\n完全看不出是环境没配齐。§7 已补齐七个变量，并写明 prepare-mainline.mjs\n只供给主线验收要的 5 个（fact/permission/audit/owner/consumer），差的四个要自己建。\n\n二、更要紧的：那次失败把 runtime-acceptance.latest.json 覆盖成了 status:failed。\n775/775 那份真实结论就此丢失，靠 git checkout 才救回——差一点被当作真实回归提交上去。\n根因是三个 runner 都无条件 writeFileSync：前置守卫失败意味着**验收根本没跑**，\n此时写一份 failed 报告不是诚实，是用操作者的环境问题顶替代码的结论，\n并且顺手销毁了上一次真的跑过的证据。三个 runner 统一改为前置失败即退出、不碰报告：\n check-runtime-acceptance 实测：报告 sha256 前后一致\n check-ui-acceptance 实测：缺 REDIS_URL 时报告 sha256 前后一致\n check-conformance-differential 实测：同上\n\n新增 preflightModuleDatabases + requiredModuleDatabaseEnvNames，把缺失的七个\n变量在动任何东西之前一次列清。变量名**现取自各模块 prisma/schema.prisma**，\n不写死清单：模块增减自动跟上，也避免抄错 ai-gateway 那个没有下划线的\nDATABASE_URL_AIGATEWAY。该检查只接进 runtime 验收——UI 与差分验收跑的是\n两个 app，不走一模块一库。\n\npnpm 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-18T00:26:48-07:00"}],"HeadCommit":{"Sha1":"0abd15c28dd2b92c583289934db660363b202fd4","Message":"chore(reports): check:evidence 回绑 @ 34fresh\n\n37 份已登记、34 份新鲜、0 error；余 3 份过期为需真实容器重跑的验收报告\n（runtime-acceptance / mainline-acceptance / revocation-sla，warn 按设计）。\n\nCo-Authored-By: Claude Opus 5 \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:28:32-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/df678ac14f88628a7bc48ce3b53e248f1b257e8b...0abd15c28dd2b92c583289934db660363b202fd4","Len":4}...
|
1789716516
|
Edit
Delete
|
|
30883
|
16
|
5
|
16
|
86
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"4bb59f1fa {"Commits":[{"Sha1":"4bb59f1faa6737e1d679f5715a0c213b46e020a8","Message":"fix(logs): 优化双击选中并稳定查找框布局\n\n- 参考 VS Code 的文本边界规则，支持连续中文和中英数字整段双击选中\n- 跨查找高亮节点建立原生选区，保留复制、选区查找和横向滚动定位\n- 按查找框宽度预留计数区域，避免加载提示及匹配数量切换挤动按钮\n- 补充选词对照测试、离屏交互与逐帧布局回归，并更新日志帮助文档\n\n验证：\n- npm run typecheck\n- npx vitest run src/features/logs/logWordSelection.test.ts（5 项通过）\n- npm run check:knowledge\n- node scripts/test-log-viewer-browser.mjs --selection\n- node scripts/test-log-viewer-browser.mjs --find\n","AuthorEmail":"228834386@qq.com","AuthorName":"starry","CommitterEmail":"228834386@qq.com","CommitterName":"starry","Timestamp":"2026-09-18T14:59:03+08:00"},{"Sha1":"6ffe247b3198442b9a270c16b88e866f7560deb6","Message":"fix(logs): 支持查找框调宽并取消匹配总量截断\n\n- 移除查找栏左侧收缩图标，增加左右拖拽调宽、边界限制及双击复原\n- 自动续查到全文结束，支持同一行从原始列继续搜索，不丢失两万项之后的命中\n- 使用分块数字坐标保存结果，仅为可见行生成高亮，避免每页复制全部结果\n- 优先定位当前阅读位置附近的命中，支持文件底部查找与完整首尾循环\n- 同步帮助文档及回归夹具\n\n验证：\n- npm run build（包含 typecheck）\n- 77 项日志相关测试\n- 查找栏离屏测试：拖拽、24050 项全文计数、底部定位与首尾循环\n- 原有日志滚动离屏回归\n- npm run check:knowledge\n- git diff --check\n\n实际操作台视觉和拖拽手感保留人工验收。\n","AuthorEmail":"228834386@qq.com","AuthorName":"starry","CommitterEmail":"228834386@qq.com","CommitterName":"starry","Timestamp":"2026-09-18T13:41:38+08:00"},{"Sha1":"931d1e3cd2263189b2c0eb592436c8b69ad455d0","Message":"feat(logs): 对齐 VS Code 查找栏并移除文件列表搜索\n\n- 删除日志文件列表搜索框及其过滤状态，保留快速打开和全局搜索\n- 按参考图实现正文右上角紧凑查找栏，支持大小写、全字、正则、选区与键盘导航\n- 自动续查并按具体出现次数计数和定位，限制缓存并明确展示未完整计数\n- 隔离正则线程并支持超时取消，限制长行摘要大小，同步使用说明\n\n验证：\n- npm run typecheck\n- npm run build\n- 73 项日志相关测试\n- 查找栏与原有日志滚动离屏夹具通过\n- npm run check:knowledge\n- git diff --check\n\n实际操作台视觉与交互保留人工验收。\n","AuthorEmail":"228834386@qq.com","AuthorName":"starry","CommitterEmail":"228834386@qq.com","CommitterName":"starry","Timestamp":"2026-09-18T13:27:49+08:00"},{"Sha1":"d94c0aa3b7d46e66054a2a7da708b46e7f69e597","Message":"perf(logs): 增加双向预读与视口缓存\n\n减少定位日志末尾后反向滚动时的短暂加载占位：\n- 围绕可见原行号提前读取上下缓冲，优先滚动方向和可见缺块\n- 按原行号合并重叠正文，按距离淘汰并限制缓存行数及正文大小\n- 后台预读独立于前台读取，不触发全局忙碌状态或修改滚动位置\n- 切换文件和前台跳转取消旧预读，忽略迟到响应\n- 补充长行小块、反向滚动和迟到响应隔离的回归测试与验收说明\n\n验证：\n- 20 项相关单元测试通过\n- 7 组 Electron 离屏合成场景通过，120 毫秒延迟下逐帧检查反向滚动无加载闪烁和位置跳动\n- npm run typecheck、npm run build 通过\n- 未启动正式操作台或连接设备，实际日志体验仍需人工复测\n","AuthorEmail":"228834386@qq.com","AuthorName":"starry","CommitterEmail":"228834386@qq.com","CommitterName":"starry","Timestamp":"2026-09-18T12:22:20+08:00"},{"Sha1":"dfa031600cf28cd8993766c88159a013c5bec41a","Message":"fix(logs): 修复正文布局并恢复连续滚动\n\n修复新增导航条抢占正文高度，以及后台读取块变成界面行数限制的问题：\n- 日志正文使用纵向弹性布局，警告和导航按内容占高，小文件贴顶显示\n- 普通查看按文件总行数连续虚拟滚动，缺失正文按需读取并缓存最近四块\n- 保留过滤结果分页和阅读位置，防止未加载范围被静默复制为残缺内容\n- 增加 24 MiB 样本、缓存边界及独立 Electron 离屏组件回归测试\n\n验证：\n- 14 项相关单元测试通过\n- 离屏测试覆盖三行文件、窄窗口、跨 2000 行、末尾、功能及文件切换、过滤切换\n- npm run typecheck、npm run build、npm run check:knowledge 通过\n- 使用合成数据验证，未连接设备或启动正式操作台\n","AuthorEmail":"228834386@qq.com","AuthorName":"starry","CommitterEmail":"228834386@qq.com","CommitterName":"starry","Timestamp":"2026-09-18T12:00:12+08:00"}],"HeadCommit":{"Sha1":"4bb59f1faa6737e1d679f5715a0c213b46e020a8","Message":"fix(logs): 优化双击选中并稳定查找框布局\n\n- 参考 VS Code 的文本边界规则，支持连续中文和中英数字整段双击选中\n- 跨查找高亮节点建立原生选区，保留复制、选区查找和横向滚动定位\n- 按查找框宽度预留计数区域，避免加载提示及匹配数量切换挤动按钮\n- 补充选词对照测试、离屏交互与逐帧布局回归，并更新日志帮助文档\n\n验证：\n- npm run typecheck\n- npx vitest run src/features/logs/logWordSelection.test.ts（5 项通过）\n- npm run check:knowledge\n- node scripts/test-log-viewer-browser.mjs --selection\n- node scripts/test-log-viewer-browser.mjs --find\n","AuthorEmail":"228834386@qq.com","AuthorName":"starry","CommitterEmail":"228834386@qq.com","CommitterName":"starry","Timestamp":"2026-09-18T14:59:03+08:00"},"CompareURL":"pengzhiyu/JuhaiOpsDesk/compare/c6fbf67a98ba850b052b6d6585e7354718024ebc...4bb59f1faa6737e1d679f5715a0c213b46e020a8","Len":8}...
|
1789716533
|
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
|
|
30905
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ea965ed90 {"Commits":[{"Sha1":"ea965ed902a9807d07d7d89fc173668804c6294c","Message":"chore(reports): 内核准入门禁首轮 8 处诚实红 回绑 @ ee6d5a9\n\nclean 绑定（worktreeDirty:false）——工作区里三份 reports/ui-*.latest.json 的改动\n早于本批次，且 report-provenance 按设计忽略 latest 报告，不影响本次绑定。\n\nK4 七处（声明为 true，evidenceSources 无机器回执）：\n- kernel.digital-employee-core.industryIndependent ← 只有 scripts/check-kernel-boundaries.mjs\n- kernel.digital-employee-core.crossProductRequired ← 只有下游夹具 .ts\n- kernel.digital-employee-core.dualBackendGoverned ← 一份 ADR + 两个脚本\n- pack.generative-ai 的 industryIndependent / dualBackendGoverned ← 源码文件与目录\n- pack.enterprise-fact-consumer 的两项同上\n\nK3 一处：tests/kernel-downstream-fixture/src/index.ts 只有命名空间导入。\n\n未一并修 evidenceSources。改指某份已存在的报告能立刻转绿，但只有当那份报告确实判过\n该条时才是真修：dual-backend-parity 是全仓级判定、不按组件出结论，改指它等于把自证\n换个地方做。哪份报告承接哪一条属 Owner 裁定，不随本次实现一并决定。\n\nK5 观测（不计红）：跨产品具名消费面 5 个符号——ProductManifestInput、\nProductManifestComposition、ProductRuntimeContractCatalog、\nProductDataContractImplementation、ProductEventContractImplementation，\n全部来自 product-manifest.ts；33/38 个模块零跨产品消费，含 tenant.ts 的 65 个导出与\ntool.ts 的 99 个。该数字只作边界收缩决策的输入，不构成「应移出 CORE」的判定。\n\nCo-Authored-By: Claude Opus 5 \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:52:16-07:00"},{"Sha1":"ee6d5a98aa6d372d2fc2ea81f328d55cc15511f9","Message":"feat(governance): 内核准入证据门禁 K1—K5，判据从声明下沉到导出清单与证据形态\n\nkernel.boundaries.json 的 admissionEvidence 是四个手写 true，evidenceSources\n只列了路径，没有「该判据确实被机器判过」的回执。实测两处后果：\n\n- CORE 声明 crossProductRequired: true，其证据源 tests/kernel-downstream-fixture/\n src/index.ts 是 10 个 import * as + 判非空 + 一个 typeof === \"function\" 的\n 命名空间冒烟测试——28 个契约模块全空它也照样通过。它能证明包可安装可加载，\n 不能证明任何一个模块跨产品必需\n- 归属粒度是文件：owns.contractModules 是文件名清单，于是\n packages/contracts/src/tenant.ts 一个 1075 行 / 65 导出的文件，把租户策略、\n JWT 验签、自建权限、work 域业务判定四类一起带进了 CORE\n\n手法同 check:platform-provenance（那一条把判据从 package.json 的声明下沉到\npnpm-lock.yaml 的解析结果）。五条判据：\n\n K1 EXPORT_LOCK_DRIFT 组件所辖契约模块的直接导出集合须与\n kernel.exports.lock.json 一致。只认直接声明，\n barrel 的再导出不算拥有——否则 index.ts 会「拥有」全仓\n K2 EXPORT_OWNERSHIP_AMBIGUOUS 同一导出名不得被两个组件同时拥有。拆分契约模块时\n 最容易「复制一份留在原处」，这条守住它\n K3 EVIDENCE_NAMESPACE_ONLY crossProductRequired 的证据源若只有命名空间导入、\n 无任何具名导入，按构造无法证明符号级必需性\n K4 EVIDENCE_NOT_BACKED 声明为 true 的每项须至少有一份机器回执\n （reports/*.json 或 *.lock.json）。脚本路径与文档路径\n 不是回执：只证明文件存在，不证明该判据被判过。\n 声明为 false 的项不要求回执\n K5 CROSS_PRODUCT_UNCONSUMED observed，不计红。CORE 模块未被产品消费不等于不该在\n CORE（OS 自己的两个后端在用）；把观测项当红盘会逼出\n 「为了绿而乱改归属」的反向激励\n\n自检 pnpm check:kernel-admission:self-test 共 10 条，含 1 条基线正例与 2 条防过度\n判红（声明 false 不因无回执计红、零跨产品消费只出 observed）——对照组是为了防\n「只会红的假门禁」。\n\n锁基线 38 个模块 / 779 个导出（CORE 30 + generative-ai 7 + fact-consumer 1）。\n首次签发只固化「现在是什么」，不代表归属正确。\n\ncheck-all 末位注册，理由同 check:platform-provenance：本门禁自引入起即为已知诚实红，\nfail-fast 语义下排前面会让其余门禁全部不执行。pnpm check 因此从 27 步变 28 步且末步红，\n前 27 步照常产出证据。\n\nCo-Authored-By: Claude Opus 5 \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:52:01-07:00"}],"HeadCommit":{"Sha1":"ea965ed902a9807d07d7d89fc173668804c6294c","Message":"chore(reports): 内核准入门禁首轮 8 处诚实红 回绑 @ ee6d5a9\n\nclean 绑定（worktreeDirty:false）——工作区里三份 reports/ui-*.latest.json 的改动\n早于本批次，且 report-provenance 按设计忽略 latest 报告，不影响本次绑定。\n\nK4 七处（声明为 true，evidenceSources 无机器回执）：\n- kernel.digital-employee-core.industryIndependent ← 只有 scripts/check-kernel-boundaries.mjs\n- kernel.digital-employee-core.crossProductRequired ← 只有下游夹具 .ts\n- kernel.digital-employee-core.dualBackendGoverned ← 一份 ADR + 两个脚本\n- pack.generative-ai 的 industryIndependent / dualBackendGoverned ← 源码文件与目录\n- pack.enterprise-fact-consumer 的两项同上\n\nK3 一处：tests/kernel-downstream-fixture/src/index.ts 只有命名空间导入。\n\n未一并修 evidenceSources。改指某份已存在的报告能立刻转绿，但只有当那份报告确实判过\n该条时才是真修：dual-backend-parity 是全仓级判定、不按组件出结论，改指它等于把自证\n换个地方做。哪份报告承接哪一条属 Owner 裁定，不随本次实现一并决定。\n\nK5 观测（不计红）：跨产品具名消费面 5 个符号——ProductManifestInput、\nProductManifestComposition、ProductRuntimeContractCatalog、\nProductDataContractImplementation、ProductEventContractImplementation，\n全部来自 product-manifest.ts；33/38 个模块零跨产品消费，含 tenant.ts 的 65 个导出与\ntool.ts 的 99 个。该数字只作边界收缩决策的输入，不构成「应移出 CORE」的判定。\n\nCo-Authored-By: Claude Opus 5 \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:52:16-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/c433d57b4aae2249bd19a085d1c520bf6baedf55...ea965ed902a9807d07d7d89fc173668804c6294c","Len":2}...
|
1789718112
|
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
|
|
31029
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"614681e6e {"Commits":[{"Sha1":"614681e6e78d0385bbf043ef964bd444d8e5958b","Message":"chore(reports): tenant.ts 拆分第一步的八份静态门禁证据 回绑 @ 53be2c3\n\n八份全部 clean 绑定（worktreeDirty:false）：naming / schema-sync / validation-source /\ncontract-consumers / dual-backend-parity / kernel-boundaries / kernel-packages 七绿，\nkernel-admission 仍是引入时那 8 处（K3 一处 + K4 七处），与拆分前逐条一致——\n本次未引入新红，也未消除旧红。\n\nkernel-admission 的 K1 在重签前如实报出本次变更：task.ts / outcome.ts 各新增、\ntenant.ts 消失 21 个（17 个降私有 + 4 个迁出）。kernel.exports.lock.json 已随实现提交\n重签为 762 个导出。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:00:33-07:00"},{"Sha1":"53be2c3dd5e52e0392225f359296ef250447bc56","Message":"refactor(contracts): tenant.ts 拆分第一步——work 域判定迁出、17 个零引用导出降私有\n\ntenant.ts 与框架 @juhai/kernel 的同名文件共有导出 0 个：它不是「改过的内核」，是绕过\n内核另写的一份，1075 行 / 65 导出里混着四类东西（租户策略、JWT 验签、自建权限、\nwork 域业务判定）。本次只做两件行为中性的事，不改任何实现。\n\n一、work 域判定迁出（不满足 kernel.boundaries.json 的 CORE 准入证据 crossProductRequired）\n\n requiredPermissionForTaskEvent / canApproveTask / canTransitionTask → task.ts\n canResolveOutcome → outcome.ts\n\n「哪些任务事件是特权事件」只对本 OS 的 work 域成立，不是跨产品必需的内核契约。\n角色与权限的定义仍留在 tenant.ts，后续随自建权限一并迁往 authorization.ts。\n\n二、17 个全仓零引用的导出降为模块内私有\n\n RsaSha256Verify verifyJwtRs256 JwksKeyStoreDeps browserJwtIdentitySchema\n BrowserJwtIdentity PermissionOverrideLike PermissionAuditEventData RoleAuditEventData\n TENANT_AUTH_STARTUP_MODES TenantAuthStartupMode TenantAuthStartupDecision\n TenantAuthEnvironment TenantAuthInput TenantAuthPosture RealtimeAuthExpiryDecision\n TenantAuthOptions AuditActorBinding\n\n前五个与 RsaSha256Verify / verifyJwtRs256 是 resolveTenantAuth 的内部实现，后端注入的是\nnode:crypto 的 createHmac / createVerify，从不按名字引用这些类型。\nPermissionAuditEventData / RoleAuditEventData 模块内也不使用，是纯死代码；本次只降可见性，\n删除留给后续。\n\ntenant.ts 65 → 44 导出。应用侧零改动——都经 @repo/contracts 根 barrel 导入，模块间搬移\n不可见；只有 contracts.test.ts 的直接 ./tenant 导入需要切分（保留 21、迁出 4）。\n\n验证：@repo/contracts 24 文件 312/312（与变更前基线逐个一致，行为中性）；typecheck 13/13；\ncheck:dual-backend / naming / schema / validation / contract-consumers / kernel-boundaries 全绿。\ncheck-dual-backend-parity.mjs 对 tenant.ts 有 5 处内容位置断言（C51/C52/C73/C181），本次\n涉及的标识符全部仍在该文件内，故未触发；C 组迁往 authorization.ts 时这 5 处必须同步改路径。\n\n顺带一处发现：check:kernel-packages 对本次 21 个符号的公开面收缩完全无感——它的 apiDigest\n只覆盖导出子路径，不覆盖符号集合。真正抓到本次变更的是 check:kernel-admission 的 K1\n（task.ts/outcome.ts 3 处新增、tenant.ts 21 处消失）。kernel.exports.lock.json 随本提交重签\n779 → 762 个导出；重签是 K1「变更即复核」的设计意图，不是绕过。\n\nCo-Authored-By: Claude Opus 5 \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:59:59-07:00"}],"HeadCommit":{"Sha1":"614681e6e78d0385bbf043ef964bd444d8e5958b","Message":"chore(reports): tenant.ts 拆分第一步的八份静态门禁证据 回绑 @ 53be2c3\n\n八份全部 clean 绑定（worktreeDirty:false）：naming / schema-sync / validation-source /\ncontract-consumers / dual-backend-parity / kernel-boundaries / kernel-packages 七绿，\nkernel-admission 仍是引入时那 8 处（K3 一处 + K4 七处），与拆分前逐条一致——\n本次未引入新红，也未消除旧红。\n\nkernel-admission 的 K1 在重签前如实报出本次变更：task.ts / outcome.ts 各新增、\ntenant.ts 消失 21 个（17 个降私有 + 4 个迁出）。kernel.exports.lock.json 已随实现提交\n重签为 762 个导出。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:00:33-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/ea965ed902a9807d07d7d89fc173668804c6294c...614681e6e78d0385bbf043ef964bd444d8e5958b","Len":2}...
|
1789718531
|
Edit
Delete
|
|
31055
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"2d4b55254 {"Commits":[{"Sha1":"2d4b55254cd0b38f4ae1750038d4a6d9e2ebb30a","Message":"chore(reports): check:gate-flow 回绑 @ 574cfb7\n\n45 个脚本、33 个有消费入口、12 个流外且全部具名（门禁 4 / 工具 8）、0 违规。\n并行会话正在本仓改 Dockerfile 与底座，主工作区非干净树——经 reports:rebind 在\nHEAD 的干净检出里生成，未触及对方在途文件。\n\nCo-Authored-By: Claude Opus 5 \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:09:55-07:00"},{"Sha1":"f3ae97f3460699338d08efe3dd60ea69a3d49fa4","Message":"feat(stack,runtime): dev 常驻运行时接上受控执行面与统一服务目录快照（CHG-018 条件 A 的目标环境半边）\n\ncompose 的 runtime 服务此前没有 PLATFORM_OPS_ENABLED / _CLIENT_IDS / _ADMIN_SUBJECTS，也没有\nPLATFORM_CATALOG_SNAPSHOT_PATH：OPS-1 的命令面在 dev 容器里根本不存在（定义 executable=false），\n/api/platform/catalog 的 snapshot 恒为 unavailable。仓内验收过的两个面没有任何一条路径到达运行环境，\nOPS-1 记录里「目标环境验收留阶段 ②」说的就是这一段。\n\n- stack/compose.yaml：四个键全部空默认值——不配置 = 不开命令面，而不是开着没人管\n- stack/overlays/dev.yaml：reports/workbench-catalog-snapshot.latest.json 只读挂到\n /srv/runtime/catalog-snapshot.json，快照绑的是它自己的 gitSha，不是本进程\n- runtime/Dockerfile：ENV PLATFORM_SOURCE_SHA=${SOURCE_SHA}，与 OCI revision 标签同源；\n 缺它时目录读面只能报 source_sha_status=unknown，不从文件系统猜\n- docs/runbook.md：§2 环境表补两行，并写明改这四个键必须重建容器（restart 带不上新环境）\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:09:52-07:00"},{"Sha1":"574cfb754278102c1588009c4af3a66dc2201777","Message":"feat(governance): 补 check:gate-flow——每个门禁的失败信号有谁在看？\n\n治理层 2026-09-14 就为自己建了 `门禁消费登记.json` 逐条回答这个问题，并写明了病因：\n一个门禁若既不在统一流内、也不在任何 CI 链里，它就停在「永远红」或「永远绿」，\n两种都不再携带信息。本仓一直没问过这个问题。\n\n实测：根 package.json 44 个脚本里 12 个既不在 `pnpm check` 链、CI 也不调用。\n多数是工具与开发者聚合入口（已逐条核实其组成部分确被消费），但其中三个是真门禁：\n\n image:smoke CI 的 image job 构建镜像、生成 SBOM、签名，**却从不启动它一次**。\n 而开发计划把这六项冒烟写成 D-1 的退出条件。更要紧的是\n `image-smoke.latest.json` 在 evidence-scopes 的未登记账里写着\n 「待其下一次真实运行后登记」——而没有任何东西会触发那次运行，\n 于是那条搁置根本没有出口。本轮把它写成带复核期的具名条件。\n promotion:check DEC-024 / DEC-026 的晋级判据，事件驱动，硬接进 check 链只会恒绿\n check:deployed 活体核验，CI runner 上没有长驻底座，接进去等于加一个恒定跳过\n\n三个各有理由，但理由此前只散在 CLAUDE.md / README 的散文里，没有一条有复核期。\n\n**消费关系一律自动推导，不接受声明。** 治理层那套让登记表自报 consumption 再用 G3\n去源码里证伪；本仓直接从 check 链的递归展开与两份 CI 工作流现取——声明会撒谎，\n推导不会。CI 有几处绕开 pnpm 直接 `node governance/build-image.mjs`，因此除按名匹配\n外还按脚本里出现的 .mjs 路径匹配（用例钉住这两条与正则转义）。\n`governance/gate-flow.json` 因此只装推不出来的那些：随接线逐条变少（F2 会拦下\n已被消费却还留着的腐烂登记），也不能无声变多（F1 拦下任何新出现的未说明脚本）。\n\nF4 守的是日期不是条件：接入条件多半含人的判断（「Secret 到位后」「首次晋级时」），\n不可能机器化；能机器化的是必须有人按期回来看一眼。同形判据已在治理层\ngate-registry-core 的 G6 与 domain-layer-baseline 的 B4 上验证过：缓期不是豁免。\n\n已串进 `pnpm check`（放 check:evidence 之前，纯静态先跑先报），报告登记进\nevidence-scopes（severity=error，作用域逐条对应它实际读的文件），并加入\nreports:rebind 的零依赖清单——本仓常有并行会话，脏树上拿不到干净绑定。\n\n治理测试 283 → 298。当前：45 个脚本，33 个有消费入口，12 个流外且全部具名\n（门禁 4 / 工具 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-18T01:09:11-07:00"}],"HeadCommit":{"Sha1":"2d4b55254cd0b38f4ae1750038d4a6d9e2ebb30a","Message":"chore(reports): check:gate-flow 回绑 @ 574cfb7\n\n45 个脚本、33 个有消费入口、12 个流外且全部具名（门禁 4 / 工具 8）、0 违规。\n并行会话正在本仓改 Dockerfile 与底座，主工作区非干净树——经 reports:rebind 在\nHEAD 的干净检出里生成，未触及对方在途文件。\n\nCo-Authored-By: Claude Opus 5 \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:09:55-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/0abd15c28dd2b92c583289934db660363b202fd4...2d4b55254cd0b38f4ae1750038d4a6d9e2ebb30a","Len":3}...
|
1789719017
|
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
|
|
31065
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"832f9b2e5 {"Commits":[{"Sha1":"832f9b2e5ab646a48adbf37b80db1d41092f2f7e","Message":"chore(reports): tenant.ts 拆分第三步的十三份静态门禁证据 回绑 @ a0a9f1a\n\n十三份全部 clean 绑定（worktreeDirty:false）：naming / schema-sync / validation-source /\ncontract-consumers / dual-backend-parity / kernel-boundaries / kernel-packages /\nkernel-downstream / kernel-extensions / statemachine-write-guard / list-bounds /\nfork-readiness 十二绿；kernel-admission 仍是引入时那 8 处（K3 一处 + K4 七处），\n与三步拆分前逐条一致——全程未引入新红，也未消除旧红。\n\n三步各自撞到的门禁都如实红过再修，没有一处是先改门禁再做变更：\n第一步 K1（导出归属漂移）；第二步 K1 + kernel-packages P7（公开面变更须伴随版本上调）\n+ kernel-downstream D1（下游安装版本随之重签）；第三步同上两处 P7 / D1。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:12:22-07:00"},{"Sha1":"a0a9f1aa5d77ac7d1c9b74a3e445a323a205f5b6","Message":"refactor(contracts): tenant.ts 拆分第三步——自建权限改名 authorization.ts，tenant 之名腾空\n\n第一步迁出 work 域判定、第二步迁出自建身份之后，tenant.ts 剩下的 22 个导出整体就是\n「自建权限」一类。因此第三步不是搬符号，是给文件正名。\n\n packages/contracts/src/tenant.ts → packages/contracts/src/authorization.ts\n\n改名本身的价值不只是可读性：OS 的 tenant.ts 与框架 @juhai/kernel 的同名文件**共有导出 0 个**，\n框架那份是租户解析策略（normalizeTenantId / tenantIdFromClaims / decideTenantResolution /\nresolveAuthMode / AUTH_MODES），OS 一个都没有。两个同名不同义的文件是「形似而神不同」漂移\n最典型的载体。改名之后 tenant.ts 这个名字腾空，留给内核退回 pin 时由 @juhai/kernel 提供的\n真正租户原语——顺带补上 OS 现在缺的 tenantId 形状与长度校验（当前主口径是无上限的\nz.string().min(1)，另有两处 .max(128) 与 employment-projection.ts 的 ^ten_.+$，三套并存）。\n\n同步改动：\n\n- 六处 import 改指：identity.ts / outcome.ts / task.ts / index.ts / kernel.ts / contracts.test.ts。\n- check-dual-backend-parity.mjs 的 C52 两条断言（权限目录与角色默认值、ALLOW/DENY 优先级）\n 改指 authorization.ts。C52 没有专用负向探针，但 expectSource 对缺失文件计 missing file\n 违规（fail-closed），门禁绿即证明两条断言在新路径上真实命中，不是指向不存在文件的假绿。\n- kernel.boundaries.json：CORE 的 contractModules 由 tenant.ts 改为 authorization.ts。\n- check-kernel-admission.mjs 头部叙述里的 tenant.ts 改为历史表述，不再指向已不存在的路径。\n- @repo/contracts 1.17.0 → 1.18.0（根与 kernel 两个 barrel 的 export 行都变了，P7 要求公开面\n 变更伴随版本上调）；kernel.packages.lock.json / kernel.downstream.lock.json /\n kernel.exports.lock.json 三把锁随之重签。\n\n本步**未**把自建权限移出 @repo/contracts/kernel 子路径。按同一套理由（铁律三：平台拥有规则）\n它和自建身份一样不属于跨产品必需的内核契约，但从已声明的稳定子路径上摘除符号是**破坏性\n收窄**，应单独裁定并走主版本号，不随改名夹带。实测当前 kernel 子路径的唯一消费者是下游夹具\n的命名空间导入，产品侧零具名消费——真要摘，成本主要在版本语义而非调用方。\n\n三步累计：tenant.ts 1075 行 / 65 导出 → authorization.ts 273 行 / 22 导出\n+ identity.ts 818 行 / 23 导出 + task.ts / outcome.ts 各收 3 / 1 个 + 17 个降私有。\n\n验证：@repo/contracts 24 文件 312/312（三步前后四次逐次一致，行为中性）；typecheck 13/13；\nnaming / schema / validation / contract-consumers / dual-backend / kernel-boundaries /\nkernel-packages / kernel-downstream / kernel-extensions / write-guard / list-bounds /\nfork-readiness 十二门全绿；kernel-admission 仍是引入时那 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-18T01:11:37-07:00"},{"Sha1":"d7c932b537561ae02bcc860d506fea7c1d878b30","Message":"chore(reports): tenant.ts 拆分第二步的十份静态门禁证据 回绑 @ 439c6f7\n\n十份全部 clean 绑定（worktreeDirty:false）：naming / schema-sync / validation-source /\ncontract-consumers / dual-backend-parity / kernel-boundaries / kernel-packages /\nkernel-downstream / kernel-extensions 九绿；kernel-admission 仍是引入时那 8 处\n（K3 一处 + K4 七处），与两步拆分前逐条一致——未引入新红，也未消除旧红。\n\n本步中 kernel-packages 的 P7 与 kernel-downstream 的 D1 都如实报过红：前者要求根 barrel\n新增导出必须伴随版本上调（@repo/contracts 1.16.0 → 1.17.0），后者要求下游夹具的安装版本\n随之重签。两处都是设计内的「变更即复核」，不是绕过。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:08:09-07:00"},{"Sha1":"439c6f7e34f48f718f18479aa1dd2e9a9e3fcfe1","Message":"refactor(contracts): tenant.ts 拆分第二步——自建身份迁出 identity.ts\n\n框架 @juhai/kernel 的 tenant.ts 在 0.4.0—0.7.0 之间把边界写死为「本文件只做策略，\n不做验签」：验签需要密钥/JWKS，而契约包被 web 直接 import，密钥语义不能泄漏进浏览器包。\nOS 分叉于框架 0.1.0，没见过这条边界，于是策略、验签、自建权限、work 域判定四类长进了\n同一个文件。第一步已迁出 work 域判定，本步迁出身份一类。\n\n packages/contracts/src/identity.ts（新增，818 行 / 23 导出）\n 验签原语（注入式，契约包自身不 import node:crypto）、JWKS 密钥库、\n 浏览器身份与会话、OIDC PKCE 三组 schema、启动姿态门、实时连接过期、\n 鉴权入口 resolveTenantAuth，以及 token 解码/比对等私有管道\n\n packages/contracts/src/tenant.ts（273 行 / 22 导出，原 1042 行 / 44 导出）\n 只剩自建权限一类：角色与权限词汇表、ALLOW/DENY 判定、授权 DTO、审计载荷\n\n两处归属判断值得记下：\n\n- bindAuditActorSubject / AuditActorBinding 一并迁入 identity.ts。它绑定的是**已验签的\n sub**，属身份来源而非授权判定；留在 tenant.ts 会让授权侧反向依赖 TenantAuthPosture，\n identity ↔ tenant 成环。\n- roleFromClaim 留在 tenant.ts 并升为导出。它是角色词汇表的一部分（claim → 合法角色），\n 两侧都要用；反过来把它搬进 identity 会让 resolveEffectiveRole 反向依赖，同样成环。\n\n依赖方向单向：identity → tenant（借 TENANT_ROLES / TenantRole / roleFromClaim），\ntenant 不反向依赖 identity。切分前已用脚本枚举 75 个顶层声明的引用图逐条验证无反向边。\n\nidentity.ts **不进 @repo/contracts/kernel 子路径**，只经根 barrel 导出：自建身份不是跨产品\n必需的内核契约，后续应换成企业 IdP 的 client-identity。\n\n同步改动：\n\n- check-dual-backend-parity.mjs 三处按路径钉在 tenant.ts 的断言改指 identity.ts——\n C51（启动姿态判定与断言）、C181（实时过期策略）、C73（已验签 sub 的审计主体绑定）。\n 改完用门禁自带负向探针验活：DUAL_BACKEND_NEGATIVE_PROBE=missing-realtime-auth-expiry\n 与 =missing-audit-actor-binding 均如期转红，断言不是改成了指向不存在文件的假绿。\n C52 两条仍在 tenant.ts（权限目录与 ALLOW/DENY 优先级未动）。\n- kernel.boundaries.json：identity.ts 登记进 CORE 的 contractModules（30 → 31）。\n- @repo/contracts 1.16.0 → 1.17.0。check:kernel-packages 的 P7 要求公开面变更必须伴随\n 版本上调；根 barrel 新增一行 export * 是加法变更，取次版本。kernel.packages.json 与\n kernel.packages.lock.json / kernel.downstream.lock.json 随之重签（后者只改版本号一行）。\n\n顺带修正上一笔提交里的说法，方向不变但更准确：check:kernel-packages 的 apiDigest 只哈希\nrequiredExports 入口的 .d.ts，而入口就是 barrel——它看得见「根 barrel 多了一行 export *」，\n看不见任何具体符号的增删。上一步降私有 17 个符号它全绿，正是这个原因。\n\n验证：@repo/contracts 24 文件 312/312（三次拆分前后逐次一致，行为中性）；typecheck 13/13；\nnaming / schema / validation / contract-consumers / dual-backend / kernel-boundaries /\nkernel-packages / kernel-downstream / kernel-extensions 九门全绿；kernel-admission 仍是\n引入时那 8 处（K3 一处 + K4 七处），未引入新红。kernel.exports.lock.json 重签为\n39 个模块 / 763 个导出。\n\nCo-Authored-By: Claude Opus 5 \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:07:27-07:00"}],"HeadCommit":{"Sha1":"832f9b2e5ab646a48adbf37b80db1d41092f2f7e","Message":"chore(reports): tenant.ts 拆分第三步的十三份静态门禁证据 回绑 @ a0a9f1a\n\n十三份全部 clean 绑定（worktreeDirty:false）：naming / schema-sync / validation-source /\ncontract-consumers / dual-backend-parity / kernel-boundaries / kernel-packages /\nkernel-downstream / kernel-extensions / statemachine-write-guard / list-bounds /\nfork-readiness 十二绿；kernel-admission 仍是引入时那 8 处（K3 一处 + K4 七处），\n与三步拆分前逐条一致——全程未引入新红，也未消除旧红。\n\n三步各自撞到的门禁都如实红过再修，没有一处是先改门禁再做变更：\n第一步 K1（导出归属漂移）；第二步 K1 + kernel-packages P7（公开面变更须伴随版本上调）\n+ kernel-downstream D1（下游安装版本随之重签）；第三步同上两处 P7 / D1。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:12:22-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/614681e6e78d0385bbf043ef964bd444d8e5958b...832f9b2e5ab646a48adbf37b80db1d41092f2f7e","Len":4}...
|
1789719150
|
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
|
|
31067
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1e6f71d84 {"Commits":[{"Sha1":"1e6f71d846a9ad3bcbd04a3f2b5fdb3f69ca1884","Message":"chore(reports): check:gate-flow 回绑 @ 5003319\n\n剥注释后判定结果不变：45 个脚本、33 个有消费入口、12 个流外且全部具名、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:20:03-07:00"},{"Sha1":"5003319dcea673584371b081f59f4e347a33c4ae","Message":"fix(governance): check:gate-flow 先剥 CI 注释再匹配——否则它会亲手把自己的发现消音\n\n推导层原本直接在 CI 原文上按名匹配。工作流里本来就有\n`# static → 私有包认证 … + 根 pnpm check（含 runtime 静态门禁）` 这样的说明行，\n它没被误判纯属侥幸：`check` 后面跟的是中文括号，不是空白。只要有人写下\n「待 Secret 后加 pnpm image:smoke 这一步」，不剥注释就会把这个门禁**最实的那条发现**\n判成已被消费，随后 F2 还会反过来要求删掉那条登记。\n\n剥注释的代价是可能漏判（shell 里 `#` 之后的真命令被切掉），而漏判只会多要一条登记、\n逼人看一眼，是安全的那一侧。\n\n同时把两条刻意的保守取舍写进文件头，并在登记表 note 里记下测量结论，免得被\"优化\"掉：\n\n一、**不扫脚本正文**。消费确实可能发生在脚本内部，但天真地按名扫正文更糟——实测\n本仓 `lib/gate-flow-core.mjs` 自己的注释里就写着 image:smoke / promotion:check /\ncheck:deployed 三个名字，扫正文会把这个门禁要报的三条发现全部判成已消费。\n\n二、**扫描面只有根 package.json，这是量过之后的决定**。另外三个 pnpm 根逐个测过，\n没有真空缺：runtime 的 check:conformance:differential 被 check-runtime-acceptance\n的 plan 数组 spawn；check-runtime-governance 与 generate-governance-status 被 profile\n运行器与 governance-report 调用；check:kernel / :production / :conformance 是框架给的\nprofile 分组、其成分检查已逐条在 runtime 的 check 链里；identity 的\ncheck:dual-backend-behavior 被该仓 check-runtime-acceptance 调用。这些消费全在脚本\n正文内部，要判它们就得解析 spawn 的实参数组，而那正是第一条否掉的方向。\n\ngate-flow 测试 15 → 18，治理测试 298 → 301。判定结果不变：45 个脚本 / 33 有消费入口 /\n12 流外且全部具名。\n\nCo-Authored-By: Claude Opus 5 \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:19:48-07:00"},{"Sha1":"dbc608b892652e920970ea5368a57a02263d9915","Message":"chore(reports): 工作台两份快照回绑 @ b1c2c0d\n\n本轮部署证据落进运维快照作用域（image-digest / image-smoke / deployed-runtime / runtime-up），\n经 reports:rebind 在 HEAD 的干净检出里重跑，两份同源快照一并带回。\n\n顺带实测：dev overlay 把目录快照按路径只读挂进容器，rebind 带回新文件后\nGET /api/platform/catalog 立刻报出新的 snapshot.provenance.gitSha=b1c2c0d，无需重建容器。\n\nCo-Authored-By: Claude Opus 5 \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:19:18-07:00"},{"Sha1":"b1c2c0dc197166f41437f03707ad0a1bd11448c1","Message":"chore(reports): dev 重新部署证据回绑 @ d8f0920 / 759e559\n\n- image-digest：干净检出构建的 d8f09205c8a5（worktreeDirty=false，contextMode=head）\n- image-smoke：6/6（scope 单 profile、Redis 逻辑库 15、:53009）\n- pg-dump.2026-09-18：切换前七个模块库快照上传 MinIO\n- runtime-up.2026-09-18：22 条读面探针 + 4 条受控执行探针 + 3 条非 canonical 对照，\n 8 条 findings（4 修 4 留裁决），可观测三后端切换后仍有信号\n- deployed-runtime：passed / IMAGE_SOURCE_EQUIVALENT\n\nprovenance.worktreeDirty=true：本工作区有并行会话 WIP，运行面记录只绑定本地；\n镜像证据独立绑定干净检出（image.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-18T01:18:59-07:00"},{"Sha1":"709cd94cfc5cd138b5539053554ef1b4d4dcd4ff","Message":"docs(部署): dev 常驻运行时重新部署与三个运行面取证记录（2026-09-18）\n\ncheck:deployed 从 BUILT_IMAGE_SOURCE_BEHIND 转 passed 的完整过程：四个部署缺口、\n一个被吞掉的真实缺陷、受控执行面的 dev 验收，以及六条仍未闭环的事实。\n作用域只到本机 dev，不外推目标环境签收。\n\nCo-Authored-By: Claude Opus 5 \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:52-07:00"}],"HeadCommit":{"Sha1":"1e6f71d846a9ad3bcbd04a3f2b5fdb3f69ca1884","Message":"chore(reports): check:gate-flow 回绑 @ 5003319\n\n剥注释后判定结果不变：45 个脚本、33 个有消费入口、12 个流外且全部具名、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:20:03-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/2d4b55254cd0b38f4ae1750038d4a6d9e2ebb30a...1e6f71d846a9ad3bcbd04a3f2b5fdb3f69ca1884","Len":7}...
|
1789719607
|
Edit
Delete
|
|
31068
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"dcd1c1486 {"Commits":[{"Sha1":"dcd1c1486e63a7f67a0c548158823764a0b58b21","Message":"chore(reports): 整轮 pnpm check 二十八份证据 回绑 @ 1994f3c，刷新快照锚点\n\n本批次最后一个提交，按 C241 纪律同时刷新 CLAUDE.md 的快照基准提交锚点到 1994f3c\n（声明落后 0，本提交自身使实测落后 1，落在 C19 式 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=1994f3c、worktreeDirty:false）。\n整轮 28 步全部执行，前 27 步全绿，末步 check:kernel-admission 红 8 处——该门禁引入时即\n登记的已知诚实红（K3 一处：crossProductRequired 的证据源是命名空间冒烟测试；\nK4 七处：三个组件的 admissionEvidence 声明为 true 却无机器回执），链尾位置正是为了不连带\n抹掉前 27 步的证据。\n\n与上一次整轮绿盘（23d1b7a @ 6396f7f，27/27）相比，本轮是 28 步：新增的第 28 步\ncheck:kernel-admission 自身就是本批次引入的。因此「27/27 全绿」与「28 步 27 绿」不是退步，\n是多了一条此前不存在的判据，并且它一上来就报出了真实缺口。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次（check:ui 不在静态链内，本轮未跑），\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:21:28-07:00"},{"Sha1":"1994f3c74ee90e08df7f1b03afff9dd570fee87d","Message":"docs(治理): 整轮 pnpm check 暴露的三处文档漂移——下游锁、边界数字、快照锚点\n\n本批次六个提交推送时没有刷新文档真相，整轮 pnpm check 的 check:docs-truth 如实报红 4 条\n（第 2 条是第 1 条的负向探针连带）。逐条修：\n\n- docs/product-extension-guide.md 的「当前下游兼容锁」行仍写 @repo/contracts@1.16.0，\n 实际已随两次公开面变更升到 1.18.0。该行要求与 kernel.downstream.lock.json **逐字**匹配。\n- CLAUDE.md 内核边界数字 142/142 → 143/143 受管面：identity.ts 迁入 CORE 的 contractModules\n 多了一个受管面。242/242 源码文件与 7/7 负向探针未变。\n （C152 那条历史教训行里的 136/136 是当时的实测记录，属历史事实，不改。）\n- 快照基准提交锚点 070b944 落后 HEAD 10 提交——其中 8 个是本批次的，另 2 个\n （23d1b7a / c433d57）在本批次之前就已漏刷。锚点随批次最后一个提交刷新，故不在本提交里改。\n\n整轮实测（28 步全部执行）：前 27 步全绿——check:platform / naming / schema / validation /\ncontract-consumers / dual-backend / write-guard / list-bounds / fork-readiness /\nkernel-boundaries / kernel-packages / kernel-downstream / kernel-extensions /\nproduct-migrations / product-acceptance / agent-adapters / report-lock / operations /\nllm-eval / rls / migrations / governance-docs / docs-truth / governance / lint（5/5）/\ntypecheck（13/13）/ platform-provenance；末步 check:kernel-admission 红 8 处，\n是该门禁引入时即登记的已知诚实红（K3 一处 + K4 七处），位置在链尾正是为了不连带抹掉\n前 27 步的证据。\n\nCo-Authored-By: Claude Opus 5 \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:19:40-07:00"}],"HeadCommit":{"Sha1":"dcd1c1486e63a7f67a0c548158823764a0b58b21","Message":"chore(reports): 整轮 pnpm check 二十八份证据 回绑 @ 1994f3c，刷新快照锚点\n\n本批次最后一个提交，按 C241 纪律同时刷新 CLAUDE.md 的快照基准提交锚点到 1994f3c\n（声明落后 0，本提交自身使实测落后 1，落在 C19 式 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=1994f3c、worktreeDirty:false）。\n整轮 28 步全部执行，前 27 步全绿，末步 check:kernel-admission 红 8 处——该门禁引入时即\n登记的已知诚实红（K3 一处：crossProductRequired 的证据源是命名空间冒烟测试；\nK4 七处：三个组件的 admissionEvidence 声明为 true 却无机器回执），链尾位置正是为了不连带\n抹掉前 27 步的证据。\n\n与上一次整轮绿盘（23d1b7a @ 6396f7f，27/27）相比，本轮是 28 步：新增的第 28 步\ncheck:kernel-admission 自身就是本批次引入的。因此「27/27 全绿」与「28 步 27 绿」不是退步，\n是多了一条此前不存在的判据，并且它一上来就报出了真实缺口。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次（check:ui 不在静态链内，本轮未跑），\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:21:28-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/832f9b2e5ab646a48adbf37b80db1d41092f2f7e...dcd1c1486e63a7f67a0c548158823764a0b58b21","Len":2}...
|
1789719706
|
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
|
|
31070
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1c8523a92 {"Commits":[{"Sha1":"1c8523a92bf32cb7257642251ad57e7a03ebf161","Message":"chore(reports): runtime 验收在 clean HEAD 首次绑定 回绑 @ dcd1c14，刷新证据新鲜度与快照锚点\n\ntenant.ts 三步拆分的运行态复验。结果与拆分前基线**逐项持平**，行为中性在运行态得到证实：\n\n testsPassed 733（基线 733，地板 683）\n behaviorParityCases 204（地板 204，violations 0）\n 87 项指标零违规——迁移 deploy/status、七包串行测试、双管道竞争验收、行为矩阵、\n auth-startup、db-credential-separation（8 负例 + 2 进程隔离）、tracing（4 服务）、\n dependency-resilience（14 故障 + 14 恢复 + 半开 4）、capacity（480 请求 p95 20.0ms）、\n write-capacity（40 链路终态 + 80 派发）、multi-instance（4 进程）、\n 产品扩展 / 迁移 / SQL 运行时与产品验收（258 正 + 124 负）\n\n**首次在 clean HEAD 上绑定**：13 份运行态报告的 provenance 全部 gitSha=dcd1c14、\nworktreeDirty:false。此前那份（2026-09-14）绑的是 6396f7f 且工作区 dirty，按仓规矩只能\n绑定本地、不能作阶段门证据。\n\n基座刻意隔离，不沿用上次配置：\n- 新建独立验收库 digital_employee_os_acceptance_20260918 @127.0.0.1:55470（按 Owner 决定保留，\n 与工作区 enterprise_platform_acceptance_* 的带日期惯例一致，便于回查）\n- 新起专用 Redis 容器（redis://127.0.0.1:6404/3）——上次用的 6404 实例已不存在\n- 不用 digital_employee_os_dev_nestjs：那是 dev 库，跑验收会被测试数据反复清洗\n- 理由是 G15/O1：本机 41 个容器多仓共用端口，且实测另有并行会话正在跑 enterprise-platform\n 的 api-nestjs。上次 runtime 长期假红的根因正是共用逻辑库导致三处订阅端收不到信封\n\nCLAUDE.md 证据新鲜度两行同步刷新（三级分开陈述，不互相冒充）：\n- 真实 DB：2026-09-14 🟡（dirty）→ 2026-09-18 ✅（clean dcd1c14）\n- 静态链：2026-09-14 ✅ 27/27 → 2026-09-18 🟡（clean 1994f3c 上 28 步全执行、前 27 绿，\n 末步 check:kernel-admission 诚实红 8 处）。「27/27」与「28 步 27 绿」不是退步，是多了一条\n 此前不存在的判据，且它一上来就报出真实缺口——该说明已写进文档行内，防止后来者误读为回归。\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 dcd1c14（声明落后 0，本提交自身使实测落后 1，\n落在 +1 自指窗内）。推送前已跑 check:docs-truth:assert 自检通过。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次（check:ui 不在 runtime 链内，未跑），\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:34:51-07:00"}],"HeadCommit":{"Sha1":"1c8523a92bf32cb7257642251ad57e7a03ebf161","Message":"chore(reports): runtime 验收在 clean HEAD 首次绑定 回绑 @ dcd1c14，刷新证据新鲜度与快照锚点\n\ntenant.ts 三步拆分的运行态复验。结果与拆分前基线**逐项持平**，行为中性在运行态得到证实：\n\n testsPassed 733（基线 733，地板 683）\n behaviorParityCases 204（地板 204，violations 0）\n 87 项指标零违规——迁移 deploy/status、七包串行测试、双管道竞争验收、行为矩阵、\n auth-startup、db-credential-separation（8 负例 + 2 进程隔离）、tracing（4 服务）、\n dependency-resilience（14 故障 + 14 恢复 + 半开 4）、capacity（480 请求 p95 20.0ms）、\n write-capacity（40 链路终态 + 80 派发）、multi-instance（4 进程）、\n 产品扩展 / 迁移 / SQL 运行时与产品验收（258 正 + 124 负）\n\n**首次在 clean HEAD 上绑定**：13 份运行态报告的 provenance 全部 gitSha=dcd1c14、\nworktreeDirty:false。此前那份（2026-09-14）绑的是 6396f7f 且工作区 dirty，按仓规矩只能\n绑定本地、不能作阶段门证据。\n\n基座刻意隔离，不沿用上次配置：\n- 新建独立验收库 digital_employee_os_acceptance_20260918 @127.0.0.1:55470（按 Owner 决定保留，\n 与工作区 enterprise_platform_acceptance_* 的带日期惯例一致，便于回查）\n- 新起专用 Redis 容器（redis://127.0.0.1:6404/3）——上次用的 6404 实例已不存在\n- 不用 digital_employee_os_dev_nestjs：那是 dev 库，跑验收会被测试数据反复清洗\n- 理由是 G15/O1：本机 41 个容器多仓共用端口，且实测另有并行会话正在跑 enterprise-platform\n 的 api-nestjs。上次 runtime 长期假红的根因正是共用逻辑库导致三处订阅端收不到信封\n\nCLAUDE.md 证据新鲜度两行同步刷新（三级分开陈述，不互相冒充）：\n- 真实 DB：2026-09-14 🟡（dirty）→ 2026-09-18 ✅（clean dcd1c14）\n- 静态链：2026-09-14 ✅ 27/27 → 2026-09-18 🟡（clean 1994f3c 上 28 步全执行、前 27 绿，\n 末步 check:kernel-admission 诚实红 8 处）。「27/27」与「28 步 27 绿」不是退步，是多了一条\n 此前不存在的判据，且它一上来就报出真实缺口——该说明已写进文档行内，防止后来者误读为回归。\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 dcd1c14（声明落后 0，本提交自身使实测落后 1，\n落在 +1 自指窗内）。推送前已跑 check:docs-truth:assert 自检通过。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次（check:ui 不在 runtime 链内，未跑），\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:34:51-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/dcd1c1486e63a7f67a0c548158823764a0b58b21...1c8523a92bf32cb7257642251ad57e7a03ebf161","Len":1}...
|
1789720501
|
Edit
Delete
|
|
31071
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"8f5cd7985 {"Commits":[{"Sha1":"8f5cd7985999b41d324ba9c2216daf1ad49ca002","Message":"chore(reports): G-3 二十八份静态门禁证据 回绑 @ b7585cf，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 b7585cf（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=b7585cf、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是引入时那 8 处已知诚实红。\n\nfork-readiness 报告新增 frameworkCriteriaCoverage 字段：交叉核对 verified（从\n工程基础框架/base-framework 读到 14 条判据号）、declared 14、registeredMissing 3；\nmetrics 新增 frameworkCriteriaDeclared / frameworkCriteriaRegisteredMissing 两项，\n使「框架判据覆盖率」第一次成为可回归的机器数字，而不是读脚本才知道。\n\ncheck:rls 在角色名改为派生后复跑仍绿（67 张租户表 × tenant/system 双策略）。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:44:35-07:00"},{"Sha1":"b7585cfab7b8130271fea714f464f5117db3733f","Message":"feat(governance): fork-readiness 补齐框架判据覆盖——号段分家、F9/F12 落地、缺席不得静默\n\nG-3。本仓 check:fork-readiness 的 F1—F7 与框架逐条对应，**F8 起分叉**：本仓 F8 是自造的\n「验收 runner 自含 contracts 构建」，框架 F8 是「可执行迁移技能」——同号不同义。后果有两层：\n跨仓说「F8 红了」会指向两个判据；更要命的是同号**掩盖了框架 F8—F14 七条长期静默缺失**，\n而其中 F11 正是「内核退回 @juhai/kernel pin」的门禁前提。\n\n一、号段分家。自造判据一律 D 号段，F 号段只留给框架。原 F8 → D1。\n\n二、两条框架判据直接落地（落地优于登记）：\n\n F9 工作区包内不得存在嵌套 lockfile —— 实测仅根一份，落地即绿\n F12 租户 RLS 组角色名必须派生自 package.json name —— **实体缺陷已修**：\n scripts/check-rls.mjs 此前把 digital_employee_os_tenant / _system 写死在 5 处\n （2 处字符串 + 3 处正则模板）。值虽然是对的，但派生仓会拿**源项目**的角色名去校验\n 自己的策略，而这个断言存在的唯一目的就是证明策略绑在本仓的角色上——\n 它会在最需要生效的场景（移植后）静默失效，与 F3 同型。改为由 package.json name 派生，\n 并加 F12 断言守住不回潮。check:rls 仍绿（67 张租户表 × 双策略）。\n\n三、缺席不得静默：新增覆盖登记 framework-criteria.json + D2—D4。\n\n D2 框架 14 条判据必须逐条登记，未登记即红；status 只能是\n implemented / implemented-elsewhere / not-applicable / missing\n D3 登记为 missing 须 reason/registeredAt/expiresAt/blockedBy/replacementPlan 五字段齐全\n 且未过期（同 platform-dependency-deviations 口径：半份登记不算登记，过期不再豁免）\n D4 登记为 implemented 必须指向本脚本真实存在的判据号——防「空口宣称已实现」，\n 与 kernel.boundaries.json 的 admissionEvidence 自证同型\n\n 门禁在框架检出可达时**交叉核对判据号快照**（实测从\n 工程基础框架/base-framework 读到 14 条，与登记表逐条吻合 → verified）；不可达显式 SKIPPED\n 而非静默通过；BASE_FRAMEWORK_ROOT 显式指定却解析不到即红，不回落到工作区布局\n （首版写成了静默回落，实活探测发现后改为 fail-closed）。\n\n当前覆盖（实测）：implemented 9（F1—F7、F9、F12）· implemented-elsewhere 1（F10 由\nkernel-boundaries + kernel-admission 两把锁承接，粒度严于框架）· not-applicable 1（F13 本仓\n已剥离示例域）· **missing 3**：\n F8 无迁移技能路由、无 reports/framework-migration.latest.json，frameworkVersion 全仓零命中\n F11 契约包可依赖形态——**内核退回 pin 的门禁前提**\n F14 apps/api-nestjs/docker-compose.yml 无顶层 name，即工作区 L9「27 仓共用 project\n api-nestjs」的本仓实证；deploy/production/compose.yml 默认值 deos-production 也不等于\n 包名派生身份\n三条均登记至 2026-12-18，报为 registered 警告不阻断——但期限到即转红。\n\n自检 pnpm check:fork-readiness:self-test 11 条（含 2 条基线正例）；另做两次实活验证：\n删掉 F14 登记 → D2 红；BASE_FRAMEWORK_ROOT 指错 → D2 红。\n\nCLAUDE.md 同步：号段纪律段、判据表 +6 行、基线表行口径、C69 两处历史引用改「D1（原 F8）」。\n整轮 pnpm check 复跑：28 步全执行，仅末步 check:kernel-admission 已知 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-18T01:40:25-07:00"}],"HeadCommit":{"Sha1":"8f5cd7985999b41d324ba9c2216daf1ad49ca002","Message":"chore(reports): G-3 二十八份静态门禁证据 回绑 @ b7585cf，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 b7585cf（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=b7585cf、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是引入时那 8 处已知诚实红。\n\nfork-readiness 报告新增 frameworkCriteriaCoverage 字段：交叉核对 verified（从\n工程基础框架/base-framework 读到 14 条判据号）、declared 14、registeredMissing 3；\nmetrics 新增 frameworkCriteriaDeclared / frameworkCriteriaRegisteredMissing 两项，\n使「框架判据覆盖率」第一次成为可回归的机器数字，而不是读脚本才知道。\n\ncheck:rls 在角色名改为派生后复跑仍绿（67 张租户表 × tenant/system 双策略）。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:44:35-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/1c8523a92bf32cb7257642251ad57e7a03ebf161...8f5cd7985999b41d324ba9c2216daf1ad49ca002","Len":2}...
|
1789721078
|
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
|
|
31089
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"117a379da {"Commits":[{"Sha1":"117a379da5e5d31ea07d5b61eb2dcdfce479d5db","Message":"chore(reports): 内核退回 pin 立项的二十八份静态证据 回绑 @ 65b0b33，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 65b0b33（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=65b0b33、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次只立项、不动代码：内核仍是仓内 0.1.0 拷贝，F8 / F11 仍登记为 missing（期限\n2026-12-18 未变），replacementPlan 改为指向立项书。fork-readiness 的\nframeworkCriteriaCoverage 保持 declared 14 / registeredMissing 3 / 交叉核对 verified。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:52:57-07:00"},{"Sha1":"65b0b33923bcebdf42aed903963afe2ce4c0a2e1","Message":"docs(planning): 内核退回 pin 立项——硬前提已验证，真正要判断的只有四个模块\n\nframework-criteria.json 里 F8 / F11 两条 missing 都指向同一件事：本仓持有一份框架 0.1.0 的\n内核拷贝，既不受任何来源门禁约束，也无法表达「落后几代」。本立项把它改为 exact pin\n@juhai/kernel。\n\n硬前提今天全部满足（实测）：\n- @juhai/kernel 在 registry 上有 0.16.0 / 0.16.1 / 0.22.0；本仓 .npmrc 已声明 @juhai:registry\n- migration:plan --mode sync 实测 0.1.0 → 0.22.0 共 139 冲突，落在 packages/contracts 的只有 5 处\n- tenant.ts 三步拆分后 tenant 之名已腾空，同名不同义只剩 rls.ts 一处\n\n十五个内核模块四分类（按导出名集合求交）：\n 直接 pin 5 statemachine 100% · replay 100% · realtime-stats 100% · realtime-command 90% · subscription 81%\n 需合并 3 realtime 57% · job 28% · health 25%\n 同名不相干 1 rls.ts ↔ 框架 tenant-rls.ts，重合 0%\n 净迁入 6 replay-buffer · tenant · api-error · request-context · platform-ports · alert\n\n**真正要做判断的只有 4 个模块**，其余是白拿或补齐。净迁入里 platform-ports（31 导出）\n是关键：写链前经权限端口决策 + 成功写入同事务 audit.append、生产未设 PLATFORM_PORTS_MODE\n即 fail-closed——本仓分叉于框架 0.1.0、从未见过这组端口，才各自造了一套 permission/audit。\n迁入后自建实现塞进本地实现位，将来换控制面 client 时接口不变：错层资产的迁移从「大手术」\n降为「接插座」。\n\n路径选 ②（pin）不选 ①（继续 sync）：① 每次框架发版都要三方合并内核，而本仓已积压 22 个\n版本 / 139 冲突——那正是脱轨的形成机制；② 之后只需 bump 版本，且让内核来源进入\ncheck:platform-provenance 的判据面（今天内核是仓内源码，没有任何门禁能判定它是什么版本）。\n\n立项先挂一条待裁决：框架 F11 要求 pin 等于本仓 package.json.version（框架版本轴 = 内核\n版本轴），这对派生仓不成立——本仓 version 停在 0.1.0、0 个 tag。建议 A 案（本仓建版本轴，\nF11 改判「pin 等于迁移凭证里的 frameworkVersion」），顺带解掉缺失梳理 §4.4「产品仓只能按\ngitSha 钉 OS」；B 案（向框架提 FR 区分两种形态）可作回灌。\n\n分六批 B0—B5，逐批退出门写在 §5；风险五条写在 §6，其中 0.15.0 的作业 API 破坏性变更\n（job 重合仅 28%）与两套 RLS 二选一是最硬的两处。§7 显式登记本立项不做的事：不改自建\npermission/audit 的实现，替换另起一线且前置是控制面客户端发布**并有 CI 阶段门证据**。\n\n同步：framework-criteria.json 的 F8 / F11 replacementPlan 指向本立项；CLAUDE.md 可迁移性节\n加立项指针与要点。立项书内不做跨仓链接（c433d57 已清理过一轮仓外链接）。\n\nCo-Authored-By: Claude Opus 5 \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:51:25-07:00"}],"HeadCommit":{"Sha1":"117a379da5e5d31ea07d5b61eb2dcdfce479d5db","Message":"chore(reports): 内核退回 pin 立项的二十八份静态证据 回绑 @ 65b0b33，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 65b0b33（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=65b0b33、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次只立项、不动代码：内核仍是仓内 0.1.0 拷贝，F8 / F11 仍登记为 missing（期限\n2026-12-18 未变），replacementPlan 改为指向立项书。fork-readiness 的\nframeworkCriteriaCoverage 保持 declared 14 / registeredMissing 3 / 交叉核对 verified。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:52:57-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/8f5cd7985999b41d324ba9c2216daf1ad49ca002...117a379da5e5d31ea07d5b61eb2dcdfce479d5db","Len":2}...
|
1789721581
|
Edit
Delete
|
|
31098
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ee4bc0660 {"Commits":[{"Sha1":"ee4bc06608d88515f025c3a2dcffacb9f47c5417","Message":"chore(reports): B0 裁决的二十八份静态证据 回绑 @ 1f74faa，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 1f74faa（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=1f74faa、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\nB0 只落裁决未改代码，故 fork-readiness 的 frameworkCriteriaCoverage 不变：declared 14 /\nregisteredMissing 3（F8 / F11 / F14）/ 交叉核对 verified。F11 现挂 adjudication:\"B0\"，\n但按 B0 口径实现的 F11 断言要到 B5 才落——在那之前 F11 仍是诚实的 missing。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:58:16-07:00"},{"Sha1":"1f74faae838116a4d546b0edaf75f4fcba026cfc","Message":"docs(决策): B0 裁决 A2——F11 对派生仓改判为「pin == 凭证 source.frameworkVersion」\n\n内核退回 pin 立项 §4 挂的那条口径已裁。框架 F11 断言「@juhai/kernel 的 pin 必须等于本仓\npackage.json.version」（框架版本轴 = 内核版本轴），这条对框架自身成立，对本仓不成立：\n本仓 version 停在 0.1.0、0 个 tag，而根版本同时要服务「产品仓钉 OS」。\n\n**裁为 A2：本仓建立自己的版本轴；F11 迁入时改判为**\n\n contracts 对 @juhai/kernel 的 exact pin 必须等于\n reports/framework-migration.latest.json 的 source.frameworkVersion\n\n三条理由：\n- F11 的意图是「pin 与所同步的框架版本一致、落后几代可判定」，用凭证里的\n source.frameworkVersion 表达同样成立，且不强求派生仓与框架共用版本号\n- 若照框架原文把根版本设成 0.22.0，产品仓钉的「OS 版本」其实是框架版本，\n 缺失梳理 §4.4 不但没解决，还被永久占用\n- **该字段凭证里已经有**（record-migration.mjs 从源仓 package.json 读取），本口径\n 不需要新增任何东西——这是选 A2 而非提 FR 阻塞的关键\n\n**不照控制面先例的原因是形态不同。** 企业控制面走的是拆根：runtime/package.json 版本\n直接设为框架版本 0.22.0，故 F11 原文成立；仓根 0.1.0 与 contracts/ 1.0.0-rc.3 各留自己的\n版本。本仓是单 pnpm 根，用不了这个办法；改多根（立项 §4 的 A3）会牵动 turbo 布局、\n13 个 typecheck 任务与所有门禁的路径假设，不在这条线上做。\n\n**版本轴起点同批裁为「留到 B5 定」**：版本号要到 B5 签凭证、真正对外表达兼容范围时才\n用得上，那时内核换源的实际破坏面已清楚，定起点更有依据；现在定等于凭空拍。\n\n落点：framework-criteria.json 新增 adjudications.B0（含 assertion / rationale / precedent /\ndeferred / upstreamFeedback 五段），F11 挂 adjudication:\"B0\" 引用；立项书 §4 标已裁决、\n§5 的 B0 行标完成。CLAUDE.md 可迁移性节同步。\n\nB5 退出门顺带补两项：① 定版本轴起点（B0 顺延项）；② check:fork-readiness 按本裁决实现\nF11 断言时，同时加一条 adjudication 引用完整性判据——criteria.\u003cid\u003e.adjudication 指向的 key\n必须存在于 adjudications，防悬空引用，与 D4 防「空口宣称」同型。本批按立项 §5 不改代码，\n故该判据留到 B5 一并落。\n\n上游回灌（不阻塞）：可向框架提 FR，让 F11 区分「框架仓」与「派生仓」两种形态。\n\nCo-Authored-By: Claude Opus 5 \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:56:44-07:00"}],"HeadCommit":{"Sha1":"ee4bc06608d88515f025c3a2dcffacb9f47c5417","Message":"chore(reports): B0 裁决的二十八份静态证据 回绑 @ 1f74faa，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 1f74faa（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=1f74faa、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\nB0 只落裁决未改代码，故 fork-readiness 的 frameworkCriteriaCoverage 不变：declared 14 /\nregisteredMissing 3（F8 / F11 / F14）/ 交叉核对 verified。F11 现挂 adjudication:\"B0\"，\n但按 B0 口径实现的 F11 断言要到 B5 才落——在那之前 F11 仍是诚实的 missing。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T01:58:16-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/117a379da5e5d31ea07d5b61eb2dcdfce479d5db...ee4bc06608d88515f025c3a2dcffacb9f47c5417","Len":2}...
|
1789721899
|
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
|
|
31100
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"32ad69a15 {"Commits":[{"Sha1":"32ad69a15ceb55e1cbcb170d7fdd47897e50c01b","Message":"chore(reports): check:caddy 回绑 @ 426a7df\n\n干净检出（.worktrees/rebind-426a7df）重跑，worktreeDirty=false；\n两个 profile 各 0 违规，caddy validate 经 docker 两份都 passed（不是 skipped）。\n报告新增 workbench 段，其中 guardsDocumentNavigation=false 是登记事实：\n入口鉴权只挡带 Authorization 头的数据面，纯静态 SPA 的文档导航挡不住。\n\n主工作区有并行会话 WIP，本次只还原本任务改动的这一份报告。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T02:05:49-07:00"},{"Sha1":"588e5ab9459d1df433f3a32b44a4afe589b6a9b7","Message":"chore(reports): check:gate-flow 回绑 @ aaf43ee\n\ncontracts:check 由 tool 订正为 gate 后重跑：46 个脚本、34 个有消费入口、\n12 个流外（门禁 5 / 工具 7）、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:04:43-07:00"},{"Sha1":"426a7df100b7b8c2c82179f2b184ed066f6ceba6","Message":"feat(stack,governance,workbench): 工作台同源托管与 /api/platform/* 入口鉴权（CHG-018 阶段 ②）\n\nCaddy 两个 profile 同步改：根路径托管工作台静态产物（产物未挂载时回原占位响应），\n/_next/* 先在产物里找文件、找不到才回身份 Web，@platform 块内对 /api/platform/*\n做 forward_auth → /t/{$PLATFORM_WORKBENCH_TENANT}/oidc/userinfo。租户空值即\n/t//oidc/userinfo → 上游 404 → 整段拒绝，不配置 = 不放行，与 PLATFORM_OPS_* 同纪律。\n\n入口只挡带 Authorization 头的数据面，挡不住文档导航：工作台是纯静态 SPA，令牌进\nsessionStorage 不进 cookie，浏览器发文档请求时网关手上没有可校验的凭据。要挡住静态壳\n就得有个发 cookie 的边缘会话组件，与 CHG-018 §5.1 已裁的形态相抵，须另起 CHG。这条\n边界写进 caddy-routes.json 的登记与报告的 guardsDocumentNavigation，不靠读代码猜。\n\n连带修好取数链路：三个读面的 accessToken 此前从没有调用方传过值（读面本来公开），\n入口挡上后工作台登录了也会永远 401。现改为必填形参；hooks 从 session store 取令牌，\n身份（不是令牌）进 queryKey，补水前不发请求，退出时清缓存。\n\ncheck:caddy 增 workbench 段与四条规则，两 profile 各 0 违规、caddy validate 经 docker\n两份都 passed；六条负向用例逐条先红后绿。另修一条已失效的旧夹具：UPSTREAM_MISSING 那条\n用 String.replace 只换第一处，forward_auth 引入同名变量后它再也换不到 reverse_proxy，\n改 replaceAll 并补一条「确实解绑了上游」的断言。\n\ndev 运行态取证与未闭环项（D-8 判责码语义、D-9 门禁守不住的绕过、D-10 issuer 不一致、\n带有效令牌的 200 分支未实测）见 docs/工作台同源托管与入口鉴权实现记录-2026-09-18.md。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T02:04:42-07:00"},{"Sha1":"aaf43ee0442d5b4a5d36325a92c1ae5bbff3c76b","Message":"chore(reports): 工作台目录与运维快照回绑 @ 8a53c39\n\n在 8a53c39 的临时干净检出里重跑 `node governance/build-workbench-snapshots.mjs`\n（主工作树有并行会话的在途改动，就地跑只能产出 worktreeDirty=true 的绑定）。\n\n目录快照：schemaVersion 2，21 条 → stale 7 / not-in-manifest 14，conflicts 0。\n运维快照：schemaVersion 仍为 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-18T02:04:29-07:00"},{"Sha1":"90f3b99b5976b58431097147662a1253b096840c","Message":"fix(governance): 订正 gate-flow 把 contracts:check 登记成 tool——它是一道有人写、没人跑的门禁\n\n昨天登记它时我写的是「role: tool，组成部分已被消费：check:local 在根 check 链与 CI\nstatic job 里」。**那是错的。** `contracts check` 比 `check:local` 多跑一个\n`scripts/check.mjs`，而那正是**对真实 Catalog 跑治理 linter** 的那一道：checkRegistry\n校验 8 份 Catalog、决议状态、应用清单、Fact 与权限命名、scopes 的阻断引用。\n`check:local` 只跑 schema-compatibility / impact-graph / check:generated / build / test。\n根链与 CI 用的都是 check:local，所以真实 Catalog 的治理判定**不在任何自动流里**，\n只有人手动敲 `pnpm contracts:check` 才会发生。\n\n技术原因不是疏忽：linter 需要工作区根（Catalog 的 directory / code_truth / evidence 与\n决议 source 都是相对工作区的路径），CI 只 checkout 本仓，接进根链会以\nWORKSPACE_ROOT_UNRESOLVED 退出 2——check:local 正是为此存在。\n\n**但挡它在链外的历史理由已经不成立。** CLAUDE.md 当前状态节写着「`check` 余 6 项\nPLATFORM_PROJECT_UNREGISTERED 待 CHG-001」，2026-09-18 实测**已全部通过**：\n17 draft apps / 168 governed entity / 11 draft fact / 9 permission resource /\n39 decisions（32 approved / 3 pending）/ 21 platform projects（19 in goal scope），\nschema 兼容 11/11 immutable，影响图 258 节点 297 边。又一次「条件早已满足而无人察觉」。\n\n已改为 role: gate，带 reason / wireInWhen / conditionReviewBy（2026-10-31）：剩下的\n只是工作区可达性，两条路二选一需裁决——给 CI 一条能取到工作区的 job（或把 linter 需要\n的工作区事实快照进本仓），或在工作区侧另起 workspace-only 链由治理层消费。\nCLAUDE.md 那句已划掉并补上实测与原因，免得下一个会话照着旧结论重走一遍。\n\n流外分布随之 4 门禁 / 8 工具 → 5 门禁 / 7 工具。\n\nCo-Authored-By: Claude Opus 5 \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:23-07:00"}],"HeadCommit":{"Sha1":"32ad69a15ceb55e1cbcb170d7fdd47897e50c01b","Message":"chore(reports): check:caddy 回绑 @ 426a7df\n\n干净检出（.worktrees/rebind-426a7df）重跑，worktreeDirty=false；\n两个 profile 各 0 违规，caddy validate 经 docker 两份都 passed（不是 skipped）。\n报告新增 workbench 段，其中 guardsDocumentNavigation=false 是登记事实：\n入口鉴权只挡带 Authorization 头的数据面，纯静态 SPA 的文档导航挡不住。\n\n主工作区有并行会话 WIP，本次只还原本任务改动的这一份报告。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T02:05:49-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/1e6f71d846a9ad3bcbd04a3f2b5fdb3f69ca1884...32ad69a15ceb55e1cbcb170d7fdd47897e50c01b","Len":11}...
|
1789722432
|
Edit
Delete
|
|
31101
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"fd3ba87ed {"Commits":[{"Sha1":"fd3ba87ed111d9245012f0578178cccb4743ab20","Message":"chore(reports): B1 的二十八份静态证据 回绑 @ fb2fb1a，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 fb2fb1a（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=fb2fb1a、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次内两把锁各重签一次，都是「变更即复核」而非绕过：\n- kernel.exports.lock.json 763 → 755（statemachine 的 8 个导出归属转移给 @juhai/kernel）\n- check:kernel-downstream 的仓外夹具改为携带 scoped registry 后转绿；缺声明即 fail-closed\n 的分支已实活验证\n\n运行态未跑：B1 只动契约包的一个转发文件，contracts 312/312 与 typecheck 13/13 已覆盖；\n按仓规矩三级证据分开陈述，不用静态绿冒充运行态绿。runtime 报告仍绑在 dcd1c14，\n下次动到两后端（B3′ 采纳上游加固）时必须重跑。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T02:08:00-07:00"},{"Sha1":"fb2fb1a730a522c6210afc0223c84aaa6946194d","Message":"feat(contracts): B1 内核首次 exact pin @juhai/kernel@0.22.0，statemachine 改为转发\n\nB1 的目的是**验证机制**，不是搬最多的代码：装包、转发、门禁、锁四条链路全走一遍，\n用唯一可证明零行为变化的模块做载体。\n\n- packages/contracts exact pin @juhai/kernel@0.22.0（registry 上有 0.16.0/0.16.1/0.22.0）\n- statemachine.ts 改为**具名**转发 8 个符号。不用 `export * from \"@juhai/kernel\"`：\n 收口前本仓还留着 10 个未迁内核模块，整体 re-export 会与它们的同名导出冲突\n- 机制验证结果：typecheck 13/13 · contracts 312/312（statemachine.test.ts 打的就是转发后的\n 实现）· 整轮 28 步前 27 绿 · **check:platform-provenance 接受新 pin**（lock 解析到 Gitea\n registry tarball）· 所有权锁 763 → 755，8 个导出的归属转移给内核包\n\n**开工即修正一处自己的判断。** 上一轮我把五个模块叫「白拿」，依据只到导出名重合率。\n逐文件 diff 后：**只有 statemachine 逐字一致**（104 行 diff 0），其余四个实现都不同，\n且方向一致——框架领先、本仓落后，落后的正好是加固：\n\n replay 框架有 maxSeq + 「游标超前于现存最大 seq ⇒ 报缺口（cursor-unknown）」，\n 本仓没有 ⇒ 伪造/串号游标被静默判成「已追平」，客户端永远收不到补发；\n 框架同时修了契约文件内部自相矛盾的 dispatchedAt 注释\n realtime-command 框架有 REALTIME_WS_MAX_PAYLOAD_BYTES，本仓 WS 载荷无上限\n subscription 框架有 REALTIME_MAX_SUBSCRIPTION_IDS/_TYPES，本仓订阅列表无上限\n realtime-stats 本仓是严格超集（多 10 个死信域导出），采纳时要保留\n\n前两类偏 DoS 面。这四个不是「白拿」而是「采纳上游加固」，要改两后端并重跑运行态，\n已从 B1 移入 B3′。立项 §2 加了修正块、§5 改了批次表。\n\n**两处实测新增风险（立项 §6）：**\n\n一、跨层 peer 不一致。已发布的 @juhai/client-fact@1.0.0-rc.3 声明 peer @juhai/kernel: 0.16.1\n（lockfile 权威），而控制面仓里**同版本的源码**声明 0.22.0——控制面昨天做框架同步时改了\n源码却没重新发布。本仓 pin 0.22.0 后 pnpm install 报 unmet peer（警告，不阻断），\n**且现有门禁一条都抓不到**。三条出路（等平台重发 / 本仓退回 0.16.1 / 登记偏差并加 peer\n判据）本提交不代为决定，登记在立项 §6 等裁。\n\n二、pin 的下游代价，由 check:kernel-downstream 第一时间抓到：它在仓外装 contracts 以证明\n下游可消费，而仓外没有 .npmrc，@juhai/kernel 落到 npmjs.org 上 404。这不是门禁的毛病，\n是 pin 的真实代价——**任何消费方不配 @juhai scoped registry 就装不上**（框架 F11 原文同样\n这么声明）。处理：夹具复制仓内 .npmrc 的 scoped registry 行，把断言坐实为「配了 registry\n的消费者装得上」；并在「pin 了 @juhai/* 却无 registry 声明」时 **fail-closed**，绝不静默\n回落到公共 registry（实活验证：去掉声明即 D4 红）。新前提已写进接入手册，五个产品仓\n迁移时要同步配置。\n\n顺带一个可复用的性质：check:kernel-admission 的 K1 只计**直接声明**，所以每迁走一个模块，\n锁里的自有导出数就降一次——它天然成了这条线的进度计（763 → 755）。\n\nCo-Authored-By: Claude Opus 5 \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:06:23-07:00"}],"HeadCommit":{"Sha1":"fd3ba87ed111d9245012f0578178cccb4743ab20","Message":"chore(reports): B1 的二十八份静态证据 回绑 @ fb2fb1a，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 fb2fb1a（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=fb2fb1a、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次内两把锁各重签一次，都是「变更即复核」而非绕过：\n- kernel.exports.lock.json 763 → 755（statemachine 的 8 个导出归属转移给 @juhai/kernel）\n- check:kernel-downstream 的仓外夹具改为携带 scoped registry 后转绿；缺声明即 fail-closed\n 的分支已实活验证\n\n运行态未跑：B1 只动契约包的一个转发文件，contracts 312/312 与 typecheck 13/13 已覆盖；\n按仓规矩三级证据分开陈述，不用静态绿冒充运行态绿。runtime 报告仍绑在 dcd1c14，\n下次动到两后端（B3′ 采纳上游加固）时必须重跑。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T02:08:00-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/ee4bc06608d88515f025c3a2dcffacb9f47c5417...fd3ba87ed111d9245012f0578178cccb4743ab20","Len":2}...
|
1789722483
|
Edit
Delete
|
|
31102
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1b2328540 {"Commits":[{"Sha1":"1b2328540134f0118d2e3ed9abe10095e2ae4679","Message":"chore(reports): 工作台两份快照回绑 @ 956c7b6\n\ndocs/runbook.md 在 workbench-ops-snapshot 的作用域里（error 级），上一条 §7 补注把它打成\n过期；同时 bc44b4a 改了 build-workbench-snapshots.mjs，两份快照的作用域都被碰到。经\npnpm reports:rebind --gates workbench-snapshots 在 HEAD 干净检出里重跑带回，两份均绑\n956c7b6 / worktreeDirty=false / status=ok。\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:15:12-07:00"},{"Sha1":"d9664ca9989ad3ea59399f95b6fcd56544170c52","Message":"chore(reports): check:module-imports 与 runtime-governance 回绑 @ bc44b4a\n\n两道门禁都在 bc44b4a 的临时干净检出里重跑（主工作树有并行会话的在途改动）：\ncheck:module-imports 扫 387 个源文件 0 处跨模块 import；runtime-governance 走读\napps/ 源码，tenant/outbox 五项接线指标均为 0。两份 provenance 均 worktreeDirty=false。\n\n两条限制写在这里，别把绑定当成这两道门禁现在是绿的：\n1. module-imports 的作用域含 governance/check-module-imports.mjs，该文件此刻仍是未提交\n 状态（并行会话在改），所以 check:evidence 仍会按 EVIDENCE_WORKTREE_CHANGED 记它，\n 要等那份改动落盘后再回绑一次。\n2. runtime-governance 是单跑一道，runId 与 runtime/reports 里同批的其余静态子报告不同。\n runtime 的 check:governance 要求静态子报告同一 SHA/dirty/runner/runId，重新对齐只能靠\n 一次完整的 pnpm --dir runtime 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-18T02:14:40-07:00"},{"Sha1":"956c7b6ad393ce44aa9aae0d647ae59fbc61ec56","Message":"docs(runbook): §7 补第四处「前置失败销毁好证据」——revocation-sla 由用例自己在 beforeAll 写 failed\n\n§7 现有那条 2026-09-18 警告说的是三个 runner（adda76a 已修前置守卫段）。同族还有第四处，\n且是唯一一处在测试代码里的：reports/revocation-sla.latest.json 的写入者不是 runner，而是\nruntime/test/e2e/revocation-sla.test.ts 自己（check-mainline.mjs 全文只写 mainline-acceptance）。\n\n要害在时机——该文件 beforeAll 的第一句（:68）就无条件写下 RUN_NOT_COMPLETED，下一句才做\nisolated() 库名校验（mainline-support.ts:11 要求 /platform_\u003ckind\u003e_(ms23|test|ci)）。先毁证据\n再校验前置，正是 adda76a 修掉的那个毛病。\n\n触发面不止 mainline:check：runtime/test 是工作区包 platform-tests，pnpm runtime:check:runtime\n第 5 步 turbo run test 就会跑到它。2026-09-18 实测：七个模块库建成 platform_\u003cm\u003e_acc0918 时\ne2e/chaos 整片以 MAINLINE_ISOLATED_DATABASE_REQUIRED 失败，该报告同时被清空。故「前置守卫段\n已修复、只有跑到一半才会写 failed」对本处不成立，本条一并写明救回方式。\n\n代码修复尚未做且本轮不做：runtime/test 正在三份验收报告的作用域里，重跑期间改它等于把刚跑出\n的绑定再作废一次。已登记在治理仓开发计划 §8 变更记录（2026-09-18）。\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:13:53-07:00"},{"Sha1":"bc44b4a3ccbdd4d16bd479c15f78c321a273e243","Message":"fix(governance): 工作台目录快照单列采纳形态，并按 Catalog 证据现算托管消费者数\n\n无运行时模块的 14 条 Catalog 条目此前被快照压成两类说法，两处都低报了 Catalog 已有的事实。\n\n一、form=adopted 的三条 P0（应用群网关 / 统一交付平台 / 集中观测平台）code_truth=null、\n无运行时模块，落进 none 分支后 note 写成「只保留历史设计引用，不可调用」。实际落点是本仓\n采纳的入口、collector 与发布/晋级门禁，evidence 里逐条登记（Caddyfile + check-caddy、\notel collector + check-otel、release-manifest + check-promotion），2026-09-16 经\nCHG-009 / 011 / 012 由 Owner 裁决改指采纳形态落点。新增 consumption.kind =\nadopted-infrastructure，判据取 Catalog 的 form，排在 code_truth 推断之前——这类能力本就\n不会有 runtime/modules 或契约包路径。当前 Catalog 下 none 归零。\n\n二、三条 module_e2 共用一句「迁出需三消费者 + G4 证据」，而 evidence 本就记着差别：\n公共文件 3 个、通知与 Webhook 3 个、配置与功能开关 1 个（与 contracts/README.md\n「配置平台尤其仍缺第二、第三消费者」一致）。hostedConsumerEvidence 按 evidence 里本仓之外的\n*acceptance*.json 依消费方仓去重计数，写进 consumption.consumers，note 按是否达到三消费者\n分开说。count \u003e= 3 只说明消费者验收证据齐，不代表 G4 已裁决。\n\n数据全部取自既有 Catalog 字段，不新设人工台账、不改 contracts/catalogs/、不动 Schema；\ndesign 只增透传的 form。consumption.kind 取值域扩了一个，枚举穷尽的消费者须回看，\nCATALOG_SCHEMA_VERSION 2 -\u003e 3，rules 两条措辞同步改。\n\n测试 8 -\u003e 9：真实输入用例断言三条采纳形态不落 none、三条托管条目的消费者数与 note 各不相同；\n新增一例专测消费者计数（同仓多份验收只算一个、本仓门禁产物不算、非 acceptance 不算）。\n篡改必红实测：短路 adopted 分支与阈值后 3 例转红。治理全量 323/323。\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:10:08-07:00"}],"HeadCommit":{"Sha1":"1b2328540134f0118d2e3ed9abe10095e2ae4679","Message":"chore(reports): 工作台两份快照回绑 @ 956c7b6\n\ndocs/runbook.md 在 workbench-ops-snapshot 的作用域里（error 级），上一条 §7 补注把它打成\n过期；同时 bc44b4a 改了 build-workbench-snapshots.mjs，两份快照的作用域都被碰到。经\npnpm reports:rebind --gates workbench-snapshots 在 HEAD 干净检出里重跑带回，两份均绑\n956c7b6 / worktreeDirty=false / status=ok。\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:15:12-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/32ad69a15ceb55e1cbcb170d7fdd47897e50c01b...1b2328540134f0118d2e3ed9abe10095e2ae4679","Len":4}...
|
1789723947
|
Edit
Delete
|
|
31111
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"3deb4ea37 {"Commits":[{"Sha1":"3deb4ea37b83c2e2977c9c2b8e8166c101002860","Message":"chore(reports): PEER_UNSATISFIED 判据的二十八份静态证据 回绑 @ 8e5c633，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 8e5c633（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=8e5c633、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\nplatform-dependency-provenance 报告新增一处 registered：PEER_UNSATISFIED（client-fact\nrc.3 的 peer 0.16.1 ↔ 本仓已解析 0.22.0），期限 2026-12-18。门禁整体仍绿——登记的作用是\n把「pnpm 只打 WARN、门禁零覆盖」变成「可见、有期限、到期转红」，不是让它消失。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T02:38:50-07:00"},{"Sha1":"8e5c633cbfbc16afc61c95b8cfcecb90a2f1aa88","Message":"feat(governance): PEER_UNSATISFIED 判据——把 pnpm 只打 WARN 的跨包版本不一致变成可见可登记\n\nB1 pin @juhai/kernel@0.22.0 后 pnpm 报了一行 unmet peer 就继续装，**本仓原有门禁一条都\n抓不到**。按内核退回 pin 立项 §6 三条出路裁为 ③（登记偏差 + 加判据，不停等发布列车）。\n\n新判据 PEER_UNSATISFIED：lock 里 @juhai/* 之间声明的 peer 必须被已解析版本满足；\n未满足即红，可按既有五字段口径登记降级为 registered，过期转红。peer 指向本仓根本没装的\n包时不判（防过度判红）。自检从 7 条扩到 12 条，新增 5 条全覆盖上述分支。\n\n实测命中一条真问题，并顺带拆出更深的一层：\n\n- 已发布的 @juhai/client-fact@1.0.0-rc.3 声明 peer @juhai/kernel: 0.16.1（发布物自证），\n 而控制面仓里**同版本的源码**声明 0.22.0——2026-09-17 框架同步只改了 package.json 没重发\n- 把 registry 上的 rc.3 拆开看：dist 里**没有** Authorization 回查鉴权，而源码 reader.ts:31\n 发 Bearer ${token}。**同一个版本号，registry 与源码是两份不同的代码**\n- 该发布物 provenance.json 为 runner:\"local\" / reports:[] / **gitSha:\"\"**——空字符串。\n 任何消费者都无法验证装到的包出自哪次提交，上一条「同版本不同内容」因此无法被机器发现\n\n不兼容风险经 delta 分析可论证为极低：内核 v0.16.1 → v0.22.0 只改 health.ts(+126)、\nalert.ts(+53)、tenant.ts(+12) 三处纯增，client-fact 一个都不消费。故登记而非阻断，\n期限 2026-12-18，blockedBy 指向平台发布列车（G-12 计费阻塞）。\n\n为什么不选另两条路（立项 §6 已记）：② 退回 pin 0.16.1 的当前代价几乎为零——三处加固\n（replay cursor-unknown、WS 载荷上限、订阅数上限）**实测都已在 v0.16.1 里**，我上一轮说\n「退回等于放弃 6 个版本加固」是错的——但它是伪解，B2 要迁 alert/tenant、B3 要迁 health 时\npeer 冲突原样回来；① 等平台重发会把本仓进度挂在不可控的跨仓列车上，且若仍走本地旁路，\nprovenance 依旧无 gitSha，只解决 peer 不解决可对账性。\n\nCo-Authored-By: Claude Opus 5 \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:37:17-07:00"}],"HeadCommit":{"Sha1":"3deb4ea37b83c2e2977c9c2b8e8166c101002860","Message":"chore(reports): PEER_UNSATISFIED 判据的二十八份静态证据 回绑 @ 8e5c633，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 8e5c633（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=8e5c633、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\nplatform-dependency-provenance 报告新增一处 registered：PEER_UNSATISFIED（client-fact\nrc.3 的 peer 0.16.1 ↔ 本仓已解析 0.22.0），期限 2026-12-18。门禁整体仍绿——登记的作用是\n把「pnpm 只打 WARN、门禁零覆盖」变成「可见、有期限、到期转红」，不是让它消失。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T02:38:50-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/fd3ba87ed111d9245012f0578178cccb4743ab20...3deb4ea37b83c2e2977c9c2b8e8166c101002860","Len":2}...
|
1789724335
|
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
|
|
31140
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"05e3826e9 {"Commits":[{"Sha1":"05e3826e9e9e4dbbdd753252c2134b8494b08f2b","Message":"chore(reports): 工作台两份快照回绑 @ dfd4832\n\ndocs/runbook.md 在 workbench-ops-snapshot 的作用域里且是 error 级——改 §7 那段就会当场\n把 check:evidence 打红。经 reports:rebind 在 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-18T07:11:36-07:00"},{"Sha1":"dfd483287cee48db9791915cf33e037c4f758f6f","Message":"chore(reports): :68 修复波及的四份验收重跑回绑 @ 08c3788\n\n作用域含 runtime/test 的三份（runtime-acceptance / mainline-acceptance / revocation-sla）\n加上连带重写的 conformance-differential，在 HEAD 的干净检出 + 隔离栈 enterprise-platform-ms23\n重跑，全部 worktreeDirty=false：\n\n- runtime-acceptance passed（7 步全绿）\n- conformance-differential passed\n- mainline-acceptance passed（fact-read-http 11 / fact-persistence 17 / audit-tamper 19 /\n mainline-revocation-chaos 18）\n- revocation-sla partial（p95 5036 ms，20 样本）\n\n结果与修复前一致，说明这次动的只是写报告的时机，没有动判据。\nui-acceptance / identity-ui 作用域不含 runtime/test，未受影响，保持原绑定。\n\nCo-Authored-By: Claude Opus 5 \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:11:12-07:00"},{"Sha1":"925eee8195821074b0e2a699acc87b4af2ea35c4","Message":"docs(部署,runbook): 记录补 §10——:68 已修、两个方向的负向实测与隔离栈会被清空的教训\n\n- runbook §7 第四处那段的收尾从「代码修复尚未做」改成已落 08c3788，并写清改的是调用点不是\n 删掉占位写；那句「跑之前先确认这份报告已提交」现在只对「跑到一半失败」成立\n- 部署记录补 §10：负向实测两个方向（旧代码毁报告 / 新代码 sha256 不变）、正向确认 t+85s\n 仍写 RUN_NOT_COMPLETED、四份重跑结果，以及中途踩的一脚——enterprise-platform-ms23 是\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-18T07:11:12-07:00"},{"Sha1":"08c3788da42c5e8a4949daa8d5c7f23d30016205","Message":"fix(runtime): revocation-sla 的「已开跑」标记挪到前置校验之后——先毁证据再校验是反的\n\nadda76a 把三个验收 runner 改成「前置失败即退出、不碰报告」，但 revocation-sla 的报告不是\nrunner 写的，是用例自己写的，所以那次没覆盖到它——这是同病的第四处（runbook §7，2026-09-18 补注）。\n\n原形态：beforeAll 的**第一句**就无条件写 status=failed / RUN_NOT_COMPLETED，**下一句**才做\nisolated() 白名单校验。于是「环境没配对、这一轮根本没开始」也会先把上一轮的好报告毁掉。\n2026-09-18 重跑六份验收时第一次就踩到：模块库用了不在白名单里的名字，绑 765300b 的 partial\n当场没了（只因为跑在独立检出里才幸存）。\n\n改法不是删掉这个标记——「跑起来但没跑完」确实该在盘上留 RUN_NOT_COMPLETED 而不是上一轮的\npartial，这是用例自己写报告带来的责任。改的是**调用点**：挪到全部前置都满足之后，即模块库白名单\n通过、真实连库建好动作、API 子进程起来且 /health 就绪的那一刻。\n\n负向实测（两个方向都做了，确认这条改动真的有牙）：\n- 同一条件下跑旧代码：报告被改写成 RUN_NOT_COMPLETED（sha256 变化，好报告已毁）\n- 同一条件下跑新代码：测试照样以 MAINLINE_ISOLATED_DATABASE_REQUIRED 失败，报告 sha256 逐字节不变\n两次都用 DATABASE_URL_PERMISSION=…/platform_permission_notallowed 触发，5 例 skipped。\n\ntypecheck 通过（platform-tests 无 lint 配置，只有 test / typecheck 两个脚本）。\n受影响报告（runtime-acceptance / mainline-acceptance / revocation-sla，作用域含 runtime/test）\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:51:53-07:00"},{"Sha1":"1f6fa2521e4d947ecd0ee43b18e691f836522049","Message":"docs(部署): 记录补 §9——六份验收在隔离栈重跑的结果与三个未写全的前置\n\n六份全部真跑回来（4 passed / 1 partial 设计内 / 1 passed），check:evidence 36 新鲜 / 4 过期。\n补上 runbook §7 没写全的三条：模块库后缀白名单、必须非超级用户角色、模块迁移要先 deploy。\n并登记 revocation-sla.test.ts:68 先毁证据再校验前置的缺陷与不在本轮修的理由。\n\nCo-Authored-By: Claude Opus 5 \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:01-07:00"}],"HeadCommit":{"Sha1":"05e3826e9e9e4dbbdd753252c2134b8494b08f2b","Message":"chore(reports): 工作台两份快照回绑 @ dfd4832\n\ndocs/runbook.md 在 workbench-ops-snapshot 的作用域里且是 error 级——改 §7 那段就会当场\n把 check:evidence 打红。经 reports:rebind 在 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-18T07:11:36-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/1b2328540134f0118d2e3ed9abe10095e2ae4679...05e3826e9e9e4dbbdd753252c2134b8494b08f2b","Len":6}...
|
1789740912
|
Edit
Delete
|
|
31143
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"91b525700 {"Commits":[{"Sha1":"91b5257007ab9d588dcada5c5ca8d0c41a024bb9","Message":"chore(reports): B2 的四十一份三级证据 回绑 @ d1eb586，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 d1eb586（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=d1eb586、worktreeDirty:false）：\n静态 28 + 运行态 13。\n\n运行态实测与基线逐项持平，**tenantId 收敛在真实写链上行为中性**：\n testsPassed 733（基线 733）· behaviorParityCases 204（基线 204）· testFailures 0\n 87 项指标零违规\n静态整轮 28 步全执行、前 27 绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次跑了三轮 runtime，前两轮红，都不是 B2 的代码问题，如实记录：\n\n一、第一轮 outcomes.integration.test.ts「outcome not opened in time」（15 秒 E2E 超时）。\n 判为偶发，依据三条：该测试用 tenant-a-nestjs-outcome，在新 schema 下合法；整份日志里\n 新校验的拒绝消息 / ZodError / invalid_string **0 次命中**；同一份代码隔离重跑该文件\n 14/14 通过。第三轮整轮亦一次过。\n 顺带记一个行为：**失败的 runtime 会删掉 8 份运行态报告**（跑到一半中止、未重新生成）。\n\n二、第二轮测试全过（733 / 204-204 / 0 失败）但整轮记 failed，红在末尾的文档复核\n governance-kernel-boundary-number-consistency。根因是本会话的一次操作失误：\n `git restore reports/` 用了目录级范围，把已重新生成的 kernel-boundaries.latest.json\n 退回 HEAD 版（143/143），而 CLAUDE.md 已是 144/144。重跑静态后边界报告回到 144/144，\n 又撞上 governance-number-evidence-shape（要求一份 passed 的 runtime），于是必须再跑\n 第三轮才解环——这正是 CLAUDE.md 记载过的那个环。\n\n 同一次失误还抹掉了三份 reports/ui-*.latest.json 的未提交改动（不属本会话）。\n 已用 git fsck --lost-found 从游离 blob 全数找回并逐字核对：它们是 2026-09-15 的 UI 验收，\n 绑 c433d57 且 dirty=false。本提交仍未包含它们。\n 教训具体化：reports/ 下同时存在「本会话产出的」与「别人的」两类文件，任何范围操作都会\n 同时命中两类，**还原必须逐文件点名**。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T07:31:09-07:00"},{"Sha1":"d1eb5860c4337cf457a03c76670d2551dc848cee","Message":"feat(contracts): B2 迁入内核租户原语，收敛 tenantId 的三套口径为单源\n\n立项 B2 原写「净迁入六个」。开工时改了做法并写回立项：**净迁入的模块不该先暴露后接线**。\napi-error / replay-buffer / request-context / platform-ports / alert 只加到 barrel 而不接线，\n就是新增零消费者的 CORE 面——正是本仓 check:kernel-admission 的 K5 在盯、K4 判「声明无回执」\n的同型。改为**接线时才迁入**。六个里只有 tenant 是「迁入即能用」的，本批只做它。\n\n一、packages/contracts/src/tenant.ts 转发 @juhai/kernel 的 11 个租户解析原语。\n 这个名字是上一步 tenant.ts → authorization.ts 改名腾出来的；本仓此前**完全没有这一组**。\n\n二、用它收敛 tenantId 的三套口径（8 处 / 6 个文件）：\n z.string().min(1) × 6（无上限、无字符约束） → tenantIdSchema\n .max(128) × 2（有长度无形状） → tenantIdSchema\n ^ten_.+$（事实投影，自成一套） → **叠加**在内核形状之上，不再另起\n\n 判据直接委托 normalizeTenantId，不在仓内重写正则——重写就又是一套口径。\n 用 normalizeTenantId(v) === v 而非 !== undefined：后者放行带首尾空白的值\n （normalize 先 trim 再判），于是「校验通过的值」与「真正该存的值」不是同一个。\n\n收紧实测咬住 11/11。B2 之前 z.string().min(1) 会放行全部这些：\"\"、\" t1 \"、\"t/1\"、\n**\"t\\n1\"**、\"_t\"、129 字符。含换行符那条是框架注释点名的伪造日志行向量（NestJS 侧有字符串\n拼接日志）；129 字符那条对应 users 表 @@unique([tenantId, email]) 撞 Postgres btree 约\n2704 字节行上限打 500。也就是说本仓在此之前**没有任何 tenantId 形状与长度校验**。\n\n三处门禁如实红过再修，没有一处先改门禁：\n check:kernel-boundaries B3 新内核面未归类 → tenant.ts 归 CORE（contractModules 32）\n check:kernel-packages P7 公开面变更须伴随版本上调 → @repo/contracts 1.18.0 → 1.19.0\n check:kernel-admission K1 导出清单漂移 → 重签（40 模块 / 756 导出）\n连带同步接入手册下游锁行与 CLAUDE.md 边界数字 143/143 → 144/144。\n\n验证：contracts 312/312 · typecheck 13/13 · 整轮静态 28 步前 27 绿（末步仍是那 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-18T07:04:17-07:00"}],"HeadCommit":{"Sha1":"91b5257007ab9d588dcada5c5ca8d0c41a024bb9","Message":"chore(reports): B2 的四十一份三级证据 回绑 @ d1eb586，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 d1eb586（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=d1eb586、worktreeDirty:false）：\n静态 28 + 运行态 13。\n\n运行态实测与基线逐项持平，**tenantId 收敛在真实写链上行为中性**：\n testsPassed 733（基线 733）· behaviorParityCases 204（基线 204）· testFailures 0\n 87 项指标零违规\n静态整轮 28 步全执行、前 27 绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次跑了三轮 runtime，前两轮红，都不是 B2 的代码问题，如实记录：\n\n一、第一轮 outcomes.integration.test.ts「outcome not opened in time」（15 秒 E2E 超时）。\n 判为偶发，依据三条：该测试用 tenant-a-nestjs-outcome，在新 schema 下合法；整份日志里\n 新校验的拒绝消息 / ZodError / invalid_string **0 次命中**；同一份代码隔离重跑该文件\n 14/14 通过。第三轮整轮亦一次过。\n 顺带记一个行为：**失败的 runtime 会删掉 8 份运行态报告**（跑到一半中止、未重新生成）。\n\n二、第二轮测试全过（733 / 204-204 / 0 失败）但整轮记 failed，红在末尾的文档复核\n governance-kernel-boundary-number-consistency。根因是本会话的一次操作失误：\n `git restore reports/` 用了目录级范围，把已重新生成的 kernel-boundaries.latest.json\n 退回 HEAD 版（143/143），而 CLAUDE.md 已是 144/144。重跑静态后边界报告回到 144/144，\n 又撞上 governance-number-evidence-shape（要求一份 passed 的 runtime），于是必须再跑\n 第三轮才解环——这正是 CLAUDE.md 记载过的那个环。\n\n 同一次失误还抹掉了三份 reports/ui-*.latest.json 的未提交改动（不属本会话）。\n 已用 git fsck --lost-found 从游离 blob 全数找回并逐字核对：它们是 2026-09-15 的 UI 验收，\n 绑 c433d57 且 dirty=false。本提交仍未包含它们。\n 教训具体化：reports/ 下同时存在「本会话产出的」与「别人的」两类文件，任何范围操作都会\n 同时命中两类，**还原必须逐文件点名**。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T07:31:09-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/3deb4ea37b83c2e2977c9c2b8e8166c101002860...91b5257007ab9d588dcada5c5ca8d0c41a024bb9","Len":2}...
|
1789741873
|
Edit
Delete
|
|
31146
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"4da2c656a {"Commits":[{"Sha1":"4da2c656ae691428be3f177563952cba66c37b88","Message":"chore(reports): 静态链首次 28/28 全通过 回绑 @ 801d916，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 801d916（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=801d916、worktreeDirty:false）。\n**pnpm check 退出码 0：28/28 个步骤通过**——自 check:kernel-admission 引入以来首次整链绿，\n也是本仓静态轴扩到 28 步后的首次。\n\n绿的成色写在实现提交里，此处只记边界：唯一没有机器回执的 CORE.crossProductRequired 走的是\nevidenceDeferred 五字段登记（期限 2026-12-18、触发条件＝第二个产品真实装载），它在报告里是\nobserved 一行，**不是绿，是登记在案的缺证**。到期不补即转红。\n\n运行态未受本批影响（只动门禁、注册表、夹具与文档，未动 apps/packages 运行代码），\nruntime 报告仍绑在上一批的 d1eb586，13 份运行态证据未重跑也未失效。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T07:42:54-07:00"},{"Sha1":"801d916f36af0ee32c77b2138ec9afcf14b34db7","Message":"feat(governance): K3/K4 裁决——八处准入声明逐条补上真回执，静态链首次 28/28\n\ncheck:kernel-admission 引入时诚实红 8 处（K3 一处 + K4 七处）。本批逐条裁决并清零，\n**没有一处是把判据改松**——三条是补实体，一条是承认无法证明。\n\n一、K3（跨产品证据只有命名空间导入）→ 补实体\n 下游夹具此前只有 10 个 import * as，按构造在契约模块全空时同样通过。改为携带 5 个\n **真实被产品消费**的符号（ProductManifestInput / Composition / RuntimeContractCatalog /\n DataContractImplementation / EventContractImplementation，实测自唯一装载的 juhai.hr）的\n 具名类型导入并用于类型位置——编译通过才第一次构成「下游能按名字用上这些契约」的证据。\n\n二、K4 的结构性问题：两条门禁要求互相冲突，拆字段解决\n check-kernel-boundaries 的 B2 明令 evidenceSources **不得指 reports/**（运行产物随时重跑、\n 可被删除——本会话实测过：失败的 runtime 会删掉 8 份报告），而 K4 要求必须有机器回执。\n 两条各自成立，是同一件事的两半。改为两个字段：\n evidenceSources 持久判据源（脚本 / 词典 / 锁）——B2 判它\n evidenceReceipts 该判据源产出的机器回执——K4 判它\n K4 同时加强：回执须真实存在、带机器结论（status 或 violations）、带 provenance.gitSha、\n 且自身不是红盘。另加两条配套判据：\n · 禁止把**本门禁自己产出的报告**当回执（结构性自指：它只要有发现就是红的）\n · 确实无法被证据支撑时走 evidenceDeferred 五字段登记，降级 observed、过期转红\n\n三、逐条落点\n industryIndependent → kernel-boundaries（逐文件扫 CORE 源码不得内嵌已登记 Product\n 命名空间，check-kernel-boundaries.mjs:181）+ naming（业务词典）\n dualBackendGoverned → dual-backend-parity\n stableContract → kernel-packages\n crossProductRequired → **无回执，登记为「证据待补」**：本仓只装载一个产品，跨产品消费面\n 实测仅 5 个符号 / 34 个模块为零，该证据客观上无从产生。期限\n 2026-12-18，触发条件＝第二个产品真实装载；到期转红。\n 硬指一份回执等于把自证换个地方做，不做。\n\n四、订正一处我自己的误判\n 先前称「parity 对 employment 零断言」——**查错了地方**：断言在 governance.registry.json\n 的 employment.parityAssertions 里，由 check-dual-backend-parity.mjs:507 通用执行，本就有\n 10 条（消费者标识分区、new FactInbox、FACT_READ_NOT_CONFIGURED fail-closed、\n autoCommit:false、未配 broker 返回 null）。\n 据此我一度把新断言**硬编码**进脚本，被 check:fork-readiness 的 F2 当场抓住\n （「门禁不得硬编码已登记业务标识」）——F2 抓的是我的代码，抓得对。已撤回硬编码，\n 把两条新不变式（事件载荷与行映射必须走契约单源）按注册表形式补入，10 → 14 条。\n\nkernel.boundaries.json 新增 evidenceNotes：逐份回执记录**它到底判了什么**，含上述订正与\n「dual-backend-behavior 的 63 个矩阵用例不含 llm/employment，故两个 pack 不以它为据」这类边界。\n指针只说明有机器判过，不代表覆盖该词全部含义。\n\n自检 10 → 17 条（新增回执质量、自指、证据待补三组，含 1 条基线正例、2 条防过度判红）。\n整轮 pnpm check：**28/28 步骤全部通过**，退出码 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-18T07:41:16-07:00"}],"HeadCommit":{"Sha1":"4da2c656ae691428be3f177563952cba66c37b88","Message":"chore(reports): 静态链首次 28/28 全通过 回绑 @ 801d916，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 801d916（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=801d916、worktreeDirty:false）。\n**pnpm check 退出码 0：28/28 个步骤通过**——自 check:kernel-admission 引入以来首次整链绿，\n也是本仓静态轴扩到 28 步后的首次。\n\n绿的成色写在实现提交里，此处只记边界：唯一没有机器回执的 CORE.crossProductRequired 走的是\nevidenceDeferred 五字段登记（期限 2026-12-18、触发条件＝第二个产品真实装载），它在报告里是\nobserved 一行，**不是绿，是登记在案的缺证**。到期不补即转红。\n\n运行态未受本批影响（只动门禁、注册表、夹具与文档，未动 apps/packages 运行代码），\nruntime 报告仍绑在上一批的 d1eb586，13 份运行态证据未重跑也未失效。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T07:42:54-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/91b5257007ab9d588dcada5c5ca8d0c41a024bb9...4da2c656ae691428be3f177563952cba66c37b88","Len":2}...
|
1789742577
|
Edit
Delete
|
|
31147
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"0c6a1918a {"Commits":[{"Sha1":"0c6a1918aa223b1779ce4653ba2c4e4609aea336","Message":"chore(reports): dev 常驻运行时切换后的部署门禁回绑 @ 06c3d4c\n\nCo-Authored-By: Claude Opus 5 \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:34:13-07:00"},{"Sha1":"06c3d4cb7fd09b2b44e621a56d7b14653bb8b445","Message":"chore(reports): runtime 镜像重建与冒烟证据回绑 @ 05e3826\n\nCo-Authored-By: Claude Opus 5 \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:33:44-07:00"}],"HeadCommit":{"Sha1":"0c6a1918aa223b1779ce4653ba2c4e4609aea336","Message":"chore(reports): dev 常驻运行时切换后的部署门禁回绑 @ 06c3d4c\n\nCo-Authored-By: Claude Opus 5 \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:34:13-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/05e3826e9e9e4dbbdd753252c2134b8494b08f2b...0c6a1918aa223b1779ce4653ba2c4e4609aea336","Len":2}...
|
1789742609
|
Edit
Delete
|
|
31148
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"c190a6ab5 {"Commits":[{"Sha1":"c190a6ab5d2c50e4c90f027bbcca72f1f3050005","Message":"fix(contracts): 通知与 Webhook 规则补入参体检——一处倒向放行、两处崩溃面与目标地址的同义写法\n\n迁入版把策略快照一侧校验到底（normalizeSnapshot 逐字段抛），请求一侧、目标地址一侧与夹具评估器三处漏风。\n补强前对 dist 逐条实测：\n\n- 放行面（唯一一处方向倒向放行）：三个状态位按真值判，`replayAuthorized: \"false\"` 在 `!value` 下为 false，\n 未授权重放被判成已授权 → DELIVER；planner 原样透传这三位，计划面同样通。现在只认布尔字面量。\n- 崩溃面：classifyNotificationEffect(undefined) / classifyProviderOutcome(undefined) 抛 TypeError 而不是拒绝，\n 夹具的 effect / provider 两条规则都能直接触发——门禁那时拿到的是异常不是判定，落到消费侧是 500 不是拒绝。\n- 目标地址（C08.05 / 蓝图「私网地址失败关闭」）：isPrivateLiteral 只认四段十进制，2130706433 / 0x7f000001 /\n 0177.0.0.1 / 127.1 全判成公网；0.0.0.0/8、CGNAT 100.64/10、组播与保留段、.internal、末尾点均未覆盖。\n 现在数字形主机一律按 IP 字面量处理，只放行严格四段十进制的公网地址；allowedHosts 自己先过这道地板\n （WEBHOOK_ALLOWED_HOST_NOT_PUBLIC），小写归一后再查一次重名。\n- 本次唯一放宽的一处，据实登记：迁入版按字符串前缀 fc / fd / fe80 判私网 IPv6，fc-portal.example.com 这类\n 正常域名被误判成私网。改判后它可用，但仍须先进运营批准的 allowlist 且为 HTTPS，不构成新的可达面。\n- 死代码：WEBHOOK_TENANT_WILDCARD_FORBIDDEN 写在字符集校验之后，`*` 永远先报 WEBHOOK_ROUTE_TENANTS_INVALID，\n 蓝图写明的「tenant allowlist 禁止 *」从未以自己的名义拦下过。\n- 退避：decideProviderOutcome 原取 min(maximumBackoff, retryAfter)，供应商回一个 Retry-After: 0 即可把批准过的\n 退避清零。现在外部回执只能把退避拉长到策略上界，上界语义与既有用例逐字不变。\n- 夹具评估器把两种非放行当成放行：SKIP_DUPLICATE 与 DLQ 都没有 reasons 字段，被 `\"reasons\" in r` 判成空数组\n = ACCEPT，与该文件自己第一句「只有 DELIVER / DELIVERED 算放行」正相反。另补 refresh 规则。\n- effect_id 改为强校验：五段必须是规范标识符（因此不含 :），否则 a:b+c 与 a+b:c 会拼出同一个 id；\n 请求一侧的标识符不再先 trim 再判定。\n\n合法快照与合法请求的判定结果逐字不变：迁入的 14 例断言一条未改。单测 14 → 24 例；夹具 8 → 17 例，并修好\n名不副实的 N06-plan-without-policy-denies-all——它此前只喂了两个字段的请求，压根走不到「无策略即拒」那一步。\n\n核验（工作树 dirty，报告未回绑，只绑本地）：contracts build / typecheck 绿、本域单测 24/24、\ncontracts/test/*.test.mjs 330/330、check:fixtures 17 套件 236 例 0 失败 0 不可用（本域 17/17；用临时报告名跑，\n跑完删除，reports/ 未动）。负向实测两次：① 把 HEAD 版三支规则单独编译后喂新夹具，8 例新增负例全部不通过\n（N07/N10/N11 直接放行、N08/N09 抛 TypeError、N12 换原因、N13/N14 旧评估器不识别 refresh）；\n② 篡改 N10 的声明原因 → 门禁 exit 1 并点名该例，翻 expect → 被 id/expect 一致性先挡下，还原后 exit 0。\n\n未做：缺失模块完善清单 C12 的模板审批 / 多渠道 Provider / 签名防重放 / 渠道切换本仓仍一件没有（该行类型是\n「裁决」，前置是运行宿主 Q01），本轮仍是契约包形态，不代表通知服务上线；Catalog 登记未动（仍 module_e2，\ncode_truth 指工单仓 packages/notification-delivery）；三个消费仓的 packages/notification-delivery 未同步；\n入站回调验签（C12.05）与 UNKNOWN 回执（C12.04）属判定面扩张，只登记未实现。\n\nCo-Authored-By: Claude Opus 5 \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:43:48-07:00"},{"Sha1":"9d13fb058d2a0356797f26d1d17a4b2149b6ab97","Message":"docs(runbook): 订正 CORS 一句——服务端代理不解 CORS，工作台吃的是 :3101 那个进程的白名单\n\n原文「控制面 Web 与 identity dev 走服务端代理，不吃这条」把两件事混了。代理只是把上游的\nAccess-Control-Allow-Origin 原样回传，吃不吃只看浏览器所在页面的 origin 与被请求 origin\n是否同源：控制面 Web 的页面与它的 /api 代理同源，不吃；工作台 dev（:3010）经 :3098 代理\n打到 :3101，跨源，放行的必须是 :3101 那个进程的 CORS_ORIGIN，而不是容器的\nPLATFORM_CORS_ORIGIN——后者 2026-09-18 补过、前者一直缺，于是总览两块读面全被浏览器拦成\n「依赖故障」，而服务端日志里是一次正常 200。今天按这句话排查，方向被带偏过一次。\n\n同轮登记两处仓外事实：identity dev 的 env 文件位置（企业控制面/.secrets/\nenterprise-platform-identity-dev.env，已含 CORS_ORIGIN=http://localhost:3010），\n以及工作台 API 基地址的单一出处（apps/workbench/.env.local，launch.json 不再覆盖）。\n\n作用域 = 文档订正，不含代码与门禁证据。本机 dev 实测：预检 204 / 三个读面 200 /\nidentity 探针 database:up redis:up，证据只绑本地运行态。\n\nCo-Authored-By: Claude Opus 5 \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:42:44-07:00"},{"Sha1":"13c7eb7271af67df9d0b4e5223bda3eaa4ab7b10","Message":"fix(contracts): 跨域流程规则补入参体检，并补上 FLOW-01 与 effect 幂等两条自己没做到的红线\n\n迁入版的判定在「入参可信」时是对的，但本能力的真实入口是 JSON：夹具评估器、approved 快照、\n未来的 Owner Adapter 载荷都从反序列化来，TS 类型只在编译期成立。四类问题均有 dist 实测，非读代码推断。\n\n1. 崩溃面八处抛 TypeError 而不是拒绝。assessWorkflowDefinition(undefined) →\n Cannot read properties of undefined (reading 'domains')；{}、domains 非数组、steps 非数组、\n 步骤缺 dependsOn、effectIdempotencyKey 是数字同理；LocalWorkflowPlanner.plan({}) →\n Cannot read properties of undefined (reading 'trim')。夹具 definition 与 plan 两条规则都能直接触发——\n 门禁那时拿到的是崩溃不是判定，落到消费侧是 500 不是拒绝。现在两侧都先按 unknown 体检：\n 定义非对象 → WORKFLOW_DEFINITION_INVALID，请求非对象或归属三件套非空串 → WORKFLOW_ATTRIBUTION_REQUIRED。\n\n2. 放行面三处脏值倒向合格。timeoutSeconds: \"abc\" 因 \"abc\" \u003c= 0 为 false 而合格；\n irreversibleEffect: 0 被当成可逆，整条不可逆效果的幂等键要求随之失效；steps: [] 的「流程」也合格，\n approved 快照喂进来就是一份零命令的 PLAN。现在 timeout 必须是正整数、irreversibleEffect 必须是布尔、\n 零步骤 → WORKFLOW_STEPS_REQUIRED。\n\n3. 判定面在两处确有扩张，都是本规则自己没做到自己的红线。FLOW-01 Eligibility 是开发计划写死的\n 第一道闸（「拒绝把域内定时任务和单域状态机迁入平台」），但迁入版只数 domains 声明了几个域，\n 不数步骤实际落在几个域——把单域状态机的 domains 写成两个即可整条绕过，实测\n {domains:[\"hr\",\"identity\"], steps:[两步都 ownerDomain:\"hr\"]} 判 ELIGIBLE。现在 Owner 面体检通过后\n 再数步骤真实跨度，沿用 NOT_CROSS_DOMAIN 不新增原因码。另一条红线写「不可逆外部效果使用独立\n effect idempotency，平台重放不得重复付款、通知」，但两个不可逆步骤共用同一把键时无人拦，\n 一次效果的幂等记录会压掉另一次 → 新增 EFFECT_IDEMPOTENCY_NOT_UNIQUE。\n\n4. 第三条扩张在 governed 步骤一侧：不可逆步骤既无同 Owner 补偿又不开人工接管时此前照常编进波次，\n 而退出门要求「每步唯一 Owner、timeout 和恢复责任明确」，这种步骤失败后没有任何恢复责任人 →\n STEP_RECOVERY_RESPONSIBILITY_REQUIRED。补偿仍是可选项：人工接管或补偿有其一即可，\n 可逆步骤不受约束，两条都有正向用例钉住。\n\n另修一处诊断损失：normalizeSnapshot 把定义体检的多条原因只抛第一条，改为逐条抛出。\n合法定义与合法请求的判定结果逐字不变，迁入的 11 例单测断言一条未改。\n\n覆盖：定向测试 11 → 22 例，补强用例另起两节；夹具 7 → 16 例（正 2 / 反 14），并给原 N01—N05\n补 reasons 声明——此前只断言「拒绝」，换一条原因拒绝也算过。\n\n未做（越界，已在 SOURCE.md 与蓝图增量节写明）：流程实例、持久调度、补偿执行器、Timer、\nOwner Adapter 与 M5 分工一件未建，按缺失模块完善清单 C15 卡在运行宿主 Q01 与 G4，本轮仍是契约包形态，\n不代表编排平台上线；Catalog 登记一律未动（仍 candidate_e0 / E0）；步骤 Permission 的资源归属仍不校验\n（ownerDomain \"hr\" 的步骤声明 identity 资源照样编进计划，而资源名与域的绑定在本包里没有可判定的真源，\n纯规则读不到 catalogs/permissions.json）；commandIdempotencyKey 含定义版本号，同一实例升版重放会换键，\n不可逆效果由不含版本的 effectIdempotencyKey 兜底，改它属运行宿主裁决时一并定的事。\n\n证据：在仅含本提交改动的导出树上 tsc 与 typecheck 绿、定向 22/22、contract-cross-domain-workflow\n夹具 16/16；负向实测把 N07-declared-domains-without-real-owner-span 的声明原因改成 WORKFLOW_CYCLE，\n门禁 exit 1 并点名该例（reasons=[\"NOT_CROSS_DOMAIN\"]），还原后转绿。导出树里 governance-linter.test.mjs\n因 /tmp 下工作区根不可解析而失败，pristine HEAD 导出树同样失败，与本次改动无关；真实工作树\ncontracts:check:local 330/330、check:fixtures 17 套件 227 例 0 失败。工作树另有并行会话的 WIP，\n故本次不回绑任何 reports/。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T07:42:22-07:00"},{"Sha1":"5720165763b35035e6778fe9a802493a16eb5aca","Message":"fix(contracts): 会话准入规则补入参体检——四条 fail-open 与一处「兜底自己会抛」收口\n\n九项契约包自 2026-09-14 迁入以来一直是「原样迁入、未改语义」，本条是第一次动判定。\n起因是对 collaboration-messaging 逐条实测而非读代码：迁入版把策略快照一侧校验到底\n（normalizeSnapshot 逐字段抛并被工厂捕获），请求一侧整个信任声明类型，而声明类型\n约束不了 HTTP 与夹具送进来的 JSON。五条缺陷均可复现，且都打在该能力自己 README 的\n「最小验收」与蓝图的「失败闭合」上：\n\n1. 抛而不拒。三个导出在畸形 JSON 下抛 TypeError 而不是返回 REJECT。兜底的 bundled\n deny-all 也不例外——createRuntimeConversationAdmissionPlanner().plan({}) 抛异常，\n 即「什么都不放行」的最后一道在畸形入参下等于没有。\n\n2. 未知 senderType 放行，且 \"AI_AGENT\"（只改大小写）同样放行。AI_ATTRIBUTION_REQUIRED\n 只在严格等于 ai_agent 时触发，于是「AI 不得冒充人员」有一条改大小写就能走的绕过路径。\n 不做大小写归一化——归一化等于替冒充者补齐形状。\n\n3. 游标不绑定会话。ConversationAppendState 有 expectedTenantId 却没有会话标识，拿 conv-1\n 的游标判 conv-9 的消息得到 APPEND，planner 直接 ADMIT 并按 conv-9 生成幂等键；重复与\n 序列 Gap 判定全程可能在读另一个会话的账本。\n\n4. processedMessageIds 传成字符串时 includes 退化为子串判断，幂等两个方向都错：\n \"msg-1\" 不含 \"msg-2\" 则漏判重复，\"msg-1,msg-2\" 含则误判重复。\n\n5. memberActive 传成真值字符串即算在籍（原判据 !state.memberActive，\"false\" 是真值）。\n\n附带：hasAttachment 非布尔即拒。此前缺字段时 attachmentAuthorizationRequired 是\nundefined，下游 if (plan.attachmentAuthorizationRequired) 就跳过公共文件平台重新授权，\n等于「缺字段 = 不需要授权」。\n\n改法只收紧失败一侧，合法输入的判定结果逐字不变：迁入的 16 例断言一条未改，只给游标补了\n新的必填字段。expectedConversationId 做成必填而不是「在场才查」——可选只能拦住已经想起来\n要绑定的调用方，拦不住忘了的那个，而忘了的那个正是第 3 条的全部成因；破坏面可枚举且全在\n仓内（本包测试与夹具各一处），Catalog 上该项 candidate_e0 / code_truth 指向本目录 /\n上层真实消费者为零。ConversationAppendDecision 新增 CONVERSATION_BINDING_REQUIRED /\nCONVERSATION_MISMATCH / STATE_INVALID 三档（原先「序列非整数」复用 REJECT，与「消息体检\n未过」同码，改后 REJECT 专指后者）；planner 新增 REQUEST_SHAPE_INVALID /\nATTACHMENT_FLAG_INVALID 两条原因与两条映射。新增原因一律排在既有原因之后判定，既有原因码\n的优先级未动。\n\n顺带修一条证据登记缺口：reports/fixtures.latest.json 的作用域只写到 runtime/modules，\n九个契约包套件的两类输入整个在作用域外——夹具用例在 contracts/test/fixtures/，判定用的\nevaluateFixturePayload 在 contracts/src/domain/。作用域写于只有运行时模块有夹具的时候，\n2026-09-14 迁入时没随迁，后果是改夹具或改规则都不会让这份报告过期，而它正是这九项在\nCatalog 上登记的证据之一。实据不用构造：本轮改动与并行会话的 public-file 改动同时在树上，\ncheck:evidence 仍不点它。补两条后该报告立刻转 EVIDENCE_WORKTREE_CHANGED，check:evidence\n由 4 条过期变 6 条——多出来的不是新问题，是此前看不见的问题。\n\n核验：contracts test 285 → 292（我的增量 +7，既有断言未改；树上现读 330，多出的是并行会话\n在途改动）；check:fixtures 本套件 8 → 14 例（正 2 / 反 12）0 失败；负向实做：把 N11 的声明\n原因改成不会产生的串，门禁 exit 1 并点名该例，还原后 exit 0；governance 测试 340/340；\n工作区一致性 L4 / L10 / L13 均 0。\n\n未做（越界）：会话 / 成员 / 消息账本、长连接服务、Fact、独立运行服务一件未建——按缺失模块\n完善清单 C16 卡在「裁决 · 实现」，前置是 Owner ADR、三消费者与 G4。Catalog 的\nimplementation_state / evidence_level / code_truth / evidence 一律未动（改登记须 CHG）。\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-18T07:41:37-07:00"},{"Sha1":"793d0a106f07c2b9974991a2a5953fdebc5be1b3","Message":"fix(contracts): 公共文件规则补入参体检——plan 遇畸形请求此前抛 TypeError，非布尔授权位此前被判成放行\n\n迁入版本在「入参可信」的前提下是对的，但本能力的实际入口是 JSON：夹具评估器、策略快照、\n三个消费仓的载荷都从反序列化来，TS 类型只在编译期成立。判定面没有扩张，改的只是拿到脏值时往哪边倒。\n\n三个缺口（均有实测，非读代码推断）：\n\n1. `LocalPublicFileAccessPlanner.plan()` 遇畸形请求抛 TypeError 而不是拒绝。补强前 dist 实测\n `plan({})` → `TypeError: Cannot read properties of undefined (reading 'trim')`，`plan(null)`\n 与缺 `file` 的请求同理。蓝图写的「失败闭合」只覆盖快照畸形（bundled deny-all），没覆盖请求畸形——\n 抛异常落到消费侧是 500，不是拒绝。现按同包 `webhook-delivery-planner.plan()` 的既有先例先体检请求：\n 非对象 → FILE_ACCESS_REQUEST_INVALID，归属三件套缺失或非字符串 → FILE_ACCESS_ATTRIBUTION_REQUIRED，\n `file` 不是对象 → FILE_REFERENCE_INVALID。\n\n2. 非布尔的授权位被判成放行。`if (!context.permissionGranted)` 对 \"false\" / 1 / {} 全部放行；\n `authorizationVersion \u003c requiredAuthorizationVersion` 与 `expiresAt \u003c= now` 在另一端缺失时都是 false，\n 即「比不出来」被当成「比过了」。现在授权位只认字面 true，两个比较的两端都必须是整数。\n\n3. `PublicFileRef.version` 声明为 \"v1\" 却从来没被校验，换版本的引用会被 v1 判定顺带放行。\n 加 FILE_REF_VERSION_UNSUPPORTED。\n\n覆盖：夹具评估器不再先把缺字段补成 \"\" / NaN（那层补齐等于夹具永远喂不进脏值，而脏值正是这次要固定的\n那一侧），payload 原样交给规则；新增 refresh 规则——planner 第三个公开方法此前在门禁上零覆盖。\n夹具 13 → 29 例（正 4 / 反 25），补齐六条此前只有单测、门禁上没有的策略白名单原因，以及\nFILE_ACCESS_ATTRIBUTION_REQUIRED / FILE_TENANT_NOT_ALLOWED 两条此前任何地方都没覆盖的原因；\n定向测试 15 → 22 例，迁入的 15 例一条未改。\n\n未做（需 CHG，已在 index.ts 抬头与 SOURCE.md 写明，不再沿用旧措辞）：\nschemas/public-file-ref.v1.schema.json（version=1 数字 + ownerEntity*/storageRef）与本目录的\nPublicFileRef（version=\"v1\" 字符串 + sha256/size/mimeType/scanStatus）不是同一个对象——一份通得过\nSchema 的引用喂不进 assessPublicFileRef，反之亦然。合并属契约变更，不在本次范围。Catalog 登记未动\n（public-file 仍 module_e2、code_truth 指向工单仓 packages/attachments），三个消费仓的副本未同步本次补强。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 22/22、contract-public-file 夹具 29/29；\n工作树另有并行会话的 WIP，故本次不回绑任何 reports/。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T07:38:28-07:00"}],"HeadCommit":{"Sha1":"c190a6ab5d2c50e4c90f027bbcca72f1f3050005","Message":"fix(contracts): 通知与 Webhook 规则补入参体检——一处倒向放行、两处崩溃面与目标地址的同义写法\n\n迁入版把策略快照一侧校验到底（normalizeSnapshot 逐字段抛），请求一侧、目标地址一侧与夹具评估器三处漏风。\n补强前对 dist 逐条实测：\n\n- 放行面（唯一一处方向倒向放行）：三个状态位按真值判，`replayAuthorized: \"false\"` 在 `!value` 下为 false，\n 未授权重放被判成已授权 → DELIVER；planner 原样透传这三位，计划面同样通。现在只认布尔字面量。\n- 崩溃面：classifyNotificationEffect(undefined) / classifyProviderOutcome(undefined) 抛 TypeError 而不是拒绝，\n 夹具的 effect / provider 两条规则都能直接触发——门禁那时拿到的是异常不是判定，落到消费侧是 500 不是拒绝。\n- 目标地址（C08.05 / 蓝图「私网地址失败关闭」）：isPrivateLiteral 只认四段十进制，2130706433 / 0x7f000001 /\n 0177.0.0.1 / 127.1 全判成公网；0.0.0.0/8、CGNAT 100.64/10、组播与保留段、.internal、末尾点均未覆盖。\n 现在数字形主机一律按 IP 字面量处理，只放行严格四段十进制的公网地址；allowedHosts 自己先过这道地板\n （WEBHOOK_ALLOWED_HOST_NOT_PUBLIC），小写归一后再查一次重名。\n- 本次唯一放宽的一处，据实登记：迁入版按字符串前缀 fc / fd / fe80 判私网 IPv6，fc-portal.example.com 这类\n 正常域名被误判成私网。改判后它可用，但仍须先进运营批准的 allowlist 且为 HTTPS，不构成新的可达面。\n- 死代码：WEBHOOK_TENANT_WILDCARD_FORBIDDEN 写在字符集校验之后，`*` 永远先报 WEBHOOK_ROUTE_TENANTS_INVALID，\n 蓝图写明的「tenant allowlist 禁止 *」从未以自己的名义拦下过。\n- 退避：decideProviderOutcome 原取 min(maximumBackoff, retryAfter)，供应商回一个 Retry-After: 0 即可把批准过的\n 退避清零。现在外部回执只能把退避拉长到策略上界，上界语义与既有用例逐字不变。\n- 夹具评估器把两种非放行当成放行：SKIP_DUPLICATE 与 DLQ 都没有 reasons 字段，被 `\"reasons\" in r` 判成空数组\n = ACCEPT，与该文件自己第一句「只有 DELIVER / DELIVERED 算放行」正相反。另补 refresh 规则。\n- effect_id 改为强校验：五段必须是规范标识符（因此不含 :），否则 a:b+c 与 a+b:c 会拼出同一个 id；\n 请求一侧的标识符不再先 trim 再判定。\n\n合法快照与合法请求的判定结果逐字不变：迁入的 14 例断言一条未改。单测 14 → 24 例；夹具 8 → 17 例，并修好\n名不副实的 N06-plan-without-policy-denies-all——它此前只喂了两个字段的请求，压根走不到「无策略即拒」那一步。\n\n核验（工作树 dirty，报告未回绑，只绑本地）：contracts build / typecheck 绿、本域单测 24/24、\ncontracts/test/*.test.mjs 330/330、check:fixtures 17 套件 236 例 0 失败 0 不可用（本域 17/17；用临时报告名跑，\n跑完删除，reports/ 未动）。负向实测两次：① 把 HEAD 版三支规则单独编译后喂新夹具，8 例新增负例全部不通过\n（N07/N10/N11 直接放行、N08/N09 抛 TypeError、N12 换原因、N13/N14 旧评估器不识别 refresh）；\n② 篡改 N10 的声明原因 → 门禁 exit 1 并点名该例，翻 expect → 被 id/expect 一致性先挡下，还原后 exit 0。\n\n未做：缺失模块完善清单 C12 的模板审批 / 多渠道 Provider / 签名防重放 / 渠道切换本仓仍一件没有（该行类型是\n「裁决」，前置是运行宿主 Q01），本轮仍是契约包形态，不代表通知服务上线；Catalog 登记未动（仍 module_e2，\ncode_truth 指工单仓 packages/notification-delivery）；三个消费仓的 packages/notification-delivery 未同步；\n入站回调验签（C12.05）与 UNKNOWN 回执（C12.04）属判定面扩张，只登记未实现。\n\nCo-Authored-By: Claude Opus 5 \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:43:48-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/0c6a1918aa223b1779ce4653ba2c4e4609aea336...c190a6ab5d2c50e4c90f027bbcca72f1f3050005","Len":5}...
|
1789742672
|
Edit
Delete
|
|
31149
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"e8fda74e2 {"Commits":[{"Sha1":"e8fda74e279a5884440d5efaac2265e513c814b6","Message":"chore(reports): 入口门禁与工作台两份快照回绑 @ a9abcbe\n\n在 a9abcbe 的干净 detached 检出里重跑（governance/rebind-reports.mjs --gates caddy,workbench-snapshots，\n带 CHECK_CADDY_DOCKER=1），三份均 provenance.gitSha=a9abcbe / worktreeDirty=false。\n\n- reports/caddy.latest.json：0 违规。12 个 HTTP 契约前缀 × 2 profile 全覆盖；新增的 routing 段逐条记下\n 模拟出来的块链，13 条登记前缀（11 个去重契约前缀 + 2 个长连接前缀）全部到达 {$PLATFORM_API_UPSTREAM}；\n workbenchGuard.reached=true / conditionalBefore=0；语法校验 dev / staging 均 passed，via docker，\n 镜像 caddy@sha256:5f5c8640…d58648（compose 锁定的那一个，不再是浮动 tag）。\n- reports/workbench-catalog-snapshot.latest.json：只有 provenance 变。caddy-routes.json 进了它的作用域\n （新增 validate / mount 段），被 check:evidence 判过期，但快照只吃 routes.contracts，内容逐字未变——\n 重建后与旧版按字段比对一致，已实测。\n- reports/workbench-ops-snapshot.latest.json：与 catalog 同一脚本产出，必须一起带回（分开会绑不同提交）。\n 它有一处内容变化不由本轮改动引起：image 段从 d8f09205 / sha256:fe418667… 更新到 05e3826e /\n sha256:c0869934…，来源是 06c3d4c 已提交的 reports/image-digest.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-18T07:46:25-07:00"},{"Sha1":"a9abcbe392de8a903512ab4b25529a6e277113ee","Message":"feat(gateway): 入口门禁改为解析块树后模拟路由——「文件里配了」不等于「这条路径上生效」\n\nC08 应用群网关是采纳形态，判定在 Caddyfile 这份配置里，由 check-caddy 守。它此前是逐行正则：\n某条指令在文件里出现过就算配了。本轮不动入口运行行为（两份 Caddyfile 一个字没改），只把它\n自己在注释里写明判不了的那一类失效变成静态判定。\n\n逐行正则判不出来的三件事：\n- 有个更靠前的 handle 块把 /api/platform/* 截走——入口鉴权配得好好的，请求根本走不到它。\n caddy-routes.json 的 workbench.note 原文是「这种绕过只能靠运行态探针发现」。\n- 请求体上限 / 上游超时 / request-id 注入写在别的块里，门禁全绿，平台路由上一层保护都没有。\n BODY_LIMIT_MISSING 这类规则问的是「文件里有没有」，不是「这条路由上有没有」。\n- 契约前缀有匹配器、但请求先被别人服务了：ROUTE_UNCOVERED 绿，流量到不了 API。\n\n新增块树解析（tokenizeLine / parseCaddyfile：`{` 只有作为行末独立 token 才开块，占位符\n{$VAR} 与 {http.request.uuid} 是 token 内部的花括号）与路由模拟（按 Caddy 的 handle 互斥语义\n与指令序，逐层并入命名匹配器），据此新增：\n- ROUTE_SHADOWED 前缀有匹配器但被更靠前的 handler 截走，到不了 {$PLATFORM_API_UPSTREAM}\n- WORKBENCH_AUTH_BYPASS 被守护前缀在到达 forward_auth 所在块之前就被别的 handler 服务了；\n 更靠前的 handler 若条件不是纯路径（header / method / file），按「可能截走」同样判红\n- INGRESS_GUARD_OUT_OF_SCOPE 入口约定在文件里有，却不在服务该前缀的那条块链上\n- STREAMING_ROUTE_UNCOVERED 登记的长连接前缀没被路由到上游（与「禁 read_timeout」凑成一对）\n- CADDYFILE_UNPARSED 花括号不配平 / 没有站点块——判不了就报，不静默通过\n\n同轮补三条登记面的：\n- PROFILE_MOUNT_UNBOUND profile 的 Caddyfile 没被登记的 compose 挂进入口容器。staging 那份此前\n 只被校验、没人核对它有没有被 overlay 加载；校验一份没人加载的配置等于没校验。\n- CADDY_IMAGE_UNPINNED compose 的入口镜像不是 digest 锁定。docker 校验原先写死浮动 tag\n caddy:2-alpine，而跑的是锁定镜像——拿另一个版本的 Caddy 校验，过了也\n 不代表运行的那个认它。现在从 compose 取镜像，取不到即 skipped，不退回浮动 tag。\n- ROUTE_MAPPING_ORPHANED 登记表映射了 modules.json 里已不存在的契约（CONTRACT_UNMAPPED 的反向死登记）\n\nstripComments 按 Caddy 口径重写：引号内的 # 是字面量，# 只有在 token 开头才起注释——原先一刀切到\n第一个 #，会把 respond \"a#b\" 这类值截半，反过来让门禁看不见后面真实生效的指令。\nevidence-scopes 的 caddy 作用域补进 stack/compose.yaml 与 stack/overlays/staging.yaml：结论现在\n也取决于「挂没挂进容器」和「校验用的是不是那个镜像」，这两个输入一改结论就可能不再成立。\n\n核验（工作树 dirty，报告未回绑，只绑本地）：\n- CHECK_CADDY_DOCKER=1 check:caddy exit 0：12 个 HTTP 契约前缀 × 2 profile 全覆盖；模拟路由 13 条\n 前缀（11 个去重契约前缀 + 2 个长连接前缀）全部到达上游且入口约定就在各自链上；\n workbenchGuard.reached=true；两份 Caddyfile 语法均 passed，镜像 caddy@sha256:5f5c8640…d58648\n （= compose 锁定、dev 常驻容器正在跑的那一个）。\n- check-caddy.test.mjs 19 → 37 例，每条新规则都有篡改夹具且夹具断言「确实改到了」。两例专门对照\n 旧规则：插入抢先的 handle 后 evaluateCaddyfile / evaluateWorkbench 仍全绿，新规则判红。\n- 与真实 Caddy 对照（同一 digest 镜像，两个一次性容器，上游指向死端口）：真实基线\n GET /api/platform/probe → 502（forward_auth 去校验，没放行）；插入抢先 handle 的那份 → 200\n 「bypassed」，门禁判红。同一份里 /api/v1/decisions 仍 502，截走范围与模拟一致。\n- 一处自测抓到的实现缺陷：scopeNodes 顶层那一跳没挡 handler 分支，\"别的块里配了也算数\"——\n 正是要判的那种失效；已修并由「请求体上限挪到别的块」一例钉住。另一例钉住命名匹配器声明在\n 里层块时必须判得动（撤掉修复即落在 reverse_proxy 而非 respond，实测过）。\n- 回归：governance 全套 340/340；工作区一致性门禁只余既有 L9 compose 重名 1 条，与本轮无关。\n\n未做：G-3 限流要 caddy-ratelimit 插件即自建镜像，会打破 digest 锁定的官方镜像，是 stack 决策；\nHTTP 方法白名单归属 2026-09-16 已裁为不阻塞退役、转 stack 待办；C08.04 East-West 身份、C08.05\nWebhook ingress 与 Egress SSRF、C08.06 外发 / WAF / HA 全无落点（Q03）。静态判定的边界据实登记：\n非路径条件只能判「可能」，route 只作近似，每个前缀只探一条代表路径（/t/\u003ctenant\u003e/login 这类\n「有意分流一部分」不在判定范围），入口鉴权仍挡不住文档导航——运行态探针仍是必要补充。\n\n报告回绑另起 chore(reports) 提交（仓纪律 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-18T07:45:36-07:00"}],"HeadCommit":{"Sha1":"e8fda74e279a5884440d5efaac2265e513c814b6","Message":"chore(reports): 入口门禁与工作台两份快照回绑 @ a9abcbe\n\n在 a9abcbe 的干净 detached 检出里重跑（governance/rebind-reports.mjs --gates caddy,workbench-snapshots，\n带 CHECK_CADDY_DOCKER=1），三份均 provenance.gitSha=a9abcbe / worktreeDirty=false。\n\n- reports/caddy.latest.json：0 违规。12 个 HTTP 契约前缀 × 2 profile 全覆盖；新增的 routing 段逐条记下\n 模拟出来的块链，13 条登记前缀（11 个去重契约前缀 + 2 个长连接前缀）全部到达 {$PLATFORM_API_UPSTREAM}；\n workbenchGuard.reached=true / conditionalBefore=0；语法校验 dev / staging 均 passed，via docker，\n 镜像 caddy@sha256:5f5c8640…d58648（compose 锁定的那一个，不再是浮动 tag）。\n- reports/workbench-catalog-snapshot.latest.json：只有 provenance 变。caddy-routes.json 进了它的作用域\n （新增 validate / mount 段），被 check:evidence 判过期，但快照只吃 routes.contracts，内容逐字未变——\n 重建后与旧版按字段比对一致，已实测。\n- reports/workbench-ops-snapshot.latest.json：与 catalog 同一脚本产出，必须一起带回（分开会绑不同提交）。\n 它有一处内容变化不由本轮改动引起：image 段从 d8f09205 / sha256:fe418667… 更新到 05e3826e /\n sha256:c0869934…，来源是 06c3d4c 已提交的 reports/image-digest.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-18T07:46:25-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/c190a6ab5d2c50e4c90f027bbcca72f1f3050005...e8fda74e279a5884440d5efaac2265e513c814b6","Len":2}...
|
1789742873
|
Edit
Delete
|
|
31152
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"b62945890 {"Commits":[{"Sha1":"b62945890987b341b65684046c6e4d8ae612c529","Message":"Merge pull request 'fix(contracts): 注册中心规则补失败关闭与摘要规范化——三个入口此前抛 TypeError，同一摘要的两种写法此前分叉成两个复核键' (#1) from feat/registry-rule-hardening into main\n\nReviewed-on: https://gitea.g-hi.com/luoanwu/enterprise-platform/pulls/1\n","AuthorEmail":"law@g-hi.com","AuthorName":"luoanwu","CommitterEmail":"law@g-hi.com","CommitterName":"luoanwu","Timestamp":"2026-09-18T22:48:44+08:00"},{"Sha1":"92a6b8e647c2c4d764c1fcdb8448bfc48a4dc4ed","Message":"fix(contracts): 注册中心规则补失败关闭与摘要规范化——三个入口此前抛 TypeError，同一摘要的两种写法此前分叉成两个复核键\n\n蓝图 docs/domain/registry-snapshot-blueprint.md 从迁入起就写着「失败关闭」与\n「review key 仅用于人工复核幂等」两条不变量，实测三处不成立。本次按蓝图自己的口径补齐，\n改动只在 contracts/src/domain/application-contract-registry/：不新增写入点、不新增宿主、\n不动 Catalog 与 Schema，每条输出仍固定 activationAllowed=false / registryWriteAllowed=false /\nhumanApprovalRequired=true。\n\n1. 失败关闭：assessRegistrySnapshot / assessRegistryTransition /\n reviewCandidateSnapshotUpgrade 对畸形输入抛 TypeError（快照缺字段、now 不是 Date、\n decisions 整个缺失都会抛），四个入口里只有 LocalManifestAdmissionPlanner.plan 是\n 失败关闭的。现四个入口一致返回 REJECT + 原因码。这不是洁癖：check-fixtures 把抛出当\n 配置错误处理，实测一次 TypeError 会让整套 15 例逐例判定塌成一条 configuration 失败。\n\n2. 十六进制引用规范化：digest / commit 的正则带 /i 收大小写两种写法，比较与入键却\n 大小写敏感——同一摘要写成大写会得到另一个 reviewIdempotencyKey，同版本大小写翻转被判成\n SAME_VERSION_DIGEST_CHANGED，大写回滚 pin 被判成 ROLLBACK_PIN_MUST_MATCH_CURRENT。\n 现一律规范化为小写后再比较、再入键，ACCEPT 回吐规范化后的值。\n\n3. 版本文法收敛：一个模块三套（快照流与清单准入用 \\d+\\.\\d+\\.\\d+，升级复核用严格 SemVer），\n 新增 registry-primitives.ts 作单一来源，含预发布序；DEC-009—012 此前在两份文件各写一份，\n 一并收敛。snapshot-upgrade-review.ts 因此净减约 60 行重复实现。\n\n两处语义变化（蓝图新增一节已如实登记）：\n- 收紧：1.02.0 这类前导零版本此前被放行，现在拒；assessRegistrySnapshot 另开始拒 latest\n 这类可变标签——此前它能过体检却必然过不了迁移规则。\n- 放宽：1.0.0-rc.1 这类预发布版本此前被快照流整条挡在外面，现在按 SemVer 序参与迁移。\n 平台自己发的就是 1.0.0-rc.N，升级复核那一侧本来就这么判。风险面有限：本模块所有出口\n 都不激活、不写 Registry，多进人工复核队列不等于多放行制品。\n\n证据（本分支隔离工作树，clean）：注册中心单测 44/44（原 34 + 加固 10）；\ncontracts check:local 302/302；check:fixtures 九个契约域套件 100 例 0 失败，\n其中本套件 15 例（正 4 / 反 11，原 8 例）。篡改必红实测两次：sameHexRef 退回大小写敏感\n→ 单测 1 红 + 夹具 P03 红；去掉快照入口守卫 → 整套塌成 0 例 1 配置失败。\n\n仍为仓内候选 sdk_e2，不代表正式 Registry、Snapshot 发布或跨仓 Required Check 已上线。\n清单登记的 C01.04 / C01.06 是「接线」型缺口且前置 Q01 运行宿主未裁，本次未动。\nreports/fixtures.latest.json 未回绑：它是 17 套件的聚合报告，只跑 9 个套件去覆盖会缩小结论面，\n应在整批（含并行会话的 public-file / IM / 跨域流程改动）落定后统一重跑回绑。\n\nCo-Authored-By: Claude Opus 5 \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:40:10-07:00"}],"HeadCommit":{"Sha1":"b62945890987b341b65684046c6e4d8ae612c529","Message":"Merge pull request 'fix(contracts): 注册中心规则补失败关闭与摘要规范化——三个入口此前抛 TypeError，同一摘要的两种写法此前分叉成两个复核键' (#1) from feat/registry-rule-hardening into main\n\nReviewed-on: https://gitea.g-hi.com/luoanwu/enterprise-platform/pulls/1\n","AuthorEmail":"law@g-hi.com","AuthorName":"luoanwu","CommitterEmail":"law@g-hi.com","CommitterName":"luoanwu","Timestamp":"2026-09-18T22:48:44+08:00"},"CompareURL":"luoanwu/enterprise-platform/compare/e8fda74e279a5884440d5efaac2265e513c814b6...b62945890987b341b65684046c6e4d8ae612c529","Len":2}...
|
1789742926
|
Edit
Delete
|
|
31153
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"0ed7ee700 {"Commits":[{"Sha1":"0ed7ee700a678dd6bea6879c5c575bd03cdb612c","Message":"chore(reports): check:fixtures 回绑 @ 7f82399\n\n合并后重跑并重新绑定。上一份绑的是 532e807，其注册中心一栏计的是本地 9ac9914 那套夹具（19 例），\n该实现已在 7f82399 的合并中整体放弃，报告随之失真，故在合并提交上重跑。\n\n在 .worktrees/merge-registry-remote 的干净检出（HEAD=7f82399）跑全 17 套件：\n296 例，失败 0，不可用 0，configurationError 0；provenance worktreeDirty=false、runner=local。\n与上一份的差异只在注册中心一栏：19 例（本地实现）→ 15 例（远端实现），总数 300 → 296。\n\ncontracts/dist 由该检出自己 tsc 构建；runtime 九个模块经 turbo 全量缓存命中\n（runtime/ 自上次绑定以来无任何提交，构建输入哈希一致）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:07:24-07:00"},{"Sha1":"7f82399ee801c5d5a740ef8a85366ea9f086650e","Message":"Merge remote-tracking branch 'origin/main' —— 注册中心取远端那套，本地 9ac9914 的实现整体放弃\n\n本域被两个并行会话各补强了一遍：Gitea 上经 PR #1 合入的 92a6b8e（抽出 registry-primitives.ts、\n重写 snapshot-upgrade-review.ts），与本地未推送的 9ac9914（守卫内联在 registry-snapshot.ts）。\n二者是对同一批规则的两套独立实现，合并时 5 个文件 11 处冲突，冲突内容是两套失败关闭实现之间的取舍。\n\n按 Owner 裁断取远端。解法不是逐块挑，而是把整个域按 origin/main 逐字取入——包括自动合并成功的\nfixture-evaluator.ts / index.ts / manifest-admission-planner.ts，避免留下两套写法拼起来的中间产物：\n\n git checkout origin/main -- contracts/src/domain/application-contract-registry \\\n contracts/test/application-contract-registry-domain.test.mjs \\\n contracts/test/fixtures/application-contract-registry.fixtures.json \\\n docs/domain/registry-snapshot-blueprint.md\n\n取入后逐文件与 origin/main 比对，九个文件全部无差异；目录内容与 origin/main 的 tree 一致\n（本地那套没有引入远端没有的文件，不存在残留）。\n\ncontracts/SOURCE.md 未被远端改动，故不在冲突里，但 9ac9914 在其中写的注册中心条目描述的是已被放弃的实现，\n留着即是假记录。该条目已替换为取舍记录：说明两套实现的来历、裁断结果与核验数字，并注明 PR #1 未在\nSOURCE.md 留条目、其缺陷清单以提交信息与蓝图增量节为准，不替它复述未经本会话核验的细节。\n\n核验（合并后，工作树 dirty，报告另行回绑）：\n- node --test contracts/test/*.test.mjs 361/361\n- 定向 contracts/test/application-contract-registry-domain.test.mjs 44/44\n- check:fixtures 17 套件 296 例，失败 0，不可用 0，configurationError 0\n （contract-application-contract-registry 15 例；本地那套的 19 例随实现一并放弃，故总数由 300 降至 296）\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:07:00-07:00"},{"Sha1":"33d84b86199f79c639208042c77816b597eeceb1","Message":"chore(reports): check:fixtures 回绑 @ 532e807\n\n在 .worktrees/evidence-fixtures 开 detached 干净检出（HEAD=532e807）跑全 17 套件：\n17 套件 300 例，失败 0，不可用 0，configurationError 0；provenance worktreeDirty=false、runner=local。\n\n为什么另开检出：主检出有并行会话未提交的 governance/check-module-imports.mjs，worktreeDirty 恒为 true，\n报告只能绑本地、不能回绑。依赖用符号链接接过来——runtime/.gitignore 的 node_modules 与 dist 不带斜杠，\n符号链接同样被忽略；根 .gitignore 的 node_modules/ 带斜杠不匹配符号链接，故 contracts/node_modules\n建成真目录、内部逐项链接，跑门禁前 git status --porcelain --untracked-files=all 实测为空。\ncontracts/dist 由该检出自己 tsc 构建；runtime 九个模块经 turbo 全量缓存命中（runtime/ 自上次绑定以来\n无任何提交，构建输入哈希一致）。\n\n案例数由上次绑定（765300b，189 例）升至 300 例，增量来自本轮九个契约包域的入参硬化：\nconfiguration-feature-flags 10→17 是本次提交带来的，其余由并行会话的同批提交带来\n（public-file 13→29、data-analytics 8→27、cost-capacity 9→32、application-contract-registry 8→19、\nenterprise-experience 6→17、notification-webhook 8→17、collaboration-messaging 8→14、\ncross-domain-workflow 7→16）。本次一并回绑，不逐仓拆分。\n\n其余 stale 报告不在本次范围，且都不由本次提交引起：release-manifest / sbom / image-smoke 的作用域变更是\nreports/image-digest.json 与 stack/compose.yaml；runtime/reports/naming 与 fork-readiness 是工作台四个文件；\nreports/module-imports.latest.json 处于 EVIDENCE_WORKTREE_CHANGED，须等并行会话提交\ngovernance/check-module-imports.mjs 后由其重跑回绑。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:01:21-07:00"},{"Sha1":"532e8072ab29d24da41fae7717985c2bcc771cd9","Message":"fix(contracts): 配置与功能开关规则补入参体检——三处倒向「开 / 采纳」、四处崩溃面与免检的兜底快照\n\n迁入版在入参可信的前提下是对的，但本能力的真实入口全是 JSON——夹具 payload、\ncreateRuntimeConfigurationClient(rawSnapshot) 收的快照文本、远端下发的开关规则都从反序列化来，\nTS 类型只在编译期成立。补强前对 dist 逐条实测，问题分六类：\n\n- 版本闸门形同虚设：rule.version \u003c context.minimumVersion 两端都不校验类型，缺任一端时 `\u003c` 恒为 false，\n 「比不出来」被当成「没过期」。version: undefined / version: \"3\" / minimumVersion: undefined\n 三种输入都直接 { enabled: true, reason: \"PERCENTAGE\" }——版本下限是配置回滚时唯一的保护。\n- 租户白名单退化成子串匹配：allowTenantIds 传成字符串时 .includes() 走的是 String.prototype.includes，\n \"xtenant-1x\" 让租户 tenant-1 命中 ALLOWLIST 并开启——不在白名单里的租户被开了灰度。\n- 未批准的配置快照被采纳：snapshotUsable 对 approved / schemaValid / containsPlaintextSecret 按真值判，\n approved: \"false\" 与 schemaValid: 1 都返回 USE_CANDIDATE；开关位 enabled: 1 同样被判成开启。\n 现在四个前提只认字面值，开关位只认布尔字面量。\n- 崩溃面：evaluateFeatureFlag(undefined, ctx) / (rule, undefined) / key: null / allowTenantIds: null 与\n selectConfigurationSnapshot(undefined, …) 全部抛 TypeError。夹具评估器两条规则各自只要少写一个键就能触发，\n 而 check:fixtures 对抛出物的处理是把整个套件记成 configurationError（0 例、报错文本当理由），\n 等于夹具门禁自己先倒了，不是多红一条。\n- 兜底快照免检：create(candidate, lastKnownGood) 对第二个参数只有声明类型，\n { version: 9, approved: \"yes\", schemaValid: 1, digest: \"zz\", values: \"nope\" } 可直接以 last_known_good 上岗——\n 它恰恰是候选不可用时的兜底，越是兜底越不能免检。现在 LKG 与候选走同一道 normalizeSnapshot，\n 参数类型也从 RuntimeConfigurationSnapshot 放宽成 unknown：这是入口，写成强类型挡不住任何东西。\n- 配置值穿透原型链：values 经 Object.fromEntries 建在 Object.prototype 上，get(\"constructor\") 返回一个函数，\n 消费侧一句 get(key) ?? fallback 就会拿函数当配置值。现在用 Object.create(null) 承载再冻结。\n 顺带收紧：version 必须是整数（原 typeof \"number\" 放过 NaN / 1.5），配置值里的数字必须有限。\n\n夹具评估器一并订正：Number(p[\"minimumVersion\"]) 会把夹具里写的 \"5\" 悄悄转成 5，\n夹具证明的是转换后的输入而不是自己写的那份。评估器应当是传声筒，现在原值直传。\n\n判定面与原因码面都没有扩张——FeatureFlagDecision 仍是那五个 reason、SnapshotSelection 仍是那三个 kind，\n没有新增任何原因码，整份改动只改「拿到脏值时往哪边倒」；迁入的 10 例单测断言一条未改。\nrefresh() 的 KEPT 分支放宽到 !== USE_CANDIDATE 并补上版本下限属防御性改动，它不修任何已知缺陷、\n对现有任何输入都不改变输出，已在 SOURCE.md 据实登记。\n\n覆盖：定向单测 10 → 20 例，夹具 10 → 17 例（正 4 / 反 13），新增目录内部件 value-guards.ts（不经 index.ts 导出）。\n负向实测三次：① 把 HEAD 版四个文件单独编到临时目录再喂新夹具，7 例全部不通过——\nN07 / N08 / N09 / N11 / N13 五例直接放行（reasons: [] = ACCEPT），N10 / N12 两例抛 TypeError；\n② 篡改 N11 的声明原因 → check-fixtures exit 1 并点名该例，把 id/expect 翻成 ACCEPT 仍 exit 1，还原后 exit 0；\n③ 源码侧还原 enabled 的布尔判定与 allowTenantIds 的数组判定 → 单测 20 例中 3 例转红，还原后 20/20。\n工作树 dirty（同期有并行会话在改其他契约包域），报告未回绑，本次用临时报告名跑完即删。\n\n未做：Catalog 登记一律未动（仍 module_e2、code_truth 指工单仓 packages/configuration-client），改登记需 CHG；\ndigest 只校验形状不校验内容、明文密钥只按顶层键名正则判、缺失模块完善清单 C13 的分桶 / 发布状态机 / kill switch\n均属判定面扩张或运行宿主（Q01），只登记未做。本轮仍是契约包形态，不代表配置中心上线。\n\nCo-Authored-By: Claude Opus 5 \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:57:18-07:00"},{"Sha1":"9ac9914ce25315472d3634c9d6d4d64e72dbe98f","Message":"fix(contracts): 注册中心规则补入参体检——393 行升级复核此前零门禁覆盖，四条就绪闸门被真值字符串顶开\n\n九个契约包里最后一个未补强的。三类问题，均先对 dist 实测再改。\n\n一、崩溃面。assessRegistrySnapshot(undefined) 与 assessRegistrySnapshot({}) 抛\nTypeError（后者停在 snapshot.appId.trim()）；assessRegistryTransition 任一侧非对象即抛；\nreviewCandidateSnapshotUpgrade 在 request / context 非对象、currentPin 或 impactEvidence\n缺失、context.now 非 Date 时抛；夹具评估器的 snapshot / transition 两条跟着抛。补\nSNAPSHOT_SHAPE_INVALID / UPGRADE_REQUEST_INVALID / UPGRADE_REVIEW_CONTEXT_INVALID\n三个稳定原因码。LocalManifestAdmissionPlanner.plan() 改前就已失败关闭，本轮一行未动。\n\n二、四条就绪闸门被真值字符串顶开。independentGitSourceReady / codeownersReady /\nrequiredCheckEvidenceReady / rollbackEvidenceReady 写作 !context.x，传 \"false\" 一律\n判为就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW。同一文件的 sourceWorktreeDirty !== false\n与 compatible / manualReviewRequired 本来就是严格写法，本次把这四条统一成它。\n\n三、两处身份判定过宽。\n\n blockedBy 传成字符串时 .length 是字符数——\"\" 等于「无阻塞」，带阻塞的快照会被放行。\n 现要求字符串数组，否则 BLOCKERS_SHAPE_INVALID。\n\n 摘要与提交 SHA 的正则带 i，大小写两收。摘要是制品的身份：两种写法都认等于同一制品\n 有两个身份，而后续每一处 !== 比较（SAME_VERSION_DIGEST_CHANGED、pin 与 target 的摘要\n 对齐、fromDigest / toDigest 对齐）都会把它们当成两件不同的东西。现只收小写；仓内\n Catalog 与夹具无任何大写摘要在用，实测无影响面。\n\n门禁覆盖：snapshot-upgrade-review.ts 整份 393 行此前在门禁上零覆盖（评估器只有\nsnapshot / transition / plan 三条规则），而它持有上述四条闸门与全部证据新鲜度判定。\n补 upgrade 规则，BLOCKED 不算放行。\n\n核验：定向 34 → 40 例；迁入的 34 例在硬化后的 dist 上 0 失败，即合法输入的判定结果\n逐字未变；夹具 8 → 19 例（正 3 / 反 16）0 失败；负向实做：把\nN13-truthy-string-must-not-mark-the-git-source-ready 的声明原因改成不会产生的串，\n门禁 exit 1 并点名该例，还原后 exit 0。仍不发布、不改消费者 pin、不写 Registry；\nCatalog 登记未动（改登记须 CHG）。\n\nCo-Authored-By: Claude Opus 5 \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:52:43-07:00"}],"HeadCommit":{"Sha1":"0ed7ee700a678dd6bea6879c5c575bd03cdb612c","Message":"chore(reports): check:fixtures 回绑 @ 7f82399\n\n合并后重跑并重新绑定。上一份绑的是 532e807，其注册中心一栏计的是本地 9ac9914 那套夹具（19 例），\n该实现已在 7f82399 的合并中整体放弃，报告随之失真，故在合并提交上重跑。\n\n在 .worktrees/merge-registry-remote 的干净检出（HEAD=7f82399）跑全 17 套件：\n296 例，失败 0，不可用 0，configurationError 0；provenance worktreeDirty=false、runner=local。\n与上一份的差异只在注册中心一栏：19 例（本地实现）→ 15 例（远端实现），总数 300 → 296。\n\ncontracts/dist 由该检出自己 tsc 构建；runtime 九个模块经 turbo 全量缓存命中\n（runtime/ 自上次绑定以来无任何提交，构建输入哈希一致）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:07:24-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/b62945890987b341b65684046c6e4d8ae612c529...0ed7ee700a678dd6bea6879c5c575bd03cdb612c","Len":9}...
|
1789744064
|
Edit
Delete
|
|
31154
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"34403ffdf {"Commits":[{"Sha1":"34403ffdfeda4af776b5f4063a40b9b04340895a","Message":"docs(部署): 记录补 §12——三个 dev 运行面重启复验与读写面 curl 取证\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:07:48-07:00"}],"HeadCommit":{"Sha1":"34403ffdfeda4af776b5f4063a40b9b04340895a","Message":"docs(部署): 记录补 §12——三个 dev 运行面重启复验与读写面 curl 取证\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:07:48-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/0ed7ee700a678dd6bea6879c5c575bd03cdb612c...34403ffdfeda4af776b5f4063a40b9b04340895a","Len":1}...
|
1789744129
|
Edit
Delete
|
|
31155
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"74c732d8d {"Commits":[{"Sha1":"74c732d8d4b88957365dd80770032bab706e84e2","Message":"chore(reports): B3′ 的四十一份三级证据 回绑 @ df72512，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 df72512（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=df72512、worktreeDirty:false）：\n静态 28 + 运行态 13。静态整轮 **28/28 步骤全部通过**（退出码 0），运行态 733 tests /\n行为矩阵 204/204 / 87 项指标零违规。\n\n本批改的是两后端的 WS 传输层与 replay 查询，两个预设风险点均未兑现：\n- 16 KiB 传输层上限**未挡住任何测试**——正常控制帧远在其下，上限值选得合适\n- outbox 查询由 findFirst 改为 aggregate(_min/_max) 后，在 RLS enforce 下行为与原先一致\n\nruntime 跑了两轮，**数字完全一致**（733 / 204-204 / 零违规），无非确定性；第一轮因改动\n尚未提交而 worktreeDirty:true，按仓规矩只绑定本地、不能作阶段门证据，故提交实现后重跑。\n这是顺序问题不是结果问题——记下来是为了下次先提交再跑，省一轮 20 分钟。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:15:17-07:00"},{"Sha1":"df72512110999b668b00c5cbf94ce0691ec7f3af","Message":"feat(realtime): B3′ 采纳上游两处加固——重放游标缺口判定与 WS 传输层单帧上限\n\n立项 §2 的「采纳上游加固 4」批次。逐个比对后实收两处真加固、一处口径收敛，另有两处\n开工时的判断被实测推翻，一并更正在代码注释里。\n\n一、replay 转发到 @juhai/kernel，补上 cursor-unknown\n\n本仓的 replay.ts 是框架 0.1.0 时代的拷贝，导出名与框架一致但实现落后一代，缺\n`maxSeq` 与策略「游标超前于现存最大 seq ⇒ 报缺口」。旧实现下，客户端报一个本租户\n从未产生过的游标（伪造 / 串号 / DB 被重置）会命中 pendingCount === 0 而返回 none——\n「已追平」与「真的没有新事件」在数值上无从区分，客户端**永远停在一个不存在的进度上、\n再也收不到补发**，与本仓「绝不静默缺口」的判据直接冲突。\n\n实证（打转发后的实现）：\n since=999999, maxSeq=42 → {\"kind\":\"gap\",\"reason\":\"cursor-unknown\"}\n since=42, maxSeq=42 → {\"kind\":\"none\"} ← 真已追平，无误报\n\n框架同时修了契约文件内部的自相矛盾：pendingCount 旧注释写「且已投递」，与两后端刻意\n选定的账本语义相反（outbox 是「发生过什么」的账本，补发范围是全部留存行，重叠由客户端\n按信封 id 去重）——docs-truth 扫不到这类矛盾。\n\n两后端各改一处查询：findFirst(minSeq) → aggregate(_min/_max)，一次拿两个边界，\n比原先还少一次往返。\n\n二、WS 传输层单帧上限（REALTIME_WS_MAX_PAYLOAD_BYTES = 16 KiB）\n\n框架注释记了一次真实事故，而**本仓此前正处在那个状态**：只有应用层的\nREALTIME_MAX_COMMAND_BYTES = 4096，没有接线传输层，而 ws 的默认 maxPayload 是 100MiB\n——任意客户端反复发 100MiB 帧即可制造内存压力，而「防撑爆」的守卫在内存被完整缓冲\n之后才生效。本批同时接线两后端并取同值（G17）：\n Fastify app.register(websocket, { options: { maxPayload: … } })\n NestJS @WebSocketGateway({ path: \"/ws\", maxPayload: … })\n传输层 16384 比应用层 4096 留一档余量，使「超协议约束」与「超传输上限」成为两种可区分\n的失败：4096~16384 的帧仍拿到语义清晰的 connection.error(too-large)，真正的巨帧在协议层\n即被 close 1009 掐断。**只加常量不接线正是该注释批评的形态**，故两者同批落地。\n\n三、两处开工判断被实测推翻，已更正在注释里\n\n1) 「订阅列表无上限」不成立：本仓原本就有 .max(50) / .max(200)，只是写成字面量，\n 值与框架一致。本批只是把魔法数字收敛成具名单源，不是补安全缺口。\n2) subscription 不是单纯落后，而是**互有领先**：框架有那两个上限，本仓有\n `envelope.resourceRefs` 这条「新事件唯一扩展协议」（禁止为产品主键继续追加字段名猜测，\n 否则行业对象会反向污染内核），框架那份仍是「取第一个以 Id 结尾的键」的启发式。\n 整份转发会删掉本仓这个设计，故**不转发**——按迁移手册 §6 走分歧账本，只取上限、\n 保留本仓实现。这是三个模块里唯一的合并式采纳。\n\n@repo/contracts 1.19.0 → 1.20.0。注意 P7 **没有要求**这次升版：根与 kernel 两个 barrel 的\nexport 行都没变，而 apiDigest 只哈希入口 .d.ts。但公开面实际多了 3 个符号，按语义应升——\n真正记录这次面变化的是 K1 锁（replay.ts 的 4 个导出转移给内核包、另两处各 +1/+2，\n40 模块 / 755 导出）。\n\n验证：contracts 312/312 · typecheck 13/13 · 静态整轮 28/28 · runtime 733 / 行为矩阵 204/204 /\n零违规（16 KiB 上限未挡住任何测试，aggregate 在 RLS enforce 下行为与 findFirst 一致）。\nruntime 报告在本提交后重跑回绑。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:03:00-07:00"}],"HeadCommit":{"Sha1":"74c732d8d4b88957365dd80770032bab706e84e2","Message":"chore(reports): B3′ 的四十一份三级证据 回绑 @ df72512，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 df72512（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=df72512、worktreeDirty:false）：\n静态 28 + 运行态 13。静态整轮 **28/28 步骤全部通过**（退出码 0），运行态 733 tests /\n行为矩阵 204/204 / 87 项指标零违规。\n\n本批改的是两后端的 WS 传输层与 replay 查询，两个预设风险点均未兑现：\n- 16 KiB 传输层上限**未挡住任何测试**——正常控制帧远在其下，上限值选得合适\n- outbox 查询由 findFirst 改为 aggregate(_min/_max) 后，在 RLS enforce 下行为与原先一致\n\nruntime 跑了两轮，**数字完全一致**（733 / 204-204 / 零违规），无非确定性；第一轮因改动\n尚未提交而 worktreeDirty:true，按仓规矩只绑定本地、不能作阶段门证据，故提交实现后重跑。\n这是顺序问题不是结果问题——记下来是为了下次先提交再跑，省一轮 20 分钟。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T08:15:17-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/4da2c656ae691428be3f177563952cba66c37b88...74c732d8d4b88957365dd80770032bab706e84e2","Len":2}...
|
1789744520
|
Edit
Delete
|
|
31156
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"56039d0a5 {"Commits":[{"Sha1":"56039d0a57c27a4ec97ad38e4fc982ec28f136c1","Message":"docs(治理): CODEOWNERS 占位维持原样——裁决与理由写进文件本身，不再让下一个人重新吵\n\nPR #36 把全部团队占位改指 @laoluojuhai（修 GitHub API 的 16 条 Unknown owner），rebase 试算时\n这处是六个 PR 里唯一一处不能机械合的冲突：照它合会抹掉 main 里 CHG-018 条件 D 要求的工作台实名行，\n照 main 合又等于默默丢掉它的修复意图。2026-09-18 由目录负责人裁决：**维持占位。**\n\n裁决时核到的事实（都写进 .github/CODEOWNERS 头注释了）：\n- GitHub 仓是个人仓（owner.type=User、private、唯一协作者 laoluojuhai/admin）。个人账号下不可能有团队，\n `@juhai-platform/*` 这 16 行永远解析不了；API 实测正是 16 条 Unknown owner，工作台那行实名反而可解析。\n- 真源远端是 Gitea（luoanwu），`@laoluojuhai` 在那边同样解析不了——这份文件当前在**两个远端都不产生\n required reviewer**，它现在只是路径 → 角色的登记。\n- 所以 16 条 Unknown owner 是「治理尚未接线」的真实信号，与本仓「显式 skipped 不冒充 passed」同口径。\n- 反面代价：唯一 owner = 唯一协作者，一旦启用 require review from Code Owners，Owner 自己的 PR 无人可批、\n 全部卡死。现在分支保护没启用所以无实害，但那正是这份文件将来要用的地方。\n\n解除条件：仓库迁入 GitHub Organization 并建出 @juhai-platform/* 团队（SRE / Owner 的仓库设置动作）。\nCLAUDE.md 未完成清单那条同步标注为「已裁 + 解除条件」，不再挂成无人认领的欠账。\n\n本提交不改任何 owner 行，只加注释：codeowners.test.mjs 2/2 通过（八条路径覆盖、七模块各有独立行）。\ntrial/rebase-36 上这处本就取的 main 侧，裁决与该分支现状一致，无需再改。\n\nCo-Authored-By: Claude Opus 5 \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:24:55-07:00"},{"Sha1":"de532d4cdc4577caab37df28e8775d4291a8290b","Message":"chore(reports): check:fixtures 回绑 @ 94366bc\n\n17 套件 302 例，失败 0，不可用 0；provenance 绑 94366bc、worktreeDirty=false。\n\n生成方式与既往不同，记在这里以便复核：主工作区连续 4 小时没有出现过干净树\n（并行会话常驻 2—3 份在途文件），因此按偏差 #34-A 裁决立的那条路径——「不放宽\nworktreeDirty 判据，改为换个干净的地方生成报告」——在 HEAD 开 git worktree、装依赖、\n构建后在该检出内跑门禁，再把报告带回。reports:rebind 工具本身拒绝 check:fixtures，\n理由是它需要构建产物（工具靠 governance/ 零依赖才能免 install），那是工具能力边界，\n不是判据边界；本次手工补上了它缺的 install 与 build 两步。\n\n检出必须落在工作区内（本次用 企业控制面/.worktrees/）：dec-039-party-model 是\nworkspaceRelative 套件，要向上找到含 workspace.json 的工作区根，放在 /private/tmp\n会以 unavailable 让门禁 exit 1。\n\n本报告作用域内（governance/fixtures、check-fixtures.mjs、lib/json-schema.mjs、\nruntime/modules、contracts/src/domain、contracts/test/fixtures、contracts/schemas）\n无任何未提交输入；当时主工作区脏的 3 个文件（CLAUDE.md 与 check-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-18T12:25:54-07:00"},{"Sha1":"94366bc03cb9ba137cd353d50151a01023e9a9c7","Message":"fix(contracts): 注册中心四条就绪闸门只认字面 true，并把持有它们的 393 行接进夹具门禁\n\n不是恢复 9ac9914。那版实现已由 7f82399 的合并整体放弃、取远端那套；本条只在现行\n实现上补它缺的一类判定，用现行实现自己的命名与写法。\n\n现行实现已经做到的，本轮一行未动：崩溃面在远端那版就已收口（REGISTRY_SNAPSHOT_REQUIRED /\nUPGRADE_REQUEST_REQUIRED / UPGRADE_REVIEW_CONTEXT_REQUIRED 等）；摘要大小写的处理比\n本地那版更好——normalizeDigest 归一化成小写、sameHexRef 做大小写无关比较，是规范化\n而不是拒绝，这条采纳远端口径。\n\n仍缺的一条：independentGitSourceReady / codeownersReady / requiredCheckEvidenceReady /\nrollbackEvidenceReady 写作 !context.x。实测传 \"false\"——JSON 里最常见的假值写法——\n一律判为已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW，1 / \"no\" / {} 同理。同一文件的\nsourceWorktreeDirty !== false 与 compatible / manualReviewRequired 本来就是严格写法，\n本轮把这四条与之对齐。\n\n门禁覆盖：snapshot-upgrade-review.ts 在夹具评估器上仍是零覆盖（规则只有 snapshot /\ntransition / plan），而它正是这四条闸门的所在。补 upgrade 规则，BLOCKED 不算放行。\n\n核验：定向 44 → 46 例（既有 44 例一条未改）；夹具 15 → 21 例（正 5 / 反 16）0 失败，\n两个方向都钉（真值字符串与字面 false 各一组）；负向实做：把\nN13-truthy-string-must-not-mark-codeowners-ready 的声明原因改成不会产生的串，门禁\nexit 1 并点名该例，还原后 exit 0。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-18T12:24:22-07:00"}],"HeadCommit":{"Sha1":"56039d0a57c27a4ec97ad38e4fc982ec28f136c1","Message":"docs(治理): CODEOWNERS 占位维持原样——裁决与理由写进文件本身，不再让下一个人重新吵\n\nPR #36 把全部团队占位改指 @laoluojuhai（修 GitHub API 的 16 条 Unknown owner），rebase 试算时\n这处是六个 PR 里唯一一处不能机械合的冲突：照它合会抹掉 main 里 CHG-018 条件 D 要求的工作台实名行，\n照 main 合又等于默默丢掉它的修复意图。2026-09-18 由目录负责人裁决：**维持占位。**\n\n裁决时核到的事实（都写进 .github/CODEOWNERS 头注释了）：\n- GitHub 仓是个人仓（owner.type=User、private、唯一协作者 laoluojuhai/admin）。个人账号下不可能有团队，\n `@juhai-platform/*` 这 16 行永远解析不了；API 实测正是 16 条 Unknown owner，工作台那行实名反而可解析。\n- 真源远端是 Gitea（luoanwu），`@laoluojuhai` 在那边同样解析不了——这份文件当前在**两个远端都不产生\n required reviewer**，它现在只是路径 → 角色的登记。\n- 所以 16 条 Unknown owner 是「治理尚未接线」的真实信号，与本仓「显式 skipped 不冒充 passed」同口径。\n- 反面代价：唯一 owner = 唯一协作者，一旦启用 require review from Code Owners，Owner 自己的 PR 无人可批、\n 全部卡死。现在分支保护没启用所以无实害，但那正是这份文件将来要用的地方。\n\n解除条件：仓库迁入 GitHub Organization 并建出 @juhai-platform/* 团队（SRE / Owner 的仓库设置动作）。\nCLAUDE.md 未完成清单那条同步标注为「已裁 + 解除条件」，不再挂成无人认领的欠账。\n\n本提交不改任何 owner 行，只加注释：codeowners.test.mjs 2/2 通过（八条路径覆盖、七模块各有独立行）。\ntrial/rebase-36 上这处本就取的 main 侧，裁决与该分支现状一致，无需再改。\n\nCo-Authored-By: Claude Opus 5 \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:24:55-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/34403ffdfeda4af776b5f4063a40b9b04340895a...56039d0a57c27a4ec97ad38e4fc982ec28f136c1","Len":3}...
|
1789770383
|
Edit
Delete
|
|
31157
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"60abd47e1 {"Commits":[{"Sha1":"60abd47e194c0b84e63968d27d493fd2fbdde658","Message":"chore(reports): B2c-1 的二十八份静态证据 回绑 @ 9eba0fd，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 9eba0fd（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=9eba0fd、worktreeDirty:false）。\n静态整轮 28/28 步骤全部通过（退出码 0）。\n\n未跑运行态：本批只新增两个纯转发的契约文件，未改任何运行代码，runtime 证据仍绑\ndf72512（733 / 204-204 / 零违规）且未失效。按三级分开陈述纪律，不用静态绿冒充运行态绿，\n也不为没动运行代码的改动重跑一轮 20 分钟。\n\nkernel-admission 报告里 request-context.ts 与 platform-ports.ts 会出现在 K5 的\n「零跨产品消费」观测行——这是**预期且已登记**的过渡态（立项 §5.1），不是新缺口：\n接线在 B2c-2，届时它们才真正被消费。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T15:32:52-07:00"},{"Sha1":"9eba0fd28474159053db82929391b72070d4c78f","Message":"feat(contracts): B2c-1 迁入平台端口契约——自建 permission/audit 的可替换插座就位\n\n「内核退回 pin」里价值最高的一块的**契约层**。框架 0.7.0 的 platform-ports 给出四个端口\n（权限 / 审计 / 事实出口 / 服务凭据），各自对应一个企业控制面模块；端口只定形状与\nfail-closed 默认实现，权威实现由基础设施在装配点注入。\n\n packages/contracts/src/request-context.ts 14 导出（platform-ports 的决策入参形状）\n packages/contracts/src/platform-ports.ts 31 导出\n\n对本仓的意义：自建 identity / permission / audit 是错层资产（铁律三：平台拥有规则），\n但此前**没有可替换的接口**，替换等于大手术。插座就位后，将来控制面客户端发布且有 CI\n阶段门证据时只换实现、**接口不变**——迁移从「大手术」降为「接插座」。本仓分叉于框架\n0.1.0、从未见过这组端口，这正是当初各造一套的原因。\n\n**本批只做契约层，接线另起一片（B2c-2），理由与代价登记在立项 §5.1。**\nB2 开工时我立过「净迁入的模块不该先暴露后接线」，这里部分收回并说明区别：接线实测远大于\n立项估计——要在两后端各实现 PermissionDecisionPort、经 registry.replace() 注入、改写一条\n**正在生效的权限判定链**。安全敏感改动不该接在长批次尾巴上做。过渡期这两个模块是零消费面，\nK5 会把它们列进观测行；**这不是绿，是登记在案的欠账**，B2c-2 长期不做就应当退回去。\n\n已查清的接线设计（下一片直接用）：**不能直接拿框架的 createLocalPlatformPorts 做权限端口**\n——它是「租户作用域 + 动作目录」式放行，比本仓的 resolveEffectivePermissions（角色矩阵 +\nsubject 级覆盖 + ALLOW/DENY 优先级）**弱**，套用等于削弱一条在跑的控制。正确做法是本仓实现\n自己的端口委托现有判定，用框架为此预留的 registry.replace() 注入。收口点已定位：\nNestJS PermissionsService.require()、Fastify hasEffectivePermission()。\n顺带好性质：PLATFORM_PORTS_MODE=local 将成为部署配置里一句可审计的显式声明\n——「本部署跑在自建权限上，不是平台权威」，错层资产第一次在编排层可见。\n\n过程中修了两个同类错误，都是**转发清单靠 grep 生成而 grep 漏了模式**：\n ① 漏 `export async function` → assertPermitted 未转发\n ② 把 class PlatformPortsRegistry 放进 type 组 → tsc 全过、运行时取不到\n第二个尤其阴险。现已加运行时可取性核对，10 个值导出全过；31 个导出与框架逐一比对无遗漏。\n\n@repo/contracts 1.20.0 → 1.21.0；三把锁重签（exports 42 模块 / 755 导出）；边界受管面\n144 → 146；接入手册下游锁行同步。静态整轮 **28/28**（退出码 0）。\n运行态未受影响——本批只加契约文件，未改任何运行代码，runtime 仍绑 df72512。\n\nCo-Authored-By: Claude Opus 5 \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:31:20-07:00"}],"HeadCommit":{"Sha1":"60abd47e194c0b84e63968d27d493fd2fbdde658","Message":"chore(reports): B2c-1 的二十八份静态证据 回绑 @ 9eba0fd，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 9eba0fd（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=9eba0fd、worktreeDirty:false）。\n静态整轮 28/28 步骤全部通过（退出码 0）。\n\n未跑运行态：本批只新增两个纯转发的契约文件，未改任何运行代码，runtime 证据仍绑\ndf72512（733 / 204-204 / 零违规）且未失效。按三级分开陈述纪律，不用静态绿冒充运行态绿，\n也不为没动运行代码的改动重跑一轮 20 分钟。\n\nkernel-admission 报告里 request-context.ts 与 platform-ports.ts 会出现在 K5 的\n「零跨产品消费」观测行——这是**预期且已登记**的过渡态（立项 §5.1），不是新缺口：\n接线在 B2c-2，届时它们才真正被消费。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T15:32:52-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/74c732d8d4b88957365dd80770032bab706e84e2...60abd47e194c0b84e63968d27d493fd2fbdde658","Len":2}...
|
1789770776
|
Edit
Delete
|
|
31158
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"04d02d611 {"Commits":[{"Sha1":"04d02d611af85737ed1ee7ae7d6644b6dedb51ad","Message":"chore(reports): check:module-imports 回绑 @ e61bfcf\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑，绑 e61bfcf / worktreeDirty=false。\n扫描 396 个源文件（扫描集 git，含新纳入的 runtime/clients 9 个），0 处违规。\n\n本工作区另有 5 份 stale 报告（release-manifest / sbom / image-smoke / runtime 的 naming 与\nfork-readiness）不由本次改动引起，属其他任务的 WIP，未动。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T15:29:14-07:00"},{"Sha1":"e61bfcf394f90171647b453a6960e84408109ed8","Message":"fix(governance): check:module-imports 补上 clients 扫描面与行号——对外发布包此前零门禁，违规行号整体前移\n\n扫描集与三处判定问题一并收口：\n\n1. 扫描集取自 `git ls-files` 而不是文件系统遍历：walk() 只认 SKIP_DIR、从不读 .gitignore，\n workbench 静态导出产物与两个 next-env.d.ts 也被计进 filesScanned，同一提交在干净检出报 387、\n 在构建过的开发机报 411。filesScanned 是绑在 provenance.gitSha 上的声明，必须是该提交能复现的数。\n 代价是未 `git add` 的新文件扫不到（实测：未 add 绿、`git add -N` 后红），由 worktreeDirty=true 标出。\n\n2. runtime/clients 此前是**双重盲区**：既不在 SCAN_ROOTS，evaluateImports 也没有该路径前缀的分支，\n 实测三种违规（module 包 / @repo/* / 越包相对）全部返回 []。唯一的事实防线是 tsc，而它只拦带绑定的\n import（TS2307）；`import \"@juhai/module-permission\";` 这种纯副作用写法 exit 0，偏偏它就足以把整个\n 模块拉进发布包的运行时依赖图。`governance/evidence-scopes.json` 的 module-imports 条目 scope 里\n 早就写着 runtime/clients——登记与实现在此分叉，登记那侧是对的。\n 新增 CLIENT_FORBIDDEN_IMPORT / ESCAPES_CLIENT；禁的是整个 @repo/*，不只 @repo/contracts：\n @repo/config 与 @repo/telemetry 同样 workspace-only，发布后消费者一律解析不到。对 module-kit 不开口子。\n\n3. 违规行号系统性偏移：stripComments 整段删块注释、又把 // 行从数组里 filter 掉，两处都在丢行。\n 本仓文件普遍有顶部大段块注释，实测真实第 9 行的违规报成第 3 行。改为等量保留换行。\n 行号是报告与 CLI 给人定位的唯一坐标，错的行号比没有行号更费事。\n\n4. violations 按 (文件, 行) 排序再交出：extractSpecifiers 按三个 pattern 分组扫，原始顺序里\n `import \"x\";` 会掉到同文件更靠后的 `import … from \"x\"` 之后。用 codePoint 序而非 localeCompare，\n 避免 CI 与本机 ICU 不同让 reports/ 的 diff 无故抖动。\n\n导出 SCAN_ROOTS 供测试引用，消除测试里另抄一份路径清单（抄的那份会跟实现分叉）。\n\n本机实测：扫描 396 个源文件（387 + 9 个 clients），全量 pnpm check 16 道 exit 0，\ngovernance 测试 341 → 346（+4 行号与 clients 回归、+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-18T15:28:21-07:00"}],"HeadCommit":{"Sha1":"04d02d611af85737ed1ee7ae7d6644b6dedb51ad","Message":"chore(reports): check:module-imports 回绑 @ e61bfcf\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑，绑 e61bfcf / worktreeDirty=false。\n扫描 396 个源文件（扫描集 git，含新纳入的 runtime/clients 9 个），0 处违规。\n\n本工作区另有 5 份 stale 报告（release-manifest / sbom / image-smoke / runtime 的 naming 与\nfork-readiness）不由本次改动引起，属其他任务的 WIP，未动。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T15:29:14-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/56039d0a57c27a4ec97ad38e4fc982ec28f136c1...04d02d611af85737ed1ee7ae7d6644b6dedb51ad","Len":2}...
|
1789771529
|
Edit
Delete
|
|
31159
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"b60cc18d6 {"Commits":[{"Sha1":"b60cc18d640a6561ccdd0fa798753d1f6476bad5","Message":"chore(reports): runtime 静态门禁链整批回绑 @ 7fc7f02\n\n在 7fc7f02 的干净 detached worktree 里跑完整 `pnpm --dir runtime check`\n（先 install --frozen-lockfile + prisma:generate，否则 api-nestjs#build 会以\n@prisma/client 缺导出成员一类的 TS 错误失败）：turbo 31/31，聚合\nruntime/reports/governance.latest.json status=passed，15 项违规指标全 0——\n其中 reportProvenanceViolations=0，正是此前单跑一道门禁做不到的那一条。\n\n18 份静态子报告现在同绑 7fc7f02 / worktreeDirty=false，15 份共用同一 runId\n（permission-catalog 与 platform-ops-definitions 沿用各自的 sync 脚本 runId，与改动前一致）。\n\n三份高等级真跑证据按原样保留、未被覆盖：runtime-acceptance @ 08c3788、\nui-acceptance @ 1b23285、conformance-differential @ 08c3788。\n\nCo-Authored-By: Claude Opus 5 \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:48:28-07:00"},{"Sha1":"57023cdc23442303c3336e86a433638d16c29452","Message":"docs(治理): 订正两处版本声明——内核 pin 落后六个 minor，contracts 落后两个 RC\n\n两处都是带来源标注、看起来可核对的事实，实际都已漂：\n\n- 内核 pin 写 `@juhai/kernel@0.16.1`，实际 `runtime/pnpm-lock.yaml` 解析到 `0.22.0`\n （tarball 确在 Gitea `luoanwu`，来源描述本身没错），12 个 package.json 声明一致。\n- contracts 写 `1.0.0-rc.1`。2026-09-18 向 Gitea Registry 实查：`@juhai/contracts` 的\n rc.0 / rc.1 / rc.2 / rc.3 四版俱在，与 `contracts/package.json` 的 rc.3 一致；\n `@juhai/governance` 同为四版，`@juhai/client-fact` 为 rc.2 / rc.3。\n\n顺带把发布通道写进去，避免下一个人把 rc.3 当成走过发布门禁的版本：rc.2 与 rc.3 都经\n本地旁路通道发出（rc.2 见 docs/G-12本地旁路发布记录-2026-09-13.md，源 eb3cf2c，\nprovenance.json 如实写 runner:\"local\"）。按 G-12 划的边界，这两版可称「已发布、可被\nexact pin 消费」，不得称「经过发布门禁验证」。\n\n**rc.3 在仓内没有对应的发布记录文档**（G-12 只记到 rc.2，而 runtime/clients/README.md\n与两份清单都已按「rc.3 已发布」在引用它）——本次只把缺口标注出来，补记录另做。\n\n这两处此前无人守：治理层 L13 只守「治理层自己的」裁决数 / 平台项目数 / 收纳表文件数，\n不覆盖真源仓 CLAUDE.md 的版本 pin。改 pin 时须手动回来改这两行。\n\nCo-Authored-By: Claude Opus 5 \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:48:19-07:00"},{"Sha1":"7fc7f02c88c9768be49c80096b80962a6d6624ad","Message":"docs(治理): runtime 动态区回灌两级验收 SHA——报告已跑到 08c3788 / 1b23285，动态区还停在 765300b\n\ncheck:docs-truth 的 freshness-sha-runtime / freshness-sha-ui 两条在 HEAD 上就是红的：\nruntime-acceptance 与 ui-acceptance 已分别重跑并绑定 08c3788 / 1b23285，而动态区仍声明\n765300b，连带隔离栈与端口也是上一轮的（ms23-ci :55485 / :56395 db10、web :3157）。\n\n按两份报告逐字回灌：775 tests / 0 failures、5 用例 / 0 失败、tenantRlsEnforced=1、\n验收库 enterprise_platform_acceptance_20260918（PG :55471）+ Redis :56380 db7、\nweb :3120 / api :3222。删掉「框架同步后首跑」——那是 765300b 那一轮的上下文，\n08c3788 已是其后的再跑。\n\nCo-Authored-By: Claude Opus 5 \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:25-07:00"},{"Sha1":"772b253623b14f66b8cd1bfddd60901348d5ca9b","Message":"chore(reports): release-manifest / sbom / naming / fork-readiness 四份回绑 @ 04d02d6\n\n四份都是真过期（与上一轮 module-imports 不同——那份实为已新鲜、误判后我撤回未提交）：\n\n release-manifest 作用域内 reports/image-digest.json 与 stack/compose.yaml 变更\n sbom 作用域内 reports/image-digest.json 变更，即它描述的是旧镜像\n naming runtime/apps/workbench 四个源文件变更\n fork-readiness 同上\n\n生成方式同 de532d4：主工作区常驻并行会话在途文件、拿不到干净树，按偏差 #34-A 裁决\n「不放宽 worktreeDirty 判据，改为换个干净的地方生成报告」，在 HEAD 开 worktree\n（落在 企业控制面/.worktrees/，workspaceRelative 套件要向上找 workspace.json）跑门禁\n再带回。release-manifest 与 sbom 的生成器在零依赖的 governance/ 下，无需 install；\nnaming 与 fork-readiness 需要已安装的私有内核包，故在检出内 pnpm --dir runtime install。\n\n四份结论逐项与旧版对照，无一劣化：\n\n release-manifest status 仍 partial，缺项仍 6 条；只有镜像绑定那条的 sha 随之更新\n （d8f0920 ≠ b202dde → 05e3826 ≠ 04d02d6），runtime 镜像仍未在 HEAD 重建\n sbom coverage 仍 partial、268 包不变；ref 由 fe418667 更新为 c0869934，\n 即它现在描述的是当前登记的镜像而不是旧的那个。连带重出\n reports/sbom.spdx.json，其 sha256 与报告记录实算一致（ecc5e62e…）\n naming violations 0 不变\n fork-readiness violations [] / forkReadinessViolations 0 不变\n\n四份 provenance 均绑 04d02d6、worktreeDirty=false，与提交时主仓 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-18T15:46:46-07:00"}],"HeadCommit":{"Sha1":"b60cc18d640a6561ccdd0fa798753d1f6476bad5","Message":"chore(reports): runtime 静态门禁链整批回绑 @ 7fc7f02\n\n在 7fc7f02 的干净 detached worktree 里跑完整 `pnpm --dir runtime check`\n（先 install --frozen-lockfile + prisma:generate，否则 api-nestjs#build 会以\n@prisma/client 缺导出成员一类的 TS 错误失败）：turbo 31/31，聚合\nruntime/reports/governance.latest.json status=passed，15 项违规指标全 0——\n其中 reportProvenanceViolations=0，正是此前单跑一道门禁做不到的那一条。\n\n18 份静态子报告现在同绑 7fc7f02 / worktreeDirty=false，15 份共用同一 runId\n（permission-catalog 与 platform-ops-definitions 沿用各自的 sync 脚本 runId，与改动前一致）。\n\n三份高等级真跑证据按原样保留、未被覆盖：runtime-acceptance @ 08c3788、\nui-acceptance @ 1b23285、conformance-differential @ 08c3788。\n\nCo-Authored-By: Claude Opus 5 \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:48:28-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/04d02d611af85737ed1ee7ae7d6644b6dedb51ad...b60cc18d640a6561ccdd0fa798753d1f6476bad5","Len":4}...
|
1789771713
|
Edit
Delete
|
|
31160
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"f3d2cfe8c {"Commits":[{"Sha1":"f3d2cfe8c6567a9f343080ec659543e412c4e688","Message":"chore(reports): ADR 0011 提案的二十八份静态证据 回绑 @ 74fbaea，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 74fbaea（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=74fbaea、worktreeDirty:false）。\n静态整轮 28/28 步骤全部通过（退出码 0）。\n\n未跑运行态：本批只动文档（ADR 0011 提案、立项书 B2c-2 挂起登记、ADR 索引），未改任何运行\n代码，runtime 证据仍绑 df72512（733 / 204-204 / 零违规）且未失效。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T15:49:10-07:00"},{"Sha1":"74fbaea684f5b580936edcdcdb1b56a0557fade8","Message":"docs(决策): ADR 0011 提案——授权判定不得以 IdP 的 role claim 为权威\n\nB2c-2 平台端口接线开工即撞到阻塞，它暴露的不是接线问题，而是本仓授权模型的一个错层。\n按「单独立裁决项」处理，B2c-2 挂起。\n\n阻塞：框架 PermissionDecisionPort.decide() 的入参是 { context: RequestContext, action,\nresourceType, resourceId }，RequestContext 只有 tenantId / actorId——**不带角色声明**。\n而本仓生效角色判定是 bootstrapAdmin ? \"admin\" : (DB 角色 ?? claim 角色)，注释写明\n「DB 覆盖 claim」：**无 DB 记录时已验签 token 的 claim 角色就是权威**。原样接线会让\n「无记录」那类 subject 的授权来源消失。平台端口假设权威方能从（租户, 主体, 动作）自行解出\n一切——这对拥有角色存储的平台成立，对本仓的混合模式不成立。\n\n所以差距不只是「谁来实现」，还包括「决策输入是什么」。\n\n提案内容：生效角色只来自本系统可控的来源（roleAssignment 记录 + AUTH_BOOTSTRAP_ADMIN\n引导身份）；已验签 token 的 role claim 降级为信息，不参与授权判定。\n\n三条理由，第一条不是架构整洁而是安全面：\n1. **签发方等于授权方。** 当前只要 IdP 在 token 里写 role: admin，本仓即授予 admin，\n **OS 侧没有任何记录**。IdP 被攻陷或被误配就直接等于本仓提权，且事后审计在 OS 侧查不到\n 授予动作——因为从来没有授予动作。「DB 覆盖 claim」只在有记录时防住，恰恰在最常见的\n 「没记录」路径上不防。\n2. 铁律三「平台拥有规则」：角色归属属于规则，权威应在控制面 permission 模块。\n3. 这是 drop-in 的前提：决策还依赖 claim，将来换控制面客户端时仍是行为变更，只是推迟。\n\n影响面按 DB 记录有无精确切分（ADR §影响 有完整表）：有记录者不变；验签且 claim 为\nmember/缺失者不变；**验签、无记录、claim 为 approver/admin 者降为 member**（失败方向是\n更拒绝，不是 fail-open，但对这些人是功能性中断）；**demo 姿态自报 admin 会降为 member**，\n而它是 UI 验收与本地开发的前提（check:ui 打 mock-oidc-idp.mjs），须一并处理。\n\nADR 明确写下裁决前置：**必须先取得目标环境中「无 DB 记录且 claim 为 approver/admin」的\nsubject 实测计数**。该计数不取得，本 ADR 不应被批准——影响面未知的授权语义变更不可裁。\n\n同批：立项书 B2c-2 行改为「挂起，待 ADR 0011」并写明阻塞原因；docs/adr/README 加索引。\nB2c-1 迁入的 platform-ports / request-context 维持零消费面的过渡态（立项 §5.1 已登记）。\nB2c-2 开工时写的 NestJS 装配模块未提交（设计已完整记在 ADR 与立项里，届时重写即可）。\n\n静态整轮 28/28。本批只动文档，未改运行代码。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T15:47:35-07:00"}],"HeadCommit":{"Sha1":"f3d2cfe8c6567a9f343080ec659543e412c4e688","Message":"chore(reports): ADR 0011 提案的二十八份静态证据 回绑 @ 74fbaea，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 74fbaea（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=74fbaea、worktreeDirty:false）。\n静态整轮 28/28 步骤全部通过（退出码 0）。\n\n未跑运行态：本批只动文档（ADR 0011 提案、立项书 B2c-2 挂起登记、ADR 索引），未改任何运行\n代码，runtime 证据仍绑 df72512（733 / 204-204 / 零违规）且未失效。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T15:49:10-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/60abd47e194c0b84e63968d27d493fd2fbdde658...f3d2cfe8c6567a9f343080ec659543e412c4e688","Len":2}...
|
1789771754
|
Edit
Delete
|