# Project Research Summary

**Project:** HoloHue — Cyberpunk GUI Framework for Rust
**Domain:** Hybrid Rust+webview desktop GUI framework with animation choreography, audio, and subwindow management
**Researched:** 2026-02-25
**Confidence:** MEDIUM-HIGH

## Executive Summary

HoloHue is a cyberpunk-aesthetic desktop GUI framework that exposes a pure Rust API while rendering its UI through a bundled webview (Tauri v2). The core architectural insight is that building a visually rich, animation-heavy framework in Rust alone is a dead end — no native Rust GUI toolkit can match the CSS animation fidelity (multi-layer box-shadow, clip-path angled corners, backdrop-filter blur, GPU-accelerated transitions) required for the cyberpunk aesthetic. The recommended approach is a Tauri v2 monorepo with SolidJS frontend: consumers run `cargo add holohue` and interact exclusively with a Rust builder API, while the framework serves a pre-built, embedded SolidJS frontend internally. The v1 deliverable is a working demo application, not a published crate — this keeps scope manageable while proving the concept end-to-end.

The recommended stack (Tauri 2.10, SolidJS 1.9, Tailwind CSS 4.0, GSAP 3.12, Howler.js 2.2) is mature and well-matched to the problem. SolidJS's fine-grained signal-based reactivity is the right choice over React or Svelte specifically because animation-heavy UIs require surgical DOM control — a theme token change must update exactly the affected elements without triggering component re-renders across the whole tree. GSAP's Timeline API is purpose-built for the kind of multi-step choreography HoloHue requires (scale up, border glow sweep, content fade, flicker). The three signature differentiators that make HoloHue worth building — choreographed animation presets, an integrated soundscape, and a first-class subwindow/panel management system — have no equivalent in the Rust GUI ecosystem today.

