| content |
{"Commits":[{"Sha1":"cf05344e1 {"Commits":[{"Sha1":"cf05344e117a84fedf092613be5fc13b7a07072b","Message":"chore(release): 三包推到 1.0.0-rc.5——pins 三层判据随包出去，fact-pii 有意留在仓内\n\n动因：check:pins 的三层判据（63ff31f）还不在任何已发布版本里，而 @juhai/governance 的\nrc.0—rc.4 已全部被占用，按 G-12 的边界只能往前发下一个 RC。\n\n**发布物里有什么、没有什么，说清楚免得下一个人误读：** check-pins.mjs 在 governance 包的\nfiles 里，所以三层判据随包出去，消费者仓跑 juhai-governance check:pins 会拿到新判据\n（他们没有 pins-baseline.json，第三方层不启用，行为与 rc.4 一致——这是设计好的向后兼容）。\n而 check-fact-pii.mjs 与 fact-pii-rules.json **有意不进 files**：它扫的是\ncontracts/schemas/facts/ 与 contracts/candidates/facts/，消费者仓根本没有这两个目录，\n发过去是道跑不起来的门禁。它属于本轮源码，但不是本轮发布物的一部分。\n\n自 rc.4 源 557a95c 起的随车内容（比 rc.4 那趟小得多）：\n contracts 14 文件 / 6 提交（7 个代码文件，三个域的 fixture-evaluator 与其单测）\n governance 10 文件 / 3 提交（两道新门禁 + 夹具覆盖度算法入文档）\n runtime/clients/fact 1 文件 / 1 提交 —— **只有 package.json，零内容变更，纯跟车**\n\n通道：本地旁路（G-12 第四次使用）。2026-09-18 实测：GitHub Actions 最新 run 35404565689 仍\nfailure（两个 job failure、其余 skipped，计费停摆的典型形态），正道仍不可满足。\n\n**一处新情况：推送死锁已解开。** rc.4 那趟记的是「GitHub 镜像落后 237 条、因分支保护的\nrequired check 跑不起来而推不动」；本次实测镜像落后已降到 24 条，github/main 指向 54e6324，\n说明有人把提交推上去了。但 Actions 仍不启动，所以正道仍差这一半——计费恢复后即可直接走正道，\n不必再先解死锁。\n\n按 CL-5 打 tag packages-v1.0.0-rc.5。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:45:09-07:00"},{"Sha1":"ff80f7e1b91b7fb012f0488736bce79b33db3ad5","Message":"docs(记录): 一个会话的契约包入参硬化与证据收口——重点是四次自我更正\n\n把散在提交信息与开发计划登记行里的结论汇到一处。写的是单个会话的范围，不代为总结\n同日并行会话在九个域做的同类工作；凡带数字的当前状态一律标注为落盘时点快照。\n\n四次更正里三次是判断错了、一次是方法缺了一步：\n\n1. 注册中心那套被放弃是对的，且不是风格之争。我当时报的「远端那版大部分相当，唯一\n 差异是原因码命名」是靠读代码比对得出的，后被 7523bd0 的双向交叉实测推翻——被放弃\n 那套有 4 个实缺陷，其中一条是它自己的注释抱怨「同一摘要两种写法等于两个身份」，\n 却只在入口拒大写、升级比较那条路上没修完。整个会话的方法论是先实测再下结论，\n 对自己的产物我没照做。\n2. module-imports 那次回绑是多余的，已撤回未提交。判据应为「这份报告现在是否被判\n 过期」，而不是「作用域是否干净」。\n3. 独立索引提交后必须 git reset 刷回共享索引，否则并行会话下次从索引提交会把已提交\n 改动带回去——本会话实际发生过一次。\n4. 上述回退事件一度被我误判为对方回退，实为 --amend 改写 SHA 叠加 BSD grep 的 \\| 不是\n 或运算符导致核实命令恒返回 0。核实要用 grep -E，且以内容为准不以 SHA 为准。\n\n另记回绑需构建产物门禁的两条实操约束：检出必须落在工作区内（workspaceRelative 套件\n要向上找 workspace.json），以及该不该回绑看作用域内有无未提交输入而非全仓是否干净。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:44:30-07:00"},{"Sha1":"bf834ce6bcb9551474ff6a18abaa832f2302739f","Message":"test(contracts): 配置与开关最大的一支规则不在门禁上——refresh 的六条原因码一条没钉，含明文密钥那条\n\n覆盖度探针对本套件的读数是「都没有 0 / 仅单测 0」，看上去已收口。但它按自述只变异夹具已有用例的\n字段，而 configuration-client.ts（167 行，LocalConfigurationClient 的 create / status / get / refresh）\n一条夹具用例都没有——整支规则从来不在它的统计口径里。两个规则文件零改动，只动夹具评估器。\n\n1. refresh() 的六条原因码一条都没钉：SNAPSHOT_FORMAT_INVALID、SNAPSHOT_VERSION_NOT_FORWARD、\n SNAPSHOT_NOT_APPROVED、SNAPSHOT_SCHEMA_INVALID、PLAINTEXT_SECRET_FORBIDDEN、SNAPSHOT_VERSION_STALE。\n 其中 PLAINTEXT_SECRET_FORBIDDEN 有两条到达路径——候选显式标注，以及键名命中密钥模式\n （normalizeSnapshot 把两者 OR 起来，apiToken 这样的键足以触发）——都在门禁之外。\n 新增 client 规则：按 active 建客户端再喂候选热更，APPLIED 为放行，否则返回 KEPT_LAST_KNOWN_GOOD\n 给出的 reasons；create 在两份快照都不可用时会抛，评估器收敛成 CONFIGURATION_UNAVAILABLE: 原因码，\n 而不是让整套夹具塌成 configurationError。\n\n2. snapshot 把 USE_LAST_KNOWN_GOOD 判成放行：候选被拒退回上一版与候选被采纳在夹具里是同一个结果，\n 实测「候选未批准」「候选含明文密钥」两种退回都判 ACCEPT。这一条改的是既有的、有意为之的口径\n （原评估器抬头写着「只有 USE_CANDIDATE / USE_LAST_KNOWN_GOOD 算放行」），理由是与同仓兄弟域对齐——\n 通知与 Webhook 的评估器写着「DUPLICATE / RETRY / DLQ / REJECT_REPLAY 都如实返回，因为它们在消费侧的\n 后果都不是『这次投递成功了』」。退回上一版同样不是「这次配置更新成功了」。\n 原 P04-falls-back-to-last-known-good 随之改名 N15-（门禁强制 id 前缀与 expect 一致）。\n\n一处明写不覆盖：refresh() 的 SNAPSHOT_VERSION_STALE 按构造不可达——active 建客户端时已过版本下限、\n候选又必须比 active 前进，合起来候选不可能低于下限；configuration-client.ts 抬头自己写明那是防御性\n补的一笔。N24 改钉「两份快照都不可用时 create 抛 CONFIGURATION_UNAVAILABLE:」这条真实出口。\n\n覆盖：夹具 18 → 28 例（正 4 / 反 24），定向测试 21 → 25 例，前一轮断言一条未改；\nfixture-coverage 稳定码 8 → 11，两档仍 0 / 0。变异探针（28 例 × 14 种脏值）4200 个变异点、0 处抛异常。\n\n未做（越界）：分桶、发布状态机、kill switch 仍不在本仓，C13 按缺失模块完善清单仍是「裁决」；\nCatalog 登记未动（仍 module_e2、code_truth 指向工单仓 packages/configuration-client）。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 408/408、该套件夹具 28/28 失败 0。\n负向实测：把 N23（密钥键名那条）的声明改成 SNAPSHOT_NOT_APPROVED → 门禁 exit 1 并点名该例，还原后 exit 0。\n本次不回绑任何 reports/。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:44:11-07:00"}],"HeadCommit":{"Sha1":"cf05344e117a84fedf092613be5fc13b7a07072b","Message":"chore(release): 三包推到 1.0.0-rc.5——pins 三层判据随包出去，fact-pii 有意留在仓内\n\n动因：check:pins 的三层判据（63ff31f）还不在任何已发布版本里，而 @juhai/governance 的\nrc.0—rc.4 已全部被占用，按 G-12 的边界只能往前发下一个 RC。\n\n**发布物里有什么、没有什么，说清楚免得下一个人误读：** check-pins.mjs 在 governance 包的\nfiles 里，所以三层判据随包出去，消费者仓跑 juhai-governance check:pins 会拿到新判据\n（他们没有 pins-baseline.json，第三方层不启用，行为与 rc.4 一致——这是设计好的向后兼容）。\n而 check-fact-pii.mjs 与 fact-pii-rules.json **有意不进 files**：它扫的是\ncontracts/schemas/facts/ 与 contracts/candidates/facts/，消费者仓根本没有这两个目录，\n发过去是道跑不起来的门禁。它属于本轮源码，但不是本轮发布物的一部分。\n\n自 rc.4 源 557a95c 起的随车内容（比 rc.4 那趟小得多）：\n contracts 14 文件 / 6 提交（7 个代码文件，三个域的 fixture-evaluator 与其单测）\n governance 10 文件 / 3 提交（两道新门禁 + 夹具覆盖度算法入文档）\n runtime/clients/fact 1 文件 / 1 提交 —— **只有 package.json，零内容变更，纯跟车**\n\n通道：本地旁路（G-12 第四次使用）。2026-09-18 实测：GitHub Actions 最新 run 35404565689 仍\nfailure（两个 job failure、其余 skipped，计费停摆的典型形态），正道仍不可满足。\n\n**一处新情况：推送死锁已解开。** rc.4 那趟记的是「GitHub 镜像落后 237 条、因分支保护的\nrequired check 跑不起来而推不动」；本次实测镜像落后已降到 24 条，github/main 指向 54e6324，\n说明有人把提交推上去了。但 Actions 仍不启动，所以正道仍差这一半——计费恢复后即可直接走正道，\n不必再先解死锁。\n\n按 CL-5 打 tag packages-v1.0.0-rc.5。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:45:09-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/67e81931c6da187ea61adff37ad74a4d9b672e8e...cf05344e117a84fedf092613be5fc13b7a07072b","Len":3}... |