2026.11.2.3: openkal-platform 0.21.1; a silent download source is left for the next; design 2026-11-02 part 3 landed

.agents/docs/2026-11-02-ecosystem-part3-ok-image-performance-parity-design.md

@@ -601,6 +601,7 @@ mcpp 在首次初始化时已把 Ninja 装进自己的 home（`ensure_ninja`，`
 | openkal-macos 0.19 | 文件映射在可执行内存可用时声明；处理器时间取自 `proc_pid_rusage`；`kal_alloc` 同 Linux。启动程序保持 `fork`：`vfork` 在 CI 的 macOS 上以 SIGSYS 结束子进程 |
 | openkal-windows 0.17 | 回答 `kal_err_not_supported`，不声明该位：保留区中拆出的部分只有在整个保留以占位方式建立时才能换成文件视图，区域会成为需逐个释放的片段表（7.1）。加载器照旧复制 |
 | openkal-image 0.3 | okld 从文件映射满足四个条件的段：不可写、文件大小等于内存大小、文件偏移与地址模 64 KiB 同余、独占所在粒度；其余段复制。每个重定位只写入可写段。okrun 在映像运行期间保持文件打开 |
+| openkal-image 0.3.1（openkal-platform 0.21.1） | 记住的 okb 准入不再读取成员：okrun 对此前在同一文件上比对过的成员只按形状准入（`okld_okb_admit_layout`）。0.2、0.3 在此计算归档声明的 CRC-32，每次启动遍历整个成员，clangd 的 71 MB 映像约 0.1 s 处理器时间；warm-prime 冷阶段启动 176 个 worker，CI 上映像因此为原生的 2.4–3.5 倍（本地以 `.oke` 测量，不经过 okb，未显现） |
 
 §5.2 的单元按 worker 建立：每个 worker 以 `kal_process_job_enter` 形成自己的单元，以 `kal_process_job_limit` 的内存限额取代
 `RLIMIT_AS`（openkal 不陈述地址空间上限）；worker 组的预算仍按 `kal_process_props` 的回答选择。
@@ -639,15 +640,32 @@ mcpp 在首次初始化时已把 Ninja 装进自己的 home（`ensure_ninja`，`
 | 0040 | 自有缓存中的模块在其发布处、凭自身的租约读取，不再为每个读者复制 |
 | 0041 | worker 结束即被看到：所有者监视以条件变量等待，worker 退出时通知；父进程查看运行中的 worker 前 50 次间隔 1 ms，此后 10 ms。冷阶段 176 个模块的就绪由 4.9 s 降为 3.4 s，worker 的中位时长由 20 ms 降为 9 ms |
 | okgen | 工具链文件变化时删除 `CMakeCache.txt` 与 `CMakeFiles` 后重新配置 |
+| worker 的上限（0042） | 每个 worker 的地址空间份额，在系统能为进程设上限的地方由 worker 自设（`RLIMIT_AS`），在 macOS 上由 clangd 监视 worker 的物理占用（`proc_pid_rusage` 的 `ri_phys_footprint`），超过份额即结束它。macOS 的进程在 main 之前已映射数百 GiB（macOS 15 上 392 GiB）：低于此值的上限被拒绝（EINVAL），原生引擎的每个 worker 因此失败；高于此值的上限不约束任何分配（上限比已映射量高 1 GiB 时，2 GiB 的分配仍成功） |
+| 已删除名字的目录 | APFS 对名字已删除、仍打开的目录报告原有的名字数（2），文件则为 0；macOS 上目录只有一个名字，删除它即无名字 |
+| 一个根只打开一次 | 一个根的前几个模块同时构建，各自测定根目录并打开其账本时，macOS 上其中一个因 ENOENT 失败；现由其中一个测定并打开，其余等待并取用其结果 |
 
 ### 17.4 验收的形态与结果
 
 - **warm-prime 的工作区**（§9.4）：由 ux-mcpp 的 `mcpp emit build-database` 生成，304 个单元、176 个模块（另有 std）。处理器时间
   与缺页在 Linux 上取 `/proc/<pid>/stat` 的 `utime`、`stime`、`cutime`、`cstime` 与对应的缺页字段，其他系统为引擎自身的时间
   加 worker 日志中各 worker 的时间。门禁在 Linux 与 macOS（两个引擎都走自有缓存与 worker）；Windows 原生走可移植路径，只记录。
 - **L3（Linux x64）**：映像对原生，冷阶段就绪 1.04、CPU 1.08、缺页 1.12；已有缓存的阶段 1.04、1.09、1.12。
