StellCloud Web 是 StellHub 系列中间件的统一前端入口，面向大型企业内部的研发、SRE、平台工程和应用负责人，提供以应用为中心的服务治理、配置中心、日志平台、消息队列和 API 网关控制台。
StellCloud Web 不是单个中间件的后台页面，而是企业中间件中台的统一入口。它的核心价值是把分散在不同后端、不同 IP、不同团队维护的中间件能力，沉淀为一致的前端工作台。
产品定位如下：
- 统一入口：用户从 StellCloud 进入所有中间件产品，不需要记忆多个后台地址。
- 应用视角：所有页面围绕当前应用展开，而不是围绕机器、集群或某个后端服务展开。
- 分域治理：服务治理、配置中心、日志平台、消息队列、API 网关保持独立 URI 和独立子模块。
- 跨后端兼容：前端支持不同中间件后端运行在不同域名、端口、网段或网关路径下。
- 企业级扩展：每个中间件子页面可以继续增长复杂业务逻辑，但入口层保持克制、清晰和稳定。
- 应用研发：查看当前应用依赖的服务、配置、日志、Topic、网关路由和权限规则。
- SRE/运维：排查链路异常、消费堆积、配置风险、实例健康和网关流量问题。
- 平台工程师：维护中间件产品能力、治理规则、全局模板和平台集成。
- 技术负责人：从应用维度观察中间件治理成熟度、风险分布和运行质量。
首页只承担企业门户和产品入口职责，不展示接口调参、后端地址、默认巡检状态等工程内部信息。
当前首页包含：
- StellCloud 品牌与中台定位。
- 当前应用视角。
- 五个中间件产品入口。
- 默认隐藏的左侧产品导航。
各中间件拥有独立页面和稳定 URI：
- 服务治理：实例信息、实例空间、路由规则、熔断规则、限流规则、鉴权规则。
- 配置中心：应用配置、通用配置。
- 日志平台：日志检索、异常分析、Trace 关联、索引管理。
- 消息队列：Topic 管理、消费组诊断、重放消息、死信队列。
- API 网关：路由管理、证书管理、鉴权策略、流量策略、上游健康、审计日志。
首页需要简约、大气、稳定，像企业级平台入口，而不是调试工具页。
设计原则：
- 不展示后端源站、代理路径、健康路径、Token、请求方法等接口调参内容。
- 不在每个中间件卡片上默认展示工程占位状态。
- 不把后端联通性作为首页第一信息层级。
- 产品卡片只表达产品域、产品名称、核心能力和进入入口。
- 健康检查、实例状态、后端联通性下沉到具体中间件页面。
健康状态是运维动作，不是首页导航能力。它应当出现在用户已经进入某个中间件之后，用来判断当前产品后端或业务域是否可用。
子页面状态分层：
- 未检查：页面尚未主动检查该中间件后端。
- 运行正常：健康接口可达，产品后端处于可用状态。
- 需要关注：健康接口可达但返回非理想状态，适合提示 SRE 进一步查看。
- 连接异常：健康接口不可达或请求失败。
这种设计可以避免首页出现一排无业务含义的默认状态，同时保留必要的运维诊断入口。
StellCloud 的全局上下文是 appId，格式固定为五段式：
organization.businessDomain.capabilityDomain.application.role
默认值：
stellhub.core.middleware.stellcloud.admin
前端需要保证：
- 路由跳转时通过
?appId=...保持应用上下文。 - 请求后端时通过
X-Stell-App-Id透传应用上下文。 - 页面展示时突出应用名称和所属组织、业务域、能力域、角色。
- 各中间件页面使用同一个 appId，避免用户在不同控制台之间重复选择应用。
StellCloud Web 使用后端目录管理每个中间件产品的连接方式。每个产品可以独立配置：
baseUrl：直接访问后端源站，例如http://10.0.1.12:18080。proxyPath：同源代理路径，例如/api/stellorbit。healthPath：子页面健康检查使用的后端健康端点。mode：direct-cors或same-origin-proxy。credentials：浏览器凭据策略，默认omit。
浏览器 CORS 不能由前端代码绕过。对于企业内网多后端场景，推荐生产环境通过 API Gateway、Nginx 或 BFF 做同源聚合，前端只维护稳定的产品级访问契约。
当前开发代理：
/api/stellorbit->http://localhost:18080/api/stellcloud/control-plane->http://localhost:18080/api/stellspec->http://localhost:18280/api/stellflow->http://localhost:18380/api/stellgate->http://localhost:18480
每个中间件平台和子模块都必须独立演进，避免把未来的大量业务代码堆在单个入口文件里。
当前代码组织：
src/app/platforms.ts：产品路由注册表。src/app/app.ts：应用壳层、全局导航、应用视角、路由渲染。src/app/backendDirectory.ts：中间件后端目录。src/app/httpClient.ts：跨后端请求封装。src/features/*：各中间件子模块页面。src/shared/*：共享类型、HTML 转义和模块页面渲染基础。
子模块通过动态导入加载，构建后会形成独立 chunk，后续可以逐步替换为更完整的组件、OpenAPI Client、状态管理和权限控制。
/platform/service-governance/instances/platform/service-governance/spaces/platform/service-governance/routes/platform/service-governance/circuit-breakers/platform/service-governance/rate-limits/platform/service-governance/auth-rules/platform/configuration/app-config/platform/configuration/shared-config/platform/observability/log-search/platform/observability/exceptions/platform/observability/trace-link/platform/observability/indexes/platform/messaging/topics/platform/messaging/consumer-groups/platform/messaging/replay/platform/messaging/dead-letter/platform/api-gateway/routes/platform/api-gateway/certificates/platform/api-gateway/auth/platform/api-gateway/traffic/platform/api-gateway/upstreams/platform/api-gateway/audit
整体视觉采用星际、宇宙、控制舱风格，但不牺牲企业系统的清晰度。
设计要求：
- 首页简洁，突出品牌、应用视角和产品入口。
- 左上角仅展示当前登录用户名称，不放置品牌、菜单文案或运行状态。
- 左侧菜单默认隐藏，避免入口页被导航压迫。
- 左侧导航与右侧工作区保持颜色层级区分。
- 子页面进入时有轻量页面动效，形成“进入新控制台”的体验。
- 不使用大面积营销式说明，不把调试信息当作主要内容。
建议按以下顺序演进：
- 接入真实 OpenAPI Client，替换当前 demo 数据。
- 引入统一权限模型，按 appId、角色、产品域控制可见能力。
- 建立产品级错误码、空状态、加载态和审计事件规范。
- 将健康检查扩展为产品子页面内的运行态诊断面板。
- 增加应用选择器、收藏视图和最近访问模块。
- 引入统一可观测埋点，追踪页面访问、操作触发和失败路径。
Install dependencies:
npm installStart the development server:
npm run devThe local Vite port is 5180.
Build for production:
npm run build