docs(tests): record how to know a launch default has stopped disarming tests

The question PR #60 left open was not which tests the launch default
disarmed, but HOW TO KNOW THE CLASS IS CLOSED. Grep cannot answer it: it
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. Finding the three disarmed tests by grep was luck.

Mutation answers it, because it does not care what a test mentions.
Recorded in context/test-evidence/clients.md: mutate every site that
writes, propagates or reads the value to the constant the default
supplies; sites where nothing fails are suspects; then RE-RUN EACH
SUSPECT WITH THE DEFAULT INVERTED. If it now fails, the test was
vacuous -- the default disarmed it, fix the fixture. If it still fails
nothing, it was simply unguarded -- pre-existing, file it.

That second step is the whole method. Without it the two species are
indistinguishable (both look like "nothing failed"), and it is what
established that the vacuity class is closed at TWO rather than three.

It found two further silent sites, neither caused by the ruling:

- App::cmd_context propagates the flag and nothing tests it. Stuck
  true, `C` on a CLOSED panel decides to close it -- the panel becomes
  unopenable by its own key -- with the workspace green. Invisible
  because the command test helper builds the value it then asserts on.
  Filed as improvise-qsmp; control run proves it predates the ruling.
- render.rs propagates it into RenderModel. Stuck true is improvise-wsaw
  reintroduced one layer up, and RUST SEES NOTHING -- only the Chromium
  harness catches it. A Rust-only run of the `test` job cannot see a
  reintroduced wsaw, which is the sharpest argument on file for the
  browser job being able to fail the build.

Also marks the_terminal_constructor_inherits_the_shared_default_rather_than_setting_it
PROSPECTIVE: with three panels its two siblings already cover every
Panel::ALL member, so it cannot fail alone today. It earns its place the
way gotcha 12 describes Panel::ALL -- a fourth panel reaches it from one
entry -- and saying so stops a green tick being read as present-tense
evidence.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FC2jVn8Au7E9JPkw6bwXXH

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

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();