docs: record the fourth review round and the two anchoring rules

CHANGELOG gains the two facts a user needs and could not infer: inheritance
reaches a member compiled as a sibling's `path` dependency (and does NOT reach
a non-member path dependency), and a relative `include_dirs` is anchored to the
workspace root.

The design document's review record gains the round that found them. All three
share one shape — a rule implemented at the one place its FIRST consumer reads
it, for a key that has three — which is §2's defect one layer up.

Author: speak-agent

.agents/docs/2026-08-30-issues-527-529-535-537-analysis-and-design.md

@@ -1747,3 +1747,21 @@ and when the axes have different owners, the uniform version is wrong.** The
 measurement that `system` builds and runs was correct and load-bearing for the
 library axis; carrying it across to the toolchain axis is what produced a
 proposal the maintainer had already declined on the issue.
+
+**Fourth round: does the new key reach everything it says it reaches?**
+
+Asked of the shipped implementation rather than of the design, and it did not.
+
+| claim as shipped | what measurement showed | where |
+|---|---|---|
+| `[workspace.build]` applies to every member | Only to the member the command names. A sibling compiled as its `path` dependency — the ordinary workspace shape — got none of the flags, in the same command. `[workspace.package] standard` hid it, because the standard is imposed graph-wide from the root for BMI compatibility and reached the sibling anyway | §5.5 |
+| a member may omit `version` when the workspace supplies it | True where the command names it; false where it is reached as a sibling's dependency, which refused it for a field the workspace does provide | §5.5 |
+| `[workspace.build] include_dirs` inherits | It did, verbatim — so a relative path written at the workspace root was resolved against each MEMBER's directory. #224 for a third key, found by re-reading the merge | §5.5, D11 |
+
+The shape all three share: **a rule was implemented at the one place its first
+consumer reads it, and the key has more than one consumer.** The inheritance
+site, the dependency load site and the package-assembly site each read a
+different half, and a fix placed at any one of them is silent at the other two.
+That is the same sentence as §2's defect, one layer up — which is why "who else
+reads this?" is the question worth asking of every new key, and why the
+denominator in each new test is a case that a single-site fix would still pass.

CHANGELOG.md

@@ -78,6 +78,14 @@
   没有 `[workspace.target.<triple>]`:根里普通的 `[target.<triple>]` 本来就按 triple
   被成员继承,为同一能力再加一种拼法只增加接口面。
 
+  ⚠️ **继承作用到每一个成员,包括「作为兄弟成员的 `path` 依赖被编译」的那个**
+  —— 也就是成员互相依赖这种最普通的形态。而 `path` 依赖里**不是成员**的那些
+  (vendored 副本、example)不会获得这些标志:成员资格问的是 workspace 自己的
+  `members` 列表,不是「这个路径在不在 workspace 目录下」。
+
+  ⚠️ `[workspace.build] include_dirs` 里的相对路径按 **workspace 根**锚定(#224):
+  它是在根 manifest 里写的,按各成员自己的目录解析会指向不存在的地方。
+
 - **依赖声明了高于当前图的标准时会说出来。** C++ 模块图只有一个标准,依赖自己的
   `standard` 不生效 —— 这是对的;缺的是它一直不说。degraded 级别(`--strict` 提升),
   且**只对工程作者自己拥有的 manifest 生效**:索引里带 mcpp 段的描述符 782 个全都声明了