fix(plugin-view,plugin-list): hand-list FLAT_MAP_CONFIG_KEYS to stop breaking the console-starter alias-closure gate

PR #5231's CI (job `Test (shard 3/4)`, run 32160288416) went red on
`examples/console-starter/test/vite-alias-closure.test.ts`:

    "@object-ui/types/zod (unresolvable under src, imported by packages/plugin-list/src/ListView.tsx)"
    "@object-ui/types/zod (unresolvable under src, imported by packages/plugin-view/src/ObjectView.tsx)"

Root cause: that test's walker resolves a bare `@object-ui/*` specifier using
plain `index.<ext>` conventions and cannot find `@object-ui/types/zod`'s real
barrel file (`zod/index.zod.ts` — a non-standard name), regardless of whether
Vite's own alias table covers it (it already does — an explicit
`@object-ui/types/zod` entry has been in
`examples/console-starter/vite.config.ts` since PR #5156). `ObjectView.tsx`
and `ListView.tsx` are both reachable from console-starter's own `src/`, so
the runtime import made them part of the walked graph for the first time;
`ObjectMap.tsx` carries the identical import today without tripping the gate
only because nothing in that graph reaches `@object-ui/plugin-map`.

Per instruction, `vite-alias-closure.test.ts` itself is untouched.

Fix: `FLAT_MAP_CONFIG_KEYS` in `ObjectView.tsx` and `ListView.tsx` is now
HAND-LISTED (no runtime `@object-ui/types/zod` import in either file) rather
than derived from `ObjectMapConfigSchema.shape`. `ObjectMap.tsx` in
`plugin-map` keeps the runtime-derived version — it is safely unreached by
the walker, and it already imports the schema for `safeParse` regardless.

Anti-drift for the two hand lists is a TEST, not just a comment, matching the
established `packages/core/src/actions/__tests__/actionKeys.pin.test.ts`
pattern: each of `ObjectView.mapFlatten.test.tsx` /
`ListView.mapFlatten.test.tsx` now imports `ObjectMapConfigSchema` from
`@object-ui/types/zod` (a TEST file, which the alias-closure walker
explicitly excludes from traversal) and asserts the exported
`FLAT_MAP_CONFIG_KEYS` equals the schema's keys minus `style`. A key added to
or removed from the declaration still fails loudly, by name, without
reintroducing the runtime edge that breaks the console-starter gate.

Both `FLAT_MAP_CONFIG_KEYS` constants are now independently hand-listed
(each pin-tested against the same canonical schema) rather than one literal
array physically shared by both call sites — the walker constraint above
rules out every within-scope way to share one runtime value without either
re-tripping this gate or statically pulling `@object-ui/plugin-map`'s
`maplibre-gl` / `react-map-gl` weight into `ObjectView` / `ListView` (that
package's single lib entry bundles everything together, and console-starter
aliases it whole to `src`). Noted explicitly in the PR body as a deviation
from strict single-sourcing, with the reasoning above.

Reverified locally: `pnpm exec vitest run examples/console-starter/test/vite-alias-closure.test.ts`
green, plus the three package suites, at the new HEAD, rebased onto current
origin/main.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE

Author: claude

packages/plugin-list/src/ListView.tsx

@@ -18,9 +18,8 @@ import { UserFilters } from './UserFilters';
 import { SchemaRenderer, useNavigationOverlay, classifyLoadError } from '@object-ui/react';
 import type { LoadErrorKind } from '@object-ui/react';
 import { useDensityMode } from '@object-ui/react';
-import type { ListViewSchema } from '@object-ui/types';
+import type { ListViewSchema, ObjectMapConfig } from '@object-ui/types';
 import { detectStatusField } from '@object-ui/types';
-import { ObjectMapConfigSchema } from '@object-ui/types/zod';
 import { usePullToRefresh } from '@object-ui/mobile';
 import { resolveConditionalFormatting, buildExpandFields, buildExportFileName, resolveEffectiveCrudAffordances, isObjectInlineEditable, normalizeListViewSchema, rowHeightToDensityMode, mergeFilterNodes, columnIdentity, collectPredicateFieldRefs, listViewPredicates, PLATFORM_RECORD_COLUMNS, EXPANDABLE_FIELD_TYPES, UNMATERIALIZED_FIELD_TYPES } from '@object-ui/core';
 import { useObjectTranslation, useObjectLabel, useSafeFieldLabel, createSafeTranslation } from '@object-ui/i18n';
