docs: the no-package iOS path is reported, not refused

Author: speak-agent

.agents/docs/2026-09-13-630-what-a-framework-still-hits-in-the-engine.md

@@ -432,15 +432,20 @@ and the row table names none. The alternatives and why they are not taken:
   SDK a machine has. The `llvm@20.1.7` workaround is this alternative done by
   hand, and it holds only until the next SDK.
 
-**What the engine does when no package is declared.** Rule C still binds:
-the runtime is the SDK's, so the headers are the SDK's
+**What the engine does when no package is declared.** The runtime is the
+SDK's. A graph that does not import `std` takes the SDK's headers
 (`-nostdinc++ -isystem <sdk>/usr/include/c++/v1`; clang's Darwin driver
-would otherwise prefer the libc++ installed beside the compiler), and the
-std module is withdrawn: the SDKs ship no module sources (measured above)
-and the engine does not consume one, so a program that imports `std` is
-refused with a message naming the two package lines, and a program that does
-not is unaffected. This is honest where today's default is a coincidence,
-and it is the same `HostCoupled` cell the macOS fallback already occupies.
+would otherwise prefer the libc++ installed beside the compiler): one libc++
+on every line, which Rule C asks for. A graph that imports `std` keeps the
+payload's module and headers over the SDK's dylib, which is what every iOS
+build got before this batch; the SDKs ship no module sources (measured
+above) and the engine does not consume one, so there is no consistent pair
+to switch to. That pairing is reported once as a degradation
+(`target/cxx-runtime`) naming the hazard and the two package lines, and the
+build proceeds. A refusal was written first and withdrawn on review: it
+would have broken a program that built the day before, while the
+degradation names the remedy at the first build and costs nothing until an
+inline path reaches an export the older dylib lacks.
 
 The engine change, in full:
 
@@ -466,10 +471,12 @@ The engine change, in full:
 5. The std-module adoption at `prepare.cppm:10362` accepts
    `mcpp:c++-abi=libc++` as the current spelling of `hosted-standard-library`
    and continues to accept the older one.
-6. On an Apple cross target without a graph C++ runtime: the compile side
-   emits `-nostdinc++ -isystem <sdk>/usr/include/c++/v1`; `hasImportStd`
-   is false, and a graph that imports `std` is refused with the message
-   naming `llvm.libcxx` and `llvm.compiler-rt-builtins`.
+6. On an Apple cross target without a graph C++ runtime: when the graph
+   does not import `std`, `Toolchain::appleSdkCxxHeaders` is set and the
+   compile side emits `-nostdinc++ -isystem <sdk>/usr/include/c++/v1`; when
+   it does, the payload's module stays and prepare reports the
+   `target/cxx-runtime` degradation naming `llvm.libcxx` and
+   `llvm.compiler-rt-builtins`.
 7. The builtins archive. Clang's Darwin driver adds
    `libclang_rt.<platform>.a` from its own resource directory and, when the
    file is absent, continues without it (its source says missing runtime
@@ -515,10 +522,10 @@ the engine's part is measured first:
   carries `-nostdlib++` and no `-lc++`.
 - `aarch64-macos` with a floor: command lines unchanged from today, byte for
   byte (the `SelfContained` row must not move).
-- `aarch64-ios-sim` without the declaration: the compile command carries
-  `-isystem <sdk>/usr/include/c++/v1` and no payload `-isystem`; a program
-  that does not import `std` links `-lc++` and runs; one that does is refused
-  with the message naming `llvm.libcxx`.
+- `aarch64-ios-sim` without the declaration: a program that does not import
+  `std` carries `-isystem <sdk>/usr/include/c++/v1` and no payload
+  `-isystem`, links `-lc++` and prints no `target/cxx-runtime` line; one that
+  does still builds and the degradation names `llvm.libcxx`.
 - Builtins: `aarch64-ios-sim` with `llvm.compiler-rt-builtins` declared and
   a program whose source contains `if (__builtin_available(iOS 17, *))`
   links and runs; without the declaration the same program fails at link

docs/20-toolchains.md

@@ -690,13 +690,16 @@ and the artifact's load commands name no `libc++.1.dylib`: the headers a
 translation unit is compiled against, the module it imports and the objects it
 links are one release by construction.
 
-Without the first declaration the runtime is the SDK's libc++, so the headers
-are the SDK's too (`-nostdinc++ -isystem <sdk>/usr/include/c++/v1`), and
-`import std` is refused with a message naming the package: the SDK ships no
-module sources, and the payload's describe a different libc++. A program that
-does not import `std` builds and links `-lc++`. Without the second, prepare
-reports once that the payload has no compiler runtime for the platform; a
-program that never reaches an availability check links regardless.
+Without the first declaration the runtime is the SDK's libc++. A program that
+does not import `std` then takes the SDK's headers too
+(`-nostdinc++ -isystem <sdk>/usr/include/c++/v1`) and links `-lc++`. A program
+that imports `std` keeps the payload's module and headers over the SDK's
+dylib, as every iOS build did before this release; the two are different
+releases of libc++, and prepare reports the pairing once, naming the two lines
+above, because it links until an inline path in the newer headers names an
+export the older dylib lacks. Without the second declaration, prepare reports
+once that the payload has no compiler runtime for the platform; a program that
+never reaches an availability check links regardless.
 
 ### The deployment target
 

docs/zh/20-toolchains.md

@@ -622,11 +622,12 @@ llvm.compiler-rt-builtins = "22.1.8.3"   # __isPlatformVersionAtLeast 与通用
 产物的加载命令不含 `libc++.1.dylib`:翻译单元编译所用的头、导入的模块与链接的目标文件按构造
 是同一个发布版本。
 
-不声明第一行时,运行时是 SDK 的 libc++,头文件因此也取 SDK 的
-(`-nostdinc++ -isystem <sdk>/usr/include/c++/v1`),`import std` 被拒绝并在消息里点名该包:
-SDK 不附带模块源,而载荷的模块源描述的是另一个 libc++。不导入 `std` 的程序照常构建并链接
-`-lc++`。不声明第二行时,prepare 报告一次「载荷没有这个平台的编译器运行时」;从不触及可用性
-检查的程序照常链接。
+不声明第一行时,运行时是 SDK 的 libc++。不导入 `std` 的程序随之取 SDK 的头文件
+(`-nostdinc++ -isystem <sdk>/usr/include/c++/v1`)并链接 `-lc++`。导入 `std` 的程序仍用载荷的
+模块与头文件配 SDK 的 dylib,与此版本之前每一次 iOS 构建相同;二者是 libc++ 的两个发布版本,
+prepare 报告一次这对搭配并点名上面两行,因为它只在较新头文件里的内联路径没有引用旧 dylib 缺失的
+导出时才能链接。不声明第二行时,prepare 报告一次「载荷没有这个平台的编译器运行时」;从不触及
+可用性检查的程序照常链接。
 
 ### 部署目标