非功能需求

NFR-01 可用性与易用性

• Dashboard 操作不超过 3 次点击完成核心流程（选择场景/策略 -> Start -> 查看曲线）
• 运行状态清晰可见（Running/Stopped/Failed），失败有明确原因与重试提示

NFR-02 响应性与实时性

• 关键操作（Start/Stop）1s 内有可见反馈
• 指标刷新周期建议 ≤ 1s（WS 推送或轮询）

NFR-03 可视化能力

• 至少 4 条实时曲线：吞吐、时延 p95、丢包率、sync_error
• 至少 1 个拓扑/节点状态视图（可先用 2D 简化）

NFR-04 可复现性

• 同一场景 + 同一 seed + 同一策略参数，重复运行结果一致（或方差可解释）
• 每次 run 必须落盘 versions.json，记录可复现所需信息

NFR-05 可维护性与扩展性

• UNET 相关逻辑隔离在 UnetAdapter；调度策略以插件化接口扩展
• 数据落盘格式稳定（CSV/JSON），便于后续接入数据库或替换前端

NFR-06 环境与依赖

• 开发环境：Windows 10/11；Python 3.10+；Node.js 18+；Git
• 部署环境（建议）：Linux（Ubuntu 20.04+）；CPU >= 2 核；内存 >= 4GB；磁盘 >= 50GB

NFR-07 日志与可观测性

• 关键阶段必须有结构化日志：run 创建/启动/停止、step 进度、调度决策、异常
• traces/metrics 生成失败时需给出原因与最小诊断信息

NFR-08 可观测性与健康检查

• 提供 GET /health 综合健康检查端点，返回数据库连接、适配器状态、逐节点健康信息
• 提供 GET /health/nodes 专用节点健康检查端点，执行深度检查（gateway 连接 → probe → check_phy → query_node_address）
• 健康状态三级分类：healthy（全部正常）、degraded（部分节点异常）、unhealthy（核心组件不可用）
• 每个节点健康报告包含：ok、phy_ok、agents 数量、services 列表、unet_addr

NFR-09 容错与降级策略

• Gateway 模式启动前执行 PHY Preflight；健康节点不足时阻断启动并提供明确错误信息
• 适配器自动探测顺序：arlpy → fjagepy → LogOnly，优先使用高精度后端，不可用时自动降级
• 数据库写入失败不阻断 run 执行；文件落盘作为最小保障
• WebSocket 断线支持自动重连，前端轮询作为 WS 不可用时的降级方案

NFR-10 配置管理

• 运行时配置集中于 RuntimeSettings，支持环境变量注入（UNET_DT_* 前缀）
• 数据库表名可通过配置映射，支持同一数据库实例部署多套环境
• 场景配置支持 YAML 文件与数据库双来源，API 合并展示
• GET /config 端点暴露当前配置摘要（脱敏），便于运维诊断