refactor: add typed frontend exhibit registry
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# GUPI OSINT Board: canonical exhibit data model
|
||||
|
||||
Status: accepted design foundation; core schema implemented by migration 006. Template clone operations, parties, and the frontend exhibit registry remain roadmap work.
|
||||
Status: accepted design foundation; the core schema, transactional template lifecycle, and frontend exhibit registry are implemented. Parties and richer event behavior remain roadmap work.
|
||||
|
||||
## Vocabulary
|
||||
|
||||
@@ -319,4 +319,4 @@ The following are computed and must not become duplicate source-of-truth tables:
|
||||
|
||||
## Implemented cutover
|
||||
|
||||
Migration 006 made this the sole persistence model. Because the POC database contained no canonical or legacy content worth preserving, the cutover intentionally dropped the JSON case store, `widgets`, `widget_relations`, and `playthrough_*` tables without a backfill period. Template save, version selection, instantiation, and reset now use one transactional board-cloning service. The remaining architectural work is the frontend exhibit/widget registry and the planned exhibit families.
|
||||
Migration 006 made this the sole persistence model. Because the POC database contained no canonical or legacy content worth preserving, the cutover intentionally dropped the JSON case store, `widgets`, `widget_relations`, and `playthrough_*` tables without a backfill period. Template save, version selection, instantiation, and reset use one transactional board-cloning service. Exhibit and document types resolve through the typed frontend registry; the remaining model work is the planned exhibit families and richer behavior.
|
||||
|
||||
Reference in New Issue
Block a user