插件选择边界
先确认插件角色、所需 Scenario 区域、服务权限、输出与后端能力，再把实例写入 Run。安装一个包不会自动启用它，也不会让它获得未声明的控制或场景访问。
当前目录包括 Server、Record、Replay、Visualizer、TUI、MCP、Interactive Debug、Mission 以及共享 recording/control/kinematics 支持包。不是所有支持包都会作为 Runtime 实例出现。
全部软件包
下面的目录由站点构建器从当前官方插件仓库生成。每个详情页保留对应 package README 的来源链接。
按应用需求选择能力
| 目标 | 首先查看 | 组合关系 |
|---|---|---|
| 执行任务与长流程 | Mission | 读取 Scenario/Scene/Frame/Geometry，使用 Control/Kinematics |
| 接入模型服务 | Model 与 transport/reference SPI | 模型语义在插件，物理执行回到 Control |
| 人工遥操作 | Teleop 与 driver/mapping SPI | 设备输入映射为稳定控制意图 |
| 生产训练/复现数据 | Record、recording-format | 在线消费授权通道，原子发布 FSR |
| 重放已封口运行 | Replay | 解析 FSR，服从当前 generation/targets/authority |
| 浏览器或远程客户端 | Server | 把同一 Application 映射为 HTTP/实时协议 |
| 本地终端控制台 | TUI | 连接公共 Server，不创建第二个 Runtime |
| Agent 工具接入 | MCP | 把明确能力投影为机器工具，仍受服务权限约束 |
| 查看规划与运行诊断 | Visualizer / Interactive Debug | 使用稳定 visualization、state 与 pause/step 边界 |
支持包（SPI、portable Provider、conformance、recording format）可能不会在 Run 中作为可见插件实例出现。它们为其他插件定义替换点、数据格式或一致性门禁；不要因为包名出现在环境中就把它写进 plugins 列表。
组合、发现与启用
第一，确认每个插件的角色与 Plugin ID；第二，确认当前版本与 Core 的兼容范围；第三，确认 Scenario 区域、实体 binding 与公共服务；第四，若存在多个控制来源，定义完整 precedence。Record、Server 等非控制角色不应意外获得控制 authority。
插件之间通过 Core 公共服务协作，不依赖彼此的 Python 私有对象。这样可以在不安装 Mission 的情况下使用 Record，也可以在不启用 Server 时运行相同 Python Application。
安装、发现与启用是三个独立阶段。安装发行包只登记 Manifest/Factory entry point；fastsim plugins list 与 inspect 用元数据查看候选能力；Run 选择兼容 Plugin ID 后，Compiler 才建立实例计划，Runtime 最后导入所选 Factory。
这也意味着排障应按顺序进行：包是否安装、entry point 是否完整、Manifest 是否兼容、Run 是否选择、binding/access 是否有效、Factory 是否可构造、hook 是否通过。直接在 Python 中导入某个内部类不能证明 FastSim 能正确发现和运行插件。
插件质量门禁
一个可发布插件至少需要配置/行为单测、Manifest 与 Index 摘要一致性、两组 entry point 验证、Factory descriptor 与生命周期一致性、重复 stop/close 和异常清理、wheel/sdist 构建、干净环境安装发现，以及对真实实现能力的后端或硬件证据。
尚未运行的真实集成只能标记为未验证。README 中存在配置片段、类名或后端名称，不等于该组合已经通过生命周期与行为验收。