-- **L2**：Linux x64 的 hosted 与映像全部 ≤ 1.15。CI 的映像对比交替运行两侧各五次、逐行取最小值：同一侧连续运行时，共享
-  机器的一段干扰只落在一侧（macOS arm64 的 options/command 一次为 1.22，重跑为 0.85）。
+- **L2**：CI 的映像对比交替运行两侧各五次、逐行取最小值：同一侧连续运行时，共享机器的一段干扰只落在一侧（macOS arm64 的
+  options/command 一次为 1.22，重跑为 0.85）。系统一侧以 `clang++` 编译（门禁）并以系统默认的 `c++` 编译（报告）：两侧的编译器
+  相同时，比值只反映运行时。Linux arm64 的 index/symbol 以 GCC 与 libstdc++ 为 220 ns，以 Clang 与同一个 libstdc++ 为 261 ns，
+  hosted 与映像均为 237 ns；比值 1.15–1.18 来自编译器而不是运行时。openkal-llvm-runtime 0.17.1 的 main CI（mcpp 2026.11.2.2），
+  映像对系统的运行时（门禁一侧；括号内为对系统默认编译器的报告值）：
+
+  | 工作负载 | Linux x64 | Linux arm64 | macOS arm64 | Linux x64 hosted |
+  |---|---|---|---|---|
+  | options/command | 0.80（0.82） | 0.92（1.00） | 0.78（0.98） | 0.78（0.80） |
+  | stringmap/element | 0.70（0.70） | 0.66（0.67） | 0.89（1.07） | 0.64（0.65） |
+  | densemap/element | 1.00（0.98） | 0.98（0.90） | 0.86（0.92） | 0.98（0.96） |
+  | bitstream/field | 0.97（0.95） | 1.03（1.06） | 0.74（0.76） | 0.98（0.95） |
+  | index/symbol | 0.86（0.91） | 0.96（1.18） | 1.00（1.12） | 0.83（0.86） |
+
+  macOS 上 `c++` 与 `clang++` 同为 Apple Clang，两列是同一个编译器的两次构建，其差（options/command 0.78 与 0.98）是共享机器
+  上交替运行之后仍余下的波动。Windows 没有系统的 C++ 编译器，只记录映像的数值。
 - **L1（报告）**：Linux x64，对 glibc。hosted（GCC 编译）69 行中 5 行超过 1.15：线程私有数据 1.20、stat 1.16、clock 1.21（多一层
   openkal 调用，约 2 ns）、4 线程的 open-close 1.16、memcmp/64/7 1.19。映像（Clang 编译）16 行超过，集中在字符串函数
   （memchr/4096 1.46、memcpy/4096 1.34、strcmp/64 1.29），另有 clock、stat 与线程私有数据；同一份源码以 Clang 编成 hosted 时为

CHANGELOG.md

@@ -4,6 +4,47 @@
 > Each `## [<version>]` section is that release's notes. Entries are written in English
 > from 2026.9.28.3 on; earlier entries remain as written.
 
