cc @kongche-jbw @ikunkun-sys @casparant
背景
ktuner 已经合入 main（src/ktuner/，#1278 ，感谢 @casparant 的 review 与合入 🙏），cosh #1279 也会在用户首次配置好 key 登录时调用它做一次只读的内核检查。在继续推进的过程中，我注意到一个缺口，想先如实同步给大家、请教后续怎么安排：
目前还没有把编译好的 ktuner 二进制送到用户机器的打包 / 发布环节 ，所以 ktuner 到不了 PATH，#1279 的首次检查会静默跳过（按设计优雅降级，不会报错）。这是组件集成的收尾工作，不是 bug。
现状核实（对照当前 main）
无打包产物 ：src/ktuner/ 只有 Cargo.toml + src/，是目前唯一既没有 .spec.in 也没有 component.toml 的运行时组件（其余组件两者都有）。分发机制里没有登记 ：grep -rn ktuner src/anolisa/manifests/ 零命中——不在 components.toml、distribution-index/index.toml、index.oss.toml。搭不了 os-skills 的车 ：os-skills.spec.in 是 noarch（“Nothing to build - skills are static assets”），只安装 SKILL.md 目录，不含二进制；ktuner 的 SKILL.md 虽然随 os-skills 发布，但那只发文档。不在 release workflow ：release.yaml 只通过 gh release create 发布源码 tarball，没有编译步骤，tag allowlist 里也没有 ktuner。不在 nightly RPM / 镜像 ：_rpm-build.yaml / docker-nightly.yaml 没有 ktuner 的打包 job。没有被遗漏的安装路径 ：install-anolisa.sh 只安装 anolisa CLI + datadir；anolisa install ktuner 会 resolve 失败（index 里没有对应行）。消费侧没问题 ：feat(cosh): consent-gated ktuner check with /ktuner command #1279 spawn('ktuner', ['check'])，只要有 /usr/bin/ktuner 或 /usr/local/bin/ktuner 就能工作。（我在 ECS 上手动放了一个 ktuner 到 PATH 验证过，链路端到端是通的。）
相关线索
distribution-index/index.oss.toml 里有一些 TODO(P1-J, owner: release-ops) 标记，覆盖其他组件的产物发布，ktuner 不在其中。看起来是同一类还没完成的分发工作——不知是否方便把 ktuner 一并纳入，还是它应该单独跟踪？
想请教两个问题
ktuner 的发布由谁负责比较合适 ？（产物 + 版本 + 校验和这一步需要 OSS / yum 凭证）走哪个渠道更合适 ——RPM/yum + nightly 镜像，还是 OSS tarball？仓库里两套都有、owner 似乎不同，想先和大家对齐再动手。
渠道和版本 owner 定了之后，in-repo 的 wiring（.spec.in / component.toml / manifest + index 行 / workflow allowlist）我很乐意来准备一个 PR，帮忙分担一部分——具体方案还是以大家的意见为准。
麻烦大家了，谢谢 🙏
cc @kongche-jbw @ikunkun-sys @casparant
背景
ktuner 已经合入 main（
src/ktuner/，#1278，感谢 @casparant 的 review 与合入 🙏），cosh #1279 也会在用户首次配置好 key 登录时调用它做一次只读的内核检查。在继续推进的过程中，我注意到一个缺口，想先如实同步给大家、请教后续怎么安排：目前还没有把编译好的
ktuner二进制送到用户机器的打包 / 发布环节，所以ktuner到不了PATH，#1279 的首次检查会静默跳过（按设计优雅降级，不会报错）。这是组件集成的收尾工作，不是 bug。现状核实（对照当前
main）src/ktuner/只有Cargo.toml+src/，是目前唯一既没有.spec.in也没有component.toml的运行时组件（其余组件两者都有）。grep -rn ktuner src/anolisa/manifests/零命中——不在components.toml、distribution-index/index.toml、index.oss.toml。os-skills.spec.in是noarch（“Nothing to build - skills are static assets”），只安装 SKILL.md 目录，不含二进制；ktuner 的 SKILL.md 虽然随 os-skills 发布，但那只发文档。release.yaml只通过gh release create发布源码 tarball，没有编译步骤，tag allowlist 里也没有 ktuner。_rpm-build.yaml/docker-nightly.yaml没有 ktuner 的打包 job。install-anolisa.sh只安装 anolisa CLI + datadir；anolisa install ktuner会 resolve 失败（index 里没有对应行）。spawn('ktuner', ['check'])，只要有/usr/bin/ktuner或/usr/local/bin/ktuner就能工作。（我在 ECS 上手动放了一个 ktuner 到 PATH 验证过，链路端到端是通的。）相关线索
distribution-index/index.oss.toml里有一些TODO(P1-J, owner: release-ops)标记，覆盖其他组件的产物发布，ktuner 不在其中。看起来是同一类还没完成的分发工作——不知是否方便把 ktuner 一并纳入，还是它应该单独跟踪？想请教两个问题
渠道和版本 owner 定了之后，in-repo 的 wiring（
.spec.in/component.toml/ manifest + index 行 / workflow allowlist）我很乐意来准备一个 PR，帮忙分担一部分——具体方案还是以大家的意见为准。麻烦大家了，谢谢 🙏