@@ -3,6 +3,89 @@
 > 本文件追踪 `mcpp-community/mcpp` 公开仓的版本演进。
 > 格式参考 [Keep a Changelog](https://keepachangelog.com/zh-CN/1.1.0/)。
 
+## [2026.8.30.2] — 2026-08-30
+
+六处缺陷,来自 #527 / #529 的分析,外加一处在实现 review 时挖出来、没有人报过的。
+它们分属两族:**记录存在而做决定的代码不读它**,以及**运行期搜索路径把「声明的」
+和「这台机器碰巧装了的」混在一起**。
+
+完整分析、量化与设计见
+[`.agents/docs/2026-08-30-issues-527-529-535-537-analysis-and-design.md`](.agents/docs/2026-08-30-issues-527-529-535-537-analysis-and-design.md)。
+
+> **host 依赖的分界是「能不能构建并运行」,不是「干不干净」。** mcpp 自身与生态
+> 发布的一切都不依赖 host;用户自己的工程可以另做选择,那是他自己保证的事 ——
+> mcpp 提示并指出受支持的路径,但不强行拒绝。而「证明跑不起来」仍然是错误。
+
+### 修复
+
+- **`mcpp test` 每次调用都在重算一份没有变化的答案(#529)。** 两个 post-link ELF
+  pass 都写了读回优化(stat 没变 ⇒ 复用上次判定),而 `prepare_build` 每次调用都用
+  一个**全新的 json 对象**重写 `resolution.json` —— 那里面没有这两条记录。于是每次
+  调用一开始,就把自己后端待会儿要找的备忘录删掉了。
+
+  记录改存进 `.mcpp-runtime-verdicts.json`(它本来就活得过 `prepare_build`),
+  `resolution.json` 继续发布一份副本 —— 这正是 `sync_resolution_verdict` 已有的
+  形态。同时:
+  - 剪枝的判据从「不在本次 plan 里」改为「产物已不在磁盘上」。`mcpp build` 与
+    `mcpp test` 共用一个输出目录而 link unit 集合不同,前一个判据让两条命令互删
+    对方的记录;
+  - 记录的失效键纳入 SubOS farm 的 `.xlings.json` 时间戳与 `MCPP_ALLOW_HOST_LIBS`
+    —— 让备忘录持久化,就产生了一条以前不存在的正确性义务。
+
+  实测(10 个 link unit,每个 11.5MB,全热):
+
+  | | 之前 | 之后 |
+  |---|---|---|
+  | `mcpp build -p <member>` | 0.70s | 0.32s |
+  | `mcpp test -p <member>`(紧接 build) | 3.15s | **0.36s** |
+  | `mcpp test -p <member>`(连续) | 1.95s | 0.40s |
+
+- **`path` 依赖里新增一个源文件,fast path 看不见。** 陈旧性扫描只覆盖被构建的那个
+  工程,于是 `mcpp build` 报 `Finished dev in 0.00s`,而那个模块从没编译过。内容改动
+  之所以还能被抓到,靠的不是扫描,是 ninja 重链后的事后放弃。这是 #359 那条形态
+  ("glob 输入变了而现存文件的 mtime 一个没动")在它当年没有覆盖到的目录里。
+  workspace 成员之间就是 `path` 依赖,所以这不是边角情况。
+
+- **`[toolchain] system` 配合 `build.mcpp` 直接崩溃(#527 Bug 1)。**
+  `posix_spawnp('') failed (error 2)`。解析出的编译器绝对路径一直在 `tc->binaryPath`
+  里,只是没有交给 `build.mcpp` 的编译闭包。**修的是一个没赋值的变量,不是加 host
+  支持** —— 同一份 manifest 去掉 `build.mcpp` 本来就能构建。
+
+- **`standard = 26`(不带引号)被静默忽略。** 键被文档写成字符串,而 `get_string` 对
+  裸整数返回空,于是工程按默认档位编译、零诊断。#527 自己的三处示例就是这么写的。
+  两种拼法现在都接受。
+
+### 新增
+
+- **`[workspace.package]` 与 `[workspace.build]`(#527 Bug 2 / RFC 3)。** workspace 根
+  的 `[build]` 此前完全没有传给成员;现在标量按「成员**声明过**就成员优先」继承,
+  向量按 workspace 在前追加。
+
+  「声明过」是**解析时记录的事实**,不是与默认值比较得出的推断 —— 成员在
+  `standard = 26` 的 workspace 下刻意写 `standard = "c++23"` 必须保住,而那与默认值
+  同为一串字节。这正是 cpp20 设计文档 §9-Q3 记下的前置条件。
+
+  `allow_host_libs` 明确不可继承:它关掉的是某个具体产物的检查,workspace 根设一次
+  就等于替所有后来加入的成员也关掉了。`[workspace.package]` / `[workspace.build]` 里
+  不认识的键会被**拒绝**而不是忽略。
+
+  没有 `[workspace.target.<triple>]`:根里普通的 `[target.<triple>]` 本来就按 triple
+  被成员继承,为同一能力再加一种拼法只增加接口面。
+
+- **依赖声明了高于当前图的标准时会说出来。** C++ 模块图只有一个标准,依赖自己的
+  `standard` 不生效 —— 这是对的;缺的是它一直不说。degraded 级别(`--strict` 提升),
+  且**只对工程作者自己拥有的 manifest 生效**:索引里带 mcpp 段的描述符 782 个全都声明了
+  `language`,其中 756/774 是 `import_std = false` 的 C 库带的样板值,信任「声明过」会
+  让 c++20 的根工程对着整个索引报警。
+
+- **方言标志没进 `import std` 预编译时,在编译前拒绝。** `[build] cxxflags` 里的
+  `-fno-exceptions` / `-fno-rtti` 会到达每个 TU 却到不了 std BMI 预编译,于是每个
+  importer 都在 mcpp 生成的文件里失败,而报错只讲机制不讲那个键。现在提前拒绝并指出
+  `dialect_cxxflags`。读的是**生效后**的标志集合(`[build]` / `[profile.*]` /
+  `[target.…]` 都算),并且在图中没有 `import std` 时不触发。
+
+  这两个标志仍然**不自动提升**:依赖可以合法地不同意,消费者无权替它决定。
+
 ## [2026.8.29.1] — 2026-08-29
 
 构建规则以普通包分发的机制自 2026.8.5.1 就能用,而**规范**一直没有:一个规则包
 
@@ -305,6 +305,46 @@ Pinned toolsets coexist with each other and with a system Visual Studio.
 > that may have been intended. (The family-less `[toolchain] … = "system"` — the PATH
 > compiler — is a separate and deliberate escape hatch, and is unaffected.)
 
+### `[toolchain] … = "system"` — the PATH compiler
+
+The escape hatch: mcpp uses whatever C++ compiler is on `PATH` instead of
+resolving one from the xim index. It works for the whole build, `build.mcpp`
+included.
+
+It is not recommended, and mcpp says so once per build:
+
+```
+warning: [toolchain] system selects a compiler from PATH
+  impact: this build depends on what this host has installed, so it is not
+          reproducible on another machine and cannot be checked by CI
+  hint:   mcpp resolves its own toolchains from the xim index so that
+          `import std` and the runtime closure are guaranteed on every host;
+          declare one with [toolchain] linux = "gcc@16.1.0" (or
+          `mcpp toolchain default`) to get the same compiler here, on a
+          teammate's machine and in CI
+```
+
+It is a warning and not a refusal, and that division is the general rule for
+host dependence in mcpp:
+
+- **mcpp itself, and everything the mcpp ecosystem publishes, depends on no
+  host.** Toolchains, payloads and libraries come through xlings — the xim index
+  or mcpp-index. This is what makes a build reproducible across machines and
+  Linux distributions.
+- **A user's own project may choose otherwise, and that choice is theirs to
+  guarantee.** mcpp warns and names the supported route; it does not refuse, as
+  long as the result builds and runs. `--strict` turns the warning into an
+  error, which is how a CI job enforces "no host dependencies" for a repository
+  that wants that.
+
+A build that provably *cannot* run is a different matter and stays an error: a
+runtime closure that cannot be satisfied is refused, because the artifact will
+not start. See [binary distribution](12-binary-distribution.md).
+
+The same wording appears wherever a host dependency is taken — a host library on
+the link line points at mcpp-index instead, and notes that contributing the
+package there is the supported route when the index does not carry it yet.
+
 ### `msvc@system` — the machine's own Visual Studio
 
 mcpp locates and identifies an installed Visual Studio / Build Tools; it never
 
@@ -72,6 +72,47 @@ Two properties worth knowing:
 If the sources `import std;` at a level the resolved toolchain does not provide the `std`
 module for, mcpp fails before compiling and names both the toolchain and the project level.
 
+Both spellings of the value are accepted: `standard = "c++26"` and `standard = 26`.
+
+When a **dependency declares a level above the graph's**, mcpp says so before compiling
+rather than letting it fail somewhere inside that dependency's sources. See
+[workspace §4.2](06-workspace.md).
+
+#### Dialect flags and the `import std` BMI
+
+Some flags change what the standard library's headers declare, so the precompiled `import std`
+BMI has to be built with them too. That is what `[build] dialect_cxxflags` is for: it is
+applied to the std BMI prebuild, the module scan **and** every translation unit in the graph,
+including dependencies.
+
+```toml
+[build]
+dialect_cxxflags = ["-fno-exceptions"]
+```
+
+mcpp promotes a few flags into that channel automatically when it finds them in `cxxflags`
+(`-freflection`, `-fchar8_t`, `-D_GLIBCXX_USE_CXX11_ABI=…`) — a graph that mixes those is
+ill-formed anyway, so no dependency can hold a different opinion about them.
+
+`-fno-exceptions` and `-fno-rtti` are **not** promoted, because a dependency can legitimately
+disagree: they remove a language facility the dependency may use, and the consumer cannot make
+that choice on its behalf. Left in `cxxflags` they reach every TU and not the prebuild, so the
+build cannot succeed — mcpp refuses it before compiling and names the key:
+
+```
+error: `-fno-exceptions` changes the language dialect, but the `import std` BMI is
+       precompiled without it, so every importing translation unit will fail with
+       "language dialect differs".
+       Declare it as a dialect flag instead:
+
+         [build]
+         dialect_cxxflags = ["-fno-exceptions"]
+```
+
+The check reads the **effective** flags, so it fires for the same flag written in
+`[profile.<name>] cxxflags` or in a `[target.…]` block. It does not fire when nothing in the
+graph imports `std`, where the flag is an ordinary per-unit option that works.
+
 ### 2.2 `[targets.<name>]` — Build Targets
 
 ```toml
 
@@ -151,6 +151,102 @@ linkage   = "static"
 default = "llvm@20.1.7"
 ```
 
+### 4.1 `[workspace.package]` and `[workspace.build]`
+
+Package metadata and build flags shared by every member are declared once at the
+workspace root:
+
+```toml
+[workspace]
+members = ["libs/core", "libs/http", "apps/server"]
+
+[workspace.package]
+standard = 26                  # or "c++26"; both spellings are accepted
+version  = "0.4.2"
+license  = "Apache-2.0"
+authors  = ["example"]
+
+[workspace.build]
+cxxflags         = ["-Wall", "-Wextra"]
+dialect_cxxflags = ["-fno-exceptions"]
+```
+
+A member then declares only what is its own:
+
+```toml
+[package]
+name = "core"
+# standard, version, license and authors are inherited;
+# [workspace.build] cxxflags are inherited
+```
+
+**The merge rule.**
+
+| kind | rule |
+|---|---|
+| scalars (`standard`, `version`, `license`, `c_standard`, `linkage`, …) | the member wins **when it declared the key**; otherwise the workspace value applies |
+| vectors (`cxxflags`, `ldflags`, `defines`, `dialect_cxxflags`, `include_dirs`, …) | append, **workspace first** — so a member's own flag comes later on the command line, where it wins |
+| `[workspace.dependencies]` | explicit opt-in per dependency, `x.workspace = true` (§3) |
+
+"Declared" means the key was written, not that its value differs from the
+default. A member that deliberately pins `standard = "c++23"` under a
+`[workspace.package] standard = 26` keeps c++23; a member that says nothing gets
+c++26. Those two are the same value and opposite intents, which is why the
+distinction is recorded rather than inferred.
+
+Scalars and vectors are inherited **implicitly**, without a per-key opt-in. The
+drift a workspace exists to prevent is a member that forgot to opt in, so
+inheritance is the default and overriding is the thing you ask for. Dependencies
+keep their explicit opt-in because a dependency is an edge in the resolution
+graph: inheriting one implicitly would change what a member resolves without its
+own manifest naming it.
+
+**`version` may be omitted by a member** when `[workspace.package]` supplies it.
+It remains required overall — a member with neither is refused, naming both the
+member and the workspace key that would have supplied it.
+
+**Not everything is inheritable.** `[workspace.build] allow_host_libs` is
+refused. It disables the hermetic-link check for a specific artifact, and a
+workspace root able to set it once would disable that check for members added
+later by someone who never read the root manifest. Keys that describe *how to
+build* are inheritable; keys that describe *which safety check not to run* stay
+with the package whose artifact it is. Any other unknown key in
+`[workspace.package]` / `[workspace.build]` is refused too, rather than ignored:
+a key that is silently dropped from a table whose whole purpose is propagation
+produces a workspace that looks configured and is not.
+
+**There is no `[workspace.target.<triple>]`.** A plain `[target.<triple>]` block
+in the workspace root is already inherited by every member, per triple, with the
+member winning. A second spelling for the same capability would be surface with
+no function.
+
+### 4.2 One standard for the whole module graph
+
+A C++ module graph has exactly one standard: BMIs are not compatible across
+levels, so the root package's `standard` is applied to every package in the
+graph, including dependencies. A dependency's own `standard` is not applied.
+
+When a dependency **declares** a level higher than the graph is built at, mcpp
+reports it before compiling:
+
+```
+warning: dependency `render` declares standard = "c++26", and this graph is
+         built at c++23
+  impact: a C++ module graph has one standard, so the dependency's declaration
+          is not applied and its sources are compiled at the graph's level
+  hint:   raise the consumer's standard to "c++26", or declare it once for
+          every member:
+
+            [workspace.package]
+            standard = "c++26"
+```
+
+This is a warning rather than an error — such a build usually succeeds, and it
+is promoted to an error by `--strict`. It is reported only for manifests the
+project author controls (the root package, workspace members, and `path`
+dependencies): a package resolved from an index carries a `standard` written by
+a descriptor generator rather than by the person reading the message.
+
 ## 5. Build Commands
 
 ### 5.1 Building & testing from the Workspace Root
 
@@ -284,6 +284,38 @@ pinned toolset 之间、以及与系统 Visual Studio 之间都可以共存。
 > `[toolchain] … = "system"` —— 即 PATH 上的编译器 —— 是另一套、也是有意保留的
 > 逃生口,不受影响。)
 
+### `[toolchain] … = "system"` —— PATH 上的编译器
+
+逃生口:mcpp 使用 `PATH` 上现成的 C++ 编译器,而不从 xim 索引解析一个。整个构建都走它,
+`build.mcpp` 也不例外。
+
+不推荐,而且 mcpp 每次构建会明说一次:
+
+```
+warning: [toolchain] system selects a compiler from PATH
+  impact: this build depends on what this host has installed, so it is not
+          reproducible on another machine and cannot be checked by CI
+  hint:   mcpp resolves its own toolchains from the xim index so that
+          `import std` and the runtime closure are guaranteed on every host;
+          declare one with [toolchain] linux = "gcc@16.1.0" (or
+          `mcpp toolchain default`) to get the same compiler here, on a
+          teammate's machine and in CI
+```
+
+它是 warning 而不是拒绝。这条分界就是 mcpp 对待 host 依赖的总规则:
+
+- **mcpp 自身、以及 mcpp 生态发布的一切,都不依赖任何 host。** 工具链、payload、库都经由
+  xlings 获得 —— xim 索引或 mcpp-index。这正是构建能跨机器、跨 Linux 发行版复现的原因。
+- **用户自己的工程可以另做选择,而这个选择由他自己保证。** mcpp 提示并指出受支持的路径,
+  但只要结果能构建、能运行,就不强行拒绝。`--strict` 会把该提示变成错误 —— 需要"零 host
+  依赖"的仓库,CI 就用它来强制。
+
+而"证明跑不起来"的构建是另一回事,仍然是错误:运行期闭包不可满足时会被拒绝,因为产物根本
+起不来。见[二进制分发](12-binary-distribution.md)。
+
+同样的措辞会出现在每一处取用 host 的地方 —— 链接行上的 host 库会改为指向 mcpp-index,并说明
+索引尚未收录时,**把包贡献进 mcpp-index** 才是受支持的路径。
+
 ### `msvc@system` —— 机器自己的 Visual Studio
 
 mcpp 只负责定位并识别已安装的 Visual Studio / Build Tools,**从不**安装、
 
@@ -70,6 +70,44 @@ repo        = "https://github.com/user/myapp"  # 仓库地址(可选)
 如果源码在某个档位上 `import std;` 而解析出的工具链在该档位不提供 `std` 模块，
 mcpp 会在编译前失败，并同时报出工具链与工程档位。
 
+值的两种拼法都接受:`standard = "c++26"` 与 `standard = 26`。
+
+当**依赖声明的档位高于当前图**时,mcpp 会在编译前说出来,而不是让它在那个依赖的源码里
+某处失败。见 [workspace §4.2](06-workspace.md)。
+
+#### 方言标志与 `import std` BMI
+
+有些标志会改变标准库头文件**声明出什么**,因此预编译的 `import std` BMI 也必须带着它们一起
+构建。这就是 `[build] dialect_cxxflags` 的用途:它会被施加到 std BMI 预编译、模块扫描
+**以及**图中每一个 TU(依赖也包括在内)。
+
+```toml
+[build]
+dialect_cxxflags = ["-fno-exceptions"]
+```
+
+其中少数几个标志,mcpp 在 `cxxflags` 里发现时会自动提升进这条通道
+(`-freflection`、`-fchar8_t`、`-D_GLIBCXX_USE_CXX11_ABI=…`)—— 混用这些标志的图本来就是
+病态的,任何依赖都不可能对它们持有另一种自洽的意见。
+
+`-fno-exceptions` 与 `-fno-rtti` **不会**被自动提升,因为依赖可以合法地不同意:它们移除的是
+依赖可能正在使用的语言设施,而消费者无权替它做这个决定。留在 `cxxflags` 里,它们会到达每一个
+TU 却到不了预编译,于是构建不可能成功 —— mcpp 在编译前就拒绝,并指出该用哪个键:
+
+```
+error: `-fno-exceptions` changes the language dialect, but the `import std` BMI is
+       precompiled without it, so every importing translation unit will fail with
+       "language dialect differs".
+       Declare it as a dialect flag instead:
+
+         [build]
+         dialect_cxxflags = ["-fno-exceptions"]
+```
+
+这项检查读的是**生效后的**标志集合,所以同一个标志写在 `[profile.<name>] cxxflags` 或
+`[target.…]` 块里同样会被抓到。而当图中根本没有 `import std` 时它不触发 —— 那里它就是一个
+正常工作的按 TU 选项。
+
 ### 2.2 `[targets.<name>]` — 构建目标
 
 ```toml