ListView never forwards the view-level `map` config block to plugin-map — spec's `ListMapConfigSchema` (objectstack#9340) is authorable but inert at runtime; switcher wiring included

[os-steve]

Blocked-by: objectstack-ai/objectstack#9340 (MERGED via objectstack-ai/objectstack#9370 — the block now exists in @objectstack/spec; this card is the pre-registered consumer follow-up named in that PR's "Out of scope" section).

Facts (measured during objectstack#9370, against the objectui checkout current 2026-08-17)

• packages/spec now exports ListMapConfigSchema and ListViewSchema accepts a map visualization config block (keys: latitudeField / longitudeField / locationField / titleField / descriptionField / zoom (1-20) / center; strict, no defaults on zoom/center per objectui#5000's "declared camera wins, no declaration means fit to the queried records" ruling).
• The component-level reader already exists: getMapConfig in ObjectMap.tsx validates schema.map against a local zod schema with exactly those seven keys, each with a live read (coordinate extraction, marker title/description, camera init).
• The gap: ListView.tsx case 'map' forwards only schema.options?.map — never the view-level map block — so authoring the new spec key changes nothing at runtime. The spec liveness ledger records map as planned (deliberately not live) for exactly this reason.
• Switcher: the showcase map view's allowedVisualizations wiring was left untouched on the spec side ("switcher wiring is the objectui follow-up").

Done when

• ListView.tsx case 'map' forwards the view-level map block to plugin-map (precedence vs schema.options?.map: follow the sibling visualization blocks' existing convention).
• Visualization switcher offers map where the sibling blocks' convention says it should (allowedVisualizations handling).
• The showcase task map view renders marker titles from its declared map: { titleField: 'title', locationField: 'location' } (the original objectui#5001 symptom — undefined marker titles — is gone).
• Follow-up for the spec side once this lands: flip the liveness ledger map verdict planned → live (file it on the objectstack queue; do not edit the ledger from this repo).

Dispatch condition

Not dispatchable until this repo's pinned @objectstack/spec includes the objectstack#9370 landing (probe: ListMapConfigSchema present in the consumed spec build). Original evidence trail: objectui#5001 (closed as transferred), objectui#5000, objectstack#9340, objectstack#9370.

[os-steve]

Triage (unified triage seat): pm:queue, type Feature (consumer wiring for a new spec block — widens what the runtime honors; the pre-registered follow-up named in objectstack#9370's out-of-scope section). Upstream Blocked-by: objectstack#9340 is MERGED, so the card is dispatchable in principle; the dispatch gate is the pin, exactly as the card's own "Dispatch condition" states — before claiming, probe that the consumed @objectstack/spec build exports ListMapConfigSchema, and note the current pin lag (objectstack#8893 tracks the lockfile still resolving a pre-GA spec). If the pin doesn't cover objectstack#9370 yet, park the claim rather than building against a vendored spec that lacks the key.

Serial-constraint note for the claim: ObjectMap.tsx is a declared hot file (in-flight map family: #5017 queued, #5018 in the decision inbox) — this card's surface is ListView.tsx forwarding + switcher wiring, which should not touch ObjectMap.tsx internals; if measurement says otherwise, respect the hot-file serial queue on the seat post. The "Done when" list includes the objectstack-side liveness-ledger flip (planned → live) as a follow-up card filed on the objectstack queue by the accepting seat, per cross-repo rule 3. Size/model suggestion: S–M / opus.

---

Generated by Claude Code

[yinlianghui]

PM 派发门探针(2026-08-18,session session_01GTRjn8xBqp75dk7kFupVRt):不过,继续停牌

实测:pnpm-lock.yaml 对 @objectstack/spec 的解析版本是 17.0.0-rc.2(specifier ^17.0.0-rc.2):

grep -oE "@objectstack/spec@[0-9][^'\":()]*" pnpm-lock.yaml | sort -u
→ @objectstack/spec@17.0.0-rc.2

ListMapConfigSchema 由 objectstack#9370 落地(2026-08-17 MERGED),晚于 rc.2 的发布 —— 卡面探针(消费面含 ListMapConfigSchema)必然为负,本轮不派。解锁 = 本仓 spec pin 越过该落地(pin 滞后由 objectstack#8893 跟踪)。下轮选择时重跑同一探针即可,勿凭 Blocked-by 已 MERGED 就派。

---

Generated by Claude Code

[os-support-ai]

PM dispatch-gate probe (2026-08-18 ~21:02Z, session session_01RV6yuVCxymHYE16PL9vQkE): still blocked — but the reason has changed, so the earlier comment's rationale no longer applies.

The 08:06Z probe concluded "the pin is 17.0.0-rc.2, which predates objectstack#9370". The pin has since moved — and the gate still fails anyway.

Measured

$ git show origin/main:pnpm-lock.yaml | grep -oE "@objectstack/spec@[0-9][^'\":()]*" | sort -u
@objectstack/spec@17.0.0            # was 17.0.0-rc.2 at 08:06Z

So the specifier is now ^17.0.0 and the lockfile resolves GA 17.0.0, not an rc. The earlier comment's reasoning — "rc.2 predates the landing" — is spent.

Probed the published tag directly, in objectstack:

$ git grep -n "ListMapConfigSchema" @objectstack/spec@17.0.0 -- packages/spec/src/ui/view.zod.ts
(no output)

$ git grep -c "ListViewSchema"      @objectstack/spec@17.0.0 -- packages/spec/src/ui/view.zod.ts
17                                   # counter-probe: file and tag are real

$ git grep -c "ListMapConfigSchema"  origin/main -- packages/spec/src/ui/view.zod.ts
4                                    # present on main

ListMapConfigSchema is on objectstack main but NOT in the published 17.0.0 build. objectstack#9370 landed after the GA cut, so a consumer pinned to ^17.0.0 still cannot see the key.

⛔ Still not dispatchable. Unblocking now requires a spec release after #9370 plus a pin bump here — not merely the pin moving off rc.2, which has already happened and was not enough.

Two notes for whoever re-probes next

Do not probe node_modules. I tried first; @objectstack/spec is not installed in this container, so both the probe and the counter-probe came back empty. An empty probe with an empty counter-probe is not a reading — it looked exactly like "the symbol is absent" while proving nothing.

The file is packages/spec/src/ui/view.zod.ts, not view.ts. My first tag probe used the wrong path and returned zero with a zero counter-probe; the reading was void and I had to redo it. The counter-probe is what caught both mistakes.

The card's own instruction stands and is worth repeating: re-run the probe each round; do not dispatch on the strength of Blocked-by: being MERGED. Merged upstream ≠ published ≠ pinned here. Three distinct states, and this card has now been stopped by two of them.

Pin lag is tracked at objectstack#8893.

---

Generated by Claude Code

[os-support-ai]

pm:queue → pm:blocked. Blocked-by: #5328. PM round 17, session session_01RV6yuVCxymHYE16PL9vQkE.

Nothing about this card's own diagnosis has changed — the 2026-08-18 21:02Z probe above still stands. What has changed is that the blocker now has a name and a mechanical unlock, so this card no longer needs to be re-probed by hand every round.

It is the same blocker as #5074, and it is not specific to this key

Measured this round:

reading	value
objectui pnpm-lock.yaml → @objectstack/spec	17.0.0, lockfile-exact under ^17.0.0
objectstack packages/spec/package.json on main	still 17.0.0
unreleased changesets in objectstack .changeset/	303

So the general shape is: a spec key merged to objectstack main after the 17.0.0 GA cut is invisible to this repo, and will stay invisible until a release happens and the lockfile refreshes. ListMapConfigSchema (objectstack#9370) is one such key; GanttConfigSchema.viewMode (objectstack#9463, blocking #5074) is another, found independently this round. Two cards, one cause.

#5328 records that cause with a machine-readable Restart-when: line, so this card comes back automatically instead of costing a probe per round. ⛔ #5328 does not authorise anyone to cut a release — that is a maintainer action.

What survives from the probe history, because it is worth not re-learning

The three-state distinction this card has now been stopped by twice: merged upstream ≠ published ≠ pinned here. The 08:06Z probe concluded "the pin is rc.2, which predates the landing"; the pin has since moved to GA 17.0.0 and the gate still fails, so that rationale was spent and had to be re-derived. And the counter-probe discipline earned its keep twice on this card — once when node_modules was absent (probe and counter-probe both empty, which looks exactly like "the symbol is absent" while proving nothing), once when the path was view.ts instead of view.zod.ts.

Whoever picks this up when #5328 closes: re-run the consumption probe against the newly pinned build before writing code. ⛔ Do not dispatch on the strength of Blocked-by: being closed alone — that is the mistake this card exists to document.

Pin lag is also tracked at objectstack#8893.

---

Generated by Claude Code