docs+ci: 本地上手三步走 + 平台矩阵拆分(linux/macos/win10/win11/win 无 MSVC STL) - #89

README(三语 + book 两语)重写「本地练习环境」段,改成明确的三步:
 1. 装工具 —— `xlings install d2x mcpp -y`,两个工具名都链到各自仓库
 2. 取课程并验证环境 —— 默认 `d2x install d2mcpp` → `cd d2mcpp` → `mcpp test`;
 clone 源码那条路收进 <details>,作为可选项而不是与默认路径并列的「二选一」
 3. 开始练习 —— `d2x checker` / `d2x status`
第 2 步把 `mcpp test` 摆到台面上是有意的:练习就是测试,新环境跑一遍
「全部不通过」既是练习的起点,也已经证明工具链是通的。
CI 从单个 ubuntu job 拆成五档平台矩阵,每档都跑完整两层验证:
 linux / macos / windows-10 线(windows-2022)/ windows-11 线(windows-2025)
 / windows 且无 MSVC STL
最后一档把 runner 上的 Visual Studio 藏掉(改名 vswhere.exe 与 VC 目录 +
清空 VS* 环境变量,并就地检查后置条件),模拟学习者的干净 Windows —— 这
才是多数人的机器。mcpp 应当自动回落到自带的 winlibs MinGW,产物 target
目录名(x86_64-windows-gnu)就是断言依据。
两层验证:
 - `mcpp test`(已有 e2e.sh)—— pristine 全不过 + 覆盖答案后全过
 - `d2x checker`(新增 checker-e2e.sh)—— 答案就位后 checker 必须自己走完
 52 道题并退 0
