Shell visual gap audit — 24 September 2026
The interactive 568×1232 study and its surface and motion plan describe the intended direction. I compared their deck, drawer, shade and Settings frames with the installed aab74fb78dd7 shell’s native 568×1232 deck and drawer captures supplied by the board operator on 24 September, the installed Settings loading capture, the real-theme host renders, and the paired Sway/Rust QEMU composite. The operator’s raw board captures were private /tmp review files at this audit, not committed physical evidence; this document does not claim a camera, touch, timing or optical pass. Host renders are isolated Rust surface pixels; QEMU composites use synthetic apps. The browser study uses illustrative app output and status values, not device telemetry.
Assessment: the installed shell has the core route and real theme plumbing, but does not yet look like the high-fidelity study. Its deck and drawer still resemble engineering scaffolding. Real Yaru icons and a real Omarchy still are visible, and the normal session has no permanent Apps/Windows rail or Back/Home footer. Those are meaningful steps, but palette adoption alone does not satisfy the shared hierarchy and spacing requirement.
| Priority | Observed gap against the study | Concrete correction and existing gate |
|---|---|---|
| P0 | Installed deck shows a large generic Cards title, a procedural “Tap to return. Swipe up to close.” subtitle, and an oversized, clipped Selected: shell@… line across a square, letterboxed Foot card. The study gives the selected app a compact icon/name/status header, preserves its live content, lets the neighboring card read as another place, and leaves a quiet drawer cue. The real card has live Foot pixels, but almost none of that visual identity or spatial hierarchy. | Replace diagnostic copy/selected-title overlay with a bounded, privacy-aware app header and small contextual gesture cue; size/crop the live viewport and adjacent peek deliberately at 568×1232. Keep real app pixels and focus ownership in Sway rather than painting a fake preview. Cover empty/private/unavailable states. Coherent-shell tasks 1.1, 1.4, 1.5, 4.1–4.3 and 5.2 remain open. |
| P0 | Board drawer shows the deck title faintly through its lower panel. The paired Latte QEMU composite independently records theme-authored launcher.background alpha 0.95, with card text showing through the panel. This damages legibility even though the palette is authentic. | Resolve the panel’s effective opacity/contrast against the live deck, including dark/light themes and active card text. Preserve authored tokens where possible, but provide a readable compositing treatment or an explicit compatibility limit. Verify native composite pixels and then optical readability on glass. Theme tasks 3.1–3.3, 5.3; coherent-shell 5.3. |
| P0 | The board Foot window leaves a narrow uncovered right/bottom edge inside the 568×1232 scene. The operator traced the client to 564×1224 and is correcting its resize-by-cells behavior. This is an app-size/scene integration defect, not a reason to stretch or misstate the panel geometry. | Check exact app logical bounds and scene fitting after the Foot change; inspect card and expanded app at the panel edges. Coherent-shell tasks 4.2 and 5.2. |
| P1 | The study’s drawer is an icon-led three-column field with concise, distinct app labels and secondary names. The installed drawer is seven full-width, heavily outlined rows; every subtitle says “Installed app.” Foot, Foot Client and Foot Server occupy three adjacent equal-weight rows, while nnn falls back to an initial. The actual list is correctly derived from installed desktop entries, so the study’s six sample apps are not an inventory to hardcode. | Establish a compact icon-led layout or equally scannable grouped layout for the real catalog; use meaningful desktop-entry role/subtitle data to distinguish Foot variants, keep labels, and give fallback icons consistent geometry. Show long-name/overflow and many-app scroll fixtures, not only two rows. Coherent-shell tasks 1.2, 1.4–1.6 and 5.3. |
| P1 | The study’s shade balances a quiet heading, truthful quick capability tiles, named notification rows and a Settings entry. Current host shade is dominated by “Notifications,” a procedural swipe instruction, two near-duplicate cards for one sample event and large unused lower area. The board shade was not captured for this audit. | Rework hierarchy around real capability state, broker preview versus history, clear count, and contextual dismissal; do not copy the mockup’s illustrative clock, Wi-Fi assertion or synthetic notices as truth. Check privacy and loading/empty/failure states. Coherent-shell tasks 2.1–2.3, 3.1–3.3 and 5.4. |
| P1 | The host Settings surface is a stack of large generic capability cards; the study groups connection and input/display with icons, an obvious path back to Notifications, and calmer spacing. The only installed Settings capture available here still says “Loading settings,” so settled board layout and controls are not established by that image. | Keep the real unavailable/read-only/pending semantics and guarded power actions, but add grouping/icon hierarchy and a clear return path. Capture settled board Settings and error/confirmation states before judging touch readability. Coherent-shell tasks 2.2–2.4, 5.1 and 5.4. |
| P1 | Theme list and preview host frames are mostly text on empty space. Preview shows palette chips and a selected *.webp filename but no image, although the actual still is rendered behind the QEMU deck. This makes choosing among real Omarchy backgrounds a blind action. | Add bounded still thumbnails or a selected-image preview with fit/crop indication, show theme choices and current/pending state compactly, and keep explicit Apply/Cancel. Continue to label unsupported video honestly. Theme tasks 4.1–4.2 and 5.3. |
| P1 | The prototype uses one type scale, margin rhythm and small context cues from deck through drawer, shade and Settings. Current Sway deck typography and Rust surfaces visibly use separate hierarchies; heavy row strokes and broad empty areas make the composite feel assembled rather than one shell. | Specify and apply one 568×1232 spacing/type/target system across both renderers; validate dark/Latte side-by-side including large catalogs, notifications and empty states. Maintain at least 56 logical-pixel targets. Coherent-shell tasks 1.5, 4.2 and 5.3, theme task 3.2. |
| P2 | The study’s motion examples emphasize the same app/card following the finger and settling from its visible position. The user’s actual-glass report describes abrupt app zoom-out and a mechanical release. Static captures cannot quantify trajectory or frame cadence; a separate motion owner is already addressing this. | Judge with real-finger video and input→commit→present traces after source fixes; include reverse and refusal. Preserve direct one-to-one drag and use easing only after release. Coherent-shell tasks 4.2–4.5, 5.2 and 5.5. |
The immediate review order is panel/viewport legibility, deck identity and drawer information layout, then shade/Settings hierarchy and visible wallpaper selection. Keep the existing host, QEMU and board evidence classes separate. A replacement visual pass should show the same live app through app→deck→drawer, all real installed entries, dark and light themes, and settled Settings/notifications on the actual panel; it should retain the opt-in rollback route until the named physical gates pass. This audit adds no new capability outside the open proposals and checks none of their tasks.