@@ -299,12 +299,23 @@ install/config 形状,而那套形状是按 Linux 写的:
 `tests/all-rules-compile` 是这一轮加的夹具:不点名任何 accelerator(每条规则立刻
 返回,一个字节都不下载),只问六个模块编不编得过。它在第一批运行里抓到:
 
-1. **macOS 14 / 15:`std::println` 不是 header-only。** 它的两个重载都要到 libc++
+1. **macOS 14:`std::println` 不是 header-only。** 它的两个重载都要到 libc++
    **dylib** 里取 `__is_posix_terminal` 与 `__get_ostream_file`,而这两个符号是在
    macOS 14 不带的那一版里加进去的。规则改用 `std::format` 再 stream。
-   **引擎侧还有一半**:`host_link_tokens` 的「信任 cfg」出口提前 return,从不发
-   `-L`/`-rpath` 指向工具链自己的运行时目录,于是 `-lc++` 解析到系统那份而头文件来自
-   载荷。已修,判据 `HostFlags.EveryExitNamesTheToolchainRuntimeDirs`。
+
+   **引擎侧那一半试过了,而显而易见的修法更糟。** 直觉是让
+   `host_link_tokens` 的「信任 cfg」出口也发 `-L<载荷>/lib`,于是 `-lc++` 找到工具链
+   自己那份 —— 而那正是 `dist::mechanism_for` 在 Mach-O 上明确拒绝的
+   ToolchainCoupled:LLVM 的 macOS libc++abi 与 libunwind dylib **向上链接**
+   `/usr/lib/libc++`,系统 libc++ 与工具链的那份同时载入,跨两份释放的对象在 libmalloc
+   里 abort(#202)。CI 报的正是这条路的第一步 —— 链接停在 `__cxa_end_catch` 与其余
+   那些系统 libc++ 会再导出、载荷那份不会的 ABI 符号上。
+
+   **这条是这一轮里唯一一个「我的修复本身被实测推翻」的。** 它被推翻的方式值得记:
+   本地全部单测绿、判据是我自己写的那条正向断言,而**红在一个我没想到会受影响的对象上**
+   —— 图形示例的构建程序,在 macOS 15 上。改回去,把不对称与它的理由写进代码,并把判据
+   改成陈述这条决定(`OnlyTheSpelledOutExitNamesTheToolchainRuntimeDirs`)。
+   **限制照实写下来:macOS 14 上构建程序不能用 `std::print` / `std::println`。**
 2. **Windows:`popen` 拼作 `_popen`。** `rules-spirv` 的宿主模块在那里编译失败。
 3. **Windows:版本约束里的 `>` 被 cmd.exe 读成重定向。** mcpp 把供给请求作为 JSON
    参数放在 shell 命令行上;`shell::quote` 回答的是子进程的 argv 解析(`\"`),而
 
@@ -13,17 +13,30 @@
 真跑一遍,暴露了两处引擎缺陷 —— 两处的共同形状是:一段代码的正确性依赖于宿主,而 CI
 只在其中一个宿主上执行它。
 
-**构建程序的链接不带工具链自己的运行时目录(macOS)。** `host_link_tokens` 的
-「信任 cfg」出口提前 return,跳过了给 `Toolchain::linkRuntimeDirs` 发 `-L` 与
-`-rpath` 的那一段。信任 cfg 决定的是**链哪些运行时**,它从来没有决定**去哪里找**:
-macOS 上 `-lc++` 于是经 SDK 解析到系统那份,而头文件来自载荷。两者在头文件引用了系统
-库还没导出的符号那一刻分道扬镳 —— macos-14 上编译一个只有 `import std` 的构建程序:
+**macOS 14 上构建程序用不了 `std::println`,而显而易见的修法更糟(已记录,未修)。**
+`host_link_tokens` 的「信任 cfg」出口不给 `Toolchain::linkRuntimeDirs` 发 `-L`,于是
+macOS 上 `-lc++` 经 SDK 解析到**系统**那份,而头文件来自载荷。macos-14 上编译一个只有
+`import std` 的构建程序:
 
     ld64.lld: error: undefined symbol: std::__1::__is_posix_terminal(__sFILE*)
 
 `std::print` 不是 header-only 的,它的两个重载都要到 libc++ **dylib** 里取支持符号,
 而那两个符号是在 macOS 14 不带的那一版里加进去的。macOS 15 有,所以这个项目用到的每
-一台 macOS runner 都是绿的。构建程序正是绝对 rpath 该在的地方:它从不被分发。
+一台 macOS runner 都是绿的。
+
+在这一条上加 `-L<载荷>/lib` 试过了,**它买来一个更糟的问题**:那会让 `-lc++` 解析到
+工具链自己的 dylib,也就是 `dist::mechanism_for` 在 Mach-O 上明确拒绝的
+ToolchainCoupled —— LLVM 的 macOS libc++abi 与 libunwind dylib **向上链接**
+`/usr/lib/libc++`,于是系统 libc++ 与工具链的那份同时载入,跨两份释放的对象在
+libmalloc 里 abort(#202)。CI 报的正是这条路的第一步:链接停在 `__cxa_end_catch`
+与其余那些系统 libc++ 会再导出、而载荷那份不会的 ABI 符号上。
+
+所以这个宿主上的 C++ 运行时就是系统那一份,而下限由分发契约选的**静态 libc++** 变成
+真的 —— 那是产物的机制,不属于一个 mcpp 编译、就地跑一次、然后丢掉的辅助程序。
+**限制照实写下来:macOS 14 上构建程序不能用 `std::print` / `std::println`。**
+`std::format` 是 header-only 的,没有这个问题;本轮 mcpp:plugins 的六个模块因此全部
+改用它。判据 `HostFlags.OnlyTheSpelledOutExitNamesTheToolchainRuntimeDirs` 把这条
+不对称写成了一条会跑的断言。
 
 **版本约束里的 `>` 被 cmd.exe 读成重定向(Windows)。** mcpp 把供给请求作为 JSON 参数
 放在 shell 命令行上;`shell::quote` 回答的是子进程的 argv 解析(`\"`),而 cmd 不认这
 
@@ -775,11 +775,7 @@ std::expected<void, std::string> run_build_program(
     compilerIdentity += "\nbuild-program-link=";
     compilerIdentity += muslStaticHelper  ? "musl-static-v1"
                       : mingwStaticHelper ? "mingw-static-v1"
-                                          : "default-v3";   // v2: DT_RPATH on Linux
-                                                            // v3: + the same on
-                                                            //     macOS/Windows,
-                                                            //     where the cfg
-                                                            //     path skipped it
+                                          : "default-v2";   // v2: DT_RPATH on Linux
     std::string programHash  = mcpp::toolchain::hash_file(src);
     std::string compilerHash = mcpp::toolchain::hash_string(compilerIdentity);
 
 
@@ -359,37 +359,42 @@ std::vector<std::string> host_link_tokens(const Toolchain& tc,
         // lld ships with the very toolchain doing the compile, so it cannot
         // be diverted to a libc++ it was not built against.
         if constexpr (mcpp::platform::is_macos) out.push_back("-fuse-ld=lld");
-        // AND THE RUNTIME DIRECTORIES, WHICH THIS PATH USED TO SKIP.
+        // AND DELIBERATELY NOT THE TOOLCHAIN'S RUNTIME DIRECTORIES. THIS WAS
+        // TRIED, AND WHAT IT COSTS IS RECORDED HERE RATHER THAN REDISCOVERED.
         //
-        // Trusting clang's cfg decides WHICH runtimes are linked. It does not
-        // decide WHERE they are found, and on macOS `-lc++` resolves through
-        // the SDK to /usr/lib/libc++.tbd -- the system copy, whose version
-        // floats with the host OS -- while the headers come from the payload.
-        // The two disagree the moment the headers reference a symbol the
-        // system library does not export yet:
+        // The motivation is real. Trusting the cfg decides WHICH runtimes are
+        // linked and never decides WHERE they are found, so on macOS `-lc++`
+        // resolves through the SDK to /usr/lib/libc++.tbd -- the system copy,
+        // whose version floats with the host OS -- while the headers come from
+        // the payload. On macOS 14 those two disagree, measured on a build
+        // program that does nothing but `import std`:
         //
         //   ld64.lld: error: undefined symbol:
         //       std::__1::__is_posix_terminal(__sFILE*)
         //   >>> referenced by std::__1::__print::__is_terminal(__sFILE*)
         //
-        // measured on macos-14 compiling a build program that does nothing but
-        // `import std`. `std::print` is not header-only: its FILE* and ostream
-        // overloads call into the libc++ dylib, and those two support symbols
-        // arrived in a version macOS 14 does not ship. macOS 15's copy has
-        // them, which is why every macOS runner this project uses was green.
+        // `std::print` is not header-only; that support symbol arrived in a
+        // libc++ macOS 14 does not ship, and macOS 15's copy has it, which is
+        // why every macOS runner this project uses was green.
         //
-        // The payload ships its own `lib/libc++.1.0.dylib` -- the toolchain's
-        // own copy, matching its own headers -- and `linkRuntimeDirs` already
-        // names that directory. Emitting `-L` and `-rpath` for it is what the
-        // Linux path has always done here; it was skipped on macOS only
-        // because this branch returned first.
+        // ADDING `-L<payload>/lib` HERE FIXES THAT AND BUYS A WORSE PROBLEM.
+        // It makes `-lc++` resolve to the toolchain's own dylib, which is the
+        // ToolchainCoupled contract that `dist::mechanism_for` REFUSES on
+        // Mach-O for a measured reason: LLVM's macOS libc++abi and libunwind
+        // dylibs upward-link /usr/lib/libc++, so the system libc++ loads
+        // alongside the toolchain's and an object freed across the two aborts
+        // in libmalloc (#202). The first step of that path is what CI reported
+        // when this was tried -- the link stopped on `__cxa_end_catch`,
+        // `std::runtime_error::~runtime_error()` and the rest of the ABI
+        // surface the system libc++ re-exports and the payload's does not.
         //
-        // A BUILD PROGRAM IS THE RIGHT PLACE FOR AN ABSOLUTE RPATH. It is
-        // never distributed: mcpp compiles it, runs it on this machine, and
-        // caches it against this toolchain's identity. The equivalent question
-        // for an ARTIFACT is decided by the distribution contract, and is not
-        // this function's to answer.
-        append_runtime_lib_dirs(tc, opt, esc, out);
+        // So the C++ runtime on this host is the system one, and the
+        // deployment floor is made real by the STATIC libc++ the distribution
+        // contract selects -- a mechanism that belongs to an artifact and not
+        // to a helper mcpp compiles, runs here, and throws away. The
+        // consequence, stated because it is a real limit: on macOS 14 a build
+        // program cannot use `std::print` or `std::println`. `std::format` is
+        // header-only and has none of this.
         return out;
     }
 
 
@@ -206,29 +206,24 @@ TEST(HostFlags, CfgBypassLinuxOnlyDiffersFromAlwaysOffLinux) {
     }
 }
 
-// ── Every exit of host_link_tokens names the toolchain's runtime dirs ───────
+// ── Which exit of host_link_tokens names the toolchain's runtime dirs ──────
 //
-// THE DEFECT THIS STATES. `host_link_tokens` has two exits: one that spells
-// clang's configuration out and one that trusts the bundled `<driver>.cfg`.
-// The second returned early, before the block that emits `-L` and `-rpath`
-// for `Toolchain::linkRuntimeDirs`. Trusting the cfg decides WHICH runtimes
-// are linked; it never decided WHERE they are found, and on macOS `-lc++`
-// then resolved through the SDK to the system library while the headers came
-// from the payload. Measured on macos-14, compiling a build program that does
-// nothing but `import std`:
+// THE ASYMMETRY IS A DECISION, AND THIS IS WHERE IT IS STATED. The spelled-out
+// exit emits `-L` and `-rpath` for `Toolchain::linkRuntimeDirs`; the
+// cfg-trusting exit does not, and both halves were measured.
 //
-//   ld64.lld: error: undefined symbol: std::__1::__is_posix_terminal(__sFILE*)
+// Emitting them there makes `-lc++` resolve to the toolchain's own dylib on
+// macOS, which is the ToolchainCoupled contract `dist::mechanism_for` refuses
+// on Mach-O: LLVM's macOS libc++abi and libunwind dylibs upward-link
+// /usr/lib/libc++, so a second libc++ loads into the process. The link does not
+// even get that far -- it stops on `__cxa_end_catch` and the rest of the ABI
+// surface the system libc++ re-exports and the payload's does not.
 //
-// -- a symbol `std::print`'s inline machinery references and that release's
-// libc++ does not export. The payload ships its own copy, one directory the
-// early return had dropped.
-//
-// AND WHY THIS TEST CAN RUN ON LINUX. The branch is chosen by the host: with
-// `LinuxOnly`, a Linux build always takes the spelled-out exit, so the exit
-// that had the defect is unreachable from a Linux runner. `CfgBypass::Never`
-// exists to make it reachable -- the defect lived in a branch that only two
-// of the three CI hosts could execute, and a test that could only run there
-// would inherit the same blind spot.
+// AND WHY THIS TEST CAN RUN ON LINUX. The exit is chosen by the host: with
+// `LinuxOnly`, a Linux build always takes the spelled-out one, so the other is
+// unreachable from a Linux runner. `CfgBypass::Never` exists to make it
+// reachable -- a decision that only two of the three CI hosts can execute
+// would otherwise be stated only in prose.
 namespace {
 
 // A directory that looks enough like a clang payload for `resolve_clang_driver`
@@ -255,7 +250,7 @@ bool names_dir(const std::vector<std::string>& tokens, std::string_view dir) {
 
 } // namespace
 
-TEST(HostFlags, EveryExitNamesTheToolchainRuntimeDirs) {
+TEST(HostFlags, OnlyTheSpelledOutExitNamesTheToolchainRuntimeDirs) {
     FakeClangPayload payload{"runtime-dirs"};
     auto tc = tc_for(CompilerId::Clang);
     tc.binaryPath = payload.root / "bin" / "clang++";
@@ -264,21 +259,23 @@ TEST(HostFlags, EveryExitNamesTheToolchainRuntimeDirs) {
     HostFlagOptions opt;
     opt.runtimeLibDirs = true;
 
-    // The cfg-trusting exit -- the one that returned early.
-    opt.cfgBypass = HostFlagOptions::CfgBypass::Never;
-    auto trusting = mcpp::toolchain::host_link_tokens(tc, opt, mcpp::toolchain::no_escape);
-    EXPECT_TRUE(names_dir(trusting, (payload.root / "lib").string()))
-        << "the cfg-trusting exit dropped the toolchain's own runtime directory, "
-           "so `-lc++` resolves to whatever the system has";
-
-    // The spelled-out exit, which always did.
+    // Spelled out: the payload's own runtime directories are named.
     opt.cfgBypass = HostFlagOptions::CfgBypass::Always;
     auto spelled = mcpp::toolchain::host_link_tokens(tc, opt, mcpp::toolchain::no_escape);
     EXPECT_TRUE(names_dir(spelled, (payload.root / "lib").string()));
 
-    // And the option is still an option: nothing is emitted when it is off.
-    opt.runtimeLibDirs = false;
+    // Trusting the cfg: they are NOT, and the comment above says what naming
+    // them costs.
     opt.cfgBypass = HostFlagOptions::CfgBypass::Never;
+    auto trusting = mcpp::toolchain::host_link_tokens(tc, opt, mcpp::toolchain::no_escape);
+    EXPECT_FALSE(names_dir(trusting, (payload.root / "lib").string()))
+        << "the cfg-trusting exit now points `-lc++` at the toolchain's own "
+           "dylib; on Mach-O that link fails on the C++ ABI symbols the system "
+           "libc++ re-exports";
+
+    // And the option is still an option on the exit that honours it.
+    opt.runtimeLibDirs = false;
+    opt.cfgBypass = HostFlagOptions::CfgBypass::Always;
     auto off = mcpp::toolchain::host_link_tokens(tc, opt, mcpp::toolchain::no_escape);
     EXPECT_FALSE(names_dir(off, (payload.root / "lib").string()));
 }