docs: a translation must carry the same tables and code blocks, and four that did not

check_docs_style.sh compares heading STRUCTURE, which catches a page that has
fallen a section behind. It cannot see a table row or a code block that never
made it across, and four were sitting in the tree — none introduced by this
batch, and none visible to any other check:

  docs/zh/22 (from 05)  the `[features]` section had NO BODY: the TOML example
                        that defines the syntax and all three bullets were
                        absent, in the section that defines the mechanism
  docs/zh/05 §2.11      the `identity` verdict table — ok / mismatch / missing /
                        unverified — and the two paragraphs around it
  docs/zh/08 §7.4       the shared-library format table and what follows it:
                        Mach-O's install name, and the refusal of an unservable
                        target
  docs/zh/16            SEVEN target rows. The 简体中文 support matrix listed 14
                        targets where the English listed 21, all seven missing
                        ones Cortex-M

Rule 10 compares table rows and fenced code blocks per document pair. It was
written after the first two were found by hand, and it immediately found the
other two, which is the argument for it: a bilingual pair can agree on every
heading and disagree about a support matrix.

Author: speak-agent

.github/tools/check_docs_structure.sh

@@ -13,6 +13,7 @@
 #   7. the generated design-record index is current
 #   8. a new design record declares its subject and status
 #   9. every relative link in docs/ and examples/ resolves
+#  10. a translation carries the same tables and code blocks
 #
 # What it deliberately does NOT check: whether a chapter documents what is
 # implemented, whether an assertion's strength matches its evidence, or whether
