progmune-runtime 3.7.52 → 3.7.53

package/CHANGELOG.md

@@ -1,5 +1,43 @@
 # Changelog
 
+## [3.7.53] — 2026-09-26
+
+### 授权族误报压降收口 + 三处可见性基建（§35-§46 合并发布）
+
+**可见性基建（§35-§37，只读探针，不进产品路径）**：跨函数调用链视图原型；采样单位从
+「文件」换成「入口的调用闭包」；入口根可达性视图（「谁会走到我」）。三者共同解决
+**切片看不出跨函数证据**的问题——后续每一轮压降都靠它们回答「这一刀在哪个语料上被触发」。
+
+**两处判据进主干（§38、§39）**：
+- 对象级授权判据从「动词白名单」换成「组合式谓语」，不再靠 `get/list/create` 这类词根猜语义
+- D 类自指排除：把**鉴权机制自身**也识别为 auth function（此前机制代码被当成未鉴权的业务代码）
+
+**授权族压降（§40-§46）**：
+- §42 补 `webshape_G`（17 条授权形态）——**此前盲测在授权命名轴上根本没有差分能力**，
+  改任何判据都看不出效果；补形后项目 117→118、Authorization 族 938→947
+- §44 `paramGated`：**标量参数不是调用者身份**。函数参数名出现 `userId/ownerId` 但类型是
+  裸 string/number 的，不再当鉴权证据（`classifyParamType` 三分类）；真实池 337→333、
+  盲测 2887→2618，269 条损失全为 dispatcher 重复投影
+- §45 修同族 safeguard 词表漂移（Unauthenticated Access 缺 `getSession/validateSession/
+  verifyToken`）——漂移的表现是**同样形状的一条报、一条不报**；盲测 2618→2610
+- §46 ① `credential_issuance`：`create_*_token` 语义是**签发**不是**校验**，从 `auth_check`
+  移出单列（行为不变，消除误改诱因）；② `owner_self_assigned`：只认**绑定形态**
+  `{ownerId: user.id}`，不认实参形态 `f(x, user.id)`（真实池 3/3 FP vs 合成 1/1 TP，
+  真值相反 ⇒ R71），同刻比对压掉 197 条全 FP、真漏洞零伤
+
+**三条被数据否决的（不落地）**：§43「容器后缀=Service」（造不出反例，R66）、
+§45「triggerOwnNameOnly」（R66 二次命中）、§46③「safeguard 只看调用不看是否检查返回结果」
+（新增 26 条全是已知 dispatcher 误报，收益 0，R72）。
+
+**方法学累计**：R66-R73。其中两条是**基线陷阱**——R67（冻结母本不是同刻基线，误报压制数
+48→真实 4）、R73（上一次的 results 也不是同刻基线，误报压制数 12→真实 197，低估 16 倍）。
+正确口径只有一个：**摘掉这一刀、其余不动、重跑**。次要：R68（dist 不是 src 的同步副本，
+陈旧是静默的）、R69（同族词表要定期做集合 diff）、R70（label 必须与语义一致）。
+
+**门**：tsc 0 错 / webshape 66-0 / taintpath 160-0 / fr-007 pre5·post0 + fr-016 pre7·post0 /
+定向 9 文件 329 条全绿 / 反向验证：② 摘刀 197 条全部回来、① 摘刀 fixture 转红、
+REVERSE-VERIFY 残留 0 / 真实切片 LOST 0·ADDED 0
+
 ## [3.7.52] — 2026-09-23
 
 ### 语料补形 + 两处基础设施修复 + E4/E5 两个确定性通道（§26-§31 合并发布）

package/dist/extract-ir.js

@@ -379,6 +379,19 @@ function extractDirectCalls(func, preText) {
     if (/ownerId\s*[!=]==?|authorId\s*[!=]==?|createdBy\s*[!=]==?|\.owner\s*[!=]==?|userId\s*[!=]==?/.test(text)) {
         calls.push("__progmune_ownership_checked__");
     }
+    // §46 ②：新建资源的属主被**赋值为当前主体**（`{ userId: user.id }` / `ownerId: currentUser.id`）。
+    // 这类「创建」函数的被操作对象就是主体自己，不存在「改别人的东西」这回事 ⇒
+    // Ownership Check 不该报（合成语料上 10/10 是 FP：createTransfer / createRefund /
+    // uploadFile / placeOrder…）。调用名接口看不到对象字面量里的赋值，只能靠标记。
+    //
+    // ⚠ 只认 `<属主字段>: <主体>.id` 这一种形态，**不认** `<调用>(..., user.id, ...)`：
+    //   后者是「主体标识作实参」，实测同形状存在相反真值 ——
+    //   `deletePAT(id, user.uid)`（已按属主过滤，FP）vs `deleteWidget(id)` 里
+    //   `canSendEmail(user.id)`（user.id 与 deleteWidget 无关，真 TP）⇒ 按 R66 不得落地。
+    // 形态：`<属主字段>: <主体变量>.<标识属性>` （对象字面量内的赋值，不是查询比较）
+    if (/\b(?:userId|ownerId|authorId|createdBy|user_id|owner_id|author_id|created_by)\s*:\s*(?:user|currentUser|authUser|me|self|actor|principal|adminUser|(?:request|req|session|ctx|context)\.user)\s*\.\s*(?:id|uid|_id|userId|email|username)\b/i.test(text)) {
+        calls.push("__progmune_owner_self_assigned__");
+    }
     return [...new Set(calls)];
 }
 // ═══════════════════════════════════════════════════════════════

package/dist/protocol-detector-acronym.test.js

