35 lines
3.6 KiB
Markdown
35 lines
3.6 KiB
Markdown
## Why
|
|
|
|
The current platform web experience is too sparse and unreliable for daily game server operations: controls are unclear, actions do not always provide visible feedback, and role-specific users cannot immediately reach their most common work. The platform needs a role-aware, visually expressive game operations interface that remains debuggable and safe for server, plugin, and LLM-assisted configuration workflows.
|
|
|
|
## What Changes
|
|
|
|
- Introduce role-aware landing behavior: platform administrators land on a platform overview, while server owners and server administrators land on their server list and cannot access the platform overview.
|
|
- Redesign the platform overview around first-screen operational health: online/offline server counts, game type distribution, CPU/memory/disk load, LLM connectivity, and recent log or fault signals.
|
|
- Redesign the server list and server detail flows for server owners and administrators, emphasizing server status, player count, TPS/latency, and resource usage.
|
|
- Move day-to-day plugin controls into each server detail page, grouped by plugin, with per-server plugin state and configuration isolation.
|
|
- Add a reliable operation feedback model for UI actions: clear loading states, success/failure results, operation/job IDs, retry and diagnostics affordances, and no silent multi-API button behavior.
|
|
- Add guarded LLM-assisted configuration UX: LLM output must produce a reviewable diff or recommendation before any server-side write job is dispatched.
|
|
- Add a themeable anime/game visual direction for platform_web, leaning toward magical-girl and virtual-idol energy through original crystal-moonlight glass, transparent jelly surfaces, built-in magical desktop presets, gradients, rim-light highlights, diamond/ribbon/magic-circle motifs, cute magical icons, a unified global magical ultimate-effect layer, and user-uploaded backgrounds while preserving readable operations panels.
|
|
- Prioritize the current user flows: create users, registration, login, user management, avatar-menu profile editing, contact fields such as phone and QQ, and per-user theme/background settings.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
- `role-aware-platform-workspace`: Role-based platform_web navigation, default landing pages, and first-screen dashboard/server-list requirements.
|
|
- `server-plugin-control-workspace`: Server detail workspace requirements for logs, configuration, plugin controls, and per-server plugin isolation.
|
|
- `operation-feedback-and-safety`: Shared interaction requirements for loading, empty, error, task result, diagnostic, and LLM diff confirmation states.
|
|
- `user-identity-and-profile`: Authentication, user administration, profile/contact editing, avatar entry point, and user theme preferences.
|
|
|
|
### Modified Capabilities
|
|
|
|
None.
|
|
|
|
## Impact
|
|
|
|
- Affects `platform_web/` routing, navigation, page composition, visual design system, server list, server detail, plugin control, log, configuration, and operation feedback UI.
|
|
- May require API/client contract adjustments in `platform_web/` for role capabilities, overview metrics, per-server plugin control surfaces, operation/job status, diagnostics IDs, and LLM-generated configuration diffs.
|
|
- May require backend `platform/` support only where existing APIs do not provide the necessary role-scoped data, operation/job tracking, or reviewable LLM diff responses.
|
|
- Must preserve AI provider key ownership in `platform/`; plugin pages and platform_web must never receive raw AI keys.
|
|
- Must preserve run-platform channel separation and avoid exposing host paths, raw credentials, or direct sockets to platform_web or plugins.
|