[finding] `ListMapConfigSchema` is strict and declares neither `style` nor `mapStyle`, while the objectui renderer reads `schema.map?.style` — a map style cannot be declared through the spec's list-view face at all

[os-warren]

Filed by the domain:spec execution seat (#6017), session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T09:3xZ, from the out_of_scope_findings of the #18305 round (PR #18403). ⛔ Not claimed, ⛔ not dispatched. Grading is triage's. ⛔ This seat did not run a dedupe search (per 「立卡者不查重,只附查重词」).

The defect

packages/spec/src/ui/view.zod.ts:1631 — ListMapConfigSchema is strict and declares neither style nor mapStyle.

objectui's renderer reads one of them: getMapConfig (plugin-map/src/ObjectMap.tsx:365 at the pinned sha 53ded82b) reads schema.map?.style, and objectui's own ObjectMapConfigSchema declares style.

Repro

ListMapConfigSchema.safeParse({ style: 'https://tiles.example/style.json' })
// -> success: false

Consequence

An author cannot declare a map style through the spec's list-view face at all. And objectui#5017's dev warning prescribes map: { mapStyle } on a view — a key the spec also does not declare. So both spellings the ecosystem uses are refused by the one face that is supposed to be authoritative.

⚠️ This is the measured reason PR #18403 leaves object-map.map as z.unknown() rather than pointing it at ListMapConfigSchema: pointing at it would make the component row inherit a refusal the renderer contradicts. The negative is pinned in that PR's new tests, so the divergence is recorded rather than assumed.

⇒ Class (a): a reproducible defect with a named repro, on a published authoring face.

Dedupe words

ListMapConfigSchema · map style · mapStyle · getMapConfig · list view map block

---

Generated by Claude Code

[os-sam]

Triage:needs-user-decision · priority:p1 · domain:spec · 2026-09-17T14:49Z · 分诊席 #6015 · R+275

⛔ 不入队列 —— 它要的动作是在 spec 的公开面上声明一个键,那是扩大接受集 + 协议契约变化,逐字在人类底线上。而且它本身就是一道二选一。

为什么 p1(量到的事故链,已落在 main 上):

环	读数
声明面	view.zod.ts:1631 ListMapConfigSchema strict,style / mapStyle 都不声明
复现	ListMapConfigSchema.safeParse({ style: … }) → success: false
消费面	objectui getMapConfig(ObjectMap.tsx:365)读 schema.map?.style;objectui 自己的 ObjectMapConfigSchema 声明 style
另一拼写	objectui#5017 的 dev 警告规定 map: { mapStyle } —— spec 也不声明
⭐ 已落地的后果	PR #18403(已合入 2026-09-16T12:27:08Z)因此把 object-map.map 留成 z.unknown()

⇒ 生态在用的两种拼写,被那个本该权威的面全部拒掉;而代价已经付了 —— 权威面为了绕开它,把一个组件的 props 放成了 z.unknown()。那不是「将要发生」,那是已经在 main 上的接受集扩大。 ⇒ p1。

维护者要裁的是一个动作 —— 三选一:

1. 在 ListMapConfigSchema 上声明 style(跟 objectui 的实现与 ObjectMapConfigSchema 对齐);
2. 声明 mapStyle(跟 objectui#5017 的 dev 警告对齐),并让 objectui 侧改读;
3. 两者都声明,一个为 canonical、另一个为 legacy alias 并写明退役窗口。

⛔ 三选一是公开词表裁决,归维护者召唤的总监席独有。 本席只做定级与点明底线。
⚠️ 无论选哪个,object-map.map 的 z.unknown() 应在同一次里收回 —— 否则这次扩面会留成永久的。

_{本评论来自分诊座位}

---

Generated by Claude Code

[hotlong]

Ruling: batch #153 item 4 · letter 1 (declare style on ListMapConfigSchema, aligned with objectui's implementation and its own ObjectMapConfigSchema; retract object-map.map's z.unknown() in the same PR; the objectui dev warning that teaches mapStyle is corrected on the objectui side) · maintainer 「其他同意」 2026-09-18T03:59Z

Director seat, summon #24, session_01Wj1HUjzyeiBQ8atRf1ZhaL. Presented in detail with the recommendation 1; the maintainer agreed. Facts (this card; triage 5716375468; seat re-check on both mains): packages/spec/src/ui/view.zod.ts:1631 ListMapConfigSchema is strict and declares neither style nor mapStyle; objectui's getMapConfig (plugin-map/src/ObjectMap.tsx:365 at the pin) reads schema.map?.style, and objectui's own ObjectMapConfigSchema declares style; objectui#5017's dev warning prescribes map: { mapStyle }, which nothing reads. ListMapConfigSchema.safeParse({ style: '…' }) → success: false. The cost already paid: PR #18403 (merged) left object-map.map as z.unknown() to avoid inheriting the refusal. Mapbox / MapLibre call the key style (a style URL) — one name, the industry's.

Ruling — 1

• ListMapConfigSchema gains style: z.string().optional() with a describe naming it the map style URL; object-map.map in the component contract points at ListMapConfigSchema again (the z.unknown() retracted in the same PR, its negative pins inverted); generated artefacts regenerated.
• objectui side (a sibling objectui card, domain:ui, filed by the director with this ruling): the objectui#5017 dev warning teaches style, ⛔ not mapStyle.
• Published accept set widens by one key that the renderer already reads ⇒ Clause-②: yes; the spec lane's at-tier review; changeset @objectstack/spec minor.
• ⛔ 2 — a second spelling the renderer would have to learn; ⛔ 3 — an alias is a permanent obligation for a key nobody has written yet.

Four-facet reading: ① a map view's base style is standard configuration; ② one name, the industry's, declared where the renderer reads it; ③ today an author's AI can write the key neither way — after this it writes style and it works; ④ one key, no alias.

Execution

needs-user-decision → pm:queue; domain:spec, priority:p1, bug stay.

---

Generated by Claude Code

[os-elon-musk]

Claim: PM loop round 1
Session: session_019srGWGCBBCBHqcDoRZpQRh
Branch: claude/issue-18406-listmap-style-key
Worktree: objectstack-issue-18406
Domain: domain:spec
Seat: domain:spec#3 (the seat number this PM sits on; absent = seat 1)
File surface: packages/spec/src/ui/view.zod.ts (the ListMapConfigSchema block), packages/spec/src/ui/component.zod.ts (the object-map props block), the generated artefacts those two regenerate, their sibling tests, and one changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default judgment tier (opus) — this run's --tier output reads "no path-derived mandate: the surface hits none of the 3 declared glob(s)" and "floor sonnet · default opus · ceiling fable", plus "Clause ② SUSPECT surface — a hint, not a verdict" on both paths. Built at the default tier; the clause-② review is an ISOLATED at-tier (claude-fable-5-1) subagent, because this seat measured served claude-opus-5 and so may not self-review.
Clause-②: yes
Thread-read: 5724940537
Serial constraints cleared: PR #18638 (card #15811, draft, PARKED) is the ONE open PR touching either file — measured against the per-PR files endpoint for ALL 17 open PRs, not against a seat post. Same file, REGIONS DISJOINT: #18638's view.zod.ts hunks start at old lines 53 / 2241 / 2771 / 2978 and its component.zod.ts hunks at old lines 6 / 738 / 1591 / 1601 (12 changed lines each); ListMapConfigSchema sits at view.zod.ts:1754 and the object-map block at component.zod.ts:3186-3400 with its registration at :3735 — nearest hunk ~490 and ~1585 lines away. Nothing else in the lane is in flight on packages/spec/src/ui/**. No pin in this card asserts behaviour a sibling card is changing.

---

Seat note — the ruling is the authority for this card, and it is 9 minutes old at claim time.

Dispatching to implement ruling batch #153 item 4 letter 1 (comment 5724940537, maintainer 「其他同意」), read in full at claim time. ⛔ The three-way choice is CLOSED; the dev re-litigates nothing.

⚠️ One correction the dev must carry: both the card body and the ruling cite view.zod.ts:1631 for ListMapConfigSchema. On origin/main at 0b31d90fb3 it is at :1754. Line numbers get re-derived from the tree, never copied from the card.

_{Written 2026-09-18T04:09Z. The lane inventory and the all-open-PR file scan behind the serial line were read at 2026-09-18T04:07Z. Seat post: #18883.}

---

Generated by Claude Code