用途

使用此 skill 对 openEuler 相关信息进行基于权威证据的查询和调研，包括：

• 查询发行版版本、下载入口、生命周期、发布说明和商业发行版信息。
• 查询官方文档、技术白皮书、FAQ、安全公告、缺陷公告、迁移及运维资料。
• 查询 SIG、组织架构、仓库归属、邮件列表、社区会议、新闻及社区动态。
• 查询软件源码、SRPM、软件包、Repo 源、镜像站、构建服务及依赖关系。
• 调研内核、Embedded BSP、硬件兼容性以及所需功能是否真正交付。

权威入口

开始调研前，必须根据问题类型查阅 openEuler 权威入口。该 reference 汇总官网顶部导航中的发行版、软件包、源码治理、文档支持及社区动态入口，并标明各入口的使用边界。

版本规则

1. 匹配用户指定的准确 openEuler 版本或分支。
2. 用户未指定版本时，仓库和 SIG 元信息使用 master，且在回复用户时需明确指出。
3. 调研内核时，记录所检查的准确内核分支、提交以及生成配置或 defconfig。
4. 不得混用不同发行分支的证据；确需引用时必须明确标注差异。

仓库发现

从 community 仓库开始，不得猜测仓库名称：

1. 读取 community 的 master 分支。
2. 在 sig/<sig-name>/ 下定位相关 SIG。
3. 读取其 sig-info.yaml 和仓库元信息。
4. 区分 openeuler/* 源码仓库和 src-openeuler/* 打包仓库。
5. 在各仓库的 AtomGit 官方地址继续内容调研。

调研嵌入式领域时，从 sig/sig-embedded/ 开始。通过元信息确认当前仓库列表，不得依赖过期的网页渲染结果或搜索引擎统计数量。

来源优先级

按以下顺序使用来源：

1. 使用 AtomGit community 元信息发现 SIG 归属和仓库。
2. 使用 AtomGit 官方仓库的准确目标分支获取源码证据。
3. 使用 openEuler 官方文档确认支持流程和发行版行为。
4. 当 openEuler 元信息明确获取外部源码时，使用对应厂商或上游官方仓库。
5. 网络搜索仅用于交叉验证或定位官方资料。

GitHub 镜像、第三方 fork、博客和搜索摘要只能作为补充。报告任何重要结论前，必须通过 openEuler、厂商或上游官方来源独立核验。

功能支持审查

跟踪完整交付链路：

1. 仓库归属——哪个 SIG 或仓库负责该功能。
2. 源码存在——请求分支上是否存在实现代码。
3. 构建选择——配方或 manifest 实际选择了哪个源码 URI 和修订版本。
4. 配置状态——相关 defconfig 或镜像配置是启用为 =y、=m，还是关闭。
5. 镜像包含——配方或 packagegroup 是否把功能安装到产出镜像。
6. 运行集成——所需固件、ACPI/DT、Bootloader、硬件 ID、用户态组件或产品策略。
7. 验证层级——区分静态源码证据、成功构建、成功启动和实硬件测试。

结论分类：

• 满足——已有实现、配置、镜像集成和适用运行链路的证据。
• 有条件满足——能力存在，但仍需配置、板级描述、固件、软件包选择或硬件验证。
• 不满足——所检查的产品链路缺少实现或集成。
• 不属于该组件职责——例如软件包管理或 A/B 编排不是内核单独提供的能力。

内核和 BSP 注意事项

• 源码中存在驱动，不代表所选 defconfig 已启用该驱动。
• 编译为模块不代表它可直接用于根设备或早期启动依赖；必须检查 initramfs 或内建配置。
• 通用 openEuler 内核检出可能不是 Embedded BSP 实际选择的内核。沿 SRC_URI、manifest、配方、修订版本和 machine 配置追踪实际源码。
• 通用框架支持不能证明支持特定设备型号或板级协议。
• UEFI/ACPI、UEFI/DTB 和 U-Boot/DTB 是不同的交付链路。必须核验实际固件、启动配方、镜像布局和硬件描述方式。
• 可构建、软件包可用、默认安装和已经验证运行是四种不同结论。

证据和报告

• 引用官方 URL；条件允许时同时给出仓库相对路径和行号。
• 说明所检查的分支；对于可变分支，还要给出提交或观察日期。
• 报告未找到结果时必须限定范围，列明检查过的仓库路径和搜索模式。
• 官方页面不完整或受阻时，改用其他官方呈现方式重试，例如 AtomGit tree/blob 视图、官方 raw 内容、发行版文档或项目指定的厂商官方仓库。不得静默切换到镜像。
• 回答长度与用户请求相称。仓库列表问题只返回所需列表；功能支持审查应提供逐项矩阵和剩余集成缺口。