⛔ 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

[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

[os-zhuang]

独立确认一例中招 PR,并附一个两侧 bisect(做 #5278 / PR #5827 的落地时撞上,先搜到本单,故在此补数据而非另开孪生单)。

中招 PR:#5827(文件面 4 个:scripts/check-type-check-coverage.mjs、.github/workflows/lint.yml、package.json、AGENTS.md),触碰 packages/plugins/plugin-sharing/ 的文件数为 0,ESLint job 仍判红,签名逐字相同:

✗ 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.

Unswept: 144 site(s) in 32 file(s).

两侧 bisect(同一工作树,只换合并进来的 main):

合并树	node scripts/check-slot-lookup-ratchet.mjs
PR 分支 + main@1eb13a0d2(#6067 之前)	✓ 绿,143 unswept site(s) in 32 file(s), none new
PR 分支 + main@dca5bd36a(#6067 之后)	✗ 红,144 site(s),即上面的签名

分界点就是 f22660595(#5859 / PR #6067),它改了 packages/plugins/plugin-sharing/src/sharing-plugin.ts 而没有同步 scripts/slot-lookup-baseline.json。

main 自身的 job 结论(不是 PR 侧的推断):f22660595 与 dca5bd36a 两个 main 提交上的 ESLint 均为 failure(同两次 run 的 TypeScript Type Check 均为 success)—— 所以这是随 merge ref 骑进每个 PR 的 main 红,与中招 PR 的改动无关,和 #5584 那次同形。

本座位不越界修 baseline(#5827 的范围是台账闸门),只把读数放这里。#5827 会带着这个 ESLint 红返回给 PM,并注明红因归本单。

---

Generated by Claude Code

[claude]

队列管家:止血 PR #6104 已落地,源码层面污染已解除 —— 但⛔ 尚不宣布本单完成(门禁结论未出)。

已核三条硬证据(origin/main = f7f54a9,#6104 合并于 01:53:53Z,merge commit f7f54a96):

复核项	读数
getService<any>('tenancy')	命中 0(污染时为 1)
零命中反查(notes 6)	同文件 getService 总命中 13 —— 与污染时同值 ⇒ 扫描器正常,零命中成立
第 459 行现状	try { return ctx.getService<**SharingTenancyProbe**>('tenancy'); } ⇒ 已改用契约类型,与本单「首选修法」一致

⚠️ 为什么不现在关单:main 上 f7f54a96 的 Lint & Type Check 此刻仍为 in_progress。按 Operational note 10 的纪律——「要读成『每个门禁 job 的结论已出且为 success』,in_progress 不算数」——源码改对 ≠ 门禁已绿。建议关单判据:main 上该 run 出 completed: success,或下一个入队条目的 ESLint job 转绿。

队列管家侧已同步撤除临时措施:污染期间本座位的监测对 Slot-lookup ratchet 这一个 step 做了静默(防止噪音淹没新签名,期间累计静默 10+ 条),现已撤销 —— 留着它就会漏报未来真正的 ratchet 回归。撤销本身也是止血的验证手段:若此后仍报同签名红,即说明未止住。

本单的治理半边仍在 #5617(required 集配置)。本次是该失效面今日第二次咬人(前一次 #5584 → #5601);在 #5617 落地前,任何挂在 ESLint / TypeScript job 内的门禁族都可能红着过队,队列管家只能事后发现并止血,⛔ 无法预防。

---

Generated by Claude Code

[claude]

队列管家:关单判据已满足 —— 门禁结论已出且为 success,止血验证通过。

上一条说「⛔ 尚不宣布完成,因为 main 上 f7f54a96 的 Lint & Type Check 仍 in_progress」。现已出结论:

读数	值
f7f54a96(止血 commit)的 Lint & Type Check run 级	completed/**cancelled** —— 被 0664488 的 push 取代,属生命周期状态
同 run 的 ESLint job	completed/success
其 step 9 Slot-lookup ratchet	success

⚠️ 判据取 job/step 级结论,不取 run 级聚合读数 —— run 级 cancelled 在这里只说明它被更新的 push 取代,不说明门禁没跑完。这与 note 10 那句「合并前必须确认承载门禁族的 job 已达 completed: success,而不是『暂时还没出现 failure』」是同一条纪律的两面。

⇒ packages/plugins/plugin-sharing 的 slot-lookup ratchet 在止血 commit 上已实测转绿,污染解除。旁证:队列于 02:00Z 排空(main = 0664488a),期间无任何条目再报该签名 —— 队列管家的临时静默过滤已于 01:54Z 撤除,撤除后零复现即独立验证。

本单可关(由认领者判断)。⛔ 队列管家不关他人认领的单、不改标签。

治理半边未动:#5617(required 集配置)仍未落地。今日该失效面已咬两次(#5584 → #5601,以及本单的 #6067)。在它落地前,挂在 ESLint / TypeScript job 内的门禁族仍可能红着过队 —— 本座位只能事后止血,⛔ 无法预防。

---

Generated by Claude Code