@@ -5,6 +5,39 @@
 
 ## [Unreleased]
 
+## [2026.9.18.2] - 2026-09-18
+
+### 2026.9.18.1 发布几小时内,三个下游仓库的 CI 揭出的三处同形缺陷:声明满足与做不到被当成了一回事
+
+三处缺陷,同一个形状:引擎把「目标默认已经满足这条声明」和「这条声明做不到」当成了同一种
+情况来处理,结果要么拒绝了一个根本不需要拒绝的编译器,要么拒绝了一个其实能实现的目标。
+
+- **GCC 在 Linux 上被拒绝,仅仅因为声明了 `[c-abi]`,即便实现出来的东西是空的。**
+  openkal-musl 0.15.0 在 Linux 上的声明——`presents = "posix", data-model =
+  "arch-default", wchar = 32`——正是 x86_64 Linux 的默认三元组本来就是的样子,实现出来
+  不需要任何令牌。旧的检查顺序是先问「这是不是 Clang」,再算实现——所以只要图里出现
+  `[c-abi]` 就先把非 Clang 编译器拒了,不管实现到底需不需要它做什么。每一个用 GCC 在
+  Linux 上构建 openkal-musl 的用户,因此白白丢了这个包。现在 `cenv::realise` 先跑(它是
+  声明与目标的纯函数,与编译器无关),只有在结果令牌非空时才检查编译器族——Windows 上的
+  Cygwin 式替换仍然是非空的,所以那条路径的拒绝没有变。
+- **macOS 默认并不满足 `presents = "posix"`,校验探针当场抓到了这一点——这正是它存在的
+  意义。** 探针报告:声明 `__unix__` 已定义,实测未定义。Apple 的 clang 默认预定义的是
+  `__APPLE__`/`__MACH__`,从来不是 `__unix__`;最初设计文本假设 macOS 的默认三元组像
+  Linux 一样已经满足,这个假设是错的。
+- **裸机(freestanding)目标对 `presents = "posix"` 一律拒绝,openkal-llvm-runtime 因此
+  在 `riscv64-none-elf` 上还没碰到别的目标就先被挡下来了。**
+
+三处修成一条规则,也是比它取代的那条更简单的表述:实现 `presents = "posix"` 在每个目标上
+陈述的是同一件可观察的事实——`__unix__` 已定义,`_WIN32` 未定义——目标之间的差别只在于
+实现它要花多大代价。Linux:不花代价。macOS 与裸机:定义 `__unix__`,一个令牌。Windows:
+Cygwin 式替换。已知的权衡,留给 mcpp-index 30 个成员的实测去称量:写成
+`#ifdef __unix__ ... #elif defined(__APPLE__)` 的可移植代码,现在在 macOS 上也会走 Unix
+分支。
+(`src/toolchain/cenv.cppm`、`src/build/prepare.cppm`,单测 `test_cenv.cpp`(
+`MacosPosixArchDefaultDefinesUnix`、`FreestandingPosixDefinesUnix`、
+`FreestandingWindowsIsStillRefused`)与 `test_cenv_probe.cpp`(令牌与探针互相印证的一例),
+e2e `tests/e2e/742_gcc_accepted_when_the_realisation_is_empty.sh`,docs/22 及其 zh 镜像)
+
 ## [2026.9.18.1] - 2026-09-18
 
 ### C 库层可以声明它呈现的 C 环境,引擎实现并校验:设计 2026-09-18(2026.9.18.1)
 
@@ -361,11 +361,42 @@ that names no C library:
 | Target | Request | Realisation |
 |---|---|---|
 | Linux | `posix` / `arch-default` | the default triple already satisfies it |
