rfc: 外部技能内容的依赖、版本锁定与可复现导入（外链或 submodule 待决） #388

为 InferRSI 建立一套外部技能内容依赖的跟踪与设计入口：当需要使用仓外技能包（会议举例为 cann-bot skill）时，必须能说明来源身份、精确版本锁定、授权/许可、离线与复现核验、更新失败与漂移时的拒绝规则，以及它与现有「蒸馏进本仓知识库」路径如何并存。

本 Issue 不预先选择外链或 git submodule；二者都只是待比较的候选实现（比较维度包括复现、权限、更新、回滚）。先把问题、约束和验收写清，实现方式在评审中决定。接受本 RFC 不等于选定实现，也不授权实施、代码搬家或批量蒸馏。cann-bot 只作为会议举例保留；实际接入时再确认具体来源，不把历史蒸馏来源自动当成本次技能包地址。

已有覆盖（不要重复验收）

现有工作覆盖的是「从钉住的上游 revision 蒸馏/摘录为本仓候选知识」，不是「把外部技能包作为可复现依赖导入并在运行时使用」。当前没有已接受的外部技能包依赖机制。

• #91（open，SearchSpace 蒸馏覆盖跟踪）已登记：
  • 历史 awesome-ascend-skills @ 75ec89c 中的 cannbot-skills 镜像材料，经 #12（已合入）进入本仓 skill library，不是对 cann/cannbot 的直接应用接入；
  • 另有一条独立来源：cann/cannbot @ c0e2ad23ee1a73e3c0f84c8df1cc459e2aae3110，由 #114 于 2026-10-23 16:06:38（Asia/Shanghai）合入，squash 4ac039c14a23335bafab52d84174d1d4765bfcb1，将固定阶段证据规则写入既有 ascend-performance-analysis 候选技能；未移植上游实现，也未建立 submodule / 外链依赖。
• #91 中的 “Output directory convention” 写的是包内语料路径 src/inferrsi/data/...，不是运行产物目录，也不是本 Issue 的范围。
• #48（已关闭、已接受）定义的是源码蒸馏与 revision pin；文中 “submodule boundaries” 指阅读上游归档时要尊重其自身子模块边界，不是 InferRSI 用 submodule 引入技能。
• #17（已关闭）是知识库内容契约；提及只读适配和引用而非拷贝，但未交付外部技能包依赖机制。
• #43（已关闭）记录过 cannbot-skills 同步来源的 license: UNKNOWN 与许可链待解；许可/分发约束仍适用于任何新的导入路径。
• #352（open）按 CannBot 蒸馏模式接入 ModelAgent；#385（open）是从 HuggingArch 蒸馏模型级 skill。二者都不是通用导入机制。
• #355（open）与已合入 #359（2026-11-10 17:36:22 Asia/Shanghai，squash 14fa1f578655bbdcd101b8c4235299fc3d8360d3）处理的是本仓知识投影 / source_revision 变更成本，不是外部技能依赖。
• #339 已于 2026-11-10 19:33:22（Asia/Shanghai）合入 bd61d20c52b4d772a3ea282ae9cb3c0fd50075df，是又一次源码钉死的蒸馏增量（Refs [Tracking] SearchSpace distillation coverage and knowledge consolidation #91 / [Research Radar] AI inference performance & RSI — daily categorized insights #177），不覆盖本机制。
• #177 是研究雷达，不授权知识自动导入。
• #387 的 Knowledge read/collect 针对本仓逻辑 Bundle 与 revision pin；未定义仓外技能包的依赖登记。

真实缺口

缺少一份被接受的契约，说明：

1. 外部技能内容如何登记来源（URL/身份在实际接入时确认，不在开 Issue 时猜）；
2. 如何精确锁定版本（commit / tag / digest）并在离线与复现时核验；
3. 许可、授权与分发边界（含历史 UNKNOWN 材料不得被默许为已授权）；
4. 导入是只读引用、锁定快照，还是进入本仓知识库；与 [Tracking] SearchSpace distillation coverage and knowledge consolidation #91 蒸馏路径如何并存、如何避免双源；
5. 失败与漂移规则：来源不可达、pin 被替换或内容漂移、许可不清、内容与声明不符、更新失败时如何拒绝，而不是静默使用。

范围

范围内： 依赖模型、精确版本锁定、授权/许可、离线与复现核验、更新失败与漂移时的拒绝规则、与现有蒸馏路径的边界、验收夹具要求，以及外链 / submodule / 其他候选实现的比较维度。

范围外： 选定并实施某一种导入技术；批量蒸馏新来源；自动晋升知识成熟度；修改 #91 覆盖表来代替本契约；把包内 src/inferrsi/data/ 布局改写成运行输出合同；访问或绑定尚未由请求方确认的私有仓库；改 Apps 目录或把依赖机制写进 Harness / Benchmark 端口。

验收 / 关闭条件

维护者书面接受（或修订后接受）下列说明后关闭。不指定负责人或日期。不因本 Issue 已开或已有讨论而关闭。实施切片另开，不在此验收合入。

• 外部技能依赖与「蒸馏进本仓」是两条路径，关系写清，不互相替代。
• 来源身份、版本锁定字段、许可/授权检查和离线/复现核验步骤已写明；许可不明则不可当作已授权内容分发或默认启用。
• 对外链、submodule 或其他候选实现给出比较维度（复现、权限、更新、回滚），但接受本 RFC 不等于选定实现。
• 至少有一组夹具约定：钉住的来源可核验；pin 被替换、内容漂移或更新失败时导入失败；未确认来源不得写入契约。
• 会议举例 cann-bot skill 仅作场景说明；具体上游 URL 与修订号在实际接入时确认。若沿用既有蒸馏来源，须显式核对，而不是默认等同于 #114 使用的 cann/cannbot。

相关讨论

方向背景见 #362（已接受方向）与 #387（公开接口，仍为 Proposed）。本议题主要落在 Knowledge 的来源与读取边界：外部技能若要进入 read/collect，须先成为带 pin 与限制的合法来源。#362 第 7.4 条知识生命周期仍由既有整理跟踪（如 #350）承接，不在本 Issue 改 status 枚举。