docs: what implementing corrected in the analysis

Author: speak-agent

.agents/docs/2026-08-26-resolved-but-not-consulted.md

@@ -533,7 +533,72 @@ EXPECT_EQ(parse("x86_64-linux")->str(), "x86_64-linux-gnu");
 
 ---
 
-## 8. 顺序与代价
+## 8. 落地(2026.8.26.2)—— 与本文的三处出入
+
+四项 A/B/C/D 全部实施。**实施过程推翻了本文的一处论断,并挖出两处本文没有想到
+的缺陷。**
+
+### 8.1 ⚠️⚠️ §4.1.1 说「不需要新的开关」,这句话是**不完整的**
+
+原文:
+
+> ⭐ **「不改全局配置」不是给方案 A 加的一条约束,而是把决定放对位置后的自然结
+> 果。** 不需要新的开关,也没有需要有人记得不去碰的写入点 —— 那些写入点位于一条
+> 不再进入的分支上。
+
+对的只有**一处**。首次运行那条分支的条件是 `!tcSpec.has_value()`,方案 A 让它有
+值,于是确实进不去。但 `write_default_toolchain` 有**三个**调用点,另外两个的条
+件不是它:
+
+| 调用点 | 条件 | A 之后可达? |
+|---|---|---|
+| 首次运行安装 | `!tcSpec.has_value()` | 否 |
+| Windows 首次运行改道 | `windowsGnuFirstRun && tcSpec.has_value()` | **是** |
+| MSVC 不可用时的修复 | `!tc_origin_is_user_explicit(tcOrigin)` | **是** |
+
+一台没装工具链的 Windows 机器,构建**一个**要求 llvm 的工程,会把 llvm 写成**这
+台机器**的默认值,交给之后每一个什么都没要求的工程。
+
+⭐ 修法不是在两处各写一个条件,而是给这条规则一个名字:
+`tc_origin_may_persist(TcOrigin)`,两处都调用它,一条单测陈述它。理由写在函数
+上方:今天有两处,第三处会由一个没读过这段注释的人写出来,而一个有名字的谓词是
+他能找到的东西。
+
+⚠️ **这条缺陷是读出来的,不是跑出来的** —— 它需要一台没有工具链的 Windows 机
+器。E10(config.toml 的 sha256)跑在已经配好工具链的环境里,两条分支一条都到不
+了,所以判据只能落到规则本身。这正是 §5 那句「E11 本机永远看不见」的更强版本:
+有些判据连 CI 都给不了,只能由单测陈述规则。
+
+### 8.2 ⚠️ 能力行的补救办法抄了约定行的
+
+第一版的 `TargetPin` 拒绝对两种行给同一段建议:「依赖一个供给该目标系统的包,
+这样就不需要行里那个载荷了」。
+
+对约定行成立(`graphSuppliesSystem` 正是取消它的东西),对**能力行不成立** ——
+`targetPinIsCapability` 让 pin 无论图供给什么都保持生效。于是那段文字给出的指
+示,被它正上方那句话("no other family emits this target")已经否掉了。
+
+⭐ 这与 §2.3.1 是同一条:**一条修不好它所印在其下的那次失败的建议,比没有建议更
+糟**。我在同一个 PR 里,隔着三屏,把自己刚指出的错误又犯了一遍。
+
+### 8.3 ⭐ `compiler.chosenBy` 落地,以及三条测试自己的缺陷
+
+- `why toolchain --format json` 新增 `compiler.chosenBy = {origin, requiredBy,
+  replaced}`(§4.1 承诺过)。e2e 301 因此改为断言这个字段而不是状态行的措辞。
+- ⚠️ **jq 的 `//` 把 `false` 当成缺席**。303 用 `.suppliesTarget // "MISSING"`
+  读一个布尔字段,`false` 是一个合法答案却读成了「字段不存在」。
+  windows-x86_64 上实测报「字段缺失」,而字段就在那里。判据要用 `has()`。
+- ⚠️ **301 第一版在错误的目录里量基线**:从 runner 的起始目录问 `why toolchain`,
+  读到的是 mcpp 自己仓库 `mcpp.toml` 里写的 gcc,于是选了 llvm 去要求,而实测工程
+  的全局默认本来就是 llvm —— 全部断言通过,而那条要求什么都没改变。基线必须取自
+  **同一份 manifest 去掉依赖**。
+- ⚠️ **281 断言的是旧建议**。它 grep `mcpp toolchain default`,而方案 A 之后唯一
+  还能走到那条拒绝的局面里,那条建议连问题都解决不了。已改成断言新建议**并且**
+  断言旧建议不出现。
+
+---
+
+## 9. 顺序与代价
 
 | 项 | 依赖 | 触及 | 风险 |
 |---|---|---|---|

CHANGELOG.md

@@ -88,6 +88,17 @@
   `cLibrary.suppliesTarget`;⭐ 是**增字段**而非改名或给 `mode` 加取值,因为
   docs/11 §6 承诺字段只增不删、含义永不改变。
 
+- **⚠️⚠️ 而「不写任何东西」需要一个有名字的规则,不只是一个位置。**
+
+  `write_default_toolchain` 有三个调用点。首次运行那个的条件是
+  `!tcSpec.has_value()`,方案确实让它进不去;另外两个 —— Windows 首次运行改道、
+  MSVC 不可用时的修复 —— 条件不是它,**都可达**。一台没装工具链的 Windows 机器
+  构建一个要求 llvm 的工程,会把 llvm 写成这台机器的默认值。
+
+  ⭐ 修法是给规则一个名字:`tc_origin_may_persist(TcOrigin)`,两处都调用,一条单
+  测陈述它。⚠️ 这条缺陷是**读出来的**:它需要一台没有工具链的 Windows 机器,而
+  `config.toml` 的 sha256 判据跑在已配好的环境里,两条分支一条都到不了。
+
 ### 判据
 
 - e2e `299`–`303`,全部走 `--format json` 分类而非字符串搜索,并接入