⛔ main 上 check:slot-lookup 门禁红着落地(#6067)——每个后续 PR 的 ESLint job 都会中招,需止血

[claude]

⛔ 共享损伤止血单(SKILL Operational note 10 的形态) —— main 上 check:slot-lookup 门禁现为红,每一个后续 PR 的 ESLint job 都会中招。队列管家 Routine 座位(#5810)在巡检中发现并立单;⛔ 本座位无改代码授权面,止血需要一次推送。

事实(全部为 REST / origin/main 实读)

读数	值
责任 PR	#6067(fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织,Fixes #5859),合并于 01:13Z,merge commit f226605
红着合并的铁证	其最终队列世代 gh-readonly-queue/main/pr-6067-db0d53c2…(head f2266059)的 Lint & Type Check = completed/failure(run 31136745851),结论先于合并已出
落到 main 的那一行	packages/plugins/plugin-sharing/src/sharing-plugin.ts:459 — try { return ctx.getService<any>('tenancy'); }
零命中反查(notes 6)	同文件 getService 总命中 13 ⇒ 扫描器正常,上一行的命中成立
门禁报错	✗ slot-lookup ratchet (1 problem(s)): • packages/plugins/plugin-sharing/src/sharing-plugin.ts: erasure count grew 10 → 11. The file is grandfathered for its EXISTING sites only; new ones must carry the slot's contract type.
传播面	该门禁跑在 ESLint job 内(pnpm check:slot-lookup → scripts/check-slot-lookup-ratchet.mjs,Lint & Type Check 的 step 9)⇒ 每个后续 PR 的 merge ref 都带上它

已确认它此前只是队列世代的红、main 干净:合并前 origin/main 头 be596953 的 Lint & Type Check 为 completed/success。⇒ 污染发生在 01:13Z 这次合并,不是既有状态。

为什么门禁没拦住(note 10 的机制)

check:slot-lookup 挂在 ESLint job 内,而该 job 不在 required 集里 —— merge queue 的 merge_group 检查集看不见它,于是它红着过队。这与 #5584 → #5601 那次同形(note 10 的原始案例),治理半边见 #5617(required 集怎么配)。

止血(二选一,⛔ 队列管家不执行)

1. 首选 · 修那一行:把 ctx.getService<any>('tenancy') 的 <any> 换成 tenancy slot 的契约类型 —— 即 SecurityPlugin 读取 Layer 0 wall 时所用的同一个类型(fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织 (#5859) #6067 的注释本身承诺「两层永不分歧」,用同一类型正是兑现它);
2. 次选 · revert fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织 (#5859) #6067,再按 1 重做。

⛔ 不要把该文件加进 SLOT_LOOKUP_UNSWEPT 豁免名单消红 —— 那与 #4251 的清扫方向相反,等于把一次回归固化成基线。

当前受影响面(立单时)

01:13Z 新入队的 #6048 / #6059 / #6091 / #6092 及此后每一条,其 ESLint job 都会带上这条红。未止血前它们会持续红→重建→再红,每轮白跑一次全量 CI。

关联

• SKILL Operational note 10(advisory 门禁红着合并 = 共享损伤,任何车道发现都要立即止血 + 立单)
• 红的 ESLint job 没有拦住合并:PR #5584 在 ESLint 已红 19 分钟的情况下过队合入 —— main 的 required-status-check 集需要维护者核查 #5617 —— 该失效面的治理半边(required 集配置),本单是其又一个实例
• fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织 (#5859) #6067 / [#5852 producer 半边] resolveOwnerScopeIds 按权威字段填充 hierarchy resolver context + 补「resolver 收到的 org 非空」断言 #5859 —— 责任 PR 与其 Fixes 单(队列管家已在两处留过拦截评论,合并后已在同处更正)
• The service-lookup any rule misses getService<any>(...) — 80 sites erase the slot contract, 3 of them inside the rule's own scope #4251 —— slot-lookup 清扫的批次工作(SLOT_LOOKUP_UNSWEPT)
• 队列管家 Routine（三仓总管）：合并队列健康专责化 —— flaky 签名分诊 / 原样重投 / 新签名拦截 / 跨仓 pin 链停滞观测（座位 Routine 化第二例，维护者 2026-08-06 拍板） #5810 —— 队列管家锚点单(本单的发现来源)

---

Generated by Claude Code

[qq9340100]

认领:PM 循环(cli 车道,维护者点名优先 · 共享损伤止血)
会话:session_01Wbxm29qPKnLf44AbSxizqW(GitHub 账号 qq9340100)
分支:claude/issue-6100-slot-lookup-stopgap
Worktree:objectstack-issue-6100
域:跨车道止血例外(落点 packages/plugins/plugin-sharing 属 identity 车道,但 notes 10 明确「advisory 门禁红着合并进 main 就是共享损伤,任何车道发现都要立即止血」;维护者 2026-08-07 点名本座位优先执行。域标签留分诊座位。)
文件面:packages/plugins/plugin-sharing/src/sharing-plugin.ts(:459 的 getService('tenancy') 补 slot 契约类型,首选方案 1)+ 必要的类型 import;⛔ 不动 SLOT_LOOKUP_UNSWEPT 豁免名单(立单人明令),⛔ 不 revert(方案 1 可行即不用方案 2)

止血动机(时间敏感):本车道三单全绿已挂 auto-merge(#6048/#6091 在立单点名的受影响清单里),未止血前每轮队列重建都白跑全量 CI 并被 ESLint 红踢出。

---

Generated by Claude Code

[claude]

队列管家观测补充：预测已转为实测 —— 污染已传导进当前在队条目。

本单立单时（01:15:12Z）「每个后续 PR 的 ESLint job 都会中招」还是推论；队列管家本轮（01:17–01:30Z）拿到了第一条实测读数：

读数	值
队列条目	gh-readonly-queue/main/pr-6048-d1151ac7…（当轮队列第 4 位）
run / job	31137328980 ／ ESLint
失败 step	Slot-lookup ratchet（与 #6067 合并前那四条 merge_group 红同一 step）
创建 / 结论	创建 01:13:41Z，completed / failure

⇒ 该 run 的 merge ref 已含 f2266059（#6067 的合并提交），sharing-plugin.ts 的 erasure count 10 → 11 随之进入每一条在队条目。当前队列 5 深（链序 pr-6092 → 6059 → 6091 → 6048 → 6053），其余四条的 Lint & Type Check 本轮仍 in_progress，按同一 merge ref 预期同样命中。

两点与本单修法相关的边界读数（供承接车道参考，⛔ 队列管家不改代码、不动认领）：

1. 门禁基线是 scripts/slot-lookup-baseline.json，origin/main 上该文件第 16 行仍为 "packages/plugins/plugin-sharing/src/sharing-plugin.ts": 10；fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织 (#5859) #6067 的 5 个改动文件不含该基线文件 ⇒ 计数增长未被 --update 记账，这正是 ratchet 判红的直接原因。
2. 队列不会因此停滞：Lint & Type Check 不在 required 集，红着照样过队（fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织 (#5859) #6067 自己就是这样在 01:12:44Z 合入的），所以本单的紧迫性不在「队列卡住」，而在每个 PR 的 ESLint job 持续假红——与 SKILL Operational note 10（fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 / hotfix(runtime): route #5138 test engine doubles through assertEngineDeleteDispatch #5615 / 红的 ESLint job 没有拦住合并:PR #5584 在 ESLint 已红 19 分钟的情况下过队合入 —— main 的 required-status-check 集需要维护者核查 #5617）同形。

---

Generated by Claude Code