| content |
{"Commits":[{"Sha1":"ba752059e {"Commits":[{"Sha1":"ba752059ee2e67443d3a4b9a1c023c80573bd584","Message":"docs(domain): 注册中心蓝图补记后三笔——第 4—6 条缺陷与现状证据此前不在蓝图里\n\n蓝图是 Catalog 给本模块登记的 evidence 之一，但它的「2026-09-18 规则加固」节只记了\n92a6b8e 那一笔：三条缺陷、数字停在单测 44 例 / 夹具 15 例（正 4 反 11）。同日的\n94366bc / 91216b5 / 5f3f608 没有在蓝图留下任何痕迹，于是蓝图对本模块的描述既滞后\n又不完整。本条只补记录，不改任何规则与 Catalog。\n\n补进去的三条：\n- 第 4 条（94366bc）：四条就绪闸门写作 !context.x，传 \"false\" / 1 / \"no\" / {} 一律\n 判为已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW；现改为 !== true，与同文件本来\n 就严格的 sourceWorktreeDirty !== false 对齐。92a6b8e 只收了入参形状，漏了这四个布尔位。\n- 第 5 条（94366bc + 91216b5）：snapshot-upgrade-review.ts 这 393 行在夹具评估器上零\n 覆盖（规则只有 snapshot / transition / plan），而第 4 条的闸门正在这里；补 upgrade\n 规则后按变异重算 snapshot / transition 侧覆盖，24 个分支里仍有 12 个没有用例走到，\n 再补 N17—N20 到 24/24。\n- 第 6 条（5f3f608）：upgrade 侧接进门禁后 6 个用例全对着四条就绪闸门，闸门下面那层\n 请求校验有 15 条原因码哪里都没有（两个 pin 的锁定四要素与消费者归属 10、目标制品\n schemaApiVersion 与 linter 证据 2、影响面清单比对 3）；补 N21—N27 后归 0。\n\n逐笔证据按各自当时的口径分列，不混成一句。另新增两段：「现状」给本节写定时 clean 树\n上的实跑值；「注意别引错证据」写明 reports/fixtures.latest.json 此刻仍绑 7523bd0、\n本套件记 25 例，5f3f608 之后未回绑，check:evidence 判 EVIDENCE_STALE——现状那行目前\n只有本地实跑支撑，引机器证据前须先重跑回绑。\n\n核验（本分支 clean 树，rebase 到 main 之后）：单测 53/53；check:fixtures 本套件 32 例\n（正 5 / 反 27）0 失败；check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写逐字一致（绑定 7523bd0 之后作用域内 3 个文件变更）；Catalog 四字段与六条 blockers\n逐项核对；runtime/modules/ 下确无本模块；相对链接 ../缺失模块完善清单-2026-09-16.md 可解析；\n表格 8 行各 4 列。\n\nCo-Authored-By: Claude Opus 5 \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:58:17-07:00"},{"Sha1":"95b88d34fca66f4030640c2652d3171ecfb05b97","Message":"docs(治理): 记录 2026-09-18 镜像同步被分支保护拒绝——顺带是 G14 缺的半份远端拦截实证\n\ngit push github HEAD:main 被 GH006 拒绝：required check\n\"Release candidate verification + manifest\" 缺失。推之前核过是纯快进（github/main\n是本地 HEAD 的祖先，落差 237 个提交，零分叉、无需 force），所以拒绝不是分叉造成的。\n\n记下三件事：① 分支保护配置快照（enforce_admins=true，对管理员生效；\nallow_force_pushes=false），这是本仓少数几处真正生效的远端拦截；② 该 check 产不出来的\n病因是 Actions 计费付款失败——最近三次 run 的失败 job 起止相差 2 秒且无日志，runner\n从未领取；③ 推之前用 merge-tree 试算的 8 条 base=main 的 PR 影响（6 条会翻成冲突），\n留档说明当前「20 条全 MERGEABLE」是镜像落后造成的假象。\n\n明写这份证据的边界：本次被拒的原因是 check 缺失，不是 check 判红，所以只能支撑\n「远端存在拦截」，不能支撑「远端拦截有效」——G14 的受控失败 PR 仍未做，不得标 GREEN。\n\nCo-Authored-By: Claude Opus 5 \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:02:20-07:00"},{"Sha1":"1a1b37e4669cfd80f87650050894fede8aee6b90","Message":"test(contracts): 会话准入 planner 的门禁覆盖——20 个可达出口只有 1 个走过，ADMIT 与 SKIP_DUPLICATE 还是同一个结果\n\n同日第一条（5720165）把判定收紧了，但门禁看不到其中绝大部分。对 dist 逐条实测：\nplan() 有 20 个可达出口，check:fixtures 上只走过 1 个（N06 无策略即拒），整张租户策略矩阵\n与 appendRejections 全部 8 行映射都只有单测看着，其中四个出口连单测也没有。\n\n本次判定逻辑一行未改——conversation-message.ts 与 conversation-admission-planner.ts 零改动，\n只动 fixture-evaluator.ts 的可见性，加用例。\n\n1. ADMIT 与 SKIP_DUPLICATE 在夹具里是同一个结果。评估器 plan 分支的判据是 `\"reasons\" in r`，\n 两者都没有 reasons，于是都返回空数组 = ACCEPT。把 ADMIT 全改写成 SKIP_DUPLICATE（或反过来）\n 门禁不会红，而这两者的区别正是「这条消息要不要真的落账」。同一文件里的 append 规则本来就写成\n 「只有 APPEND 算放行」，plan 现在与之同口径：非 ADMIT 即列出出口名。\n\n2. refresh() 在门禁上零覆盖（与公共文件 793d0a1 同形）。planner 三个公开方法里它是唯一没有夹具\n 规则的，版本回退拒绝与坏快照保留 last-known-good 此前只有单测。新增 refresh 规则：\n applied=true 为放行，否则返回 planner 自己给的 reason。\n\n3. 四个出口此前任何地方都没走过，均补单测：TENANT_NOT_ALLOWED（策略里根本没有这个租户，与\n 「请求跨租户」不是一回事）、CONVERSATION_TYPE_NOT_ALLOWED、SENDER_TYPE_NOT_ALLOWED（凭据与\n 发送者类型配套、策略仍不允许该类型，须与 ACTOR_CREDENTIAL_MISMATCH 分开证明）、\n CONVERSATION_TENANT_MISMATCH（映射表把 classify 的 TENANT_MISMATCH 换成 planner 自己的码）。\n\n覆盖：夹具 14 例（正 2 / 反 12）→ 39 例（正 4 / 反 35）；定向测试 23 → 30 例，第一轮的断言一条未动。\n并给此前只断言「拒绝」的 N05 / N06 补上 reasons 声明。plan 与 refresh 各留一例放行（P03 / P04）——\n只有放行一侧也钉住，SKIP_DUPLICATE 与 applied 的区分才有意义。\n\n一处明写不覆盖：appendRejections 的 REJECT → MESSAGE_APPEND_INVALID 按当前控制流不可达——\nclassifyConversationAppend 只在 preflight 失败时返回 REJECT，而 plan() 更早就返回了 preflight 拒绝。\n保留该行作纵深防御，但不造用例假装覆盖，理由写进夹具 description 与蓝图。\n\n未做（越界）：会话 / 成员 / 消息账本、长连接服务、Fact、独立运行服务一件未建，C16 按缺失模块完善清单\n仍卡在「裁决 · 实现」（Owner ADR、三消费者、G4）；Catalog 登记一律未动。\n\n证据：真实工作树 pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas\n无漂移、node --test contracts/test/*.test.mjs 382/382、contract-collaboration-messaging 夹具 39/39。\n负向实测两次：把 N19 的声明原因改成 ACTOR_CREDENTIAL_MISMATCH → 门禁 exit 1 并点名该例\n（reasons=[\"SENDER_TYPE_NOT_ALLOWED\"]）；把 N13 的 expect 翻成 ACCEPT → 被 id/expect 一致性规则\n先挡下（exit 1）。两次还原后 exit 0。本次不回绑任何 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:01:18-07:00"},{"Sha1":"ffdd21a2ae238023f2bb48a632deaabade5e88f1","Message":"docs(发布): 按产物内 provenance 订正 rc.2 的源——eb3cf2c 是写记录时的 HEAD，发布实际在 6d3900a\n\nG-12 表格原记「源 eb3cf2c」。rc.2 三个 tarball 内的 provenance.json 各自独立却一致记为\n6d3900a：该文件由 publish-rc.mjs 在发布那一刻写入，三包互证，是一手证据。\n三份产物的 sha512 与 Registry 登记的 integrity 也逐一核对一致，确认读的是架上那三个包。\n\neb3cf2c（21:26:55）与 6d3900a（21:42:24）相隔 15 分钟，其间只有一个纯文档提交\n（docs(ci)，改 stack/ci/act-runner/README.md）——**未触及三个发布包**。\n所以两个源产出的包字节完全相同，provenance.sourceSha 是唯一能区分的证据；\n产物本身不受影响，受影响的只是「从哪个提交发的」这条事实记录。\n\n上一条提交里「不擅改、留给执行者确认」的处置随之改为已订正，三处同步：\nG-12 表格、G-12「补记时一并发现的两处偏离」第 2 条、CLAUDE.md 的 contracts 条目。\n\nCo-Authored-By: Claude Opus 5 \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:00:24-07:00"},{"Sha1":"5f3f6084506e2a173759f07f882713ffdd4111ae","Message":"test(contracts): 注册中心 upgrade 的请求体检面——15 条原因码只有实现没有用例\n\n同日「注册中心入参体检的门禁覆盖」补的是 snapshot / transition 两条规则；按同一口径把 upgrade 也算了\n一遍，15 条「哪里都没有」，全部在四条就绪闸门下面那层请求校验：\n\n 两个 pin 的锁定四要素（snapshotVersion / snapshotDigest / sourceCommit / lockMode=exact_digest）\n 与消费者归属 10 条\n 目标制品的 schemaApiVersion 与 linter 证据 2 条\n 影响面的受影响清单、已确认清单与消费者归属比对 3 条\n\n此前 6 个 upgrade 用例全部对着四条就绪闸门（independentGitSourceReady 等各一条真值用例，那部分做得\n完整）。闸门开了之后请求本身长什么样，门禁不看——这 15 条删掉不会红。我今天早些时候说「upgrade 那半边\n做得很扎实」是说窄了：说的是闸门，不是闸门下面的请求面。\n\n补：夹具 25 → 32 例（N21–N27），单测 49 → 53 例。成组声明是有意的——门禁要求声明的原因逐条出现，\n所以一条用例同时钉住四要素，比四条各钉一条更严。补后重算：本域「哪里都没有」归 0。\n\n负向实测：给 N21 加一条不会产生的声明原因 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补覆盖，没有改任何判定；snapshot-upgrade-review.ts 一行未动。\n九个契约包至此「哪里都没有」全部归零。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 53/53、contract-application-contract-registry 32/32。\n\nCo-Authored-By: Claude Opus 5 \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:59:45-07:00"}],"HeadCommit":{"Sha1":"ba752059ee2e67443d3a4b9a1c023c80573bd584","Message":"docs(domain): 注册中心蓝图补记后三笔——第 4—6 条缺陷与现状证据此前不在蓝图里\n\n蓝图是 Catalog 给本模块登记的 evidence 之一，但它的「2026-09-18 规则加固」节只记了\n92a6b8e 那一笔：三条缺陷、数字停在单测 44 例 / 夹具 15 例（正 4 反 11）。同日的\n94366bc / 91216b5 / 5f3f608 没有在蓝图留下任何痕迹，于是蓝图对本模块的描述既滞后\n又不完整。本条只补记录，不改任何规则与 Catalog。\n\n补进去的三条：\n- 第 4 条（94366bc）：四条就绪闸门写作 !context.x，传 \"false\" / 1 / \"no\" / {} 一律\n 判为已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW；现改为 !== true，与同文件本来\n 就严格的 sourceWorktreeDirty !== false 对齐。92a6b8e 只收了入参形状，漏了这四个布尔位。\n- 第 5 条（94366bc + 91216b5）：snapshot-upgrade-review.ts 这 393 行在夹具评估器上零\n 覆盖（规则只有 snapshot / transition / plan），而第 4 条的闸门正在这里；补 upgrade\n 规则后按变异重算 snapshot / transition 侧覆盖，24 个分支里仍有 12 个没有用例走到，\n 再补 N17—N20 到 24/24。\n- 第 6 条（5f3f608）：upgrade 侧接进门禁后 6 个用例全对着四条就绪闸门，闸门下面那层\n 请求校验有 15 条原因码哪里都没有（两个 pin 的锁定四要素与消费者归属 10、目标制品\n schemaApiVersion 与 linter 证据 2、影响面清单比对 3）；补 N21—N27 后归 0。\n\n逐笔证据按各自当时的口径分列，不混成一句。另新增两段：「现状」给本节写定时 clean 树\n上的实跑值；「注意别引错证据」写明 reports/fixtures.latest.json 此刻仍绑 7523bd0、\n本套件记 25 例，5f3f608 之后未回绑，check:evidence 判 EVIDENCE_STALE——现状那行目前\n只有本地实跑支撑，引机器证据前须先重跑回绑。\n\n核验（本分支 clean 树，rebase 到 main 之后）：单测 53/53；check:fixtures 本套件 32 例\n（正 5 / 反 27）0 失败；check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写逐字一致（绑定 7523bd0 之后作用域内 3 个文件变更）；Catalog 四字段与六条 blockers\n逐项核对；runtime/modules/ 下确无本模块；相对链接 ../缺失模块完善清单-2026-09-16.md 可解析；\n表格 8 行各 4 列。\n\nCo-Authored-By: Claude Opus 5 \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:58:17-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/fb755985cca612c5a0ab2a117213fb41689c6521...ba752059ee2e67443d3a4b9a1c023c80573bd584","Len":11}... |