fix: 平台构建

platform_web/theme/README.md

@@ -39,11 +39,19 @@ This directory owns the platform_web visual system. Keep the console in a unifie
 - `data-theme-palette` on the document root is the source of truth for theme-specific CSS selectors. Do not infer the active theme from route state, component-local state, or background preset IDs.
 - Theme changes must be visually atomic: root marker, CSS variables, menu/sidebar chrome, active navigation frame, and shared surface accessories should all reflect the same selected palette immediately.
 
+## Typography Rules
+
+- Theme-level font differences must come from palette variables: `--font-ui`, `--font-display`, `--font-mono`, `--title-weight`, `--title-tracking`, `--heading-weight`, and `--heading-tracking`.
+- Page and component CSS should not hardcode independent font stacks for headings, code, logs, diffs, or textareas. Use the shared font variables so black mecha and magical-girl can diverge without page-local overrides.
+- Display headings should use `--font-display`; normal UI copy should inherit `--font-ui`; code-like surfaces such as logs and diffs should use `--font-mono`.
+
 ## Surface Rules
 
-- Use shared classes such as `metric-card`, `overview-card`, `console-panel`, `catalog-card`, `server-card`, `server-detail-header`, `resource-table-wrap`, `provider-table-wrap`, `drawer-panel`, `confirm-panel`, `plugin-group`, and `operation-item` instead of creating page-local card styles.
+- Use shared outer surface classes such as `metric-card`, `overview-card`, `console-panel`, `catalog-card`, `server-card`, `server-detail-header`, `resource-table-wrap`, `provider-table-wrap`, `drawer-panel`, `confirm-panel`, and `plugin-group` instead of creating page-local card styles.
+- Repeated console content must reuse the internal shared classes: `console-module` for panel modules, `console-stat-strip` for compact metric strips, `console-row-list` and `console-row` for compact status rows, `console-record-list` and `console-record` for operation/history records, `console-row-actions` for action rows, and `access-list` / `access-list-row` for access-management rows.
+- Legacy page-specific classes such as `operations-module`, `operations-pulse-strip`, `operations-endpoint-row`, `operation-list`, `operation-item`, `maintenance-actions`, `user-actions`, and `user-management-item` are compatibility aliases only. New UI should not make these classes the style owner; pair or replace them with the shared `console-*` / `access-*` classes.
 - Shared framed surfaces should use `var(--panel-material)`, `var(--panel-shadow)`, `var(--frame-corner)`, and `var(--frame-accent)` so each theme can change structure, fill, and glow style beyond simple color swaps.
-- A visual region should have only one ornamental frame at a hierarchy level. If a `.state-view` is nested inside a shared framed parent such as `.console-panel`, `.catalog-card`, `.server-card`, `.resource-table-wrap`, `.provider-table-wrap`, `.server-table-wrap`, `.plugin-group`, or `.operation-item`, the parent owns the frame and the nested state view must render as transparent, borderless content with no `::before` or `::after` accessory.
+- A visual region should have only one ornamental frame at a hierarchy level. If a `.state-view` is nested inside a shared framed parent such as `.console-panel`, `.catalog-card`, `.server-card`, `.resource-table-wrap`, `.provider-table-wrap`, `.server-table-wrap`, `.plugin-group`, `.console-record`, or compatibility `.operation-item`, the parent owns the frame and the nested state view must render as transparent, borderless content with no `::before` or `::after` accessory.
 - Standalone `.state-view` instances may keep their own readable state treatment when they are not inside an already framed surface.
 - Menu frames should use `var(--menu-item-bg)`, `var(--menu-item-active-bg)`, `var(--menu-glyph-bg)`, `var(--menu-title-shadow)`, and `var(--menu-active-outline)` so each theme changes active-state treatment, icon material, and rail/sidebar structure.
 - Action dropdowns and contextual menus are small operational overlays, not decorative panels. They must stay anchored to the trigger, fit within the viewport, use compact rows, and avoid moving or resizing the parent card, row, grid, or table.
@@ -58,7 +66,8 @@ This directory owns the platform_web visual system. Keep the console in a unifie
 ## Adding UI
 
 1. Reuse existing shared surface, command, table, form, status, and state-view classes first.
-2. If a new shared pattern is truly needed, add it in `base.css` and describe its intended use here.
-3. When placing empty/loading/error states inside an existing shared panel, verify the state view does not introduce a second framed panel or accessory layer.
-4. If a new palette or background preset is added, update `tokens.ts`, `tokens.test.ts`, and any CSS contract tests together.
-5. Run the relevant focused checks before claiming completion. Use `npm run typecheck`, `npm test`, `npm run build`, and `scripts/check-structure.sh` when the scope warrants them; run `openspec validate <change> --strict` only when an OpenSpec change was created.
+2. For new panel-internal records, rows, stat strips, and action rows, start from `console-record`, `console-row`, `console-stat-strip`, and `console-row-actions` before adding a narrowly scoped modifier class.
+3. If a new shared pattern is truly needed, add it in `base.css` and describe its intended use here.
+4. When placing empty/loading/error states inside an existing shared panel, verify the state view does not introduce a second framed panel or accessory layer.
+5. If a new palette or background preset is added, update `tokens.ts`, `tokens.test.ts`, and any CSS contract tests together.
+6. Run the relevant focused checks before claiming completion. Use `npm run typecheck`, `npm test`, `npm run build`, and `scripts/check-structure.sh` when the scope warrants them; run `openspec validate <change> --strict` only when an OpenSpec change was created.