+## [2026.11.2.3] - 2026-11-02
+
+The built-in openkal platform is 0.21.1; a download source that sends nothing
+is left for the next one; a requirement a layer decides is checked; design
+2026-11-02 part 3 landed.
+
+### Changed
+
+- **The built-in `<arch>-openkal` platform is `mcpplibs.openkal-platform@0.21.1`**
+  (docs/35): openkal-image 0.3.1, whose runner admits an okb member it has
+  compared before, on the same file, by its shape alone. 0.3.0 computed the
+  member's CRC-32 on every start: 0.1 s of processor time for a 71 MB image,
+  paid by each program an okb starts (a language server's 176 module workers
+  in a cold build).
+
+### Fixed
+
+- **A requirement a layer decides is checked** (docs/22, docs/specs/target-side.md
+  §2.2). `[target.'cfg(all(windows, compiler = "llvm"))'] requires =
+  ["mcpp:compiler-runtime=compiler-rt"]` names a layer in its selector, and
+  such a table's requirement was dropped without a word: the requirements were
+  gathered before any layer resolved. It is now checked once the layers are
+  resolved and before anything is compiled, with the refusal a `[package]`
+  requirement gets. openkal-musl 0.27.0 states this one: on PE under clang its
+  link names no runtime, and a graph without compiler-rt (openkal-llvm-runtime)
+  reached the link with `___chkstk_ms` undefined.
+- **A download source that connects and sends nothing no longer stops the
+  install** (docs/specs/home-initialization.md §5). xlings leaves such a source
+  after 30 seconds without a byte and tries the next; mcpp stopped the install
+  after 30 seconds without a byte or a new source, so the next source was never
+  reached (CI, 2026-11-02: a GitHub proxy that accepted the connection,
+  attempt 1). mcpp's own bound is now 45 seconds; a source's bounds, 8 seconds
+  to connect and 30 without a byte, are unchanged.
+
+### Design
+
+- Design 2026-11-02 part 3 (ok image performance parity) landed: the engine's
+  revisions measured on macOS (a worker's ceiling watched, an open directory's
+  count of names on APFS, one opening of a cache root), L2 on every system and
+  L3 on every system.
+
 ## [2026.11.2.2] - 2026-11-02
 
 The built-in openkal platform is 0.21.0; an embedded dependency's link

docs/04-mcpp-toml.md

@@ -1502,7 +1502,7 @@ the platform's own key names ([35 — Platforms](35-platforms.md)):
 
 ```toml
 [target.'cfg(os = "openkal")']
-platform = "openkal-platform@0.21.0"          # or { path = "…" }, or "none"
+platform = "openkal-platform@0.21.1"          # or { path = "…" }, or "none"
 
 [target.'cfg(platform = "openkal")'.layers]
 c-abi = { path = "../openkal-musl" }

docs/10-pack-and-release.md

@@ -952,7 +952,7 @@ and sha256. A provided format, `--merge` and `mcpp emit xpkg` read it
 ([SPEC-014](specs/packaging.md) §4.5):
 
 ```json