The most critical risks are front-loaded: cross-platform webview rendering inconsistency (WebView2 vs WKWebView vs WebKitGTK), GPU hardware acceleration being off by default in system webviews, the crates.io 10MB size limit that precludes embedding audio files, and audio autoplay being blocked until user interaction. All of these must be addressed in Phase 1 (Foundation) before any component or animation work begins. Two architectural decisions are existential: the subwindow system must be DOM-based virtual windows (Tauri's native multiwebview is unstable and unusable), and audio assets must not be embedded in the crate binary (use procedural generation or a build-time download strategy).

## Key Findings

### Recommended Stack

The framework uses a dual-layer architecture: a Rust crate manages configuration, window lifecycle, and public API via Tauri's builder pattern, while a bundled SolidJS frontend handles all rendering, animation, theming, and audio. For v1 (demo-ready), the frontend is pre-built and embedded into the Rust binary using `rust-embed` + Tauri's custom protocol. For v2+ (crate-publishable), this evolves to a dual-package model (`tauri-plugin-holohue` on crates.io + `@holohue/ui` on npm). The v1 monorepo structure (`src-tauri/` + `src/` + `Cargo.toml`) is standard Tauri and gets full tooling support.

**Core technologies:**
- **Tauri 2.10**: Application shell, window management, IPC bridge — only mature Rust+webview framework with plugin architecture, transparent windows, and ~6MB binary size
- **SolidJS 1.9**: Frontend UI framework — fine-grained signal reactivity is critical for animation-heavy UIs; 3.9KB, no VDOM, surgical DOM updates; official Tauri template support
- **Tailwind CSS 4.0**: Utility-first CSS foundation — v4's `@property` support enables animating CSS custom properties (glow colors, intensities); CSS-first config, 5x faster builds
- **GSAP 3.12**: Animation choreography — the only animation library with proper Timeline API for multi-step coordinated sequences; now 100% free including all plugins
- **Howler.js 2.2**: Audio playback — 7KB, audio sprites for bundled SFX, zero dependencies, battle-tested; handles the soundscape system
- **rust-embed 8.11**: Compile-time asset embedding — embeds the SolidJS build bundle into the Rust binary; use compression feature
- **serde/serde_json 1.x**: Rust-to-JS serialization — required for all IPC payloads (theme configs, window constraints, animation triggers)
- **ts-rs**: Rust-to-TypeScript type generation — eliminates drift between Rust API types and frontend TypeScript types at the IPC boundary

**What NOT to use:** Electron (244MB binary), egui/iced (no CSS animation richness), React (VDOM overhead, cascading re-renders), Tauri's native multiwebview (unstable, layout/resize bugs per issues #10420, #10011, #13071), `include_bytes!` for large assets (exceeds 10MB crate limit).

### Expected Features

The feature research identified a clear three-tier structure: what must exist, what makes HoloHue worth choosing, and what to defer.

**Must have (table stakes):**
- Core component set: buttons, text inputs, labels, toggles, sliders, dropdowns, panels, tables, modals, tooltips
- Grid layout + split panes + resizable panels (dashboard layout primitives)
- Color token system (two-tier: primitive + semantic CSS custom properties)
- Default cyberpunk theme + 2-3 presets (the "hero" neon-cyan-on-void-black look)
- `prefers-reduced-motion` support — built from day one, not retrofitted; WCAG 2.3.3 mandatory
- Keyboard navigation baseline (Tab, Enter/Space, Escape)
- Demo application tying everything together

**Should have (differentiators — core competitive advantage):**
- Cyberpunk window chrome (angled/notched corners via CSS `clip-path`, 6-8px glow-line perimeter) — the product identity
- Animation choreography system with named presets: `power-on`, `power-off`, `alert-pulse`, `data-stream`, `glitch-flash`
- Window spawn animation (scale expand + glow line sweep + content flicker-in)
- Soundscape system: ambient background loops + UI interaction sounds (click, hover, transition, error)
- Global mute/volume control (non-negotiable if sounds ship)
- Virtual subwindow/panel system: overlay floating panels + edge-docked panels
- Runtime theme switching (CSS custom property swap, zero re-renders)

**Defer to v1.x (post-demo validation):**
- Queued row/column panel grid system (depends on drag-drop + layout persistence; highest complexity)
- Layout persistence (save/restore panel positions)
- 5-8 theme preset collection
- Sound theme presets (multiple audio palettes)
- Additional components: progress bars, tabs, breadcrumbs, notification toasts
- Keyboard navigation audit (thorough accessibility pass)
- Rust API polish (builder patterns, type safety, ergonomic naming)
- Per-component documentation

**Defer to v2+ (post-product-market-fit):**
- Chart/graph container components
- Plugin/extension system
- Multi-monitor/popout windows (real OS window management)
- Rich text or code editor components

**Anti-features to avoid:** Light mode theme (fundamentally breaks cyberpunk aesthetic), full form validation (application logic, not presentation), data fetching layer (out of scope), chart components (entire crate's worth of work), CSS-in-JS (fights the token system).

### Architecture Approach

HoloHue is a dual-layer system where the Rust crate owns the public API and configuration, and the webview frontend owns all rendering. The two layers communicate via Tauri's command/event IPC: Rust is the source of truth for configuration (theme presets, window constraints, sound config) and pushes config down to the frontend at init; the frontend is the source of truth for visual state and sends user actions up to Rust via commands. The critical architectural decision already made: subwindows are DOM-based virtual windows (styled div containers with drag/resize), not native Tauri webviews. Theme tokens flow entirely through CSS custom properties — a theme switch is a single DOM operation, zero JavaScript re-renders. Animation choreography is defined as declarative data (sequences of targets, properties, timing, and sound cues) interpreted by an engine, not imperative code per-component. Sound is fire-and-forget from components via hooks; the engine manages sprites, volume, and mute state.

**Major components:**
1. **App Builder (Rust)** — public consumer-facing API: `HoloHue::builder().theme(...).soundscape(...).run()`; wraps Tauri's `Builder::default()` internally; never exposes Tauri types to consumers
2. **Tauri Runtime Bridge (Rust)** — registers IPC commands, emits events, manages shared state (theme, constraints, sound config); all payloads JSON-serialized via serde
3. **holohue-types crate** — shared Rust+TypeScript type definitions via `ts-rs`; prevents IPC contract drift
4. **Theme Engine (JS)** — applies two-tier CSS custom property tokens to `:root`; manages theme-switch animations; no component re-renders needed
5. **Animation Choreography System (JS)** — interprets declarative sequence data; orchestrates multi-step timelines via GSAP; includes sound cue routing
6. **Virtual Window Manager (JS)** — SolidJS store-based; manages overlay/docked/queued subwindow lifecycle, drag, resize, z-order; enforces Rust-provided constraints
7. **Soundscape Engine (JS)** — Howler.js wrapper; category management (ambient, interaction, transition, notification); lazy AudioContext initialization for autoplay policy
8. **Component Library (JS)** — SolidJS components consuming theme tokens via CSS custom properties; animation targets registered with choreography engine; sounds triggered via `useBleep()` hooks

**Build order enforced by dependencies:** Types/scaffold → Theme system → Core components → Animation system → Virtual window manager → Sound system → Full component library + demo.

### Critical Pitfalls

1. **Cross-platform webview rendering inconsistency** — WebView2 (Windows), WKWebView (macOS), WebKitGTK (Linux) render CSS differently. Glow effects, box-shadow blur radii, and filter behaviors diverge. The cyberpunk aesthetic is existentially dependent on visual fidelity. Mitigation: prototype the window chrome and glow-line effect on all three platforms in Phase 1 before any component work. Limit animation properties to `transform` and `opacity` (universally GPU-accelerated); avoid `filter: drop-shadow()` (inconsistent WebKit behavior). Build screenshot regression tests early.

2. **GPU hardware acceleration disabled by default in system webviews** — CSS animations run at 15-30fps instead of 60fps. On Windows: set `WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS="--ignore-gpu-blocklist"` in framework init. On Linux: verify WebKitGTK GPU compositing. Use `will-change: transform` sparingly. The `HoloHue::init()` path must handle platform-specific GPU workarounds automatically — do not leave this to consumers.

3. **Tauri IPC bridge too slow for animation state** — each IPC call has ~0.5ms serialization overhead; per-frame Rust-driven animation consumes budget before rendering. Decision: animation choreography, timing, and execution live entirely in the webview (JS/CSS). Rust's role is trigger-only (fire event saying "play animation X") and config-only (send preset parameters once at setup). No Rust-side frame loops, ever.

4. **crates.io 10MB size limit blocks distribution** — audio files (ambient loops + 20+ SFX) easily reach 5-15MB. Do NOT embed audio in the crate binary with `include_bytes!`/`rust-embed`. Options: build.rs asset downloader from CDN/GitHub release, procedural Web Audio API sound synthesis (eliminates files entirely), or companion `holohue-assets` crate. This decision must be made in Phase 1 before any audio assets are created.

5. **Audio autoplay blocked by webview security policy** — Web Audio API requires user interaction before playing. Ambient audio at app start silently fails. Hover sounds fail if user hasn't clicked. Mitigation: lazy AudioContext initialization; design audio as opt-in (first interaction unlocks it); show subtle visual indicator for "click to enable audio"; or use Rust-side audio (rodio) for ambient sounds that play without interaction (but rodio requires ALSA on Linux as a system dependency).

6. **Tauri multiwebview is broken** — the `unstable` multiwebview feature has known layout, rendering, and resize bugs (verified Tauri issues #10420, #10011, #13071, #10131, #11376). Do not use it. Subwindows must be DOM-based virtual windows in a single webview.

7. **Compile time tax** — Tauri's dependency tree (~300 crates) combined with HoloHue's dependencies creates 5-10+ minute first builds. Use Cargo features aggressively (make audio optional); audit dependency count at each phase gate; document expected build times honestly.

## Implications for Roadmap

The architecture research provides a concrete 7-phase build order based on hard dependency chains. This maps directly to roadmap phases. The ordering is non-negotiable: each phase's outputs are inputs to the next.

### Phase 1: Foundation and Project Scaffold

**Rationale:** Everything else depends on having a working Tauri project with asset embedding, an IPC bridge, and shared types. Cross-platform GPU acceleration and window chrome must be validated here before any component or animation work begins — failures discovered later require tearing down built components.

**Delivers:** Tauri monorepo scaffold, Rust builder API skeleton (`HoloHue::builder().run()`), SolidJS project with Vite, basic Tauri-to-SolidJS IPC bridge, `holohue-types` crate with `ts-rs` type generation, asset embedding pipeline (frontend bundle embedded in Rust binary via `rust-embed`), GPU acceleration initialization (platform-specific environment variable workarounds in framework init code), window chrome proof-of-concept validated on Windows/macOS/Linux.

**Addresses features:** Cargo crate distribution, idiomatic Rust API (builder pattern), demo application scaffold.

**Avoids pitfalls:** Cross-platform rendering inconsistencies (validate immediately), GPU acceleration disabled (fix in init code), crates.io size limit (decide asset strategy before any assets created), compile time tax (audit dependency tree before adding more).

**Research flag: Needs `/gsd:research-phase`.** The window chrome cross-platform validation (CSS `clip-path` vs SVG vs pseudo-elements for angled corners + glow-line perimeter) requires prototyping. The asset distribution strategy decision (procedural audio vs CDN download vs companion crate) needs a spike before committing.

### Phase 2: Theme System

**Rationale:** Every visual component consumes theme tokens. Building components before the token system means reworking every component when the token architecture is established. The token system is the lowest-common-denominator dependency of the entire visual stack.

**Delivers:** Two-tier CSS custom property architecture (primitive tokens + semantic tokens), `ThemeProvider` SolidJS component, 2-3 built-in cyberpunk theme presets (enough to prove switching works), runtime theme switching (CSS swap at `:root`, zero re-renders), Rust theme config types + `set_theme` IPC command, theme validation (reject non-color CSS injection).

**Addresses features:** Color token system, default theme + 2-3 presets, runtime theme switching.

**Avoids pitfalls:** JavaScript-heavy theme logic causing cascading re-renders (use CSS custom properties, not SolidJS state per component), CSS injection via theme values (validate all token values are valid CSS colors).

**Research flag: Standard patterns.** CSS custom property design token architecture is extremely well-documented (PrimeVue, Tailwind v4, Material Design 3 all use this pattern). Skip `/gsd:research-phase`.

### Phase 3: Core Component Library

**Rationale:** Animation targets must exist as DOM elements before choreography can be written. Components must be built before the animation system can target them. The window chrome component is the highest-priority piece (product identity).

**Delivers:** Cyberpunk window chrome component (angled/notched corners, glow-line perimeter), core component set (Button, Panel, TextInput, Toggle, Slider, Dropdown, Table, StatusBar), all components consuming theme tokens via `var(--hh-*)`, component focus states and keyboard accessibility baseline, `prefers-reduced-motion` CSS media query respected by all animated properties.

**Addresses features:** Cyberpunk window chrome, core component set (8-10 components), accessibility baseline, dark-first design, font system.

**Avoids pitfalls:** Animation-less components being built without the token system they'll use (theme system is prerequisite).

**Research flag: Partially needs `/gsd:research-phase`.** The window chrome implementation (achieving angled corners with simultaneous glow-line perimeter without the clip-path-clips-glow problem) is a specific CSS technique requiring research. The table component (sortable, virtualized for large datasets) is also complex enough to warrant a spike. Other components follow established patterns.

### Phase 4: Animation Choreography System

**Rationale:** Animations require component DOM targets to exist. The animation system defines the architecture that Phase 5 (window manager) depends on for window spawn/close sequences. Establishing the choreography data format here prevents rework when sound cues are added in Phase 6.

**Delivers:** Choreography engine (GSAP Timeline-based sequence interpreter), built-in named animation presets (`window-spawn`, `button-click`, `view-transition`, `dropdown-populate`, `alert-pulse`), ambient effect system (CSS keyframe loops for breathing/ripple — no JS involvement), `prefers-reduced-motion` runtime check integrated into engine (static fallbacks for all sequences), staggered entrance orchestration utility, components integrate animation targets via refs.

**Addresses features:** Animation choreography system, animation preset library, ambient breathing/ripple effects, staggered entrance orchestration, window spawn animation, button interaction animation.

**Avoids pitfalls:** IPC animation bottleneck (all choreography executes in webview, Rust is trigger-only — enforce this boundary explicitly in architecture docs), imperative animation spaghetti (all sequences defined as declarative data, engine is sole coordinator), `setTimeout`-based sequencing (GSAP Timeline handles this natively).

**Research flag: Needs `/gsd:research-phase`.** GSAP Timeline integration with SolidJS's fine-grained reactivity has documented interaction patterns but requires spike work to avoid SolidJS signal tracking inside GSAP callbacks causing unintended reactive re-executions.

### Phase 5: Virtual Window Manager

**Rationale:** The subwindow system depends on the animation choreography engine (window spawn/close use named presets), the theme system (window chrome applies theme tokens), and the core components (subwindows contain components). It is the highest-complexity single feature and comes after its infrastructure is solid.

**Delivers:** SolidJS store-based window state management (positions, z-order, dock state, minimized state), overlay floating panel type (draggable, resizable, z-index managed), edge-docked panel type (slide-in from left/right/bottom), constraint enforcement against Rust-provided rules (max subwindows, allowed positions, min/max sizes), drag + resize pointer event handlers, window lifecycle animations (spawn/close via choreography engine), Rust IPC commands for `open_window`, `close_window`, `set_constraints`.

**Addresses features:** Overlay subwindows, edge-docked panels, panel constraints system.

**Avoids pitfalls:** Tauri native multiwebview (explicitly DOM-only, document this decision), JS context isolation (subwindows are DOM elements in one webview, no isolation problem), "implement as real OS windows first" shortcut (DOM-first is the only safe path).

**Research flag: Needs `/gsd:research-phase`.** Drag-and-drop with constraint enforcement, z-index management, and edge-docking behavior in SolidJS requires researching existing implementations (solidjs-window-manager, WinBox.js) to avoid reinventing solved problems poorly.

### Phase 6: Soundscape System

**Rationale:** Sound cues are embedded in choreography sequences as data (established in Phase 4). The sound system must be built after the choreography sequence format is stable so sound cues integrate cleanly without rework. Sound is independent of visual components (parallel dev is possible) but the IPC integration point requires the bridge layer from Phase 1.

**Delivers:** Howler.js integration wrapped in `SoundProvider` context, audio sprite build pipeline, sound categories (ambient, interaction, transition, notification) with independent volume controls, built-in sound presets mapped to component events (click, hover, transition, error), ambient background loop management with crossfade, global mute/volume toggle and slider, `useBleep()` hook for declarative component sound binding, lazy AudioContext initialization (autoplay policy compliance), Rust `set_volume` and `set_mute` IPC commands, choreography sequences updated to include sound cues.

**Addresses features:** Ambient background audio, UI interaction sounds, sound theme presets (at least 1), global mute/volume control.

**Avoids pitfalls:** Audio autoplay blocked (lazy AudioContext, opt-in design, visual "click to enable" indicator), tight coupling between sound and animation (sound cues are data in sequences, engine routes them; disabling sound silently drops cues), concurrent sound management (debounce hover sounds, limit simultaneous sprites).

**Research flag: Needs `/gsd:research-phase`.** Audio asset strategy (procedural Web Audio synthesis vs file-based sprites) and the crates.io size limit constraint requires a decision spike. Procedural synthesis eliminates the file problem but is more complex to implement. If file-based: the build.rs asset download strategy needs prototyping.

### Phase 7: Full Component Library and Demo Application

**Rationale:** The remaining components and layout primitives depend on all infrastructure (theme, animation, sound hooks). The demo application integrates everything and is the v1 success metric. It should be built incrementally as components are completed in earlier phases, with final polish here.

**Delivers:** Remaining components (Modal/dialog, Tooltip, progress bars, tabs, breadcrumbs, notification toasts), layout primitives (Grid, SplitPane, ResizablePanel, scroll containers, status bar), complete demo application showcasing all components across 2-3 theme presets with runtime switching, subwindow management (overlay + docked), soundscape enabled, animation presets visible.

**Addresses features:** Complete core component set, grid layout + split panes, demo application, all P1 features from prioritization matrix.

**Avoids pitfalls:** "Looks done but isn't" checklist — verify keyboard navigation, animation cancellation, concurrent sound handling, docking persistence, cross-platform rendering, glow-line responsiveness on resize, focus states on all interactive components.

**Research flag: Standard patterns.** Component implementation follows established patterns from Phases 3-6. Demo application structure is straightforward. Skip `/gsd:research-phase` for this phase.

### Phase Ordering Rationale

- **Types and scaffold first:** The IPC type contract and asset embedding pipeline are prerequisites for every other layer. Establishing these early prevents the worst kind of rework.
- **Theme before components:** Token architecture must be stable before components consume tokens. Building components first means retrofitting tokens onto every component.
- **Components before animation:** Cannot choreograph DOM elements that don't exist yet. Animation targets are real DOM nodes with real refs.
- **Animation before window manager:** Window spawn/close sequences are choreography sequences. The engine must exist before windows can animate.
- **Sound after animation:** Sound cues are embedded in choreography sequence data. The sequence format must be finalized before adding sound cue fields.
- **Full component library last:** Depends on all infrastructure. Benefits from each prior phase being solid before adding volume.
- **Cross-platform validation in Phase 1:** Discovering that glow effects are broken on Linux in Phase 5 means rebuilding 4 phases' worth of components. Early validation is mandatory.

### Research Flags

Needs `/gsd:research-phase` during planning:
- **Phase 1:** Window chrome CSS technique (clip-path + glow-line without clipping the glow); asset distribution strategy decision (procedural vs CDN vs companion crate); cross-platform GPU acceleration configuration specifics
- **Phase 3:** CSS technique for angled corners with simultaneous external glow (wrapper element pattern needs validation per exact browser behavior); Table component virtualization for large datasets
- **Phase 4:** GSAP + SolidJS reactivity integration (avoiding unintended reactive tracking inside GSAP callbacks)
- **Phase 5:** Drag/resize/constraint/z-index system implementation; existing solidjs-window-manager library evaluation
- **Phase 6:** Audio asset strategy final decision; build.rs CDN download implementation if file-based audio chosen

Standard patterns (skip `/gsd:research-phase`):
- **Phase 2:** CSS custom property design token architecture is extremely well-documented across multiple mature frameworks
- **Phase 7:** Component implementation and demo structure follow patterns established in Phases 3-6

## Confidence Assessment

| Area | Confidence | Notes |
|------|------------|-------|
| Stack | HIGH | All major technology choices verified against official documentation and stable releases. Tauri 2.10.2, SolidJS 1.9.0, Tailwind 4.0, GSAP 3.12 all confirmed stable. The Tauri-as-library-wrapper pattern is MEDIUM (not widely documented but architecturally sound). |
| Features | MEDIUM | Table stakes derived from established GUI framework patterns (HIGH confidence). Differentiators derived from competitor analysis (Arwes, CYBERCORE, Slint) which are MEDIUM confidence sources. Feature scope is well-defined; specific component API ergonomics require validation during implementation. |
| Architecture | MEDIUM-HIGH | DOM-based virtual windows decision is HIGH confidence (verified via Tauri issue tracker). Provider-based frontend, CSS token architecture, and choreography-as-data patterns are HIGH confidence (established patterns). The holohue-types/ts-rs shared type approach is MEDIUM (sound pattern, limited prior art for this specific use case). |
| Pitfalls | HIGH | All 7 critical pitfalls are verified against specific Tauri GitHub issues (issue numbers cited), official documentation, and established CSS animation performance research. Recovery strategies are battle-tested patterns from the web platform. |

**Overall confidence:** MEDIUM-HIGH

### Gaps to Address

- **Window chrome implementation technique:** The specific CSS approach for angled corners + glow-line perimeter without clipping requires cross-platform prototyping. Research identifies the wrapper element pattern (outer has glow, inner has clip-path) as the solution, but exact implementation needs validation on WebKitGTK specifically.
- **Audio asset strategy:** The procedural-vs-file decision is unresolved. File-based audio with CDN download requires a build.rs download script that hasn't been prototyped. Procedural synthesis eliminates the problem but requires Web Audio synthesis work. This is a Phase 1 design decision with major downstream impact.
- **Tauri library wrapper pattern:** Wrapping `tauri::Builder` inside a library crate is architecturally sound but not widely documented. The exact interaction between `tauri-build` in a library crate's `build.rs` and the consuming binary's build process needs a working proof-of-concept in Phase 1.
- **SolidJS 2.0 migration path:** SolidJS 2.0 is in early development. v1.9.x is the correct target for v1, but the team should track migration announcements. No action needed now; monitor during v1.x work.
- **`prefers-reduced-motion` in GSAP:** GSAP doesn't automatically respect this media query. The choreography engine must check `window.matchMedia('(prefers-reduced-motion: reduce)')` and provide static fallbacks for all sequences. This needs explicit engineering in Phase 4, not an afterthought.

## Sources

### Primary (HIGH confidence)
- [Tauri v2 Official Docs](https://v2.tauri.app/) — architecture, IPC, plugin development, window customization, capabilities
- [Tauri v2 Stable Release Blog](https://v2.tauri.app/blog/tauri-20/) — v2 release Oct 2024 confirmed; 2.10.2 current
- [Tauri GitHub Issues](https://github.com/tauri-apps/tauri/issues) — #4891 (GPU acceleration), #3478/#9968 (audio autoplay), #10420/#10011/#13071 (multiwebview bugs), #3571 (compile time), verified bugs
- [WRY Issue #617](https://github.com/tauri-apps/wry/issues/617) — CSS animation 14fps on Linux confirmed
- [crates.io Publishing Guide + Issue #195](https://doc.rust-lang.org/cargo/reference/publishing.html) — 10MB limit confirmed
- [Tailwind CSS v4.0 Blog](https://tailwindcss.com/blog/tailwindcss-v4) — Jan 2025 release, `@property` support, Lightning CSS internals
- [GSAP GitHub](https://github.com/greensock/GSAP) — 3.12.x, 100% free confirmed
- [Howler.js GitHub](https://github.com/goldfire/howler.js) — v2.2.3, 14k+ stars
- [rust-embed docs.rs](https://docs.rs/crate/rust-embed/latest) — v8.11.0 confirmed
- [W3C WCAG 2.3.3](https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html) — prefers-reduced-motion requirement
- [MDN Animation Performance](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Animation_performance_and_frame_rate) — transform/opacity GPU compositing
- [Carbon Design System Motion](https://carbondesignsystem.com/elements/motion/choreography/) — choreography and stagger timing patterns

### Secondary (MEDIUM confidence)
- [SolidJS GitHub Releases](https://github.com/solidjs/solid/releases) — v1.9.0 stable, 2.0 roadmap
- [solid-motionone](https://github.com/solidjs-community/solid-motionone) — WAAPI-based animation for SolidJS
- [solidjs-window-manager](https://github.com/AndreiTelteu/solidjs-window-manager) — validates DOM-based window pattern
- [Arwes Sci-Fi UI Framework](https://github.com/arwes/arwes) — competitor analysis, sound system patterns
- [WinBox.js](https://nextapps-de.github.io/winbox/) — window management feature reference
- [Dockview](https://dockview.dev/) — docking/panel feature patterns
- [2025 Survey of Rust GUI Libraries](https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-gui-libraries.html) — Rust GUI ecosystem state
- [PrimeVue Theming](https://primevue.org/theming/styled/) — design token architecture reference
- [Tauri vs Electron (DoltHub)](https://www.dolthub.com/blog/2025-11-13-electron-vs-tauri/) — binary size comparison

### Tertiary (LOW confidence)
- [CYBERCORE CSS](https://dev.to/sebyx07/introducing-cybercore-css-a-cyberpunk-design-framework-for-futuristic-uis-2e6c) — cyberpunk CSS patterns (reference only, do not depend on)
- [Cyberpunk 2077 Game UI Database](https://www.gameuidatabase.com/gameData.php?id=439) — visual reference for cyberpunk aesthetic patterns

---
*Research completed: 2026-02-25*
*Ready for roadmap: yes*