SOLIDWORKS Bridge

@@ -347,7 +347,22 @@ not.  ## Roadmap -- v0.6.7 (this): **ordering is not equality — a consent-affecting bug I shipped+- v0.6.8 (this): **unit-tested is not wired.** `identity_matches_attribution`+  shipped in 0.6.7 with ZERO production callers — the fifth guard in this project+  to do that, and the third about attribution. The commit message said it was+  wired into `swx_stop`; the edit that would have wired it was in a script that+  aborted partway through, and nobody checked the file. Every test was green,+  because every test tested the function. It is now called from `swx_stop` (at the+  front gate AND in the per-rung re-sweep), `swx_close_all_documents` and+  `swx_reset_workspace`, each with a test that drives the VERB and asserts+  `identity_mismatch` in its response — mutation-checked by deleting the CALL+  SITE, leaving the function and its unit tests untouched. And `tests/wiring.rs`+  now lists every guard in the bridge and fails if any has no production caller,+  so retiring one is a decision somebody makes rather than a silent edit. The+  audit that built that list found exactly one other candidate, and it was a false+  alarm: `hwnd_still_owned`'s only caller lives in `#[cfg(windows)]` code. 301+  tests.+- v0.6.7: **ordering is not equality — a consent-affecting bug I shipped   in 0.6.6.** That release fixed the walk to try every `sldworks.exe`, and used   the COM-attached pid only to ORDER the candidates, taking the first that   descended. With two SOLIDWORKS running it could therefore prove lineage for our

@@ -908,3 +908,37 @@ registry in `owned-docs.json` keyed to the SOLIDWORKS process and treats an unre Still unproven live: the launch routes (needs SOLIDWORKS closed), and a graceful quit — the `Process.CloseMainWindow()` experiment was blocked by the agent-side auto-mode classifier, see docs/QUIT-INVESTIGATION.md.++## The rule this project keeps having to learn: unit-tested is not wired++Five guards in this bridge have shipped **unit-tested and with no production+caller**. Three of them were about attribution — the part of the system whose+entire job is to decide what this bridge may touch.++The most recent, `identity_matches_attribution` (0.6.7), is the clearest case.+The function was written, unit-tested, described in a commit message as "wired+into swx_stop", and reviewed. It had zero callers: the edit that was supposed to+insert the call was in a script that aborted partway through on an unrelated+assertion, and nobody checked the file afterwards. Every test was green, because+every test tested the function.++**A unit test proves a function behaves. It says nothing about whether anything+calls it.** The two facts are independent, and only one of them was being+checked.++So, as of 0.6.8, two rules — both enforced mechanically rather than remembered:++1. **A guard ships with a verb-level test that reaches it.** Not a test of the+   function: a test that drives the VERB and asserts on the verb's response. The+   check is a mutation — delete the CALL SITE, leaving the function and its unit+   tests untouched, and the verb-level test must fail. If it still passes, the+   test is not reaching the guard and the guard is not doing anything.+2. **`tests/wiring.rs` lists every guard and fails if any has no production+   caller.** It is a text scan with `#[cfg(test)]` blocks stripped — crude,+   because the failure it catches is crude. Retiring a guard means removing its+   line from that list, which makes deleting a guard a decision somebody makes on+   purpose rather than a silent edit.++The audit that produced the list found one unwired guard+(`identity_matches_attribution`); `hwnd_still_owned`'s only caller is inside+`#[cfg(windows)]` code, which is a production caller and counts.