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

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.

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

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

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

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

Unblocked — premise re-verified on the merged ref and it still holds

Unlock scan by the spec@objectui seat after PR #5529 merged. Checked against origin/main @ 2d36552d2, not taken from the card text.

Blocker discharged

ListMapConfigSchema (objectstack#9340) shipped in @objectstack/spec@17.1.0, and this repo now pins it: lockfile resolves 17.1.0 for all six @objectstack/* packages, with 0 entries left at 17.0.0. All three states — merged upstream / published / pinned here — are finally true. Blocked-by: objectui#5328 discharged; pm:blocked → pm:queue.

The card's substance survives the pin

Measured on merged main: ListMapConfigSchema has zero references anywhere in packages/ or apps/. The spec-declared, view-level map block is still authorable and still inert at runtime — exactly what this card says.

⚠️ One thing that will look like the fix and is not

ListView.tsx:2143 does forward map config today:

locationField: schema.options?.map?.locationField || 'location',
...pickFlatMapConfig(schema.options?.map),

That is a different path: schema.options.map, described in its own comment as "an untyped bag", fed through the whitelisted flatten added by objectui#5177. It is not the spec's typed view-level block, and it is not a partial implementation of this card.

Whoever picks this up: do not read that call site as "already done", and do not fold the typed block into the options bag — the point of ListMapConfigSchema is that the view-level shape is declared and validated, which the bag by construction is not. The relationship between the two paths (does the typed block replace the bag, or compose with it?) is the first thing to settle, and the answer may be worth a decision card rather than a guess.

Switcher wiring, as the title says, is in scope.

Generated by Claude Code

Triage: domain:ui. ListMapConfigSchema is already authorable in @objectstack/spec (objectstack#9340) — the contract half exists. What is missing is the runtime forward: ListView never hands the view-level map block to plugin-map, plus the switcher wiring. Both are objectui renderer code, so the ui stream.

This is the declared-but-inert shape read from the consumer side: the declaration is fine, the reader is absent.

objectui three-stream split (maintainer 2026-08-21): domain:devx engineering surface · domain:spec contract surface · domain:ui everything else (published libraries and apps).

Routed via the maintainer direct-dispatch channel, this session, verbatim: 「objectui 有 79 张卡在车道视图之外（占该仓 35%），你帮我分批处理」. PM session session_0124Qg8rLvpXnQDwCmpKUmaJ. Not a Routine triage fire — the triage seat remains the standing producer of domain:* and may re-grade.

⛔ pm-state, assignee and scope untouched.

Generated by Claude Code

Claimed by an os-dev seat dispatched from the domain:ui PM seat.

session id: 01EuPCi56cnGyykygi3z9w4m
branch: claude/issue-5042-listview-map-config

No prior claim comment and no assignee were present at claim time (the six existing comments are triage/dispatch-gate probes, none naming a branch). Next: re-verify the discharged blocker on the installed pin (ListMapConfigSchema present in the consumed @objectstack/spec build) before writing any code, per this card's own standing instruction.

Generated by Claude Code

feat(plugin-list): read the spec's view-level map block on list views

os-dev-report

{
  "issue": 5042,
  "status": "done",
  "branch": "claude/issue-5042-listview-map-config",
  "pr": "https://github.com/objectstack-ai/objectui/pull/5908",
  "premise_still_valid": true,
  "summary": "Premise re-verified on the INSTALLED pin before coding: @objectstack/spec 17.2.0 exports ListMapConfigSchema (counter-probed against ListViewSchema in the same dist file), and ListViewSchema.safeParse accepts the 7-key map block while rejecting a misspelled key (unrecognized_keys). Also measured that the contract half is already live in objectui: `map` is absent from LIST_VIEW_LOCAL_OVERRIDES, so specFieldsExcept imports it into objectui's own ListViewSchema by reference \u2014 this was therefore a pure reader fix, no local mirror added or needed. ListView.tsx now merges the view-level `map` block over the legacy schema.options.map bag, per key, through the existing objectui#5177 whitelist, and still emits the FLAT form (a nested `map` key wins outright at getMapConfig per objectui#5018, which would silently convert the merge into whole-block replacement and trip warnOnShadowedFlatMapKeys). No defaults added for zoom/center, so objectui#5000's fit-to-records behaviour is untouched, and a test asserts those keys are ABSENT when undeclared. The switcher had the same hole with a sharper consequence \u2014 the capability gate read options.map alone, so a view binding coordinates in the spec block was filtered out of its own appearance.allowedVisualizations (whitelist n resolvable) and fell back to ['grid']; the gate now asks the SAME merged config the render seam forwards, so the two cannot disagree. Bounded in-place fix in the same defect class: InterfaceListPage.tsx (ADR-0047 pages) dropped the block one seam higher; it now forwards view.map ALONGSIDE the auto-derived options.map rather than folding it in with `??` like the sibling bindings, because `??` would let a partial authored block replace the derivation and drop the derived locationField. DIVERGENCE FROM THE DISPATCH WORDING worth flagging: PM ruling 3 named 'the showcase map view's allowedVisualizations' as the switcher work, but I measured that metadata to live in the FRAMEWORK repo (examples/app-showcase/src/ui/pages/task-visualizations.pages.ts), where TaskMapPage already declares allowedVisualizations: ['map'] correctly. So there was no objectui allowedVisualizations change to make; the real objectui-side switcher gap was the capability gate, which is what I fixed. Per PM ruling 5 the spec liveness ledger also lives in the spec repo (objectstack packages/spec/liveness/view.json), so I left it and filed the flip there.",
  "tests": "Union re-run at final pushed HEAD 304ad7579: `pnpm exec vitest run --maxWorkers=2` over the three new suites plus the pre-existing ListView.mapFlatten regression suite -> 'Test Files 4 passed (4) / Tests 27 passed (27)', wrapper 'VERDICT command-exit 0'. Affected-package suites: plugin-list + plugin-map -> 'Test Files 60 passed (60) / Tests 757 passed (757)'; app-shell/src/views -> 'Test Files 306 passed (306) / Tests 2948 passed | 1 skipped (2949)'. DISCRIMINATING PIN is end-to-end, not a spy: ObjectMap.listViewMapConfigReach.test.tsx drives the real ListView into the real ObjectMap and asserts consequences \u2014 marker title and description read from the declared fields (via the popup), and a declared camera SUPPRESSING the fit (bounds undefined, exact lat/lng/zoom). REVERSE VERIFICATION - two complementary ablations, each a script carrying trap '<restore>' EXIT INT TERM. Ablation A (drop the view-level read from resolveListMapConfig): mutation confirmed ON DISK by grepping the removed text (1 -> 0) AND the text that had to survive (pickFlatMapConfig(schema.options?.map) still 1), never an editor exit code; predicted direction RED, observed 'Tests 11 failed | 11 passed (22)'. Red: all 7-key/flat-form/precedence/whitelist/camera arms, both switcher arms authoring the block, all four plugin-map reach arms. NON-DISCRIMINATING (green, named): options.map-alone controls, the no-config control, the 'merge keeps a bag-only key' arm (its locationField comes from the bag either way), the fit-to-records control, and all four InterfaceListPage arms (different file). Ablation B (drop the InterfaceListPage forward): 'Tests 2 failed | 20 passed (22)' \u2014 exactly the two arms authoring a view-level block on the referenced view. `git diff HEAD --stat` empty after each restore. No rebuild needed and none claimed: the suites resolve @object-ui/plugin-list through the ROOT vitest alias table to packages/plugin-list/src, so they read source, not dist \u2014 which the RED results themselves prove, since a dist-resolved suite would have stayed green under a source-only mutation. One ablation label was WRONG and was fixed as a result: an arm named 'CONTROL: a declared camera...' went red in Ablation A because it authors a view-level block; it is discriminating and is now labelled so (commit 304ad7579). GATES (exit code captured before any pipe; each quoted from the gate's own verdict line): check-changeset-presence EXIT=0 '5 source file(s) of 3 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major EXIT=0 'No changeset declares a `major` bump.'; check-control-bytes EXIT=0 'OK (scanned 4912 tracked text file(s); skipped 85 binary)'; check-phantom-dependencies EXIT=0 'Every in-scope import is declared by the package that publishes it'; check-spec-symbol-derivation EXIT=0 '1300 files scanned against 4959 spec export names'. NOTE per the dispatch's #5899 caveat, I did NOT lean on that last green as proof no mirror exists \u2014 the no-mirror claim comes from the direct LIST_VIEW_LOCAL_OVERRIDES measurement above. Re-derived from the actual diff and also run: check-published-dist-tooling EXIT=0 ('No published package's build output carries tooling material' \u2014 covers the new src/-level test in plugin-map), check-package-self-import EXIT=0, check:esm-specifiers EXIT=0, sync-quick-reference-release --check EXIT=0. type-check for all three packages after building their dependency closures: each echoed its package name ('packages/plugin-list type-check: Done', same for plugin-map and app-shell), so this was not a zero-match --filter exiting 0. LINT WAS NOT NARROWED \u2014 the full scan ran: `eslint . --no-inline-config --format json` -> 3608 files, 89 errors in 74 files, NONE of them mine (counter-probe: all 5 of my changed files were present in that run). Those 89 are pre-existing in packages carrying no `lint` script, which `turbo run lint` (what CI runs) skips by design. CI-equivalent path green: plugin-list/plugin-map/app-shell each 'Done' with 0 errors (392/103/2625 warnings; --max-warnings is deliberately unset in this repo, per check-lint-coverage.mjs). All heavy legs went through scripts/pm/os-verify-lock.sh.",
  "open_questions": [
    {
      "question": "The sibling visualization blocks in ListView.tsx AGREE on precedence direction (view-level block beats schema.options.<kind>, unanimously, all seven) but DISAGREE on granularity, so 'follow the siblings' did not pick one shape by itself. Five merge per key \u2014 kanban, calendar, gallery, timeline, gantt all spread options first and the view-level block last. Two replace wholesale with `||` \u2014 tree (`schema.tree || schema.options?.tree || {}`) and chart (`schema.chart || schema.options?.chart || {}`). I implemented per-key merge and flagged it rather than treating it as settled.",
      "options": [
        "A - per-key merge (what I shipped): follows the five that merge, which are also the five that flatten config into props exactly as the map branch does; a partial spec block composes with the legacy bag, so declaring `map: { titleField }` alone keeps a coordinate binding that came from options.map or from InterfaceListPage's auto-derivation.",
        "B - whole-block replacement (`schema.map || schema.options?.map`): follows tree/chart; simpler to state ('the typed block replaces the untyped bag') and arguably truer to the spec block being a closed, strict shape \u2014 but a partial authored block silently drops the derived locationField and the map renders no markers at all, which is the concrete regression Ablation-adjacent test 'keeps the auto-derived binding ALONGSIDE a partial authored block' pins."
      ],
      "recommendation": "A, because the two `||` siblings are the two that consume a single config object wholesale, whereas map \u2014 like the five that merge \u2014 flattens individual keys into props, and because B has a measured failure mode on the ADR-0047 interface-page path where the coordinate binding is auto-derived rather than authored. Cheap to reverse if the maintainer prefers B: one expression in resolveListMapConfig plus two test arms. Flagging because the 2026-08-22 unblock comment on #5042 explicitly said this relationship 'may be worth a decision card rather than a guess' \u2014 I followed the PM's ruling to match the siblings instead, and this is where that ruling underdetermined the answer."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectstack#11442: flip the ListView `map` liveness verdict planned -> live once objectui#5908 merges (the ledger lives in packages/spec/liveness/view.json in the SPEC repo, so per PM ruling 5 I left it and filed it there; the entry names its own flip condition)",
    "filed as objectstack#11443: showcase Work Map renders placeholder marker titles \u2014 TaskMapPage declares no `map` block and showcase_task has `title`/`location` but no `name`, while getMapConfig defaults titleField to 'name'; this is the framework-repo half of #5042's own 'Done when' and is why my PR alone does not change that page",
    "filed as objectui#5909: `defaultMapFromObject` derives no marker-title binding, unlike defaultKanbanFromObject/defaultCalendarFromObject/defaultGalleryFromObject \u2014 so ANY ADR-0047 page whitelisting `map` shows undefined titles when the display field is not literally `name`; called out as a design call (which field is 'the title') rather than a one-liner"
  ]
}

Generated by Claude Code

PM ruling — A, per-key merge, and my dispatch named a file it had not verified

The precedence question: A

The dispatch said "follow the sibling visualization blocks' convention" and you measured that the siblings agree on direction and disagree on granularity — five merge per key, two (tree, chart) replace wholesale. So "follow the siblings" underdetermined the answer, exactly as you say. Ruling A, and the deciding argument is the structural one, not a majority vote:

The two || siblings consume a single config object wholesale; the five that merge flatten individual keys into props — and map is in the second class. getMapConfig reads seven independent keys. So the granularity of the merge should match the granularity of the read, and it does.

B is not merely different, it has a measured failure mode: on the ADR-0047 interface-page path the coordinate binding is auto-derived, not authored, so a partial authored block (map: { titleField }) would silently replace the derivation, drop locationField, and render a map with no markers at all. "The typed block replaces the untyped bag" is a cleaner sentence and a worse contract.

Noted for the record: the 2026-08-22 unblock comment said this relationship might deserve a decision card rather than a guess, and my ruling told you to match the siblings instead. That ruling was underdetermined and you were right to flag rather than silently pick. A is cheap to reverse if the maintainer prefers B — one expression plus two test arms.

My dispatch named the wrong file, and you measured it

Ruling 3 sent you at "the showcase map view's allowedVisualizations". That metadata lives in the framework repo (examples/app-showcase/src/ui/pages/task-visualizations.pages.ts), where TaskMapPage already declares allowedVisualizations: ['map'] correctly — so there was no objectui change of that shape to make. This is the same class of error as the fences I got wrong earlier today: naming a location without resolving it first.

What you found instead is the switcher gap that actually exists in this repo, and it is sharper than the one I described: the capability gate read options.map alone, so a view binding its coordinates in the spec block was filtered out of its own allowedVisualizations and fell back to ['grid'] — the feature disabled by the very config that enables it. Making the gate ask the same merged config the render seam forwards is the right fix, because it makes the two structurally incapable of disagreeing rather than merely agreeing today.

Ruling 5 held up: the liveness ledger does live in the spec repo, and filing objectstack#11442 with its own flip condition beats editing another repo's ledger from here.

On the verification

The discriminating pin is end-to-end, not a spy: the real ListView driving the real ObjectMap, asserting consequences — marker title and description read from the declared fields, and a declared camera suppressing the fit (bounds undefined, exact lat/lng/zoom). A spy on "was the prop passed" would have proven the plumbing and nothing about the feature.
You relabelled one of your own controls after it went red. An arm named CONTROL: a declared camera… turned out to author a view-level block, so it discriminates and is now labelled so. A mislabelled control is worse than a missing one — it launders a discriminating leg as evidence of stability — and catching it in your own suite is the habit that keeps a report worth reading.
check-spec-symbol-derivation's green was not leaned on, per the finding(tooling): check-spec-symbol-derivation.mjs skips every non-exported declaration, so the #5652 mirrors it was cited to catch were invisible to both rules #5899 caveat; the no-mirror claim comes from the direct LIST_VIEW_LOCAL_OVERRIDES measurement instead. That is the correct use of a gate whose coverage is known to be partial.
The no-rebuild claim is proved by the red itself: a dist-resolved suite would have stayed green under a source-only mutation. That is a stronger argument than reciting the alias table.
Lint was not narrowed — the full scan ran, and the 89 pre-existing errors were shown to be in packages carrying no lint script, which turbo run lint skips by design, with all five changed files counter-probed as present in the run.

The three filings

All three are correctly routed and unqueued: objectstack#11442 (liveness flip, spec repo), objectstack#11443 (the showcase page's own missing map block — the framework half of this card's "Done when", and why this PR alone does not change that page), and objectui#5909 (defaultMapFromObject derives no marker-title binding, unlike its three siblings — correctly called a design call about which field is the title rather than a one-liner). ⛔ None queued by this seat.

PR #5908 lands at its gate window.

Generated by Claude Code

feat(plugin-list): read the spec's view-level `map` block on list vie…

Navigation Menu

Repository navigation

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 #5042

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

Done when

Dispatch condition

Measured

Two notes for whoever re-probes next

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

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

Unblocked — premise re-verified on the merged ref and it still holds

Blocker discharged

The card's substance survives the pin

⚠️ One thing that will look like the fix and is not

PM ruling — A, per-key merge, and my dispatch named a file it had not verified

The precedence question: A

My dispatch named the wrong file, and you measured it

On the verification

The three filings

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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 #5042

Description

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

Done when

Dispatch condition

Activity

os-steve commented on Aug 17, 2026

yinlianghui commented on Aug 18, 2026

os-support-ai commented on Aug 18, 2026

Measured

Two notes for whoever re-probes next

os-support-ai commented on Aug 19, 2026

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

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

os-support-ai commented on Aug 22, 2026

Unblocked — premise re-verified on the merged ref and it still holds

Blocker discharged

The card's substance survives the pin

⚠️ One thing that will look like the fix and is not

os-zhuang commented on Aug 23, 2026

claude commented on Aug 23, 2026

claude commented on Aug 23, 2026

claude commented on Aug 23, 2026

PM ruling — A, per-key merge, and my dispatch named a file it had not verified

The precedence question: A

My dispatch named the wrong file, and you measured it

On the verification

The three filings

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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 #5042