-{"schema": 1, "name": "hello", "version": "0.1.0", "platform": "openkal-platform@0.21.0",
+{"schema": 1, "name": "hello", "version": "0.1.0", "platform": "openkal-platform@0.21.1",
  "linkage": "shared", "mode": "vendored", "legs": ["x86_64-openkal", "aarch64-openkal"], "systems": [],
  "launch": {"runner": ["okrun", "{}"], "entry": {"x86_64": "lib/x86_64/hello.oke", "aarch64": "lib/aarch64/hello.oke"}},
  "files": [{"path": "lib/x86_64/hello.oke", "role": "image", "leg": "x86_64-openkal", "sha256": "…"}]}

docs/22-target-side.md

@@ -343,6 +343,16 @@ An engine older than 2026.10.26.1 refuses the table form; a package that uses it
 states the floor (`[build-dependencies.mcpp] version = ">= 2026.10.26.1"`, or
 `mcpp = ">= 2026.10.26.1"` in an index descriptor).
 
+A selector may name a layer, and the requirement then holds where that layer
+resolved as named. It is checked once the layers are resolved and before
+anything is compiled (mcpp 2026.11.2.3; an older engine does not check it):
+
+```toml
+# the compiler's runtime on PE under clang is the graph's (openkal-musl)
+[target.'cfg(all(windows, compiler = "llvm"))']
+requires = ["mcpp:compiler-runtime=compiler-rt"]
+```
+
 ### One C++ runtime per process (mcpp 2026.10.26.1+)
 
 Two Itanium C++ runtimes — libstdc++, and libc++ with libc++abi — define the

docs/24-openkal-cross.md

@@ -111,7 +111,7 @@ practice.
 
 ```toml
 [target.'cfg(any(linux, macos, windows))']
-platform = "openkal-platform@0.21.0"
+platform = "openkal-platform@0.21.1"
 ```
 
 One table (2026.10.27.1+). It selects the openkal platform for the host triples,

docs/35-platforms.md

@@ -113,9 +113,9 @@ The first of these that answers selects the target's platform:
 
 | Source | Spelling |
 |---|---|
-| the command line | `--platform openkal-platform@0.21.0`, `--platform path:../openkal-platform`, `--platform none` |
+| the command line | `--platform openkal-platform@0.21.1`, `--platform path:../openkal-platform`, `--platform none` |
 | the environment | `MCPP_TARGET_X86_64_OPENKAL_PLATFORM=…` |
-| the project | `[target.<selector>] platform = "openkal-platform@0.21.0"`, or `{ path = "…" }` |
+| the project | `[target.<selector>] platform = "openkal-platform@0.21.1"`, or `{ path = "…" }` |
 | this machine | the same key in `~/.mcpp/config.toml` |
 | the target table | the platform column (`mcpp toolchain list`) |
 
@@ -129,7 +129,7 @@ its own conventions. `[host] platform` selects a platform for them instead:
 
 ```toml
 [host]
-platform = "openkal-platform@0.21.0"
+platform = "openkal-platform@0.21.1"
 ```
 
 ```
@@ -151,7 +151,7 @@ implementation:
 
 ```toml
 [target.'cfg(any(linux, macos, windows))']
-platform = "openkal-platform@0.21.0"
+platform = "openkal-platform@0.21.1"
 ```
 
 On Windows the arrangement is the GNU ABI's row (`--target x86_64-windows-gnu`);

docs/50-machine-output.md

@@ -527,7 +527,7 @@ installation, which is located on the machine rather than installed by mcpp. A
 target row is `{target, note, toolchain, pin, status, default}`, and `status` is
 one of `installed` / `available` / `via dependency graph` / `planned`.
 A target row also carries `platform` (2026.10.27.1+): the platform package the
-target table selects for it (`mcpplibs.openkal-platform@0.21.0`), or `null`.
+target table selects for it (`mcpplibs.openkal-platform@0.21.1`), or `null`.
 
 **`toolchain` and `pin` are not the same field twice.** `toolchain` is what
 the row is associated with — the installed payload on an installed row, the

docs/specs/home-initialization.md

@@ -87,8 +87,9 @@ mirror 更改只写本地配置。配置读取、本地初始化、能力获取
 状态查询要求 `read_only_queries` 能力；缺失时**必须**跳过查询，继续本地诊断，
 **禁止**为了诊断安装替代提供者。
 
-下载连接上限 8 秒、无字节进展上限 30 秒；已有更短限制保留。
-heartbeat 或重复字节值**禁止**更新下载进展时间。小型索引请求保留 120 秒总保护，
+下载的每个来源连接上限 8 秒、无字节进展上限 30 秒，由提供者执行，超出即换下一个来源；已有更短限制保留。
+父进程在一个文件既无新字节也无新来源 45 秒时终止安装：这一上限**必须**长于来源的上限，否则连上而不发送
+字节的来源会在提供者换源的同一时刻终止安装。heartbeat 或重复字节值**禁止**更新下载进展时间。小型索引请求保留 120 秒总保护，
 大型安装保留 3 小时最终进程保护。实际下载源和候选重试次数来自提供者事件，
 **禁止**将探测成功的候选伪报为实际下载来源。
 

docs/specs/packaging.md

@@ -237,7 +237,7 @@ openkal 目标上 `static` 为一个 `.oke`、无 `.okso`,`shared` 为 `.oke` 
   "schema": 1,
   "name": "hello",
   "version": "0.1.0",
-  "platform": "openkal-platform@0.21.0",
+  "platform": "openkal-platform@0.21.1",
   "linkage": "declared",
   "mode": "vendored",
   "legs": ["x86_64-openkal", "aarch64-openkal"],

docs/specs/target-side.md

@@ -80,7 +80,9 @@ mcpp:<层名>[=<实现名>]
 清单**必须**以 `requires-private-layer` 报错 —— 一个映像中的第二个 C 库不是孤岛,而是两个 C 库。
 
 `requires` **可以**写在 `[target.<选择器>]` 下。生效的需求是 `[package] requires` 与所有匹配
-选择器的 `requires` 的并集,合并规则与 `requires_abi` 相同。
+选择器的 `requires` 的并集,合并规则与 `requires_abi` 相同。选择器引用层(`compiler`、
+`compiler-runtime`、`kernel-abi`、`c-abi`、`c++-abi`)时,需求**必须**在层解析之后、任何编译开始
+之前按规则二检查;引擎**禁止**忽略这样的需求。
 
 ### 2.3 标准库模块源 已实现
 
@@ -335,4 +337,5 @@ mcpp:<层名>[=<实现名>]
 | v1.0 | 2026-08-24 | 初版。五层闭集、`provides`/`requires` 语法、三条规则、报告与兼容性条款。 |
 | v1.1 | 2026-09-26 | 规则三增补:`c-abi` 来自图时,链接不搜索宿主库目录(ELF 已实现,mcpp#696)。 |
 | v1.3 | 2026-10-26 | 随 mcpp 2026.10.26.1:§2.2 增加 `requires` 的对象形式与 `visibility`、`[target.<选择器>] requires`;新增 §7 一个进程一套 C++ 运行时(U/I/H、孤岛条件、外来运行时按类型识别、依赖图供给的 libstdc++)(mcpp#838)。 |
+| v1.4 | 2026-11-03 | 随 mcpp 2026.11.2.3:§2.2 选择器引用层的 `requires` 在层解析之后检查(此前未检查即被丢弃)。 |
 | v1.2 | 2026-10-23 | 随 mcpp 2026.10.24.1:§1.3 `prebuilt` 放宽为被点名、按内容识别的预制目录;§2.4 改为由测量回答、`provides` 声明或核对,标为已实现;规则一增加基座是一个供给者与 c-abi 独占律;规则二增加基座上的编译器运行库与可测量的下限;规则三增加可叠加层;新增 §6 目标侧执行(组合、运行器契约、物理边界)。 |

docs/zh/04-mcpp-toml.md

@@ -1384,7 +1384,7 @@ runner 与 `run_under`。
 
 ```toml
 [target.'cfg(os = "openkal")']
-platform = "openkal-platform@0.21.0"          # or { path = "…" }, or "none"
+platform = "openkal-platform@0.21.1"          # or { path = "…" }, or "none"
 
 [target.'cfg(platform = "openkal")'.layers]
 c-abi = { path = "../openkal-musl" }

docs/zh/10-pack-and-release.md

@@ -799,7 +799,7 @@ Authenticode 可以签名它。Linux 与 macOS 经 shell 启动它：`sh pg-0.1.
 提供的格式、`--merge` 与 `mcpp emit xpkg` 读取它（[SPEC-014](../specs/packaging.md) §4.5）：
 
 ```json
-{"schema": 1, "name": "hello", "version": "0.1.0", "platform": "openkal-platform@0.21.0",
+{"schema": 1, "name": "hello", "version": "0.1.0", "platform": "openkal-platform@0.21.1",
  "linkage": "shared", "mode": "vendored", "legs": ["x86_64-openkal", "aarch64-openkal"], "systems": [],
  "launch": {"runner": ["okrun", "{}"], "entry": {"x86_64": "lib/x86_64/hello.oke", "aarch64": "lib/aarch64/hello.oke"}},
  "files": [{"path": "lib/x86_64/hello.oke", "role": "image", "leg": "x86_64-openkal", "sha256": "…"}]}

docs/zh/22-target-side.md

@@ -296,6 +296,15 @@ requires = [{ layer = "mcpp:c++-abi=libstdc++", visibility = "private" }]
 （`[build-dependencies.mcpp] version = ">= 2026.10.26.1"`，或 index 描述文件中的
 `mcpp = ">= 2026.10.26.1"`）。
 
+选择器可以引用层，此时需求在该层解析为所写的实现时成立。它在层解析之后、任何编译开始之前检查
+（mcpp 2026.11.2.3；更早的引擎不检查）：
+
+```toml
+# PE 上 clang 的编译器运行库来自依赖图（openkal-musl）
+[target.'cfg(all(windows, compiler = "llvm"))']
+requires = ["mcpp:compiler-runtime=compiler-rt"]
+```
+
 ### 一个进程一套 C++ 运行时（mcpp 2026.10.26.1+）
 
 两套 Itanium C++ 运行时 —— libstdc++，以及 libc++ 加 libc++abi —— 定义同样的 ABI

docs/zh/24-openkal-cross.md

@@ -93,7 +93,7 @@ SDK，或者区分 `linux`/`windows`/`macos`。那些是 C 环境层或平台层
 
 ```toml
 [target.'cfg(any(linux, macos, windows))']
-platform = "openkal-platform@0.21.0"
+platform = "openkal-platform@0.21.1"
 ```
 
 一张表（2026.10.27.1+）。它为宿主三元组选择 openkal 平台，平台的宿主部分命名编译器与目标侧三个层的包；

docs/zh/35-platforms.md

@@ -98,9 +98,9 @@ C++ 运行时的包同时提供编译器运行时,因此 `"c++-abi" = false` 只
 
 | 来源 | 写法 |
 |---|---|
-| 命令行 | `--platform openkal-platform@0.21.0`、`--platform path:../openkal-platform`、`--platform none` |
+| 命令行 | `--platform openkal-platform@0.21.1`、`--platform path:../openkal-platform`、`--platform none` |
 | 环境变量 | `MCPP_TARGET_X86_64_OPENKAL_PLATFORM=…` |
-| 工程 | `[target.<selector>] platform = "openkal-platform@0.21.0"`,或 `{ path = "…" }` |
+| 工程 | `[target.<selector>] platform = "openkal-platform@0.21.1"`,或 `{ path = "…" }` |
 | 本机 | `~/.mcpp/config.toml` 中的同一个键 |
 | 目标表 | 平台列(`mcpp toolchain list`) |
 
@@ -112,7 +112,7 @@ C++ 运行时的包同时提供编译器运行时,因此 `"c++-abi" = false` 只
 
 ```toml
 [host]
-platform = "openkal-platform@0.21.0"
+platform = "openkal-platform@0.21.1"
 ```
 
 ```
@@ -130,7 +130,7 @@ platform = "openkal-platform@0.21.0"
 
 ```toml
 [target.'cfg(any(linux, macos, windows))']
-platform = "openkal-platform@0.21.0"
+platform = "openkal-platform@0.21.1"
 ```
 
 Windows 上这一安排对应 GNU ABI 的行(`--target x86_64-windows-gnu`);`[platform.hosted] targets` 之外的

docs/zh/50-machine-output.md

@@ -463,7 +463,7 @@ mcpp toolchain list --format json
 的形状是 `{target, note, toolchain, pin, status, default}`，`status` 取
 `installed` / `available` / `via dependency graph` / `planned` 之一。
 目标行另有 `platform`（2026.10.27.1+）：目标表为该目标选择的平台包
-（`mcpplibs.openkal-platform@0.21.0`），或 `null`。
+（`mcpplibs.openkal-platform@0.21.1`），或 `null`。
 
 **`toolchain` 与 `pin` 不是把同一个字段写了两遍。** `toolchain` 表示这一行
 关联到什么 —— 已装的行是装好的载荷，词表行是它自己的约定。`pin` 只承载目标

mcpp.toml

@@ -1,6 +1,6 @@
 [package]
 name        = "mcpp"
-version = "2026.11.2.2"
+version = "2026.11.2.3"
 description = "Modern C++ build & package management tool"
 license     = "Apache-2.0"
 authors     = ["mcpp-community"]