@@ -34,17 +33,37 @@ import { usePermissions } from '@object-ui/permissions';
  * spreading the raw `map` block collapsed the two namespaces onto one key
  * (objectui#5177).
  *
- * DERIVED, not hand-listed: `ObjectMapConfigSchema` (`@object-ui/types/zod`) is
- * the same declaration `plugin-map`'s `ObjectMap.tsx` validates the `map` block
- * against and derives its own `FLAT_MAP_CONFIG_KEYS` from, so a key added there
- * reaches this flattener without a second edit. Read from `@object-ui/types`
- * rather than imported from `@object-ui/plugin-map` deliberately: `plugin-map`
- * is loaded lazily (`ComponentRegistry.registerLazy('object-map', ...)`)
- * specifically so its `maplibre-gl` / `react-map-gl` weight is paid only when a
- * map view actually renders — a static import here would defeat that for every
- * `ListView`, map or not.
+ * HAND-LISTED, not derived at runtime — deliberately, and only here (`plugin-
+ * map`'s own `FLAT_MAP_CONFIG_KEYS` in `ObjectMap.tsx` DOES derive from
+ * `ObjectMapConfigSchema.shape`, and should stay that way): this file is
+ * reachable from `examples/console-starter`'s own `src/`, so it is part of the
+ * import graph `vite-alias-closure.test.ts` walks. That walker resolves a bare
+ * `@object-ui/*` specifier with plain `index.<ext>` conventions and cannot find
+ * `@object-ui/types/zod`'s actual barrel file (`zod/index.zod.ts` — a
+ * non-standard name) — a REAL runtime import of it here reproducibly fails
+ * that gate (measured on objectui#5177's first PR, PR #5231, CI run
+ * 32160288416), even though Vite's own alias table already resolves the
+ * specifier correctly (`examples/console-starter/vite.config.ts` has carried
+ * an explicit `@object-ui/types/zod` entry since PR #5156). `ObjectMap.tsx`
+ * gets away with the runtime import only because nothing in
+ * console-starter's graph reaches `@object-ui/plugin-map` today.
+ *
+ * Anti-drift is a TEST, not this comment: `ListView.mapFlatten.test.tsx` pins
+ * this exact list against `ObjectMapConfigSchema.shape` — imported only from
+ * that TEST file, which the alias-closure walker explicitly excludes from
+ * traversal — so a key added to or removed from the declaration still fails
+ * here, loudly and by name, without reintroducing the runtime edge that
+ * breaks the walker.
  */
-const FLAT_MAP_CONFIG_KEYS = Object.keys(ObjectMapConfigSchema.shape).filter((key) => key !== 'style');
+export const FLAT_MAP_CONFIG_KEYS = [
+  'latitudeField',
+  'longitudeField',
+  'locationField',
+  'titleField',
+  'descriptionField',
+  'zoom',
+  'center',
+] as const satisfies readonly (keyof Omit<ObjectMapConfig, 'style'>)[];
 
 /** Pick only the declared flat map keys present on an authored `map` block. */
 function pickFlatMapConfig(mapConfig: unknown): Record<string, unknown> {

packages/plugin-list/src/__tests__/ListView.mapFlatten.test.tsx

@@ -16,21 +16,28 @@
  * legal on every node), so a `map: { style: '<url>' }` authoring intent
  * arrived at the top level as that CSS-shaped key.
  *
- * These pin the whitelist (`FLAT_MAP_CONFIG_KEYS`, derived from
- * `ObjectMapConfigSchema` in `@object-ui/types/zod` — the same declaration
- * `ObjectMap.tsx`'s own `FLAT_MAP_CONFIG_KEYS` derives from) rather than the
- * raw spread: a declared key still travels, `style` does not, and neither
- * does an arbitrary undeclared one. Mirrors
- * `ObjectView.mapFlatten.test.tsx`'s #5177 coverage for the sibling
+ * These pin the whitelist (`FLAT_MAP_CONFIG_KEYS`, hand-listed in
+ * `ListView.tsx` itself — see the comment on that constant for why it is not
+ * derived from `ObjectMapConfigSchema` at runtime there) rather than the raw
+ * spread: a declared key still travels, `style` does not, and neither does an
+ * arbitrary undeclared one. The bottom of this file also pins the hand list
+ * against `ObjectMapConfigSchema` directly, so it cannot silently drift.
+ * Mirrors `ObjectView.mapFlatten.test.tsx`'s #5177 coverage for the sibling
  * flattener.
  */
 
 import React from 'react';
 import { describe, it, expect, vi, beforeEach } from 'vitest';
 import { ComponentRegistry } from '@object-ui/core';
 import { render, waitFor } from '@testing-library/react';
-import { ListView } from '../ListView';
+import { ListView, FLAT_MAP_CONFIG_KEYS } from '../ListView';
 import { SchemaRendererProvider } from '@object-ui/react';
+// Test-only: `ListView.tsx` hand-lists `FLAT_MAP_CONFIG_KEYS` rather than
+// importing this schema at runtime, precisely so this module never appears in
+// `examples/console-starter`'s walked import graph (see the comment on the
+// constant). A test file is explicitly excluded from that walk, so pinning
+// against the real declaration HERE is safe.
+import { ObjectMapConfigSchema } from '@object-ui/types/zod';
 
 let captured: Array<Record<string, any>> = [];
 
@@ -114,3 +121,22 @@ describe('ListView flattens `options.map` through a whitelist, not a raw spread
     expect(schema.locationField).toBe('location');
   });
 });
