Windows UI redesign — Verification/readiness epic: three focused jobs #115

Coordination epic — work through the small jobs

This issue groups related work; it is not one implementation job or one all-at-once design approval. Review and complete the linked leaf issues separately. Their questions, narrow scopes and prerequisites govern execution. The older phase-wide material below is reference context.

Screen context

This picture illustrates verification targets only. It adds no new product UI and is not native-build pass evidence.

Coordination status: awaiting job-level discussion. Keep this epic open until its linked jobs have actual implementation/verification evidence. The first discussion is #117, typography only. No automatic next-job work or release.

Visual walkthrough and discussion

This task proves that the redesigned native app still works. The test path loops back when a regression appears; it does not jump straight from an attractive mockup to a release.

Schematic only: these diagrams explain structure and behavior, not exact pixel geometry, font rendering, or an implemented Windows screenshot.

flowchart TD
  CORE["Completed implementation of #111–#114"] --> BUILD["Local core tests + Viewer/Comparator Release builds"]
  BUILD --> CHECK["Native checks<br/>Layout / DPI / theme / keyboard / UIA<br/>E stability / navigation / selection / pixels / metrics / GPU / performance"]
  CHECK --> PASS{"All required checks pass?"}
  PASS -- "No" --> FIX["Fix the problem and repeat affected checks"]
  FIX --> BUILD
  PASS -- "Yes" --> DOC["Update guide, changelog, and applicable Store wording"]
  DOC --> REPORT["Record evidence and limitations"]
  REPORT --> DECISION["Discuss release scope and version separately<br/>No automatic tag or Store publication"]

Historical phase-level discussion prompts (reference)

• Which folders/images/videos should be included as representative tests from your actual workflow?

• Are there additional shortcut, viewing, or comparison scenarios you want explicitly checked?

• After the evidence is available, discuss release/version choices rather than assuming a major bump now.

Reference status: use the focused leaf-job questions above for approval. This phase-wide material is not one implementation job.

Parent and dependencies

Parent: #110. Depends on #111, #112, #113, #114. Core release gate; Phase 6 is not a prerequisite.

Goal

Confirm native Windows correctness, accessibility, performance, and documentation before deciding a release scope/version. Do not mistake mockup checks for implementation verification.

Verification checklist

• Record the tested commit, machine/OS, current pre-change baseline, representative files, DPI/text settings, and pass/fail evidence.
• Check client sizes 640×480 / 960×600 / 1440×900 DIP; 100/125/150/200% DPI; Windows text enlargement; mixed-monitor transitions; long Korean/English/unbroken/mixed-script names.
• Check Light/Dark/System/high contrast, reduced motion, actual text and essential-control contrast pairs, consistent baselines, and UIA/Narrator focus/selection/state.
• Verify E with small/large/manual-zoom/video content: one atomic toggle, no unintended file/frame step, correct Fit/manual-anchor behavior, no shaking.
• Verify folder/drive/UNC traversal and failures, Gallery/List eligibility, 1/2/4/5/many selection, directory watching/path-based restoration, and partial Recycle Bin failure.
• Verify RAW/YUV/Pixel Exact, source versus display values, ROI, captures, existing HDR/HLG policy, A/B-only metrics and C/D view-only, LPIPS preparation/cancellation/errors.
• Verify same-folder explicit multi-image opening, bounded thumbnail CPU/GPU caches, visible-first loading, no new directory-wide decode, no idle repaint loop, and GPU resource recreation with state preservation.
• Compare interaction latency, first decode, memory, and playback under comparable pre/post conditions. Treat ~100ms visible feedback as an initial goal, not an already measured guarantee.
• Fix any discovered regression and repeat the affected check before closing the corresponding implementation issue.

Local build gate

Follow AGENTS.md: run Write-Q1ViewVersion.ps1 using the existing dev-version policy; locate VS2022 MSBuild through vswhere if it is absent from PATH; build/run CoreRegressionTests; build Viewer/Viewer.sln and Comparator/Comparator.sln in Release/x64/v143. Preserve the distinction between local 0.0.0.dev and tagged CI versioning.

Documentation and rollout

• Update USER_GUIDE with actual startup, panels, drive navigation, selection/Recycle Bin wording, shortcuts, themes, and Comparator scope; resolve implementation/documentation mismatches.
• Keep user-visible Store listing/changelog claims accurate; one logical line per changelog/store bullet or paragraph.
• Attach PR/commit references and actual verification evidence to all core implementation issues.
• Review compatibility, known limitations, release notes, and whether a major bump is justified; do not preselect a version just for appearance changes.
• Obtain release direction before tagging/publishing. A readiness result is not authorization to cut a release.

The GitHub Actions release workflow remains the final authority for tagged packaging/signing, GitHub Release creation, and Store submission. Release execution is a separate explicitly authorized step; do not continuously poll release jobs as part of this planning task.

Execution and completion rules

Windows MFC Viewer/Comparator only; follow the parent specification and existing AGENTS.md. Start a focused branch from current origin/master and keep unrelated changes intact. Reuse existing command IDs and rendering/data paths. Run relevant automated/manual checks plus local CoreRegressionTests and both Windows Release builds for changes affecting shared or release-sensitive code. Record the branch/PR, verification evidence, remaining limitations, and any regression fixes. A mockup or build alone is not completion. Do not tag/publish a release in this implementation step.