Rozdíl mezi souborem návrhu a knihovnou komponent je identita. Soubor návrhu má tvary. Knihovna komponent má pojmenované, opakovaně použitelné části se stabilními identifikátory. components/inventory.json je odpověď figmascope na otázku: "které části v tomto návrhu jsou zamýšleny jako komponenty a jak se instance propojují zpět s nimi?"

Schéma

components/inventory.json je pole objektů:

[
  {
    "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"
  }
]

Každá položka má tři pole:

To je celé schéma. Je záměrně minimální.

Jak se instance propojují zpět

Propojení z instancí na inventář je v IR pro každou obrazovku. Každý uzel, který je INSTANCÍ komponenty, nese componentId a componentName:

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

componentId odpovídá id v inventory.json. componentName odpovídá name. Obě pole jsou přítomna, takže agent nemusí načítat inventory.json pro získání jména — ale pokud potřebuje vědět, že tato komponenta je součástí COMPONENT_SET, odkáže se na inventář.

Takto coding agent ví, že uzel tlačítka na obrazovce není vlastní rozvržení, které by měl reprodukovat podrobně — je to instance PrimaryButton, a měl by zavolat existující composable PrimaryButton() místo generování nového z strukturálních detailů IR.

Bez identity komponent agent generuje stejné tlačítko od začátku na každé obrazovce. S ní agent zavolá existující composable a přeskočí strukturální codegen úplně. Rozdíl je v tom, zda dostanete 40 bloků Row { Text(...) Surface { ... } } nebo 40 volání PrimaryButton(...).

Proč záleží na bezpečnosti refaktoringu

Design systémy se refaktorují. Tlačítko dostane nový tvar, nové odsazení, jinou barvu. Pokud byl veškerý generovaný kód strukturálně doslovný, refaktoring znamená úpravu každé obrazovky, která má tlačítko. Pokud generovaný kód používal referenci composable PrimaryButton, refaktoring je jeden soubor.

Inventář to umožňuje tím, že při generování ustanovuje smlouvu: "tento uzel není vlastní rozvržení, je to instance známé komponenty." Agent, který tuto smlouvu respektuje, generuje kód, který je již strukturován pro refaktoring na úrovni komponent.

To je primární strukturální výhoda oproti handoff na základě screenshotů. Screenshot tlačítka jsou pixely. Nemá žádnou identitu. Agent pracující ze screenshotu vždy generuje strukturální kód pro tlačítko na každé obrazovce. Agent pracující z IR s propojením na inventář může rozpoznat instanci a místo toho použít referenci komponenty.

COMPONENT vs. COMPONENT_SET

Systém komponent Figma má dvě úrovně. COMPONENT je definice jedné komponenty. COMPONENT_SET je kontejner pro varianty — to, co Figma nazývá "varianty" (např. tlačítko s primárním/sekundárním/destruktivním stylem a výchozím/přejetým/stisknutým stavem).

V praxi bude instance na obrazovce vždy odkazovat na COMPONENT (konkrétní variantu), ne na COMPONENT_SET. COMPONENT_SET je tam, aby agent věděl o celém povrchu variant, když potřebuje implementovat stavový stroj komponenty.

// Položky inventáře pro sadu 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 v IR obrazovky odkazuje na konkrétní variantu
{ "componentId": "890:101", "componentName": "Button/Primary/Default" }

Agent generující kód Compose pro toto ví: komponenta je Button se stylem Primary a stavem Default. Může odvodit, že signatura funkce pravděpodobně zahrnuje parametry style: ButtonStyle a state: ButtonState, nebo alespoň použít Button/Primary/Default jako sémantickou referenci pro primární tlačítko ve výchozím stavu.

Limit 300 položek

figmascope omezuje inventory.json na 300 položek. Figma soubory ve velkém měřítku — zejména soubory design systémů s rozsáhlými knihovnami komponent — mohou mít tisíce komponent. Zahrnutí všech do kontextového balíčku, který má být odeslán LLM, by odsadilo kontextové okno definicemi, které agent nepoužije pro implementované obrazovky.

Když je limit dosažen, v inventáři se zobrazí pole _truncated:

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

totalCount říká, kolik komponent v souboru existuje. included říká, kolik se jich dostalo do inventáře. Pořadí je podle prvního výskytu ve stromu uzlů Figma, takže komponenty odkazované brzy v dokumentu (typicky primární obrazovky) mají větší pravděpodobnost zahrnutí.

Pokud pracujete na obrazovkách, které používají komponenty definované pozdě v dokumentu a nejsou v inventáři, uzly IR pro ty instance stále mají componentId a componentName — informace o identitě jsou zachovány i když komponenta není v inventáři uvedena. Agent zná název komponenty z IR, i bez položky inventáře.

Co inventář nezahrnuje

Inventář je seznam identity, ne implementační specifikace. Říká vám, že existuje komponenta s názvem PrimaryButton s ID 789:012. Neříká vám:

Tyto mezery jsou záměrné ve v0.4. Úplné odvozování props komponent ze struktury IR je možné, ale pro komponenty s komplexní logikou variant by produkovalo nespolehlivé výsledky. Inventář dává stabilní identitu. Detaily implementace pocházejí z vaší existující kódové základny, ke které má agent také přístup.

Správné workflow: agent vidí componentId: "789:012", vyhledá ho v inventáři jako PrimaryButton, poté prohledá vaši kódovou základnu Kotlin pro PrimaryButton a zjistí skutečnou signaturu funkce. Inventář je most mezi návrhem a kódem, ne náhrada za kód. Inventář z libovolného Figma souboru exportujete na figmascope.dev.

Identita komponent v IR je to, co odděluje "generuj kód z tohoto návrhu" od "generuj kód, který zapadne do existující kódové základny." To první je hračka. To druhé je práce.

Srovnání s handoff pouze na základě screenshotů

Agent pracující z PNG stejné obrazovky nemá identitu komponent. Vidí modrý zaoblený obdélník s centrovaným textem a generuje:

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

Agent pracující z IR s inventářem vidí componentId: "789:012", vyhledá PrimaryButton, najde existující composable v kódové základně a generuje:

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

Druhý výstup se integruje s vaším design systémem. První vytváří divergenci. Inventář je to, co umožňuje druhý výstup. Více o tom, proč screenshoty selhávají jako artefakty handoff, viz Proč screenshoty selhávají.

IR pro jednotlivé obrazovky, který obsahuje reference componentId, je podrobně pokryt v IR pro jednotlivé obrazovky — Stack, Overlay, Absolute, Leaf. Celá struktura kontextového balíčku, která obsahuje oba artefakty, je představena přes Anatomii CONTEXT.md. Pro získání vlastního inventáře komponent spusťte figmascope na svém Figma souboru.