@@ -160,6 +161,46 @@ for f in list(pathlib.Path("docs").rglob("*.md")) + list(pathlib.Path("examples"
 sys.exit(1 if bad else 0)
 PYCHECK
 
+# ── 10. a translation carries the same tables and code blocks ────────────
+#
+# check_docs_style.sh compares HEADING STRUCTURE, which is what catches a page
+# that has fallen a section behind. It does not see a table row or a code block
+# that never made it across, and two of those were sitting in the tree: the
+# 简体中文 `[features]` section had no body at all, and 简体中文 §2.11 was
+# missing the `identity` verdict table. Both predate this check and both are
+# invisible to every other one.
+python3 - <<'PYPARITY' || fail=1
+import pathlib, sys, re
+bad = 0
+for en in sorted(pathlib.Path("docs").glob("*.md")):
+    zh = pathlib.Path("docs/zh") / en.name
+    if not zh.exists():
+        continue
+    def count(f):
+        rows = blocks = 0
+        infence = False
+        for line in f.read_text(errors="ignore").split("\n"):
+            if line.startswith("```"):
+                if not infence:
+                    blocks += 1
+                infence = not infence
+                continue
+            if infence:
+                continue
+            if line.startswith("|"):
+                rows += 1
+        return rows, blocks
+    er, eb = count(en)
+    zr, zb = count(zh)
+    if er != zr:
+        print(f"FAIL: {en.name}: {er} table rows in English, {zr} in 简体中文")
+        bad += 1
+    if eb != zb:
+        print(f"FAIL: {en.name}: {eb} code blocks in English, {zb} in 简体中文")
+        bad += 1
+sys.exit(1 if bad else 0)
+PYPARITY
+
 if [[ "$fail" -eq 0 ]]; then
   echo "OK: docs structure checks pass"
 fi

docs/zh/05-mcpp-toml.md

@@ -1099,6 +1099,21 @@ requirements/providers/artifacts、LinkIntent、平台搜索机制与链接后 v
 `mcpp why runtime` 只是最新存储文件的纯解释器:不重新解析 manifest,也不启动图形/
 硬件 probe。需要重新诊断所选 host provider 时使用 `xlings doctor`。
 
+每个 artifact 还带一个仅由路径算出的 `identity` 判定:
+
+| `identity` | 含义 |
+|---|---|
+| `ok` | 声明的路径(穿过符号链接后)落在声明的那个版本里 |
+| `mismatch` | 它解析到了别处 —— **该 binding 已陈旧**,后来的某次安装把它重新指向了别的地方 |
+| `missing` | 声明了,但那个路径上什么都没有 |
+| `unverified` | 声明时没有可供比对的版本 |
+
+这就是 mcpp 早已施加于私有 libc 的那条规则的推广(`glibc@2.44` 解析到那一份载荷;
+陈旧或缺失是错误,而绝不是「已安装版本里哪个看起来能用就用哪个」)。它不需要知道
+该 artifact 做什么。`unverified` **有意**不等于 `ok`:一个解析到了却没有 artifact
+在其背后的 provider 并未被核验过,因此 `mcpp why runtime` 打印
+`(not declared by the environment — nothing to verify)` 而不是 `(none)`。
+
 能力名使用分层小写 `domain.sub.role`(如 `display.present`)和前缀类
 `abi:<name>`(如 `abi:glibc`,参与工具链 ABI 强制)。
 

docs/zh/08-toolchain-internals.md

@@ -464,6 +464,30 @@ C 世界(`CLibMode::Sysroot`)并有自己的 libc++ 链接处理;Windows 没有
 mcpp 把运行时 DLL 部署到产物 exe 旁,这正是该平台对 §3–§4 所做一切的原生
 等价物。
 
+**工程自己产出的共享库**(`kind = "shared"`)确实按格式而不同,而这个差别不是
+flag 的拼法 —— 它是产物记录下的关于它自己的东西:
+
+| 格式 | 生产方发出什么 | 消费方链接什么 |
+|---|---|---|
+| ELF | 声明了 soname 时发 `-Wl,-soname,<n>` | `-L` + `-l`、`-Wl,-rpath,$ORIGIN` |
+| Mach-O | **总是**发 `-Wl,-install_name,@rpath/<file>` | `-L` + `-l`、`-Wl,-rpath,@loader_path` |
+| PE / MinGW | `-Wl,--out-implib,<lib>` | **导入库**,且 `-Wl,-Bdynamic` 在前 |
+| PE / MSVC | 拒绝(不做自动导出;见 docs/12) | —— |
+
+其中三行是新增的:在此之前,除 ELF 之外一律被拒绝,原生与交叉都是。要让它们
+可用而不只是被允许,有两处细节必须改。Mach-O 的 install name 默认取该库被**链接**
+时的路径,因此「仅在声明了 `soname` 时才发出」会让其余每个 `.dylib` 都记下一个构建
+目录 —— 在构建它的那台机器上没问题,换任何一台就是 `image not found`。而这个选择
+原先由宿主上的 `#if defined(__APPLE__)` 做出,那只在原生 macOS 构建上碰巧正确,
+对任何交叉链接都是错的;它现在由目标决定,正如 `target_output` 早已如此。
+
+**服务不了的目标会被拒绝**,而不是悄悄按宿主构建:Linux 上的
+`--target x86_64-windows-msvc` 从前会解析到原生 `g++`、写进
+`target/x86_64-linux-gnu/` 并报告成功。词汇表的档位说的是「mcpp 支持这个目标」;
+`host_can_serve`(`registry.cppm`)回答的是另一个问题「这台机器能不能产出它」,
+而 `prepare.cppm` 现在会问它 —— 显式的 `[target.X] toolchain = "…"` 是作者自备
+交叉工具链时的出口。
+
 ### 7.5 一个 flag 由哪根轴决定
 
 2026.8.18 那一轮改了四个 flag,每一个此前都挂在错误的轴上。而这类错误的表现

docs/zh/16-the-target-triple.md

@@ -383,6 +383,13 @@ CRT;图供给时是 `musl`。一个目标字符串,两个不同的 C 库 ——
 | `riscv32-none-elf` | verified | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
 | `aarch64-none-elf` | preview | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
 | `x86_64-none-elf` | preview | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
+| `thumbv6m-none-eabi` | verified | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
+| `thumbv7m-none-eabi` | verified | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
+| `thumbv7em-none-eabi` | preview | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
+| `thumbv7em-none-eabihf` | verified | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
+| `thumbv8m.base-none-eabi` | preview | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
+| `thumbv8m.main-none-eabi` | verified | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
+| `thumbv8m.main-none-eabihf` | preview | `llvm@22.1.8` | 载荷 | 载荷 | 载荷 | 载荷 |
 
 `载荷` 这里有工具链载荷产出它 · `图` 没有载荷,但依赖可以供给系统 ·
 `系统` 在机器上被找到,不是 mcpp 装的 · `SDK` 平台自己的 ·

docs/zh/22-features-and-capabilities.md

@@ -10,6 +10,22 @@ Feature 是一个包提供可选内容的方式:一个编译宏、一份额外
 
 ## `[features]` —— Feature(Cargo 风格,可加性)
 
+```toml
+[features]
+default = ["base"]        # 默认激活集合
+base    = []
+docking = ["extra"]       # 激活 docking 即隐含激活 extra(传递闭包)
+extra   = []
+```
+
+- 激活来源:包自己的 `default` 集合 ∪ 显式请求(根包经由
+  `mcpp build --features a,b`;依赖经由长形式依赖 spec 的 `features = [...]`
+  与 `backend = "..."` 糖)。
+- 每个被激活的 feature 在该包编译时得到宏 `-DMCPP_FEATURE_<NAME>`(名字大写,
+  非字母数字变 `_`,例如 `backend-a` → `MCPP_FEATURE_BACKEND_A`)。
+- **严格校验**:目标包声明了 `[features]` 表时,请求一个未声明的 feature 产生
+  警告,在 `--strict` 下是错误。不声明 `[features]` 的包接受任意请求(纯宏用法)。
+
 ### 表形式 —— 让 feature 贡献的不止是隐含 feature
 
 `[features]` 的条目除了写成数组,还可写成**表**,从而让该 feature 在隐含 feature