-| macOS | `posix` / `arch-default` | the default triple already satisfies it |
+| macOS | `posix` / `arch-default` | one token, `-D__unix__` — Apple's clang predefines `__APPLE__`/`__MACH__` on its default triple, never `__unix__` |
+| freestanding | `posix` / `arch-default` | the same one token, `-D__unix__`, for the same reason: nothing here defines it either |
 | Windows | `posix` / `arch-default` | Cygwin-flavoured: `--target=x86_64-pc-cygwin` on the compile line only; `__CYGWIN__`/`__CYGWIN32__` are left defined (see the note below); `data-model` becomes LP64 as a consequence of the triple, not a separate flag |
 | any | `builtins = "iso"` | turns off code-generation idioms that assume a platform C library — `-fno-builtin-memset_pattern16` on Apple targets is the one this survey measured; see `src/toolchain/cenv.cppm` for what else was checked and found not to apply |
 | anything else | | refused, naming the target, the request and what is missing — never a silent downgrade |
 
+**The macOS and freestanding rows are a correction, not the design's original
+text (coordinator revision, caught by real builds within a day of
+2026.9.18.1 shipping).** The rule realising `presents = "posix"` follows is:
+the SAME observable fact on every target — `__unix__` defined, `_WIN32`
+not — and targets differ only in what realising it COSTS. The original text
+assumed macOS's default triple already presented it, the way Linux's does;
+the verification probe (below) caught that assumption as false on a real
+build — declared defined, measured undefined — which is precisely the class
+of error that probe exists to catch. The original text also refused a
+freestanding target outright for asking `presents = "posix"` at all, which
+blocked a whole target (`riscv64-none-elf`, openkal-llvm-runtime) rather
+than realising a fact this engine can in fact deliver: a freestanding target
+starts with neither macro defined, exactly like macOS's default triple, so
+the fix costs it the identical token. Known cost, left to the mcpp-index
+30-member measurement to weigh: portable code written
+`#ifdef __unix__ ... #elif defined(__APPLE__)` now takes the Unix branch on
+macOS too, correct only if that branch is written to also be correct there.
+
+**A compiler is refused only when the realisation actually needs a token it
+cannot take — not merely because `[c-abi]` is declared.** `cenv::realise`
+(above) runs first, as a pure function of the declaration and the target;
+the Clang-only requirement is checked second, and only fires when the
+resulting tokens are non-empty. openkal-musl's own declaration on Linux —
+`presents = "posix", data-model = "arch-default", wchar = 32` — realises to
+nothing at all (the first row of the table above), so GCC is accepted there
+and the verification probe confirms it, exactly as it would for any other
+empty realisation. The Windows case is unchanged: the Cygwin-flavoured
+substitution is non-empty, so a non-Clang compiler is still refused there,
+naming what it cannot do.
+
 The Windows row is the flagship case: `x86_64-w64-windows-gnu` and
 `x86_64-pc-cygwin` produce IDENTICAL machine code — same PE format, same
 Win64 calling convention, same SEH — and differ only in what the
 
@@ -298,11 +298,32 @@ libunwind 的 `assembly.h`,正是按这个宏来选寄存器保存集的)。mcpp
 | 目标 | 请求 | 实现 |
 |---|---|---|
 | Linux | `posix` / `arch-default` | 默认三元组已经满足 |
-| macOS | `posix` / `arch-default` | 默认三元组已经满足 |
+| macOS | `posix` / `arch-default` | 一个令牌,`-D__unix__`——Apple 的 clang 默认三元组预定义的是 `__APPLE__`/`__MACH__`,从来不是 `__unix__` |
+| 裸机(freestanding) | `posix` / `arch-default` | 同样一个令牌,`-D__unix__`,原因相同:这里同样没有任何东西定义它 |
 | Windows | `posix` / `arch-default` | 采用 Cygwin 式语义:仅在编译行加 `--target=x86_64-pc-cygwin`;`__CYGWIN__`/`__CYGWIN32__` 保持定义(见下方说明);`data-model` 变为 LP64 是三元组切换的结果,不是另一个开关 |
 | 任意目标 | `builtins = "iso"` | 关闭代码生成阶段假定平台 C 库在场的惯用法识别——本轮实测到的唯一一例是 Apple 目标上的 `-fno-builtin-memset_pattern16`;`src/toolchain/cenv.cppm` 记录了还核实过哪些、结论是不适用 |
 | 其余情况 | | 明确拒绝,点名目标、请求与缺什么——不静默降级 |
 
