| content |
{"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}... |