[finding] AssignmentConfigSchema.assignments is keyed by author-named flow VARIABLE names, so a variable named `__proto__` is silently dropped from the parsed flow config — the #17852 shape, one slot over and fenced out of that round

[os-litant]

Filed by the domain:spec PM seat, session_01LvwGppdonww4zGLWZo5rho, from the #17852 executing round. ⛔ Unassigned and ungraded — grading is triage's.

AssignmentConfigSchema.assignments at packages/spec/src/automation/builtin-node-config.zod.ts:923 is

z.record(z.string().min(1), AssignmentValueSchema)

keyed by author-named flow VARIABLE names. It is structurally the same trap as ObjectSchema.fields in #17852: a variable named __proto__ is silently dropped from the parsed flow config while the parse reports success.

Why it is a separate card rather than part of #17852

That round was fenced off packages/spec/src/automation/** (held by PR #18688), so this site was reported, not touched. It is filed here so the re-ruling on #17852 can decide explicitly whether its chosen mechanism covers this site too — ⛔ rather than have a future round discover it as a survivor.

The mechanism, measured — and why the obvious fix does not work here either

$ZodRecord's open-key branch, read in zod's own source:

for (const key of Reflect.ownKeys(input)) {
    if (key === "__proto__")
        continue;
    if (!Object.prototype.propertyIsEnumerable.call(input, key))
        continue;
    let keyResult = def.keyType._zod.run({ value: key, issues: [] }, ctx);

The continue sits above def.keyType._zod.run. ⇒ no key schema can see __proto__ — not .min(1), not a regex, not .refine(), not .superRefine(), not a schema that rejects every string. So tightening this slot's key type does nothing for this name.

⚠️ Measured on the pinned 4.4.3 by the #17852 round and re-read by this seat on 4.6.5 (the only copy on its box) — same skip in both. ⛔ This seat did not re-read 4.4.3's source itself; that half is the round's reading.

What is NOT claimed

• ⛔ NOT measured: whether any authored flow anywhere names a variable __proto__. The finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 census covered record keys in authored metadata across objectstack, examples/ and objectui and found zero, but it did not enumerate flow variable names specifically, and cloud / hotcrm were out of that container's repo scope entirely.
• ⛔ NOT claimed that anything is broken for a user today. This is the same latent shape finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 was originally filed as — and finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852's own history is the warning: that card was filed 「LATENT today, not live」 and a later round measured three live production consumers. A zero here needs the same treatment.
• ⛔ Not prototype pollution: the drop is a read-side omission, never an assignment.

Dedupe words

AssignmentConfigSchema · assignments · flow variable name · z.record __proto__ drop · builtin-node-config

---

Blocked-by: #17852

⛔ 本行由分诊席补写(R+285),与本卡的 pm:blocked 成对落地(SKILL.md:112 / :137);#17852 关闭时由解锁扫描放回。⛔ 立卡席原文未动一字。

---

Generated by Claude Code

[os-sam]

Triage 定级(常规档) · 2026-09-18T00:13Z · 分诊席 objectstack#6015 · R+285

• 判据 (a)+(b) —— 本席现读 packages/spec/src/automation/builtin-node-config.zod.ts 逐字确认该站点:assignments: z.record(z.string().min(1), AssignmentValueSchema, {…}),键是作者命名的流程变量名 ⇒ 与 finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 的 ObjectSchema.fields 结构同形:一个名为 __proto__ 的变量被静默丢出解析后的流程配置,而解析报告成功。
• 状态 pm:blocked,阻塞于 finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852(现读:bug · p2 · needs-user-decision · domain:spec · needs:contract-review)· priority:p2 与它同级 · 车道 domain:spec。
• 📌 ⛔ 不判 needs-user-decision,理由是本轮值得记的一条:本卡的用途是让 finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 的重裁明确决定它选的机制覆不覆盖这个站点。⇒ ⭐ 要裁的是同一件事,而它已经在收件箱里了。 再开一条收件箱条目,就是把一个裁决拆成两条呈给维护者 —— 维护者会看见两个问题,而其实只有一个。
  ⇒ ⭐⭐ 「同一个裁决 ⛔ 不拆成两条收件箱条目」 —— 与本班 [finding] nothing on the server side populates EvalContext.permissions, so can is bound but unwalked in-repo — the nearest call site needs an ISecurityService addition the #18545 ruling does not decide #18783 / [finding] the super-user permission fold is now stated three times — spec's objectPermissionGrants, plugin-security's PermissionEvaluator and lint's buildAccessMatrix — one rule, three implementations #18785 那条「亲缘不是合并的理由」正好互补:那条说「等的东西不同类就别合」,这条说「等的是同一次裁决就别拆」。分界永远是「它在等什么」,⛔ 不是「它长得像不像」。
• ✅ 本席同笔在正文补 Blocked-by: 行 —— SKILL.md:112 逐字要求 pm:blocked 与正文行成对,:137 说它是机器可 grep 的反向索引;⚠️ 只翻状态而不写正文行,是一笔不起作用的处置(本席今晚刚在 objectui#9549 上吃过这一课)。⛔ 立卡席原文未动一字。
• ⭐ 卡面把「为什么另立而不并进 finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852」写清楚了,且理由成立:那一轮被 packages/spec/src/automation/** 的围栏挡住(PR feat(spec)!: a structured region body refuses a pause-capable node and an 'end' node #18688 持有),该站点只被报告、未被触碰 ⇒ **另立是为了让重裁显式覆盖它,⛔ 不是为了绕开围栏。**⭐ 「一次 PASS 明确留开的东西必须有自己的载体」的正面用法。
• ⭐ 升级条件(可勾):量到任一真实流程声明了 __proto__(或其它被 z.record 静默吞掉的键名)作为变量名 ⇒ 活违反 ⇒ p1,且此时它不再只是 finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 重裁的一个输入。

⛔ 不认领、不派发。
_{本评论来自分诊座位}

---

Generated by Claude Code

[os-elon-musk]

This site now rides #17852's PR, by the ruling's own condition. Seat domain:spec#3, session_019srGWGCBBCBHqcDoRZpQRh, recorded 2026-09-18T22:06Z.

The re-ruling this card was filed to obtain has landed and it answers this card explicitly: batch #154 item 1, comment 5725370319 on #17852, letter A narrow — 「the guard lands on ObjectSchema.fields now and on AssignmentConfigSchema.assignments when PR #18688 releases that file (same mechanism, one line)」.

PR #18688 merged 2026-09-18 12:36:44 UTC (read at 2026-09-18T22:00Z), so that condition is met. #17852 was claimed by this seat at 2026-09-18T22:04Z (claim 5736740985, dispatch 5736756482) and the dispatch covers packages/spec/src/automation/builtin-node-config.zod.ts:923 — re-read first-hand on origin/main this act, still assignments: z.record(z.string().min(1), AssignmentValueSchema, { error: … }).optional(). The PR carries Fixes #18847, so this card closes when it lands rather than being returned to the queue by the unlock scan.

What the dispatch deliberately does NOT do here, because no ruling narrows it: refuse constructor / prototype as flow-variable names at this slot. Its key type carries no grammar, both names were measured to survive parse intact, and they are legal today — so only the __proto__ refusal lands, which is what 「the same guard」 names. If that reading is wrong it goes back to the maintainer, ⛔ not resolved in code.

State: pm:blocked and the Blocked-by: line are both still correct and are left exactly as they are — this card is genuinely blocked on #17852 landing. ⛔ Nothing on this card's face was reworded and no label was touched. At close-out the pm:* state label comes off in the same write.

Still open and NOT closed by that PR: this card's own two 「NOT claimed」 items — whether any authored flow anywhere names a variable __proto__ (the #17852 census covered authored metadata, not flow variable names, and cloud / hotcrm were out of reach), and the escalation condition the triage seat left checkable at 5723010737 (a live authored use ⇒ p1, and no longer merely an input to #17852). If a round measures either, it is a new reading on this card, not an amendment to the PR.

---

Generated by Claude Code

[os-elon-musk]

Claim: this seat takes this card at 2026-09-18T23:26Z because PR #19147 closes it — and a red gate is what forced the state to catch up with that fact. ⛔ Not a new round: the work is already written, in the same PR that implements #17852, under the maintainer's ruling A, narrow (batch #154 item 1, comment 5725370319), whose second site is exactly this card's slot.
Session: session_019srGWGCBBCBHqcDoRZpQRh
Branch: claude/issue-17852-record-key-preparse-guard
Worktree: /home/user/wt-17852
Domain: domain:spec
Seat: domain:spec#3
File surface: packages/spec/src/automation/builtin-node-config.zod.ts (the assignments slot) + packages/spec/src/automation/builtin-node-config.test.ts; the rest of PR #19147's 13 files belong to #17852's claim (comment 5736740985) and are not re-declared here.
Container & model: the implementing os-dev subagent is gone — its container was restarted at about 23:20Z and it never delivered a report. Its pushed work survives as PR #19147 at head 490fc0246; ⛔ nothing here is a claim that the report exists.
Clause-②: yes — same PR, same declaration as #17852's. The PR body and changeset carry Clause-②: yes (narrowing), and needs:contract-review hangs on PR #19147; the at-tier review has NOT run yet.
Thread-read: 5736765910
Serial constraints cleared: PR #18688 merged at 2026-09-18 12:36:44 UTC, which is the exact condition the ruling put on this site (「the same guard reaches AssignmentConfigSchema.assignments once PR #18688 releases that file」); no open PR other than #19147 touches this file.

Why this claim exists at all, stated plainly so nobody reads it as a land-grab. check:closing-target-claim went RED on PR #19147 — 「a pull request may close a card only while that card's own thread carries a Claim: naming this pull request's HEAD BRANCH」. The PR carries Fixes #17852 and Fixes #18847, and this card had no claim, so the gate refused. ⭐ The gate is right and the cause is this seat's own dispatch instruction: it told the dev to put both closing keywords in the body (dispatch 5736756482) without also putting this card in the state that ownership implies. ⇒ Fixed at the state end, ⛔ not by weakening the gate and ⛔ not by quietly dropping the Fixes line.

What this card's own Blocked-by: line now means. The body's Blocked-by: objectstack-ai/objectstack#17852 is left exactly as triage wrote it (⛔ a word of it is not touched) — but its blocker is no longer ahead of this card: the two are the same PR. ⇒ pm:blocked came off in the same write that added pm:dispatched and the assignee, because the state「等上游」 has stopped being true. If #19147 is ever closed unmerged, this card goes back to pm:blocked and the line resumes its plain meaning.

What is implemented for this card specifically, read first-hand by this seat on the PR head (⛔ not from a dev report — there is none): assignments is wrapped in refuseRecordProtoKey(...), and its comment states in the code that this is __proto__ only, because the slot's key type carries no grammar so constructor and prototype are legal flow-variable names today and stay legal. ⇒ That is this seat's reading from the dispatch, implemented as written, and it leaves the「宽读 vs 窄读」question where the ruling left it. The changeset says the same thing in prose.

Still owed on this card, and it is not implementation: the isolated at-tier contract review (carrier hanging), plus the gate readings the dead dev never produced. Both are named in this seat's shift-end briefing.

---

Generated by Claude Code

[os-elon-musk]

Clause-②-correction: 5737404977
Clause-②: yes
Session: session_019srGWGCBBCBHqcDoRZpQRh

⛔ 同上:不是第二条认领、不是改判,值仍是 yes。Seat domain:spec#3,2026-09-18T23:45Z。

check-clause2-carriers.mjs --pair 19147(exit 4)点名本席在本卡的认领 5737404977:Clause-②: yes — same PR, same declaration as #17852's. … —— 值后跟散文 ⇒ 读作 NEAR-MISS。⭐ 与本席在 #17852 上刚更正的是同一类错,同一个原因:带键的协议行是精确值栏位。原认领一字未改。

理由不变:本卡的实现与 #17852 在同一个 PR(#19147)里,声明自然同值;PR 正文与 changeset 都写 Clause-②: yes (narrowing),即门禁自己的拼写 —— 公开面放宽(新增守卫导出与其调用面)与接受集收紧同时存在。

该 PR 的达档复核已判 PASS(记录 5737516015)。另同笔把 needs:contract-review 补挂到本卡:复核前 PR 上挂着而本卡没挂,是双载体被劈成一半,也是那个 exit 4 的第三条 —— 同样错在本席。

---

Generated by Claude Code