docs: stop citing workbench paths that are not shipped

Eight citations in the reference documents pointed at tools/ paths, and .gitignore excludes tools/ -- so neither an installed skill nor a clone of this repository can open them. Each is now either an inline statement of the fact or a pointer to the evidence file under docs/tool-verification/ that actually holds it. One of the eight was introduced by the benchmark pass itself (protocol-reverse.md cited a workbench script).

The evidence records keep quoting tools/_work/... deliberately: there they are operation records of where a run happened. docs/tool-verification/README.md now states that distinction and the rule that follows from it -- a reference document never cites a tools/ path as its evidence, even when the work happened there.

docs/tool-verification/README.md

@@ -12,7 +12,13 @@ build time) the figure is kept and the target is named generically.
 
 Targets measured: Flutter AOT applications, multi-dex, mid-size native library sets, no packer.
 
-The APKs themselves are **not** in this repository (`.gitignore` excludes `*.apk`).
+The APKs themselves are **not** in this repository (`.gitignore` excludes `*.apk`, and `tools/`).
+
+**Workbench paths are an operation record, not a pointer.** A record may say a run happened *at*
+`tools/_work/...` so the command can be judged; `.gitignore` excludes `tools/`, so that path is not
+something a reader can open. Anything a reader is *meant* to follow is named under
+`docs/tool-verification/` or inside the skill — that rule is why a reference document never cites a
+`tools/` path as its evidence, even when the work happened there.
 
 ## Strength labels
 

skills/apk-reverse/references/kernel-and-environment-hardening.md

@@ -92,14 +92,13 @@ documentation (sources at the end of the section); none were re-measured here
 
 Sources: KernelSU README + FAQ (github.com/tiann/KernelSU), APatch FAQ (apatch.dev, project
 originally at github.com/bmax121/APatch), fetched 2026-09. Device facts (Magisk alpha on kernel
-4.14.186) are `observed` in `tools/_phone-modules/README-手机模块环境.md`.
+4.14.186) are `observed` on the reference device used for this pass.
 
 ## 3. Environment-hiding modules: Zygisk-Assistant vs Shamiko
 
 Both are Zygisk modules that hide root + Zygisk from target apps. **Do not install both** — they
 overlap in function (mount-namespace handling, trace wiping) and interfere; this is documented in
-the module ecosystems and was the deciding fact on the reference device (`observed` in
-`tools/_phone-modules/README-手机模块环境.md`: Shamiko kept as a backup zip, uninstalled).
+the module ecosystems and was the deciding fact on the reference device (`observed`: Shamiko kept as a backup zip and uninstalled there).
 
 The practical difference is their **denylist dependency** (from each project's own README,
 `inferred`):
@@ -117,7 +116,7 @@ ZygiskNext) is the supported path. The denylist/enforcement settings are the par
 wrong: **enforcement off, list populated** is the working combination for both.
 
 Verification status: neither module's hiding effect was tested against a real detector on the
-reference device (`tools/_phone-modules/README-手机模块环境.md` §未覆盖的验证) — treat every
+reference device — treat every
 "this hides X" claim above as documented-but-unproven here.
 
 ## 4. Kernel-level interception — the map, and the version gate
@@ -137,7 +136,7 @@ uname -r            # on the device. The gate for most of this section is 5.10+
   expects it) targets GKI kernels. Source: the Android kernel architecture documentation on
   source.android.com (GKI and eBPF pages). On the reference
   device (kernel **4.14.186**) this entire row is **closed** — `observed` (the version), with the
-  consequence recorded in `tools/_phone-modules/README-MCP与网络环境.md`: eBPF-based tooling
+  consequence that eBPF-based tooling
   (stackplz, mcp-termux's tracing half) is unavailable there. Write the one-line environment fact
   per `detection-and-anti-analysis.md` Step 5 and do not revisit it.
 
@@ -255,7 +254,7 @@ rather than to any tool:
 ## 6. What the reference environment chose (and why it generalises)
 
 On the 4.14-kernel reference device, the escalation ladder terminates early — and that is the
-honest outcome (`observed`, from `tools/_phone-modules/README-*.md`):
+honest outcome (`observed` on that device):
 
 | Layer | Status on a 4.14 Magisk device |
 |---|---|

skills/apk-reverse/references/on-device-tooling.md

@@ -6,7 +6,7 @@ is no laptop in the loop. This file covers the **on-device toolchain** and — m
 when each tool beats its PC counterpart and when it does not.
 
 Evidence basis: the facts below come from a real configured environment (Android 11, Magisk +
-Zygisk, LSPosed v1.9.2, MT Manager 2.26.9), archived in `tools/_phone-modules/`. Framework
+Zygisk, LSPosed v1.9.2, MT Manager 2.26.9). Framework
 activation and the module set are `observed` there; per-workflow usability notes are `measured`
 where marked, otherwise `inferred`. The MT MCP tool surface is from MT's official documentation
 (`observed` as a list; live invocation requires the service to be running — see §2).
@@ -87,7 +87,7 @@ code 2 — usable as a loop check ("is it up yet") while you start it by hand. `
 LSPosed (via Zygisk) gives you a **Java-layer hook platform that needs no PC at runtime**: write/
 install a module once, and it applies to target apps at every launch.
 
-Facts from the reference environment (`observed`, archived in `tools/_phone-modules/`):
+Facts from the reference environment (`observed`):
 
 - Activation is verifiable from logs: the `ZygiskCompanion: welcome to LSPosed!` banner, the
   version line, the `lspd` daemon process running as system.

skills/apk-reverse/references/protocol-reverse.md

@@ -31,9 +31,9 @@ sequence". That is the whole format; the schema supplies meaning and nothing els
 | Wire type 5 | fixed 4 bytes (fixed32/sfixed32/float) |
 | Wire types 3/4 | group start/end, legacy; treat as unsupported when walking a modern payload |
 
-A host-side check of the rules, including the canonical `150 -> 96 01`, lives in
-`tools/_work/t4-dbi/pb_selftest.py` (workbench, not shipped with the skill). Measured output on the
-fixture built there:
+A host-side check of the rules, including the canonical `150 -> 96 01`, was run independently of the
+shipped decoder — `docs/tool-verification/EXTENSION-protobuf-raw.md` records that cross-check against
+the official runtime. Measured output on the fixture built for it:
 
 ```
 message (29 B): 089601120774657374696e671a0508011201782206038e029ea7052800