2026.11.5.1: scope build requests and report optional action progress (#888)

Validate complete accelerator requests, bind capabilities in each consumer closure, isolate build-only target layers and add optional action progress with UTF-8 runtime channels. Align bilingual documentation and published platform defaults. The exact head passes full CI and the subsequent ecosystem review.

Author: Sunrisepeak

.agents/docs/2026-11-05-heterogeneous-build-implementation-plan.md

@@ -18,7 +18,7 @@ superseded_by: 2026-09-07-....md  # when status is superseded
 ---
 ```
 
-346 records.
+349 records.
 
 ## By subject
 
@@ -80,6 +80,12 @@ Records that declare one. Everything else is listed by date below.
 - [The island boundary's names: one rule for both lanes, and the check that makes it true](2026-09-08-island-boundary-names.md) — active
 - [Implementation plan: the island boundary's names](2026-09-08-island-boundary-names-implementation-plan.md) — active
 
+### heterogeneous-build
+
+- [异构构建语义与插件边界补充方案（mcpp#885、mcpp#887）](2026-11-05-heterogeneous-build-semantics-and-plugin-boundaries-supplement.md) — active
+- [异构构建补充方案的第二轮调研与实验](2026-11-05-heterogeneous-build-research-and-experiments.md) — active
+- [生态 885 与异构构建补充方案的实现依赖](2026-11-05-heterogeneous-build-implementation-plan.md) — active
+
 ### home
 
 - [首次初始化、home 重定向与网络诊断优化设计](2026-10-19-first-run-home-and-network-design.md) — landed
@@ -161,6 +167,9 @@ Records that declare one. Everything else is listed by date below.
 
 ### 2026-11
 
+- [异构构建语义与插件边界补充方案（mcpp#885、mcpp#887）](2026-11-05-heterogeneous-build-semantics-and-plugin-boundaries-supplement.md) — active
+- [异构构建补充方案的第二轮调研与实验](2026-11-05-heterogeneous-build-research-and-experiments.md) — active
+- [生态 885 与异构构建补充方案的实现依赖](2026-11-05-heterogeneous-build-implementation-plan.md) — active
 - [生态设计 part 4：超越原生——openkal 之上与之下的优化、可观测性与安全](2026-11-03-ecosystem-part4-beyond-native-design.md) — active
 - [生态设计 part 3：ok 映像的性能对等——引擎路径、openkal 运行时与观测](2026-11-02-ecosystem-part3-ok-image-performance-parity-design.md) — active
 ### 2026-10

.agents/docs/2026-11-05-heterogeneous-build-research-and-experiments.md

@@ -4,6 +4,39 @@
 > 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.5.1] - 2026-11-05
+
+### Added
+
+- Build actions can opt into internal stage reporting with `action.progress`
+  (protocol 18). Each execution supplies a separate UTF-8 snapshot path;
+  bounded, ordered snapshots update the build status. Exit codes and output
+  checks still determine success, and completion or cancellation cleans the
+  channel. Existing actions leave reporting disabled.
+
+### Changed
+
+- Both built-in openkal targets select platform 0.23.6. Its final ThinLTO link
+  retains emulated TLS; the group includes musl 0.27.5, runtime 0.18.6 and
+  loader/tools 0.4.4. Explicit platform selections continue to override the
+  built-in default.
+
+### Fixed
+
+- Accelerator requests and constrained source declarations are validated in
+  full. Unclosed sets, trailing text and repeated implementation members are
+  refused; target and implementation ordering share one canonical identity.
+  Published legacy artifact matching remains compatible.
+- Capability requirements and exclusive providers are checked within each
+  consumer's dependency closure. Independent workspace products can use
+  different providers, and applications can supply library requirements.
+  Selected static libraries do not add duplicate consumer contexts; their own
+  programs, shared libraries, tests and standalone selections retain checks.
+  Provider pins accept qualified identities and preserve all link inputs.
+- Build-only providers and requirements no longer select the final artifact's
+  target ABI. Transitive build dependencies remain in the host graph, while
+  packages also used as ordinary dependencies retain their target instances.
+
 ## [2026.11.3.1] - 2026-11-03
 
 The built-in openkal platform is 0.23.3 (openkal 0.23: an image at a base of

.agents/docs/2026-11-05-heterogeneous-build-semantics-and-plugin-boundaries-supplement.md

@@ -190,6 +190,12 @@ resolver binds exactly one provider from the dependency graph. This is how a bui
 one of several interchangeable backends (OpenBLAS / MKL / …) without baking a choice
 into the library.
 
+
+From 2026.11.5.1, requirements bind within each selected consumer's ordinary dependency closure. A library can require a capability supplied by a sibling dependency of its application. Independent workspace products can use different providers; a provider belonging only to another product cannot satisfy a missing requirement. Build-time tool edges are excluded from the target context. Workspace root pins, member pins and `--cap` apply in that order. A short provider name is accepted only when it identifies one candidate; `namespace:name` distinguishes equal short names. Exclusive providers are checked within that same consumer closure, including linked shared libraries. A pin does not remove another provider from the link.
+
+A selected member containing only static-library or entry targets does not add a duplicate binding context when another selected consumer reaches it. Its own executable, shared-library or test targets retain an independent context. Selecting the library alone validates its own dependency closure.
+
+
 ```toml
 # A provider package satisfies a capability for any dependent that requires it.
 [package]
@@ -307,19 +313,12 @@ provides  = ["gpu-blas"]
 exclusive = ["gpu-blas"]
 ```
 
-Two packages that both provide `gpu-blas`, where at least one declares it
+Two packages in one consumer closure that both provide `gpu-blas`, where at least one declares it
 exclusive, are refused when capabilities are bound — before anything is
 compiled, naming the capability and both providers:
 
 ```
-error: capability 'gpu-blas' is provided by more than one package, and they
-       declare it EXCLUSIVE.
-         providers: [compat.cublas, compat.rocblas]
-         exclusive: [compat.cublas, compat.rocblas]
-       Two implementations of one interface define the same symbols, so the
-       link would resolve every call to whichever archive it reached first.
-       Keep one of them — a `[capabilities]` pin selects a provider for a
-       REQUIREMENT and cannot make two definitions of one symbol safe.
+error: capability 'gpu-blas' is EXCLUSIVE in consumer 'app'; providers: [compat.cublas, compat.rocblas]; exclusive: [compat.cublas, compat.rocblas]. A [capabilities] pin selects a provider for a requirement and cannot make two definitions of one symbol safe.
 ```
 
 The refusal reports `exclusive-capability` in `--format json` (chapter 11).

.agents/docs/README.md

@@ -111,7 +111,7 @@ practice.
 
 ```toml
 [target.'cfg(any(linux, macos, windows))']
-platform = "openkal-platform@0.23.3"
+platform = "openkal-platform@0.23.6"
 ```
 
 One table (2026.10.27.1+). It selects the openkal platform for the host triples,
@@ -411,6 +411,8 @@ Nothing else is declared (2026.10.27.1+): the target table selects
 `openkal-platform` for both rows, and the platform states the toolchain, the
 layers, the tools, the conventions below and the runner ([35](35-platforms.md)).
 
+In mcpp 2026.11.5.1, both built-in openkal targets select platform 0.23.6 by default. An explicit `platform` configuration overrides that selection. This platform preserves the emulated TLS convention through the final ThinLTO link.
+
 | | the platform's statement | the reason |
 |---|---|---|
 | compile | `--target=<arch>-unknown-none-elf -fPIC -femulated-tls -fvisibility=hidden -fasynchronous-unwind-tables -Xclang -fstack-clash-protection`; on AArch64 also `-ffixed-x18 -mno-outline-atomics`; `-ffreestanding` when the graph supplies no C library | an image is told no operating system; it does not address the thread pointer and does not use the platform register, which two systems reserve; it exports what its source marks `visibility("default")` |

CHANGELOG.md

@@ -820,6 +820,14 @@ a.arg("cp").arg("${mcpp.artifact:updater/updater}").arg(out.c_str())
 A placeholder that names no `artifacts` entry fails planning and is named in the
 error.
 
+#### Optional action progress (2026.11.5.1+, protocol 18)
+
+Set `a.progress = true` in build.mcpp to enable telemetry for that action. The default is `false`; all five roles support it. The command receives `MCPP_ACTION_PROGRESS_FILE` when reporting is available and treats an absent or empty value as disabled. The path is encoded as UTF-8 on every host, including Windows.
+
+The worker atomically replaces the file with its latest JSON snapshot, for example `{"v":1,"seq":2,"phase":"compile","done":3,"total":9}`. `phase` can be reported without a total. The build status displays the latest valid snapshot while the action runs. Counts describe work inside that action and do not contribute to the outer Ninja step count. The command's exit status and output checks determine success.
+
+The runtime channel is allocated for this execution and is not a declared input or output. Editing the build program to enable telemetry can replan the build. Existing NDJSON build events retain their meanings. Snapshot fields, limits and ordering are specified in [SPEC-007 §3.1](specs/build-plugins.md#31-可选-action-进度协议-18).
+
 ### Deploying what the program generated: `deploy` (2026.9.12.3+, protocol 11)
 
 `[runtime] deploy` (docs/04 §2.11) places a file that already exists in the
@@ -1723,6 +1731,8 @@ of the cache key — an override is an escape hatch, not a reproducible input.
 
 ### Libraries of a build program: `[build-dependencies]` (mcpp 2026.10.11.1+)
 
+Build-only libraries supply layers and requirements to the build-program sub-build. They do not select the final artifact’s ABI, including when reached transitively (2026.11.5.1+). A package also reached through an ordinary dependency retains its target instance.
+
 A rule (say "run protoc over these `.proto` files") is written once, as an
 ordinary mcpp library package, and so is any library a build program needs —
 a TOML parser, a formatter. A build program uses a library its package names

docs/06-features-and-capabilities.md

@@ -470,7 +470,10 @@ say and says nothing, and a probe that reaches no answer invents none.
 accel = "cuda12.8+{sm_80,sm_90f} ptx>=90"
 ```
 
-overridden for one build by `--accel`, which is the relationship `--target`
+From 2026.11.5.1, a build request is read completely: unclosed sets, trailing text and empty target entries are errors. An implementation appears once per request; combine its targets as `sycl+{nvptx64-sm_89,nvptx64-sm_90}`. Implementation and target ordering, and repeated targets within a member, do not allocate different build variants. Target tokens belong to their implementation and are interpreted by its rule; selecting a SYCL NVIDIA target does not itself select CUDA source compilation. Source constraints use the same complete syntax check, including in a CPU-only build.
+
+
+The manifest request is overridden for one build by `--accel`, which is the relationship `--target`
 has with `[toolchain]`. `--no-accel` is not the absence of `--accel`; it is an
 explicit request for no accelerator, which is what selects a CPU-only variant
 of a package that also publishes device builds.

docs/24-openkal-cross.md

@@ -36,7 +36,7 @@
 | [SPEC-004](manifest-semantics.md) | `mcpp.toml` 的平面划分、条件化形状、解析轴与命名规约 | 草案 v1.17 | 2026-10-23 | 条件化形状 mcpp >= 2026.8.29.1;目标轴 mcpp >= 2026.9.6.4;`linkage` 默认值 mcpp >= 2026.9.15.2;链接 flag 的词读法 mcpp >= 2026.9.26.2;条件化的 `dialect_cxxflags` 与 `-p` 的包身份 mcpp >= 2026.9.28.1;条件表按具体程度生效 mcpp >= 2026.9.28.2;平台前缀规约 mcpp >= 2026.10.5.1;根包的继承、根位置的 profile、链接 flag 的作用域、链接期优化与导出发现 mcpp >= 2026.10.5.2;架构段的 `x86` 即 `i686` mcpp >= 2026.10.5.3;前缀即语义与工作空间层 mcpp >= 2026.10.10.1;依赖的库与配置(§12) mcpp >= 2026.10.11.1;值的四档层次与 `run_under` mcpp >= 2026.10.24.1 |
 | [SPEC-005](build-database.md) | 构建数据库:`mcpp emit build-database` 的内容、取值规则与不写工程目录的保证 | 评审中 v1.8 | 2026-10-11 | mcpp >= 2026.9.15.1;v1.3 条款 mcpp >= 2026.9.26.2;v1.4 条款 mcpp >= 2026.9.27.1;v1.5 条款 mcpp >= 2026.9.28.1;v1.6 条款 mcpp >= 2026.9.29.5;v1.7 条款 mcpp >= 2026.9.30.2;v1.8 条款 mcpp >= 2026.10.11.1 |
 | [SPEC-006](toolchain-management.md) | 工具链管理:身份、来源、选择与载荷契约 | 草案 v0.10 | 2026-10-23 | 逐条标注;已实现条款 mcpp >= 2026.9.24.1;§3.7 mcpp >= 2026.9.28.1;§3.7.1 mcpp >= 2026.9.28.2;§2.2.1 与 §3.3 的非缺省来源 mcpp >= 2026.10.1.3;§3.8 mcpp >= 2026.10.8.1;§3.9 至 §3.11 mcpp >= 2026.10.24.1 |
-| [SPEC-007](build-plugins.md) | 构建插件:配置、施工与校验的分工,运行时与规划期的义务 | 草案 v0.9 | 2026-10-11 | 逐条标注;mcpp >= 2026.9.26.2;v0.3 条款 mcpp >= 2026.9.27.1;v0.4 条款 mcpp >= 2026.9.28.1;v0.5 条款 mcpp >= 2026.9.28.2;v0.6(§9)mcpp >= 2026.9.28.3;R3.9、R3.10 mcpp >= 2026.10.10.1;§10 mcpp >= 2026.10.11.1 |
+| [SPEC-007](build-plugins.md) | 构建插件:配置、施工与校验的分工,运行时与规划期的义务 | 草案 v0.12 | 2026-11-05 | 逐条标注;mcpp >= 2026.9.26.2;v0.3 条款 mcpp >= 2026.9.27.1;v0.4 条款 mcpp >= 2026.9.28.1;v0.5 条款 mcpp >= 2026.9.28.2;v0.6(§9)mcpp >= 2026.9.28.3;R3.9、R3.10 mcpp >= 2026.10.10.1;§10 mcpp >= 2026.10.11.1;§3.1 协议 18 mcpp >= 2026.11.5.1 |
 | [SPEC-008](library-interface.md) | 库的接口:公开模块、发布闭包与两种形态的一致 | 草案 v0.2 | 2026-10-11 | 第一阶段(只警告)mcpp >= 2026.9.28.3;v0.2 mcpp >= 2026.10.11.1 |
 | [SPEC-009](toolchain-maintenance.md) | 工具链的支持与维护:版本线、默认值、来源、移动与退役 | 草案 v0.6 | 2026-10-09 | 逐条标注;本版只有规范,多数条款未实现;§6.4 mcpp >= 2026.10.8.1 |
 | [SPEC-010](home-initialization.md) | home 选择、单跳入口、初始化、网络边界与单次运行的 `--home` | 草案 v0.2 | 2026-10-26 | mcpp >= 2026.10.19.1；网络能力逐条标注；§6 mcpp >= 2026.10.26.1、xlings >= 2026.10.26.1 |