diff --git a/context/test-evidence/clients.md b/context/test-evidence/clients.md
index f6b47dee..9b26784c 100644
--- a/context/test-evidence/clients.md
+++ b/context/test-evidence/clients.md
@@ -1405,6 +1405,61 @@ does not mutate" would hold only for the first click of a session, since every
 click after the first is a "second click" in the loose reading. Clicking A then
 B must select B.
 
+#### How to know a launch default has stopped disarming things
+
+The question this left open was **how to know you have exhausted the class**.
+Grep does not answer it: grep finds sites that *name* the flag, and the hazard
+is a test that merely **starts from a default-built state** and asserts
+something downstream, mentioning nothing. Three disarmed tests were found by
+grepping `category_panel_open`; that was luck, not method.
+
+**Mutation answers it, because it does not care what a test mentions.** The
+recipe, which a reviewer ran across five sites in about twenty minutes:
+
+> For every production site that **writes, propagates or reads** the value,
+> replace it with the constant the default supplies, and run
+> `--no-fail-fast`. Sites where nothing fails are suspects. Then **re-run each
+> suspect with the default inverted.** If it now fails something, the test was
+> **vacuous** — the default disarmed it, and the fix is the fixture. If it
+> still fails nothing, it was simply **unguarded** — a different problem,
+> pre-existing, and a bead rather than a fixture.
+
+**The second step is the one that matters**, and without it the two classes are
+indistinguishable: both look like "nothing failed". It is what established that
+the class is closed at **two** (`set_panel_open_and_cursor`,
+`panel_commands_address_the_named_panel_only`) and that two further silent sites
+are older problems this ruling did not cause:
+
+- `ui/app.rs`'s `App::cmd_context` propagator — hardcode it `true` and the whole
+  workspace passes. `registry.rs` reads it for `toggle-panel-and-focus`'s
+  open-vs-close decision, so `C` on a closed panel would decide to *close* and
+  nothing would fail. Invisible because `cmd/mod.rs`'s test helper sets the
+  field explicitly, so no command test reaches the propagator. Filed.
+- `improvise-wasm-client/src/render.rs`'s `RenderModel` field — hardcode it
+  `true` and **Rust sees nothing at all**; only the Chromium harness catches it,
+  at `contract.spec.js`'s `toBeHidden`. That is literally improvise-wsaw
+  reintroduced one layer up, and **a Rust-only CI run cannot see it** — which is
+  the sharpest argument on file for why the browser job must be able to fail the
+  build.
+
+Note `resolve.rs`'s `panel_open` reader is **well** guarded by contrast:
+hardcoding it `true` fails two click tests. So the picture is not "everything
+touching this flag is untested"; it is specifically the propagators.
+
+### the_terminal_constructor_inherits_the_shared_default_rather_than_setting_it
+
+**Prospective rather than present-tense, and the doc comment says so.** With
+three panels, `the_terminal_app_launches_with_the_category_panel_open` and
+`the_other_two_panels_are_shut_at_launch` already cover every `Panel::ALL`
+member, so this test cannot currently fail without one of them failing too. A
+reviewer confirmed that by control.
+
+It earns its place the way gotcha 12 describes `Panel::ALL`: a **fourth** panel
+reaches it from one `ALL` entry, and at that moment it becomes the only test
+asserting that `App::new` did not quietly give the TUI its own launch state —
+the divergence improvise-wsaw closed. Recorded here so nobody later reads a
+green tick as evidence of something it is not yet checking.
+
 ### the_terminal_app_launches_with_the_category_panel_open
 
 The user ruled (2026-09-20) that the category sidebar is visible at launch in
diff --git a/tests/tui_launch_state.rs b/tests/tui_launch_state.rs
index 8e724de6..0a69dac2 100644
--- a/tests/tui_launch_state.rs
+++ b/tests/tui_launch_state.rs
@@ -28,8 +28,8 @@ fn the_other_two_panels_are_shut_at_launch() {
     assert!(!app.view_state.view_panel_open, "views stay shut");
 }
 
-/// `App::new` is the TUI's own constructor, so it could override the shared
-/// default without the protocol-level test noticing. It must not.
+/// `App::new` could override the shared default without the protocol test
+/// noticing. PROSPECTIVE with three panels — see the evidence file.
 #[test]
 fn the_terminal_constructor_inherits_the_shared_default_rather_than_setting_it() {
     let shared = improvise::ui::app::ViewState::default();