Design Component コレクション
概要
wf2des の直接組み立てフローに向けた、コンポーネントのインスタンス化コンテキストを保持するコレクション — 各 Figma コンポーネントがどのようにインスタンス化されるか(バリアントプロパティ、テキスト/画像スロット、デフォルトサイズ)であり、コンポーネントレジストリそのものではない。component_sweep が書き込む(決定論的な Figma REST 全ファイル走査、_id での upsert、single-flight ガード付き)。generation-assemble は、ある実行の inputs.components セットに固定されたコンポーネントをインスタンス化するためにこれを読み取る。
テーブル定義
| 論理名 | 物理名 | カラム名 | データ型 | 主キー | リレーション | ユニーク | NULL許可 | デフォルト値 | 備考 |
|---|---|---|---|---|---|---|---|---|---|
| Design Component | design_component | _id | string | ◯ | design:id | プラットフォームの design 行 id(type=component)= {project_id}_{figma_file_key}_{node_id}。これそのものが同一性であり、別の代理キーはない。figma_file_key/node_id は split('_', 2) により _id から導出され、別途格納しない(別の platform_design_id フィールドはない)。コンテキスト専用ドキュメント。レジストリのライフサイクル(存在/名前/削除/ステータス)はプラットフォームの design 行に置かれる(ここに removed_at はない)。node_id は assemble 時に _id から導出されてスペックの component_node_id になる |
|||
| organization_id | number | テナント所有者 | |||||||
| project_id | number | project:id | プロジェクトスコープ | ||||||
| component_key | string | ◯ | Figma のパブリッシュキー。NULL 可 — ローカルコンポーネントでは null(node_id でインスタンス化。パブリッシュキーなし) |
||||||
| kind | string | published / local | |||||||
| name | string | 表示名 | |||||||
| text_slots | object[] | テキスト置換スロット [{ layer_path: string, default_text: string, ambiguous: boolean }](曖昧性は登録時にフラグ付け)。例: [{"layer_path": "title", "default_text": "Page title", "ambiguous": false}] |
|||||||
| image_slots | object[] | sweep がコンポーネント内で発見する画像レイヤー(text_slots と並行)[{ layer_path: string, ambiguous: boolean }] — instancing コンテキスト用に記録される構造的プレースホルダー。自動塗りはされない |
|||||||
| default_size | object | { w: number, h: number }。例: {"w": 375, "h": 56} |
|||||||
| key_provenance | string | component_key を最後に書いた生成元。プラグインキャプチャ(plugin-observed)は REST スイープより優先されるため、再スイープが正規の key を null で上書きすることはない |
|||||||
| name_provenance | string | name についての同様の規則 |
|||||||
| family | object | ◯ | { name, node_id, node_type } — デザインシステム自身のグルーピング。スイープがコンポーネントを検出した SECTION から読む(例: Button、Heading、Form)。スイープ時にしか取得できず、後からは復元できないため記録する |
||||||
| variant_defaults | object | 軸 → デフォルト値(コンポーネントセットの宣言どおり) | |||||||
| variants | object[] | バリアントごとのプロファイル [{ variant_props, size, text_slots[], nested_components[], layout_shape, appearance[], semantics[] }] — 各バリアントが実際に保持する内容。軸ラベルを鵜呑みにせず兄弟バリアントを区別するために使う |
|||||||
| text_props | string[] | コンポーネントが公開する非バリアントのテキストプロパティ名 | |||||||
| semantics | object | ◯ | { kind, also_kinds[], is_placeholder, function[], appearance[], model_id, prompt_version, tagged_at, facts_hash }。kind は閉じた語彙の単一カテゴリ(button / form_field / heading / media / …)。is_placeholder は「内容を提供せず場所だけ確保する」コンポーネントを示す。拡充パス(pin cs@0.3)が書き込み、未実行なら NULL |
||||||
| lineage | object | 全ドキュメント共通の lineage ブロック { source_url, source_hash, processor_version, index_schema_version, processed_at, job_id }。source_hash ≡ コンポーネントサブツリーのコンテンツハッシュ(別の content_hash フィールドはない)。job_id = 生成元の実行 id(component_sweep 実行) |
リレーション
_id→ プラットフォームのdesign行 id(type=component)、値による。_idそのものがその id(代理キーはない)。- project_id → project.id
- DocumentDB 内ではリレーションは強制されない。論理リレーションであり、アプリケーションコードで検証する。
インデックス
- PRIMARY KEY (_id)
component_sweepの single-flight ガード(project_figma_fileドキュメント上のsweep_marker)下での_idの upsert。代理のユニークキーはない。- すべての読み書きは
organization_id+project_id(テナントスコープ)でフィルタする。
Type Codes
kind:
- published: パブリッシュ済みの Figma コンポーネント。
component_keyを持つ。 - local: ローカル(未パブリッシュ)コンポーネント。
component_keyは null で、node_idによってインスタンス化される。
注記
component_sweepがこのコレクションへの書き込みを所有する — 決定論的な Figma REST 全ファイル走査であり、どこにも LLM はない。すべてのフィールド(component_key、variant_properties、text_slots、image_slots、default_size)は Figma JSON の直接変換である。- インスタンス化コンテキスト専用。レジストリのライフサイクル(存在/名前/削除/ステータス)はプラットフォームの
design行(type=component)に置かれ、バックエンドが sweep マニフェストから UPSERT する — ここにremoved_atはなく、コンポーネントの削除は design 行のステータスとして記録される。 _idが唯一の同一性である:figma_file_keyとnode_idはsplit('_', 2)によってそこから復元されるため、別のfigma_file_key、node_id、platform_design_idフィールドは存在しない。generation-assembleは結果ドキュメントのinputs.componentsセットに固定されたコンポーネントについてこのドキュメントを読み取る。候補セットはレジストリ全体(重複排除・ハイジーン統合済み)で、どのセクションでも同一 — ロールやサイズのゲートはない。選択 LLM が各候補の完全な構造で選り分ける(サイズはゲートではなくシグナル。類似/検索の仕組みはない)。- assemble 時、バリデータの slot-constraints およびスペックの
instance.platform_design_idに対する安定キーは、変化しうる Figma のcomponent_keyではなくdesign_component._idである。 - ファイルレベルのローカルテキストスタイルとカラー変数はここに格納しない — それらは
project_figma_file.style_captures(figma_file_keyごとに 1 つ)に置かれ、派生スペックのstyle_bindingsマップの出所となる。