|
31190
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"748492c2a {"Commits":[{"Sha1":"748492c2a1013dbf03b6234f2a85dea73af7e9e6","Message":"chore(reports): fact-pii / gate-flow / ci-mirror 三份回绑 @ bb26784\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑，三份均绑 bb26784 /\nworktreeDirty=false：\n\n fact-pii 21 个 Fact / 116 个字段，0 处 PII 形状与开放结构，25 个自由文本登账待裁\n gate-flow 47 个脚本、35 个有消费入口（新门禁已被推导为在链上），12 个流外且已具名\n ci-mirror 规范化 462 行逐行相同（两份工作流同步加了 check:fact-pii）\n\n后两份的作用域含本轮改动的 package.json 与两份 workflow，故一并回绑。\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:28:00-07:00"},{"Sha1":"bb26784b4f44517b57389d78fbfacac5915a0317","Message":"feat(治理): 补上 check:fact-pii——仓纪律 4 的三件事里，Fact payload 禁 PII 此前无人守\n\n纪律 4 把三件事并列：禁 ^/~（check:pins 守）、禁跨模块 import（check:module-imports 守）、\nFact payload 禁止复制 PII（**没有任何机器在守**）。check:facts 只校验「声明的 Fact 类型是否\n登记」，从不看 payload 里装什么——往某个 Fact schema 加一个 user_email 字段，全链门禁一片绿。\nFact 是跨域流转的事件：个人信息应当留在权威域里按权限查，不随事件复制到每个消费者的\nInbox 与审计链上。\n\n两条判红：\n\n PII_SHAPED_KEY 字段名命中 PII 模式且未显式豁免。按 (^|_)pattern($|_) 的词边界匹配——\n 裸子串会让 principal_id（princ-ip-al）、storage_kind（stor-age）误报，\n 门禁第一天就会被当成坏了而绕过。测试钉住了这一条。\n UNBOUNDED_PAYLOAD 对象缺 properties 或未禁 additionalProperties。这条不是锦上添花：\n 开放结构能装任意键，键名规则对它完全无效，不堵住它前一条只是君子协定。\n\n一条**不判红**：unconstrainedText——无 enum/pattern/format 约束的字符串字段（现有 25 个，\nbuyer_snapshot 这种名字含糊、maxLength 200 的自由文本最典型）。它们确实是 PII 的入口，\n但「这个字段实际装什么」是业务语义。这 25 个字段**全部没有 description**，我写不出可靠的\n豁免理由，编造 25 条登记只会污染治理真源。如实登账进报告，留给人裁定。\n\n判据单源是 governance/fact-pii-rules.json（63 条模式 + 豁免登记），不写死在脚本里——\nPII 形状会随业务扩张，写死就意味着每次扩张都要改门禁代码并重跑它的测试。与 otel-attributes.json\n同思路。豁免按 \u003cFact\u003e:\u003c字段路径\u003e 登记，不是裸键名：同名字段在不同 Fact 里性质可以不同。\n\n扫描面含 contracts/candidates/facts——候选必须一起扫，否则 PII 字段可以先进候选、\n再随批准转正，绕开本门禁。不扫 compatibility/baselines：历史兼容基线按定义不可改，报红也无从修。\n\n接入：根 check 链（check:facts 之后）、两份 CI 工作流（check:ci-mirror 守逐行一致，462 行通过）、\nevidence-scopes 作用域登记。本机实测：21 个 Fact / 116 字段 0 违规；篡改必红两种形态\n（加 PII 字段、改开放结构）均 exit 1，还原后 exit 0；门禁测试 8 例全过。\n\n顺带把纪律 4 里 check:pins 的判据范围写明为 @juhai/* —— 原措辞未限定，读起来像全仓禁 ^/~。\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:26:28-07:00"}],"HeadCommit":{"Sha1":"748492c2a1013dbf03b6234f2a85dea73af7e9e6","Message":"chore(reports): fact-pii / gate-flow / ci-mirror 三份回绑 @ bb26784\n\n经 governance/rebind-reports.mjs 在 HEAD 的临时干净检出里重跑，三份均绑 bb26784 /\nworktreeDirty=false：\n\n fact-pii 21 个 Fact / 116 个字段，0 处 PII 形状与开放结构，25 个自由文本登账待裁\n gate-flow 47 个脚本、35 个有消费入口（新门禁已被推导为在链上），12 个流外且已具名\n ci-mirror 规范化 462 行逐行相同（两份工作流同步加了 check:fact-pii）\n\n后两份的作用域含本轮改动的 package.json 与两份 workflow，故一并回绑。\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:28:00-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/832a54f24c1bf763ba06cf5513f7f7bd53b28e45...748492c2a1013dbf03b6234f2a85dea73af7e9e6","Len":2}...
|
1789774131
|
Edit
Delete
|
|
31189
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"832a54f24 {"Commits":[{"Sha1":"832a54f24c1bf763ba06cf5513f7f7bd53b28e45","Message":"docs(部署): 记录补 §14.6——D-11 闭环，forward_auth 的 200 分支第一次在服务端实测到\n\n三个分支实测（网关 :58080）：无令牌 401 / 伪造令牌 401 / **真实 IdP 令牌 200**；\n对照同一令牌直连容器 :53001 也是 200。返回体的 mode=fail-closed 与四个 ledger 端口\n确认打到的是容器而不是 dev 进程（:3101 那条链回的是 mode=local）。\n\nD-11 此前卡在一个操作顾虑而不是技术障碍：令牌只在浏览器里，搬进 shell 就会经过对话记录。\n这次用一次性本地接收端绕开——只听 127.0.0.1:45999、收到第一个 POST 就落盘（600）并自毁，\n页面把令牌 POST 过去（Content-Type: text/plain 在 CORS 安全列表内，不触发预检），shell 从\n文件读，用完 shred。方法一并写进记录，免得下次重新想。\n\n同轮把 D-11 从「未闭环」表摘掉（闭环项留在未闭环表里是自相矛盾），并把 §14 开头\n「后者只关掉一半」收窄为：服务端语义与服务端直连都已验证，唯一仍测不到的是浏览器跨源\n带令牌那条路，而它测不到的原因是预检带不了令牌（§14.4），属设计使然、不是缺证据。\n\n也写明这个令牌验不了 D-13：工作台客户端 scope 只有 openid profile，没有 platform:ops，\nevaluateOpsAccess 第一关就以 OPS_SCOPE_REQUIRED 挡下，到不了 admins.has(auth.subject)。\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:26:00-07:00"},{"Sha1":"4df190ddfc1fdc7d3fe7ac71f4094a1641484eca","Message":"test(contracts,runtime): 把最后 9 条「仅单测」钉进夹具——两档归零，17 套件 458 例\n\n覆盖度探针的「都没有」在同日已全部归零（契约包九个域 + 运行时模块侧 4 条由 91ae216 补齐），\n但「仅单测」还剩 9 条。逐条看过，它们都不属于该工具自述里 ③ 说的两类豁免（基线闸门登记位\n*_BASELINE_NOT_READY / G3 / G5、演进对比类），而是普通字段守卫——守卫删掉只有 contracts:test\n或模块单测会红，门禁不会：\n\n module-permission APP_ID_REQUIRED（preflight 缺 appId）\n cross-domain-workflow WORKFLOW_IDENTITY_INVALID（定义缺 id）\n WORKFLOW_SCOPE_VERSION_INVALID（计划请求缺 scopeVersion）\n collaboration-messaging MESSAGE_CONTEXT_REQUIRED（消息缺 tenantId）\n OWNER_COMMAND_REQUIRED（动作卡缺 ownerDomain）\n notification-webhook WEBHOOK_SOURCE_EVENT_ID_REQUIRED\n WEBHOOK_TEMPLATE_VERSION_INVALID\n WEBHOOK_VARIABLES_INVALID\n\n跨域流程那两条是本会话同日第一条补强（13c7eb7）自己新增/收紧的判定，当时只补了单测没进夹具，\n本轮补齐——自己留的口子自己收。\n\n构造用例时踩到的坑：自动「从同规则里挑最完整的一条用例作底」会挑到已经带别的缺陷的负例，\n产出里混进无关原因码（实测跨域流程那条挑到了「两步共用幂等键」、IM 那条挑到了「senderType 大小写错」）。\n改为一律从该规则的正例派生、只做一处改动，每例产出单一原因码；reasons 按规则真实返回值逐字回填，\n不用前缀蒙混。\n\n覆盖：module-permission 10 → 11、cross-domain-workflow 16 → 18、collaboration-messaging 42 → 46、\nnotification-webhook 39 → 42；根链 check:fixtures 17 套件 458 例 0 失败 0 不可用。\n模块夹具与 test/negative/*.fixtures.test.ts 同源（it.each 直接遍历夹具文件），module-permission 的\n用例数随夹具自动同步，pnpm --dir runtime --filter @juhai/module-permission test 51/51。\n\n结果：15 个套件的「都没有」与「仅单测」两档现均为 0。口径与数字同步写进仓根 CLAUDE.md 那一段，\n并留了一句「后续新增规则请照此维持，或在本行注明保留理由」。\n\n证据：node --test contracts/test/*.test.mjs 404/404、typecheck 绿、check:fixtures 17 套件 458 例 0 失败。\n负向实测：把 IM 新增那条的声明改成 SENDER_TYPE_INVALID → 门禁 exit 1 并点名该例\n（reasons=[\"OWNER_COMMAND_REQUIRED\"]），还原后 exit 0。\n工作树另有并行会话的 check-fact-pii 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-18T16:23:53-07:00"},{"Sha1":"2f9175b43d249cdf68a65071a9cba4a5c214c0f1","Message":"test(contracts): 会话追加的 STALE 与 REJECT 两个出口没钉——订正我把它判成探针误报的结论\n\nfixture-coverage 把 collaboration-messaging 的 REJECT 与 STALE 报成「仅单测」，我一度判为探针把\n「决策 kind」误当原因码统计、准备去改探针。判错了。\n\n这套 kind-as-reason 是评估器有意的约定：同一份夹具里 DUPLICATE / GAP / NOT_MEMBER /\nTENANT_MISMATCH / CONVERSATION_BINDING_REQUIRED / CONVERSATION_MISMATCH / STATE_INVALID 七个出口\n都是这么声明的，notification-webhook 的 DUPLICATE / DLQ 同理。探针的分类是对的，该补的是夹具。\n\nclassifyConversationAppend 有 10 个出口，夹具此前钉了 7 个，缺的两个：\n STALE incomingSequence 不前移——乱序或重放（conversation-message.ts:76）\n REJECT 消息自身 preflight 就没过（:67）\n前者是「重放的消息不能覆盖已处理序列」这条纪律在门禁上的唯一出口。\n\n补：夹具 42 → 44 例（N39 / N40）。该域「仅单测」由 4 降至 2。\n\n负向实测：把 N39 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n教训写进 SOURCE.md：探针报出来的要逐条回源码核，不能因为「看着像 kind 不像 code」就判成误报——\n这套契约包里 kind 就是 code。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 32/32、contract-collaboration-messaging 44/44。\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:22:38-07:00"}],"HeadCommit":{"Sha1":"832a54f24c1bf763ba06cf5513f7f7bd53b28e45","Message":"docs(部署): 记录补 §14.6——D-11 闭环，forward_auth 的 200 分支第一次在服务端实测到\n\n三个分支实测（网关 :58080）：无令牌 401 / 伪造令牌 401 / **真实 IdP 令牌 200**；\n对照同一令牌直连容器 :53001 也是 200。返回体的 mode=fail-closed 与四个 ledger 端口\n确认打到的是容器而不是 dev 进程（:3101 那条链回的是 mode=local）。\n\nD-11 此前卡在一个操作顾虑而不是技术障碍：令牌只在浏览器里，搬进 shell 就会经过对话记录。\n这次用一次性本地接收端绕开——只听 127.0.0.1:45999、收到第一个 POST 就落盘（600）并自毁，\n页面把令牌 POST 过去（Content-Type: text/plain 在 CORS 安全列表内，不触发预检），shell 从\n文件读，用完 shred。方法一并写进记录，免得下次重新想。\n\n同轮把 D-11 从「未闭环」表摘掉（闭环项留在未闭环表里是自相矛盾），并把 §14 开头\n「后者只关掉一半」收窄为：服务端语义与服务端直连都已验证，唯一仍测不到的是浏览器跨源\n带令牌那条路，而它测不到的原因是预检带不了令牌（§14.4），属设计使然、不是缺证据。\n\n也写明这个令牌验不了 D-13：工作台客户端 scope 只有 openid profile，没有 platform:ops，\nevaluateOpsAccess 第一关就以 OPS_SCOPE_REQUIRED 挡下，到不了 admins.has(auth.subject)。\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:26:00-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/2156538deab81264dd796a4ed668509522dbff45...832a54f24c1bf763ba06cf5513f7f7bd53b28e45","Len":3}...
|
1789773970
|
Edit
Delete
|
|
31188
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"2156538de {"Commits":[{"Sha1":"2156538deab81264dd796a4ed668509522dbff45","Message":"docs(部署): D-13 归属改为与 D-4 一并验，并写明为什么不先单独改\n\nOwner 2026-09-18 定：等 feat/identity-canonical-tenants 合并后连 D-4 一起验。\n\n归属列同时写下理由，而不只写「等」。D-13 看上去是两行就能改完的配置错误\n（.secrets 里换一个 UUID + 重建容器），容易被顺手改掉再顺手记一句「已修复」——\n但单独改它最多验到「守卫这关过了」：M3 写路径仍会挂在 D-4 的 CANONICAL_TENANT_REQUIRED，\n证不出「受控执行面对 IdP 令牌可用」。把这句话留在表里，是为了让下一个人别拿\n半条证据当整条用。\n\n依赖关系现在三处一致：§6 D-4、§14.5 D-13、未合并分支登记-2026-09-15.md 的\nfeat/identity-canonical-tenants 行。\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:22:14-07:00"}],"HeadCommit":{"Sha1":"2156538deab81264dd796a4ed668509522dbff45","Message":"docs(部署): D-13 归属改为与 D-4 一并验，并写明为什么不先单独改\n\nOwner 2026-09-18 定：等 feat/identity-canonical-tenants 合并后连 D-4 一起验。\n\n归属列同时写下理由，而不只写「等」。D-13 看上去是两行就能改完的配置错误\n（.secrets 里换一个 UUID + 重建容器），容易被顺手改掉再顺手记一句「已修复」——\n但单独改它最多验到「守卫这关过了」：M3 写路径仍会挂在 D-4 的 CANONICAL_TENANT_REQUIRED，\n证不出「受控执行面对 IdP 令牌可用」。把这句话留在表里，是为了让下一个人别拿\n半条证据当整条用。\n\n依赖关系现在三处一致：§6 D-4、§14.5 D-13、未合并分支登记-2026-09-15.md 的\nfeat/identity-canonical-tenants 行。\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:22:14-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/4f36e22448f8fdf4611af3f5fa34305ae58769ef...2156538deab81264dd796a4ed668509522dbff45","Len":1}...
|
1789773742
|
Edit
Delete
|
|
31187
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"4f36e2244 {"Commits":[{"Sha1":"4f36e22448f8fdf4611af3f5fa34305ae58769ef","Message":"test(contracts): 注册中心 plan 把 BLOCKED 判成了放行——裁决没批、候选自带 blocker，夹具都说通过\n\n前一轮（91216b5）补了入参体检的门禁覆盖。本轮按「公开方法 × 出口」再盘，查出的是\ngovernance/fixture-coverage.mjs 按设计查不到的一类：它只变异夹具已有用例的字段，\n夹具从没构造过的入口不会被发现。三个规则文件零改动，只动夹具评估器的可见性。\n\n1. plan 把 BLOCKED 判成放行。评估器原判据是 `\"reasons\" in r`；ManifestAdmissionResult 三个出口里\n BLOCKED 携带的是 blockers 不是 reasons，于是返回空数组 = ACCEPT。实测两种 BLOCKED 都被夹具判为通过：\n 候选自带 blockedBy（[\"CHG-001\"]）、所需裁决仍 pending（[\"DECISION_PENDING:DEC-011\"]）——\n 而它们明写着 activationAllowed: false / registryWriteAllowed: false。\n 同一文件下面的 upgrade 规则本来就写对了（... : [...d.blockers]），plan 与自己的兄弟规则不一致。\n\n2. 没有任何一条 plan 用例带合法快照。整条「有策略」分支（清单字段校验、裁决闸门、READY_FOR_REVIEW）\n 在门禁上根本不存在，唯一那条 N05 是「无策略即拒」。\n\n3. refresh 没有夹具规则：planner 第三个公开方法零门禁覆盖。\n\n修完之后覆盖度一度变差，这是对的。补上带快照的 plan 用例后，此前够不着的清单校验分支第一次被变异探针\n走到，fixture-coverage 随即报出 12 条「夹具与单测都没有」（SERVICES_REQUIRED / PERMISSIONS_REQUIRED /\nPRODUCED_FACTS_REQUIRED / CONSUMED_FACTS_REQUIRED / DEPENDENCIES_REQUIRED / MANIFEST_BLOCKERS_REQUIRED /\nMANIFEST_KIND_INVALID / OWNER_DOMAIN_REQUIRED 与 refresh 侧四条）——它们一直都在，只是之前没人能看见。\n连同 4 条「仅单测」一并钉住后回到 0 / 0。\n\n另修一处本轮自己的松懈：N42 的 reasons 写成了前缀 MANIFEST，任何 MANIFEST* 都能匹配，已改为确切原因码。\n\n一处明写不覆盖：plan() 的 DECISION_MISSING:\u003cid\u003e 按当前控制流不可达——缺一条必需裁决在 normalizePolicy\n装载时就抛 MANIFEST_DECISION_STATUS_INVALID:\u003cid\u003e，运行时工厂退回 deny-all。N39 钉这条真实路径，\nN49 钉装载侧原因码，不为不可达分支造用例。\n\n覆盖：夹具 41 → 70 例（正 7 / 反 63），定向测试 59 → 63 例，前一轮断言一条未改。\n变异探针（70 例 × 14 种脏值）38374 个变异点、0 处抛异常。\n\n未做（越界）：C01.04 五个关键应用的固定版本消费（今 2 个 pin）与 C01.06 只读目录查询入口属接线，\n不在本轮；Catalog 登记未动。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 404/404、该套件夹具 70/70 失败 0、fixture-coverage 该套件 0 / 0。\n负向实测：把 N37 的 blocker 声明改成 CHG-999 → 门禁 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:21:01-07:00"}],"HeadCommit":{"Sha1":"4f36e22448f8fdf4611af3f5fa34305ae58769ef","Message":"test(contracts): 注册中心 plan 把 BLOCKED 判成了放行——裁决没批、候选自带 blocker，夹具都说通过\n\n前一轮（91216b5）补了入参体检的门禁覆盖。本轮按「公开方法 × 出口」再盘，查出的是\ngovernance/fixture-coverage.mjs 按设计查不到的一类：它只变异夹具已有用例的字段，\n夹具从没构造过的入口不会被发现。三个规则文件零改动，只动夹具评估器的可见性。\n\n1. plan 把 BLOCKED 判成放行。评估器原判据是 `\"reasons\" in r`；ManifestAdmissionResult 三个出口里\n BLOCKED 携带的是 blockers 不是 reasons，于是返回空数组 = ACCEPT。实测两种 BLOCKED 都被夹具判为通过：\n 候选自带 blockedBy（[\"CHG-001\"]）、所需裁决仍 pending（[\"DECISION_PENDING:DEC-011\"]）——\n 而它们明写着 activationAllowed: false / registryWriteAllowed: false。\n 同一文件下面的 upgrade 规则本来就写对了（... : [...d.blockers]），plan 与自己的兄弟规则不一致。\n\n2. 没有任何一条 plan 用例带合法快照。整条「有策略」分支（清单字段校验、裁决闸门、READY_FOR_REVIEW）\n 在门禁上根本不存在，唯一那条 N05 是「无策略即拒」。\n\n3. refresh 没有夹具规则：planner 第三个公开方法零门禁覆盖。\n\n修完之后覆盖度一度变差，这是对的。补上带快照的 plan 用例后，此前够不着的清单校验分支第一次被变异探针\n走到，fixture-coverage 随即报出 12 条「夹具与单测都没有」（SERVICES_REQUIRED / PERMISSIONS_REQUIRED /\nPRODUCED_FACTS_REQUIRED / CONSUMED_FACTS_REQUIRED / DEPENDENCIES_REQUIRED / MANIFEST_BLOCKERS_REQUIRED /\nMANIFEST_KIND_INVALID / OWNER_DOMAIN_REQUIRED 与 refresh 侧四条）——它们一直都在，只是之前没人能看见。\n连同 4 条「仅单测」一并钉住后回到 0 / 0。\n\n另修一处本轮自己的松懈：N42 的 reasons 写成了前缀 MANIFEST，任何 MANIFEST* 都能匹配，已改为确切原因码。\n\n一处明写不覆盖：plan() 的 DECISION_MISSING:\u003cid\u003e 按当前控制流不可达——缺一条必需裁决在 normalizePolicy\n装载时就抛 MANIFEST_DECISION_STATUS_INVALID:\u003cid\u003e，运行时工厂退回 deny-all。N39 钉这条真实路径，\nN49 钉装载侧原因码，不为不可达分支造用例。\n\n覆盖：夹具 41 → 70 例（正 7 / 反 63），定向测试 59 → 63 例，前一轮断言一条未改。\n变异探针（70 例 × 14 种脏值）38374 个变异点、0 处抛异常。\n\n未做（越界）：C01.04 五个关键应用的固定版本消费（今 2 个 pin）与 C01.06 只读目录查询入口属接线，\n不在本轮；Catalog 登记未动。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 404/404、该套件夹具 70/70 失败 0、fixture-coverage 该套件 0 / 0。\n负向实测：把 N37 的 blocker 声明改成 CHG-999 → 门禁 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:21:01-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd...4f36e22448f8fdf4611af3f5fa34305ae58769ef","Len":1}...
|
1789773705
|
Edit
Delete
|
|
31186
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"73d03c062 {"Commits":[{"Sha1":"73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd","Message":"docs(runbook): 补 §2.1——demo 租户重建的完整应对，含「哪一列」这个会咬人的细节\n\nidentity 库被清掉（db.sh --fresh / 手工重建 / 从早于 09-16 的 dump 恢复）之后，租户、\n管理员、应用与两个 OIDC 客户端会一起没——它们只在库里，不在任何配置文件里；而管理员\n明文口令全机只有 .secrets/idp-demo-admin.txt 一份（库存散列，备份 dump 里也搜不到明文）。\n\n本节写清四件此前只能靠翻代码才知道的事：两个 bootstrap 各自的一次性约束\n（TENANT_SLUG_CONFLICT / ADMINISTRATION_ALREADY_BOOTSTRAPPED）与「库还在时只能走管理 API」；\n两条 bootstrap 的确切载荷（按 zod schema 核对，password ≥ 12、redirectUri 只收 https 或\nloopback）；工作台客户端为什么必须先有人工登录才能登记，且不得给它 idp:manage；以及\n四个 UUID 换新后要同步的四处配置，每处配上漏掉时的具体症状。\n\n其中 PLATFORM_OPS_ADMIN_SUBJECTS 填 users.subject 而不是 users.id——现存 dev 值就是错的，\n见 dev 部署记录 D-13。改 PLATFORM_OPS_* 必须重建容器，只 restart 不带新环境。\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:18:51-07:00"},{"Sha1":"3ed10d6c9473aca115f12b9f32aac435aa79e3ee","Message":"docs(部署): 登记 D-13——PLATFORM_OPS_ADMIN_SUBJECTS 的 dev 值填的是 users.id，不是令牌里的 sub\n\n判定链是 token-verifier.ts:136（subject = payload.sub）→ AuthContext.subject →\nplatform-ops.adapter.ts:22（admins.has(auth.subject)），而 IdP 访问令牌的 sub 取自\nusers.subject。当前 dev 配的是该管理员的 users.id（4782bc0d-…），实际 sub 是\ne6783482-…，两者不同——**IdP 签发的管理员令牌打受控执行面会 403 OPS_FORBIDDEN**。\n\nsub 是从 §14 那次真实登录拿到的令牌里解出来的，不是推断。之所以此前没暴露：§5\n「三重守卫齐全 200」的取证用的是手工签发的合成令牌，值自然与白名单对得上；真实 IdP\n令牌这条路是 §14 才第一次走通的。\n\n本轮只登记不改：订正它要动仓外 .secrets 并重建容器，且正向验证需要再走一次人工登录。\n重建 demo 租户时该填哪一列，写在 runbook §2.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-18T16:18:43-07:00"},{"Sha1":"91ae21671f2d958ef5e228e525cc931a8e586d40","Message":"test(runtime): 补掉覆盖度探针在两个模块查出的 4 条——夹具与单测都没走到\n\ngovernance/fixture-coverage.mjs 落仓后第一次全量扫描（15 个套件）查出的 4 条，全在运行时模块侧：\n\n module-permission ACTION_REQUIRED / RESOURCE_REQUIRED / RESOURCE_ID_REQUIRED\n module-audit AUDIT_COMMIT_MODE_INVALID\n\npermission 的 preflight 已经钉了 tenant / request / trace / actor / scopeVersion 五项（N01–N03），\n唯独「资源三件套」一条用例都没有——那三条守卫删掉，check:fixtures 与模块单测都不会红。\naudit 的 commit 模式同理：mode 不在册时拒绝这条判定此前无人走到。\n\n补：permission 夹具 9 → 10 例（N08，三条原因一条用例同时钉住，门禁要求逐条出现）、\naudit 26 → 27 例（N18，mode=\"best-effort\" 这种看着合理但不在册的取值）。\n模块夹具与 test/negative/*.fixtures.test.ts 同源——单测 it.each 直接遍历夹具文件，所以加夹具用例\n即同时加单测，本次没有另写测试代码。\n\npermission 的夹具是 prettier 按宽度折行的混合风格，JSON round-trip 会把整份重排成 180 行噪音；\n改用文本插入，diff 保持 +8/-1。\n\n负向实测：把 N08 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n补后 15 个套件的「夹具与单测都没有」全为 0，CLAUDE.md 同步改口。\n\n证据：module-permission 50/50、module-audit 81/81（vitest 无库单测）；\ncheck:fixtures 两套件 37/37；fixture-coverage 全量 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-18T16:18:36-07:00"}],"HeadCommit":{"Sha1":"73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd","Message":"docs(runbook): 补 §2.1——demo 租户重建的完整应对，含「哪一列」这个会咬人的细节\n\nidentity 库被清掉（db.sh --fresh / 手工重建 / 从早于 09-16 的 dump 恢复）之后，租户、\n管理员、应用与两个 OIDC 客户端会一起没——它们只在库里，不在任何配置文件里；而管理员\n明文口令全机只有 .secrets/idp-demo-admin.txt 一份（库存散列，备份 dump 里也搜不到明文）。\n\n本节写清四件此前只能靠翻代码才知道的事：两个 bootstrap 各自的一次性约束\n（TENANT_SLUG_CONFLICT / ADMINISTRATION_ALREADY_BOOTSTRAPPED）与「库还在时只能走管理 API」；\n两条 bootstrap 的确切载荷（按 zod schema 核对，password ≥ 12、redirectUri 只收 https 或\nloopback）；工作台客户端为什么必须先有人工登录才能登记，且不得给它 idp:manage；以及\n四个 UUID 换新后要同步的四处配置，每处配上漏掉时的具体症状。\n\n其中 PLATFORM_OPS_ADMIN_SUBJECTS 填 users.subject 而不是 users.id——现存 dev 值就是错的，\n见 dev 部署记录 D-13。改 PLATFORM_OPS_* 必须重建容器，只 restart 不带新环境。\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:18:51-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/45a6bd523973c97e88f31faa12604773150cec87...73d03c062f82dc9e8b9a0e66e6e973ca9aca54cd","Len":3}...
|
1789773540
|
Edit
Delete
|
|
31185
|
5
|
9
|
5
|
116
|
0
|
0
|
refs/tags/packages-v1.0.0-rc.4
|
0
|
{"Commits":null,"HeadCommit":{" {"Commits":null,"HeadCommit":{"Sha1":"557a95c4422518cf3d9fdff04d261114ab389169","Message":"chore(release): 三包推到 1.0.0-rc.4——clients 扫描面与这轮 contracts 硬化一起上车\n\n发 rc.4 的直接动因：e61bfcf 给 check:module-imports 补的 clients 扫描面与两条规则\n（CLIENT_FORBIDDEN_IMPORT / ESCAPES_CLIENT）不在任何已发布版本里，而 @juhai/governance\n的 rc.0—rc.3 已全部被占用，按 G-12 的边界只能往前发下一个 RC。\n\n随车发出的远不止这些。自 rc.3 的源 036a308 起：\n contracts 147 个文件 / 51 条提交（九域规则的入参体检与门禁覆盖那一大轮）\n governance 61 个文件 / 48 条提交\n runtime/clients/fact 5 个文件 / 5 条提交\n三包版本一致，符合 CL-5「一次发布 = 一个 tag = 一组同版本包」；包目录单源仍是\ngovernance/release-packages.json。\n\n通道：本地旁路（G-12 第三次使用）。CI 正道 2026-09-18 实测双重不可用——GitHub Actions\n最近三次 run 全部 failure（账户计费，最新 35215270797 即 CLAUDE.md 记的那条注解），\n且 GitHub 镜像落后 237 条提交、因分支保护的 required check 跑不起来而推不动，\ne61bfcf 的代码根本不在 GitHub 上。按 G-12 边界，rc.4 同样不得宣称经过发布门禁验证。\n\n本次按 CL-5 补打 tag packages-v1.0.0-rc.4——rc.2 / rc.3 两趟都漏了这一步。\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:08:15-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/0000000000000000000000000000000000000000...557a95c4422518cf3d9fdff04d261114ab389169","Len":0}...
|
1789773457
|
Edit
Delete
|
|
31184
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"45a6bd523 {"Commits":[{"Sha1":"45a6bd523973c97e88f31faa12604773150cec87","Message":"docs(发布): 当场记录 rc.4 列车——三包已发，tag 这趟补上，并写清验证的真实范围\n\nrc.4 三包（contracts / governance / client-fact）2026-09-18 经本地旁路发出，源 557a95c，\nRegistry 实查确认在架、三包均 registry integrity verified。与前两趟不同，本次是当场记录。\n\n这趟补上了 CL-5 要求的 tag packages-v1.0.0-rc.4——rc.2 / rc.3 都漏了这一步，\nprovenance.tag 因此第一次不是 null。构建与发布在 .worktrees/rc4-release 的 detached\n干净检出里做，所以 worktreeDirty:false 是真的（主检出当时有并行会话在改 contracts）。\n\n记录里写清了两件容易被夸大的事：\n\n1. rc.4 远不止触发它的那两条 clients 规则。自 rc.3 源 036a308 起，contracts 147 文件 /\n 51 提交、governance 61 文件 / 48 提交随车发出，包含九域规则入参体检那一整轮。\n2. 发布前只跑了 check:fixtures（17 套件 394 例）与 check:module-imports（396 文件），\n 退出码均 0；**完整 pnpm check 是发布后补跑的**（真实退出码 0，check:evidence partial：\n 36 新鲜 / 5 过期，过期项均属其他任务 WIP）。按 G-12 边界，这些都不构成阶段门证据。\n\nCLAUDE.md 的 contracts 条目同步推到 rc.4，并顺手修掉一处自相矛盾：该条前半句还写着\nrc.2 源 eb3cf2c，而后半句已说明按 provenance 订正为 6d3900a。\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:17:05-07:00"},{"Sha1":"df90a19192218b2b65c7cde7326968ac81d03de0","Message":"chore(reports): check:module-imports 回绑 @ 557a95c\n\n在 .worktrees/rc4-release 的干净检出（detached 557a95c = packages-v1.0.0-rc.4）里重跑，\n绑 557a95c / worktreeDirty=false，扫描 396 个源文件、0 处违规。\n\n同批在该检出里跑的 check:fixtures 也是 0 失败（17 套件 394 例），但那份报告**没有提交**：\nfixtures 的证据作用域含 contracts，而并行会话正在高频改 contracts，绑 557a95c 的快照\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-18T16:14:43-07:00"},{"Sha1":"0b3dab61a1072d682d5a921e00025f46431c95d3","Message":"test(contracts): decideProviderOutcome 在门禁上零覆盖——退避被供应商压短这条修过的规则，没人盯着它别被改回去\n\n前两轮收了入参硬化（c190a6a）与请求体检／出站 allowlist 的用例（d950aa2）。本轮按「公开方法 × 出口」\n重新盘了一遍，两类空白。两个规则文件零改动，只动夹具评估器、夹具与测试。\n\n1. decideProviderOutcome 在门禁上零覆盖。planner 四个公开方法（status / plan /\n decideProviderOutcome / refresh）里，夹具只有 plan 与 refresh 两条规则。既有的 provider 规则走的是\n 独立函数 classifyProviderOutcome——它只看状态码与次数，不认路由策略：退避基数 baseBackoffSeconds、\n 上界 maximumBackoffSeconds、Retry-After 的钳制全在 planner 方法里，夹具一条都看不到。\n 而那里恰好有一条修过的规则：Retry-After 可以把退避拉长到策略上界，但不能把批准过的退避拉短\n （原实现 min(maximumBackoff, retryAfter)，供应商回一个 Retry-After: 0 即可令退避清零）。\n 规则改对了，门禁却看不见它有没有被改回去。\n\n 新增 route-outcome 规则，并把 RETRY 连同算出来的秒数一并返回（RETRY:\u003c秒\u003e）——否则夹具只能看见\n 「重试了」，看不见「退避是不是被压短了」。负向实测：把 N33 的声明由 RETRY:20 改成 RETRY:10，\n 门禁 exit 1 并点名该例，秒数确实被钉住。\n\n2. plan() 八条出口此前门禁上没走过：请求非对象、目的地不在册、effectId 非请求派生、尝试次数越界、\n 未授权重放、模板版本未批准、变量越出模板 allowlist、敏感载荷落在未批准敏感数据的模板上。\n 构造用例时注意 effectId = tenant:sourceEvent:destination:template:v\u003c版本\u003e 是派生值，改 templateVersion\n 必须同步改 effectId，否则先撞 WEBHOOK_EFFECT_ID_MISMATCH，测不到目标那条。\n\n一处预期被实测推翻，按实现订正：retryAfterSeconds 超出 [0, 3600] 不是「钳到上界」，而是整条回执判\nPROVIDER_OUTCOME_INVALID。两条边界各钉一例（3600 → RETRY:60；9999 → 拒）。\n\n覆盖：夹具 25 → 39 例（正 4 / 反 35）；定向测试 28 → 30 例，补上唯一一条「门禁有、单测没有」的\nWEBHOOK_TEMPLATE_NOT_APPROVED 以及 Retry-After 取值域。前两轮断言一条未改。\n变异探针（39 例真实 payload × 14 种脏值）14560 个变异点、0 处抛异常。\n\n未做（越界）：模板审批流、多渠道 Provider、签名防重放、渠道切换仍不在本仓，C12 按缺失模块完善清单\n仍是「裁决」；Catalog 登记未动（notification-webhook 仍 module_e2、code_truth 指向工单仓）。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 400/400、contract-notification-webhook 夹具 39/39 失败 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:13:04-07:00"},{"Sha1":"0b30631d9c45ceff29558ddf821e6cb5a5c7cd00","Message":"docs(治理): 夹具覆盖度的算法写进 CLAUDE.md，并把探针从 /tmp 落进仓里\n\n今天九个契约包的门禁空白有一半是靠一个临时脚本找出来的，光看用例名一个也发现不了。方法写进文档\n而脚本留在 /tmp，下次没人跑得起来——所以一并落仓。\n\ngovernance/fixture-coverage.mjs（诊断，不是门禁：不写报告、不进 pnpm check）：\n由 governance/fixtures/*.suite.json 驱动，新增套件自动纳入，不写死域名单。拿每个夹具用例的真实\npayload 逐个叶子字段换脏值，走门禁自己的 evaluateFixturePayload 入口，收集规则实际吐出的原因码，\n分三档——已钉（被某条用例的 reasons 声明过，守卫回退必红）/ 仅单测 / 都没有（守卫删掉任何一道都\n不会红）。--list 连「仅单测」一并列出，--json 出机器格式。\n\n三条读法都写进了脚本抬头与 CLAUDE.md：散文式校验消息不是稳定码，单列「非码」不计缺口；插值原因码\n词汇表无界，按前缀过滤；「仅单测」不等于缺陷——§5 迁入时的设计就是夹具只固定失败关闭一侧。\n\n落仓后第一次全量扫描立刻有新发现：九个契约包「都没有」全为 0（今天收口的结果），但运行时模块侧\n还有 4 条——module-permission 的 ACTION_REQUIRED / RESOURCE_REQUIRED / RESOURCE_ID_REQUIRED、\nmodule-audit 的 AUDIT_COMMIT_MODE_INVALID。已在 CLAUDE.md 记为尚未处理；那是 runtime/ 的纪律范围，\n本次不动。\n\n证据：在仅含本提交改动的导出树上跑通（模块未构建时按 unavailable 跳过，与 check:fixtures 同因）。\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:12:09-07:00"}],"HeadCommit":{"Sha1":"45a6bd523973c97e88f31faa12604773150cec87","Message":"docs(发布): 当场记录 rc.4 列车——三包已发，tag 这趟补上，并写清验证的真实范围\n\nrc.4 三包（contracts / governance / client-fact）2026-09-18 经本地旁路发出，源 557a95c，\nRegistry 实查确认在架、三包均 registry integrity verified。与前两趟不同，本次是当场记录。\n\n这趟补上了 CL-5 要求的 tag packages-v1.0.0-rc.4——rc.2 / rc.3 都漏了这一步，\nprovenance.tag 因此第一次不是 null。构建与发布在 .worktrees/rc4-release 的 detached\n干净检出里做，所以 worktreeDirty:false 是真的（主检出当时有并行会话在改 contracts）。\n\n记录里写清了两件容易被夸大的事：\n\n1. rc.4 远不止触发它的那两条 clients 规则。自 rc.3 源 036a308 起，contracts 147 文件 /\n 51 提交、governance 61 文件 / 48 提交随车发出，包含九域规则入参体检那一整轮。\n2. 发布前只跑了 check:fixtures（17 套件 394 例）与 check:module-imports（396 文件），\n 退出码均 0；**完整 pnpm check 是发布后补跑的**（真实退出码 0，check:evidence partial：\n 36 新鲜 / 5 过期，过期项均属其他任务 WIP）。按 G-12 边界，这些都不构成阶段门证据。\n\nCLAUDE.md 的 contracts 条目同步推到 rc.4，并顺手修掉一处自相矛盾：该条前半句还写着\nrc.2 源 eb3cf2c，而后半句已说明按 provenance 订正为 6d3900a。\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:17:05-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d...45a6bd523973c97e88f31faa12604773150cec87","Len":4}...
|
1789773436
|
Edit
Delete
|
|
31183
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ec0f1c04d {"Commits":[{"Sha1":"ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d","Message":"docs(部署): 记录补 §14——工作台登录第一次真正走通，以及 200 分支为什么在浏览器里测不了\n\n同源托管记录 §6 那一行挂着「工作台 OIDC 公开客户端仍未在身份模块登记」，以及由此导致的\n「forward_auth 的 200 分支未实测」。本节走通前者，后者只关掉一半。\n\n卡住的不是配置。登录页显示「缺配置」容易读成填个环境变量就行，实际是 demo 租户里\n根本没有回调为 http://localhost:3010/callback/ 的客户端；而登记它要过 IdpManagementGuard\n（idp:manage ∧ 管理客户端 ∧ 活跃管理员授权），也就是必须先有人以管理员身份走完托管登录——\n那一步要人工提交口令，这正是它一直没做的原因。\n\n登记出来的客户端只给 openid profile，不给 idp:manage：登记用的是 demo-console 的管理权，\n不是把管理权发给一个跑在浏览器里的公开客户端。\n\n实测走通全链（作用域 = 本机 dev，证据等级 = 运行态链路 + 真实浏览器）：SSO 未再要口令、\n同意屏、换令牌、令牌只落 sessionStorage 两键（无 localStorage 无 cookie）、登录页显示出\n与库中 admin@demo.test 一致的 subject（即没踩同源托管记录的 D-10）、userinfo 200、\n带令牌读 modules 200。userinfo 正是 forward_auth 的校验端点，服务端语义上 200 分支成立。\n\n但浏览器跨源那一半关不掉，且是设计使然：带 Authorization 的跨源请求先发 OPTIONS 预检，\n预检按规范不带该头，forward_auth 收到无令牌的 OPTIONS 就 401，真请求发不出去。终态是\n同源托管故无影响，但 :3010 这个 dev 形态永远走不通网关。这与 §11「两个键、两个进程」\n是同一族问题的两面：跨源这件事，代理和网关都不替你解决。\n\n新登记 D-11（服务端直连验 200 分支未做——本轮令牌只在浏览器里，不把有效 bearer 打进\n命令行与日志）与 D-12（登录后顶栏的 hydration 告警）。\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:11:45-07:00"}],"HeadCommit":{"Sha1":"ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d","Message":"docs(部署): 记录补 §14——工作台登录第一次真正走通，以及 200 分支为什么在浏览器里测不了\n\n同源托管记录 §6 那一行挂着「工作台 OIDC 公开客户端仍未在身份模块登记」，以及由此导致的\n「forward_auth 的 200 分支未实测」。本节走通前者，后者只关掉一半。\n\n卡住的不是配置。登录页显示「缺配置」容易读成填个环境变量就行，实际是 demo 租户里\n根本没有回调为 http://localhost:3010/callback/ 的客户端；而登记它要过 IdpManagementGuard\n（idp:manage ∧ 管理客户端 ∧ 活跃管理员授权），也就是必须先有人以管理员身份走完托管登录——\n那一步要人工提交口令，这正是它一直没做的原因。\n\n登记出来的客户端只给 openid profile，不给 idp:manage：登记用的是 demo-console 的管理权，\n不是把管理权发给一个跑在浏览器里的公开客户端。\n\n实测走通全链（作用域 = 本机 dev，证据等级 = 运行态链路 + 真实浏览器）：SSO 未再要口令、\n同意屏、换令牌、令牌只落 sessionStorage 两键（无 localStorage 无 cookie）、登录页显示出\n与库中 admin@demo.test 一致的 subject（即没踩同源托管记录的 D-10）、userinfo 200、\n带令牌读 modules 200。userinfo 正是 forward_auth 的校验端点，服务端语义上 200 分支成立。\n\n但浏览器跨源那一半关不掉，且是设计使然：带 Authorization 的跨源请求先发 OPTIONS 预检，\n预检按规范不带该头，forward_auth 收到无令牌的 OPTIONS 就 401，真请求发不出去。终态是\n同源托管故无影响，但 :3010 这个 dev 形态永远走不通网关。这与 §11「两个键、两个进程」\n是同一族问题的两面：跨源这件事，代理和网关都不替你解决。\n\n新登记 D-11（服务端直连验 200 分支未做——本轮令牌只在浏览器里，不把有效 bearer 打进\n命令行与日志）与 D-12（登录后顶栏的 hydration 告警）。\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:11:45-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/7a4b69367b18f4e284218704981b54c0ee10d2b6...ec0f1c04d60b56c0fa19a2c06fc89e7a64b69c4d","Len":1}...
|
1789773116
|
Edit
Delete
|
|
31181
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"7a4b69367 {"Commits":[{"Sha1":"7a4b69367b18f4e284218704981b54c0ee10d2b6","Message":"test(contracts): 成本容量的门禁覆盖——29 个原因码只有 20 个在夹具上走过，M0 后计费字段禁入那条一片空白\n\n与同日 bdb662d（数据分析）同一套做法：把 29 个原因码逐条与夹具的实际产出比对——跑每个用例、\n收集真实返回值，不读代码推断。判定逻辑一行未改，resource-tags.ts 本轮零改动。\n\n1. 9 条从未在门禁上走过：\n - POST_M0_BINDING_FORBIDDEN：M0 阶段禁止把 invoice / price / budget / quota / chargeback 这类\n 计费与容量动作字段写进用量记录（23 个禁入词），是本域最靠近红线的一条，门禁上一片空白。\n - TAG_VALUE_INVALID：标签取值字符集。此前只有「缺标签」有夹具，「标签值乱写」没有。\n - CORRECTION_REFERENCE_INVALID：更正引用必须成对（id 与 reasonCode 同在或同不在）且不得自指。\n - SOURCE_CLASSIFICATION_DOWNGRADE：记录分级不得低于来源登记分级。\n - 六条基线旗标里除 G3_NOT_REACHED 外的全部五条：G5 产品窗口、应用登记、服务身份、审计、资源标签目录。\n\n2. 反方向 4 条门禁有、单测没有：RESOURCE_TAGS_INVALID / CONTENT_DIGEST_INVALID /\n METER_VERSION_INVALID / USAGE_LINEAGE_REQUIRED，补进单测。\n\n覆盖：夹具 32 → 41 例（正 3 / 反 38），新增 N30—N38 九例且每例只产出一条原因（逐例核过实际返回值）；\n定向测试 28 → 32 例；原因码门禁覆盖 20/29 → 29/29，单测覆盖 25/29 → 29/29。上一轮用例一条未改。\n\n写单测时两处预期被实测推翻，按实现订正而不是反过来改实现——夹具与用例的作用正在于此：\n① RESOURCE_TAGS_INVALID 不是标签面自己报的码。assessResourceTags 对非对象入参报的是\n REQUIRED_TAG_MISSING 并把八个必填键全列进 missing；RESOURCE_TAGS_INVALID 是 assessUsageRecord\n 把「内嵌标签没过体检」收敛成的一条。\n② meterVersion 的 semver 模式接受预发布后缀，1.0.0-rc.1 合法。\n两条都写成用例固定住，免得下次被当成缺陷「修」掉。\n\n夹具变异探针（41 例真实 payload × 14 种脏值，走 evaluateFixturePayload 入口）：\n22792 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做（越界）：全资源计量账本、AI 成本明细（依赖 M7）一件未建，C19 按缺失模块完善清单仍是「裁决」；\nCatalog 登记未动。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 398/398、contract-cost-capacity 夹具 41/41 失败 0。\n负向实测：把 N32 的声明原因改成 USAGE_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n（reasons=[\"POST_M0_BINDING_FORBIDDEN\"]），还原后 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:09:29-07:00"},{"Sha1":"557a95c4422518cf3d9fdff04d261114ab389169","Message":"chore(release): 三包推到 1.0.0-rc.4——clients 扫描面与这轮 contracts 硬化一起上车\n\n发 rc.4 的直接动因：e61bfcf 给 check:module-imports 补的 clients 扫描面与两条规则\n（CLIENT_FORBIDDEN_IMPORT / ESCAPES_CLIENT）不在任何已发布版本里，而 @juhai/governance\n的 rc.0—rc.3 已全部被占用，按 G-12 的边界只能往前发下一个 RC。\n\n随车发出的远不止这些。自 rc.3 的源 036a308 起：\n contracts 147 个文件 / 51 条提交（九域规则的入参体检与门禁覆盖那一大轮）\n governance 61 个文件 / 48 条提交\n runtime/clients/fact 5 个文件 / 5 条提交\n三包版本一致，符合 CL-5「一次发布 = 一个 tag = 一组同版本包」；包目录单源仍是\ngovernance/release-packages.json。\n\n通道：本地旁路（G-12 第三次使用）。CI 正道 2026-09-18 实测双重不可用——GitHub Actions\n最近三次 run 全部 failure（账户计费，最新 35215270797 即 CLAUDE.md 记的那条注解），\n且 GitHub 镜像落后 237 条提交、因分支保护的 required check 跑不起来而推不动，\ne61bfcf 的代码根本不在 GitHub 上。按 G-12 边界，rc.4 同样不得宣称经过发布门禁验证。\n\n本次按 CL-5 补打 tag packages-v1.0.0-rc.4——rc.2 / rc.3 两趟都漏了这一步。\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:08:15-07:00"},{"Sha1":"2c3928d388603168f2510c6f1450b41804c429cf","Message":"test(contracts): 统一体验的 21 条原因码只有单测——门禁一条没有\n\n这是九个契约包里最后一块成规模的门禁空白，也是唯一一个判定与单测都齐全、只差夹具的域——所以本条\n一条单测都没加，补的全是夹具。\n\n21 条分四组：\n 贡献自身的体检（归属、类型、分级、双时间、投影修订与新鲜度、Owner Command 声明） 9 条\n 与来源登记的四项比对 4 条\n 派发前动作复核的会话 / 租户 / 源版本 / 幂等键 4 条\n 四条基线闸门真正未就绪时的阻断 4 条\n\n用例按语义写而不是删字段：类型 / 分级填不在册的值、生效时间不可解析、投影修订超过源修订、\nmaxAgeSeconds=1 触发过期、maxRevisionLag=0 触发落后、动作声明 reauthorize=false、会话 expired、\n源修订漂移 5。其中「登记前缀是壳根 /」是规则注释自己点名的红线——根前缀会让「登记应用前缀下」的约束\n失效，等于授权该应用深链到任意其他应用的路由，而门禁此前看不到这条。\n\n补：夹具 18 → 36 例（正 3 / 反 33）。本域「夹具无但单测有」由 21 归 0，「哪里都没有」保持 0。\n\n负向实测：把壳根那条的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补覆盖，没有改任何判定，也没有改单测；experience-contribution.ts 一行未动。\n九个域的门禁覆盖至此收口：「哪里都没有」全为 0，「夹具无但单测有」由 77 降至 29。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 35/35、contract-enterprise-experience 36/36。\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:07:54-07:00"}],"HeadCommit":{"Sha1":"7a4b69367b18f4e284218704981b54c0ee10d2b6","Message":"test(contracts): 成本容量的门禁覆盖——29 个原因码只有 20 个在夹具上走过，M0 后计费字段禁入那条一片空白\n\n与同日 bdb662d（数据分析）同一套做法：把 29 个原因码逐条与夹具的实际产出比对——跑每个用例、\n收集真实返回值，不读代码推断。判定逻辑一行未改，resource-tags.ts 本轮零改动。\n\n1. 9 条从未在门禁上走过：\n - POST_M0_BINDING_FORBIDDEN：M0 阶段禁止把 invoice / price / budget / quota / chargeback 这类\n 计费与容量动作字段写进用量记录（23 个禁入词），是本域最靠近红线的一条，门禁上一片空白。\n - TAG_VALUE_INVALID：标签取值字符集。此前只有「缺标签」有夹具，「标签值乱写」没有。\n - CORRECTION_REFERENCE_INVALID：更正引用必须成对（id 与 reasonCode 同在或同不在）且不得自指。\n - SOURCE_CLASSIFICATION_DOWNGRADE：记录分级不得低于来源登记分级。\n - 六条基线旗标里除 G3_NOT_REACHED 外的全部五条：G5 产品窗口、应用登记、服务身份、审计、资源标签目录。\n\n2. 反方向 4 条门禁有、单测没有：RESOURCE_TAGS_INVALID / CONTENT_DIGEST_INVALID /\n METER_VERSION_INVALID / USAGE_LINEAGE_REQUIRED，补进单测。\n\n覆盖：夹具 32 → 41 例（正 3 / 反 38），新增 N30—N38 九例且每例只产出一条原因（逐例核过实际返回值）；\n定向测试 28 → 32 例；原因码门禁覆盖 20/29 → 29/29，单测覆盖 25/29 → 29/29。上一轮用例一条未改。\n\n写单测时两处预期被实测推翻，按实现订正而不是反过来改实现——夹具与用例的作用正在于此：\n① RESOURCE_TAGS_INVALID 不是标签面自己报的码。assessResourceTags 对非对象入参报的是\n REQUIRED_TAG_MISSING 并把八个必填键全列进 missing；RESOURCE_TAGS_INVALID 是 assessUsageRecord\n 把「内嵌标签没过体检」收敛成的一条。\n② meterVersion 的 semver 模式接受预发布后缀，1.0.0-rc.1 合法。\n两条都写成用例固定住，免得下次被当成缺陷「修」掉。\n\n夹具变异探针（41 例真实 payload × 14 种脏值，走 evaluateFixturePayload 入口）：\n22792 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做（越界）：全资源计量账本、AI 成本明细（依赖 M7）一件未建，C19 按缺失模块完善清单仍是「裁决」；\nCatalog 登记未动。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 398/398、contract-cost-capacity 夹具 41/41 失败 0。\n负向实测：把 N32 的声明原因改成 USAGE_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n（reasons=[\"POST_M0_BINDING_FORBIDDEN\"]），还原后 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:09:29-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/54e6324c8b404aba56e1fa681cbcbe67019128c0...7a4b69367b18f4e284218704981b54c0ee10d2b6","Len":3}...
|
1789773006
|
Edit
Delete
|
|
31180
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/docs/registry-blueprint-record
|
0
|
{"Commits":[{"Sha1":"3bd0c5896 {"Commits":[{"Sha1":"3bd0c5896c9b7842434caa9c60d32d7bfbd686c4","Message":"docs(domain): 注册中心蓝图补记后四笔，并把「现状」改成指向机器报告而不是复写活数字\n\n蓝图是 Catalog 给本模块登记的 evidence 之一，它的「2026-09-18 规则加固」节此前只记了\n92a6b8e 一笔：三条缺陷、数字停在单测 44 例 / 夹具 15 例。同日 94366bc / 91216b5 /\n5f3f608 / d860eb6 四笔在蓝图里没有任何痕迹。本条只补记录，不改任何规则与 Catalog。\n\n补进去的四条缺陷（表格 3 行 → 7 行）：\n- 第 4 条（94366bc）：四条就绪闸门写作 !context.x，传 \"false\" / 1 / \"no\" / {} 一律判为\n 已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW；改为 !== true。92a6b8e 只收了入参\n 形状，漏了这四个布尔位。\n- 第 5 条（94366bc + 91216b5）：snapshot-upgrade-review.ts 那 393 行在夹具评估器上零\n 覆盖；补 upgrade 规则后重算 snapshot / transition 侧，24 个分支里仍有 12 个没走到。\n- 第 6 条（5f3f608）：upgrade 用例全对着四条闸门，闸门下面的请求校验有 15 条原因码\n 哪里都没有。\n- 第 7 条（d860eb6）：证据本身可不可信这一层，13 条原因码只有单测、门禁看不到；其中\n TARGET_SOURCE_MUST_BE_CLEAN 与本仓「证据只能绑干净树」同源，两条 *_LINEAGE_MISMATCH\n 是「写着通过了、说的却是别的版本」，比没有证据更危险。\n\n写法上的一处改动，起因是这份文档已经过期过两次：「现状」段不再复写单测与夹具的绝对数，\n改成给出取数命令并指向 reports/fixtures.latest.json。该模块一天内被连续补了四轮覆盖，\n任何写进正文的活数字都会在下一笔提交后失真。逐笔证据里的数字保留——它们绑各自 SHA，\n是历史口径，不随后续变化。另加一段提醒：那份报告此刻仍绑 7523bd0、check:evidence 判\nEVIDENCE_STALE，回绑前其例数不代表当前代码。\n\n核验（本分支 clean 树，rebase 到 origin/main 之后）：文中给的 check-fixtures 命令实跑通过\n（0 失败；例数有意不写进文档）；check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写一致；Catalog 四字段与六条 blockers 逐项核对；runtime/modules/ 下确无本模块；相对链接\n../缺失模块完善清单-2026-09-16.md 可解析；表格 9 行各 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":"54e6324c8b404aba56e1fa681cbcbe67019128c0","Message":"test(contracts): 四个域共享的快照版本号分支，外加会话准入的两条同组兄弟\n\nnormalizeSnapshot（或其等价物）在四个域里是同一个形状，而「version 必须是正整数」这一条四个域都\n没钉：FILE_ACCESS_POLICY_VERSION_INVALID、WEBHOOK_POLICY_VERSION_INVALID、\nCONVERSATION_POLICY_VERSION_INVALID、NO_USABLE_LAST_KNOWN_GOOD（配置开关）。版本号是「最后良好\n快照」向前比较的唯一依据，比不出来就不能换。\n\n四个域各补一条夹具用例（version: 0；缺失 / 负数 / 字符串 / 小数走同一路，由单测覆盖全部五种）与\n一条单测。配置开关的后果与其余三个不同——它不是「整份拒收」而是保留最后良好快照，所以那条单测断的是\n「活动版本不得被无效候选改动」，这才是该分支的真正断言。\n\n顺带把 collaboration-messaging 的两条同组兄弟一并补上（CONVERSATION_POLICY_REVISION_REQUIRED、\nCONVERSATION_TENANT_POLICIES_REQUIRED）——它与 public-file 的 N26 / N27 是同一形状，三条一起钉住\n才算完整。补后该域「哪里都没有」由 2 归 0。\n\n夹具：public-file 31 → 32、notification-webhook 24 → 25、collaboration-messaging 40 → 42、\nconfiguration-feature-flags 17 → 18。\n\n负向实测：public-file 与 notification-webhook 各把新用例的声明原因改成不会产生的串 → 门禁 exit 1，\n恢复后转绿。\n\n本条只补覆盖，没有改任何判定。至此九个域「哪里都没有」全部为 0。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、四域定向 104/104、四个套件 117/117。\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:06:26-07:00"},{"Sha1":"52fe066412543b57b729791de298ac0b5898b52b","Message":"docs(部署): D-8 裁决落地——dev 面配上现签令牌，并记下它当场被实证的代价\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:04:51-07:00"},{"Sha1":"bdb662d439cf7e24d8caef596c9ebf5d5e38b12d","Message":"test(contracts): 指标契约的门禁覆盖——34 个原因码只有 21 个在夹具上走过，G3 前运维绑定那条一片空白\n\n同日 daa226b 把崩溃面、枚举零校验与真值旗标收了。本轮只问一件事：这些判定门禁看得见几条。\n做法是把 34 个原因码逐条与夹具的实际产出比对——跑每个用例、收集真实返回值，不读代码推断。\n\n判定逻辑一行未改：metric-contract.ts 本轮零改动，只动夹具与测试。\n\n1. 12 条从未在门禁上走过，只有单测看着：CDC_CAPTURE_CONTRACT_REQUIRED、DIMENSION_ID_DUPLICATED、\n OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3，演进的五条不可变断言（METRIC_ID_CHANGED /\n METRIC_NAME_CHANGED / METRIC_OWNER_CHANGED / METRIC_SOURCE_CHANGED / EPISTEMIC_STATUS_CHANGED）、\n REFRESH_SLA_REGRESSION，以及六条基线旗标里的三条（FACT_OR_CDC / IDENTITY_SCOPE /\n DATA_CLASSIFICATION_BASELINE_NOT_READY）。其中 OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3 是本域最\n 靠近红线的一条——G3 前不得把 sql / dburl / outputTable 之类写进契约——门禁上此前一片空白。\n\n2. 1 条走到过但没人钉住：METRIC_CLASSIFICATION_TOO_LOW 由别的用例顺带产出，没有任何用例声明它，\n 改坏了门禁不会红。\n\n3. 反方向一条：REFRESH_SLA_INVALID 门禁有、单测没有，补进单测，连同「演进时 SLA 只能收紧」的正反向。\n\n覆盖：夹具 27 → 40 例（正 3 / 反 37），新增 N25—N37 十三例且每例只产出一条原因（逐例核过实际返回值，\n不靠门禁的前缀包含蒙混）；定向测试 25 → 27 例；原因码门禁覆盖 21/34 → 34/34。上一轮用例一条未改。\n\n另跑一遍夹具变异探针（40 例的真实 payload，逐个叶子字段换 14 种脏值，走 evaluateFixturePayload 入口）：\n13552 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做（越界）：采集、语义层、查询 API 一件未建，C17 按缺失模块完善清单仍是「裁决」；Catalog 登记未动。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 390/390、contract-data-analytics 夹具 40/40 失败 0。\n负向实测：把 N27 的声明原因改成 METRIC_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n（reasons=[\"OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3\"]），还原后 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:04:20-07:00"},{"Sha1":"d860eb62560ba66297681a63c1466cf47c40d12f","Message":"test(contracts): 注册中心 upgrade 的证据链可信度——13 条原因码只有单测，门禁看不到\n\n前两轮补的是「请求缺字段」；这一轮是证据本身可不可信，它是九个契约包里唯一一处成规模的门禁空白。\n\n13 条分四组：\n 目标制品的身份四要素与来源工作树是否干净 5 条\n 兼容性证据是否通过 / 时间可解析 / 血缘对得上 3 条\n 影响面证据是否定稿 / 可计时 / 同源 3 条\n 复核时钟与候选状态 2 条\n\n其中 TARGET_SOURCE_MUST_BE_CLEAN 尤其要紧：目标制品自己声明是从脏工作树构建的，这类制品不该被\n采信——和本仓报告纪律是同一条（证据只能绑干净树），而门禁此前看不到这条路径。\nCOMPATIBILITY_EVIDENCE_LINEAGE_MISMATCH / IMPACT_EVIDENCE_LINEAGE_MISMATCH 同理：一份「通过了」\n但说的是别的版本、别的提交的证据，比没有证据更危险。\n\n补：夹具 32 → 41 例（N28–N36，九条用例覆盖 13 个原因，每条都是有语义的场景而不是单纯删字段），\n单测 53 → 59 例。本域「夹具无但单测有」由 23 降至 10，「哪里都没有」保持 0。\n\n负向实测：把 N29 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补覆盖，没有改任何判定；snapshot-upgrade-review.ts 一行未动。\n全仓「夹具无但单测有」由 77 降至 64，其中约 15 条是各域基线闸门的登记位，按已知口径保留。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 59/59、contract-application-contract-registry 41/41。\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:03:45-07:00"}],"HeadCommit":{"Sha1":"3bd0c5896c9b7842434caa9c60d32d7bfbd686c4","Message":"docs(domain): 注册中心蓝图补记后四笔，并把「现状」改成指向机器报告而不是复写活数字\n\n蓝图是 Catalog 给本模块登记的 evidence 之一，它的「2026-09-18 规则加固」节此前只记了\n92a6b8e 一笔：三条缺陷、数字停在单测 44 例 / 夹具 15 例。同日 94366bc / 91216b5 /\n5f3f608 / d860eb6 四笔在蓝图里没有任何痕迹。本条只补记录，不改任何规则与 Catalog。\n\n补进去的四条缺陷（表格 3 行 → 7 行）：\n- 第 4 条（94366bc）：四条就绪闸门写作 !context.x，传 \"false\" / 1 / \"no\" / {} 一律判为\n 已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW；改为 !== true。92a6b8e 只收了入参\n 形状，漏了这四个布尔位。\n- 第 5 条（94366bc + 91216b5）：snapshot-upgrade-review.ts 那 393 行在夹具评估器上零\n 覆盖；补 upgrade 规则后重算 snapshot / transition 侧，24 个分支里仍有 12 个没走到。\n- 第 6 条（5f3f608）：upgrade 用例全对着四条闸门，闸门下面的请求校验有 15 条原因码\n 哪里都没有。\n- 第 7 条（d860eb6）：证据本身可不可信这一层，13 条原因码只有单测、门禁看不到；其中\n TARGET_SOURCE_MUST_BE_CLEAN 与本仓「证据只能绑干净树」同源，两条 *_LINEAGE_MISMATCH\n 是「写着通过了、说的却是别的版本」，比没有证据更危险。\n\n写法上的一处改动，起因是这份文档已经过期过两次：「现状」段不再复写单测与夹具的绝对数，\n改成给出取数命令并指向 reports/fixtures.latest.json。该模块一天内被连续补了四轮覆盖，\n任何写进正文的活数字都会在下一笔提交后失真。逐笔证据里的数字保留——它们绑各自 SHA，\n是历史口径，不随后续变化。另加一段提醒：那份报告此刻仍绑 7523bd0、check:evidence 判\nEVIDENCE_STALE，回绑前其例数不代表当前代码。\n\n核验（本分支 clean 树，rebase 到 origin/main 之后）：文中给的 check-fixtures 命令实跑通过\n（0 失败；例数有意不写进文档）；check:evidence 对 fixtures 报告的 EVIDENCE_STALE 判定与文中\n所写一致；Catalog 四字段与六条 blockers 逐项核对；runtime/modules/ 下确无本模块；相对链接\n../缺失模块完善清单-2026-09-16.md 可解析；表格 9 行各 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/ba752059ee2e67443d3a4b9a1c023c80573bd584...3bd0c5896c9b7842434caa9c60d32d7bfbd686c4","Len":5}...
|
1789772915
|
Edit
Delete
|
|
31175
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"54e6324c8 {"Commits":[{"Sha1":"54e6324c8b404aba56e1fa681cbcbe67019128c0","Message":"test(contracts): 四个域共享的快照版本号分支，外加会话准入的两条同组兄弟\n\nnormalizeSnapshot（或其等价物）在四个域里是同一个形状，而「version 必须是正整数」这一条四个域都\n没钉：FILE_ACCESS_POLICY_VERSION_INVALID、WEBHOOK_POLICY_VERSION_INVALID、\nCONVERSATION_POLICY_VERSION_INVALID、NO_USABLE_LAST_KNOWN_GOOD（配置开关）。版本号是「最后良好\n快照」向前比较的唯一依据，比不出来就不能换。\n\n四个域各补一条夹具用例（version: 0；缺失 / 负数 / 字符串 / 小数走同一路，由单测覆盖全部五种）与\n一条单测。配置开关的后果与其余三个不同——它不是「整份拒收」而是保留最后良好快照，所以那条单测断的是\n「活动版本不得被无效候选改动」，这才是该分支的真正断言。\n\n顺带把 collaboration-messaging 的两条同组兄弟一并补上（CONVERSATION_POLICY_REVISION_REQUIRED、\nCONVERSATION_TENANT_POLICIES_REQUIRED）——它与 public-file 的 N26 / N27 是同一形状，三条一起钉住\n才算完整。补后该域「哪里都没有」由 2 归 0。\n\n夹具：public-file 31 → 32、notification-webhook 24 → 25、collaboration-messaging 40 → 42、\nconfiguration-feature-flags 17 → 18。\n\n负向实测：public-file 与 notification-webhook 各把新用例的声明原因改成不会产生的串 → 门禁 exit 1，\n恢复后转绿。\n\n本条只补覆盖，没有改任何判定。至此九个域「哪里都没有」全部为 0。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、四域定向 104/104、四个套件 117/117。\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:06:26-07:00"}],"HeadCommit":{"Sha1":"54e6324c8b404aba56e1fa681cbcbe67019128c0","Message":"test(contracts): 四个域共享的快照版本号分支，外加会话准入的两条同组兄弟\n\nnormalizeSnapshot（或其等价物）在四个域里是同一个形状，而「version 必须是正整数」这一条四个域都\n没钉：FILE_ACCESS_POLICY_VERSION_INVALID、WEBHOOK_POLICY_VERSION_INVALID、\nCONVERSATION_POLICY_VERSION_INVALID、NO_USABLE_LAST_KNOWN_GOOD（配置开关）。版本号是「最后良好\n快照」向前比较的唯一依据，比不出来就不能换。\n\n四个域各补一条夹具用例（version: 0；缺失 / 负数 / 字符串 / 小数走同一路，由单测覆盖全部五种）与\n一条单测。配置开关的后果与其余三个不同——它不是「整份拒收」而是保留最后良好快照，所以那条单测断的是\n「活动版本不得被无效候选改动」，这才是该分支的真正断言。\n\n顺带把 collaboration-messaging 的两条同组兄弟一并补上（CONVERSATION_POLICY_REVISION_REQUIRED、\nCONVERSATION_TENANT_POLICIES_REQUIRED）——它与 public-file 的 N26 / N27 是同一形状，三条一起钉住\n才算完整。补后该域「哪里都没有」由 2 归 0。\n\n夹具：public-file 31 → 32、notification-webhook 24 → 25、collaboration-messaging 40 → 42、\nconfiguration-feature-flags 17 → 18。\n\n负向实测：public-file 与 notification-webhook 各把新用例的声明原因改成不会产生的串 → 门禁 exit 1，\n恢复后转绿。\n\n本条只补覆盖，没有改任何判定。至此九个域「哪里都没有」全部为 0。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、四域定向 104/104、四个套件 117/117。\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:06:26-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/52fe066412543b57b729791de298ac0b5898b52b...54e6324c8b404aba56e1fa681cbcbe67019128c0","Len":1}...
|
1789772828
|
Edit
Delete
|
|
31173
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"52fe06641 {"Commits":[{"Sha1":"52fe066412543b57b729791de298ac0b5898b52b","Message":"docs(部署): D-8 裁决落地——dev 面配上现签令牌，并记下它当场被实证的代价\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:04:51-07:00"},{"Sha1":"bdb662d439cf7e24d8caef596c9ebf5d5e38b12d","Message":"test(contracts): 指标契约的门禁覆盖——34 个原因码只有 21 个在夹具上走过，G3 前运维绑定那条一片空白\n\n同日 daa226b 把崩溃面、枚举零校验与真值旗标收了。本轮只问一件事：这些判定门禁看得见几条。\n做法是把 34 个原因码逐条与夹具的实际产出比对——跑每个用例、收集真实返回值，不读代码推断。\n\n判定逻辑一行未改：metric-contract.ts 本轮零改动，只动夹具与测试。\n\n1. 12 条从未在门禁上走过，只有单测看着：CDC_CAPTURE_CONTRACT_REQUIRED、DIMENSION_ID_DUPLICATED、\n OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3，演进的五条不可变断言（METRIC_ID_CHANGED /\n METRIC_NAME_CHANGED / METRIC_OWNER_CHANGED / METRIC_SOURCE_CHANGED / EPISTEMIC_STATUS_CHANGED）、\n REFRESH_SLA_REGRESSION，以及六条基线旗标里的三条（FACT_OR_CDC / IDENTITY_SCOPE /\n DATA_CLASSIFICATION_BASELINE_NOT_READY）。其中 OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3 是本域最\n 靠近红线的一条——G3 前不得把 sql / dburl / outputTable 之类写进契约——门禁上此前一片空白。\n\n2. 1 条走到过但没人钉住：METRIC_CLASSIFICATION_TOO_LOW 由别的用例顺带产出，没有任何用例声明它，\n 改坏了门禁不会红。\n\n3. 反方向一条：REFRESH_SLA_INVALID 门禁有、单测没有，补进单测，连同「演进时 SLA 只能收紧」的正反向。\n\n覆盖：夹具 27 → 40 例（正 3 / 反 37），新增 N25—N37 十三例且每例只产出一条原因（逐例核过实际返回值，\n不靠门禁的前缀包含蒙混）；定向测试 25 → 27 例；原因码门禁覆盖 21/34 → 34/34。上一轮用例一条未改。\n\n另跑一遍夹具变异探针（40 例的真实 payload，逐个叶子字段换 14 种脏值，走 evaluateFixturePayload 入口）：\n13552 个变异点、0 处抛异常——daa226b 的硬化结论在扩面后仍成立。\n\n未做（越界）：采集、语义层、查询 API 一件未建，C17 按缺失模块完善清单仍是「裁决」；Catalog 登记未动。\n\n证据：pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas 无漂移、\nnode --test contracts/test/*.test.mjs 390/390、contract-data-analytics 夹具 40/40 失败 0。\n负向实测：把 N27 的声明原因改成 METRIC_LINEAGE_REQUIRED → 门禁 exit 1 并点名该例\n（reasons=[\"OPERATIONAL_BINDING_FORBIDDEN_BEFORE_G3\"]），还原后 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:04:20-07:00"},{"Sha1":"d860eb62560ba66297681a63c1466cf47c40d12f","Message":"test(contracts): 注册中心 upgrade 的证据链可信度——13 条原因码只有单测，门禁看不到\n\n前两轮补的是「请求缺字段」；这一轮是证据本身可不可信，它是九个契约包里唯一一处成规模的门禁空白。\n\n13 条分四组：\n 目标制品的身份四要素与来源工作树是否干净 5 条\n 兼容性证据是否通过 / 时间可解析 / 血缘对得上 3 条\n 影响面证据是否定稿 / 可计时 / 同源 3 条\n 复核时钟与候选状态 2 条\n\n其中 TARGET_SOURCE_MUST_BE_CLEAN 尤其要紧：目标制品自己声明是从脏工作树构建的，这类制品不该被\n采信——和本仓报告纪律是同一条（证据只能绑干净树），而门禁此前看不到这条路径。\nCOMPATIBILITY_EVIDENCE_LINEAGE_MISMATCH / IMPACT_EVIDENCE_LINEAGE_MISMATCH 同理：一份「通过了」\n但说的是别的版本、别的提交的证据，比没有证据更危险。\n\n补：夹具 32 → 41 例（N28–N36，九条用例覆盖 13 个原因，每条都是有语义的场景而不是单纯删字段），\n单测 53 → 59 例。本域「夹具无但单测有」由 23 降至 10，「哪里都没有」保持 0。\n\n负向实测：把 N29 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补覆盖，没有改任何判定；snapshot-upgrade-review.ts 一行未动。\n全仓「夹具无但单测有」由 77 降至 64，其中约 15 条是各域基线闸门的登记位，按已知口径保留。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 59/59、contract-application-contract-registry 41/41。\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:03:45-07:00"}],"HeadCommit":{"Sha1":"52fe066412543b57b729791de298ac0b5898b52b","Message":"docs(部署): D-8 裁决落地——dev 面配上现签令牌，并记下它当场被实证的代价\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:04:51-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/95b88d34fca66f4030640c2652d3171ecfb05b97...52fe066412543b57b729791de298ac0b5898b52b","Len":3}...
|
1789772730
|
Edit
Delete
|
|
31172
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/docs/registry-blueprint-record
|
0
|
{"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}...
|
1789772601
|
Edit
Delete
|
|
31171
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"95b88d34f {"Commits":[{"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"}],"HeadCommit":{"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"},"CompareURL":"luoanwu/enterprise-platform/compare/1a1b37e4669cfd80f87650050894fede8aee6b90...95b88d34fca66f4030640c2652d3171ecfb05b97","Len":1}...
|
1789772550
|
Edit
Delete
|
|
31170
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"1a1b37e46 {"Commits":[{"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"}],"HeadCommit":{"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"},"CompareURL":"luoanwu/enterprise-platform/compare/ffdd21a2ae238023f2bb48a632deaabade5e88f1...1a1b37e4669cfd80f87650050894fede8aee6b90","Len":1}...
|
1789772524
|
Edit
Delete
|
|
31169
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ffdd21a2a {"Commits":[{"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"}],"HeadCommit":{"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"},"CompareURL":"luoanwu/enterprise-platform/compare/5f3f6084506e2a173759f07f882713ffdd4111ae...ffdd21a2ae238023f2bb48a632deaabade5e88f1","Len":1}...
|
1789772427
|
Edit
Delete
|
|
31168
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"5f3f60845 {"Commits":[{"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":"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"},"CompareURL":"luoanwu/enterprise-platform/compare/352e61531916d12d6eb804674f5e49796104fd06...5f3f6084506e2a173759f07f882713ffdd4111ae","Len":1}...
|
1789772398
|
Edit
Delete
|
|
31167
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"352e61531 {"Commits":[{"Sha1":"352e61531916d12d6eb804674f5e49796104fd06","Message":"chore(reports): check:fixtures 回绑 @ 7523bd0\n\n上一份绑 91216b5，其后 notification-webhook 与 public-file 两份夹具有提交变更，报告随之过期\n（本次 SOURCE.md 的文档提交不在任何 evidence-scopes 作用域内，不是过期原因）。\n\n在 .worktrees/rebind-fixtures 的 detached 干净检出（HEAD=7523bd0）跑全 17 套件：\n316 例，失败 0，不可用 0，configurationError 0；provenance worktreeDirty=false、runner=local。\n\n先在主树跑过一次，跑到一半并行会话改了 contracts/test/fixtures/application-contract-registry.fixtures.json，\nprovenance 落成 worktreeDirty=true、例数 323（含那份未提交增量），该份作废未采用，主树报告已还原到已提交版\n后改走干净检出。两次差的 7 例即该未提交增量，待其提交后由对应会话重绑。\n\ncontracts/dist 由该检出自己 tsc 构建；runtime 九个模块经 turbo 全量缓存命中。\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:32-07:00"}],"HeadCommit":{"Sha1":"352e61531916d12d6eb804674f5e49796104fd06","Message":"chore(reports): check:fixtures 回绑 @ 7523bd0\n\n上一份绑 91216b5，其后 notification-webhook 与 public-file 两份夹具有提交变更，报告随之过期\n（本次 SOURCE.md 的文档提交不在任何 evidence-scopes 作用域内，不是过期原因）。\n\n在 .worktrees/rebind-fixtures 的 detached 干净检出（HEAD=7523bd0）跑全 17 套件：\n316 例，失败 0，不可用 0，configurationError 0；provenance worktreeDirty=false、runner=local。\n\n先在主树跑过一次，跑到一半并行会话改了 contracts/test/fixtures/application-contract-registry.fixtures.json，\nprovenance 落成 worktreeDirty=true、例数 323（含那份未提交增量），该份作废未采用，主树报告已还原到已提交版\n后改走干净检出。两次差的 7 例即该未提交增量，待其提交后由对应会话重绑。\n\ncontracts/dist 由该检出自己 tsc 构建；runtime 九个模块经 turbo 全量缓存命中。\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:32-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/7523bd04ab6e3606adf9d17c0b19b74e951e9dd5...352e61531916d12d6eb804674f5e49796104fd06","Len":1}...
|
1789772377
|
Edit
Delete
|
|
31166
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/docs/registry-blueprint-record
|
0
|
{"Commits":[{"Sha1":"fb755985c {"Commits":[{"Sha1":"fb755985cca612c5a0ab2a117213fb41689c6521","Message":"docs(domain): 注册中心蓝图补记后两笔——第 4 / 5 条缺陷与现状证据此前不在蓝图里\n\n蓝图是 Catalog 给本模块登记的 evidence 之一，但它的「2026-09-18 规则加固」节只记了\n92a6b8e 那一笔：三条缺陷、数字停在单测 44 例 / 夹具 15 例（正 4 反 11）。同日的\n94366bc 与 91216b5 没有在蓝图留下任何痕迹，于是蓝图对本模块的描述既滞后又不完整。\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 规则后按变异重算覆盖，24 个入参分支里仍有 12 个没有用例走到，再补 N17—N20 到 24/24。\n\n逐笔证据按各自当时的口径分列，不混成一句；并新增「现状」与「没有被这三笔改变的」两段：\nCatalog 仍 candidate_e0 / E0、六条 blockers 未动，C01.04 / C01.06 是接线型缺口且前置\nQ01 未裁，三笔都未触及。\n\n核验（本分支 clean 树）：文中每个数字都实跑对过——单测 49/49；check:fixtures 本套件\n25 例（正 5 / 反 20）0 失败；reports/fixtures.latest.json 的 provenance 确为\ngitSha=91216b5、worktreeDirty=false；Catalog 四个字段与 blockers 逐项核对；\nruntime/modules/ 下确无本模块；文中相对链接 ../缺失模块完善清单-2026-09-16.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-18T15:58:17-07:00"}],"HeadCommit":{"Sha1":"fb755985cca612c5a0ab2a117213fb41689c6521","Message":"docs(domain): 注册中心蓝图补记后两笔——第 4 / 5 条缺陷与现状证据此前不在蓝图里\n\n蓝图是 Catalog 给本模块登记的 evidence 之一，但它的「2026-09-18 规则加固」节只记了\n92a6b8e 那一笔：三条缺陷、数字停在单测 44 例 / 夹具 15 例（正 4 反 11）。同日的\n94366bc 与 91216b5 没有在蓝图留下任何痕迹，于是蓝图对本模块的描述既滞后又不完整。\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 规则后按变异重算覆盖，24 个入参分支里仍有 12 个没有用例走到，再补 N17—N20 到 24/24。\n\n逐笔证据按各自当时的口径分列，不混成一句；并新增「现状」与「没有被这三笔改变的」两段：\nCatalog 仍 candidate_e0 / E0、六条 blockers 未动，C01.04 / C01.06 是接线型缺口且前置\nQ01 未裁，三笔都未触及。\n\n核验（本分支 clean 树）：文中每个数字都实跑对过——单测 49/49；check:fixtures 本套件\n25 例（正 5 / 反 20）0 失败；reports/fixtures.latest.json 的 provenance 确为\ngitSha=91216b5、worktreeDirty=false；Catalog 四个字段与 blockers 逐项核对；\nruntime/modules/ 下确无本模块；文中相对链接 ../缺失模块完善清单-2026-09-16.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-18T15:58:17-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/033fe58013bb8911bcb2f63be44d9b4b003fca66...fb755985cca612c5a0ab2a117213fb41689c6521","Len":1}...
|
1789772340
|
Edit
Delete
|
|
31165
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/docs/registry-blueprint-record
|
0
|
|
1789772340
|
Edit
Delete
|
|
31164
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"7523bd04a {"Commits":[{"Sha1":"7523bd04ab6e3606adf9d17c0b19b74e951e9dd5","Message":"docs(contracts): 注册中心取舍补双向交叉实测——放弃的那套有 4 个实缺陷，不是覆盖更全\n\n7f82399 的取舍此前只写了「按 Owner 裁断取远端」，没有实测支撑。补做交叉验证：两侧各自编译成 dist\n后互喂夹具与单测，不靠读代码比对。\n\n① 9ac9914 的 19 例夹具喂当前实现：13 通过 / 6 不通过。6 例里 5 例只是原因码改名、同一输入两侧都拒；\n 余 1 例是设计取向不同——大写摘要旧的拒，新的经 normalizeDigest 归一为小写，比较走 sameHexRef。\n 其 40 例单测喂当前实现：36 通过 / 4 不通过，失败集中在同样四个主题。\n② 反向，当前 25 例夹具喂 9ac9914：18 通过 / 7 不通过。3 例是改名的镜像，另外 4 例是被放弃那套的实缺陷：\n - N10-mutable-version-tag 返回 [] 即放行可变版本标签；\n - N11-leading-zero-version 拒了但拒错原因，其 \\d+\\.\\d+\\.\\d+ 收下了 1.02.0；\n - P03-same-digest-other-case 误拒——它自己的注释抱怨「同一摘要两种写法等于两个身份」，却只在入口拒大写，\n 升级比较那条路上仍把大小写变体当成两个摘要，它抱怨的 bug 它没修完；\n - P04-prerelease-precedes-its-release 误拒 1.0.0-rc.0，而平台自己正在发 1.0.0-rc.x。\n③ 根因是结构性的：被放弃那套三个文件各带一套版本文法，远端抽 registry-primitives.ts 正是为收敛这三套，\n 其抬头所述经比对属实。\n④ 覆盖面 19/40 → 25/49。旧的在 upgrade 规则上多 1 例，但 ① 已证明那 7 例在当前实现下无一失守。\n\n结论：放弃 9ac9914 未造成覆盖缺口，反而避开 4 个实缺陷；唯一差异是原因码命名，无需回捡。\n\n同条订正一处措辞：「报告另行回绑」已不成立，该报告已于 0ed7ee7 回绑 @ 7f82399，其后由后续会话在更新\nSHA 上重绑。本次只改 contracts/SOURCE.md，不在任何 evidence-scopes 作用域内，不影响报告新鲜度。\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:50-07:00"},{"Sha1":"3e1cc814eb2141710a42e4afdb865f937790436d","Message":"docs(发布): 补记 rc.3 列车的本地旁路发布——证据取自产物内 provenance，并记下两处偏离\n\nrc.3 三包（contracts / governance / client-fact）2026-09-13 经旁路通道发出，当时没留记录。\n2026-09-18 做对抗验收、核对 CLAUDE.md 的 contracts 版本声明时，才从 Registry 实查发现\nrc.3 在架而仓内一字没有——provenance.json 随包分发、不入仓，漏写记录就等于这次发布\n在仓里不留任何痕迹。\n\n证据全部一手：Gitea Registry packument + 三个 rc.3 tarball 内的 provenance.json；\n下载产物的 sha512 与 Registry 登记的 integrity 三包逐一核对一致，确认读到的\nprovenance 出自架上那三个包。\n\n记下的事实：源 036a308（三包 package.json 在该提交上均已是 1.0.0-rc.3，符合「一组同版本包」），\n三份 provenance 均 worktreeDirty:false、runner:\"local\"、releaseChannel:\"local-bypass\"，\nverificationRun* 与 candidateSha256 全 null、reports:[]。实际动因是 client-fact 的 U-29；\ncontracts 从 rc.2 到 rc.3 **零内容变更**，只有版本号跟车。边界逐条继承 rc.2 那节，一个字不放宽。\n\n补记时一并发现两处偏离，都写进文档：\n\n1. 两趟车都没打 tag。CL-5 的口径是「一次发布 = 一个 tag = 一组同版本包」，而 rc.2 / rc.3\n 六份 provenance 的 tag 全是 null，仓里 packages-v* 也只到 packages-v1.0.0-rc.1。\n2. 上一节表格写 rc.2「源 eb3cf2c」，而 rc.2 产物内 provenance 记的是 6d3900a。\n **未擅改上一节表格**，只记录这个不一致，留给该次发布的执行者确认。\n\nCLAUDE.md 同步去掉上一条提交里标的「rc.3 无发布记录」缺口，改为指向本记录。\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:47-07:00"},{"Sha1":"098263a175e453448d36f3f281522f7cd96040fe","Message":"docs(部署): 记录补 §13——会话级临时目录里的密钥清干净\n\n§11.3 把 identity 的 env 从上一个会话的 /private/tmp scratchpad 搬进 .secrets/ 之后，\n那个 scratchpad 里还躺着三份带密文件。本节把它收口：一挪两删一剪，逐条记依据。\n\n要点不是「清理干净了」，是那个位置为什么放不得：会话级 scratchpad 随时会被清，\n而 launch.json 指着它（运行面下次起不来）、里面又有别处没有备份的凭证（东西就没了），\n两个隐患叠在一起。\n\n本轮新核实两件事，都写进记录：demo 租户管理员的明文口令**全工作区仅此一份**——\n连 .secrets/backups/ 里 09-17 那套交付备份的 platform_identity_dev.dump 也搜不到明文\n（库里存散列，账号能从备份恢复、明文不能），而同一租户只能 bootstrap 一次（runbook §2）；\n以及 git grep -F over HEAD 确认该口令**未出现在任何被跟踪文件**里（邮箱出现在 4 份，非机密）。\n\n删除与保留都留了判据：删前查引用与进程命令行，保留的三行用 sha256 前后比对证明逐字节未改。\n§13.4 登记单点风险：是否给 idp-demo-admin.txt 做仓外备份，留 Owner 判断。\n\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-18T15:58:32-07:00"},{"Sha1":"d950aa2f4b6f6bdcc3ccb7e4b0ba4bc69d6f7822","Message":"test(contracts): 通知与 Webhook 的请求体检与出站 allowlist 前置——七条原因码只有实现没有用例\n\n按同一口径算覆盖（变异每个夹具用例的每个叶子字段 → 收集规则实际产出的原因码 → 查夹具声明与单测），\nnotification-webhook 有 7 条「哪里都没有」：\n\n WEBHOOK_TENANT_ID_REQUIRED WEBHOOK_INTENT_ID_REQUIRED\n WEBHOOK_DESTINATION_ID_REQUIRED WEBHOOK_TEMPLATE_ID_REQUIRED\n WEBHOOK_REQUESTED_BY_REQUIRED WEBHOOK_CLASSIFICATION_INVALID\n WEBHOOK_ALLOWED_HOSTS_REQUIRED\n\n前六条在 plan() 开头那段 try/catch 里：归属三件套（tenant / intent / requestedBy）与投递目标\n（destination / template）缺一即拒、分级必须在册。整段体检删掉，夹具与单测都不会红——原来那 17 个\n用例里没有一个喂缺字段的请求。\n\n第七条是快照前置：allowedHosts 缺失 / 空 / 非数组时 normalizeSnapshot 拒收整份策略。放行一个\n「没有出站约束」的路由比没有路由更危险，投递目标不再受任何主机限制，而这条同样零覆盖。\n\n补：夹具 17 → 24 例（N15–N21），单测 24 → 27 例（六个字段 × 五种脏值、分级四种、allowlist 三种）。\n补后重算：notification-webhook 的「哪里都没有」归 0。\n\n负向实测：把 N20 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补覆盖，没有改任何判定；webhook-delivery-planner.ts / notification-effect.ts 一行未动。\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 27/27、contract-notification-webhook 24/24。\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:30-07:00"}],"HeadCommit":{"Sha1":"7523bd04ab6e3606adf9d17c0b19b74e951e9dd5","Message":"docs(contracts): 注册中心取舍补双向交叉实测——放弃的那套有 4 个实缺陷，不是覆盖更全\n\n7f82399 的取舍此前只写了「按 Owner 裁断取远端」，没有实测支撑。补做交叉验证：两侧各自编译成 dist\n后互喂夹具与单测，不靠读代码比对。\n\n① 9ac9914 的 19 例夹具喂当前实现：13 通过 / 6 不通过。6 例里 5 例只是原因码改名、同一输入两侧都拒；\n 余 1 例是设计取向不同——大写摘要旧的拒，新的经 normalizeDigest 归一为小写，比较走 sameHexRef。\n 其 40 例单测喂当前实现：36 通过 / 4 不通过，失败集中在同样四个主题。\n② 反向，当前 25 例夹具喂 9ac9914：18 通过 / 7 不通过。3 例是改名的镜像，另外 4 例是被放弃那套的实缺陷：\n - N10-mutable-version-tag 返回 [] 即放行可变版本标签；\n - N11-leading-zero-version 拒了但拒错原因，其 \\d+\\.\\d+\\.\\d+ 收下了 1.02.0；\n - P03-same-digest-other-case 误拒——它自己的注释抱怨「同一摘要两种写法等于两个身份」，却只在入口拒大写，\n 升级比较那条路上仍把大小写变体当成两个摘要，它抱怨的 bug 它没修完；\n - P04-prerelease-precedes-its-release 误拒 1.0.0-rc.0，而平台自己正在发 1.0.0-rc.x。\n③ 根因是结构性的：被放弃那套三个文件各带一套版本文法，远端抽 registry-primitives.ts 正是为收敛这三套，\n 其抬头所述经比对属实。\n④ 覆盖面 19/40 → 25/49。旧的在 upgrade 规则上多 1 例，但 ① 已证明那 7 例在当前实现下无一失守。\n\n结论：放弃 9ac9914 未造成覆盖缺口，反而避开 4 个实缺陷；唯一差异是原因码命名，无需回捡。\n\n同条订正一处措辞：「报告另行回绑」已不成立，该报告已于 0ed7ee7 回绑 @ 7f82399，其后由后续会话在更新\nSHA 上重绑。本次只改 contracts/SOURCE.md，不在任何 evidence-scopes 作用域内，不影响报告新鲜度。\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:50-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/a8733b8670d68e423adf4595fb210d185c882afa...7523bd04ab6e3606adf9d17c0b19b74e951e9dd5","Len":4}...
|
1789772335
|
Edit
Delete
|
|
31163
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a8733b867 {"Commits":[{"Sha1":"a8733b8670d68e423adf4595fb210d185c882afa","Message":"test(contracts): 公共文件 refresh 规则的快照体检分支——夹具与单测都没钉\n\n按「算覆盖」的口径复查自己这一轮的三个域：变异每个夹具用例的每个叶子字段，收集规则实际产出的原因码，\n再查夹具有没有声明过、单测有没有兜住。data-analytics / cost-capacity 的「哪里都没有」为 0，\npublic-file 有 2 条：FILE_ACCESS_POLICY_REVISION_REQUIRED、FILE_TENANT_POLICIES_REQUIRED。\n\n成因是本轮自己留下的：给 public-file 新增 refresh 规则时，把 normalizeSnapshot 的错误码经\nrefresh().reason 接了出来，但只钉了「版本不前向」与「未批准」两条，快照体检的其余拒绝分支\n（revision 缺失、租户策略为空 / 非数组）没有任何用例走到——那两处守卫改回去门禁不会红。\n\n补：夹具 29 → 31 例（N26 / N27），单测 22 → 23 例，并断言挡下之后活动快照不动、仍按 version 1 出计划。\n补后重算：public-file 的「哪里都没有」归 0。\n\n本条只补覆盖，没有改任何判定。\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 23/23、contract-public-file 31/31。\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:57:22-07:00"},{"Sha1":"033fe58013bb8911bcb2f63be44d9b4b003fca66","Message":"chore(reports): 工作台两份快照回绑 @ 73e36fd\n\n在 73e36fd 的干净 detached worktree 里重跑 build-workbench-snapshots.mjs。两份都有\n实质内容变化，不只是 provenance：\n\n- Manifest 换代。两份快照上一次绑 a9abcbe，当时 reports/release-manifest.latest.json\n 的 sourceSha 还是 b202dde；772b253 把它回绑到 04d02d6 后，两份快照的发布维度就落在了\n 上一代 Manifest 上。现在 21 条 entries 的 release.source_sha 与 ops 的 release 区块\n 一并更新到 04d02d6，缺项文案也从「镜像绑定 d8f0920 ≠ 当前 b202dde」变成\n 「05e3826 ≠ 当前 04d02d6」。\n- runbook 进了 ops 快照的作用域。73e36fd 给 §7 补了 image:smoke 的 env-file 来源，\n docs/runbook.md 是 workbench-ops-snapshot 的登记输入之一，改了就要重绑。\n\n发布档位仍是 stale 7 / not-in-manifest 14，conflicts 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-18T15:56:40-07:00"}],"HeadCommit":{"Sha1":"a8733b8670d68e423adf4595fb210d185c882afa","Message":"test(contracts): 公共文件 refresh 规则的快照体检分支——夹具与单测都没钉\n\n按「算覆盖」的口径复查自己这一轮的三个域：变异每个夹具用例的每个叶子字段，收集规则实际产出的原因码，\n再查夹具有没有声明过、单测有没有兜住。data-analytics / cost-capacity 的「哪里都没有」为 0，\npublic-file 有 2 条：FILE_ACCESS_POLICY_REVISION_REQUIRED、FILE_TENANT_POLICIES_REQUIRED。\n\n成因是本轮自己留下的：给 public-file 新增 refresh 规则时，把 normalizeSnapshot 的错误码经\nrefresh().reason 接了出来，但只钉了「版本不前向」与「未批准」两条，快照体检的其余拒绝分支\n（revision 缺失、租户策略为空 / 非数组）没有任何用例走到——那两处守卫改回去门禁不会红。\n\n补：夹具 29 → 31 例（N26 / N27），单测 22 → 23 例，并断言挡下之后活动快照不动、仍按 version 1 出计划。\n补后重算：public-file 的「哪里都没有」归 0。\n\n本条只补覆盖，没有改任何判定。\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 23/23、contract-public-file 31/31。\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:57:22-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/73e36fd4d78f4fe2e6d2ee90381700b0da82d381...a8733b8670d68e423adf4595fb210d185c882afa","Len":2}...
|
1789772257
|
Edit
Delete
|
|
31162
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"73e36fd4d {"Commits":[{"Sha1":"73e36fd4d78f4fe2e6d2ee90381700b0da82d381","Message":"docs(runbook): §7 补 image:smoke 的 --env-file 从哪来——仓里没有这份文件，此前只写了占位\n\nrunbook 只写 `pnpm image:smoke -- --env-file \u003cenv\u003e`，而仓里既没有这份 env，也没说它从\n哪来。实跑一次才发现 .secrets/enterprise-platform-runtime-dev.env 用的是 compose 变量名，\n镜像读的是容器变量名，映射在 stack/compose.yaml 的 runtime environment 块。\n\n连带记下三处只有实跑才撞得上的坑：smoke 的 docker run 不挂 stack 网络（compose 内部主机名\n解析不了，要换 host.docker.internal + 已发布端口）、Redis 逻辑库别撞 dev 常驻运行时的 14、\nscope 这种 shape 档不需要 DATABASE_URL_\u003cMODULE\u003e。\n\n另加一条判读规则：冒烟报告的 sourceSha 是镜像来源提交、provenance.gitSha 是本次运行绑定，\n两者不同是正常的；check:evidence 判 image-smoke 过期时先比它与 image-digest.json 的\nsourceSha，相同就只需重跑补绑定，不必重建镜像。\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:55:22-07:00"},{"Sha1":"d3c6a3f5fee8d2d65b58e89bddd00f6e12c12930","Message":"chore(reports): check:fixtures 回绑 @ 91216b5\n\n17 套件 307 例，0 失败 0 不可用；干净树本地跑（provenance worktreeDirty=false —— 判定按仓内口径\n排除 *.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:55:13-07:00"},{"Sha1":"91216b52fce5a1c677eab2d973a5cdbdac2a68f7","Message":"test(contracts): 注册中心入参体检的门禁覆盖——24 个分支里 12 个没有任何用例走到\n\n同日注册中心那笔把 appId / version / blockedBy 的入参体检从抛 TypeError 改成了拒绝，夹具也从 8 例\n补到 21 例。但「不崩了」与「崩回去会被门禁抓到」是两回事。复核方式不是读用例名，而是算覆盖：对当年\n会抛的那 20 处变异逐一跑规则、取回原因码，再看夹具里有没有用例声明过该原因。\n\n结果：\n snapshot.version（4 种脏值） 已钉 VERSION_REQUIRED\n snapshot.blockedBy（4 种） 已钉 SNAPSHOT_BLOCKERS_INVALID\n next.version（4 种） 已钉 SEMANTIC_VERSION_REQUIRED\n snapshot.appId（4 种） ✗ APP_ID_REQUIRED\n next.appId（4 种） ✗ APP_ID_CHANGED\n next.blockedBy（4 种） ✗ NEXT_SNAPSHOT_NOT_CONSUMABLE\n\n21 个用例里没有任何一个往 appId 或 transition 侧的 blockedBy 喂脏值——那两处守卫改回去\ncheck:fixtures 不会红，它压根走不到那条路径。APP_ID_CHANGED 与 NEXT_SNAPSHOT_NOT_CONSUMABLE\n此前单测与夹具都是零覆盖，后者还是 transition 规则里最常出现的一条。\n\n补：夹具 21 → 25 例（N17 appId 非字符串 / N18 appId 整键缺失 / N19 transition 改写 Owner 应用 /\nN20 next 侧 blockers 非数组），单测 46 → 49 例。补后重算覆盖：24 / 24 全钉。\n\n负向实测：把 N19 的声明原因改成不会产生的串 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补门禁覆盖，没有改任何判定——registry-snapshot.ts / snapshot-upgrade-review.ts 一行未动；\nupgrade 规则那半边（四条就绪闸门各一条真值用例）本来就完整，不在范围内。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 49/49、contract-application-contract-registry 25/25。\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:54:24-07:00"},{"Sha1":"7c2ac28f4020b30d3b1940a85169738c3f4f5039","Message":"chore(reports): 镜像冒烟重跑回绑 @ 5a40e51\n\n在 5a40e51 的干净 detached worktree 里真起容器跑 governance/smoke-image.mjs，\n6 项全过：container-running / api-health-200（database、redis 均 up）/\nplatform-modules-view（fail-closed，scope(shape)）/ module-health-200 /\ndecisions-unauthenticated-401 / docker-healthcheck-healthy。容器结束即删。\n\n冒的仍是 reports/image-digest.json 里那个镜像（sha256:c086993…，源码 05e3826e，\nlinux/arm64），未重建；报告里的 sourceSha 因此仍是 05e3826e——它记的是镜像的来源提交，\nprovenance.gitSha=5a40e51 才是本次冒烟的运行绑定。此前 check:evidence 判它过期是因为\nimage-digest.json 在 05e3826e 之后才被提交进来，结论本身没变，这次是用真跑把绑定补上。\n\nenv-file 由 .secrets/enterprise-platform-runtime-dev.env 按 stack/compose.yaml 的\n容器变量名映射而来，落在会话临时目录、未进仓；容器不挂 stack 网络，故主机名换成\nhost.docker.internal + 已发布端口（PG :55470 / Redis :56379），Redis 借未分配的\n逻辑库 15（dev 常驻运行时占 14，禁止共用）。\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:52:52-07:00"},{"Sha1":"5a40e517a6f296e16d35481b22b4db15478eaa50","Message":"chore(reports): check:fixtures 回绑 @ f2f1063\n\n17 套件 303 例，0 失败 0 不可用；干净树本地跑，provenance worktreeDirty=false。\n\n九个契约包夹具在本轮入参体检后的分布：\n public-file 29 / cost-capacity 32 / data-analytics 27 / application-contract-registry 21 /\n enterprise-experience 18 / configuration-feature-flags 17 / notification-webhook 17 /\n cross-domain-workflow 16 / collaboration-messaging 14\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:51:21-07:00"}],"HeadCommit":{"Sha1":"73e36fd4d78f4fe2e6d2ee90381700b0da82d381","Message":"docs(runbook): §7 补 image:smoke 的 --env-file 从哪来——仓里没有这份文件，此前只写了占位\n\nrunbook 只写 `pnpm image:smoke -- --env-file \u003cenv\u003e`，而仓里既没有这份 env，也没说它从\n哪来。实跑一次才发现 .secrets/enterprise-platform-runtime-dev.env 用的是 compose 变量名，\n镜像读的是容器变量名，映射在 stack/compose.yaml 的 runtime environment 块。\n\n连带记下三处只有实跑才撞得上的坑：smoke 的 docker run 不挂 stack 网络（compose 内部主机名\n解析不了，要换 host.docker.internal + 已发布端口）、Redis 逻辑库别撞 dev 常驻运行时的 14、\nscope 这种 shape 档不需要 DATABASE_URL_\u003cMODULE\u003e。\n\n另加一条判读规则：冒烟报告的 sourceSha 是镜像来源提交、provenance.gitSha 是本次运行绑定，\n两者不同是正常的；check:evidence 判 image-smoke 过期时先比它与 image-digest.json 的\nsourceSha，相同就只需重跑补绑定，不必重建镜像。\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:55:22-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/b60cc18d640a6561ccdd0fa798753d1f6476bad5...73e36fd4d78f4fe2e6d2ee90381700b0da82d381","Len":6}...
|
1789772184
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
31151
|
5
|
11
|
5
|
116
|
0
|
0
|
|
0
|
1|fix(contracts): 注册中心规则补失败关闭与摘要规范化——三个入口此前抛 TypeE 1|fix(contracts): 注册中心规则补失败关闭与摘要规范化——三个入口此前抛 TypeError，同一摘要的两种写法此前分叉成两个复核键...
|
1789742925
|
Edit
Delete
|
|
31150
|
5
|
7
|
5
|
116
|
0
|
0
|
|
0
|
1|fix(contracts): 注册中心规则补失败关闭与摘要规范化——三个入口此前抛 TypeE 1|fix(contracts): 注册中心规则补失败关闭与摘要规范化——三个入口此前抛 TypeError，同一摘要的两种写法此前分叉成两个复核键...
|
1789742918
|
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
|
|
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
|
|
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
|
|
31145
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/feat/registry-rule-hardening
|
0
|
{"Commits":[{"Sha1":"92a6b8e64 {"Commits":[{"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"},{"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"},{"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":"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"},"CompareURL":"luoanwu/enterprise-platform/compare/05e3826e9e9e4dbbdd753252c2134b8494b08f2b...92a6b8e647c2c4d764c1fcdb8448bfc48a4dc4ed","Len":4}...
|
1789742570
|
Edit
Delete
|
|
31144
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/feat/registry-rule-hardening
|
0
|
|
1789742570
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
30851
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"c9e0f59d1 {"Commits":[{"Sha1":"c9e0f59d11a533e7e5e3386f80eff8fb6d6ba6c8","Message":"test(identity): 给「模块故障不传导到宿主健康」的成对断言补设计说明\n\n2026-09-18 目录负责人裁决「维持分离」（开发计划 §6 偏差 #36）：模块依赖故障\n≠ 宿主运行时不健康。模块健康只在 GET /api/platform/modules[/:id/health] 可见，\n/api/health 只反映宿主自己的依赖。\n\n这条用例第 188—189 行的 degraded 与 200 是成对断言，此前没有注释说明它守的是\n一个有意的设计选择，读起来像实现欠账——于是框架 0.19.0 受理本仓 FR-1 后，我\n想当然地把模块 health() 汇入 /api/health，真实 DB 验收当场由 775 跌到 561，\n正是被这两行拦下的。\n\n补注释写明裁决出处与那次实锤，并点出「FR 被受理 ≠ 它解锁的工作就该做」。\n只加注释，断言与逻辑一字未动；typecheck 14/14。\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:49:14-07:00"}],"HeadCommit":{"Sha1":"c9e0f59d11a533e7e5e3386f80eff8fb6d6ba6c8","Message":"test(identity): 给「模块故障不传导到宿主健康」的成对断言补设计说明\n\n2026-09-18 目录负责人裁决「维持分离」（开发计划 §6 偏差 #36）：模块依赖故障\n≠ 宿主运行时不健康。模块健康只在 GET /api/platform/modules[/:id/health] 可见，\n/api/health 只反映宿主自己的依赖。\n\n这条用例第 188—189 行的 degraded 与 200 是成对断言，此前没有注释说明它守的是\n一个有意的设计选择，读起来像实现欠账——于是框架 0.19.0 受理本仓 FR-1 后，我\n想当然地把模块 health() 汇入 /api/health，真实 DB 验收当场由 775 跌到 561，\n正是被这两行拦下的。\n\n补注释写明裁决出处与那次实锤，并点出「FR 被受理 ≠ 它解锁的工作就该做」。\n只加注释，断言与逻辑一字未动；typecheck 14/14。\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:49:14-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/a63414ab085268e9570c6f51816a92718f2effeb...c9e0f59d11a533e7e5e3386f80eff8fb6d6ba6c8","Len":1}...
|
1789714158
|
Edit
Delete
|
|
30824
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a63414ab0 {"Commits":[{"Sha1":"a63414ab085268e9570c6f51816a92718f2effeb","Message":"chore(reports): F-7 收口——框架迁移凭证 frameworkVersion 0.22.0\n\npnpm migration:record --mode sync：source=base-framework 0.22.0 @ df53867 →\ntarget=enterprise-platform 0.22.0，runId cb50e485。\n\n**一致性门禁 L12 清零**（内核 pin 落后六个 minor 的常驻问题）。常驻问题由\nL9 / L12 两条降为 L9 一条——后者是 8 个上层应用仓的 compose 身份，待 N-11\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-17T22:39:42-07:00"}],"HeadCommit":{"Sha1":"a63414ab085268e9570c6f51816a92718f2effeb","Message":"chore(reports): F-7 收口——框架迁移凭证 frameworkVersion 0.22.0\n\npnpm migration:record --mode sync：source=base-framework 0.22.0 @ df53867 →\ntarget=enterprise-platform 0.22.0，runId cb50e485。\n\n**一致性门禁 L12 清零**（内核 pin 落后六个 minor 的常驻问题）。常驻问题由\nL9 / L12 两条降为 L9 一条——后者是 8 个上层应用仓的 compose 身份，待 N-11\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-17T22:39:42-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/d24b762cd6740f0bce850ae3fffcc84e8a279c28...a63414ab085268e9570c6f51816a92718f2effeb","Len":1}...
|
1789709986
|
Edit
Delete
|
|
30823
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"d24b762cd {"Commits":[{"Sha1":"d24b762cd6740f0bce850ae3fffcc84e8a279c28","Message":"chore(reports): 框架同步 0.16.1 → 0.22.0 后全套验收回绑 @ 765300b\n\n三级验收全部在干净树重跑，与升级前逐项持平：\n\n- runtime-acceptance **775 / 775 passed**，租户 RLS enforce（地板 775 未降）\n- ui-acceptance 5 / 5，1 组合\n- mainline-acceptance 四套件 11 / 17 / 19 / 18\n- mainline-restore passed，port-conformance 41 / 41\n- revocation-sla partial（invalidationPush 仍是 harness 传输，生产未接线）\n- release-manifest / sbom / identity-ui 随后重跑\n\ncheck:evidence **passed：35 份全新鲜 / 0 过期 / 0 例外**。\n\n过程中一处自伤已修复：曾用 git checkout -- runtime/reports 还原「跑门禁弄脏\n的报告」，连带把真跑出的六份验收证据还原成旧版，已在干净树重跑全套找回。\n教训：还原前必须按 provenance.gitSha 分辨本轮产出与脏绑，不可整目录 checkout。\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-17T22:38:56-07:00"},{"Sha1":"d66f63659bc07fa65ac84685335a0f3c5e15af5d","Message":"docs(runtime): 动态区 SHA 回灌至 765300b（重跑后的验收绑定）\n\n上一轮误用 git checkout -- runtime/reports 把真跑出的六份验收报告还原成了\n旧版，已在干净树重跑全套（runtime 775/775、UI 5/5、主线 11/17/19/18、恢复\n演练、端口一致性 41/41），六份统一绑 765300b / dirty=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-17T22:36:52-07:00"},{"Sha1":"765300b962ca658d112ac6064f925d82d0579dfd","Message":"docs(runtime): 动态区回灌框架同步后的三级验收 @ 56e78df\n\ncheck:docs-truth 再次拦下「报告已刷新而动态区未跟上」。\n\n- 真实 DB：775 tests / 0 failures clean 56e78df——框架同步 0.16.1 → 0.22.0 后\n 首跑，测试数与升级前持平、租户 RLS 仍 enforce\n- 浏览器：5 用例 / 1 组合 clean 56e78df\n- 环境如实记：隔离栈 enterprise-platform-ms23-ci（PG :55485 / Redis :56395 /\n Redpanda :59105）+ 验收库 enterprise_platform_acceptance_fwsync\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-17T22:29:47-07:00"},{"Sha1":"56e78dfa4fb1001fad92e6d93b0e3bb2f7569594","Message":"fix(runtime): 修正 CHANGELOG 并入六段后的跨仓断链（一致性门禁 L4）\n\n框架 CHANGELOG 0.17.0—0.22.0 六段里的 ../\u003c框架变更请求\u003e.md 指的是框架仓同级，\n并入本仓后全部失效，L4 报 5 条。改为 ../../../工程基础框架/\u003c文件\u003e 跨仓路径。\n\n这是框架同步的真实副作用：并入上游文档时，其相对链接的锚点也跟着换了仓。\nL4 / L10 / L13 恢复 CLEAN。\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-17T21:38:33-07:00"},{"Sha1":"b30ddd94965db4c6686a249d280ce579a879fc65","Message":"feat(runtime): 框架同步 0.16.1 → 0.22.0 主体（F-2b / F-3 / F-4）\n\nC-14 的实际形态。本轮把版本轴与两后端行为接线一次做完，部署两级按目录负责人\n裁决走「改判据 + 提 FR-6」。\n\nF-3 版本轴\n- 12 处 @juhai/kernel pin、runtime/package.json.version、packages/contracts\n version 全部 0.16.1 → 0.22.0；**F11 转绿**（这是抬 pin 一直卡住的门禁）\n- CHANGELOG 并入框架 0.17.0—0.22.0 六段，版本序连续；COMPATIBILITY.md 取 0.22.0\n\nF-4 两后端接线（C34 / C35 / C39 绊网全绿）\n- 直取六个未改过的文件：health.controller / health.module / health-checks.registry\n / request-log.middleware / logger / routes/health，另 types.ts、四个 C39 文件\n- 两处真三方合并：\n · api-fastify/src/app.ts：取 0.22.0 后按 sample-domain 标记剥离三个示例域块\n （本仓以 --strip-sample 建仓，本仓对该文件的唯一定制就是这三处剥离）\n · api-nestjs/src/create-app.ts：两侧改动不重叠——本仓加平台模块装载、框架加\n 访问日志中间件，合并保留两者\n\nF-2b 门禁脚本\n- check-dual-backend-parity / check-docs-truth / check-runtime-acceptance 取 0.22.0\n\ndocs-truth 四级新鲜度的本地修正（已提 FR-6）\n框架 0.22.0 把新鲜度断言由两级扩到四级，新增的部署 / 生产两级在本仓无法成立：\n其验收链要求 apps/api-nestjs/Dockerfile，而那份里写着 COPY packages/kernel/\npackage.json——本仓**不 vendor 内核**（pin 已发布包，packages/kernel 不存在），\n实测构建必然失败。本仓自己的制品镜像是 D-1 的 runtime/Dockerfile，与框架那套\n并存会变成两条镜像路径。判据改为「只对本仓真正接线了的级别断言」，未接线的\n打印 SKIPPED 而非伪装通过——不接受占位报告，与框架 doctrine「诚实的空」一致。\n已撤回全部 F-5 部署物与失败留下的半截报告。\n\n治理测试锚点 0.16.1 → 0.22.0。\n\n验收：turbo build 17/17、typecheck 31/31、runtime check 全链通过（两级 SKIPPED\n如实打印）、governance 测试 277/277。**真实三级验收随后在 clean 树重跑并回绑**\n——check:evidence 已如实报出 20 份证据的输入被本轮改动，不得只回绑静态报告。\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-17T21:23:29-07:00"}],"HeadCommit":{"Sha1":"d24b762cd6740f0bce850ae3fffcc84e8a279c28","Message":"chore(reports): 框架同步 0.16.1 → 0.22.0 后全套验收回绑 @ 765300b\n\n三级验收全部在干净树重跑，与升级前逐项持平：\n\n- runtime-acceptance **775 / 775 passed**，租户 RLS enforce（地板 775 未降）\n- ui-acceptance 5 / 5，1 组合\n- mainline-acceptance 四套件 11 / 17 / 19 / 18\n- mainline-restore passed，port-conformance 41 / 41\n- revocation-sla partial（invalidationPush 仍是 harness 传输，生产未接线）\n- release-manifest / sbom / identity-ui 随后重跑\n\ncheck:evidence **passed：35 份全新鲜 / 0 过期 / 0 例外**。\n\n过程中一处自伤已修复：曾用 git checkout -- runtime/reports 还原「跑门禁弄脏\n的报告」，连带把真跑出的六份验收证据还原成旧版，已在干净树重跑全套找回。\n教训：还原前必须按 provenance.gitSha 分辨本轮产出与脏绑，不可整目录 checkout。\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-17T22:38:56-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/96bfdde508464b4b0e1e3fb05f77a9f488492fc0...d24b762cd6740f0bce850ae3fffcc84e8a279c28","Len":6}...
|
1789709941
|
Edit
Delete
|
|
30747
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"96bfdde50 {"Commits":[{"Sha1":"96bfdde508464b4b0e1e3fb05f77a9f488492fc0","Message":"chore(reports): 回绑 @ 903f019\n\ncheck:evidence passed：35 份已登记全部新鲜，0 过期 / 0 例外 / 0 告警；\n未登记 13 份（四份手工记录退役后的稳定态）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-17T19:23:58-07:00"},{"Sha1":"903f019dc8033d3042cc0446e054e2665782fedc","Message":"chore(governance): 退役 mainline-dev-deployment，四份手工记录清零\n\n目录负责人裁决：与今日退役的另三份同类处置。\n\n它只记 09-12 在 dev 栈启用 Redpanda 这一件事（自述 scope「Redpanda only」），\n仓内无生成脚本、不可重跑。该结论现由三处覆盖且都会自动保鲜：\n\n- stack/compose.yaml 的 redpanda 已是启用状态（非候选注释块），MS-2 的机器\n 判定直接读它\n- stack/reports/runtime-up.*.json：四份更新的 dev 运行记录（09-14 / 09-16 ×3）\n- pnpm check:deployed：活体核验运行镜像与源提交\n\ndev 栈此后已重建多轮，09-12 那份快照描述的容器与端点早已不是当前事实。\n\nevidence-scopes note 补记本次裁决（它本就未登记，无条目可撤）；\n09-12 的执行记录里那处纯文本引用补一句退役说明——L4 不报（不是 markdown\n链接），但读者会去找一个不存在的文件。\n\n至此四份无生成脚本的手工记录全部退役：identity-http、\nmainline-candidate-regression、stack-image-pins、mainline-dev-deployment。\n\ncheck:evidence passed：35 份已登记全部新鲜，未登记 14 → 13。\ngovernance 测试 277/277。\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-17T19:23:31-07:00"}],"HeadCommit":{"Sha1":"96bfdde508464b4b0e1e3fb05f77a9f488492fc0","Message":"chore(reports): 回绑 @ 903f019\n\ncheck:evidence passed：35 份已登记全部新鲜，0 过期 / 0 例外 / 0 告警；\n未登记 13 份（四份手工记录退役后的稳定态）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-17T19:23:58-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/314c179366fb02a53485f4efbd0e3d3e88cd5470...96bfdde508464b4b0e1e3fb05f77a9f488492fc0","Len":2}...
|
1789698242
|
Edit
Delete
|
|
30745
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"314c17936 {"Commits":[{"Sha1":"314c179366fb02a53485f4efbd0e3d3e88cd5470","Message":"chore(reports): 回绑 @ 71b306f，登记面 33 → 35 全新鲜\n\nrelease-manifest 与 sbom 首次带嵌套 provenance 并受新鲜度保护。\n\nManifest 刷新后缺项 4 → 6，多出的两条都是真的、被旧快照藏了四天：\n- images.stack.*：compose 启用 runtime 服务后镜像是变量 ${PLATFORM_RUNTIME_IMAGE:?}，\n 未按 digest 锁定（PF-05 / PF-23 晋级前解决）\n- sbom：局部 lockfile 清单（268 包，仅 Node 依赖，不含基础镜像 Debian 包）\n 不满足 D-2 的完整 SBOM 要求\n\ncheck:evidence passed：35 份已登记全部新鲜，0 过期 / 0 例外 / 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-17T19:21:00-07:00"},{"Sha1":"71b306f53390e6119590b5225b660cd4effcd3b5","Message":"chore(governance): 登记 release-manifest 与 sbom 进 evidence-scopes（35 条）\n\n承 c5d9897。三份补了嵌套 provenance 之后，其中两份现在就能登记：\n\n- release-manifest（warn）：作用域 = compose、image-digest.json、四类包的\n package.json、runtime/modules、生成器与 schema。**这是 MS-4 退出条件的判据\n 输入**，此前无人监控其新鲜度\n- sbom（warn）：作用域 = image-digest.json、生成器、runtime 锁文件\n\nimage-smoke 本轮不登记：生成器已修，但要补上形状得起真实容器重跑（脚本强制\n--env-file，需 DB/Redis），不值得为补一个形状去起一套底座——待其下一次真实\n运行后登记。note 里写明了这一条与 mainline-dev-deployment 的区别（后者没有\n生成脚本，属手工记录那一类，不是形状问题）。\n\n同时修正 note 里 ① 类的描述：原写「没有 provenance.gitSha，要先让产生脚本写\nprovenance」，对这四份是不准确的——数据早就有。\n\ngovernance 测试 277/277。\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-17T19:20:23-07:00"},{"Sha1":"c5d98975f8c466d035550a4f38899db325d8b806","Message":"feat(governance): 三份报告补嵌套 provenance，让 MS-4 判据输入受新鲜度保护\n\n2026-09-17 目录负责人裁决：补嵌套 provenance，四份有 SHA 的全做。\n\n问题：release-manifest / sbom / image-smoke / mainline-dev-deployment 都写了\n源 SHA，但是**平铺**在顶层（sourceSha），而 check:evidence 只认嵌套的\nprovenance.gitSha。于是它们登记不进 evidence-scopes，游离在新鲜度之外。\n此前 evidence-scopes 的口径说明把它们归为「没有 provenance.gitSha，要先让\n产生脚本写 provenance」——对其中四份是不准确的：数据早就有，缺的是形状。\n\n实锤这不是理论风险：Manifest 绑 ac3683d（2026-09-14），其后它的结论输入改了\n10 个文件（contracts/governance 的 package.json、image-digest.json、\ncompose.yaml、client-fact 全套），四天无人报警。重跑后缺项 4 → 6，多出的两条\n都是真的——compose 启用 runtime 服务后镜像是变量未按 digest 锁定；SBOM 未随\n19150ae 镜像重生成。**一份过期的 Manifest 一直在少报，而 MS-4 的退出条件正是\n读它**（status=complete 且 runner 为 CI）。\n\n改动：\n- stack/release-manifest.schema.json 增可选 provenance 对象（不进 required，\n 向后兼容；additionalProperties:false 故必须显式加），并写明与顶层三项同源\n- release-manifest.mjs 同时写 provenance 与顶层兼容字段，实测两者一致\n- sbom.mjs / smoke-image.mjs 增 provenance: gitProvenance(root)。注意它们原有的\n sourceSha 是**镜像的**源提交，与「本报告在哪个提交产出」不是一回事，两者都留\n\nmainline-dev-deployment 做不了：全仓搜索确认它没有生成脚本，是第四份手工记录\n（与今日退役的三份同类），不是形状问题。另行处置。\n\ngovernance 测试 277/277。\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-17T19:19:03-07:00"}],"HeadCommit":{"Sha1":"314c179366fb02a53485f4efbd0e3d3e88cd5470","Message":"chore(reports): 回绑 @ 71b306f，登记面 33 → 35 全新鲜\n\nrelease-manifest 与 sbom 首次带嵌套 provenance 并受新鲜度保护。\n\nManifest 刷新后缺项 4 → 6，多出的两条都是真的、被旧快照藏了四天：\n- images.stack.*：compose 启用 runtime 服务后镜像是变量 ${PLATFORM_RUNTIME_IMAGE:?}，\n 未按 digest 锁定（PF-05 / PF-23 晋级前解决）\n- sbom：局部 lockfile 清单（268 包，仅 Node 依赖，不含基础镜像 Debian 包）\n 不满足 D-2 的完整 SBOM 要求\n\ncheck:evidence passed：35 份已登记全部新鲜，0 过期 / 0 例外 / 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-17T19:21:00-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/2dfbcb9148a7beabb926462eebb82645e548c10a...314c179366fb02a53485f4efbd0e3d3e88cd5470","Len":3}...
|
1789698065
|
Edit
Delete
|
|
30740
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"2dfbcb914 {"Commits":[{"Sha1":"2dfbcb9148a7beabb926462eebb82645e548c10a","Message":"chore(reports): 回绑 @ a9fd6e8，check:evidence 全绿\n\n33 份已登记全部新鲜，0 过期 / 0 未提交输入 / 0 例外 / 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-17T19:00:52-07:00"},{"Sha1":"a9fd6e826db77532ac3abfc149a9de822e40ea12","Message":"chore(governance): 退役 stack-image-pins，check:evidence 首次转 passed\n\n目录负责人裁决：按该报告自己的例外里写的「倾向 ① 退役」执行。\n\n它与今日退役的另两份同类：仓内无生成脚本（2026-09-14 全仓搜索确认），是\n一次性手工产物，永远无法重跑，只能靠例外掩盖。其结论「compose 12 个镜像\n是否全按 digest 锁定」已由 governance/release-manifest.mjs 的\nparseComposeImages 完整覆盖——实测同为 12 条、0 未锁，且未锁时进 missing，\n由真脚本产出、自动保鲜，严格优于被退役的手工快照。\n\n- evidence-scopes：entries 34 → 33，exceptions 1 → 0（自此为空）\n- check-evidence-freshness 的成因注释保留 2026-09-14 那条实锤（它正是本门禁\n 存在的理由），但标注该报告已退役，免得后人去找一个不存在的文件\n\ncheck:evidence：**passed**，33 新鲜 / 0 过期 / 0 输入未提交 / 0 例外。\n这是它第一次不是 partial。governance 测试 277/277。\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-17T19:00:17-07:00"}],"HeadCommit":{"Sha1":"2dfbcb9148a7beabb926462eebb82645e548c10a","Message":"chore(reports): 回绑 @ a9fd6e8，check:evidence 全绿\n\n33 份已登记全部新鲜，0 过期 / 0 未提交输入 / 0 例外 / 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-17T19:00:52-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/e6d286b4f61d0227fa7f42cd0f5f40e624540dbf...2dfbcb9148a7beabb926462eebb82645e548c10a","Len":2}...
|
1789696855
|
Edit
Delete
|
|
30730
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"e6d286b4f {"Commits":[{"Sha1":"e6d286b4f61d0227fa7f42cd0f5f40e624540dbf","Message":"docs: 修复退役报告导致的断链（一致性门禁 L4）\n\n09-12 的候选校验记录链向 reports/mainline-candidate-regression.latest.json，\n该报告已随 23281b8 退役，治理层一致性门禁 L4 随即报断链。改为文字说明：\n报告已退役、退役理由、结论现由 governance 测试产出（今 277/277），当时的\n154/0/1 保留为历史记录，不改写历史结论。\n\nL4 / L10 / L13 恢复 CLEAN。\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-17T18:58:04-07:00"}],"HeadCommit":{"Sha1":"e6d286b4f61d0227fa7f42cd0f5f40e624540dbf","Message":"docs: 修复退役报告导致的断链（一致性门禁 L4）\n\n09-12 的候选校验记录链向 reports/mainline-candidate-regression.latest.json，\n该报告已随 23281b8 退役，治理层一致性门禁 L4 随即报断链。改为文字说明：\n报告已退役、退役理由、结论现由 governance 测试产出（今 277/277），当时的\n154/0/1 保留为历史记录，不改写历史结论。\n\nL4 / L10 / L13 恢复 CLEAN。\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-17T18:58:04-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/36e0423efe0ddc105136d193bfb594efb9838d62...e6d286b4f61d0227fa7f42cd0f5f40e624540dbf","Len":1}...
|
1789696688
|
Edit
Delete
|