Add reusable component comparison mode

[rheos]

Closes #8

Summary

• generalize the comparison workbench to every category with at least two existing models: GPUs, power supplies, and processors
• keep comparisons within one category so physical scale and specification rows remain meaningful; motherboard comparison will become available when a second model exists
• discover comparable models and their root catalogue entries from canonical level metadata instead of maintaining a hardcoded list in the comparison view
• keep only category-specific labels and specification rows in the comparison schema
• render desktop split panes or a mobile A/B pane with one renderer, scene, camera, and OrbitControls pair
• preserve truthful relative scale for physical models and a consistent shared scale for logical processor diagrams
• reuse one stage runtime for renderer setup, demand-driven frame scheduling, controls, camera fitting, context-loss reporting, and disposal
• reuse one scratch-backed model-stage path for posing, inventory, and bounds without per-frame vector allocation
• share disassembly playback between exploration and comparison
• move the comparison entry point into the Explore by scale panel as a clear labelled action
• preserve ordinary exploration, reduced motion, focus restoration, and explicit resource disposal

Adding models and categories

The comparison view no longer keeps its own hardcoded list of models. Each comparable model declares a comparisonGroup in the main level catalogue, and the shared workbench discovers the eligible models and their catalogue data from there.

Adding another GPU, power supply, or processor therefore requires no change to the comparison view. A completely new category only needs a small schema describing the specifications that should appear in its table, since those fields differ by category. It still uses the same comparison UI and renderer.

Automated verification

• npm run check
• npm run lint
• npm test — 58/58 passing, including metadata-driven model discovery, every configured group, and common bounds at assembled, half-disassembled, and inventory positions
• npm run build — passing (existing chunk-size advisory only)
• git diff --check
• Impeccable UI detector — no findings

Browser QA

• desktop split rendering for GPU, PSU, and CPU groups
• mobile A/B switching and responsive specification sheet
• category switching, duplicate prevention, side swap, shared disassembly, and catalogue-backed specifications
• processor inventory uses a shared top-down view
• explorer/comparison entry and exit after the shared runtime refactor
• no browser console warnings or errors

Ready for maintainer review. The latest GitHub Actions run is waiting for maintainer approval because it comes from a fork. Vercel also reports an external deployment-authorization failure. CI/CD is maintainer-owned and was intentionally left unchanged.

[vercel]

@rheos is attempting to deploy a commit to the Yoseph's projects Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pc-anatomy	Ready	Preview	Sep 21, 2026 12:42pm UTC

[rheos]

Ready for maintainer review.

Implementation and final verification are complete: type checking, linting, all 57 tests, production build, cross-browser interaction QA, accessibility/reduced-motion checks, and repeated WebGL lifecycle testing all passed.

The only remaining failed status is Vercel deployment authorization. CI/CD is maintainer-owned, so no deployment configuration was changed in this PR.

[Yoosseph]

This looks really solid and the GPU comparison itself is working well. One thing before I merge it: the original scope of #8 was comparison between components within the same category in general, not only GPUs.

Would you be willing to generalize the comparison system so it can support the other categories as well? If that’s significantly more work, I’m also fine treating this as Phase 1, but in that case I’d like to keep #8 open and track the remaining generic comparison work separately rather than closing it with this PR.

Also, Is the comparison infrastructure already generic and the UI currently just exposes GPUs, or is the underlying implementation itself GPU-specific? Because I see there has been 2554 additions across 15 files.

[rheos]

Follow-up on support for future models and categories:

I changed this in commit 80c0c05 so the comparison view no longer maintains its own hardcoded list of models. Comparable model roots now declare a comparisonGroup in lib/levels.ts, and the workbench discovers the eligible models and their root catalogue data from there.

That means a new GPU, power supply, or processor only needs to be added to the normal level/model/catalogue setup and assigned to its comparison group. The comparison view and renderer do not need to change.

A completely new category still needs a small schema describing which specifications should appear in its table, since those fields differ by category. It then uses the same comparison UI, state handling, and renderer. The discovery behavior is covered by the comparison tests, with all 58 tests passing locally.

[Yoosseph]

Thanks, this is solid work, and the checks pass. Before merging, I’d like the comparison mode to fully satisfy #8 by supporting every category with at least two comparable models, rather than only GPU, PSU, and CPU.
Please make comparison categories metadata-driven: when a category contains at least two models explicitly marked as comparable, it should automatically appear in the comparison viewer. Adding another model to an existing comparison category should not require changes to the comparison UI. Models should only be marked comparable when they use compatible physical or diagram scales.

In particular, please add Storage comparison for the SATA SSD and NVMe models. Their current model scales differ, so these must first be normalized to ensure the physical-size comparison remains accurate.

Please also include relevant dimensions, interfaces, architecture, and category-specific specifications wherever applicable. Category-specific specification definitions may still require configuration, since the meaningful fields differ between component types.

Finally, could you reduce the implementation by roughly 400–600 lines without removing functionality or changing the visible UI?
The main opportunities appear to be:

• Shortening the 189-line comparison specification document.
• Consolidating and reusing existing styles within the 697 new CSS lines.
• Removing duplicated comparison state/UI boilerplate and repeated metadata work.
• Of course you don't have to exactly shorten it by X amount of lines, but we try to reuse as much code as we can to prevent excessive code in the future.

Also to be specific i’m not asking you to replace the shared renderer architecture,it is well designed, perhaps the button placement where swapping between different categories could be improved and/or made larger and more obvious.

The goal is to retain the same behavior and appearance while making the PR easier to maintain. Please also update the inconsistent test counts in with the new techincalities added ARCHITECTURE.md.

Please do leave a comment with what has been updated for the next push here in the thread.

[Yoosseph]

Changes completed before merging:

• Generalized comparison mode across every configured category with at least two eligible models.
• Added comparisons for graphics cards, power supplies, processors, and Storage.
• Added SATA SSD versus M.2 NVMe comparison.
• Normalized SATA and NVMe model scales so their visible physical dimensions remain accurate.
• Added catalogue-backed Storage architecture, protocol, interface, format, and dimensions.
• Added processor architecture data, including Zen 5 and Arrow Lake/Lion Cove/Skymont.
• Made category discovery data-driven so adding another model to an existing comparison group does not require editing the comparison UI.
• Removed the remaining hardcoded GPU startup dependency; comparison mode now starts from the first eligible category.
• Increased and clarified the category controls without changing the rest of the visual design.
• Prevented selecting the same model on both sides.
• Preserved shared disassembly, camera framing, swapping, responsive desktop split view, and mobile A/B switching.
• Corrected keyboard accessibility for the specification panel: focus now enters the close control and returns to the Specs button after closing.
• Consolidated duplicated viewer initialization, update, error handling, gesture detection, playback, and disposal logic.
• Preserved explicit WebGL, geometry, material, texture, event-listener, animation-frame, and observer cleanup.
• Updated the architecture documentation and comparison-mode specification.
• Added regression coverage for category discovery, valid model pairing, specifications, state transitions, physical scale, bounds, and generic startup behavior.
  Final verification:
• Type checking passed.
• Linting passed.
• All 58 automated tests passed.
• Production build passed.
• Desktop, mobile, 699/700px breakpoint, specification-table, keyboard-focus, and repeated viewer-lifecycle checks passed.
• Local and remote main are synchronized at commit ec5ae3a.
  PR Add reusable component comparison mode #17 has been merged and automatically closed. Issue Interactive comparison mode #8 was also closed as completed.