Perbedaan antara file desain dan pustaka komponen adalah identitas. File desain memiliki bentuk. Pustaka komponen memiliki bagian bernama yang dapat digunakan ulang dengan pengenal yang stabil. components/inventory.json adalah jawaban figmascope untuk: "bagian mana dalam desain ini yang dimaksudkan sebagai komponen, dan bagaimana instance terhubung kembali ke sana?"

Skema

components/inventory.json adalah array objek:

[
  {
    "id": "789:012",
    "name": "PrimaryButton",
    "type": "COMPONENT"
  },
  {
    "id": "789:013",
    "name": "SecondaryButton",
    "type": "COMPONENT"
  },
  {
    "id": "890:100",
    "name": "Button",
    "type": "COMPONENT_SET"
  },
  {
    "id": "890:101",
    "name": "Button/Primary/Default",
    "type": "COMPONENT"
  },
  {
    "id": "890:102",
    "name": "Button/Primary/Pressed",
    "type": "COMPONENT"
  }
]

Setiap entri memiliki tiga bidang:

Itulah skema lengkapnya. Ini sengaja minimal.

Cara instance terhubung kembali

Tautan dari instance ke inventaris ada di per-screen IR. Setiap node yang merupakan INSTANCE dari komponen membawa componentId dan componentName:

// screens/home.json
{
  "kind": "stack",
  "id": "555:201",
  "componentId": "789:012",
  "componentName": "PrimaryButton",
  "axis": "horizontal",
  ...
}

componentId cocok dengan id di inventory.json. componentName cocok dengan name. Kedua bidang ada sehingga agen tidak harus memuat inventory.json untuk mendapatkan nama — tetapi jika perlu mengetahui bahwa komponen ini adalah bagian dari COMPONENT_SET, ia melakukan referensi silang inventaris.

Inilah cara agen koding mengetahui bahwa node tombol di layar bukan tata letak kustom yang harus direproduksi secara detail — itu adalah instance dari PrimaryButton, dan ia harus memanggil composable PrimaryButton() yang sudah ada daripada membuat yang baru dari detail struktural IR.

Tanpa identitas komponen, agen menghasilkan tombol yang sama dari awal di setiap layar. Dengan identitas, agen memanggil composable yang ada dan melewati codegen struktural sepenuhnya. Perbedaannya adalah apakah Anda mendapatkan 40 blok Row { Text(...) Surface { ... } } atau 40 panggilan PrimaryButton(...).

Mengapa ini penting untuk keamanan refactor

Design system di-refactor. Tombol mendapatkan bentuk baru, padding baru, warna berbeda. Jika semua kode yang dihasilkan secara literal struktural, refactor berarti menyentuh setiap layar yang memiliki tombol. Jika kode yang dihasilkan menggunakan referensi composable PrimaryButton, refactor hanya satu file.

Inventaris memungkinkan ini dengan menetapkan kontrak pada waktu pembuatan: "node ini bukan tata letak kustom, ini adalah instance dari komponen yang diketahui." Agen yang menghormati kontrak ini menghasilkan kode yang sudah terstruktur untuk refactor tingkat komponen.

Ini adalah keunggulan struktural utama dibandingkan handoff berbasis screenshot. Screenshot tombol adalah piksel. Ia tidak memiliki identitas. Agen yang bekerja dari screenshot akan menghasilkan kode struktural untuk tombol di setiap layar, selalu. Agen yang bekerja dari IR dengan tautan inventaris dapat mengenali instance dan menggunakan referensi komponen sebagai gantinya.

COMPONENT vs. COMPONENT_SET

Sistem komponen Figma memiliki dua level. COMPONENT adalah definisi tunggal. COMPONENT_SET adalah wadah untuk varian — apa yang Figma sebut "varian" (misalnya, tombol dengan status Primary/Secondary/Destructive dan Default/Hovered/Pressed).

Dalam praktiknya, instance dalam layar akan selalu mereferensikan COMPONENT (varian spesifik), bukan COMPONENT_SET. COMPONENT_SET ada agar agen mengetahui permukaan varian penuh ketika perlu mengimplementasikan state machine komponen.

// Entri inventaris untuk set Button
{ "id": "890:100", "name": "Button", "type": "COMPONENT_SET" }
{ "id": "890:101", "name": "Button/Primary/Default", "type": "COMPONENT" }
{ "id": "890:102", "name": "Button/Primary/Pressed", "type": "COMPONENT" }
{ "id": "890:103", "name": "Button/Secondary/Default", "type": "COMPONENT" }

