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

{aru_code-0.44.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.44.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.44.0 → aru_code-0.46.0}/aru/tui/app.py

@@ -32,6 +32,7 @@ from __future__ import annotations
 
 import asyncio
 import sys
+import time
 from typing import Any
 
 from textual.app import App, ComposeResult
@@ -244,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),
     ]
@@ -256,12 +262,24 @@ class AruApp(App):
         "skills", "agents", "commands", "mcp", "yolo",
     }
 
-    # Layer 10 — interval (seconds) between belt-and-suspenders re-emits of
-    # the mouse-tracking enable sequences. 8s is the worst-case time-to-recover
-    # if a leaked DEC private-mode escape disables the wheel mid-turn; the
-    # cost is ~24 bytes per tick (four idempotent SGR sequences). See
-    # ``on_mount`` and ``_reenable_mouse_tracking`` for context.
-    _MOUSE_REENABLE_INTERVAL: float = 8.0
+    # Layer 10 / 12 — interval (seconds) between belt-and-suspenders re-emits
+    # of the mouse-tracking enable sequences. Was 8s pre-Layer-12; user
+    # report on 2026-04-25 against ``final-fantasy-9/.aru/sessions/b33dfb99``
+    # was that the wheel never came back even after the turn ended in YOLO,
+    # and 8s was visibly long enough that the user gave up before the next
+    # tick. 3s is short enough that a corrupted state self-heals before the
+    # next mouse interaction, and the cost is still ~64 bytes per tick (the
+    # Layer 12 off-then-on shake — see ``_reenable_mouse_tracking``).
+    _MOUSE_REENABLE_INTERVAL: float = 3.0
+
+    # Layer 12 — minimum interval (seconds) between keypress-triggered
+    # mouse-tracking re-arms. Each keystroke is an opportunity to recover
+    # — if the user is typing it might be precisely BECAUSE the wheel just
+    # stopped working — but we don't want a fast typist to turn every
+    # keystroke into four extra terminal writes. 500 ms is below human
+    # noticeable retry latency yet caps the keystroke→write amplification
+    # at ~2 Hz worst case.
+    _KEYPRESS_REARM_DEBOUNCE: float = 0.5
 
     def __init__(
         self,
@@ -288,6 +306,12 @@ class AruApp(App):
         # cleared) by on_input_submitted.
         self._pending_paste: str | None = None
         self._pending_paste_lines: int = 0
+        # Layer 12 — last time we re-emitted the mouse-tracking enable
+        # sequences via the keypress path. Used to debounce per-keystroke
+        # re-arming so a fast typist doesn't spam the terminal with re-
+        # enables. Initialised to negative infinity so the first keystroke
+        # always rearms.
+        self._last_mouse_reenable_at: float = float("-inf")
 
     # ── Composition ──────────────────────────────────────────────────
 
@@ -549,7 +573,14 @@ class AruApp(App):
         suggestion and fires ``Input.Submitted``, which produced the
         "three Enters to run /help" glitch. Tab is the only key that
         accepts the highlighted suggestion.
+
+        Layer 12 — every keystroke is also a recovery opportunity. The
+        Layer 10 periodic tick still runs every ``_MOUSE_REENABLE_INTERVAL``
+        but a typing user wants the wheel back NOW, not in three seconds.
+        Debounced via ``_KEYPRESS_REARM_DEBOUNCE`` so a fast typist
+        doesn't amplify each keystroke into four extra terminal writes.
         """
+        self._maybe_rearm_mouse_on_keypress()
         try:
             completer = self.query_one(SlashCompleter)
         except Exception:
@@ -1097,34 +1128,138 @@ class AruApp(App):
             # without waiting for the periodic Layer 10 tick.
             self._reenable_mouse_tracking()
 
+    # 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
+    )
+    _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-emit Textual's mouse-tracking enable sequences (idempotent).
-
-        Calls the active driver's ``_enable_mouse_support`` which writes
-        four short SGR sequences (``?1000h`` / ``?1003h`` / ``?1015h`` /
-        ``?1006h``). They re-arm X10 mouse reporting at the terminal level
-        so a leaked ``\\x1b[?1000l`` (or any other DEC private-mode escape
-        that disabled wheel input) is recovered from automatically.
-        Idempotent — sending an enable when tracking is already on is a
-        documented no-op on every emulator.
-        Called from two 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 (e.g. a leaked escape in panel content)
-          within ``_MOUSE_REENABLE_INTERVAL`` instead of leaving the wheel
-          dead until the (potentially long) turn finishes.
-        Wrapped in ``try/except`` because the driver may be ``None`` in
-        headless / test mode and the private method's exact name could
-        shift in a future Textual; better to 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 not None:
-                driver._enable_mouse_support()
+            if driver is None:
+                return
+            for seq in self._FULL_MODE_DISABLE_SEQS:
+                try:
+                    driver.write(seq)
+                except Exception:
+                    pass
+            for seq in self._FULL_MODE_ENABLE_SEQS:
+                try:
+                    driver.write(seq)
+                except Exception:
+                    pass
+            try:
+                driver.flush()
+            except Exception:
+                pass
         except Exception:
             pass
 
+    def _maybe_rearm_mouse_on_keypress(self) -> None:
+        """Layer 12 — re-arm mouse tracking on each keystroke (debounced).
+
+        Trigger fires from ``on_key`` so any user keypress is treated as a
+        recovery opportunity. A typing user is the strongest signal we
+        have that the wheel just stopped working — they reached for the
+        keyboard because the mouse stopped responding, or they're about
+        to scroll back with PgUp and want it ready. Either way, paying
+        ~64 bytes per keypress (capped at 2 Hz by ``_KEYPRESS_REARM_DEBOUNCE``)
+        is a trivial cost for sub-second recovery latency.
+
+        The debounce intentionally uses ``time.monotonic`` rather than the
+        Textual scheduler so it survives across the async ``on_key``
+        boundary without an extra task. ``-inf`` initial value guarantees
+        the first keystroke always rearms.
+        """
+        now = time.monotonic()
+        if now - self._last_mouse_reenable_at < self._KEYPRESS_REARM_DEBOUNCE:
+            return
+        self._last_mouse_reenable_at = now
+        self._reenable_mouse_tracking()
+
     def _self_heal_terminal_state(self) -> None:
         """Periodic recovery of mouse tracking and input focus (Layers 10 + 11).
 
@@ -1345,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.44.0 → aru_code-0.46.0}/aru/tui/widgets/chat.py

