fix(showcase): Work Map declares its marker bindings (title/location)

[os-steve]

Fixes#11443

The placeholder-title mechanism

TaskMapPage (showcase_task_map, "Work Map", in
examples/app-showcase/src/ui/pages/task-visualizations.pages.ts) whitelisted map in
appearance.allowedVisualizations but declared no field binding for it. With nothing
declared, objectui's defaultMapFromObject auto-derivation fills in only
{ locationField } — never a title field — and the map renderer's flat-form fallback
defaults titleField to 'name'. showcase_task (task.object.ts) has title, not
name, so every marker on the Work Map rendered a placeholder title.

Placement evidence — why sourceView, not a map: block on interfaceConfig

The card asked for map: { titleField: 'title', locationField: 'location' } declared
directly on the page's interfaceConfig. Measured against the schema before writing
anything: InterfacePageConfigSchema (packages/spec/src/ui/page.zod.ts) is a closed
(strictObject) shape whose declared keys are source, columns, sort, filterBy,
levels, sourceView, appearance, userFilters, userActions, addRecord, buttons,
recordAction, showRecordCount, allowPrinting — no map (or kanban/calendar/…)
key exists at any level. Confirmed empirically:

PageSchema.parse({ …, interfaceConfig: { …, map: { titleField: 'title', locationField: 'location' } } })
→ ZodError: unrecognized_keys ["map"] at ["interfaceConfig"]
"Unrecognized key(s) on this interface page configuration: `map`. Until #4001 closed
this shape these were dropped silently — the page still rendered, without whatever
the key was meant to configure."

No sibling page in examples/** declares a per-visualization block directly on
interfaceConfig either — none exists to follow as precedent, because the schema has no
such slot.

The one schema-legal channel is sourceView — and showcase_task already declares the
exact binding this card wants, on its own named map listView
(examples/app-showcase/src/ui/views/task.view.ts, landed with #9340):

map: {label: 'Work Locations (Map)',type: 'map',
data,columns: ['title','location','assignee'],map: {titleField: 'title',locationField: 'location'},},

So the fix is one line — sourceView: 'map' — pointing the page at that view instead of
re-declaring the binding somewhere the schema won't accept it. Verified this parses and
carries the reference:

TaskMapPage.interfaceConfig.sourceView === 'map' ✓

Pin-coverage note (per triage's rider)

objectui's InterfaceListPage resolves sourceView against the source object's named
views (resolveSourceView) and — since objectui#5908 (confirmed merged into
objectui's origin/main, commit e2e8e68) — forwards the resolved view's map block
verbatim so ListView merges it over the legacy options.map bag:

+ // The spec's view-level `map` block (`ListMapConfigSchema`), forwarded+ // verbatim so `ListView` can merge it over the `options.map` bag below.+ ...((view as any).map ? { map: (view as any).map } : {}),

Before that pin lands in this repo's own console (.objectui-sha), the forwarding code
objectui runs today does not yet read view.map this way, so the authored sourceView
reference is harmless-but-inert against the current pin — same as before this PR,
markers still fall back to the auto-derived { locationField } only. It becomes visible
once the console pin covers objectui#5908. This is an authoring-correctness fix, not a
runtime-behavior claim; the rendered effect is a pin-coverage matter, not a blocker on
this PR.

Scope

Example-app metadata only — no packages/spec/src/** change. The broader gap this card's
issue also names (defaultMapFromObject's auto-derivation never binding a title field for
any interface page that whitelists map without an explicit view) is objectui-side and
out of scope here; it already has its own card there (objectui#5042 lineage).

Tests

Added examples/app-showcase/test/task-map-marker-title.test.ts — three pins: the page
carries sourceView: 'map'; the referenced view still carries
map: { titleField: 'title', locationField: 'location' }; a map block declared
directly on interfaceConfig stays rejected (documents the schema boundary this fix
works around, so a future schema change either updates this pin deliberately or a
regression here is caught).

Check	Result
objectstack validate (@objectstack/example-showcase)	Validation passed — 24 objects, 28 pages, 6 views; only pre-existing unrelated warnings
@objectstack/example-showcasetypecheck (tsc --noEmit)	clean
@objectstack/example-showcasetest (vitest)	26 files / 370 tests passed (was 25/367 before this PR's new file)
pnpm check:cross-package-test-inputs	OK
pnpm check:examples-live-imports	OK — 0 invisible, 72 graph-visible
pnpm check:published-files	OK
pnpm check:test-source-alias	OK
pnpm check:type-source-resolution	OK
node scripts/check-cross-package-test-inputs.mjs	OK
pnpm check:nul-bytes	OK — 6464 files scanned, no raw control bytes
pnpm check:query-options-erasure	ratchet holds, no new sites
pnpm check:engine-double-contract	OK — 394 pinned, no new doubles
pnpm check:where-matcher	OK — 290/290 judged, none new
pnpm check:type-check-coverage (structural half)	OK — no new ledger entries
pnpm check:type-check-debt --re-measure	refuses locally — pre-existing, unrelated: needs the full packages/* closure built (@objectstack/service-knowledge has no built dist/ in this worktree); the structural half above is clean and this package's own typecheck already covers the new test file, so there is no plausible mechanism for this diff to move the ratchet. CI runs this with a full build.

Gate list derived via node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
against the final commit (7ac43a37d3); all matched + convention-triggered families for
this diff (new test file) are accounted for above.

Changeset

None — skip-changeset instead.@objectstack/example-showcase is private: true
and unpublished, so an examples-only change releases nothing — same call PR #7764 made on
the same package.

---

Generated by Claude Code