提供的能力
@nocobase/app-plugin-foundation 提供应用能力概览，帮助管理员了解当前应用接入了哪些 Core 能力、已有何种使用证据，以及业务模块与这些能力的关系。
底座用于观察已有接入，不负责安装插件或替代实际业务验收。
查看应用能力
打开应用底座后，选择账户、权限、文件、通知、AI 等能力，查看当前配置、可识别的使用情况和相关包。插件按请求读取应用配置、已注册服务、默认数据库连接及迁移信息，结果会短暂缓存；刷新会重新采集。
“已安装”“已注册”“已配置”和“已使用”是不同证据。一个包出现在依赖中，不能证明业务正在使用它。未识别的自定义或商业扩展可显示为独立项，其使用情况可能仍待确认。
使用场景与示例
示例：确认邮件能力是否接通
- 在应用底座查看邮件能力是否识别到运行时及已连接邮箱。
- 打开相应业务模块，确认真正接入了邮件账户页和工作台。
- 完成一次受控收发验证，再结合底座中的统计检查使用情况。
底座展示的是读取到的证据，不会代替真实邮件收发、模型调用或业务验收。记录总数只在明确选择统计时查询；采集失败不应被理解成数量为零。
开发提示词（交给当前应用目录中的 Coding Agent）：
请使用应用底座插件，为管理员接入 Core 能力概览。
优先复用已注册页面，保留 unrestricted 访问要求，按应用导航放入系统设置。
需要部署后的模块关联时接入 CLI 构建贡献。
区分已安装、已注册、已配置和使用证据，采集失败不能显示成零或未使用。
验证普通用户直接请求被拒绝；邮件等能力另做受控业务验收。完成标志：管理员能看到能力与证据，普通用户被拒绝，未识别或失败状态不会被误报为业务结论。
重要原理与实现
以下是实现本例时的接入位置与预期界面变化；它们是开发说明，具体文件名沿用当前应用结构。
| 接入位置 | 代码或配置变化 | 界面与行为变化 |
|---|---|---|
| Client、Server 插件配置 | 配置页面路径及导航选项 | 系统设置中展示能力概览 |
| 可选 CLI 贡献与构建 | 生成 foundation-modules.json | 部署后可读取静态模块关联 |
| 业务验证记录 | 将底座观察结果与实际业务验收对应 | 不把依赖存在误认为业务已经跑通 |
接入与入口
在身份认证、权限管理等依赖之后注册 Client 和 Server 插件。foundation() 默认提供 /foundation 页面和菜单，默认模板使用 foundation({ settingsGroup: true }) 将其放入系统设置分组。
| Client 选项 | 用途 |
|---|---|
path | 更改页面路径 |
navigation: false | 保留页面但不自动显示菜单 |
routes: false | 由应用自己挂载公开的 FoundationPage |
settingsGroup: true | 将入口放入设置分组 |
页面与 GET /api/foundation/overview 只允许 unrestricted 身份访问，例如持有 root 权限集的管理员。这不是可以任意分配给普通角色的页面权限。
业务模块与部署
业务模块来源于当前导航树，关联关系来自可识别的页面、接口和后端依赖。矩阵中的空白表示未识别，不能据此判断模块一定没有使用某项能力。
需要部署产物保留静态模块关联时，注册 /cli 的贡献。应用构建会生成 dist/server/foundation-modules.json；已有应用需要重新构建后才能获得这份信息。插件不执行被扫描的业务源码来判断关联。
AI 开发的约束与验证
本插件的开发约束
- 页面和接口保留 unrestricted 要求，不为让入口出现而放宽为普通登录即可访问。
- 不把空白关联或采集失败解释成没有使用；显示保留证据的原检查时间。
- 部署时核对构建产物，具体邮件、模型或数据库操作仍分别验收，不能用底座统计代替业务测试。
验证与限制
检查管理员访问、普通用户拒绝、刷新和信息读取失败的展示。默认连接以外的数据、无法静态识别的服务组合或尚未支持的扩展可能不在统计范围；历史可靠数据会标注原检查时间。
本插件不负责安装、启用或升级其他插件，也不能证明升级检查、迁移校验或业务测试已经通过。相关文档：管理插件、数据库浏览。
上述检查是接入后的验收要求，不表示本文已完成运行验证。让 Agent 报告实际改动、执行过的检查和未验证项；项目指引、Skills 与通用检查流程见持续开发应用和测试。
源码依据：插件公开入口与实现。