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