| event_payload |
{"ref":"refs/heads/main","befo {"ref":"refs/heads/main","before":"0c6a1918aa223b1779ce4653ba2c4e4609aea336","after":"c190a6ab5d2c50e4c90f027bbcca72f1f3050005","compare_url":"https://gitea.g-hi.com/luoanwu/enterprise-platform/compare/0c6a1918aa223b1779ce4653ba2c4e4609aea336...c190a6ab5d2c50e4c90f027bbcca72f1f3050005","commits":[{"id":"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","url":"https://gitea.g-hi.com/luoanwu/enterprise-platform/commit/c190a6ab5d2c50e4c90f027bbcca72f1f3050005","author":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"committer":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"verification":null,"timestamp":"2026-09-18T07:43:48-07:00","added":["contracts/src/domain/notification-webhook/value-guards.ts"],"removed":[],"modified":["contracts/SOURCE.md","contracts/src/domain/notification-webhook/fixture-evaluator.ts","contracts/src/domain/notification-webhook/notification-effect.ts","contracts/src/domain/notification-webhook/webhook-delivery-planner.ts","contracts/test/fixtures/notification-webhook.fixtures.json","contracts/test/notification-webhook-domain.test.mjs"]},{"id":"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","url":"https://gitea.g-hi.com/luoanwu/enterprise-platform/commit/9d13fb058d2a0356797f26d1d17a4b2149b6ab97","author":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"committer":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"verification":null,"timestamp":"2026-09-18T07:42:44-07:00","added":[],"removed":[],"modified":["docs/runbook.md"]},{"id":"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","url":"https://gitea.g-hi.com/luoanwu/enterprise-platform/commit/13c7eb7271af67df9d0b4e5223bda3eaa4ab7b10","author":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"committer":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"verification":null,"timestamp":"2026-09-18T07:42:22-07:00","added":[],"removed":[],"modified":["contracts/SOURCE.md","contracts/src/domain/cross-domain-workflow/workflow-definition.ts","contracts/src/domain/cross-domain-workflow/workflow-planner.ts","contracts/test/cross-domain-workflow-domain.test.mjs","contracts/test/fixtures/cross-domain-workflow.fixtures.json","docs/domain/workflow-definition-blueprint.md"]},{"id":"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","url":"https://gitea.g-hi.com/luoanwu/enterprise-platform/commit/5720165763b35035e6778fe9a802493a16eb5aca","author":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"committer":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"verification":null,"timestamp":"2026-09-18T07:41:37-07:00","added":[],"removed":[],"modified":["contracts/SOURCE.md","contracts/src/domain/collaboration-messaging/conversation-admission-planner.ts","contracts/src/domain/collaboration-messaging/conversation-message.ts","contracts/src/domain/collaboration-messaging/fixture-evaluator.ts","contracts/test/collaboration-messaging-domain.test.mjs","contracts/test/fixtures/collaboration-messaging.fixtures.json","docs/domain/conversation-message-blueprint.md","governance/evidence-scopes.json"]},{"id":"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","url":"https://gitea.g-hi.com/luoanwu/enterprise-platform/commit/793d0a106f07c2b9974991a2a5953fdebc5be1b3","author":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"committer":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"verification":null,"timestamp":"2026-09-18T07:38:28-07:00","added":[],"removed":[],"modified":["contracts/SOURCE.md","contracts/src/domain/public-file/fixture-evaluator.ts","contracts/src/domain/public-file/index.ts","contracts/src/domain/public-file/public-file-access-planner.ts","contracts/src/domain/public-file/public-file-ref.ts","contracts/test/fixtures/public-file.fixtures.json","contracts/test/public-file-domain.test.mjs","docs/domain/public-file-ref-blueprint.md"]}],"total_commits":0,"head_commit":{"id":"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","url":"https://gitea.g-hi.com/luoanwu/enterprise-platform/commit/c190a6ab5d2c50e4c90f027bbcca72f1f3050005","author":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"committer":{"name":"juhailaoluo pro","email":"hillao@juhailaoluodeMacBook-Pro.local","username":""},"verification":null,"timestamp":"2026-09-18T07:43:48-07:00","added":["contracts/src/domain/notification-webhook/value-guards.ts"],"removed":[],"modified":["contracts/SOURCE.md","contracts/src/domain/notification-webhook/fixture-evaluator.ts","contracts/src/domain/notification-webhook/notification-effect.ts","contracts/src/domain/notification-webhook/webhook-delivery-planner.ts","contracts/test/fixtures/notification-webhook.fixtures.json","contracts/test/notification-webhook-domain.test.mjs"]},"repository":{"id":116,"owner":{"id":5,"login":"luoanwu","login_name":"","source_id":0,"full_name":"","email":"law@g-hi.com","avatar_url":"https://gitea.g-hi.com/avatar/627574a890388a2aadc80ab38d22f3a0","html_url":"https://gitea.g-hi.com/luoanwu","language":"","is_admin":false,"last_login":"0001-01-01T00:00:00Z","created":"2026-01-30T16:28:30+08:00","restricted":false,"active":false,"prohibit_login":false,"location":"","website":"","description":"","visibility":"public","followers_count":0,"following_count":0,"starred_repos_count":0,"username":"luoanwu"},"name":"enterprise-platform","full_name":"luoanwu/enterprise-platform","description":"","empty":false,"private":false,"fork":false,"template":false,"mirror":false,"size":18768,"language":"","languages_url":"https://gitea.g-hi.com/api/v1/repos/luoanwu/enterprise-platform/languages","html_url":"https://gitea.g-hi.com/luoanwu/enterprise-platform","url":"https://gitea.g-hi.com/api/v1/repos/luoanwu/enterprise-platform","link":"","ssh_url":"git@gitea.g-hi.com:luoanwu/enterprise-platform.git","clone_url":"https://gitea.g-hi.com/luoanwu/enterprise-platform.git","original_url":"","website":"","stars_count":0,"forks_count":0,"watchers_count":1,"branch_count":43,"open_issues_count":0,"open_pr_counter":0,"release_counter":0,"default_branch":"main","archived":false,"created_at":"2026-09-11T07:33:25+08:00","updated_at":"2026-09-18T22:43:29+08:00","archived_at":"1970-01-01T08:00:00+08:00","permissions":{"admin":true,"push":true,"pull":true},"has_code":true,"has_issues":true,"internal_tracker":{"enable_time_tracker":true,"allow_only_contributors_to_track_time":true,"enable_issue_dependencies":true},"has_wiki":true,"has_pull_requests":true,"has_projects":true,"projects_mode":"all","has_releases":true,"has_packages":true,"has_actions":true,"ignore_whitespace_conflicts":false,"allow_merge_commits":true,"allow_rebase":true,"allow_rebase_explicit":true,"allow_squash_merge":true,"allow_fast_forward_only_merge":true,"allow_rebase_update":true,"allow_manual_merge":false,"autodetect_manual_merge":false,"default_delete_branch_after_merge":false,"default_merge_style":"merge","default_allow_maintainer_edit":true,"avatar_url":"","internal":false,"mirror_interval":"","object_format_name":"sha1","mirror_updated":"0001-01-01T00:00:00Z","topics":[],"licenses":[]},"pusher":{"id":5,"login":"luoanwu","login_name":"","source_id":0,"full_name":"","email":"5+luoanwu@noreply.localhost","avatar_url":"https://gitea.g-hi.com/avatar/627574a890388a2aadc80ab38d22f3a0","html_url":"https://gitea.g-hi.com/luoanwu","language":"","is_admin":false,"last_login":"0001-01-01T00:00:00Z","created":"2026-01-30T16:28:30+08:00","restricted":false,"active":false,"prohibit_login":false,"location":"","website":"","description":"","visibility":"public","followers_count":0,"following_count":0,"starred_repos_count":0,"username":"luoanwu"},"sender":{"id":5,"login":"luoanwu","login_name":"","source_id":0,"full_name":"","email":"5+luoanwu@noreply.localhost","avatar_url":"https://gitea.g-hi.com/avatar/627574a890388a2aadc80ab38d22f3a0","html_url":"https://gitea.g-hi.com/luoanwu","language":"","is_admin":false,"last_login":"0001-01-01T00:00:00Z","created":"2026-01-30T16:28:30+08:00","restricted":false,"active":false,"prohibit_login":false,"location":"","website":"","description":"","visibility":"public","followers_count":0,"following_count":0,"starred_repos_count":0,"username":"luoanwu"}}... |