docs(ROADMAP): P1.12.3 / P1.16 九条同源漂移按现实改写 (#3738)

ROADMAP.md

@@ -858,12 +858,12 @@ ObjectUI is a universal Server-Driven UI (SDUI) engine built on React + Tailwind
 - [x] `/system/metadata/:metadataType` — the URL still resolves, but as a legacy alias: its route element is `MetadataRedirect` (`apps/console/src/AppContent.tsx`), which forwards in one hop to the metadata-admin engine's own `metadata/:type`. The `MetadataManagerPage` named here has zero files and zero references under `apps/console/src/`; the generic, registry-driven list that route lands on is `MetadataResourceListPage` (`packages/app-shell/src/views/metadata-admin/ResourceListPage.tsx`), mounted by `packages/app-shell/src/console/AppContent.tsx` (#3639)
 
 **Unified Metadata Management (P1.12.3):**
-- [x] Metadata type registry (`config/metadataTypeRegistry.ts`) — centralized config for all metadata types
+- [x] Metadata type registry (`config/metadataTypeRegistry.ts`) — centralized config for all metadata types. That file did ship, at `apps/console/src/config/metadataTypeRegistry.ts`, and was deleted in commit ff9a0d9e9 ("remove studio app and migrate to metadata-admin engine"); `metadataTypeRegistry` has zero hits anywhere in the tree today. The live registry is the metadata-admin engine's own `MetadataResourceRegistry` (`packages/app-shell/src/views/metadata-admin/registry.ts`): its per-type row is `MetadataResourceConfig`, filled in by `registerMetadataResource()`. It is not centralized config in the old sense either — a type needs no entry at all to be listed and edited, an entry only overrides the defaults
 - [x] Generic `MetadataManagerPage` for listing/managing items of any registered type — shipped, then deleted when `apps/console` was slimmed for third-party customisation. The generic list is now `MetadataResourceListPage` (`packages/app-shell/src/views/metadata-admin/ResourceListPage.tsx`), driven by the engine's own `MetadataResourceRegistry` (`registry.ts` in that directory) rather than by a console-side config, and it covers every registered metadata type from one shell
-- [x] SystemHubPage auto-generates metadata type cards from registry (dashboard, page, report)
-- [x] Dynamic `/system/metadata/:metadataType` routes in all route contexts
+- [x] SystemHubPage auto-generates metadata type cards from registry (dashboard, page, report) — nothing is generated and none of those three types has a card: `metadataTypeCards` in `apps/console/src/pages/system/SystemHubPage.tsx` is a hand-written literal (Applications, Metadata, Datasources), and the comment directly above it records why the per-type cards went away — the engine started auto-listing every type, so a card per type stopped paying for itself. What enumerates types from the registry today is the engine's own type directory, `MetadataDirectoryPage`, which the hand-written "Metadata" card links to
+- [x] Dynamic `/system/metadata/:metadataType` routes in all route contexts — this spelling is declared only in the console host fragment (`apps/console/src/AppContent.tsx`, in three arities: bare, `/:metadataType`, `/:metadataType/:itemName`) and is not a page in any of them: the route element is `MetadataRedirect`, a `<Navigate>` onto the engine's route. The dynamic route that renders is the engine's `metadata/:type` in `packages/app-shell/src/console/AppContent.tsx` — and that one *is* declared in both route contexts, the with-app branch and the zero-app branch, which is the half of this claim that survives (#3639)
 - [x] Generic `MetadataService` methods: `getItems()`, `saveMetadataItem()`, `deleteMetadataItem()`
-- [x] Types with custom pages (`app`, `object`) link to existing dedicated routes
+- [x] Types with custom pages (`app`, `object`) link to existing dedicated routes — still true of `app` (`system/apps` renders `AppManagementPage`, `apps/console/src/AppContent.tsx`), no longer true of `object`: it has no dedicated page or route of its own. The engine's generic shell lists and edits it, configured by `registerMetadataResource({ type: 'object', … })` in `packages/app-shell/src/services/builtinComponents.tsx` and in `views/metadata-admin/anchors.ts` — list columns, searchable fields, create-form fields and anchor groups, and no component override. The only shell pages any type replaces are `permission`'s `EditPage` and `datasource`'s `ListPage`
 - [x] Legacy routes preserved — no breaking changes
 - [x] New tests for the registry-driven metadata surface — no total is carried here, because none of the four suites named survives in that form: the `MetadataManagerPage` and `config/metadataTypeRegistry.ts` suites went with the code they covered, `MetadataService` has no test file in the tree at all, and `SystemHubPage`'s remaining suites test its two hand-written cards, not registry-generated ones. What covers this surface today is the metadata-admin engine's own tests under `packages/app-shell/src/views/metadata-admin/`, plus the console's hub-card and legacy-redirect suites under `apps/console/src/`
 
@@ -984,10 +984,10 @@ Enterprise-grade visual designers for managing object definitions and configurin
 - [x] Enhanced object properties card with separated concern sections
 
 **Metadata Manager Grid Mode:**
-- [x] `listMode: 'grid' | 'table' | 'card'` configuration on MetadataTypeConfig
-- [x] Professional table rendering with column headers and action buttons in grid mode
-- [x] Report type configured with grid mode by default
-- [x] Reusable `MetadataGrid` component extracted for cross-page reuse
+- [x] `listMode: 'grid' | 'table' | 'card'` configuration on MetadataTypeConfig — neither the option nor the interface exists: `listMode` and `MetadataTypeConfig` both have zero hits in the tree. The engine's per-type row is `MetadataResourceConfig` (`packages/app-shell/src/views/metadata-admin/registry.ts`) and it carries no rendering-mode key at all; what it exposes for list shape is `listColumns`, plus `ListPage` to replace the shell page outright
+- [x] Professional table rendering with column headers and action buttons in grid mode — the table rendering is real, but it is not a mode you select: `MetadataResourceListPage` (`packages/app-shell/src/views/metadata-admin/ResourceListPage.tsx`) renders a single `<table>` whose `<thead>` is built from `listColumns` (falling back to an inferred primary + label pair) for every type unconditionally. There is no branch to switch on, so there is no "grid mode" to be in
+- [x] Report type configured with grid mode by default — `report` does have a registry entry, `registerMetadataResource({ type: 'report', … })` in `packages/app-shell/src/views/metadata-admin/anchors.ts`, but nothing in it selects a rendering mode, because there is none to select. What it configures is the object anchor group and the create-form seeds (`createFields`, `createDerive`, `createDefaults`); its list is the same unconditional table every other type gets
+- [x] Reusable `MetadataGrid` component extracted for cross-page reuse — `MetadataGrid` has zero hits in the tree; it went with the console-side manager page it was extracted from. Cross-type reuse is no longer achieved by importing a grid component per page: every type's list is the one shell page reached through the engine's `metadata/:type` route
 
 **MetadataFormDialog Enhancements:**
 - [x] `number` field type — renders HTML number input
@@ -998,7 +998,7 @@ Enterprise-grade visual designers for managing object definitions and configurin
 - [x] `getItemsByType(type)` method on MetadataProvider for dynamic registry access
 - [x] Object type merged into the generic metadata pipeline — `ObjectManagerPage` removed (only stale docblock mentions of it remain, in the two `utils/metadataConverters.ts`). Neither vehicle named here survived the move onto the metadata-admin engine: `ObjectManagerListAdapter` has zero hits, and `object` needs no custom list at all — it is listed by the engine's generic shell, configured by `registerMetadataResource({ type: 'object', … })` in `packages/app-shell/src/services/builtinComponents.tsx`
 - [x] Per-type override slot for injecting a custom list UI — `listComponent` on `MetadataTypeConfig` went with that console-side registry (both names have zero hits today). The engine's equivalent is `ListPage` on `MetadataResourceConfig` (`packages/app-shell/src/views/metadata-admin/registry.ts`), which bypasses the generic shell for one type; `datasource` is the only type overriding it
-- [x] All entry points (sidebar, QuickActions, hub cards) unified to `/system/metadata/object`
+- [x] All entry points (sidebar, QuickActions, hub cards) unified to `/system/metadata/object` — judged per entry, none of the three aims there today, and they left for different reasons. The hub cards carry no object card at all: `SystemHubPage`'s hand-written cards aim at the engine's type directory and at `metadata/datasource`. The sidebars' `sys-objects` item (in both `AppSidebar` and `UnifiedSidebar`) and the home page's `manage-objects` quick action were re-pointed at the engine's canonical `/apps/setup/metadata/object` (#3739), because the `system/…` spelling is not a page: `MetadataRedirect` serves it with a `<Navigate>` onto exactly that URL, so aiming at it charged every click a redundant hop plus a re-render. What is unified is the destination, not this spelling of it — the alias routes stay declared for bookmarks and external links
 
 **Technical Debt Cleanup:**
 - [x] Unified icon resolver — consolidated 3 duplicated ICON_MAP/resolveIcon into shared `getIcon` utility