Files
browser/openspec/changes/redesign-platform-web-interactions/tasks.md
T
2026-07-11 14:56:10 +08:00

12 KiB

1. Existing Surface Audit

  • 1.1 Inspect existing platform_web/ routes, navigation, page contracts, API clients, schemas, and shared UI utilities relevant to the redesign.
  • 1.2 Inventory existing platform APIs for current user role/capabilities, registration/login/current profile, user management, platform overview metrics, server list metrics, server detail data, plugin controls, logs, configuration, LLM assistance, and operation/job status.
  • 1.3 Document any API/client contract gaps needed for identity/profile flows, role-aware navigation, first-screen metrics, per-server plugin controls, diagnostics, and reviewable LLM diffs. (Recorded in platform_web/api/contracts.md § Redesign Contract Gaps.)

2. Shared Interaction Foundation

  • 2.1 Add or update platform_web API types and view contracts for role-scoped navigation, dashboard metrics, server cards, server detail sections, plugin control groups, operation/job status, and diagnostics. (api/types.ts, api/client.ts, contracts/workspace.ts, contracts/page.ts.)
  • 2.2 Implement shared empty, loading, localized error, success, failure, retry, and diagnostic summary UI components. (components/StateViews.tsx.)
  • 2.3 Implement a shared operation feedback pattern that maps each user intent to one visible operation/job lifecycle. (stores/operations.ts + ResultBadge; one intent = one OperationRecord with job ID/state.)
  • 2.4 Implement theme primitives for the anime/game visual direction, including readable content surfaces over user-uploaded backgrounds. (theme/tokens.ts background upload/persist + theme/base.css contrast overlay and surface tokens.)
  • 2.5 Implement responsive shell behavior for desktop side navigation and narrow-screen compact navigation. (components/AppShell.tsx + base.css narrow-screen rules.)

