processmission 用途
使用此 skill 对 openEuler 相关信息进行基于权威证据的查询和调研，包括：
- 查询发行版版本、下载入口、生命周期、发布说明和商业发行版信息。
- 查询官方文档、技术白皮书、FAQ、安全公告、缺陷公告、迁移及运维资料。
- 查询 SIG、组织架构、仓库归属、邮件列表、社区会议、新闻及社区动态。
- 查询软件源码、SRPM、软件包、Repo 源、镜像站、构建服务及依赖关系。
- 调研内核、Embedded BSP、硬件兼容性以及所需功能是否真正交付。
权威入口
开始调研前，必须根据问题类型查阅 openEuler 权威入口。该 reference 汇总官网顶部导航中的发行版、软件包、源码治理、文档支持及社区动态入口，并标明各入口的使用边界。
版本规则
- 匹配用户指定的准确 openEuler 版本或分支。
- 用户未指定版本时，仓库和 SIG 元信息使用
master，且在回复用户时需明确指出。 - 调研内核时，记录所检查的准确内核分支、提交以及生成配置或 defconfig。
- 不得混用不同发行分支的证据；确需引用时必须明确标注差异。
仓库发现
从 community 仓库开始，不得猜测仓库名称：
- 读取
community的master分支。 - 在
sig/<sig-name>/下定位相关 SIG。 - 读取其
sig-info.yaml和仓库元信息。 - 区分
openeuler/*源码仓库和src-openeuler/*打包仓库。 - 在各仓库的 AtomGit 官方地址继续内容调研。
调研嵌入式领域时，从 sig/sig-embedded/ 开始。通过元信息确认当前仓库列表，不得依赖过期的网页渲染结果或搜索引擎统计数量。
来源优先级
按以下顺序使用来源：
- 使用 AtomGit
community元信息发现 SIG 归属和仓库。 - 使用 AtomGit 官方仓库的准确目标分支获取源码证据。
- 使用 openEuler 官方文档确认支持流程和发行版行为。
- 当 openEuler 元信息明确获取外部源码时，使用对应厂商或上游官方仓库。
- 网络搜索仅用于交叉验证或定位官方资料。
GitHub 镜像、第三方 fork、博客和搜索摘要只能作为补充。报告任何重要结论前，必须通过 openEuler、厂商或上游官方来源独立核验。
功能支持审查
跟踪完整交付链路：
- 仓库归属——哪个 SIG 或仓库负责该功能。
- 源码存在——请求分支上是否存在实现代码。
- 构建选择——配方或 manifest 实际选择了哪个源码 URI 和修订版本。
- 配置状态——相关 defconfig 或镜像配置是启用为
=y、=m，还是关闭。 - 镜像包含——配方或 packagegroup 是否把功能安装到产出镜像。
- 运行集成——所需固件、ACPI/DT、Bootloader、硬件 ID、用户态组件或产品策略。
- 验证层级——区分静态源码证据、成功构建、成功启动和实硬件测试。
结论分类：
- 满足——已有实现、配置、镜像集成和适用运行链路的证据。
- 有条件满足——能力存在，但仍需配置、板级描述、固件、软件包选择或硬件验证。
- 不满足——所检查的产品链路缺少实现或集成。
- 不属于该组件职责——例如软件包管理或 A/B 编排不是内核单独提供的能力。
内核和 BSP 注意事项
- 源码中存在驱动，不代表所选 defconfig 已启用该驱动。
- 编译为模块不代表它可直接用于根设备或早期启动依赖；必须检查 initramfs 或内建配置。
- 通用 openEuler 内核检出可能不是 Embedded BSP 实际选择的内核。沿
SRC_URI、manifest、配方、修订版本和 machine 配置追踪实际源码。 - 通用框架支持不能证明支持特定设备型号或板级协议。
- UEFI/ACPI、UEFI/DTB 和 U-Boot/DTB 是不同的交付链路。必须核验实际固件、启动配方、镜像布局和硬件描述方式。
- 可构建、软件包可用、默认安装和已经验证运行是四种不同结论。
证据和报告
- 引用官方 URL；条件允许时同时给出仓库相对路径和行号。
- 说明所检查的分支；对于可变分支，还要给出提交或观察日期。
- 报告未找到结果时必须限定范围，列明检查过的仓库路径和搜索模式。
- 官方页面不完整或受阻时，改用其他官方呈现方式重试，例如 AtomGit tree/blob 视图、官方 raw 内容、发行版文档或项目指定的厂商官方仓库。不得静默切换到镜像。
- 回答长度与用户请求相称。仓库列表问题只返回所需列表；功能支持审查应提供逐项矩阵和剩余集成缺口。