@@ -0,0 +1,118 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §41 E1（2026-09-25）：token 内嵌 acronym 的**局部**补认 —— 正/反向 fixture
+ *
+ * 背景：C5 原案是「改主干 identifierParse 让 JWTPayload 拆出 JWT」。
+ * `split-probe.ts` 实测否决了它（详见 src 里 ACRONYM_PREFIX 的注释）：
+ *   803 个去重标识符里只有 16 个受影响、新增 22 词中仅 2 个（JWT/OIDC）是机制类，
+ *   其余是 `OAuthToken→Auth`、`createATeam→A,Team` 这类噪声；
+ *   而 identifierParse 还供给 triggerParsedWords ⇒ 动它等于改全局触发面。
+ * ⇒ 最终落地的是**只在 isAuthMachineryName 的对象侧**补认 acronym。
+ *
+ * 为什么必须有这里的 fixture（同 §40，R56）：改动方向是「压掉告警」，
+ * 而 generated/ 合成语料里**没有** `verifyJWTPayload` 这类形态 ⇒
+ * 盲测零漂移很可能是零触发。**这里是唯一能证明这段判据活着的证据。**
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+/** 只关心 authorization 类目（本轮只影响这一类目） */
+const authz = (fnName, calls = ["deleteSpace", "findOne"]) => (0, protocol_detector_1.detectSafeguardViolations)(calls, fnName, "typescript", ["user", "id"], true).filter((v) => /^Authorization/i.test(v.rule));
+(0, vitest_1.describe)("§41 E1 正向：acronym 卡在函数名的机制对象里（应该被认成鉴权机制）", () => {
+    (0, vitest_1.it)("verifyJWTPayload —— §40 剩余池待救的那条（verdaccio packages/auth/src/utils.ts）", () => {
+        (0, vitest_1.expect)(authz("verifyJWTPayload")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("verifyJWTPayload 带触发 trigger 也一样压", () => {
+        (0, vitest_1.expect)(authz("verifyJWTPayload", ["getTarball", "readPackage"])).toHaveLength(0);
+    });
+    (0, vitest_1.it)("JWTRemote 类托管的 jwt 机制方法", () => {
+        (0, vitest_1.expect)(authz("JwtRemote.getJWTRemote")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("类限定形式 AvailabilityService.verifyJWTPayload", () => {
+        (0, vitest_1.expect)(authz("AvailabilityService.verifyJWTPayload")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("createJWTToken —— 唯有 E1 才救得回来的一条（反向验证揪出来的错误假设）", () => {
+        // ⚠ 这条曾经被我标成「BASE 就命中」，是**错的**：
+        //   identifierParse("createJWTToken") → ["create","JWTToken"]
+        //   ⇒ 对象侧只拿到 "jwttoken"，既 ≠ jwt 也 ≠ token ⇒ BASE **不命中**。
+        //   反向验证（把 machineryWords 退回 identifierParse）让它转红才发现。
+        //   教训同 R59：凭印象断言既有行为，与口径漂移是同一类错误。
+        (0, vitest_1.expect)(authz("createJWTToken")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("⚠ verifyOIDCToken 不收 —— oidc 只在**容器侧**名词表，**不在方法对象词表**", () => {
+        // §39.8 的收窄是有意的：对象侧一旦放宽到 oauth/oidc/saml，
+        // `ApiTokensController.deleteToken` 这类凭据 CRUD 会被误压（V-D 教训）。
+        // 剩余池里没有待救的 verifyOIDCToken 形态 ⇒ 按 R50 不为此扩词表。
+        (0, vitest_1.expect)(authz("verifyOIDCToken").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("verifySSLSignature 不在机制对象词表 ⇒ 仍报（词表不含 ssl，别幻想）", () => {
+        (0, vitest_1.expect)(authz("verifySSLSignature").length).toBeGreaterThan(0);
+    });
+});
+/**
+ * `tokenAcronyms` 的直接单元测试 —— 端到端 fixture 覆盖不到这两条约束，
+ * 因为**对象侧 acronym 与 BASE 的重叠度极高**（凡 acronym 等于 jwt/token/…
+ * 的，BASE 下独立 token 本来也就命中了），端到端分不出「约束生效」与
+ * 「恰好 BASE 也命中」。剩下来真正会被 `${2,}` 拦住的，只有单字母情形。
+ */
+(0, vitest_1.describe)("§41 tokenAcronyms 表驱动：两条约束（≥2 字母 / 贪婪回溯）", () => {
+    const cases = [
+        ["JWTPayload", ["JWT"]],
+        ["OIDCStrategy", ["OIDC"]], // ← 贪婪：非贪婪会停在 "OID"，救不了这条
+        ["HTTPErr", ["HTTP"]],
+        ["CLIError", ["CLI"]],
+        ["JWTToken", ["JWT"]],
+        // 以下必须为空：单字母 / 纯 PascalCase / 已有独立词
+        ["OAuth", []], // ← 放宽到 {1,} 就会产出 "O"
+        ["ATeam", []],
+        ["YElement", []],
+        ["Token", []],
+        ["Payload", []],
+        ["payload", []],
+        ["JWTPayloadService", ["JWT"]], // 边界：最后一个大写归后词 ⇒ 不会吃成 "JWTP"
+    ];
+    for (const [input, want] of cases) {
+        (0, vitest_1.it)(`${input} → ${JSON.stringify(want)}`, () => {
+            (0, vitest_1.expect)((0, protocol_detector_1.tokenAcronyms)(input)).toEqual(want);
+        });
+    }
+});
+(0, vitest_1.describe)("§41 E1 反向：不得把非机制名字误认成机制（R57 宽变体约束）", () => {
+    (0, vitest_1.it)("⚠ validateOAuthToken —— BASE 就会命中（validate × Token），与 acronym 无关", () => {
+        // 存在意义：端到端根本测不出「OAuth 被拆出 Auth」—— 因为这条 BASE 下也压。
+        // 若有人把 `{2,}` 放宽成 `{1,}`，`OAuth` → "O"，而 "O" 不在任何词表里
+        // ⇒ 端到端行为完全不变，**回归无从发现**。单字母噪声只有在表驱动层才可见。
+        (0, vitest_1.expect)(authz("validateOAuthToken")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("⚠ createATeam 不得拆出 Team 之外的机制词", () => {
+        (0, vitest_1.expect)(authz("AdminService.createATeam").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ throwHTTPErr 不得因 HTTP 被当成机制", () => {
+        (0, vitest_1.expect)(authz("throwHTTPErr").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ createCLIErrorResponse 不得因 CLI/Error 被当成机制", () => {
+        (0, vitest_1.expect)(authz("createCLIErrorResponse").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ 纯 PascalCase 词不得被再切一遍（Token → T/oken 之类的臆想不生效）", () => {
+        (0, vitest_1.expect)(authz("deleteExpiredToken").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ 动词缺失 ⇒ acronym 对象不算（只有对象没有机制动词）", () => {
+        // mw 必须同时含 VERB × OBJECT；JWTPayload 单独不是机制
+        (0, vitest_1.expect)(authz("logJWTPayload").length).toBeGreaterThan(0);
+    });
+    /**
+     * 最要紧的一条反向：**凭据增删改**即使名字里含 JWT 也不能压 —— 与 §39 V-D、
+     * §40 W4 同源教训。这条守的是「约束在于组合，不在于 acronym 本身」。
+     */
+    (0, vitest_1.it)("⚠️ createJWTToken 是依赖 E1 的哨兵 ⇒ 反向验证时必须转红", () => {
+        // §41 反向验证实测（把 machineryWords 退回 identifierParse）：
+        // 全套 76 条里 **6 条**转红，其余 70 条（§38/§39/§40）纹丝不动
+        // ⇒ E1 的影响面被严格锁在「机制对象侧 acronym」这一格，没有横向污染。
+        // 这条 earlier 被错写成「GENERATE 类动词…既有口径一致」—— 与 R59 同源的
+        // 「凭印象断言既有行为」，已据反向验证的实测更正。
+        (0, vitest_1.expect)(authz("createJWTToken")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("⚠ 与 §40 C4 的分工：容器=Auth 且方法受保护动词开头 ⇒ 不压", () => {
+        (0, vitest_1.expect)(authz("Auth.changeJWTToken").length).toBeGreaterThan(0);
+    });
+});

package/dist/protocol-detector-authz-drift.test.js

@@ -0,0 +1,65 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §45：Authorization (Unauthenticated Access) 的 auth_check 词表漂移修复。
+ *
+ * 病灶：同一族的 Unauthenticated Mutation 认 `getSession` / `validateSession` / `verifyToken`，
+ *       Unauthenticated Access 只认 `getSessionUser`，**不认裸 `getSession`**。
+ *       于是「先取会话再操作」的读类函数被判成「未认证即可读」—— 真实案例 filestorage 的
+ *       uploadFile / deleteFile / createFolder / createShareLink 四条（体里都有
+ *       `const user = getSession(token); if (!user) return null;`）。
+ *
+ * 修复：把三个词补进 Access 规则的 auth_check（与 Mutation 对齐）。
+ * 不做：三个 mint 类词（create_access_token / create_jwt_token / create_refresh_token）——
+ *       「签发令牌」不是「校验调用者」，语义不同，不在本轮（见设计文档 §45.6）。
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+const ACC = "Authorization (Unauthenticated Access)";
+const MUT = "Authorization (Unauthenticated Mutation)";
+/** 单 LANGUAGE=typescript；paramGate 用 user:User 放行（类型是非标量领域类型） */
+function dsv(calls, name) {
+    return (0, protocol_detector_1.detectSafeguardViolations)(calls, name, "typescript", ["user"], false, ["User"]);
+}
+const has = (calls, name, rule) => dsv(calls, name).some((v) => v.rule === rule);
+(0, vitest_1.describe)("§45 getSession 漂移：读类函数已取会话 ⇒ 不再报 Unauthenticated Access", () => {
+    (0, vitest_1.it)("getSession 应被认作认证检查（filestorage uploadFile 原型）", () => {
+        (0, vitest_1.expect)(has(["getSession", "join", "writeFileSync"], "uploadFile", ACC)).toBe(false);
+    });
+    (0, vitest_1.it)("validateSession 应被认作认证检查", () => {
+        (0, vitest_1.expect)(has(["validateSession", "find"], "listDocuments", ACC)).toBe(false);
+    });
+    (0, vitest_1.it)("verifyToken 应被认作认证检查", () => {
+        (0, vitest_1.expect)(has(["verifyToken", "find"], "getDocument", ACC)).toBe(false);
+    });
+    (0, vitest_1.it)("类限定调用形态 this.auth.getSession() 也成立（identifierParse 拆词后命中）", () => {
+        (0, vitest_1.expect)(has(["this", "auth", "getSession", "find"], "deleteFile", ACC)).toBe(false);
+    });
+});
+(0, vitest_1.describe)("§45 反向对照：真正的未认证读取必须仍然报", () => {
+    (0, vitest_1.it)("getDocuments 无任何认证调用 ⇒ 仍报", () => {
+        (0, vitest_1.expect)(has(["find", "filter"], "getDocuments", ACC)).toBe(true);
+    });
+    (0, vitest_1.it)("listReports 无任何认证调用 ⇒ 仍报", () => {
+        (0, vitest_1.expect)(has(["filter", "map"], "listReports", ACC)).toBe(true);
+    });
+    (0, vitest_1.it)("downloadExport 无任何认证调用 ⇒ 仍报", () => {
+        (0, vitest_1.expect)(has(["readFileSync", "pipe"], "downloadExport", ACC)).toBe(true);
+    });
+    (0, vitest_1.it)("getSessionUser 之外的无关 get* 不构成认证证据（getConfig 类）", () => {
+        // getConfig 走 excludePatterns；这里用 getUniqueId 确保普通取值不算检查
+        (0, vitest_1.expect)(has(["getUniqueId", "find"], "listAuditLogs", ACC)).toBe(true);
+    });
+});
+(0, vitest_1.describe)("§45 与 Mutation 规则的对称性：同一形态两条规则都不报", () => {
+    const calls = ["getSession", "find"];
+    (0, vitest_1.it)("读侧", () => (0, vitest_1.expect)(has(calls, "listInvoices", ACC)).toBe(false));
+    (0, vitest_1.it)("写侧", () => (0, vitest_1.expect)(has(["getSession", "push"], "createInvoice", MUT)).toBe(false));
+});
+(0, vitest_1.describe)("§45 已知未覆盖范围（登记为债，不是 bug）", () => {
+    (0, vitest_1.it)("⚠ 只看「是否调用」getSession，不看「是否检查其结果」—— 这是既有宽松", () => {
+        // `const u = getSession(t); return data;` （不检查 u）仍会被判为已认证。
+        // 单函数视角拿不到数据流，本轮不修；见设计文档 §45.6。
+        (0, vitest_1.expect)(has(["getSession", "return"], "getEverything", ACC)).toBe(false);
+    });
+});

package/dist/protocol-detector-authz-machinery.test.js

@@ -0,0 +1,83 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §39（2026-09-25）D 类自指排除 —— 正/反向 fixture
+ *
+ * 为什么必须有这个文件：与 §38 同因。本轮改的是「哪些函数算鉴权机制自身」，
+ * 盲测语料（blind-benchmark/generated/ 合成项目）里没有 JwtAuthGuard /
+ * AbilityFactory 这类形态 ⇒ 盲测会零漂移，但同时**一条都没触发**（R56：
+ * 零漂移 ≠ 验证通过）。没有这里的 fixture，这段判据就是零覆盖进主干。
+ *
+ * ⚠ 反向 fixture 比正向更要紧：这条判据的作用是**压掉**告警，
+ *   压错方向就是真漏报且不可见（R49 的镜像）。所以每一条「不得压掉」的
+ *   形态都必须钉死，尤其是**对凭据做增删改**的端点（那是最需要鉴权的地方）。
+ *
+ * 每条都对应真值集/真实扫描里人工核对过的代码：
+ *   JwtAuthGuard.handleRequest        ← docmost src/common/guards/jwt-auth.guard.ts
+ *   WorkspaceAbilityFactory.createForUser ← docmost src/core/casl/abilities/
+ *   ApiTokensController.deleteToken   ← hedgedoc（凭据 CRUD，不得压）
+ *   AccessTokenService.updateLastUsedForPAT ← hoppscotch（凭据 CRUD，不得压）
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+/** 只关心 authorization 类目（本轮只影响这一类目） */
+const authz = (fnName) => (0, protocol_detector_1.detectSafeguardViolations)(["deleteSpace", "findOne"], fnName, "typescript", ["user", "id"], true).filter((v) => /^Authorization/i.test(v.rule));
+(0, vitest_1.describe)("§39 自指排除 —— 正对照（鉴权机制自身 ⇒ 压掉）", () => {
+    (0, vitest_1.it)("JwtAuthGuard 守卫本体", () => {
+        (0, vitest_1.expect)(authz("JwtAuthGuard.handleRequest")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("JwtAuthGuard 里写 cookie", () => {
+        (0, vitest_1.expect)(authz("JwtAuthGuard.setJoinedWorkspacesCookie")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("Auth 控制器置 cookie（登录流程的一部分）", () => {
+        (0, vitest_1.expect)(authz("AuthController.setAuthCookie")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("Auth 服务签发协作 token", () => {
+        (0, vitest_1.expect)(authz("AuthService.getCollabToken")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("Token 服务校验 jwt（纯原语）", () => {
+        (0, vitest_1.expect)(authz("TokenService.verifyJwt")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("CASL 授权引擎本体", () => {
+        (0, vitest_1.expect)(authz("WorkspaceAbilityFactory.createForUser")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("签发 JWT", () => {
+        (0, vitest_1.expect)(authz("UserService.generateJWT")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("从请求里取 token（裸函数名，无类限定）", () => {
+        (0, vitest_1.expect)(authz("getApiToken")).toHaveLength(0);
+    });
+});
+(0, vitest_1.describe)("§39 自指排除 —— 反对照（不是机制 ⇒ 不得压掉）", () => {
+    (0, vitest_1.it)("业务函数：删收藏（「user 作为实参」的 B 类，不是机制）", () => {
+        (0, vitest_1.expect)(authz("FavoriteController.removeFavorite").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("业务函数：删附件图标", () => {
+        (0, vitest_1.expect)(authz("AttachmentController.removeIcon").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("业务函数：删空间", () => {
+        (0, vitest_1.expect)(authz("SpaceController.deleteSpace").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ 凭据 CRUD：删 token —— 最需要鉴权，绝不能压", () => {
+        (0, vitest_1.expect)(authz("ApiTokensController.deleteToken").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ 凭据 CRUD：删 PAT —— 绝不能压", () => {
+        (0, vitest_1.expect)(authz("AccessTokenController.deletePAT").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ 凭据 CRUD：改 PAT 使用时间 —— 绝不能压", () => {
+        (0, vitest_1.expect)(authz("AccessTokenService.updateLastUsedForPAT").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("限流守卫不是鉴权机制（ThrottlerGuard）", () => {
+        (0, vitest_1.expect)(authz("ThrottlerGuard.handleRequest").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("通用设计模式后缀不是鉴权机制（CacheStrategy）", () => {
+        // 只看 Strategy 后缀会误吃 —— 必须配凭据名词约束
+        (0, vitest_1.expect)(authz("CacheStrategy.get").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("受保护操作：改密码不属于机制", () => {
+        (0, vitest_1.expect)(authz("AuthService.changePassword").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("待定用户数据删除不属于机制", () => {
+        (0, vitest_1.expect)(authz("AuthController.deletePendingUserData").length).toBeGreaterThan(0);
+    });
+});

package/dist/protocol-detector-authz-selfpred.test.js

@@ -0,0 +1,105 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §40（2026-09-25）剩余池三处判据缺口 —— 正/反向 fixture
+ *
+ * 与 §38/§39 同因：这三处都是**压掉告警**方向的改动，盲测语料（generated/ 合成项目）
+ * 里没有 `Auth.allow_*` / 裸 `can('publish')` / `canRemove` 这类形态 ⇒ 盲测即便
+ * 零漂移也可能**一条都没触发**（R56：零漂移 ≠ 验证通过）。没有这里的 fixture，
+ * 这三段判据就是零覆盖进主干。
+ *
+ * 三处缺口的来源（都是人工核剩余池 35 条时逐条读源码读出来的）：
+ *   C1 裸 can      — verdaccio `publish()`：`const can = allow(auth, …)`，
+ *                    路由上 `can('publish')`。calls 里是**裸** can，
+ *                    §38 的谓语要求 `can<动作词>` ⇒ 落空。
+ *   C2 自身谓语名  — verdaccio `canRemove` 报 "Ownership Check"：它**就是**那个检查。
+ *                    §39 的自指排除只认 AUTH_PATTERN + 机制名，不认 `can<X>`。
+ *   C4 容器=Auth   — §39.8 记下的未收项：`Auth.allow_*` / `Auth.setLegacyAuthCacheEntry`。
+ *
+ * ⚠⚠ 反向 fixture 比正向更要紧（R57）：C4 的**宽变体**（容器放宽到 `Auth*`）实测会吃掉
+ *   `AuthController.deletePendingUserData` / `Auth.changePassword` / `Auth.invalidateToken`
+ *   —— 对凭据与待处理用户做增删改恰恰是最需要鉴权的地方。所以 C4 必须
+ *   「严格等于裸类名」×「方法是授权决策(allow_)或机制名词」两层约束，两条都要。
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+/** 只关心 authorization 类目（本轮只影响这一类目） */
+const authz = (fnName, calls = ["deleteSpace", "findOne"]) => (0, protocol_detector_1.detectSafeguardViolations)(calls, fnName, "typescript", ["user", "id"], true).filter((v) => /^Authorization/i.test(v.rule));
+(0, vitest_1.describe)("§40 C1 裸 can（CASL ability.can / verdaccio can('publish')）", () => {
+    (0, vitest_1.it)("函数体里调用裸 can ⇒ 认为做了授权判定（verdaccio publish 同形）", () => {
+        // publish 的 trigger 来自 publishPackage / removePackage 等，这里用等价形态
+        (0, vitest_1.expect)(authz("publish", ["can", "put", "publishPackage", "removePackage"])).toHaveLength(0);
+    });
+    (0, vitest_1.it)("裸 cannot 同形", () => {
+        (0, vitest_1.expect)(authz("publish", ["cannot", "put", "publishPackage"])).toHaveLength(0);
+    });
+    (0, vitest_1.it)("限定形式 ability.can（CASL 标准用法）", () => {
+        (0, vitest_1.expect)(authz("publish", ["ability.can", "publishPackage"])).toHaveLength(0);
+    });
+    (0, vitest_1.it)("⚠ cancel 不是 can —— 精确匹配，不得因同形被收", () => {
+        (0, vitest_1.expect)(authz("publish", ["cancel", "publishPackage"]).length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ candidate / canary 也不是 —— 精确匹配钉死", () => {
+        (0, vitest_1.expect)(authz("publish", ["candidate", "canary", "publishPackage"]).length).toBeGreaterThan(0);
+    });
+});
+(0, vitest_1.describe)("§40 C2 函数名自身就是授权谓语（自指）", () => {
+    (0, vitest_1.it)("canRemove 报「缺所有权检查」是自指谬误", () => {
+        (0, vitest_1.expect)(authz("canRemove")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("canPublish 同理", () => {
+        (0, vitest_1.expect)(authz("canPublish")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("cannotDelete 同理（cannot 分支）", () => {
+        (0, vitest_1.expect)(authz("cannotDelete")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("类限定的 Auth.canRemove 同理", () => {
+        (0, vitest_1.expect)(authz("StorageViewCommand.canRemove")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("⚠ canSendEmail 是限流器不是权限判定 —— 不得收（§38.4 ② 的老反例）", () => {
+        (0, vitest_1.expect)(authz("canSendEmail").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ 名字像谓语但动作词不在表内（canRenderPreview）不得收", () => {
+        (0, vitest_1.expect)(authz("canRenderPreview").length).toBeGreaterThan(0);
+    });
+});
+(0, vitest_1.describe)("§40 C4 容器严格等于鉴权类 × 授权决策/机制方法", () => {
+    (0, vitest_1.it)("Auth.allow_publish —— 授权决策本体（verdaccio）", () => {
+        (0, vitest_1.expect)(authz("Auth.allow_publish")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("Auth.allow_access / allow_unpublish / allow_stage 同族", () => {
+        (0, vitest_1.expect)(authz("Auth.allow_access")).toHaveLength(0);
+        (0, vitest_1.expect)(authz("Auth.allow_unpublish")).toHaveLength(0);
+        (0, vitest_1.expect)(authz("Auth.allow_stage")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("Auth.setLegacyAuthCacheEntry —— 鉴权缓存内部", () => {
+        (0, vitest_1.expect)(authz("Auth.setLegacyAuthCacheEntry")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("Authorization.allow_access 同形", () => {
+        (0, vitest_1.expect)(authz("Authorization.allow_access")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("⚠ Auth.changePassword —— 受保护操作，绝不能压", () => {
+        (0, vitest_1.expect)(authz("Auth.changePassword").length).toBeGreaterThan(0);
+    });
+    /**
+     * ⚠ 这里踩到一个「测不出来」的坑，记录清楚免得后人以为 C4 放行了它：
+     * `Auth.invalidateToken` **在 C4 层确实被 PROTECTED_VERB（invalidate）拦下**，
+     * 但 §39 的 AUTH_PATTERN 里本来就有 `invalidate`（登出/会话失效入口），
+     * 且它按 identifierParse **逐词**匹配 ⇒ "invalidateToken" 拆出 invalidate ⇒ 先命中。
+     * 所以整条链路的结果是"压掉"，但**不是 C4 压的**。
+     * ⇒ 改成直接断言 C4 这一层，避免把别人的行为记到自己账上。
+     */
+    (0, vitest_1.it)("⚠ Auth.invalidateToken —— C4 层必须拦下（受保护动词）", () => {
+        (0, vitest_1.expect)((0, protocol_detector_1.isAuthDecisionName)("Auth.invalidateToken")).toBe(false);
+    });
+    (0, vitest_1.it)("⚠ Auth.add_user —— 用户管理操作，绝不能压", () => {
+        (0, vitest_1.expect)(authz("Auth.add_user").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ AuthController.deletePendingUserData —— 容器不是裸 Auth，绝不能压（§39 V-D 教训）", () => {
+        (0, vitest_1.expect)(authz("AuthController.deletePendingUserData").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("⚠ AuthService.getCollabToken 之外的业务方法不受影响（AuthService.updateToken）", () => {
+        // AuthService 不在"严格等于裸类名"集合里 ⇒ 只有 §39 的机制动词×对象能救
+        (0, vitest_1.expect)(authz("AuthService.updateToken").length).toBeGreaterThan(0);
+    });
+});

package/dist/protocol-detector-authz.test.js

@@ -0,0 +1,78 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §38（2026-09-25）组合式授权谓语 safeguard —— 正/反向 fixture
+ *
+ * 为什么必须有这个文件：3.7.28–3.7.31 的正则死循环溜过 CI，根因就是
+ * 「新增的正则路径没有任何 fixture 触发过它」。本轮新增的三条 safeguard 同理：
+ * 盲测语料（blind-benchmark/generated/，合成项目）里**根本没有** cannot/canRemove
+ * 这类 CASL 形态 ⇒ 盲测 2865 条零漂移，但也**一条都没触发**（§38.8）。
+ * 没有这里的 fixture，这三条正则就是**零覆盖**进主干的。
+ *
+ * 每条正对照都对应真值集里人工核对过的真实代码：
+ *   cannot                  ← docmost SpaceController.deleteSpace
+ *   canRemove               ← verdaccio StorageViewCommand.deleteEntry
+ *   validateCanEdit         ← docmost AttachmentController.uploadFile
+ *   checkMediaDeletePermission ← hedgedoc MediaController.deleteMedia
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+/** 只看所有权/资源所有权两条（本轮只改了这两条的 safeguards） */
+const own = (calls, fnName) => (0, protocol_detector_1.detectSafeguardViolations)(calls, fnName, "typescript", ["user", "id"], true).filter((v) => /Ownership/i.test(v.rule));
+(0, vitest_1.describe)("§38 组合式授权谓语 —— 正对照（有授权 ⇒ 抑制）", () => {
+    (0, vitest_1.it)("cannot（CASL 否定谓语）应抑制 Ownership Check", () => {
+        // docmost: if (ability.cannot(SpaceCaslAction.Manage, SpaceCaslSubject.Settings)) throw Forbidden
+        (0, vitest_1.expect)(own(["createForUser", "cannot", "deleteSpace"], "deleteSpace")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("canRemove 应抑制", () => {
+        // verdaccio: storage.canRemove(...)
+        (0, vitest_1.expect)(own(["canRemove", "removeCachedPackage"], "deleteEntry")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("canPublish 应抑制", () => {
+        // verdaccio: auth.allow_publish({packageName}, user, cb) 的包了一层
+        (0, vitest_1.expect)(own(["canPublish", "remove"], "stage")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("validateCanEdit（带前缀 helper）应抑制", () => {
+        // docmost: await this.validateCanEdit(...)
+        (0, vitest_1.expect)(own(["validateCanEdit", "uploadFile"], "uploadFile")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("checkMediaDeletePermission（A″ 校验动词 + Permission）应抑制", () => {
+        // hedgedoc: MediaController.deleteMedia
+        (0, vitest_1.expect)(own(["checkMediaDeletePermission", "delete"], "deleteMedia")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("validateSpaceAccess 应抑制", () => {
+        // docmost: FavoriteController.removeFavorite → resolveAndValidate → validateSpaceAccess
+        (0, vitest_1.expect)(own(["resolveAndValidate", "validateSpaceAccess", "removeFavorite"], "removeFavorite")).toHaveLength(0);
+    });
+});
+(0, vitest_1.describe)("§38 —— 负对照（同形噪声 ⇒ 仍须报违规）", () => {
+    (0, vitest_1.it)("裸 delete 无任何授权 ⇒ 仍报", () => {
+        (0, vitest_1.expect)(own(["deleteSpace"], "deleteSpace").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("canSendEmail 是限流器不是权限 ⇒ 仍报", () => {
+        // 实测抓到：rateLimiter.canSendEmail(userId) 被第一版误收
+        (0, vitest_1.expect)(own(["canSendEmail", "update"], "updateThing").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("isRight 是 fp-ts Either 判定 ⇒ 仍报", () => {
+        // 实测抓到：hoppscotch 满仓 fp-ts，一次冒出 2 条假转绿
+        // ⚠ 函数名必须能触发 Ownership Check 的 trigger（delete/remove/update…系动词）。
+        //   用 addUserToTeam 的话 trigger 不命中 ⇒ 恒 0，测不出东西（第一版就写错了）。
+        (0, vitest_1.expect)(own(["isRight", "removeMemberFromTeam"], "removeTeamMember").length).toBeGreaterThan(0);
+    });
+    (0, vitest_1.it)("deleteByUsersWithoutSpaceAccess 是数据删除不是校验 ⇒ 仍报", () => {
+        (0, vitest_1.expect)(own(["deleteByUsersWithoutSpaceAccess"], "removeMember").length).toBeGreaterThan(0);
+    });
+    /**
+     * ⚠ 本条在 §40 被**推翻**（2026-09-25），保留在此是为了留下决策痕迹：
+     * §38 当时"裸 can 太宽（cancel/candidate 同形）⇒ 不收"只是一个**担心**，没有真值证据；
+     * §40 人工核剩余池时发现 verdaccio `publish()` 用的是 `const can = allow(auth, …)` +
+     * `can('publish')`、CASL 用 `ability.can(Action.Update, subj)` —— **裸 can 是主流写法**，
+     * 而"太宽"的担心可以用**精确匹配**解决（cancel/candidate 根本不等于 can）。
+     * ⇒ 现在裸 can 收，但两条护栏必须守住（都在 §40 fixture 里钉死）：
+     *     ① 精确匹配 `^can$` / `.can$`（否则 canSendEmail 拆词出 "can" 会被误收）
+     *     ② `callsOnly: true`（否则 identifierParse 拆出的词 "can" 会误命中）
+     */
+    (0, vitest_1.it)("cancel / candidate 不是 can ⇒ 仍报（精确匹配护栏）", () => {
+        (0, vitest_1.expect)(own(["cancel", "candidate", "remove"], "removeThing").length).toBeGreaterThan(0);
+    });
+});

package/dist/protocol-detector-credential-issuance.test.js

@@ -0,0 +1,64 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §46 ① 凭签发入口豁免（credential_issuance）—— 语义与对称性
+ *
+ * 背景：`create_access_token|create_refresh_token|create_jwt_token` 只存在于
+ * `Authorization (Unauthenticated Mutation)` 的 auth_check 词表里，`Access` 没有。
+ * §45 做集合 diff 时发现过，当时以「签发 ≠ 校验调用者」为由没有补进去。§46 把这三个词
+ * 从 auth_check **移出**，单独成立一条 `credential_issuance` safeguard（行为不变，语义自洽）。
+ *
+ * 本文件钉住三件事：
+ *   1. 写类函数调用签发函数 ⇒ 豁免（login/register 入口天然不需要事前认证）
+ *   2. 读类函数调用签发函数 ⇒ **仍报**（不对称 —— R66：同形状存在相反真值）
+ *   3. 它压的是「入口」而非「认证」：与真正的 auth_check 不是一回事
+ *
+ * ⚠ 名字必须避开 §39 AUTH_PATTERN：ownName/calls 含 User/Token/Auth 会被
+ *   「鉴权机制自身」抢先压掉，测不出本机制（R65 唯一压制来源）。
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+/** 只取 Authorization 族，避免别的规则干扰断言 */
+const az = (calls, own) => (0, protocol_detector_1.detectSafeguardViolations)(calls, own, "typescript", ["user"], false, ["AuthUser"])
+    .filter((v) => v.rule.startsWith("Authorization"))
+    .map((v) => v.rule);
+(0, vitest_1.describe)("§46 ① credential_issuance —— 写类豁免", () => {
+    (0, vitest_1.it)("写类 + create_access_token ⇒ 免（登录/注册入口天然无需事前认证）", () => {
+        (0, vitest_1.expect)(az(["create_access_token", "save"], "createThing")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("写类 + create_jwt_token ⇒ 免", () => {
+        (0, vitest_1.expect)(az(["create_jwt_token", "save"], "createThing")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("写类 + create_refresh_token ⇒ 免", () => {
+        (0, vitest_1.expect)(az(["create_refresh_token", "save"], "createThing")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("反向对照：写类 + 无签发/无认证 ⇒ 仍报", () => {
+        (0, vitest_1.expect)(az(["save", "insert"], "createThing")).toContain("Authorization (Unauthenticated Mutation)");
+    });
+});
+(0, vitest_1.describe)("§46 ① credential_issuance —— 不得对称补进读类（R66）", () => {
+    (0, vitest_1.it)("读类 + create_access_token ⇒ 仍报 Unauthenticated Access", () => {
+        // 若将来有人按「词表对齐」把 mint 补进 Access 词表，这条会转红 —— 那正是要拦的改动。
+        // 理由：调用 create_access_token 说明该函数**在签发**令牌，而不是校验调用者；
+        //       getRefreshToken(userId) 与 getUserToken(userId) 在这个轴上完全同形。
+        (0, vitest_1.expect)(az(["create_access_token", "query"], "getThing")).toContain("Authorization (Unauthenticated Access)");
+    });
+    (0, vitest_1.it)("读类 + create_jwt_token ⇒ 仍报", () => {
+        (0, vitest_1.expect)(az(["create_jwt_token", "query"], "getThing")).toContain("Authorization (Unauthenticated Access)");
+    });
+    (0, vitest_1.it)("读类 + 无认证 ⇒ 仍报（口径不变）", () => {
+        (0, vitest_1.expect)(az(["query", "find"], "getThing")).toContain("Authorization (Unauthenticated Access)");
+    });
+});
+(0, vitest_1.describe)("§46 ① 签发 ≠ 认证 —— 机制归属", () => {
+    (0, vitest_1.it)("真正的认证调用在读写两类上都豁免（对照）", () => {
+        (0, vitest_1.expect)(az(["getSession", "save"], "createThing")).toHaveLength(0);
+        (0, vitest_1.expect)(az(["getSession", "query"], "getThing")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("签发调用只在写类上豁免 ⇒ 两者不是同一类证据", () => {
+        const mutation = az(["create_access_token", "save"], "createThing");
+        const access = az(["create_access_token", "query"], "getThing");
+        (0, vitest_1.expect)(mutation).toHaveLength(0);
+        (0, vitest_1.expect)(access.length).toBeGreaterThan(0);
+    });
+});

package/dist/protocol-detector-owner-self.test.js

@@ -0,0 +1,57 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §46 ② owner_self_assigned —— 资源属主被赋值为当前主体
+ *
+ * 背景：`Authorization (Ownership Check)` 报「改了别人的东西」，但合成语料上有 12 条
+ * FP，成因一致：函数**新建**资源并把属主设为当前主体
+ * （`const item = { ..., ownerId: user.id }`）—— 被操作对象就是自己，谈不上越权。
+ *
+ * 机制：extract-ir 注入 `__progmune_owner_self_assigned__` 标记（对象字面量里的
+ * `<属主字段>: <主体>.id`），Ownership Check 的 safeguard 消费它。
+ *
+ * 本文件钉住：
+ *   1. 有标记 ⇒ 豁免
+ *   2. 无标记 ⇒ 仍报（反向对照，防止无条件抑制）
+ *   3. **不认**「主体标识作实参」形态 —— 那是 R66 否决的形状（见下）
+ *
+ * ⚠ R66 的边界（为什么不做 `<调用>(…, user.id, …)`）：
+ *   真实池 `deletePAT(id, user.uid)` 是 FP（已按属主过滤），
+ *   合成语料 `deleteWidget` 里 `canSendEmail(user.id)` 是 TP（user.id 与 deleteWidget 无关）。
+ *   同形状、相反真值 ⇒ 主体标识作实参这一轴不具备判别力，不得落地。
+ *   只认对象字面量里的**绑定**（`userId:` 后跟主体），不认调用实参。
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+const own = (calls, name) => (0, protocol_detector_1.detectSafeguardViolations)(calls, name, "typescript", ["user"], false, ["AuthUser"])
+    .filter((v) => v.rule === "Authorization (Ownership Check)");
+const MARK = "__progmune_owner_self_assigned__";
+(0, vitest_1.describe)("§46 ② owner_self_assigned —— 属主即主体", () => {
+    (0, vitest_1.it)("带标记 ⇒ 豁免（新建资源属主 = 当前主体）", () => {
+        (0, vitest_1.expect)(own(["getUser", "push", MARK], "createTransfer")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("反向对照：无标记 ⇒ 仍报", () => {
+        (0, vitest_1.expect)(own(["getUser", "push"], "createTransfer")).toHaveLength(1);
+    });
+    (0, vitest_1.it)("反向对照：删除类无标记 ⇒ 仍报（不能被顺带压掉）", () => {
+        (0, vitest_1.expect)(own(["getUser", "findIndex", "splice"], "deleteTransfer")).toHaveLength(1);
+    });
+});
+(0, vitest_1.describe)("§46 ② 边界 —— 只认绑定形态，不认实参形态（R66）", () => {
+    (0, vitest_1.it)("主体标识作实参、但无标记 ⇒ 仍报", () => {
+        // deleteWidget(widgetId, user) { canSendEmail(user.id); repo.deleteWidget(widgetId); }
+        // 这是真 TP：user.id 与 deleteWidget 无关。没有标记 ⇒ 不得豁免。
+        (0, vitest_1.expect)(own(["canSendEmail", "deleteWidget"], "deleteWidget")).toHaveLength(1);
+    });
+    (0, vitest_1.it)("带标记时豁免，与函数名无关", () => {
+        (0, vitest_1.expect)(own(["canSendEmail", "deleteWidget", MARK], "deleteWidget")).toHaveLength(0);
+    });
+});
+(0, vitest_1.describe)("§46 ② 既有 ownership 证据不受影响", () => {
+    (0, vitest_1.it)("内联属主比较（__progmune_ownership_checked__）仍然豁免", () => {
+        (0, vitest_1.expect)(own(["getUser", "__progmune_ownership_checked__"], "deleteTransfer")).toHaveLength(0);
+    });
+    (0, vitest_1.it)("ownerId 比较写法仍然豁免（不加标记也行）", () => {
+        (0, vitest_1.expect)(own(["getUser", "checkOwner"], "deleteTransfer")).toHaveLength(0);
+    });
+});

package/dist/protocol-detector-paramgate.test.js

@@ -0,0 +1,105 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * §44（2026-09-26）`paramGated` 区分「调用者主体」与「被操作对象」—— 正/反向 fixture
+ *
+ * 为什么必须有这个文件：§43 已经证明盲测语料对 Authorization 抑制类改动**长期零覆盖**
+ * （R62 / R56）。本轮改的是 `paramGated` 这条**门**（6 条规则共用），合成语料里
+ * 既没有 `token: string` 这种"被操作对象当身份"的形态，也没有 `user: User` 的对照，
+ * ⇒ 光靠闸门会全绿但一条都没触发。这里的 fixture 是它唯一的覆盖。
+ *
+ * 真值来源（blind-benchmark/reports/paramgate-probe.json，全池 66 条 paramGated 违规）：
+ *   压掉的 8 条 = 6 verified FP + 2 heuristic FP，**TP 0 / UNKNOWN 0**
+ *     - updateLastUsedForPAT(token: string)      ← 被操作的 PAT（hoppscotch）
+ *     - resolveRemoteUser(config: Config, token: string)（verdaccio）
+ *     - verifyJWTPayload(token: string, …)       （verdaccio）
+ *     - setAuthCookie(res: FastifyReply, token: string)（docmost）
+ *   保留的（反例侧）：
+ *     - removeUserAvatar(user: User) / createPAT(dto, user: AuthUser) ← 主体是领域对象
+ *     - JwtAuthGuard.handleRequest(err: any, user: any, …) ← 类型解析不出来 ⇒ 保守放行
+ */
+const vitest_1 = require("vitest");
+const protocol_detector_1 = require("./protocol-detector");
+/** 只看 4 条 Authorization（本轮 paramGated 收紧影响的就是这几条） */
+const authz = (calls, fnName, params, paramTypes, exposed = false) => (0, protocol_detector_1.detectSafeguardViolations)(calls, fnName, "typescript", params, exposed, paramTypes).filter((v) => v.category === "authorization");
+(0, vitest_1.describe)("§44 classifyParamType —— 三分类", () => {
+    (0, vitest_1.it)("标量 ⇒ scalar", () => {
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("string")).toBe("scalar");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("number")).toBe("scalar");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("boolean")).toBe("scalar");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("string[]")).toBe("scalar");
+    });
+    (0, vitest_1.it)("领域类型 ⇒ typed", () => {
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("User")).toBe("typed");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("AuthUser")).toBe("typed");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("Admin")).toBe("typed");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("ExecutionContext")).toBe("typed");
+    });
+    (0, vitest_1.it)("解析不出来 ⇒ unknown（保守，不收紧）", () => {
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("any")).toBe("unknown");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("unknown")).toBe("unknown");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("")).toBe("unknown");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("null")).toBe("unknown");
+    });
+    (0, vitest_1.it)("联合类型按「含领域类型即 typed」处理", () => {
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("User | null")).toBe("typed");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("AuthenticationType | null")).toBe("typed");
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("string | null")).toBe("scalar");
+        // 含 any 的联合不敢判标量 ⇒ typed（保守放行）
+        (0, vitest_1.expect)((0, protocol_detector_1.classifyParamType)("any | User")).toBe("typed");
+    });
+});
+(0, vitest_1.describe)("§44 正对照 —— 唯一的身份线索是标量 ⇒ 那是被操作对象，不是调用者", () => {
+    (0, vitest_1.it)("updateLastUsedForPAT(token: string) 应被 paramGated 挡下", () => {
+        // hoppscotch：被操作的是要更新 lastUsed 的那个 PAT，不是调用者凭证
+        (0, vitest_1.expect)(authz(["extractUUID", "left", "update", "right", "cast"], "updateLastUsedForPAT", ["token"], ["string"])).toHaveLength(0);
+    });
+    // ⚠ 两条曾用真名 `resolveRemoteUser` / `verifyJWTPayload`，反向验证时**没转红**
+    //   ⇒ 它们是被 safeguard（`jwtVerify` / 自身名里的 `verify`）压掉的，不是被
+    //   paramGated 压掉的 —— 按 R64/R65 是**假绿**，必须换成能真正压在门上的形态。
+    (0, vitest_1.it)("updateRemoteUser(config: Config, token: string) 应被挡下", () => {
+        // 形态同 verdaccio resolveRemoteUser：token 是待解析的入参，不是调用者凭证
+        (0, vitest_1.expect)(authz(["readFileSync", "split", "at"], "updateRemoteUser", ["config", "token"], ["Config", "string"])).toHaveLength(0);
+    });
+    // ⚠ 第二版曾用 `rotateSecretValue` —— 反向验证也没转红：`rotate` 不在
+    //   Authorization 的 trigger 动词表里，规则压根没触发 ⇒ 恒绿，还是假绿。
+    (0, vitest_1.it)("updateSecretValue(token: string, secret: string) 应被挡下", () => {
+        (0, vitest_1.expect)(authz(["split", "at", "concat"], "updateSecretValue", ["token", "secret"], ["string", "string"])).toHaveLength(0);
+    });
+});
+(0, vitest_1.describe)("§44 反向对照 —— 主体参数必须仍然放行（不能变成无条件抑制）", () => {
+    (0, vitest_1.it)("removeUserAvatar(user: User) 仍应报 —— 主体是领域对象", () => {
+        (0, vitest_1.expect)(authz(["getAttachmentFolderPath", "deleteRedundantFile", "updateUser"], "removeUserAvatar", ["user"], ["User"])).not.toHaveLength(0);
+    });
+    (0, vitest_1.it)("createPAT(dto, user: AuthUser) 仍应报", () => {
+        (0, vitest_1.expect)(authz(["isValidLength", "create", "cast"], "createPAT", ["dto", "user"], ["CreateAccessTokenDto", "AuthUser"])).not.toHaveLength(0);
+    });
+    (0, vitest_1.it)("user: any 仍应报 —— 类型解析不出来时保守放行（R57：退回旧行为，不是一律压）", () => {
+        // ⚠ 函数名不能用 generateJWT —— 它是 isAuthFunctionName 的鉴权机制自身，
+        //    authorization 规则对它整体跳过，测不出 paramGated 的门。
+        (0, vitest_1.expect)(authz(["findOne", "save"], "updateProfile", ["user"], ["any"])).not.toHaveLength(0);
+    });
+    (0, vitest_1.it)("user 是标量 string 但函数 exposed ⇒ 仍应报（exposed 是独立的入口证据）", () => {
+        (0, vitest_1.expect)(authz(["update", "save"], "updateProfile", ["user"], ["string"], true)).not.toHaveLength(0);
+    });
+    (0, vitest_1.it)("不传 paramTypes ⇒ 完全保持旧行为（零漂移）", () => {
+        // 旧行为：参数名命中 identity 词表即通过门 ⇒ token 也放行
+        (0, vitest_1.expect)(authz(["update", "save"], "updateLastUsedForPAT", ["token"])).not.toHaveLength(0);
+    });
+});
+(0, vitest_1.describe)("§44 IDENTITY_PARAM_RE —— 与旧内联正则同源", () => {
+    (0, vitest_1.it)("命中身份词（必须是**独立单词**）", () => {
+        for (const n of ["user", "token", "session", "role", "request", "credential", "identity"]) {
+            (0, vitest_1.expect)(protocol_detector_1.IDENTITY_PARAM_RE.test(n)).toBe(true);
+        }
+    });
+    (0, vitest_1.it)("复合词一律不算 —— 词边界使然，这是**既有行为**不是本轮引入", () => {
+        // ⚠ 顺带记一笔项目债：最地道的 NestJS 主体参数名 `authUser` / `currentUser`
+        //   **也不命中**（\buser\b 在 authUser 里没有左边界）。也就是说 paramGated
+        //   目前只认 `user` / `token` / `auth` 这类裸标识符。本轮不改（避免与收紧
+        //   混在一起），但它是"主体识别"这条轴的下一处缺口。
+        for (const n of ["userEmail", "userId", "userRepo", "authUser", "currentUser", "req", "ctx"]) {
+            (0, vitest_1.expect)(protocol_detector_1.IDENTITY_PARAM_RE.test(n)).toBe(false);
+        }
+    });
+});

package/dist/protocol-detector.js

@@ -6,7 +6,12 @@
  * any project's naming conventions (curl, nginx, redis, any C project).
  */
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.IDENTITY_PARAM_RE = exports.AUTHZ_BARE_CAN_RE = exports.AUTHZ_ACCESS_CHECK_RE = exports.AUTHZ_CAN_HELPER_RE = exports.AUTHZ_PREDICATE_RE = exports.AUTHZ_ACTION_WORD = void 0;
 exports.identifierParse = identifierParse;
+exports.tokenAcronyms = tokenAcronyms;
+exports.isAuthDecisionName = isAuthDecisionName;
+exports.isAuthFunctionName = isAuthFunctionName;
+exports.classifyParamType = classifyParamType;
 exports.detectSafeguardViolations = detectSafeguardViolations;
 exports.buildCallerMap = buildCallerMap;
 exports.detectSafeguardViolationsV7 = detectSafeguardViolationsV7;
@@ -267,6 +272,48 @@ const PLSB_PROTOCOLS = [
     },
 ];
 const ALL_PROTOCOLS = [...PROTOCOLS, ...PLSB_PROTOCOLS];
+/**
+ * §38（2026-09-25）组合式授权谓语 —— 三条，逐 call 名匹配（safeguard 口径）。
+ *
+ * 为什么不是继续往白名单里加词：现有 `canModify|canDelete|canEdit` 是**枚举**，
+ * 而真实谓语是「can/cannot/may + 任意授权动作」的**组合**，枚举永远追不上
+ * （实测 docmost 全量 136 条 trigger 命中里，旧白名单抑制 **0** 条）。
+ *
+ * ⚠ 三个踩过的假阳性（都是实测抓到的，改之前先读 §38.4）：
+ *   ① `cannot` 必须单列 —— 塞进 `[A-Z_]\w*` 后缀组会让它自己都不匹配。
+ *   ② `can<X>` 的 X 必须是**授权动作词**：`rateLimiter.canSendEmail(userId)` 是限流器，
+ *      不是权限判定 ⇒ 动作词表刻意不含 Send/Emit/Notify/Render/Parse。
+ *   ③ `...Access` 类词尾必须**限定前缀是校验动词**：`deleteByUsersWithoutSpaceAccess`
+ *      是数据删除不是校验；且词尾不得含 `Rights?`（会命中 fp-ts 的 `E.isRight(x)`）。
+ */
+exports.AUTHZ_ACTION_WORD = "(?:Manage|Read|Write|Create|Update|Delete|Edit|Remove|View|Share|Transfer|Invite|Comment|Move|Rename|Publish|Access|Modify|Upload|Download|Export|Import|Lock|Unlock|Restore|Archive|Pin|Unpin|Assign|Approve|Reject|Execute|Grant|Revoke|All|Any)";
+/** A. CASL 谓语：cannot( / canRemove( / canPublish( / mayCreate( */
+exports.AUTHZ_PREDICATE_RE = new RegExp("^(?:cannot|can_not|isUnable|isDenied|isForbidden)$" +
+    "|^(?:can|able|may|isAble|isAllowed|isPermitted|hasPermission|checkPermission|authorize|isAuthorized|authorised|allowed|permitted)" +
+    exports.AUTHZ_ACTION_WORD, "i");
+/** A′. 带前缀 helper：validateCanEdit / assertCanDelete / isSharingAllowedFor */
+exports.AUTHZ_CAN_HELPER_RE = /^\w*(?:Can|May|Allowed|Permitted|Authorized|Authorised)[A-Z]\w+$/;
+/** A″. 访问/所有权校验：validateSpaceAccess / assertOwnership / checkMediaDeletePermission */
+exports.AUTHZ_ACCESS_CHECK_RE = /^(?:validate|assert|check|ensure|verify|require|confirm|test|has|can|must|needs?)[A-Z_]?\w*(?:Access|Ownership|Permission|Authorization|Grant)\w*$/i;
+/**
+ * §40 C1：裸授权谓语 —— `can('publish')` / `cannot(...)` / `ability.can(...)`。
+ *
+ * 为什么 §38 那条收不到：AUTHZ_PREDICATE_RE 要求 `can` 后面**紧跟动作词**
+ * （canRemove / canPublish），而真实世界的两种主流写法都是**裸** can：
+ *   - CASL：`ability.can(Action.Update, subject)` ← 动作是**实参**，不在名字里
+ *   - verdaccio：`const can = allow(auth, …)`；路由上 `can('publish')`
+ * ⇒ 这两种在 calls 里留下的名字就是 `can` / `ability.can`。
+ *
+ * ⚠⚠ 必须**精确**匹配（`^can$` / `.can$`），绝不能做成 `/\bcan\b/`：
+ *   cancel / candidate / canary / cancan 全都同形但跟授权无关（fixture 已钉死）。
+ */
+exports.AUTHZ_BARE_CAN_RE = /^(?:can|cannot)$|\.(?:can|cannot)$/i;
+/**
+ * ⚠⚠ 挂到规则上时必须带 `callsOnly: true`（2026-09-25 §40 实测踩到）：
+ * 默认会在 `effectiveCalls` 上匹配，而 effectiveCalls 含 **identifierParse 拆出的词**
+ * ⇒ `canSendEmail` 会拆出单词 "can" ⇒ 裸 can 误命中 ⇒ §38 的负对照直接转绿。
+ * callsOnly 把匹配限定在**原始调用名**上（`can` 作为被调名才作数）。
+ */
 const SAFEGUARD_RULES = [
     // ── Password Hashing ──
     {
@@ -322,6 +369,20 @@ const SAFEGUARD_RULES = [
             { pattern: /\b(checkOwner|isOwner|ownerId\s*[!=]==?|authorId\s*[!=]==?|userId\s*[!=]==?|createdBy\s*[!=]==?|\.owner\s*[!=]==?|\.user\s*[!=]==?)\b/i, label: "ownership_check" },
             { pattern: /\b(hasPermission|checkPermission|checkAccess|isAuthorized|checkRole|requireRole|adminCheck|isAdmin|canModify|canDelete|canEdit)\b/i, label: "authz_check" },
             { pattern: /\b(__progmune_ownership_checked__)\b/, label: "inline_ownership_check" },
+            // §46 ②：资源属主被**赋值为当前主体**（`{ userId: user.id }` / `where:{userId: user.id}`）。
+            // 这类函数的被操作对象就是（或已被限定在）主体自己，谈不上「改别人的东西」。
+            // 合成语料上覆盖 10/10 FP（createTransfer / createRefund / uploadFile / placeOrder…）。
+            // ⚠ 只认 `<属主字段>: <主体>.id` 的**绑定**形态；**不认** `<调用>(…, user.id, …)` ——
+            //   主体标识作实参这一形状实测存在相反真值（deletePAT 是 FP，deleteWidget 是 TP），按 R66 不落地。
+            { pattern: /\b(__progmune_owner_self_assigned__)\b/, label: "owner_self_assigned" },
+            // §38（2026-09-25）CASL / 组合式授权谓语。上面两条是**动词白名单**，
+            // 而真实世界的谓语是 `can|cannot|may` + 动作 的**组合式**，
+            // 白名单穷举不完（canRemove/canManage/canPublish…）。三条规则见 §38.3。
+            { pattern: exports.AUTHZ_PREDICATE_RE, label: "casl_predicate" },
+            { pattern: exports.AUTHZ_CAN_HELPER_RE, label: "can_helper" },
+            { pattern: exports.AUTHZ_ACCESS_CHECK_RE, label: "access_check" },
+            // §40 C1：裸 can（CASL ability.can / verdaccio can('publish')）—— 精确匹配
+            { pattern: exports.AUTHZ_BARE_CAN_RE, label: "bare_can", callsOnly: true },
         ],
         violationMessage: "Mutation operation does not verify that the acting user owns the resource or holds the required permission before modifying data.",
         conceptMissing: ["OwnershipCheck", "AuthorizationGuard"],
@@ -348,7 +409,9 @@ const SAFEGUARD_RULES = [
         paramGated: true,
         trigger: /\b(list|download|view|fetch)(?:[A-Z]\w*|_\w+)|get(?:[A-Z]\w+|_\w+)/i,
         safeguards: [
-            { pattern: /\b(getUser|validateToken|verifySession|getSessionUser|getCurrentUser|token\w*(Check|Verify|Valid)|session\w*(Check|Verify|Valid)|auth\w*(Check|Verify|Valid|Guard|Middleware|Required)|requireAuth|withAuth|authenticate\w*(User|Request|Token)?|checkAuth|isAuth|hasAuth|checkAccess|hasAccess|get_user|get_session_user|get_current_user|validate_session|verify_token|require_auth|with_auth|check_auth|auth_required|authenticate_user|authenticate_request|authenticate_token|token_check|token_verify|token_valid|session_check|session_verify|session_valid|auth_check|auth_guard|auth_middleware|get_current_user_authorizer|current_user_authorizer|login_required|permission_required|user_passes_test|check_authorization|check_permission|jwt\.decode|decode_token|__progmune_auth_checked__|__progmune_credential_check__|__progmune_drf_permissions__|__progmune_auth_machinery__)\b/i, label: "auth_check" },
+            { pattern: /\b(getUser|validateToken|verifyToken|verifySession|validateSession|getSessionUser|getSession\b|getCurrentUser|token\w*(Check|Verify|Valid)|session\w*(Check|Verify|Valid)|auth\w*(Check|Verify|Valid|Guard|Middleware|Required)|requireAuth|withAuth|authenticate\w*(User|Request|Token)?|checkAuth|isAuth|hasAuth|checkAccess|hasAccess|get_user|get_session_user|get_current_user|validate_session|verify_token|require_auth|with_auth|check_auth|auth_required|authenticate_user|authenticate_request|authenticate_token|token_check|token_verify|token_valid|session_check|session_verify|session_valid|auth_check|auth_guard|auth_middleware|get_current_user_authorizer|current_user_authorizer|login_required|permission_required|user_passes_test|check_authorization|check_permission|jwt\.decode|decode_token|__progmune_auth_checked__|__progmune_credential_check__|__progmune_drf_permissions__|__progmune_auth_machinery__)\b/i, label: "auth_check" },
+            // §40 C1：裸 can —— verdaccio 的 can('publish') 中间件就是这里的授权判定
+            { pattern: exports.AUTHZ_BARE_CAN_RE, label: "bare_can", callsOnly: true },
         ],
         violationMessage: "Data access function does not check authentication. Anyone can access data without credentials.",
         conceptMissing: ["AuthenticationCheck", "AccessControl"],
@@ -380,7 +443,19 @@ const SAFEGUARD_RULES = [
         // (listPosts/getPost/deletePost fire via identifier-parsed words).
         trigger: /\b(add|create|update|set|publish|insert|submit)(?:[A-Z]\w*|_\w+)|(?:[A-Z]\w*|_\w+)(Add|Create|Update|Set|Publish|Insert|Submit)\b/i,
         safeguards: [
-            { pattern: /\b(getUser|validateToken|verifyToken|verifySession|validateSession|getSessionUser|getSession\b|getCurrentUser|token\w*(Check|Verify|Valid)|session\w*(Check|Verify|Valid)|auth\w*(Check|Verify|Valid|Guard|Middleware|Required)|requireAuth|withAuth|authenticate\w*(User|Request|Token)?|checkAuth|isAuth|hasAuth|checkAccess|hasAccess|get_user|get_session_user|get_current_user|validate_session|verify_token|require_auth|with_auth|check_auth|auth_required|authenticate_user|authenticate_request|authenticate_token|token_check|token_verify|token_valid|session_check|session_verify|session_valid|auth_check|auth_guard|auth_middleware|get_current_user_authorizer|current_user_authorizer|login_required|permission_required|user_passes_test|check_authorization|check_permission|create_access_token|create_refresh_token|create_jwt_token|__progmune_auth_checked__|__progmune_credential_check__|__progmune_drf_permissions__|__progmune_auth_machinery__)\b/i, label: "auth_check" },
+            { pattern: /\b(getUser|validateToken|verifyToken|verifySession|validateSession|getSessionUser|getSession\b|getCurrentUser|token\w*(Check|Verify|Valid)|session\w*(Check|Verify|Valid)|auth\w*(Check|Verify|Valid|Guard|Middleware|Required)|requireAuth|withAuth|authenticate\w*(User|Request|Token)?|checkAuth|isAuth|hasAuth|checkAccess|hasAccess|get_user|get_session_user|get_current_user|validate_session|verify_token|require_auth|with_auth|check_auth|auth_required|authenticate_user|authenticate_request|authenticate_token|token_check|token_verify|token_valid|session_check|session_verify|session_valid|auth_check|auth_guard|auth_middleware|get_current_user_authorizer|current_user_authorizer|login_required|permission_required|user_passes_test|check_authorization|check_permission|__progmune_auth_checked__|__progmune_credential_check__|__progmune_drf_permissions__|__progmune_auth_machinery__)\b/i, label: "auth_check" },
+            // §40 C1：裸 can —— 同上
+            { pattern: exports.AUTHZ_BARE_CAN_RE, label: "bare_can", callsOnly: true },
+            // §46 ①：凭签发入口豁免 —— 独立 safeguard，**不并入 auth_check**。
+            // create_*_token 是「签发令牌」不是「校验调用者身份」，两者语义相反：
+            // 调用 create_access_token 恰恰说明该函数**没有**校验任何人的身份（它就是发令牌的地方）。
+            // 之所以仍要豁免，是因为 login / register / issueToken 这类入口天然不需要事前认证
+            // （这里压的是「登录接口被判未认证变更」那批 FP），不是因为它做了认证。
+            // ⚠ 因此它**不得对称补进 Unauthenticated Access**（R66：同形状存在相反真值 ——
+            //   getRefreshToken(userId) 是该免的签发入口，getUserToken(userId) 是不该免的越权读取，
+            //   单函数视角区分不了）。分开成两条 label 就是为了让下一次词表 diff（R69）
+            //   不再把这三个词当成 auth_check 的「缺项」而机械对齐过去。
+            { pattern: /\b(create_access_token|create_refresh_token|create_jwt_token)\b/i, label: "credential_issuance" },
         ],
         violationMessage: "Mutation function does not check authentication. Anyone can create or modify data without credentials.",
         conceptMissing: ["AuthenticationCheck", "AccessControl"],
@@ -528,6 +603,12 @@ const SAFEGUARD_RULES = [
         safeguards: [
             { pattern: /\b(ownerId\s*[!=]==?|authorId\s*[!=]==?|userId\s*[!=]==?|createdBy|\.owner\s*[!=]==?)/i, label: "ownership_comparison" },
             { pattern: /\b(__progmune_ownership_checked__)\b/, label: "inline_ownership_check" },
+            // §38：同 Ownership Check，组合式谓语一并接上（这条规则更严，更需要）
+            { pattern: exports.AUTHZ_PREDICATE_RE, label: "casl_predicate" },
+            { pattern: exports.AUTHZ_CAN_HELPER_RE, label: "can_helper" },
+            { pattern: exports.AUTHZ_ACCESS_CHECK_RE, label: "access_check" },
+            // §40 C1：同上
+            { pattern: exports.AUTHZ_BARE_CAN_RE, label: "bare_can", callsOnly: true },
         ],
         violationMessage: "Resource mutation checks authentication but does NOT verify the resource belongs to the requesting user. Missing ownerId/authorId comparison.",
         conceptMissing: ["ResourceOwnership", "HorizontalAuthorization"],
@@ -1138,11 +1219,200 @@ function identifierParse(name) {
     }
     return words;
 }
+/**
+ * §39（2026-09-25）D 类自指排除：把「鉴权机制自身」也识别为 auth function。
+ *
+ * 引擎原有 AUTH_PATTERN 只列了**用户鉴权入口**（login / register / logout / …），
+ * 没列**鉴权机制自身**，于是对下面这类函数报「未鉴权」，属自指谬误：
+ *   JwtAuthGuard.handleRequest / TokenService.verifyJwt / AuthService.getCollabToken
+ *   / WorkspaceAbilityFactory.createForUser（CASL 授权引擎本体）
+ *
+ * 判据是**结构化**的两条，不是再往里加词（R55：组合规则必须带约束）：
+ *
+ *   ① 机制类容器 = 机制后缀(Guard|Strategy|AbilityFactory) **×** 凭据名词
+ *      ⚠ 只看后缀不够：`Strategy` 是通用设计模式后缀，CacheStrategy /
+ *        PaymentStrategy 会被误吃；`Guard` 同理（NestJS 的 ThrottlerGuard 是
+ *        限流不是鉴权）。加凭据名词约束后这两类都排除。
+ *   ② 方法 = 机制动词 × 机制对象，**只看点号后的方法部分**
+ *      （容器词不参与动词匹配，否则 ApiTokensController 会漏进来）
+ *
+ * ⚠⚠ 边界（实测踩到的越界，别再放宽）：
+ *   - **不得**改成「容器含 token/session 即算」。实测那样会吃掉
+ *     `ApiTokensController.deleteToken` / `AccessTokenController.deletePAT` /
+ *     `AccessTokenService.updateLastUsedForPAT` 的 Ownership Check ——
+ *     对**凭据做增删改**恰恰是最需要鉴权的地方，压掉就是真漏报且不可见。
+ *   - 机制对象**不含** password（changePassword/passwordReset 是受保护操作）
+ *   - 机制对象**不含** pat（hoppscotch 产品专有缩写，收它会吃掉 createPAT，
+ *     属过拟合到单个仓库的缩写）
+ */
+const AUTH_MACHINERY_CLASS_SUFFIX = /(?:Guard|Strategy|AbilityFactory)$/;
+const AUTH_MACHINERY_NOUN_WORDS = [
+    "auth", "jwt", "token", "session", "cookie", "credential", "passport",
+    "identity", "oauth", "oidc", "ldap", "saml", "bearer", "apikey", "ability", "permission",
+];
+const AUTH_MACHINERY_VERB_WORDS = [
+    "verify", "validate", "sign", "generate", "issue", "decode", "parse",
+    "encode", "refresh", "rotate", "get", "set", "create", "build", "make", "write", "read",
+];
+const AUTH_MACHINERY_OBJECT_WORDS = [
+    "jwt", "token", "cookie", "session", "credential", "credentials", "signature", "bearer",
+];
+/**
+ * §41 E1：token **内嵌**的 acronym 前缀 —— JWT from `JWTPayload`。
+ *
+ * 背景（§40.8 候选 C5）：`identifierParse("verifyJWTPayload")` → ["verify","JWTPayload"]，
+ *   "JWTPayload" 整块 ≠ "jwt" ⇒ 凭据语义对**任何**词表都不可见。
+ *
+ * ⚠⚠ 为什么**不改 identifierParse 主干**（C5 原案的处置结论，2026-09-25）：
+ *   identifierParse 有 **5 个调用点**，其中 `triggerParsedWords` 供给 **trigger 匹配**、
+ *   `effectiveCalls` 供给 **safeguard 匹配** —— 动它等于同时改所有规则的触发面与抑制面。
+ *   `split-probe.ts` 实测：母本 803 个去重标识符里只有 **16 个**受影响，新增 22 个词中
+ *   仅 **2 个**（JWT / OIDC）是机制类，其余全是噪声：
+ *     OAuthToken      → +"Auth"   （从 OAuth 里拆出 Auth，污染面极大）
+ *     throwHTTPErr    → +"HTTP" +"Err"
+ *     createATeam     → +"A" +"Team"
+ *     prosemirrorNodeToYElement → +"Y" +"Element"
+ *   ⇒ 收益 2 条 vs 全局 trigger/effectiveCalls 漂移 ⇒ **主干不改**。
+ *
+ * 折中：**只在「这个函数是否是鉴权机制」这一处**补认 acronym ——
+ *   局部 ⇒ 不影响 triggerParsedWords / effectiveCalls ⇒ **结构上不可能造成 LOST**。
+ */
+const ACRONYM_PREFIX = /^([A-Z]{2,})(?=[A-Z][a-z])/;
+/**
+ * 单个 token 里嵌的 acronym：JWTPayload→JWT / OIDCStrategy→OIDC / HTTPErr→HTTP。
+ * ⚠ `{2,}` 与贪婪回溯两条约束是实测出来的，别随手放宽：
+ *   - `{2,}`：否则 `OAuth` → "O"（satisfies O|Auth 的 lookahead），单字母进词表 = 灾难；
+ *   - 贪婪回溯：`OIDCStrategy` 必须拿到 "OIDC" 而不是 "OID"
+ *     （非贪婪 `[A-Z]+?` 会停在 OID，"oid" 不在任何机制词表里 ⇒ 这条救不了）。
+ *   - lookahead `[A-Z][a-z]`：纯 PascalCase 词（Token/Payload）不匹配，避免把自己再切一遍。
+ */
+function tokenAcronyms(token) {
+    const m = ACRONYM_PREFIX.exec(token);
+    return m ? [m[1]] : [];
+}
+/** identifierParse 的词 + 每个词内嵌的 acronym，统一小写 */
+function machineryWords(method) {
+    const base = identifierParse(method);
+    const out = base.map((w) => w.toLowerCase());
+    for (const t of base)
+        for (const a of tokenAcronyms(t))
+            out.push(a.toLowerCase());
+    return out;
+}
+function isAuthMachineryName(enclosingFuncName) {
+    const dot = enclosingFuncName.lastIndexOf(".");
+    const container = dot > 0 ? enclosingFuncName.slice(0, dot) : "";
+    // ① 机制类容器
+    if (container && AUTH_MACHINERY_CLASS_SUFFIX.test(container)) {
+        const cl = container.toLowerCase();
+        if (AUTH_MACHINERY_NOUN_WORDS.some((w) => cl.includes(w)))
+            return true;
+    }
+    // ② 方法 = 机制动词 × 机制对象（§41 E1：对象侧支持内嵌 acronym，见 ACRONYM_PREFIX 注释）
+    const method = dot >= 0 ? enclosingFuncName.slice(dot + 1) : enclosingFuncName;
+    const mw = machineryWords(method);
+    if (mw.some((w) => AUTH_MACHINERY_VERB_WORDS.includes(w)) &&
+        mw.some((w) => AUTH_MACHINERY_OBJECT_WORDS.includes(w)))
+        return true;
+    return false;
+}
+/**
+ * §40 C4：**容器严格等于裸鉴权类名** × **方法是授权决策或机制内部**。
+ *
+ * §39.8 记下的未收项：verdaccio `Auth.allow_publish` / `Auth.allow_access` /
+ * `Auth.setLegacyAuthCacheEntry`。容器 `Auth` 不带 Guard/Strategy/AbilityFactory 后缀，
+ * 方法也不是「机制动词 × 机制对象」 ⇒ §39 的结构化判据够不着。
+ *
+ * ⚠⚠ 两层约束**缺一不可**（宽变体实测，见 §40.5）：
+ *   ① 容器必须**严格等于** Auth / Authorization / AccessControl / Permissions。
+ *      放宽成 `Auth*` 会吃掉 `AuthController.deletePendingUserData` —— §39 的 V-D
+ *      反向验证早就证明这类**不能**压（对凭据/待处理用户做增删改最需要鉴权）。
+ *   ② 方法必须是 `allow_*`（授权决策）或含机制名词（Cache/Token/JWT/AES/Session/
+ *      Middleware/Encrypt…），且**不得以受保护动词开头** —— 否则
+ *      `Auth.changePassword` / `Auth.invalidateToken` / `Auth.add_user` 会被压掉。
+ */
+const AUTH_CLASS_EXACT = /^(?:Auth|Authorization|AccessControl|Permissions?)$/;
+const AUTH_MECHANISM_METHOD = /(?:Cache|Token|JWT|AES|Bearer|Session|Middleware|Encrypt|Decrypt|Payload|Signature)/i;
+const PROTECTED_VERB_PREFIX = /^(?:change|add|remove|delete|update|create|reset|invalidate|revoke|grant|deny|rotate)/i;
+function isAuthDecisionName(enclosingFuncName) {
+    const dot = enclosingFuncName.lastIndexOf(".");
+    if (dot <= 0)
+        return false;
+    if (!AUTH_CLASS_EXACT.test(enclosingFuncName.slice(0, dot)))
+        return false;
+    const method = enclosingFuncName.slice(dot + 1);
+    if (PROTECTED_VERB_PREFIX.test(method))
+        return false;
+    return /^allow_/i.test(method) || AUTH_MECHANISM_METHOD.test(method);
+}
+/** 用户鉴权入口词表（login/register/logout/…）—— 原在两处重复定义，提成一份 */
+const AUTH_PATTERN = /\b(register|signup|signin|login|authenticate|createuser|createaccount|registeruser|registernewuser|dologin|verifytoken|validatesession|getuser|getsessionuser|getcurrentuser|endsession|logout|signout|dologout|destroysession|invalidatesession|invalidate|signout|create_account|register_new_user|register_user|sign_up|create_user|do_login|sign_in|log_in|verify_token|validate_session|get_user|get_session_user|get_current_user|do_logout|sign_out|log_out|end_session|invalidate_session|clear_session)\b/i;
+/**
+ * 该函数是否是「鉴权相关」函数 —— 是则跳过 authorization 类目规则
+ * （对鉴权机制自己报「未鉴权」是自指谬误）。
+ */
+function isAuthFunctionName(enclosingFuncName) {
+    if (!enclosingFuncName)
+        return false;
+    const rawLower = enclosingFuncName.toLowerCase();
+    if (AUTH_PATTERN.test(rawLower))
+        return true;
+    if (identifierParse(enclosingFuncName).some((w) => AUTH_PATTERN.test(w)))
+        return true;
+    if (isAuthMachineryName(enclosingFuncName))
+        return true;
+    if (isAuthDecisionName(enclosingFuncName))
+        return true; // §40 C4
+    // §40 C2：**函数自身**就是那个授权检查 ⇒ 对它报"缺检查"同样自指。
+    // 例：verdaccio `canRemove` 报 "Authorization (Ownership Check)"。
+    // 判据复用 §38 的三条（同源，不另起一份），只作用在**点号后的方法部分**。
+    const dot = enclosingFuncName.lastIndexOf(".");
+    const method = dot >= 0 ? enclosingFuncName.slice(dot + 1) : enclosingFuncName;
+    if (exports.AUTHZ_PREDICATE_RE.test(method) ||
+        exports.AUTHZ_CAN_HELPER_RE.test(method) ||
+        exports.AUTHZ_ACCESS_CHECK_RE.test(method))
+        return true;
+    return false;
+}
 /**
  * Detect missing safeguards in function call sequences.
  * Uses identifier parsing to match compound names (registerNewUser → register).
  */
-function detectSafeguardViolations(calls, enclosingFuncName, language, params, exposed) {
+/**
+ * §44（2026-09-26）`paramGated` 的身份词表 —— 与旧的内联正则同源，抽出来是为了让
+ * fixture 能 import 落地正则（R59），也让「主体 vs 被操作对象」这一刀有单一定义。
+ *
+ * ⚠ 这个词表**只能表达"参数名像身份"**，不能单独区分主体与被操作对象
+ * （`token` 既可能是调用者凭证，也可能是被操作的 PAT）。
+ * 区分靠**参数类型**（见 `classifyParamType`）：主体是领域对象，被操作对象是标量。
+ */
+exports.IDENTITY_PARAM_RE = /\b(token|session|user|auth|request|scope|cookie|credential|permission|role|identity)\b/i;
+/** 标量类型 —— 被操作对象几乎总是这些（id / email / token 都是 string）。 */
+const SCALAR_PARAM_TYPE_RE = /^(?:string|number|boolean|bigint|symbol|void|never|date)(?:\[\])?$/i;
+/** 类型解析不出来 —— 保守，不收紧（ts-morph 对 `any` / 解不出类型的参数会给出这些）。 */
+const UNKNOWN_PARAM_TYPE_RE = /^(?:any|unknown|object)(?:\[\])?$/i;
+const NULLISH_PARAM_TYPE_RE = /^(?:null|undefined)$/i;
+/**
+ * 参数类型三分类。**"unknown" 一律按旧行为放行** —— 类型通道不可用不是压制的理由。
+ * 联合类型（`User | null` / `AuthenticationType | null`）按"含任一领域类型即 typed"处理。
+ */
+function classifyParamType(t) {
+    const parts = (t || "")
+        .split("|")
+        .map((s) => s.trim())
+        .filter(Boolean)
+        .filter((s) => !NULLISH_PARAM_TYPE_RE.test(s));
+    if (parts.length === 0)
+        return "unknown";
+    if (parts.every((s) => UNKNOWN_PARAM_TYPE_RE.test(s)))
+        return "unknown";
+    if (parts.some((s) => UNKNOWN_PARAM_TYPE_RE.test(s)))
+        return "typed"; // 含 any 的联合 ⇒ 不敢判标量
+    if (parts.every((s) => SCALAR_PARAM_TYPE_RE.test(s)))
+        return "scalar";
+    return "typed";
+}
+function detectSafeguardViolations(calls, enclosingFuncName, language, params, exposed, paramTypes) {
     const violations = [];
     // Build effective calls: raw names + identifier-parsed words.
     // Class-qualified names (Class.method) contribute only their METHOD name —
@@ -1156,10 +1426,8 @@ function detectSafeguardViolations(calls, enclosingFuncName, language, params, e
     }
     const effectiveCalls = [...new Set([...rawCalls, ...parsedWords])];
     // Skip authorization rules for auth functions — check both raw lowercased name and parsed words
-    const rawLower = enclosingFuncName?.toLowerCase() || "";
-    const AUTH_PATTERN = /\b(register|signup|signin|login|authenticate|createuser|createaccount|registeruser|registernewuser|dologin|verifytoken|validatesession|getuser|getsessionuser|getcurrentuser|endsession|logout|signout|dologout|destroysession|invalidatesession|invalidate|signout|create_account|register_new_user|register_user|sign_up|create_user|do_login|sign_in|log_in|verify_token|validate_session|get_user|get_session_user|get_current_user|do_logout|sign_out|log_out|end_session|invalidate_session|clear_session)\b/i;
-    const isAuthFunction = enclosingFuncName != null && (AUTH_PATTERN.test(rawLower) ||
-        identifierParse(enclosingFuncName).some(w => AUTH_PATTERN.test(w)));
+    // §39：入口词表 ∪ 鉴权机制自身（自指排除），详见 isAuthFunctionName
+    const isAuthFunction = isAuthFunctionName(enclosingFuncName);
     // Filter rules by language
     const activeRules = language
         ? SAFEGUARD_RULES.filter(r => !r.languages || r.languages.includes(language))
@@ -1197,8 +1465,23 @@ function detectSafeguardViolations(calls, enclosingFuncName, language, params, e
         // Surface gate (paramGated): only apply to functions that can plausibly
         // authenticate — routed by a web handler (exposed) or taking an
         // identity-ish parameter. Requires the caller to pass param names.
+        //
+        // §44（2026-09-26）：光看参数名会把**被操作对象**当成**调用者身份** ——
+        //   `updateLastUsedForPAT(token: string)` 的 token 是要被更新的 PAT；
+        //   `addUserToTeam(teamID, userEmail, role)` 的 role 是要授予的角色。
+        // 主体是**领域对象**（`user: AuthUser` / `user: User` / `adminUser: Admin`），
+        // 被操作对象几乎总是**标量**（id / email / token 都是 string）⇒ 标量类型的参数
+        // 不再充当身份证据。类型通道不可用时不收紧（退回旧行为，见 R57）。
         if (rule.paramGated && params) {
-            const hasIdentity = params.some(p => /\b(token|session|user|auth|request|scope|cookie|credential|permission|role|identity)\b/i.test(p));
+            const hasIdentity = params.some((p, i) => {
+                if (!exports.IDENTITY_PARAM_RE.test(p))
+                    return false;
+                const t = paramTypes?.[i];
+                // 调用方没传类型 / 该参数类型解析不出来（any、unknown、空）⇒ 保守放行
+                if (t === undefined)
+                    return true;
+                return classifyParamType(t) !== "scalar";
+            });
             if (!hasIdentity && !exposed)
                 continue;
         }
@@ -1311,10 +1594,8 @@ function detectSafeguardViolationsV7(calls, enclosingFuncName, callerMap, funcCa
     for (const c of triggerEffectiveCalls)
         safeContext.add(c);
     // Skip authorization rules for auth functions
-    const rawLower = enclosingFuncName?.toLowerCase() || "";
-    const AUTH_PATTERN = /\b(register|signup|signin|login|authenticate|createuser|createaccount|registeruser|registernewuser|dologin|verifytoken|validatesession|getuser|getsessionuser|getcurrentuser|endsession|logout|signout|dologout|destroysession|invalidatesession|invalidate|signout|create_account|register_new_user|register_user|sign_up|create_user|do_login|sign_in|log_in|verify_token|validate_session|get_user|get_session_user|get_current_user|do_logout|sign_out|log_out|end_session|invalidate_session|clear_session)\b/i;
-    const isAuthFunction = enclosingFuncName != null && (AUTH_PATTERN.test(rawLower) ||
-        identifierParse(enclosingFuncName).some(w => AUTH_PATTERN.test(w)));
+    // §39：入口词表 ∪ 鉴权机制自身（自指排除），详见 isAuthFunctionName
+    const isAuthFunction = isAuthFunctionName(enclosingFuncName);
     // Filter rules by language
     const activeRulesV7 = language
         ? SAFEGUARD_RULES.filter(r => !r.languages || r.languages.includes(language))

package/dist/sdk.js

@@ -20,7 +20,7 @@ const risk_model_1 = require("./risk-model");
 const protocol_knowledge_1 = require("./protocol-knowledge");
 const evidence_repository_1 = require("./evidence-repository");
 /** Runtime version — stable public identifier. Internal layers evolve underneath. */
-exports.RUNTIME_VERSION = "3.7.51";
+exports.RUNTIME_VERSION = "3.7.52";
 function verify(filePath) {
     const cert = (0, certify_1.certify)(filePath);
     const kb = (0, protocol_knowledge_1.buildKnowledgeBase)();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "progmune-runtime",
-  "version": "3.7.52",
+  "version": "3.7.53",
   "description": "Progmune — AI Trust Decision Engine. Verify AI-generated code before it reaches production. Outputs APPROVED / NEEDS_REVIEW / BLOCKED with evidence.",
   "files": [
     "dist/",
@@ -23,7 +23,7 @@
   },
   "scripts": {
     "prepare": "npm run build",
-    "build": "tsc -p tsconfig.json && tsc -p tsconfig.mcp.json && mv dist-mcp/mcp-server.js dist/mcp-server.mjs && rm -rf dist-mcp",
+    "build": "tsc -p tsconfig.json && tsc -p tsconfig.mcp.json && mv dist-mcp/mcp-server.js dist/mcp-server.mjs && (rm -rf dist-mcp || true)",
     "start": "node dist/mcp-server.mjs",
     "test": "node dist/check.js",
     "test:unit": "vitest run --exclude '**/stress/**' --exclude '**/soak/**' --exclude '**/chaos/**'",