docs: a positioning table at the top, refreshed highlights, and the row my own criterion could not see

Review found a table row sitting on line 1 of README.zh-CN.md, above the
document's title. It was put there by the probe that verified rule 10: the
restore step replaced the empty string, which inserts at position 0 rather than
where the row came from. Rule 10 stayed green throughout at 61 rows against 61,
because a count cannot see WHERE a row is. The row is back in the target table.

Rule 15 is the criterion that would have caught it: a maximal run of lines
beginning with `|` is a table only if its second line is a delimiter row, so a
row moved anywhere else lands in a run of its own and is reported. Verified by
reproducing the defect exactly as the probe produced it, and watching the rule
name the file and the line.

The opening now answers "what is this" before the feature list does. C++ spreads
five jobs across five tools; the table gives mcpp's answer for each, and a second
row names what each column is usually recognised as, so a reader arriving with
CMake, vcpkg or rustup in mind can place the whole tool in one glance.

The highlights had not moved since the tool was a module build system. Two of
the five bullets stated the same thing twice and none of them mentioned a
target other than the host. They now cover the surface the sections below
document: dependencies and workspaces are one bullet, and the two that replace
the freed one state that a target is one flag away and that accelerators and
`build.mcpp` exist. The bundled toolchain versions leave the highlight, since
the host default and the freestanding pin are different versions and this line
is not where that is explained.

Author: speak-agent

.github/tools/check_docs_structure.sh

@@ -18,6 +18,7 @@
 #  12. a citation naming a section lands in the chapter that contains it
 #  13. every table the manifest reference documents is in the lookup index
 #  14. a link labelled with a chapter number points at that chapter
+#  15. every table row is inside a table
 #
 # What it deliberately does NOT check: whether a chapter documents what is
 # implemented, whether an assertion's strength matches its evidence, or whether
@@ -375,6 +376,48 @@ for f in files:
 sys.exit(1 if bad else 0)
 PYLABEL
 
+# ── 15. every table row is inside a table ───────────────────────────────────
+#
+# Rule 10 counts a translation's table rows, and a COUNT cannot see WHERE a row
+# is. One row of the target table was moved to line 1 of README.zh-CN.md, above
+# the document's own title, and rule 10 stayed green at 61 rows against 61: the
+# row was still in the file. What a reader saw was a stray table row before the
+# heading, and only a reader saw it.
+#
+# The check is positional rather than numeric: a maximal run of lines beginning
+# with `|` is a table only if its second line is a delimiter row. A row that has
+# been moved somewhere else lands in a run of its own and has no delimiter.
+python3 - <<'PYROW' || fail=1
+import re, pathlib, sys
+DELIM = re.compile(r"^\|[\s:|-]+\|?\s*$")
+files = (list(pathlib.Path("docs").rglob("*.md"))
+         + [pathlib.Path("README.md"), pathlib.Path("README.zh-CN.md")])
+bad = 0
+for f in files:
+    lines, infence, run = f.read_text(errors="ignore").split("\n"), False, []
+    def close(run):
+        global bad
+        if not run:
+            return
+        if len(run) < 2 or not DELIM.match(run[1][1]):
+            n, text = run[0]
+            print(f"FAIL: {f}:{n}: a table row outside a table: {text[:60]}")
+            bad += 1
+    for n, line in enumerate(lines, 1):
+        if line.startswith("```"):
+            infence = not infence
+            close(run); run = []
+            continue
+        if infence:
+            continue
+        if line.startswith("|"):
+            run.append((n, line))
+        else:
+            close(run); run = []
+    close(run)
+sys.exit(1 if bad else 0)
+PYROW
+
 if [[ "$fail" -eq 0 ]]; then
   echo "OK: docs structure checks pass"
 fi

README.md

@@ -18,13 +18,22 @@
   <img src="https://github.com/user-attachments/assets/6c85896e-9a37-4f62-acfb-d37a4eae2363" alt="mcpp demo" width="720">
 </p>
 
+C++ normally spreads these five jobs across five tools. mcpp is one command for
+all five — the second row names what each column is usually recognised as.
+
+| | build system | build plugins | package manager | toolchain manager | environment and runtime |
+|---|---|---|---|---|---|
+| **mcpp** | module-first C++ on a ninja backend | `build.mcpp` and rule packages | SemVer, a lockfile, package indices | `family@version`, installed on demand | xlings — a user-space environment in an isolated sandbox |
+| **closest to** | CMake + Ninja | CMake modules, xmake rules | vcpkg, Conan | rustup, nvm | conda, Nix |
+
 ## Highlights
 
 - **Native C++23 module support** — `import std` handled automatically, file-level incremental builds, automatic module dependency analysis, zero manual configuration
 - **Pure modular self-hosting** — mcpp is written entirely in C++23 module interface units and builds itself with the pipeline it ships
