@@ -1402,9 +1402,16 @@ each with a phase-local context struct where several of its steps share locals.
 Readings on the final tree: the gate reports no function over 400 lines; the
 seven fixtures are byte-identical to the pre-split binary; AddressSanitizer
 reports nothing over the fixtures and a 20-script e2e subset; the unit suite
-passes. The gate runs in `ci-linux.yml`'s LLVM toolchain job after mcpp builds
-itself with llvm@20.1.7, with clang-tidy from `xim:llvm-tools` at the version
-that wrote the compile database, because it reads that clang's BMIs. The merge
+passes. The gate was wired into `ci-linux.yml`'s LLVM toolchain job, after the
+step that builds mcpp with llvm@20.1.7, and crashed there: that build has
+never completed (libc++ 20's `std` module hides `directory_iterator`'s
+comparison), and the step reads the resolution line rather than the build's
+exit status, so the job reports success on `main` too. The step came out again,
+the gate's finding filter was narrowed to diagnostic lines (the crash dump named
+the check and every file and had read as a finding), and #729 records the step
+and the wiring. The gate resolves clang-tidy from `xim:llvm-tools` at the
+version that wrote the compile database, because it reads that clang's BMIs,
+and is run by hand after `mcpp build --toolchain llvm@22.1.8`. The merge
 of the first pass took `plan.cpp` to 2,505 lines, over the file gate; the
 records half of P13 (`mcpp.lock`, `resolution.json`) moved to `records.cpp`,
 byte-identical on the same fixtures.
@@ -30,9 +30,16 @@
 # A compile database that names BMIs explicitly (-fmodule-file=...), which
 # only a build actually produces: `mcpp build --toolchain llvm@22.1.8` writes
 # compile_commands.json at the project root. This script does not build it:
-# the caller runs that build first (a developer, or ci-linux.yml's LLVM
-# toolchain job, which builds mcpp with llvm@20.1.7 before this step).
-# check_file_lengths.sh needs no such division because it reads the tree.
+# the caller runs that build first. check_file_lengths.sh needs no such
+# division because it reads the tree.
+#
+# NOT IN CI YET. The only CI job that builds mcpp with clang (ci-linux.yml,
+# "toolchain: musl + llvm", llvm@20.1.7) does not produce a complete build:
+# libc++ 20's `std` module does not make directory_iterator's comparison
+# visible, and that step reads the resolution line rather than the build's
+# exit status. Over the partial database clang-tidy crashes. The gate is wired
+# in once a CI job builds mcpp with clang (mcpp-community/mcpp#729); until
+# then it is run by hand after `mcpp build --toolchain llvm@22.1.8`.
 #
 # clang-tidy itself is not part of the plain xim:llvm payload mcpp resolves
 # for `--toolchain llvm@...` (measured: xim-x-llvm/22.1.8/bin has clang,
@@ -150,7 +157,10 @@ rc=$?
 # Only findings inside the decomposition's own directory gate the build: a
 # bundled third-party header (e.g. modules/libs/src/json/json.hpp) reached
 # through one of these files' imports is not this decomposition's to fix.
-relevant=$(grep "readability-function-size" "$OUT" | grep -F -e "/$DIR/" -e "/$(basename "$PRIMARY")" || true)
+# A finding is a diagnostic line, which ends with the bracketed check name; a
+# crash dump also names the check (in its program arguments) together with
+# every file path, and must not read as a finding.
+relevant=$(grep -E '\[readability-function-size\]$' "$OUT" | grep -F -e "/$DIR/" -e "/$(basename "$PRIMARY")" || true)
 
 if [ -n "$relevant" ]; then
     echo "$relevant" >&2
 
@@ -253,16 +253,6 @@ jobs:
           # Restore
           sed -i 's/^default = "llvm@20.1.7"/default = "gcc@16.1.0"/' mcpp.toml
 
-      # The function-size gate (mcpp#722) reads clang-tidy's own function
-      # boundaries over the compile database the LLVM build above wrote, so it
-      # runs here, where mcpp itself was just built with clang. clang-tidy is
-      # the sibling payload xim:llvm-tools at that clang's version, because it
-      # reads the BMIs that clang wrote.
-      - name: "Function-size gate (src/build/prepare, clang-tidy)"
-        run: |
-          XLINGS_HOME="$MCPP_HOME/registry" "$XLINGS_BIN" install xim:llvm-tools@20.1.7 -y
-          bash .github/tools/check_function_sizes.sh
-
   # Integration: the mcpp built from THIS PR's source builds & runs a real
   # external C++ project — xlings (openxlings/xlings ships its own mcpp.toml).
   # MCPP_VENDORED_XLINGS only supplies the xlings package backend that mcpp
 
@@ -70,8 +70,8 @@
 - **`src/build/prepare/` 的阶段函数按其小节拆分(#722)。** 代码逐字移动,不改变语句顺序;七个
   夹具的 `resolution.json`、`build.ninja` 与构建数据库输出与拆分前逐字节相同。该目录下没有超过
   400 行的函数:`.github/tools/check_function_sizes.sh` 以 clang-tidy 的 `readability-function-size`
-  在 LLVM 自举构建之后检查,拆分前报告 10 处。`mcpp.lock` 与 `resolution.json` 的写入移入
-  `records.cpp`。
+  在以 LLVM 构建得到的编译数据库上检查,拆分前报告 10 处;CI 中尚无能完整构建 mcpp 的 clang 任务,
+  接入见 #729。`mcpp.lock` 与 `resolution.json` 的写入移入 `records.cpp`。
 - **xlings 固定版本为 2026.9.28.1。** 该版本的 interface 协议为 1.2:`update_packages` 按阶段发出
   进度事件,interface 能力运行期间写到标准输出的文本不再混入事件流(openxlings/xlings#625)。
 
 
@@ -371,7 +371,14 @@ static std::expected<void, std::string> step13_make_plan(PrepareState& state, Bu
     // SPEC-007 R4.3: a declared deploy outranks a search directory's file of
     // the same name, and a difference between the two is said here, where
     // the user sees it (the post-link placement edge says it only under -v).
+    // A declared source that an action writes is left to that edge: at
+    // planning it may still hold the previous build's bytes.
+    std::set<std::filesystem::path> actionOutputs;
+    for (auto const& a : ctx.plan.actions)
+        for (auto const& o : a.outputs)
+            actionOutputs.insert(std::filesystem::path(o).lexically_normal());
     for (auto const& s : ctx.plan.shadowedSearchDirDlls) {
+        if (actionOutputs.contains(s.declared.lexically_normal())) continue;
         std::error_code ec;
         if (std::filesystem::is_regular_file(s.declared, ec)
             && !mcpp::build::stage::same_content(s.declared, s.offered))