Dictionary contents don't include referenced dictionaries

[anna-poplawski]

When I open a dictionary that has a referenced dictionary, only the contents of the top-level dictionary show up.

[ww-mw]

Thanks @anna-poplawski. Triaged: this is a real gap, but it is a feature decision about where inherited data belongs, not a bug I can fix unattended. Here is what the code actually says, so the decision can be made quickly.

What exists today

The extension shows a .sldd → .sldd reference in exactly one place: the Data Explorer sidebar tree, which draws sldd->sldd edges (src/host/SectionsTreeProvider.ts) and renders an unresolved one as unresolved reference and a cycle as ↻ circular reference. Clicking a node runs dataExplorer.openFile, so the referenced dictionary opens as its own tab.

The table shows nothing: neither the inherited entries nor the fact that a referenced dictionary exists at all. So if you are looking at the table — which is the main surface — a dictionary that inherits everything looks empty.

The part that makes this a decision

Core already has the resolver: resolveDictionaryReferences (src/core/DataModel.ts:1387). It has zero callers in the extension — not an oversight, but a documented contract. Its comment states it must not graft sub-dictionary entries into the parent's tree, and gives the reason: the same tree is what serializeSource writes back on save. Grafting inherited rows in would mean an edit to an inherited row lands in the wrong file, or silently disappears on save. The contract ends: "A host that wants to show inheritance shows two files."

So "just show the inherited entries in the table" is not a small display change; it collides with the model-is-the-save-payload invariant.

Options

(a) A read-only "Referenced Dictionaries" section in the table — a fifth section listing each referenced .sldd by name and resolution state (resolved / unresolved / circular), each row opening that file. Uses core's existing resolver for the names, grafts no entries, so the save payload is untouched. Makes inheritance discoverable from the surface where it is currently invisible, and keeps "an entry belongs to exactly one file" intact. Cost: the table's four sections are load-bearing in a few places (section counts, the section: ID convention, baseline diffing), so it needs care and its own tests.

(b) Show inherited entries inline, greyed — what the issue literally asks for. I'd reject this. It contradicts core's stated contract, and the failure mode is data loss: an edit to a greyed row either writes to the wrong dictionary or is dropped at save. If we ever want it, it needs a per-row provenance concept and a save router — a design change, not a display one.

(c) Discoverability only — leave the table alone, and make the existing sidebar edge easier to find (e.g. a count or a hint in the table header when a dictionary has references). Cheapest, no invariant risk, but it does not answer "what does this dictionary actually give me".

I'd recommend (a): it answers the real question (which dictionaries does this one build on, and let me go look) without pretending an inherited entry lives here. If the underlying need is really "see the effective merged set", that is a bigger feature — a resolved/flattened read-only view — and worth its own issue rather than being bolted onto the editable table.

@anna-poplawski — one thing that would decide between (a) and the bigger feature: are you trying to navigate to the parent dictionary, or to see the merged set of parameters in one list? They point at different designs.