Repository navigation
Assess completion-to-diff review motion #10252
Description
Activity
Independent Astra-medium assessment: reject adding a second completion-to-diff animation on current main. The useful relationship is already implemented; this pass produces no code or PR.
Inspected clean upstream main
eee05575ebd514db36f61d7eb05d2258a10c96bdin isolated worktree/Users/saphid/.t3/worktrees/t3code-diff-motion-20260906. The dirty primary and previous Stash overlay were not modified.Evidence:
- ChatView.tsx#L4041 already observes the running-to-completed turn transition and, when proactive panels are enabled on a wide layout, selects that exact turn before opening its diff. It does not trigger merely because a completed thread was loaded.
- ChatView.logic.ts#L109 requires a matching previously running turn. Its action resolver waits for the checkpoint and repository status, ignores empty/non-ready diffs, and preserves an active pull-request surface. Adding automatic opening would undermine these existing decisions.
- settings.ts#L102 defaults panel motion to 0 ms, explicitly because layout work matters on lower-power clients. panelAnimations.ts#L81 gates opt-in motion on reduced-motion and navigation suppression. The right panel already uses this common flow.
- PreviewPanelShell.tsx#L85 suppresses transitions for resizing/maximizing and clips a fixed-width inner panel during opt-in open/close. A shared-element scale from a completion affordance into the entire diff would add text distortion and coordination over a large scrollable surface. The Motion layout guide itself documents scale distortion and scroll-container requirements.
No concrete missing relationship remained after this inspection. A small additional fade would still add no demonstrated information beyond the existing selected-turn panel transition; no measured problem justifies replacing the common panel architecture. Human Interface Craft p10 asks for meaningful, interruptible relationships and continuity; p13 asks for a useful outcome independent of the effect. The existing flow already meets the intended relationship at the source level.
Overlap check: targeted open PR title searches found #10150 (turn diff baselines), #8826 (preserve diff scroll/collapsed files), and #2338 (oversized diff lines). These are adjacent work, not evidence that the proposed motion exists in a separate PR. The decisive overlap is the code already on main. Searches were scoped, not exhaustive.
Verification: read-only source assessment and clean
git status --porcelain(exit 0); no executable changes, tests, independent cross-provider code review, or live visual captures. No runtime timing/performance claim is made. No new Motion dependency or API means installed export verification is not applicable. No PR or before/after capture is needed for this rejected addition.Triage
Motion-audit assessment ticket (not a user bug): should completed work grow a stronger visual relationship into its diff, without changing proactive-panel rules, focus, reading position, or opt-in panel motion (default 0 ms)?
Verdict: reject extra completion-to-diff motion. The requester already recorded an independent Astra-medium reject (comment). I checked the same
main(eee05575e) and agree. No code or PR.What already exists
On a running → completed turn (not on load of an already-finished thread), with proactive panels enabled and a wide layout, ChatView selects that turn and opens the diff:
ChatView.tsx— observe settle →selectTurn→open(..., "diff")ChatView.logic.ts—shouldOpenProactiveTurnDiff/resolveProactiveTurnDiffActionwait for checkpoint + repo status, ignore empty/non-ready diffs, and leave an active pull-request surface alone- Tests in
ChatView.logic.test.tscover those gates
Panel motion is already a shared, opt-in path:
settings.ts—panelAnimationDurationMsdefaults to 0 (width/height transitions are layout work on lower-power clients);proactivePanelsEnableddefaults to falsepanelAnimations.ts— active only when duration > 0, reduced motion is off, and navigation suppression is off; right panel usesusePanelPresencePreviewPanelShell.tsx— no width transition on resize/maximize; inner panel is clipped during opt-in open/close
A shared-element scale from a completion affordance into the whole diff would add distortion and coordination over a large scrollable surface, and extra automatic opening would undo the gates above.
Related work (not this ticket)
Shipped: #9276 proactive panels, #9753 empty diffs vs PRs, #8830 opt-in panel motion, #9766 / #9778 no motion on navigation.
Adjacent only: #10150 turn baselines, #8826 diff scroll, #2338 oversized lines.
Siblings #10248–#10255 are separate motion-audit scopes, not duplicates of this one.
Next step
Close as wontfix. Do not implement. Remaining acceptance items (implementation, cross-provider review, before/after captures) do not apply to a rejected addition.
- addedvia-triageFiled through npx t3 triageFiled through npx t3 triageenhancementRequested improvement or new capability.Requested improvement or new capability.wontfixThis will not be worked onThis will not be worked on
on Sep 6, 2026 Closing as wontfix per triage: independent Astra-medium reject — no stronger completion-to-diff motion beyond existing proactive-panel behavior.
Assess relationship between completed work and opening its diff. Preserve existing proactive-panel behavior, focus and reading position, and honor opt-in panel motion (default 0 ms). Avoid expensive whole-panel scaling/reflow or additional automatic opening.
Requested by Alex after the T3 UI motion audit. First record an independent Astra-medium accept/revise/reject verdict with source evidence. Accepted changes should end in small focused PRs; do not implement a rejected suggestion.
Use the installed shadcn-motion-ui skill and Human Interface Craft guidelines (feedback, relationship, continuity, accessibility, signature moments). Consult current official docs, reuse local primitives, verify installed API compatibility and add exact source references. Respect native platforms, reduced motion, interruptions, responsiveness, focus, and performance. No continuous repaint loops or framework rewrites.
Acceptance:
Do not change live user data, the dirty primary checkout, existing Stash worktree, or unrelated work. No merge or deployment is requested.