-- **Works out of the box** — one-command install, bundled GCC 16 / LLVM 20 toolchains downloaded into an isolated sandbox, never polluting your system
-- **Integrated dependency management** — SemVer constraint resolution, lockfile, cross-project BMI cache, custom package indices
-- **Multi-package workspaces** — unified lockfile and version management for larger projects
+- **Works out of the box** — one-command install; the GCC or LLVM toolchain a build needs is downloaded into an isolated sandbox, never polluting your system
+- **Dependencies and workspaces** — SemVer constraint resolution, lockfile, cross-project BMI cache, custom package indices, and multi-package workspaces sharing one lockfile
+- **One flag changes the target** — `--target` reaches from Linux, Windows and macOS to Cortex-M and RISC-V bare metal; the toolchain payload is resolved and installed for you, and a runner puts the artifact on the board
+- **Accelerators, and a way to extend** — CUDA, HIP, SYCL, Vulkan/SPIR-V and Ascend C each have a rule package; a step with no rule is written in `build.mcpp`, and packaged as a rule for other projects
 
 ## Why mcpp
 

README.zh-CN.md

@@ -1,4 +1,3 @@
-| `aarch64-macos`       | llvm(*macOS 默认*) | verified |
 # mcpp
 
 > 一个 现代C++ 模块化构建工具 — 纯 C++23 模块编写，已实现自举
@@ -19,13 +18,22 @@
   <img src="https://github.com/user-attachments/assets/6c85896e-9a37-4f62-acfb-d37a4eae2363" alt="mcpp demo" width="720">
 </p>
 
+C++ 通常把这五件事分给五个工具。mcpp 用一条命令承担全部五件 —— 第二行是每一列
+在既有认知里通常对应的东西。
+
+| | 通用构建系统 | 构建插件 | 包管理 | 工具链管理 | 环境与运行时 |
+|---|---|---|---|---|---|
+| **mcpp** | 模块优先的 C++ 构建，ninja 后端 | `build.mcpp` 与规则包 | SemVer、锁文件、包索引 | `family@version`，按需安装 | xlings —— 隔离沙盒里的用户态环境 |
+| **最接近的** | CMake + Ninja | CMake modules、xmake rules | vcpkg、Conan | rustup、nvm | conda、Nix |
+
 ## 核心特性
 
 - **C++23 模块原生支持** — `import std` 自动处理，文件级增量构建，模块依赖自动分析，零手动配置
 - **纯模块化自举** — mcpp 完全由 C++23 模块接口单元写成，并用它自己发布的这条流水线构建自己
-- **开箱即用** — 一条命令安装，内置 GCC 16 / LLVM 20 工具链，自动下载到隔离沙盒，不污染系统
-- **集成依赖管理** — SemVer 约束解析、锁文件、跨项目 BMI 缓存、自定义包索引
-- **多包工作空间** — Workspace 统一锁文件与版本管理，适合大型项目
+- **开箱即用** — 一条命令安装；构建所需的 GCC 或 LLVM 工具链自动下载到隔离沙盒，不污染系统
+- **依赖与工作空间** — SemVer 约束解析、锁文件、跨项目 BMI 缓存、自定义包索引，以及共用一份锁文件的多包 workspace
+- **换目标只换一个开关** — `--target` 从 Linux、Windows、macOS 一路到 Cortex-M 与 RISC-V 裸机；工具链载荷自动解析安装，产物由 runner 送上板子
+- **加速器，以及扩展的方式** — CUDA、HIP、SYCL、Vulkan/SPIR-V 与 Ascend C 各有规则包；没有现成规则的那一步用 `build.mcpp` 写，并可打成规则包给别人用
 
 ## 为什么选择 mcpp
 
@@ -396,6 +404,7 @@ mcpp 的身份模型是两条正交轴:**工具链** = `family@version`(family 
 | `x86_64-windows-gnu`  | gcc 16 MinGW-w64——Windows 原生,Linux 交叉(wine)(*无 Visual Studio 时的 Windows 默认*) | verified |
 | `x86_64-windows-msvc` | `msvc@system`(探测 VS/BuildTools)或 llvm ¹(*有 Visual Studio 时的 Windows 默认*) | verified |
 | `x86_64-windows-musl` | llvm 22——带 musl C 库的 PE,没有 gcc 能产出它;系统由依赖图供给 | preview |
+| `aarch64-macos`       | llvm(*macOS 默认*) | verified |
 | `riscv64-none-elf` · `riscv32-none-elf` | llvm 22——裸机,`xim:picolibc-riscv` ² | verified |
 | `thumbv6m-none-eabi` · `thumbv7m-none-eabi` | llvm 22——Cortex-M0/M0+/M1、Cortex-M3 ² | verified |
 | `thumbv7em-none-eabihf` · `thumbv8m.main-none-eabi` | llvm 22——Cortex-M4F/M7F 硬浮点、Cortex-M33/M55 软浮点 ² | verified |