Merged, deployed, and verified

Loading skeletons now hold the exact geometry of the content they replace.

Tegy’s loading states were audited as paired layouts, corrected across the application, and given an automated guard against future drift.

15skeleton components inventoried
15loading/resolved pairs measured
18state and viewport runs
0skeleton-parity failures

Environment

Application
Production Tegy
Commit
a8056b81c15069389a25c45ada68f12aa8cdade8
Worker version
a24845a3-2621-41f0-8aca-82160b5c9d6c
Visual evidence
Isolated Playwright visual-fuzz harness using the production UI build and deterministic synthetic API fixtures.
Focused viewports
320 × 568 and 1280 × 800 across nine loading scenarios.

The embedded clip uses synthetic fixture data so loading can be held and resolved deterministically. Production was separately verified through auth and real-chat smoke checks.

Before

Layout drift

  • Project placeholders were 24px taller than their resolved cards.
  • A generic row skeleton represented both 52px chats and 120px knowledge tiles.
  • Project detail loading used different lanes, insets, and content order.
  • Chat, billing, settings, recents, and artifact shells had measurable placement differences.

Testing gap

Screenshot baselines could catch appearance regressions, but they could not prove that two intentionally different states occupied the same geometry.

The replacement checker measures paired DOM boxes in the same page before and after held API requests resolve.

After: the real transition

The clip moves from pending project-card skeletons to resolved synthetic projects. The surrounding header, search field, grid columns, card envelopes, and gaps remain fixed.

Loading and resolved geometry

Projects route showing eight loading skeleton cards
Pending API response: eight exact card envelopes.
Projects route showing eight resolved project cards
Resolved response: the same grid, dimensions, and gaps.

Responsive evidence

Mobile Projects loading skeleton at 320 by 568
Projects at 320 × 568.
Desktop project detail loading skeleton
Project detail at 1280 × 800, including transcript, composer, tabs, and files.

How the checker works

1. Hold

The harness pauses the exact data request and records the loading-state boxes.

2. Resolve

It releases the same request in the same page and records the resolved boxes.

3. Compare

Position, size, count, grid, and spacing are checked in CSS pixels with a 1px tolerance.

Verification

  • npm run test:loading-states — 15 components, 27 loading markers, 15 measured pairs, and 5 documented fixed-container exemptions.
  • npm run build and npm run lint — passed.
  • npm run test:browser — all 150 browser tests passed.
  • Focused visual matrix — 18 runs, 0 error-level findings, and 0 skeleton-parity findings.
  • Production auth and real-chat smoke paths — passed.
  • Captured target: http://127.0.0.1:<ephemeral>/projects, titled Projects - Tegy. The clip contains one target page and no multi-tab sequence.
  • Final report target: https://reports.tegy.io/skeleton-parity-showcase-1245/, titled Tegy loading-state geometry parity, opened in Chromium Profile 3.
  • Representative video frames at the beginning, middle, and end were decoded and visually inspected. The final embedded asset matches SHA-256 b01dad881639b7926d46ed45f94d4d17382e4ad3edf94300d0a72cecaf3ea2e5.

Open the full 18-run matrix and raw JSON →

Risks

  • The generic UI fuzzer still reports warning-only candidates for intentional truncation and small controls; these are not skeleton geometry failures.
  • Five stable preview/loading containers are explicit exemptions because their eventual content dimensions are intentionally variable.
  • The clip includes roughly half a second of dark capture before the first app frame; the poster and stills expose the loading state without relying on playback timing.

Remaining work

None for issue #1245. New skeleton components must be registered in the measured parity manifest or carry a documented fixed-container exemption.