+
+/**
+ * `FLAT_MAP_CONFIG_KEYS` is hand-listed in `ListView.tsx` itself (not derived
+ * at runtime — see the comment on the constant for why), so THIS is the
+ * mechanism that keeps it from silently drifting off `ObjectMapConfigSchema`
+ * — the same role `packages/core/src/actions/__tests__/actionKeys.pin.test.ts`
+ * plays for `SPEC_ACTION_KEYS`. A key added to or removed from the schema
+ * fails this test by name, without requiring a runtime import of
+ * `@object-ui/types/zod` from production code that reaches
+ * `examples/console-starter`.
+ */
+describe('FLAT_MAP_CONFIG_KEYS pins against ObjectMapConfigSchema (objectui#5177)', () => {
+  it('matches the schema minus `style`, so the hand list cannot silently drift', () => {
+    const declared = Object.keys(ObjectMapConfigSchema.shape)
+      .filter((key) => key !== 'style')
+      .sort();
+    expect([...FLAT_MAP_CONFIG_KEYS].sort()).toEqual(declared);
+  });
+});

packages/plugin-view/src/ObjectView.tsx

@@ -32,6 +32,7 @@ import type {
   ViewType,
   NamedListView,
   ViewNavigationConfig,
+  ObjectMapConfig,
 } from '@object-ui/types';
 import { ObjectGrid } from '@object-ui/plugin-grid';
 import { ObjectForm } from '@object-ui/plugin-form';
@@ -58,7 +59,6 @@ import { Plus } from 'lucide-react';
 import { useObjectTranslation, createSafeTranslation } from '@object-ui/i18n';
 import { buildExpandFields, normalizeListViewSchema, mergeFilterNodes } from '@object-ui/core';
 import { SchemaRenderer as ImportedSchemaRenderer } from '@object-ui/react';
-import { ObjectMapConfigSchema } from '@object-ui/types/zod';
 import { ViewSwitcher } from './ViewSwitcher';
 import { deriveRecordSurface } from './recordSurface';
 
