05: P1 修复 C — 暂缓态写拦截（D-07/08）+ 禁领规则接线（D-09）

Type: task Status: resolved Blocked by: 02

任务

现象：发布「禁领」公海规则后，用户仍能 claim 领取——规则只影响回收 Job，不影响领取。
根因：PoolRuleMatcher.loadPublished() 只被 OpportunityMaintenanceJob 消费；claim/release 路径未接。
修法：claim（领取）路径接入规则校验——按商机所属部门匹配部门专用规则（owner_dept_id，依赖票 03 修好），无部门专用规则走 isDefault 规则；规则 allowFreeClaim=0 → 拒绝领取（业务码提示「该商机所属部门配置了禁领规则」）。release（抛公海）是否也受规则约束按票 02 裁决口径（默认不受，抛是主动行为）。
性能注意：matcher 已有 loadPublished 缓存机制（Job 在用），claim 路径直接复用同一 matcher/缓存，别每次领取全表扫规则。

暂缓态：edit 返回业务码拦截；close 返回业务码拦截；恢复正常态后两操作恢复可用。
禁领：发布禁领规则（部门专用 + 默认两种）后 claim 被拒且错误信息可读；allowFreeClaim=1 正常领取；无任何发布中规则时不受影响（回归确认）。
e2e-core.py F 段（状态流转）+ e2e-rules.py U03 段回归。
单测：暂缓拦截 ×2 + 禁领命中/未命中 ×3。

已完成（2026-08-30）。范围按票 02 裁决调整：D-08 翻案剔除，D-07 口径扩大为「一切编辑操作全禁」。

OpportunityActionGuard（state/，新组件，对齐状态机「业务前置校验归调用方」分工）：
- ensureNotPaused(opp)：暂缓中(3) → 66003「暂缓中的商机不允许此操作，请先取消暂缓」；复用调用方已查实体零额外查询。
- ensureClaimAllowed(oppId)：查商机（null→66002）→ matcher.loadPublished().match(ownerDeptId) → 规则 allowFreeClaim≠1（含 null 保守禁）→ 新码 66014「该商机所属部门已配置禁领规则，无法自由领取，请联系管理员分配」。
D-07 接入 13 写端点（阶段切换既有 66005 不动，focus/touch 用户行为日志不拦，D-08 剔除故 close 不拦）：edit、follow add/delete、site-survey add/delete、attachment add/delete、customer add/set-primary、team add/update/delete、scheme-card save/submit。其中 addFollow 顺带修复「insert 后才查商机且 null 静默容忍」的坏顺序（改为前置 requireOpp + 66002）；submitCard 新增 requireOppByCard（脏数据报 66002）。
D-09 接入 claim/claim-batch（TransitionController）：claim 单领前置校验；claim-batch 全量预检（确定性拒绝先拦，避免部分领取；CAS 类竞态仍由状态机兑底）。release/assign 不拦（裁决：分配是禁领替代路径）。matcher 快照实时查库无缓存问题，性能符合票面要求（复用同一 matcher，非全表扫）。
OpportunityConstants：+CODE_OPP_CLAIM_FORBIDDEN = 66014。

单测 192/192 全绿（crm-opportunity 全模块）：新增 OpportunityActionGuardTest 7 用例（暂缓拦截/放行 + 禁领部门专用/默认/allow=1/空快照/商机不存在）+ OpportunityDetailServiceImplTest 2 用例（edit 暂缓拒/放行，守卫用真实实例）。既有 Sub/SchemeCard 测试兼容性修复（新构造参数补 @Mock guard 保持 no-op；submit 三用例补 opp stub）。
运行时验证 26/26（t05-verify.py）：Part P 20 项——14 写端点暂缓态逐一 66003、拦截无副作用（团队/跟进行数不变）、只读放行、resume 后 edit 恢复；Part R 6 项——owner_dept 非空、部门专用禁领 claim 66014、claim-batch 全量预检 66014 且两单均未被领取、放行版发布后 claim/claim-batch 恢复成功。
e2e 回归：F14 状态机 22✅/1⚠/0❌（⚠=公海计数旁证，seed 残留）；e2e-rules PR 段 10✅/1⚠/0❌（⚠=规则模块存量 50001 主键冲突，本票范围外）。回归证据另存 report-core-t05-regression.md / report-rules-t05-regression.md。
e2e 脚本断言按裁决同步修正：F14「暂缓不可直接关闭」→「暂缓态关闭（E6 2,3→4 合法边，D-08 翻案）」；e2e-rules U03「按缺陷预期放行」→「release-pool 放行（D-09 裁决：仅 claim 接禁领）」。

ADMIN（罗伟健）是全库 6047 用户中唯一 dept_id 为 NULL 的，致 D-13 修复的创建快照落 null、部门专用规则永不命中 → 补 dept_id=744841292348915712（广东保伦电子，顶级部门）。
F14 的 11 个 e2e-seed 商机被此前清场软删 → 复活并按名字语义复位状态（推进2/暂缓3/关闭4/公海1）。票 11 正式刷 seed 时可直接复用 t05-seedreset.py。