multi-repo-capability-review

name	multi-repo-capability-review
description	对两个及以上代码仓进行全量能力支持度联评：复用或自动补齐 report/仓名/map.md，按模型、算法、优化特性取并集，以红黄绿三态生成每仓一列的支持矩阵，并评估模型时效性、算法流行度、资源/吞吐收益及迁移代码量和人力。用于多仓选型、能力差距分析、特性移植规划、竞品矩阵、模型/算法/优化覆盖对比；当任一仓缺少能力地图时先调用 repo-capability-insight 生成。

多仓能力全量联评

对至少两个仓的固定基线能力做可追溯联评。只把 map.md 中有证据的事实写成支持；把外部时效、流行度和 benchmark 与仓内支持状态分开。

输入与输出

接受仓名、仓 URL 或本地路径；默认工作区为当前目录。规范化报告名时沿用 repo-capability-insight 的命名规则。

输出到：

report/_joint/<仓A>--<仓B>[--更多仓]/
├── support-matrix.md
└── aliases.json          # 仅在存在别名时保留

support-matrix.md 必须包含：分析元数据、模型支持联评、算法支持联评、优化特性联评、迁移优先级、证据与限制。

工作流

1. 固定范围

1. 读取工作区 AGENTS.md、未提交状态和现有 report/，保留用户文件。
2. 确认至少两个目标仓、目标后端/硬件和比较日期。用户未指定目标仓时，将“迁移”解释为：把并集中某项能力迁到当前缺失该项的仓。
3. 从各仓 map.md 读取仓 URL、完整提交 SHA 和分析日期。不同日期或动态分支不得伪装为同一时间截面。

2. 补齐缺失地图

逐仓检查 report/<仓名>/map.md。只要缺少一个：

1. 定位并完整读取 repo-capability-insight/SKILL.md；优先使用工作区 skills/repo-capability-insight/，其次使用已安装技能目录。
2. 按该技能为缺失仓生成完整五件套，不用 README 摘要替代 map.md。
3. 运行该技能的 validate_reports.py，修完错误再继续联评。

若只给仓名且无法确定仓 URL/本地路径，停止并向用户确认，不猜同名仓。

3. 生成三类并集

先运行并集脚本生成可审计草稿：

python3 <skill-dir>/scripts/build_union_matrix.py \
  --workspace <工作区> \
  --repo <仓A> --repo <仓B> \
  --output <输出目录>/support-matrix.md \
  [--aliases <输出目录>/aliases.json]

脚本按名称归一化但不擅自合并语义。人工复核以下高风险别名：

• 模型家族与具体版本，如 Qwen3、Qwen3-VL、Qwen3-MoE；不同架构不得合并。
• 算法变体，如 DPO 与 IPO、LoRA 与 QLoRA；只有实现语义相同才合并。
• 优化别名，如 SP、Ulysses、CP；通信模式不同不得因目标相似而合并。

确需合并时写 aliases.json，格式见 联评口径，重新生成草稿。每个仓库支持单元格只使用以下红黄绿三态，状态标签后再写范围和证据说明：

• ✅ 支持：当前入口、实现及测试/案例相互印证。
• 🟡 部分支持：确有实现或可调用入口，但仅覆盖部分模型/后端，或仍是原型、实验、文档支持、受限/遗留路径。
• ❌ 不支持：主动核查未发现当前实现；或者 map.md 无同名项，复核别名/组合项后仍没有正向支持证据。证据不足归入红色，不得用黄色表达未知。

先检查别名和更高层组合项，再定稿支持状态。自动草稿对无同名记录的仓直接输出 ❌ 不支持 并保留“需复核别名/组合项”的原因；人工复核若找到正向实现证据，再改成黄或绿。不得使用 ✅ 已实现、🟡 部分/实验、🟡 证据不足、❌ 未发现 等旧标签，也不得引入第四种颜色。

4. 补充迁移价值

完整阅读 联评口径，替换脚本生成的所有 REVIEW_REQUIRED。

模型维度：

1. 浏览官方发布页、模型卡或 release，记录首次公开日期和访问日期。
2. 按比较日计算年龄；区分最新家族与旧小版本，不能用家族新版本掩盖仓内实际支持的旧版本。
3. 结合当前生态采用、目标场景和替代模型评估迁移收益。模型过旧且已有明确替代时，默认降低优先级。

算法维度：

1. 用当前官方文档核查至少三个主流训练栈的采纳情况；没有足够来源时写“证据不足”。
2. 区分主流基础能力、快速增长、新兴试验、利基/下降；论文热度不能替代生产实现。
3. 说明新增任务能力、质量收益或训练成本影响，避免只写“流行”。

优化特性维度：

1. 分开写资源节约（HBM、host RAM、I/O、卡数、checkpoint 时间）与吞吐收益（tokens/s、step-time、MFU、通信暴露）。
2. 优先引用同模型、同硬件、同 batch/sequence 的 benchmark；条件不一致时明确不可横比。
3. 没有数字时只写机制收益和验证方案，不编造百分比。

5. 估算迁移工作量

以“最佳来源实现 → 当前缺失仓”为方向，逐项给出：

• 代码量区间（LoC）与涉及文件数。
• 人力：工程师数量 × 人周，并拆出实现、测试、配置/文档和硬件验证。
• 估算依据：源 map.md 的迁移工作量、目标仓相似抽象、后端差异和测试矩阵。

若各缺失仓差异显著，在工作量单元格按仓分别列出；禁止用一个精确数字覆盖所有目标仓。

6. 排序与验收

按“当前缺口 × 迁移收益 × 时效/流行度 × 适用广度 ÷ 工作量与风险”给出 P0/P1/P2，并记录不迁移项及原因。优先级规则见 联评口径。

运行：

python3 <skill-dir>/scripts/validate_joint_review.py \
  <输出目录>/support-matrix.md --repo <仓A> --repo <仓B>

修完全部错误后才宣布完成。最终报告必须满足：

• 三张并集表每项有名称、内容说明、每仓支持列、迁移收益、代码量和人力、证据 URL。
• 每个仓的支持结论可回溯到固定 SHA 的 map.md；没有正向证据的项标为 ❌ 不支持，同时保留“证据不足/未发现”的原因，避免把判断强度伪装成事实强度。
• 模型有官方发布日期；算法有当前流行度证据；优化收益区分量化证据与机制推断。
• 明确地图时点不一致、外部资料访问日期、未跑实验和不可比 benchmark。