+**macOS 与裸机这两行是一次修正,不是设计原文(协调者修订,2026.9.18.1 发布不到一天就被真实
+构建抓到)。** 实现 `presents = "posix"` 遵循的规则是:在每一个目标上陈述的是同一件可观察的
+事实——`__unix__` 已定义,`_WIN32` 未定义——目标之间的差别只在于实现它要花多大代价。原文
+假设 macOS 的默认三元组已经像 Linux 一样呈现了它;真实构建上的校验探针把这个假设当场
+抓包为假——声明已定义,实测未定义——这正是那个探针存在的意义所在,不是它的漏洞。原文还
+把裸机目标对 `presents = "posix"` 的任何请求一律拒绝,这挡住了整整一个目标
+(`riscv64-none-elf`,openkal-llvm-runtime),而不是去实现这个引擎其实能给出的事实:裸机
+目标一开始两个宏都没有定义,和 macOS 默认三元组一模一样,所以这处修复付出的是同一个令牌
+的代价。已知的成本,留给 mcpp-index 30 个成员的实测去权衡:写成
+`#ifdef __unix__ ... #elif defined(__APPLE__)` 的可移植代码,现在在 macOS 上也会走 Unix
+分支,只有那条分支本身在 macOS 上也写对了才是对的。
+
+**编译器只在实现真的需要一个它拿不出来的令牌时才被拒绝——不是仅仅因为声明了
+`[c-abi]`。** `cenv::realise`(上文)先跑,是声明与目标的纯函数;只有 Clang 才行的要求
+第二个才检查,且只在结果令牌非空时才触发。openkal-musl 自己在 Linux 上的声明——
+`presents = "posix", data-model = "arch-default", wchar = 32`——实现出来什么都没有(上表
+第一行),所以 GCC 在那里被接受,校验探针照常核实,和任何其他空实现一样。Windows 那一情形
+没有变:Cygwin 式替换是非空的,所以一个非 Clang 编译器在那里仍然被拒绝,并点名它做不到
+什么。
+
 Windows 一行是旗舰情形:`x86_64-w64-windows-gnu` 与 `x86_64-pc-cygwin` 生成的机器码完全一致——
 同样的 PE 格式、同样的 Win64 调用约定、同样的 SEH——差别只在预处理器看到什么、`long` 有多宽。
 因此实现只触及**编译**行;**链接**行保持图解析出的三元组,因为目标文件格式没有变化。
 
@@ -1,6 +1,6 @@
 [package]
 name        = "mcpp"
-version = "2026.9.18.1"
+version = "2026.9.18.2"
 description = "Modern C++ build & package management tool"
 license     = "Apache-2.0"
 authors     = ["mcpp-community"]
 
@@ -31,6 +31,6 @@ import std;
 
 export namespace mcpp {
 
-inline constexpr std::string_view MCPP_VERSION = "2026.9.18.1";
+inline constexpr std::string_view MCPP_VERSION = "2026.9.18.2";
 
 } // namespace mcpp
