Restore a data source or code generator where it was (#141)

[matt-edmondson]

Closes #141.

The bug

Schema.RestoreDataSource and RestoreCodeGenerator append. So undoing a delete put the element back in the schema, but at the end — quietly reordering it. Order is part of the schema's meaning: it round-trips through the file and drives the order generated code is written in.

Classes, enums and members were already fixed, by remembering the index before the delete and moving the element back after the restore. Data sources and code generators could not be, because Schema exposed an ordered set for the first two (ClassSet, EnumSet) and nothing for the other two — the editor had nothing to reposition them with. That gap is what #141 records, and what the roadmap's decision 8 said was outstanding.

The fix

Schema now exposes DataSourceSet and CodeGeneratorSet, mirroring the existing pair exactly:

public SchemaChildSet<DataSource, DataSourceName> DataSourceSet => new(DataSourcesInternal);
public SchemaChildSet<SchemaCodeGenerator, CodeGeneratorName> CodeGeneratorSet => new(CodeGeneratorsInternal);

Additive public API — read-through views over the same collections the schema already serializes, so there is no second copy to diverge and no change to the on-disk format. The editor's two delete commands then take the same shape as the class and enum ones.

A note on the API decision

I raised this on #141 as the owner's call, because it puts new surface on a published package. I have gone ahead on the assumption that it is routine: the properties are additive rather than breaking, and exactly symmetric with ClassSet/EnumSet — the alternative shape (an index parameter on Restore*) would change existing signatures instead. If you would rather have that shape, say so and I will rework it.

Tests

Five in Schema.Test (new SchemaRootSetTests) — order through each set, IndexOf, the remove → restore → move sequence with the appended order asserted in between so the move is what is being tested, and that a repositioned data source survives a serialization round trip.

Two in SchemaEditor.Test that drive the real context menu: delete the middle of three, undo, and check all three are back in their original order. Deleting from the middle matters — at either end, appending on restore is indistinguishable from doing it correctly.

Both editor tests fail if the restore appends; I checked by making it append, one at a time.

304 library tests and 98 editor tests, 0 failures.

Also

Two stale entries in docs/ROADMAP.md, found while updating decision 8:

• Remove or wire up the unused Schema.Contracts API surface and its dead helpers #110 was listed both as outstanding work and as the number-one thing to decide next, but it was closed by Make the models implement Schema.Contracts (#110) #129 back in August.
• Decision 8 said data sources and code generators still restore at the end. It now describes what this PR makes true, and says why Restore* still appends — the position is the caller's to remember.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Jc8o5zF3cmfCGjzWvQdGDE

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
10 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud