Document confirmed-but-not-root-caused cross-monitor border-clip glitch

Live-confirmed via a controlled test (move a window between differently-
scaled monitors, screenshot immediately after vs. a couple of minutes
later): the border briefly shows clipped/missing right after a
cross-monitor tiling move, then self-corrects on a later redraw.

Working hypothesis recorded (client configure/resize/commit round-trip
lagging the compositor's own already-updated model, likely wider on a
cross-scale move than a same-monitor tiling swap), but not confirmed --
reproduction via srd dispatch move window proved inconsistent (its
direction semantics swap within a monitor as often as they cross one),
and a live mouse-drag can't be synthesized here to test directly.

Not a corruption risk: an earlier resize-lag fix already
bounds every border/titlebar crop against the decoration buffer's real
last-built size, so the worst case is a stale/incomplete frame, never an
out-of-bounds read.

1 files changed, 8 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index 257dd56..5c055cb 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -13,6 +13,14 @@ that has the full story. Keep this list current as items close or open;
 update the source doc's own entry too, don't let this drift into a
 second stale copy the way `PANEL_SUPPORT_TODO.md` did.
 
+## Real bug, confirmed live, not yet root-caused: a window's border/decoration briefly shows clipped/missing after a cross-monitor tiling move, self-correcting on a later redraw (2026-08-26)
+
+Reported live: "the border/window looks cut offed when moved from one monitor to another". Confirmed directly, not just reported - moved a real window (`srd dispatch move window <id> right`) from `HDMI-A-1` (scale ~0.843) to `eDP-1` (scale 1.0) and screenshotted immediately after: the window's left border was entirely missing and its content sat flush against the screen edge (the page's own heading read "...UNK" instead of "TYPERPUNK", clipped). A second screenshot of the same window a couple of minutes later showed a complete, correctly-bordered window - the same window, same position, self-corrected.
+
+Working hypothesis, not confirmed: `crates/srdwm/src/main.rs::sync()` calls `apply_geometry`/`redraw_decoration` for every visible window synchronously, every dirty tick, immediately after `arrange_workspace` - so the border rebuilds from the compositor's own already-updated model (`w.geometry`) with no apparent lag on that side. But `redraw_decoration`'s own frame calculation (`effective_frame_of`) corrects against the *client's* real committed size, which needs an actual `configure` -> client resize -> commit round-trip to catch up - normally fast enough to be invisible, but a cross-*monitor* move between different scales asks the client to resize by more than a same-monitor tiling swap ever would, plausibly widening that window enough to actually see.
+
+Not fixed this pass - reliable reproduction via `srd dispatch move window` turned out to be inconsistent (its "left"/"right" semantics swap within a monitor's own tiling order as often as they cross monitors, state-dependent in a way that isn't fully understood yet either), and a live mouse-drag (the gesture the user actually described) can't be synthesized from this environment to test directly. Not a corruption risk regardless - this session's own earlier defensive `src`-crop clamp (the resize-lag fix, see below) already bounds every border/titlebar crop against the decoration buffer's real last-built size, so the failure mode here is "briefly shows a stale/incomplete frame," never an out-of-bounds read. Next step, if picked back up: either synthesize the exact multi-window cross-monitor retile that reproduced it once, or add targeted diagnostic logging around `redraw_decoration`/`effective_frame_of`'s own inputs across a live-tested restart.
+
 ## Real bug, root-caused and fixed, jointly with a peer session (dotfiles-16): layer-shell surfaces on a fractionally-scaled output were unclickable and, for a bottom/right-anchored one, never painted at all (2026-08-26)
 
 Reported live in stages: "AGS isn't even working fast/seems weird now on this monitor even", "dock and AGS buttons aren't working in the other monitor". The peer session independently instrumented AGS itself (both bar and dock report `win_visible=true realized=true reveal=true overlapped=false` on the affected output - the client is asking for the right thing) and srdwm's own `layer_hit_test` log, and found the dock received zero hits across ~40 minutes while the same output's wallpaper and bar took hundreds - full findings in their own `docs/PANEL_SUPPORT_TODO.md`/`SESSION_HANDOFF.md` in the `rust-rewrite` worktree.