mcpp: Skill for Claude Code

mcpp 版本发布流程

版本号规范

格式：YYYY.M.D.N（日期版本，月/日不补零），例如 2026.7.27.1。 自 2026.7.27.1 起启用，此前为 0.0.x。与 xlings 生态一致（xlings 于同日从 0.4.70 迁入）。

第 4 段的语义：

.0 保留给正式版本 / 稳定版本。日常迭代默认从 .1 开始。

即一天内可发 .1、.2、.3 …… 若干次常规版本；.0 只在该版本被认定为正式 release 或稳定版时使用。

跨方案的序是单调的：0.0.109 < 2026.7.27.1，第一段从 0 变 2026，不存在回退。

比较逻辑见 src/version_req.cppm。它支持 4 段；改动那里时务必保证 str() 精确回写， src/pm/resolver.cppm 用它重建依赖版本串，会流向 lock 文件与 xlings wire 地址。 尤其 .0 结尾的版本不能塌成三段。

Overview

mcpp 有 三个持久化版本位置，以及 ci-fresh-install 的一个运行时推导值。它们分属 两组，在不同时间更新；把"正在构建的版本"与 bootstrap pin 一起前移会让 CI 尝试安装 尚未发布的 mcpp。

第一组：正在构建的版本（发布时改，走 bump PR）

1. mcpp.toml → [package].version — 构建系统读取的项目版本，release.yml 由它推导 tag
2. src/version.cppm → MCPP_VERSION — 编译期硬编码常量（--version 输出、BMI 指纹、E0006 索引底线比较）

这两处必须在同一个 commit 里一起改：tests/e2e/01_help_and_version.sh 交叉比对 mcpp.toml 与 mcpp --version，只改一处 CI 立刻红。

第二组：bootstrap pin —— CI 用哪个 mcpp 来自举（发布并进索引之后才可改）

1. .xlings.json → workspace.mcpp — CI bootstrap 装哪个 mcpp

.xlings.json 必须指向一个已经发布、镜像并进入索引的版本。因此它在 bump PR 中 保持已有的可安装版本，直到发布收尾时才可前移。

ci-fresh-install.yml 的 MCPP_PIN 不是持久化 pin：wait-index 从最新 GitHub Release 推导一次，所有安装 job 消费同一个输出。绝不能手工编辑或恢复字面量 MCPP_PIN，否则 index guard 和实际安装版本会再次漂移。

.github/tools/check_version_pins.sh 校验版本关系和 xlings pin：

bash .github/tools/check_version_pins.sh

必须用 bash 跑，不能用 sh。 脚本用了进程替换（done < <(...)），POSIX sh/dash 解析不了，用 sh 调用会在第 95 行附近报 Syntax error: redirection unexpected。那是调用它的 shell 的问题，不是脚本的缺陷 —— 它的 shebang 是 #!/usr/bin/env bash，CI 也是用 bash 调的。别据此把这条 guard 当成坏的而跳过： 它是唯一能机器化捕捉 pin 漂移的东西。

也不要通过修改文档或 workflow 绕开动态 MCPP_PIN 设计。src/platform/xlings/xlings.cppm 的 pinned::kXlingsVersion 仍是 xlings 版本的唯一真源。

发布步骤

1. 确认 main 分支状态

git checkout main && git pull origin main
# 确认 CI 全部通过
gh run list --branch main --limit 3

以分支保护和 gh pr checks <pr-number> 显示的 actual required checks 为准。 在 main 上监控当前运行时，检查 ci 这一个工作流的运行（它包含各平台、e2e 分片、 交叉构建与 e2e-coverage）；known-red 的腿（名字里带 issue 号）允许失败。跳过或 非 required 的 workflow 不是合入 gate。不要在 ci 红的时候发版。