| name | lava-data-view |
| description | Wire up how an artifact renders in LAVA, end to end across the producer and the viewer. Use when adding a conversation view to an artifact, when a view renders wrong or not at all, when adding a field to the LAVA schema or manifest, or when asked to "add a module to the LAVA schema". |
Adding or changing a LAVA data view
LAVA/docs/schema/ is the authority and is more current than any summary:
| doc | covers |
|---|
docs/schema/data-views.md | every view type and every config field, with a required/optional table |
docs/schema/output-data-v1.md | the _lava_data manifest structure |
docs/schema/sqlite-data-v1.md | the artifact database layout |
Read data-views.md before writing a data_views block. This skill is the order of
operations and the traps around it.
The change is always two-sided
The extractor declares the view; LAVA renders it. A change to one half without the other
either does nothing or breaks the case. Decide up front which halves you are touching, and
say so in the PR.
Producer side (any of the five extractors): the data_views block in
__artifacts_v2__, plus whatever columns the view references.
Viewer side (LAVA): only needed for a genuinely new view type or a new config field.
An existing view type with a new artifact needs no LAVA change at all.
1. Producer: declare the view
Column values in the config are the display names as they appear in the artifact module,
not the sanitized SQL names. LAVA resolves them, and also accepts an exact match on the
sanitized form, so use the display name and stay consistent.