@@ -345,6 +345,262 @@ virtualisation experiments) would close some of these by structure,
 but at the cost of every other property the chat currently has
 (selection, copy, mid-stream insertion of arbitrary Rich panels, plan
 mounts). Layered defences are cheap and additive; the rewrite is not.
+
+----
+
+Post-mortem — "self-heal didn't recover the wheel" (2026-04-25,
+``fix/scroll-analysis2``)
+---------------------------------------------------------------------
+**Symptom:** wheel-dead reproduced again post-Layer-11, this time
+against ``final-fantasy-9/.aru/sessions/b33dfb99``. After a YOLO turn
+finished, mouse wheel stopped working on every scrollable surface
+simultaneously — the canonical Layer 7/9/10 fingerprint. User report:
+*"não vi nenhum self healing seu funcionar até agora"* — Layers 9
+(turn-boundary call) and 10 (8 s periodic tick) ran, the four
+``?1000h``/``?1003h``/``?1015h``/``?1006h`` enables were emitted, and
+yet the wheel never came back.
+
+A byte scan of the persisted session turned up zero ``\\x1b`` bytes —
+same shape as the Layer 9 incident. The leak is from a non-persisted
+path (transient tool output, panel content, ConPTY-side state drift)
+and we accept we won't trace its emitter. The real question Layer 12
+answers is: **why didn't the recovery sequences work even when they
+fired?**
+
+**Two root causes the previous re-enable couldn't address:**
+
+1. **ConPTY enable-cache.** Windows ConPTY tracks DEC private-mode
+   state on its side. When its cache says ``?1000`` is already ``h``
+   it can suppress the write to the underlying terminal — even when
+   the terminal itself lost the state. Sending ``?1000h`` while the
+   cache thinks it's already on is therefore a no-op against a real
+   leak. Our Layer-9/10 emit was exactly this no-op.
+
+2. **Driver-side enable gate.** ``WindowsDriver._enable_mouse_support``
+   in textual 8.2.4 (``windows_driver.py:55``) opens with
+   ``if not self._mouse: return``. ``_mouse`` is True by default and
+   shouldn't flip in normal use, but our recovery path was a single
+   ``driver._enable_mouse_support()`` call — if any future Textual
+   refactor decides to flip the gate during pause / alt-screen toggle
+   / shutdown, every layer 9 + 10 call silently no-ops and we'd never
+   see the failure.
+
+**Layer 12 — three coordinated changes** (in ``aru/tui/app.py``):
+
+a. **Off-then-on shake instead of enable-only.**
+   ``_reenable_mouse_tracking`` now emits the four ``?...l`` (off)
+   sequences first, then the four ``?...h`` (on) sequences, then
+   flushes. The forced state transition defeats ConPTY's enable-cache —
+   the cache sees ``l→h`` and propagates the write regardless of what
+   it thinks the prior state was. Eight short writes (~64 bytes)
+   bufferised into one terminal emit by Textual's ``WriterThread``.
+   Idempotent: a healthy terminal lands in the same final state as
+   the old enable-only path, with a microscopic transition gap that
+   doesn't drop wheel events in practice.
+
+b. **Bypass the driver's enable gate.** Recovery now calls
+   ``driver.write(...)`` for each sequence directly instead of
+   ``driver._enable_mouse_support()``. The four ``...l`` and four
+   ``...h`` strings are kept as class-level tuples
+   (``_MOUSE_DISABLE_SEQS`` / ``_MOUSE_ENABLE_SEQS``) so any future
+   call site (Click handler, focus event) reuses the exact same set
+   without drift, and the path is robust against Textual API changes.
+
+c. **Keypress trigger + tighter periodic tick.**
+   ``_MOUSE_REENABLE_INTERVAL`` drops from 8 s to 3 s so worst-case
+   self-heal latency is sub-poll-cycle. ``on_key`` calls
+   ``_maybe_rearm_mouse_on_keypress`` which fires
+   ``_reenable_mouse_tracking`` on every keystroke debounced to 2 Hz
+   (``_KEYPRESS_REARM_DEBOUNCE = 0.5 s``). A typing user is the
+   strongest signal we have that they noticed the wheel just stopped
+   responding — recovery now happens on the very next keystroke, not
+   on the next tick.
+
+Layer 12 differs from Layer 10 in the failure-mode it covers, not in
+its shape. Layer 10 said "the bug will keep finding new emitters; let's
+recover on a clock". Layer 12 says "even when we recover on the clock,
+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.44.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.44.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.44.0 → aru_code-0.46.0}/aru_code.egg-info/SOURCES.txt

@@ -166,6 +166,8 @@ tests/test_tui_completer.py
 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.44.0 → aru_code-0.46.0}/pyproject.toml

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