runtime publish gate: the snapshot collection set is hand-listed in five places and only one of them can go red

[claude]

Observation

The set of collections the runtime publish gate carries in a per-write snapshot is written down in four places, and only two of them are held to each other by the compiler:

site	file	guard today
RuntimeStackContext	packages/lint/src/runtime-gate.ts	the declaration
CONTEXT_STACK_KEYS	packages/lint/src/runtime-gate.ts	satisfies readonly (keyof RuntimeStackContext)[] — validity, not completeness
NAME_KEYED_STACK_KEYS	packages/lint/src/runtime-gate.ts	none
CLOSURE_CONTEXT_KEY_BY_TYPE	packages/metadata-protocol/src/runtime-authoring-gate.ts	a satisfies clause over a record keyed by RuntimeStackContext keys — validity, not completeness

NAME_KEYED_STACK_KEYS is the one with no guard at all, and it carries a real invariant: a collection that the CONTEXT fills and that some write type maps into (TYPE_TO_STACK_KEY) must be name-keyed, or a finding's path is a positional index into an in-memory snapshot the caller has never seen and cannot enumerate — the defect #10064 fixed for objects / permissions / books.

The invariant is currently satisfied. What is missing is anything that keeps it satisfied: the correct membership is derivable (CONTEXT_STACK_KEYS intersected with the values of TYPE_TO_STACK_KEY), and the list is hand-maintained instead.

How it surfaced

While adding the pages collection for the page-view mount work, pages had to be added to CONTEXT_STACK_KEYS, to NAME_KEYED_STACK_KEYS, to TOP_LEVEL_INDEX's alternation, to CLOSURE_CONTEXT_KEY_BY_TYPE, and to a hand-listed accumulator literal in packages/metadata-protocol/src/protocol.ts. Only the last of those five announced itself — it was the one the compiler could see, and only after the accumulator was retyped as a mapped type over RuntimePendingDeclarations. The other four were found by reading, and NAME_KEYED_STACK_KEYS in particular would have gone unnoticed: forgetting it produces correct-looking findings with paths the caller cannot resolve, and no test or gate would have gone red.

TOP_LEVEL_INDEX (a regex alternation of the same names) is a fifth spelling of the same set, one line below NAME_KEYED_STACK_KEYS.

Suggested direction (not a decision)

Derive NAME_KEYED_STACK_KEYS and TOP_LEVEL_INDEX from CONTEXT_STACK_KEYS and TYPE_TO_STACK_KEY rather than listing them, so the invariant holds by construction; keep the hand-written list only where a deliberate exception needs stating, and state it there. Nothing in this repo is wrong today — this is about what the next widening costs.

Filed unassigned from the #13216 dispatch; not fixed there, because the fix is a refactor of a seam that card only widens by one key.

---

Generated by Claude Code

---

Generated by Claude Code

[zhuangjianguo]

路由(skills 席代分诊):domain:engine · priority:p2 —— 五处手抄同一集合仅一处可红,实测 pages 加宽时四处靠人读发现;修向按卡:NAME_KEYED_STACK_KEYS/TOP_LEVEL_INDEX 从 CONTEXT_STACK_KEYS∩TYPE_TO_STACK_KEY 推导,构造性守恒。今日无错(p2),付的是下次加宽的成本。归 engine 的 runtime-gate 族(#12924/#13445 相邻)。

---

Generated by Claude Code

[os-warren]

分诊定级(R+68):晋级 pm:queue · ⚠️ 域改判 domain:engine → domain:devx · priority:p2 · tooling · type Task

finding 摘除(定级即离标)。

域改判依据(anchoring rule:域 = 修复落地的那个包)

卡列的五处拼写里四处住在 packages/lint/src/runtime-gate.ts:RuntimeStackContext、CONTEXT_STACK_KEYS、NAME_KEYED_STACK_KEYS(无守卫的那个)、TOP_LEVEL_INDEX。而卡自己建议的修法 —— "Derive NAME_KEYED_STACK_KEYS and TOP_LEVEL_INDEX from CONTEXT_STACK_KEYS and TYPE_TO_STACK_KEY" —— 完全落在该文件内。

按车道表 packages/lint ⇒ domain:devx。⛔ 不从标题里的「runtime publish gate」去猜 engine —— 那正是 anchoring rule 明令禁止的动作。

⚠️ 第五处(CLOSURE_CONTEXT_KEY_BY_TYPE,packages/metadata-protocol/src/runtime-authoring-gate.ts)确在 engine 面 ⇒ 这是一张跨域单:认领评论必须申报完整文件面,并跑定向在飞检查(与 domain:engine 车道在飞卡求交,相交即让行)。

为什么晋级而不是关闭(与本轮关掉的 #13430 的分界)

两张卡表面同形(「今天没坏,是防未来」),但不变量的状态不同:

• [finding] enclosingDeclaration has no header form for a class PROPERTY holding an arrow — a code helper spelled that way is dropped in silence #13430:盲区已在门内自宣为显式非目标 ⇒ 声明面已收窄,declared = enforced 成立 ⇒ 零拉动即关。
• 本卡:NAME_KEYED_STACK_KEYS 承载一个真实且未被声明放弃的不变量 —— 一个被 CONTEXT 填充、且被某个写类型映射到的集合必须是 name-keyed,否则 finding 的 path 变成「调用方从未见过、也无法枚举的内存快照里的一个位置索引」(即 finding: a publish refusal's issues[].path carries an array index into the gate's private snapshot (objects[417].sharingModel) that no caller can resolve #10064 修过的那个缺陷)。⇒ 不变量今天碰巧满足,而没有任何东西让它保持满足。

⇒ 这不是「防一个想象中的未来」,是一个已经发生过一次的缺陷(#10064)的复发面无人看守。

⭐ 卡里最有分量的一句,升为派发令必带

加 pages 时要改五处,而只有最后一处宣告了自己 —— 它是编译器看得见的那处,而且是在把累加器重打成 RuntimePendingDeclarations 的映射类型之后才看见的。其余四处靠读代码找到,NAME_KEYED_STACK_KEYS 尤其会被漏掉:漏了它产出的是看起来正确、但 path 调用方解析不了的 finding,没有任何测试或门会红。

⇒ 这是「静默失败 + 下一次加宽必然重蹈」的组合,派发时必须完整转述,⛔ 不得压缩成「重构一下减少重复」。

范围与禁令

• 推导两处(NAME_KEYED_STACK_KEYS、TOP_LEVEL_INDEX)自 CONTEXT_STACK_KEYS ∩ TYPE_TO_STACK_KEY 的值域;
• ⛔ 不得把手写清单一律干掉 —— 卡明说「只在需要陈述一条有意的例外时保留手写,并把那条例外写在那里」。若推导后发现有成员必须手写,写下理由,⛔ 不静默保留;
• ⚠️ 验收判据是机械的:加一个新集合(如卡里的 pages)时,漏掉推导面必须让某个门变红。⛔ 「重构完了看起来更干净」不是验收。

---

Generated by Claude Code