aru-code 0.45.0__tar.gz → 0.46.0__tar.gz

{aru_code-0.45.0/aru_code.egg-info → aru_code-0.46.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aru-code
-Version: 0.45.0
+Version: 0.46.0
 Summary: A Claude Code clone built with Agno agents
 Author-email: Estevao <estevaofon@gmail.com>
 License-Expression: MIT

aru_code-0.46.0/aru/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.46.0"

{aru_code-0.45.0 → aru_code-0.46.0}/aru/tui/app.py

@@ -245,6 +245,11 @@ class AruApp(App):
         Binding("ctrl+b", "toggle_sidebar", "Sidebar", show=True),
         Binding("ctrl+y", "copy_last", "Copy last", show=True),
         Binding("ctrl+shift+y", "copy_all", "Copy all", show=False),
+        # Layer 13 — user-invoked terminal recovery. priority=True so the
+        # binding fires before any focused widget can absorb the key, in
+        # case Textual ever reclassifies ctrl+r as printable on some
+        # platform. See ``action_recover_terminal`` for what it does.
+        Binding("ctrl+r", "recover_terminal", "Recover", show=True, priority=True),
         Binding("up", "history_prev", "Prev", show=False, priority=False),
         Binding("down", "history_next", "Next", show=False, priority=False),
     ]
@@ -1123,79 +1128,105 @@ class AruApp(App):
             # without waiting for the periodic Layer 10 tick.
             self._reenable_mouse_tracking()
 
