The gap
jmsfx-editor's stated purpose (CLAUDE.md) is editing the model file itself (`model-standard.yml`). Investigated the module end to end: there is no YAML read or write path anywhere in it - no SnakeYAML/Jackson-YAML imports, no file I/O at all.
What exists is `DynamicIconLibrary` + ~20 `*Impl` classes: a mutable, `ObservableList`/JavaFX-property-backed implementation of jmsfx-core's `IconLibrary`/`SymbolSet`/etc. interfaces. But `DynamicIconLibrary`'s only constructor (`DynamicIconLibrary(IconLibrary staticLibrary)`) builds a live mutable copy of an already-generated `IconLibrary` (i.e. `StandardIconLibrary.instance()`, jmsfx-standard's generated singleton) - it never reads YAML. So even "loading" today really means "clone the generated output," not "load the source of truth."
The actual YAML read/write logic that exists - `JmsfxParser.readLibraryModel`/`writeLibraryModel` in `jmsfx-generator` - operates on a completely different type hierarchy: `jmsfx-generator`'s own `LibraryModel`/`SymbolSetModel` generation-time DTOs, not jmsfx-core's `IconLibrary`/`SymbolSet` interfaces that `DynamicIconLibrary` implements. `jmsfx-editor`'s `pom.xml` doesn't even depend on `jmsfx-generator`. These two type systems were never connected.
Scope
This is real design work, not wiring:
Depends on / blocks
This is a prerequisite for #8 (the actual editor GUI) having anything real to load and save.
The gap
jmsfx-editor's stated purpose (CLAUDE.md) is editing the model file itself (`model-standard.yml`). Investigated the module end to end: there is no YAML read or write path anywhere in it - no SnakeYAML/Jackson-YAML imports, no file I/O at all.
What exists is `DynamicIconLibrary` + ~20 `*Impl` classes: a mutable, `ObservableList`/JavaFX-property-backed implementation of jmsfx-core's `IconLibrary`/`SymbolSet`/etc. interfaces. But `DynamicIconLibrary`'s only constructor (`DynamicIconLibrary(IconLibrary staticLibrary)`) builds a live mutable copy of an already-generated `IconLibrary` (i.e. `StandardIconLibrary.instance()`, jmsfx-standard's generated singleton) - it never reads YAML. So even "loading" today really means "clone the generated output," not "load the source of truth."
The actual YAML read/write logic that exists - `JmsfxParser.readLibraryModel`/`writeLibraryModel` in `jmsfx-generator` - operates on a completely different type hierarchy: `jmsfx-generator`'s own `LibraryModel`/`SymbolSetModel` generation-time DTOs, not jmsfx-core's `IconLibrary`/`SymbolSet` interfaces that `DynamicIconLibrary` implements. `jmsfx-editor`'s `pom.xml` doesn't even depend on `jmsfx-generator`. These two type systems were never connected.
Scope
This is real design work, not wiring:
Depends on / blocks
This is a prerequisite for #8 (the actual editor GUI) having anything real to load and save.