@@ -75,17 +75,37 @@ const SchemaRendererComponent: React.FC<any> = ImportedSchemaRenderer;
  * spreading the raw `map` block collapsed the two namespaces onto one key
  * (objectui#5177).
  *
- * DERIVED, not hand-listed: `ObjectMapConfigSchema` (`@object-ui/types/zod`) is
- * the same declaration `plugin-map`'s `ObjectMap.tsx` validates the `map` block
- * against and derives its own `FLAT_MAP_CONFIG_KEYS` from, so a key added there
- * reaches this flattener without a second edit. Read from `@object-ui/types`
- * rather than imported from `@object-ui/plugin-map` deliberately: `plugin-map`
- * is loaded lazily (`ComponentRegistry.registerLazy('object-map', ...)`)
- * specifically so its `maplibre-gl` / `react-map-gl` weight is paid only when a
- * map view actually renders — a static import here would defeat that for every
- * `ObjectView`, map or not.
+ * HAND-LISTED, not derived at runtime — deliberately, and only here (`plugin-
+ * map`'s own `FLAT_MAP_CONFIG_KEYS` in `ObjectMap.tsx` DOES derive from
+ * `ObjectMapConfigSchema.shape`, and should stay that way): this file is
+ * reachable from `examples/console-starter`'s own `src/`, so it is part of the
+ * import graph `vite-alias-closure.test.ts` walks. That walker resolves a bare
+ * `@object-ui/*` specifier with plain `index.<ext>` conventions and cannot find
+ * `@object-ui/types/zod`'s actual barrel file (`zod/index.zod.ts` — a
+ * non-standard name) — a REAL runtime import of it here reproducibly fails
+ * that gate (measured on objectui#5177's first PR, PR #5231, CI run
+ * 32160288416), even though Vite's own alias table already resolves the
+ * specifier correctly (`examples/console-starter/vite.config.ts` has carried
+ * an explicit `@object-ui/types/zod` entry since PR #5156). `ObjectMap.tsx`
+ * gets away with the runtime import only because nothing in
+ * console-starter's graph reaches `@object-ui/plugin-map` today.
+ *
+ * Anti-drift is a TEST, not this comment: `ObjectView.mapFlatten.test.tsx`
+ * pins this exact list against `ObjectMapConfigSchema.shape` — imported only
+ * from that TEST file, which the alias-closure walker explicitly excludes
+ * from traversal — so a key added to or removed from the declaration still
+ * fails here, loudly and by name, without reintroducing the runtime edge that
+ * breaks the walker.
  */
-const FLAT_MAP_CONFIG_KEYS = Object.keys(ObjectMapConfigSchema.shape).filter((key) => key !== 'style');
+export const FLAT_MAP_CONFIG_KEYS = [
+  'latitudeField',
+  'longitudeField',
+  'locationField',
+  'titleField',
+  'descriptionField',
+  'zoom',
+  'center',
+] as const satisfies readonly (keyof Omit<ObjectMapConfig, 'style'>)[];
 
 /** Pick only the declared flat map keys present on an authored `map` block. */
 function pickFlatMapConfig(mapConfig: unknown): Record<string, unknown> {

packages/plugin-view/src/__tests__/ObjectView.mapFlatten.test.tsx

@@ -30,8 +30,14 @@
 
 import { describe, it, expect, vi } from 'vitest';
 import { render, waitFor } from '@testing-library/react';
-import { ObjectView } from '../ObjectView';
+import { ObjectView, FLAT_MAP_CONFIG_KEYS } from '../ObjectView';
 import type { ObjectViewSchema } from '@object-ui/types';
+// Test-only: `ObjectView.tsx` hand-lists `FLAT_MAP_CONFIG_KEYS` rather than
+// importing this schema at runtime, precisely so this module never appears in
+// `examples/console-starter`'s walked import graph (see the comment on the
+// constant). A test file is explicitly excluded from that walk, so pinning
+// against the real declaration HERE is safe.
+import { ObjectMapConfigSchema } from '@object-ui/types/zod';
 
 /** Every schema the view hands to SchemaRenderer, in order. */
 const rendered: any[] = [];
@@ -148,3 +154,22 @@ describe('ObjectView flattens `map` through a whitelist, not a raw spread (objec
     expect(Object.prototype.hasOwnProperty.call(schema, 'totallyUndeclaredKey')).toBe(false);
   });
 });
+
+/**
+ * `FLAT_MAP_CONFIG_KEYS` is hand-listed in `ObjectView.tsx` itself (not
+ * derived at runtime — see the comment on the constant for why), so THIS is
+ * the mechanism that keeps it from silently drifting off `ObjectMapConfigSchema`
+ * — the same role `packages/core/src/actions/__tests__/actionKeys.pin.test.ts`
+ * plays for `SPEC_ACTION_KEYS`. A key added to or removed from the schema
+ * fails this test by name, without requiring a runtime import of
+ * `@object-ui/types/zod` from production code that reaches
+ * `examples/console-starter`.
+ */
+describe('FLAT_MAP_CONFIG_KEYS pins against ObjectMapConfigSchema (objectui#5177)', () => {
+  it('matches the schema minus `style`, so the hand list cannot silently drift', () => {
+    const declared = Object.keys(ObjectMapConfigSchema.shape)
+      .filter((key) => key !== 'style')
+      .sort();
+    expect([...FLAT_MAP_CONFIG_KEYS].sort()).toEqual(declared);
+  });
+});