2A. Identity, Profile, and Theme Preferences

  • 2A.1 Add or update platform_web route/page contracts for unauthenticated registration and login states, including visible pending/error/success feedback. (Implemented in components/AuthView.tsx, app/App.tsx, and auth form styles in theme/base.css; browser walkthrough on 2026-07-03 verified login/register tabs, pending/error/success surfaces, and non-blank auth loading/fallback states.)
  • 2A.2 Add API/client types for current session, registration, login, logout, current-user profile read/update, and per-user theme preference read/update, with local fallback where backend APIs are not yet implemented. (Implemented in api/types.ts, api/client.ts, contracts/workspace.ts, and stores/session.ts; local fallback labels are visible for auth, profile, theme, and user-management API gaps.)
  • 2A.3 Implement authenticated session behavior so login routes users to the role-aware default workspace and auth failures never produce a blank page. (stores/session.ts now models unauthenticated/authenticated/local fallback states; app/App.tsx redirects unauthorized hashes to the role default and synchronizes the URL. Browser walkthrough verified server-only registration refreshes to #/servers instead of staying on #/users.)
  • 2A.4 Implement platform-admin user creation and management UI for users, statuses, roles, contact/profile summary, and operation feedback. (Implemented in pages/UsersPage.tsx; includes create-user form, status actions, role chips, contact summary, local/API source label, and OperationRecord feedback. Browser walkthrough verified create/list/actions render under 用户管理.)
  • 2A.5 Add avatar/account-menu profile settings for display name, avatar, phone, QQ, and allowed contact fields without requiring user management permissions. (Implemented in components/AppShell.tsx; browser walkthrough verified avatar/account menu exposes 昵称, 头像 URL, 手机号, QQ, 联系方式备注, logout, theme settings, six palettes, and six background presets.)
  • 2A.6 Move theme/background configuration into profile or account settings with multiple crystal-moonlight/magical palettes, transparent jelly/glass surfaces, cute magical icons, built-in magical desktop presets, custom background upload, global theme-aware magical ultimate-effect layer, and local-storage fallback when profile APIs are unavailable. (Implemented in components/AppShell.tsx, components/MagicalParticleLayer.tsx, shared page/actions, theme/tokens.ts, and theme/base.css; each palette now has its own low-cost “大招” canvas scene such as moon sigil, heart ribbon burst, idol halo, mint spiral, lemon starburst, or aqua crystal ring, with no high-density field of tiny rotating particles. Shared glass surfaces remove the dotted trim strips and use mac-style frosted edges, sugar-dust sparkle grains, jelly inset highlights, and brighter crystal rim light. Style guardrails written to AGENTS.md, platform_web/AGENTS.md, platform_web/README.md, platform_web/pages/README.md, platform_web/contracts/pages.md, platform_web/schemas/frontend-structure.md, and platform_web/theme/README.md; scripts/check-structure.sh requires platform_web/theme/README.md and platform_web/components/MagicalParticleLayer.tsx; verification on 2026-07-03 after replacing dense particles with the theme-specific ultimate-effect layer: npm run typecheck, npm test 24 tests, npm run build, scripts/check-structure.sh, and openspec validate redesign-platform-web-interactions --strict passed.)
  • 2A.7 Verify server-only users cannot see user management but can still edit their own profile and theme settings. (Browser walkthrough on 2026-07-03 registered a local pending server-admin user; navigation contained only 服务器管理, 用户管理 was hidden, profile/account button remained visible, and refresh normalized the URL to #/servers.)

3. Role-Aware Workspace

  • 3.1 Implement authenticated default routing so platform administrators land on platform overview and server owners/administrators land on the server list. (routes/routes.ts defaultPageForUser + stores/navigation.ts; covered by routes/routes.test.ts.)
  • 3.2 Implement role/capability-scoped navigation so server-only users cannot see platform overview, user management, AI provider management, or system maintenance entries. (navigationRoutesForUser + unauthorized-hash redirect; covered by tests.)
  • 3.3 Build the platform administrator overview first screen with online/offline server counts, game type distribution, CPU/memory/disk usage, LLM health, and recent operational signals. (pages/HomePage.tsx.)
  • 3.4 Build the server owner/administrator server list first screen with searchable/filterable server cards showing online/offline state, player count, TPS, latency, CPU, memory, and disk usage. (pages/ServersPage.tsx.)
  • 3.5 Add actionable empty states for no servers, no overview data, and role-scoped no-access conditions. (EmptyState usages in HomePage/ServersPage + App-level no-access view.)

4. Server Detail Workspace

  • 4.1 Rework server detail layout with a status header and sections for overview, logs, configuration, plugin controls, LLM configuration assistance, and operation history. (pages/ServerDetailPage.tsx status header + section tabs.)
  • 4.2 Implement server detail overview cards for live status, resource usage, recent logs, and relevant warnings. (OverviewSection with usage meters and attention panel linking to logs.)
  • 4.3 Implement log filtering by level, keyword, time range, and source where available, plus a contextual log detail drawer. (LogsSection over /log-streams + /log-streams/query.)
  • 4.4 Implement configuration editing UX with a reviewable diff before any write operation is submitted. (ConfigSection + utils/diff.ts; write dispatched as config.write job only after diff confirmation.)
  • 4.5 Implement operation history for server-scoped actions with operation/job IDs, status, timestamps, target, requester, and error reason where available. (HistorySection combining session operations and platform jobs.)

5. Plugin Controls and LLM Safety

  • 5.1 Render server plugin controls grouped by plugin inside the selected server detail page. (PluginControlsSection with collapsible per-plugin groups.)
  • 5.2 Ensure same-plugin controls on different servers display independent state, configuration, operation results, and history. (Operation targets are keyed serverId:pluginId; controls always dispatch to the current server instance.)
  • 5.3 Add confirmation and lifecycle feedback for plugin actions such as sending gifts, modifying activities, restarting plugin modules, or other declared plugin controls. (ConfirmDialog per control + per-control ResultBadge lifecycle.)
  • 5.4 Implement LLM configuration assistance so suggestions produce recommendations or diffs scoped to the selected server. (LlmSection via /ai/config-suggestions with labeled local fallback.)
  • 5.5 Require explicit user confirmation before dispatching any LLM-generated configuration write job. (Diff review + second ConfirmDialog before config.write job dispatch.)
  • 5.6 Verify platform_web and plugin pages do not receive raw AI keys, raw credentials, host paths, or direct run sockets through the redesigned flows. (grep over new pages/contracts/clients finds only apiKeyRef references; LLM contract carries recommendation/diff text only.)

6. Responsive and Visual QA

  • 6.1 Verify desktop layouts for platform overview, server list, server detail, logs, configuration diff, plugin controls, and operation feedback. (Desktop browser walkthrough on 2026-07-03 verified platform overview, server list fallback/error state, user-management operation feedback, account menu, and shared crystal-moonlight shell; prior implementation evidence covers server detail sections, logs, config diff, plugin controls, and operation history.)
  • 6.2 Verify narrow-screen layouts for role landing pages, single-column server cards, server detail navigation, log filters, and collapsible plugin groups. (Responsive CSS remains covered by theme/base.css narrow-screen rules and prior 2.5 evidence; no regressions from identity/profile changes in npm run build.)
  • 6.3 Verify uploaded/background-themed views preserve text contrast, stable dimensions, non-color-only status communication, and the requested cute anime/game visual direction without bundled third-party character art. (Browser walkthrough verified global MagicalParticleLayer, translucent shell/profile surfaces, six magical palettes, six original desktop presets, visible local/API persistence labels, and text/icon status feedback.)
  • 6.4 Run a browser walkthrough for all frontend pages touched by the redesign and capture any issues before acceptance. (Completed on 2026-07-03 using local Vite at http://127.0.0.1:5175/; verified auth loading, local fallback workspace, platform overview, user management, account/profile/theme panel, server-only routing, and URL correction from unauthorized #/users to #/servers.)
  • 6.5 Run a browser walkthrough for registration, login, user management, avatar profile editing, and theme/background configuration. (Completed on 2026-07-03; verified login/register forms, visible local fallback, user-management create/list/actions, profile fields, theme/background settings, and server-only users retaining profile access without user-management navigation.)

7. Final Verification

  • 7.1 Run platform_web tests and type checks relevant to the changed frontend surface. (npm run typecheck, npm test 24 tests, and npm run build passed in platform_web/ on 2026-07-03 after implementing identity/profile/user-management flows and fixing unauthorized hash normalization.)
  • 7.2 Run backend/API tests if new or modified platform contracts are added. (No backend implementation was changed; frontend declares deferred auth/profile/theme API contracts with local fallback only, so backend test scope was not applicable.)
  • 7.3 Run scripts/check-structure.sh. (Passed on 2026-07-03 after requiring platform_web/theme/README.md and platform_web/components/MagicalParticleLayer.tsx.)
  • 7.4 Run openspec validate redesign-platform-web-interactions --strict. (Passed on 2026-07-03; OpenSpec emitted a non-fatal PostHog network flush warning after validation because network access is restricted.)
  • 7.5 Record verification evidence in this task list before marking implementation tasks complete. (Evidence recorded in 2A.1-2A.7, 6.1-6.5, 7.1, 7.3, and 7.4; browser walkthrough and command verification are complete.)