-    # Layer 12 — DEC private-mode sequences for mouse tracking. Defined
-    # at class scope so both the off-then-on shake below and any future
-    # caller (Click handler, focus event) can reuse the exact same set
-    # without drift.
-    _MOUSE_DISABLE_SEQS: tuple[str, ...] = (
-        "\x1b[?1000l",
-        "\x1b[?1003l",
-        "\x1b[?1015l",
-        "\x1b[?1006l",
+    # Layer 14 — full set of DEC private modes that ``WindowsDriver
+    # .start_application_mode`` enables at boot, minus alt-screen
+    # (``?1049``, not idempotent — would save/restore the display
+    # buffer) and kitty-keyboard (``>1u``, terminal-specific, doesn't
+    # affect wheel). Layer 13 introduced this set as a Ctrl+R-only
+    # heavy shake; user confirmation that Ctrl+R actually recovered
+    # the wheel after Windows display sleep/wake (2026-04-25) is the
+    # signal that the broader set is what works in practice — the
+    # mouse-only shake from Layer 12 was insufficient. Layer 14 promotes
+    # the full set into ``_reenable_mouse_tracking`` so every existing
+    # caller (Layer 9 turn boundary, Layer 10 periodic tick, Layer 12
+    # broken keypress) gets the proven recovery automatically.
+    _FULL_MODE_DISABLE_SEQS: tuple[str, ...] = (
+        "\x1b[?1000l",  # mouse VT200
+        "\x1b[?1003l",  # any-event mouse
+        "\x1b[?1015l",  # VT200 highlight mouse
+        "\x1b[?1006l",  # SGR ext mode mouse
+        "\x1b[?1004l",  # focus events
+        "\x1b[?2004l",  # bracketed paste
     )
-    _MOUSE_ENABLE_SEQS: tuple[str, ...] = (
+    _FULL_MODE_ENABLE_SEQS: tuple[str, ...] = (
         "\x1b[?1000h",
         "\x1b[?1003h",
         "\x1b[?1015h",
         "\x1b[?1006h",
+        "\x1b[?1004h",
+        "\x1b[?2004h",
     )
 
     def _reenable_mouse_tracking(self) -> None:
-        """Re-arm mouse tracking via an off-then-on shake (Layer 12).
-
-        Pre-Layer-12 this method delegated to the driver's
-        ``_enable_mouse_support`` which writes four short SGR sequences
-        (``?1000h`` / ``?1003h`` / ``?1015h`` / ``?1006h``). That worked
-        when the terminal forwarded the writes verbatim, but the user
-        report on 2026-04-25 against
-        ``final-fantasy-9/.aru/sessions/b33dfb99`` was the wheel never
-        coming back even though Layer 9 (turn-boundary call) and Layer 10
-        (8s tick) both ran. Two failure modes the old code couldn't
-        recover from:
-
-        1. **ConPTY enable cache.** Windows ConPTY tracks DEC private-mode
-           state on its side and may treat ``?1000h`` as a no-op when its
-           cache says "already enabled" — even when the underlying
-           terminal lost the state. Sending ``?1000l`` first forces the
-           cache through a state transition so the subsequent ``?1000h``
-           is propagated.
-        2. **Driver-side gate.** ``WindowsDriver._enable_mouse_support``
-           opens with ``if not self._mouse: return`` (textual 8.2.4,
-           windows_driver.py:55). If a future Textual flips the gate
-           during shutdown / pause / alt-screen toggle, our recovery
-           silently no-ops. Going through ``driver.write`` bypasses the
-           gate and writes the bytes regardless.
-
-        Implementation: emit all four ``...l`` (off) sequences, then all
-        four ``...h`` (on) sequences, then flush. Eight short writes
-        (~64 bytes) bufferised into one terminal emit by ``WriterThread``.
-        Idempotent on a healthy terminal — the off→on cycle leaves the
-        final state identical to a single ``?1000h``, just with a
-        microscopic gap during the transition (no observable wheel-event
-        loss in practice).
-
-        Called from three sites:
-        * ``_run_turn`` finally-clause (Layer 9) — eager recovery at every
-          turn boundary so the first post-turn scroll always works.
-        * ``_self_heal_terminal_state`` periodic tick (Layer 10) — recovers
-          mid-turn corruption within ``_MOUSE_REENABLE_INTERVAL``.
-        * ``on_key`` keypress trigger (Layer 12) — recovers the moment the
-          user touches the keyboard, since a keystroke is a strong signal
-          they noticed the wheel is dead.
-
-        Wrapped in ``try/except`` because the driver may be ``None`` in
-        headless / test mode; we'd rather no-op silently than crash.
+        """Re-arm terminal modes via console-mode re-assert + full-mode shake.
+
+        Single recovery primitive used by every layer: turn boundary
+        (Layer 9), periodic tick (Layer 10), keypress trigger (Layer 12,
+        broken — see chat.py post-mortem), and ``Ctrl+R`` action (Layer
+        13, which adds a refresh + chat message on top). The method
+        keeps its name (``_reenable_mouse_tracking``) for git-blame
+        continuity even though it now re-arms more than just mouse —
+        what it does is documented here, and the post-mortem in
+        chat.py traces the evolution from Layer 12 through Layer 14.
+
+        Two failure modes the recovery handles:
+
+        1. **``ENABLE_VIRTUAL_TERMINAL_INPUT`` cleared on stdin (Windows).**
+           ``enable_application_mode`` (textual win32.py:179) sets this
+           flag at startup, but a display sleep / wake or other Windows
+           console state transition can clear it. While cleared,
+           ConPTY stops translating mouse / focus events into VT
+           sequences and *no* stdout escape we write can recover wheel
+           input. Re-asserting the flag additively (``current | flag``)
+           preserves any other input flags while ensuring VT input
+           translation is back on.
+
+        2. **DEC private-mode state lost on the terminal side.** Layer
+           12 originally addressed this for mouse-only via an off-then-on
+           shake (``?1000l → ?1000h``) to defeat ConPTY's enable-cache.
+           Layer 14 widens the shake to the full set ``WindowsDriver
+           .start_application_mode`` enables: mouse (4 modes) + focus
+           events (``?1004``) + bracketed paste (``?2004``). 12 escapes
+           total off-then-on, ~108 bytes, one flush. Excluded:
+           alt-screen (not idempotent) and kitty-keyboard (terminal-
+           specific, doesn't affect wheel). The user report on
+           2026-04-25 confirmed the mouse-only shake didn't recover
+           the wheel after display wake but the full shake (via Ctrl+R)
+           did — Layer 14 promotes that proven recovery into the auto
+           path.
+
+        Cost per call: ~108 bytes + one ``GetConsoleMode`` +
+        ``SetConsoleMode`` syscall pair on Windows. At the 3s tick
+        rate that is ~36 B/s plus microseconds — negligible.
+
+        Wrapped in ``try/except`` everywhere because the driver may be
+        ``None`` in headless / test mode and the win32 import may fail
+        on non-Windows; we'd rather no-op silently than crash.
         """
+        if sys.platform == "win32":
+            try:
+                from textual.drivers.win32 import (
+                    ENABLE_VIRTUAL_TERMINAL_INPUT,
+                    get_console_mode,
+                    set_console_mode,
+                )
+                current = get_console_mode(sys.__stdin__)
+                set_console_mode(
+                    sys.__stdin__, current | ENABLE_VIRTUAL_TERMINAL_INPUT
+                )
+            except Exception:
+                pass
+
         try:
             driver = self._driver
             if driver is None:
                 return
-            for seq in self._MOUSE_DISABLE_SEQS:
+            for seq in self._FULL_MODE_DISABLE_SEQS:
                 try:
                     driver.write(seq)
                 except Exception:
                     pass
-            for seq in self._MOUSE_ENABLE_SEQS:
+            for seq in self._FULL_MODE_ENABLE_SEQS:
                 try:
                     driver.write(seq)
                 except Exception:
@@ -1449,6 +1480,46 @@ class AruApp(App):
         except Exception:
             pass
 
+    def action_recover_terminal(self) -> None:
+        """Layer 13 — user-invoked terminal-state recovery (Ctrl+R).
+
+        Delegates the recovery sequence (Windows console-mode re-assert
+        + full DEC private-mode shake + flush) to
+        ``_reenable_mouse_tracking`` — that method now does the strong
+        shake for every layer (Layer 14 promotion), so Ctrl+R, the 3s
+        tick, and the turn-boundary call all run identical recovery
+        bytes. This action adds two extras unique to the manual path:
+
+        * ``self.refresh()`` to force a compositor redraw — the
+          autonomous paths don't need this because the next paint
+          cycle handles it; Ctrl+R is interactive and the user wants
+          immediate visible confirmation.
+        * **Visible chat message** so the user sees the recovery did
+          execute. The user explicitly noted that silent recovery is
+          indistinguishable from no recovery, so we surface it on the
+          manual path. Periodic / turn-boundary callers stay silent
+          to avoid spamming the chat.
+
+        Bound to ``Ctrl+R`` with ``priority=True`` so the binding fires
+        regardless of focused widget. Bindings dispatch via Textual's
+        binding system, not through ``_on_key``, so this path is immune
+        to the ``Input._on_key → event.stop()`` problem that breaks
+        Layer 12's keypress trigger.
+        """
+        self._reenable_mouse_tracking()
+
+        try:
+            self.refresh()
+        except Exception:
+            pass
+
+        try:
+            self.query_one(ChatPane).add_system_message(
+                "[Ctrl+R] Terminal modes re-armed (mouse / focus / paste)"
+            )
+        except Exception:
+            pass
+
     def action_toggle_sidebar(self) -> None:
         """Hide / show the right sidebar to give the chat full width."""
         try:

{aru_code-0.45.0 → aru_code-0.46.0}/aru/tui/widgets/chat.py

@@ -423,6 +423,184 @@ the recovery sequence itself can be ineffective; let's make the
 recovery actually do something". The two stack: tick still runs,
 keypress trigger gives it sub-second latency, off-on shake makes the
 sequence the tick emits actually take effect.
+
+----
+
+Post-mortem — "no self-heal of Layers 9/10/12 actually recovers"
+(2026-04-25, ``fix/scroll-analysis3``)
+---------------------------------------------------------------------
+**Symptom:** user reported on a Windows display-sleep/wake scenario
+that the wheel dies and *no* existing self-heal recovers it. They
+explicitly observed: "não vi nenhum self healing seu funcionar até
+agora", and confirmed that even sending a message (which fires the
+Layer 9 turn-boundary call) does not bring the wheel back.
+
+**Two distinct root causes (one structural, one effectiveness):**
+
+1. **Layer 12's keypress trigger is dead during normal typing.**
+   ``Input._on_key`` in textual 8.x calls ``event.stop()`` for any
+   ``event.is_printable`` key (``textual/widgets/_input.py:736-737``).
+   The event is consumed at the widget level and never bubbles to
+   ``App.on_key``, so ``_maybe_rearm_mouse_on_keypress`` is never
+   invoked while the user types. The Layer 12 tests
+   (``tests/test_tui_layer12_recovery.py:109-116``) call the method
+   directly and never exercise the real path, so the bug shipped
+   silently. Only non-printable keys (Ctrl+combinations, arrows, Esc)
+   reach ``App.on_key``, and those also bypass it via the BINDINGS
+   system — which dispatches actions directly, again skipping
+   ``on_key``. In short: **Layer 12 keypress recovery never fires in
+   any production scenario**.
+
+2. **The off-then-on shake of mouse-only is not sufficient for the
+   user's failure mode.** Layer 9 (turn boundary) and Layer 10 (3s
+   tick) both fire ``_reenable_mouse_tracking``, which re-emits four
+   mouse DEC private modes. But ``WindowsDriver.start_application_mode``
+   enables a wider set at boot: mouse + focus-events (``?1004h``) +
+   bracketed paste (``?2004h``) + kitty-keyboard. If the display
+   sleep/wake corrupts more than just mouse — e.g. the entire VT
+   private-mode block on Windows Terminal's side — re-emitting only
+   mouse leaves the rest dead and the wheel doesn't come back. There
+   is also a possibility that ``ENABLE_VIRTUAL_TERMINAL_INPUT`` on
+   stdin gets cleared on wake, in which case **no** stdout escape we
+   write can recover wheel input regardless of what we send, because
+   ConPTY stops translating mouse events into VT on the input side.
+
+**Layer 13 — user-invoked guaranteed-fire recovery (Ctrl+R).**
+``AruApp.action_recover_terminal`` (``app.py``) does four things in
+order:
+
+a. **Re-asserts ``ENABLE_VIRTUAL_TERMINAL_INPUT`` on stdin (Windows
+   only)** via ``set_console_mode(stdin, current | flag)``. Aditive so
+   other input flags survive. Closes the input-side hypothesis from
+   root cause 2.
+
+b. **Off-then-on shakes the FULL DEC private mode set** —
+   ``_FULL_MODE_DISABLE_SEQS`` / ``_FULL_MODE_ENABLE_SEQS`` cover
+   mouse + focus-events + bracketed-paste. Excludes alt-screen
+   (``?1049``, not idempotent — would save/restore the display) and
+   kitty-keyboard (terminal-specific, doesn't affect wheel). 12
+   escapes total, ~108 bytes, one flush. Broader than Layer 12's
+   four-mode shake, so it catches whatever the wake corrupted even
+   if we don't know exactly what dropped.
+
+c. **``self.refresh()``** to force a compositor redraw. Covers the
+   case where Textual's view of the screen drifted from terminal
+   reality.
+
+d. **Visible system message** in the chat
+   (``[Ctrl+R] Terminal modes re-armed...``). The user explicitly
+   said silent recovery is indistinguishable from no recovery, so
+   we surface that the action did fire — separating "Aru's recovery
+   ran but the terminal still won't honor it" from "Aru never
+   actually tried".
+
+Bound to ``Ctrl+R`` with ``priority=True``. Bindings dispatch through
+Textual's binding system *before* the focused widget's ``_on_key``,
+so this path is immune to the ``Input._on_key → event.stop()`` issue
+that broke Layer 12. The user has a guaranteed-fire keystroke
+regardless of focus state.
+
+**What Layer 13 does NOT fix:**
+
+* It does not trace the emitter — same as Layer 7/9/10/12, the cause
+  of the disable is still outside our reach (likely a ConPTY / Windows
+  Terminal interaction during display power transitions).
+* It is not automatic — requires a user keystroke. Layers 9, 10, and
+  the (broken) 12 attempted automatic recovery; Layer 13 is the
+  manual fallback while we figure out which automatic trigger to
+  add. Candidates for a future Layer 14 if the manual shake proves
+  effective: hook ``AppFocus`` events, detect long gaps in the
+  periodic tick (wake-from-sleep signature), or move the keystroke
+  rearm from ``on_key`` to ``on_input_changed`` so it actually fires
+  during typing.
+
+**Why this is Layer 13 and not a rewrite of Layers 9/10/12:** the
+two failure modes (printable-key absorption and mouse-only-shake
+insufficient) point at distinct fixes; folding them into the existing
+periodic / turn-boundary callers would make every tick emit 12
+escapes plus a Windows console mode call (currently 8 + nothing),
+which is wasteful when the simple shake is enough — and would still
+not fix the printable-key absorption bug. Keeping the strong shake
+in a user-invoked path means:
+
+* The cheap path (Layer 9/10) keeps running every 3s with mouse-only.
+* The full path (Layer 13) runs only when the user signals "I
+  noticed the wheel is dead, please fix it".
+* If the cheap path is actually sufficient most of the time, we
+  don't pay the heavier cost on every tick.
+
+If, after Layer 13 ships, the user reports that ``Ctrl+R`` reliably
+recovers but the automatic paths still don't, that proves the strong
+shake is what works and Layers 9/10/12 should be upgraded — that's
+Layer 14's signal. If even ``Ctrl+R`` doesn't recover, the hypothesis
+shifts to "VT escapes are not enough, need ``SetConsoleMode`` direct
+or alt-screen toggle", which is Layer 14 in the other direction.
+
+----
+
+Post-mortem — "Ctrl+R recovered the wheel; promote the shake"
+(2026-04-25, ``fix/scroll-analysis3`` continued)
+---------------------------------------------------------------------
+**Signal:** the user reported, on the same day Layer 13 shipped, that
+the wheel went dead during a session and pressing ``Ctrl+R`` brought
+it back. That is the exact branch the Layer 13 post-mortem set up:
+"if Ctrl+R reliably recovers but the automatic paths still don't,
+that proves the strong shake is what works and Layers 9/10/12 should
+be upgraded".
+
+**Layer 14 — promote the strong shake into ``_reenable_mouse_tracking``.**
+Single change: the body of ``AruApp._reenable_mouse_tracking`` now does
+what Layer 13's ``action_recover_terminal`` did inline — re-assert
+``ENABLE_VIRTUAL_TERMINAL_INPUT`` on stdin (Windows) plus off-then-on
+shake of the full DEC private-mode set (mouse + focus-events +
+bracketed-paste). Every existing caller benefits without further
+changes:
+
+* **Layer 9** (``_run_turn`` finally clause) — every turn boundary
+  now runs the proven recovery, so a wheel that died mid-turn is back
+  before the user reaches for it.
+* **Layer 10** (3s periodic tick via ``_self_heal_terminal_state``)
+  — autonomous recovery within 3 seconds of the wheel dying, with
+  the shake that actually works.
+* **Layer 12** (per-keystroke trigger via ``_maybe_rearm_mouse_on_keypress``)
+  — still broken in production because ``Input._on_key`` consumes
+  printable keys before ``App.on_key`` sees them, so the trigger
+  never actually fires. Layer 14 doesn't fix this; the rearm primitive
+  is still pinned by tests for the day a future Layer wires it to
+  ``on_input_changed`` (which uses Message bubbling, not key events).
+
+``action_recover_terminal`` (Ctrl+R) now delegates the shake to
+``_reenable_mouse_tracking`` and adds two extras unique to the manual
+path: ``self.refresh()`` for immediate visible repaint and the
+``[Ctrl+R] Terminal modes re-armed`` chat message. Periodic / turn-
+boundary callers stay silent — running the strong shake without
+spamming the chat or forcing a redraw every 3s.
+
+**Cost of the upgrade:** every periodic tick emits 12 escapes (~108
+bytes) + one ``GetConsoleMode``/``SetConsoleMode`` syscall pair on
+Windows instead of 8 escapes (~64 bytes) + nothing. At 3s cadence
+that is ~36 B/s plus microseconds of syscall — negligible.
+
+**Risk acknowledged but not seen:** the off→on transition on
+``?1004`` (focus events) could in theory cause Windows Terminal to
+emit a spurious focus event during the gap. Idempotent in practice
+on healthy terminals (``?1004l → ?1004h`` should leave focus state
+unchanged), but if a future signal points at "focus events firing
+unexpectedly every 3s", the fix is to keep ``?1004`` and ``?2004`` in
+the Ctrl+R-only path and revert the periodic shake to mouse-only.
+
+**What Layer 14 does NOT change:**
+
+* The Layer 12 keystroke trigger remains broken — ``Input._on_key``
+  still absorbs printable keys, so typing in the prompt never
+  triggers recovery. Fix candidate for a future layer: hook
+  ``on_input_changed`` instead of ``on_key`` (uses Message bubbling
+  which isn't blocked by widget consumption).
+* The underlying emitter that disables terminal mouse tracking is
+  still unidentified — same as every layer back to 7.
+* No new automatic trigger beyond the existing 3s tick + turn
+  boundary. Hooking ``AppFocus`` for wake-from-display-blank
+  detection is a follow-up if Layer 14 still misses cases.
 """
 
 from __future__ import annotations

{aru_code-0.45.0 → aru_code-0.46.0/aru_code.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aru-code
-Version: 0.45.0
+Version: 0.46.0
 Summary: A Claude Code clone built with Agno agents
 Author-email: Estevao <estevaofon@gmail.com>
 License-Expression: MIT

{aru_code-0.45.0 → aru_code-0.46.0}/aru_code.egg-info/SOURCES.txt

@@ -167,6 +167,7 @@ tests/test_tui_completer_dynamic.py
 tests/test_tui_copy.py
 tests/test_tui_input_behaviour.py
 tests/test_tui_layer12_recovery.py
+tests/test_tui_layer13_recovery.py
 tests/test_tui_mention_expand.py
 tests/test_tui_modals.py
 tests/test_tui_mode_cycle.py

{aru_code-0.45.0 → aru_code-0.46.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "aru-code"
-version = "0.45.0"
+version = "0.46.0"
 description = "A Claude Code clone built with Agno agents"
 readme = "README.md"
 license = "MIT"

{aru_code-0.45.0 → aru_code-0.46.0}/tests/test_tui_layer12_recovery.py

@@ -1,16 +1,32 @@
-"""Layer 12 — mouse-tracking recovery: off-then-on shake + keypress trigger.
-
-Background: ``aru/tui/widgets/chat.py`` post-mortem under "self-heal didn't
-recover the wheel" (2026-04-25). Layers 9/10 emitted only the four ``?...h``
-enable sequences; if ConPTY's enable-cache or the driver's gate suppressed
-the write, no recovery happened. Layer 12 emits a forced ``?...l → ?...h``
-state transition via ``driver.write`` and adds a per-keypress trigger so the
-user gets sub-second recovery instead of waiting for the periodic tick.
-
-These tests pin down the observable contracts:
-* the eight DEC private-mode sequences are emitted in disable→enable order;
-* the keypress trigger calls into ``_reenable_mouse_tracking`` debounced by
-  ``_KEYPRESS_REARM_DEBOUNCE``.
+"""Layer 12 / 14 — terminal-state recovery: off-then-on shake + keypress trigger.
+
+Background: ``aru/tui/widgets/chat.py`` post-mortem traces the evolution.
+
+Layer 12 (2026-04-25) introduced an off-then-on shake of the four mouse
+DEC private modes via ``driver.write`` to defeat ConPTY's enable cache
+and bypass the driver's ``_mouse`` gate. That helped some sessions but
+the user reported (``fix/scroll-analysis3``) that mouse-only shake did
+not recover the wheel after Windows display sleep / wake — the wake
+appears to corrupt more than just mouse, and on the input side
+``ENABLE_VIRTUAL_TERMINAL_INPUT`` may also drop, so no stdout escape
+recovers wheel events.
+
+Layer 14 (2026-04-25, after Ctrl+R proved the heavy shake works)
+promoted ``_reenable_mouse_tracking`` from mouse-only to:
+* re-assert ``ENABLE_VIRTUAL_TERMINAL_INPUT`` on stdin (Windows), and
+* shake the full DEC private-mode set from
+  ``WindowsDriver.start_application_mode`` (mouse + focus-events +
+  bracketed-paste).
+
+These tests pin the observable contracts of the promoted method:
+* the twelve DEC private-mode sequences are emitted in disable→enable
+  order with one flush;
+* headless/no-driver path is a quiet no-op;
+* the keypress trigger calls into ``_reenable_mouse_tracking`` debounced
+  by ``_KEYPRESS_REARM_DEBOUNCE`` (the trigger itself is broken in
+  practice — ``Input._on_key`` consumes printable keys before
+  ``App.on_key`` sees them — but the debounce contract is what this
+  test pins).
 """
 
 from __future__ import annotations
@@ -36,12 +52,19 @@ class _RecordingDriver:
 
 @pytest.mark.asyncio
 async def test_reenable_mouse_tracking_emits_off_then_on_shake():
-    """Layer 12: ``?...l`` (4) is emitted *before* ``?...h`` (4), then flush.
+    """Layer 14: full DEC mode set, off→on order, single flush.
 
     The off→on shake forces ConPTY's enable-cache through a state
-    transition, defeating the case where its cache claims ``?1000`` is
+    transition, defeating the case where its cache claims a mode is
     already ``h`` and suppresses the propagated write. Order matters —
     if the on sequences came first the cache could no-op them.
+
+    Layer 12 covered four mouse modes only; Layer 14 widens the shake
+    to mouse + focus-events (``?1004``) + bracketed-paste (``?2004``) —
+    the full set ``WindowsDriver.start_application_mode`` enables at
+    boot. User confirmation on 2026-04-25 was that the mouse-only shake
+    did not recover after Windows display sleep/wake but the full shake
+    via Ctrl+R did, which is the signal that justified the promotion.
     """
     from aru.tui.app import AruApp
 
@@ -59,12 +82,16 @@ async def test_reenable_mouse_tracking_emits_off_then_on_shake():
         "\x1b[?1003l",
         "\x1b[?1015l",
         "\x1b[?1006l",
+        "\x1b[?1004l",
+        "\x1b[?2004l",
     ]
     expected_on = [
         "\x1b[?1000h",
         "\x1b[?1003h",
         "\x1b[?1015h",
         "\x1b[?1006h",
+        "\x1b[?1004h",
+        "\x1b[?2004h",
     ]
     assert rec.writes == expected_off + expected_on
     # One flush at the end — the ``WriterThread`` bufferises everything
@@ -90,6 +117,12 @@ async def test_keypress_rearm_is_debounced(monkeypatch):
     Two keystrokes within the debounce window should produce exactly one
     ``_reenable_mouse_tracking`` invocation; a third keystroke after the
     window elapses should produce a second.
+
+    The trigger itself is broken in production (``Input._on_key``
+    consumes printable keys before ``App.on_key`` sees them), but this
+    test pins the debounce *primitive* contract — useful if a future
+    Layer wires the rearm to ``on_input_changed`` (which bubbles via
+    Message dispatch and isn't absorbed by Input).
     """
     from aru.tui import app as app_mod
     from aru.tui.app import AruApp
@@ -115,6 +148,7 @@ async def test_keypress_rearm_is_debounced(monkeypatch):
     fake_now[0] += 0.5
     app._maybe_rearm_mouse_on_keypress()
 
-    # Each fired call emits 8 sequences (4 off + 4 on). Two fires = 16.
-    assert len(rec.writes) == 16
+    # Each fired call emits 12 sequences (Layer 14 full mode set: 6 off
+    # + 6 on). Two fires = 24.
+    assert len(rec.writes) == 24
     assert rec.flushes == 2