// Instance dalam IR layar mereferensikan varian spesifik
{ "componentId": "890:101", "componentName": "Button/Primary/Default" }

Agen yang menghasilkan kode Compose untuk ini tahu: komponen adalah Button dengan gaya Primary dan status Default. Ia dapat menyimpulkan tanda tangan fungsi kemungkinan melibatkan parameter style: ButtonStyle dan state: ButtonState, atau minimal menggunakan Button/Primary/Default sebagai referensi semantik untuk tombol primary dalam status default.

Batas 300 entri

figmascope membatasi inventory.json pada 300 entri. File Figma dalam skala besar — terutama design system dengan pustaka komponen yang lengkap — dapat memiliki ribuan komponen. Menyertakan semuanya dalam context bundle yang dimaksudkan untuk dikirim ke LLM akan memadati context window dengan definisi yang tidak akan digunakan agen untuk layar yang sedang diimplementasikan.

Ketika batas tercapai, bidang _truncated muncul dalam inventaris:

[
  { "id": "...", "name": "...", "type": "COMPONENT" },
  ...
  { "_truncated": true, "totalCount": 847, "included": 300 }
]

totalCount memberi tahu Anda berapa banyak komponen yang ada dalam file. included memberi tahu Anda berapa banyak yang masuk ke inventaris. Urutannya berdasarkan yang pertama ditemukan dalam pohon node Figma, jadi komponen yang direferensikan di awal dokumen (biasanya layar utama) lebih mungkin disertakan.

Jika Anda bekerja pada layar yang menggunakan komponen yang didefinisikan belakangan dalam dokumen dan tidak ada dalam inventaris, node IR untuk instance tersebut masih memiliki componentId dan componentName — informasi identitas tetap terjaga bahkan ketika komponen tidak terdaftar dalam inventaris. Agen mengetahui nama komponen dari IR, bahkan tanpa entri inventaris.

Apa yang tidak disertakan inventaris

Inventaris adalah daftar identitas, bukan spesifikasi implementasi. Ia memberi tahu Anda bahwa komponen bernama PrimaryButton dengan ID 789:012 ada. Ia tidak memberi tahu Anda:

Kesenjangan ini disengaja dalam v0.4. Inferensi props komponen penuh dari struktur IR dimungkinkan tetapi akan menghasilkan hasil yang tidak dapat diandalkan untuk komponen dengan logika varian yang kompleks. Inventaris memberikan identitas yang stabil. Detail implementasi datang dari codebase Anda yang sudah ada, yang juga dapat diakses agen.

Workflow yang tepat: agen melihat componentId: "789:012", mencarinya di inventaris sebagai PrimaryButton, kemudian mencari PrimaryButton di codebase Kotlin Anda untuk memahami tanda tangan fungsi yang sebenarnya. Inventaris adalah jembatan antara desain dan kode, bukan pengganti kode. Anda dapat mengekspor inventaris dari file Figma apa pun di figmascope.dev.

Identitas komponen dalam IR adalah yang memisahkan "hasilkan kode dari desain ini" dari "hasilkan kode yang cocok dengan codebase yang ada." Yang pertama adalah mainan. Yang kedua adalah pekerjaannya.

Perbandingan dengan handoff hanya-screenshot

Agen yang bekerja dari PNG layar yang sama tidak memiliki identitas komponen. Ia melihat persegi panjang biru bulat dengan teks terpusat dan menghasilkan:

Box(
    modifier = Modifier
        .background(Color(0xFF7F5CFE), RoundedCornerShape(24.dp))
        .padding(horizontal = 32.dp, vertical = 16.dp)
) {
    Text("Start", color = Color.White, fontWeight = FontWeight.SemiBold)
}

Agen yang bekerja dari IR dengan inventaris melihat componentId: "789:012", mencari PrimaryButton, menemukan composable yang ada di codebase, dan menghasilkan:

PrimaryButton(
    label = stringResource(R.string.start),
    onClick = { /* TODO */ }
)

Output kedua terintegrasi dengan design system Anda. Yang pertama menciptakan divergensi. Inventaris adalah yang membuat output kedua mungkin. Untuk lebih lanjut tentang mengapa screenshot gagal sebagai artefak handoff, lihat Mengapa Screenshot Gagal.

Per-screen IR yang berisi referensi componentId dibahas secara rinci dalam Per-Screen IR — Stack, Overlay, Absolute, Leaf. Struktur context bundle lengkap yang berisi kedua artefak diperkenalkan melalui Anatomi CONTEXT.md. Untuk mendapatkan inventaris komponen Anda sendiri, jalankan figmascope pada file Figma Anda.