feat(data): scope conversion to a model-driven app

[david-hudec-networg]

Stacked on #190 → #191. Only the last commit belongs to this PR; the earlier ones are those two. GitHub cannot express a cross-fork stack, so the base has to be master. Review in order.

What it does

Lets the tool answer "what is this app built on", not only "what does this solution declare".

txc data model convert --root . --root ../TALXIS --app ntg_projectmanagement --target dbml

No environment or profile — an app names its own tables in its AppModule file, and everything it names is in source.

Three things about how apps sit on disk

These drove the implementation and are each covered by a test:

• The search is anchored on the AppModules folder, not on Declarations. Some modules keep their declarations under CDS instead, and a search anchored on either name silently misses the other.
• Identity is the UniqueName inside the file, never the folder name. The two differ in case in the wild — invisible on Windows, wrong on a case-sensitive filesystem.
• One app can be declared across several files — a base declaration plus fragments from other areas whose components carry solutionaction="Added". Its component set is the union of all of them.

Only type="1" components carry a table name; views, forms, charts and workflows reference their owner by id alone. Sitemap entities are included too, from both the Entity attribute and the etn parameter inside a Url — both forms occur, sometimes in the same file.

--root

Apps and entity schema live in different modules (Apps.Home vs Model), so scoping to an app structurally needs to reach past a single declarations folder. --root expands to every declarations folder beneath it, found by looking for the entity declarations themselves rather than a folder name. Pass the product repository as a second root when the base model lives there.

Ordering, which turned out to matter

Scoping runs before relationships are built. Filtering afterwards lets a relationship between two dropped tables synthesise both of them straight back as stubs — measured at 261 tables reappearing before this was ordered correctly.

A relationship is kept when its referencing side is in scope, so a lookup out of the app still terminates somewhere visible rather than dangling. Option sets belonging to dropped tables are pruned as well, or the output declares more enums than it has columns using them (907 enums for 883 columns, before).

Measured

Project root plus product root, one invocation each:

app	tables	refs	columns	enums
ntg_projectmanagement	70	124	883	88
ntg_administration	36	59	388	29
ntg_easementmanagement	79	183	1055	130
ntg_hiltipartnerportal	25	34	216	21

Four apps across three unrelated solutions, all parsed with @dbml/core. Same repositories, different app, radically different diagram — which is the point.

An unknown app fails with the apps it did find (Apps found: ntg_administration, ntg_operation, …), so a typo is a question rather than an empty diagram.

Back-compat

Without --app, nothing is filtered. Single-input conversion across three solutions × five targets is unchanged and idempotent by hash. ParseModules(List<Module>) and ParseRelationships(modules, tables) keep their existing signatures; the scope is an added optional parameter with one code path, not a parallel implementation.

Tests

tests/TALXIS.CLI.Tests/Data/DataModelConverter/AppScopeTests.cs — ten tests over temp folders and in-memory modules: type-1 only; CDS folder found; several files union; identity from content not folder; sitemap via attribute and via URL; unknown app lists what it found; out-of-scope tables dropped and not resurrected as stubs; a lookup out of the app still terminates; and nothing filtered without a scope.

🤖 Generated with Claude Code