加第二层是因为 checker 在 mcpp test 之上还叠了 Provider 的 NDJSON 协议、
进度持久化、文件监听三层;这三层断掉时 mcpp test 照样全绿,Windows 上就
出过这种静默回归(#87)。checker-e2e.sh 的看门狗自己用 shell 轮询实现,
不依赖 timeout(1)(macOS 默认没有)。
顺带:
- .xlings.json pin 上抬 —— mcpp 2026年8月1日.1 → 2026年8月2日.1(裸 Windows 自动
 回落 MinGW 是这个版本才有的能力,无 MSVC STL 那一档依赖它),
 d2x 2026年08月02日.1 → 2026年08月02日.2
- 修复文件名核对 job:它还在按迁移前的布局找 `intro/tests cpp*/tests`,
 练习早已搬进 src/,于是一个文件都没扫到、永远绿。现在真的核对 52 对。
- 工作流触发路径补上 .xlings.json
本地已验:e2e.sh all(zh/en 各 52/52)、checker-e2e.sh zh 与 en 均全过。

chapter_1 是三份 README 的「更多细节」落点,但它的 §0 只装 xlings,
接着就直接 `d2x install d2mcpp` —— 一台干净的机器照着做会在第二条命令
上失败,因为 d2x 这个二进制根本还没装。
补两处,与 README 新的三步保持同一套说法:
- §0 结尾加 `xlings install d2x mcpp -y`,两个工具名链到各自仓库
- §1 加「验证环境」小节:`cd d2mcpp` + `mcpp test`,并说明「刚拿到课程
 时全部未通过」既是起点也是工具链已通的证据

原话把 `mcpp test` 说成「验证每道练习都能编译并运行」,正好说反了:练习发
下来就是没做完的,`std:endl`、`D2X_YOUR_ANSWER` 这类东西**必然编不过**,
pristine 状态下 0 passed 才是对的(e2e.sh 的断言 1 就是在守这条)。
顺带澄清一个容易误会的点:`solutions/` 不是工作区成员(mcpp.toml 的
members 里没有它),`mcpp test` 从头到尾不碰它。要它变绿得先覆盖到练习
文件上——那是 CI 的动作,不是学习者跑一条命令就会发生的事。
改成说清楚它到底验了什么:工具链解析成功、d2x 库编译通过、运行器逐题都
跑到了;练习本身红着是设计如此。README 三语 + book 两语 + chapter_1 两语
共 7 处同步。

在此之前 solutions/ 只是一堆躺在磁盘上的 .cpp:不是工作区成员,mcpp 从头到
尾不认识它。想验证答案对不对,唯一的办法是把 52 个文件覆盖到 src/*/tests/
上、跑一遍、再 git 还原 —— 一套带副作用、要求工作树干净、只有 CI 脚本会用
的流程。学习者或贡献者想确认「答案是好的」,没有一条命令可以跑。
现在 solutions/ 是一个正经工程:
 solutions/mcpp.toml name=solutions, c++23, 依赖 d2x
 solutions/tests/<std>/... 52 份答案,就是它的测试
于是:
 mcpp test -p solutions # 52 passed; 0 failed
 mcpp test -p solutions cpp11 # 按子串筛
零副作用、不碰练习目录、任何人随手可跑。布局与练习一一对应,测试名
(intro/hello-mcpp、cpp11/00-auto-and-decltype/0) 直接对回练习文件。
配置刻意与练习工程一致(c++23 + d2x),否则「答案能过」推不出「答案放进
练习里也能过」。
覆盖-还原那套 e2e 保留 —— 它验的是另一件事:答案放到练习的位置上也成立,
且练习在未完成时确实不通过。两条互补:新的这条挂了说明答案本身是错的,
旧的那条挂了说明答案与练习对不上。
- e2e.sh 新增 solutions_selftest(),并核对测试条数 == 答案文件数:测试发现
 是按 tests/**/*.cpp 自动扫的,布局一改就可能一个都没扫到,而「0 个测试」
 在 mcpp 眼里同样是 "test result ok"
- CI 每档平台新增独立一段 `mcpp test -p solutions`,排在覆盖-还原之前,
 失败定位最短
- e2e.sh / checker-e2e.sh / 文件名核对 job 的路径映射跟随改为 solutions/tests/

上一版让 step 2 跑裸 `mcpp test`,然后解释「全红是对的」。这在逻辑上站不住:
工具链坏掉时也是全红,学习者看着同样的输出,分辨不出是自己还没做题还是环境
没装好——一个只会红的命令没法用来验证环境。
solutions/ 成为工程之后就有了确定的绿:
 mcpp test -p solutions # 验证环境: 52 份参考答案, 应当全绿
 mcpp test # 你的进度表: 练习还没做, 此刻全红
两条命令各自含义明确:第一条绿 = 工具链没问题;第二条红 = 你的起点。
README 三语 + book 两语 + chapter_1 两语同步。chapter_1 里另外写清了答案与
练习靠 tests/ 相对路径配对,以及 `mcpp test -p solutions cpp11` 的筛选用法。
撰稿技能(.agents/skills/d2mcpp-authoring)的路径与「答案怎么验」也跟随更新:
新增答案后可以直接 `mcpp test -p solutions <slug>` 自查,不必再走覆盖流程。

step 2 摆两条命令、再解释「第一条绿第二条红」,等于在验证环境这一步塞了
一个当下用不上的概念。step 2 现在只做一件事:
 mcpp test -p solutions # 验证环境: 52 份参考答案, 应当全绿
裸 `mcpp test`(你自己的进度表)本来就属于「不经过 d2x 怎么练」这一类,
归到 step 3 已有的那条可选 note 里,和 `mcpp test -p src/cpp11` 放一起:
 > 不想经过 d2x? 练习就是测试 —— `mcpp test` 打印你的完整进度表(动手前
 > 全红), `mcpp test -p src/cpp11` 只跑某一章。
同步的地方:
- README 三语 + book 两语:step 2 收敛为一条命令;<details> 里 clone 那条
 路的环境验证也跟着改成 `mcpp test -p solutions`(原来还是裸 mcpp test)
- chapter_1 两语:「验证环境」节同样只留参考答案那条;裸 `mcpp test` 落到
 已有的「原生模式(可选)」节,作为该节三条命令里的第一条