@@ -10788,21 +10788,29 @@ prepare_build(bool print_fingerprint,
         // below is therefore skipped, and every command line unchanged, for
         // the graph this engine has always built.
         if (tc && resolvedTargetSide.cAbiDecl) {
-            if (!mcpp::toolchain::is_clang(*tc)) {
-                refusal::record(refusal::Code::CEnvUnrealisable);
-                return std::unexpected(std::format(
-                    "the C library ('{}', {}) declares [c-abi], and this "
-                    "build's compiler ('{}') is not one mcpp can realise it "
-                    "through.\n"
-                    "       [c-abi] is realised with Clang-specific "
-                    "mechanisms — a `--target=` substitution and "
-                    "`-f[no-]short-wchar` — so a Clang toolchain is required "
-                    "for this target while a [c-abi] block is in the graph.\n"
-                    "       Select one: [toolchain] default = \"llvm@<version>\", "
-                    "or [target.<triple>] toolchain = \"llvm@<version>\".",
-                    resolvedTargetSide.cAbi.interfaceName,
-                    resolvedTargetSide.cAbi.impl, tc->compiler_family()));
-            }
+            // `cenv::realise` FIRST, THE COMPILER-FAMILY GATE SECOND — not
+            // the other way around (coordinator report, openkal-musl 0.15.0
+            // regression: GCC on Linux refused for a declaration
+            // `presents = "posix", data-model = "arch-default", wchar = 32,
+            // builtins = "iso"` that Linux/x86_64's own default ALREADY
+            // satisfies, needing no substitution at all — a gratuitous
+            // refusal that lost the package for every GCC user on Linux).
+            // `cenv::realise` is a pure function of the declaration and the
+            // TARGET, not of the compiler (`mcpp.toolchain.cenv`'s own
+            // module header) — computing it before asking anything about the
+            // compiler is what lets an EMPTY realisation answer "does this
+            // compiler need to be Clang" correctly: no. The Clang-specific
+            // mechanisms (`--target=` substitution, `-f[no-]short-wchar`,
+            // the `builtins = "iso"` flags) are only needed when realisation
+            // actually produces tokens; when it produces none, the target's
+            // own default already IS the declaration, and any compiler that
+            // can run the verification probe below (`-E -dM`, not a
+            // Clang-specific flag) can be trusted to have gotten there —
+            // which is exactly what that probe then confirms rather than
+            // assumes. The Windows/GCC case is UNCHANGED by this: there the
+            // realisation is non-empty (the Cygwin-flavoured substitution),
+            // and MinGW's `long` is 32-bit regardless of flags (openkal-musl
+            // measured), so the gate below still refuses it.
             auto tt = mcpp::toolchain::triple::parse(tc->targetTriple);
             auto realised = mcpp::toolchain::cenv::realise(
                 *resolvedTargetSide.cAbiDecl, tt ? tt->os : std::string{},
@@ -10811,6 +10819,24 @@ prepare_build(bool print_fingerprint,
                 refusal::record(refusal::Code::CEnvUnrealisable);
                 return std::unexpected(realised.error());
             }
+            if ((!realised->tokens.empty() || !realised->builtinsTokens.empty())
+                && !mcpp::toolchain::is_clang(*tc)) {
+                refusal::record(refusal::Code::CEnvUnrealisable);
+                return std::unexpected(std::format(
+                    "the C library ('{}', {}) declares [c-abi] whose "
+                    "realisation for this target requires Clang-specific "
+                    "substitution, and this build's compiler ('{}') cannot "
+                    "carry it out.\n"
+                    "       [c-abi] is realised, for targets that need "
+                    "anything at all, with Clang-specific mechanisms — a "
+                    "`--target=` substitution and `-f[no-]short-wchar` — so "
+                    "a Clang toolchain is required for this target while "
+                    "this declaration is in the graph.\n"
+                    "       Select one: [toolchain] default = \"llvm@<version>\", "
+                    "or [target.<triple>] toolchain = \"llvm@<version>\".",
+                    resolvedTargetSide.cAbi.interfaceName,
+                    resolvedTargetSide.cAbi.impl, tc->compiler_family()));
+            }
             tc->cEnvTokens          = realised->tokens;
             tc->cEnvBuiltinsTokens  = realised->builtinsTokens;
             tc->cEnvExpectWcharBits = realised->expectWcharBits;