Wireframe Collection

Overview

Collection for the wireframe structure parsed from a Figma wireframe frame. The wf2des worker writes it: wf_parse (plugin frame-registration) and the generation parse phase both extract the frame into a WFNode tree. The generation assemble phase and the plugin preview read it. Extraction is deterministic — the LLM assigns each node's role and intent only, never the tree shape — and this collection carries no retrieval embeddings.

Table Definition

Logical Name	Physical Name	Column Name	Data Type	Primary Key	Relation	Unique	Nullable	Default Value	Remarks
Wireframe	wireframe	_id	string	◯					Composite id {project_id}_{figma_file_key}_{node_id} (the platform wireframe-row id format); figma_file_key / node_id are derived from _id, not stored separately
		organization_id	number						Tenant owner
		project_id	number		project:id				Project scope
		name	string						Full Figma frame name (Japanese may exceed the PG frame_name 100-char cap)
		type	number						Content type — see Type Codes
		based_on	number						Origin — see Based On Codes
		screen_id	string				◯		Screen id; a wf_parse grammar miss yields null plus a logged ingest issue
		variation_label	string				◯		Deterministic frame-name split (e.g. 会員登録TOP｜案1 → 案1)
		structure	object						Parsed WFNode tree (recursive): { node_id, role, bbox {x,y,w,h}, intent (string\|null), text?, children[] }. Deterministic extraction; the LLM assigns role / intent only
		memos	object[]						{ memo_node_id, text, status } — status is open or resolved (resolved when inside a 取込済 frame; a resolved memo is excluded from live intent)
		board_regions	object[]						The comprehended board — one entry per region: [{ node_id, name, figma_type, x, y, features, marker_hit, resolved_marker_hit, is_registered_frame, text_sample[], role, refers_to }]. A board has no fixed layout (wireframe only, or with annotations and memos alongside), so regions are segmented and each is classified. This is the SOURCE of memos: intent comes from what a designer wrote as a NOTE about the screen, not from every string on the board
		summaries	object						{ element_type_histogram, node_count } — computed deterministically
		lineage	object						Shared lineage envelope on every doc { source_url, source_hash, processor_version, index_schema_version, processed_at, job_id }. The write fence is last-write-wins on (source_hash, processed_at); job_id = the producing wf_parse / generation-parse run

Relations

• project_id → project.id
• No direct relation is enforced inside DocumentDB; relations are logical and validated by application code.

Indexes

• PRIMARY KEY (_id)
• No vector indexes — this collection carries no retrieval embeddings.

Type Codes

Value	Meaning
0	page
1	component

Based On Codes

Value	Meaning
0	imported
1	design
2	wireframe

Notes

• Written by the wf2des worker: wf_parse (plugin frame registration) and the generation parse phase both produce this doc; wf_parse's output IS its record (no result doc, no webhook, no PG effect).
• The write fence is last-write-wins on (source_hash, processed_at) — a write lands only with a new source_hash or a newer processed_at. Generation-parse and wf_parse writing the same _id is intended non-collision.
• Direct assembly, no retrieval: this collection holds no visual / semantics vector embeddings. The generation assemble phase reads structure / memos deterministically and never does similarity search.
• The full parsed tree a generation run used is also snapshotted to the immutable parse.json artifact (referenced by design_generation_result.artifact_urls.parse), so a later reparse of this cache doc never rewrites the record a run relied on.
• Use based_on, not base_on — the column name matches the platform design / code based_on convention.